Sitôt que l’ensemble cible est non vide, un mandataire PEUT commencer à transmettre la demande. Un mandataire à états pleins PEUT traiter l’ensemble dans n’importe quel ordre. Il PEUT traiter plusieurs cibles en série, permettant à
chaque transaction client de se terminer avant de commencer la suivante. Il PEUT commencer des transactions client avec chaque cible en parallèle. Il PEUT aussi diviser arbitrairement l’ensemble en groupes, traitant les groupes en série et traitant les cibles dans chaque groupe en parallèle.
Un mécanisme d’ordonnancement courant est d’utiliser le paramètre qvaleur des cibles obtenues des champs d’en-tête Contact (voir au paragraphe 20.10). Les cibles sont traitées de la plus forte qvaleur à la plus faible. Les cibles avec des qvaleur égales peuvent être traitées en parallèle.
Un mandataire à états pleins doit avoir un mécanisme de maintenance de l’ensemble cible lorsque les réponses sont reçues et associer les réponses à chaque demande transmise avec la demande originelle. Pour les besoins du modèle, ce mécanisme est un "contexte de réponse" créé par la couche mandataire avant la transmission de la première demande.
Pour chaque cible, le mandataire transmet la demande en suivant ces étapes : 1. Faire une copie de la demande reçue
2. Mettre à jour l’URI-de-demande
3. Mettre à jour le champ d’en-tête Max-Forwards
4. Ajouter facultativement une valeur de champ d’en-tête Record-route 5. Ajouter facultativement un champ d’en-tête supplémentaire
6. Post-traiter les informations d’acheminement
7. Déterminer l’adresse, port, et transport du prochain saut 8. Ajouter une valeur de champ d’en-tête Via
9. Ajouter si nécessaire un champ d’en-tête Content-Length 10. Transmettre la nouvelle demande
11. Etablir le temporisateur C
Chacune de ces étapes est détaillée ci-dessous.
1. Copie de la demande
Le mandataire commence par une copie de la demande reçue. La copie DOIT initialement contenir tous les champs d’en-tête provenant de la demande reçue. Les champs non détaillés dans le traitement décrit ci-dessous NE DOIVENT PAS être retirés. La copie DEVRAIT conserver l’ordre des champs d’en-tête comme dans la demande reçue. Le mandataire NE DOIT PAS réordonner les valeurs de champs avec un nom de champ commun (voir au paragraphe 7.3.1). Le mandataire NE DOIT PAS ajouter au corps de message, ni le modifier ou le retirer.
Une mise en œuvre réelle n’a pas besoin d’effectuer une copie ; la principale exigence est que le traitement pour chaque prochain saut commence avec la même demande.
2. URI-de-demande
L’URI-de-demande dans la ligne de début de la copie DOIT être remplacé par l’URI pour cette cible. Si l’URI contient des paramètres non autorisés dans un URI-de-demande, ils DOIVENT être retirés.
Ceci est l’essence du rôle du mandataire. C’est le mécanisme par lequel un mandataire achemine une demande vers sa destination.
Dans certaines circonstances, l’URI-de-demande reçu est placé dans l’ensemble cible sans être modifié. Pour cette cible, le remplacement ci-dessus est effectivement une no-op.
3. Max-Forwards
Si la copie contient un champ d’en-tête Max-Forwards, le mandataire DOIT diminuer sa valeur de un (1).
Si la copie ne contient pas de champ d’en-tête Max-Forwards, le mandataire DOIT en ajouter un avec une valeur de champ qui DEVRAIT être 70.
Certains agents d’utilisateur existants ne fourniront pas de champ d’en-tête Max-Forwards dans une demande.
4. Record-Route
Si ce mandataire souhaite rester sur le chemin des demandes futures dans un dialogue créé par cette demande (en supposant que la demande crée un dialogue), il DOIT insérer une valeur de champ d’en-tête Record-Route dans la copie avant toute valeur de champ d’en-tête Record-Route existant, même si un champ d’en-tête Route est déjà présent.
Les demandes qui établissent un dialogue peuvent contenir un champ d’en-tête Route préchargé.
Si cette demande fait déjà partie d’un dialogue, le mandataire DEVRAIT insérer une valeur de champ d’en-tête Record-Route s’il souhaite rester sur le chemin des demandes futures dans le dialogue. Dans le fonctionnement normal de point d’extrémité, comme indiqué au paragraphe 12, ces valeurs de champs d’en-tête Record-Route n’auront aucun effet sur l’ensemble des routes utilisées par les points d’extrémité.
Le mandataire va rester sur le chemin s’il choisit de ne pas insérer de valeur de champ d’en-tête Record-Route dans des demandes qui font déjà partie d’un dialogue. Cependant, il serait retiré du chemin lorsqu’un point d’extrémité ayant
subi un échec reconstitue le dialogue.
Un mandataire PEUT insérer une valeur de champ d’en-tête Record-Route dans toute demande. Si la demande n’initialise pas un dialogue, les points d’extrémité ignoreront la valeur. Voir à la Section 12 les précisions sur la façon dont les points d’extrémité utilisent les valeurs de champ d’en-tête Record-Route pour construire les champs d’en-tête Route.
Chaque mandataire sur le chemin d’une demande choisit indépendamment s’il ajoute une valeur de champ d’en-tête Record-Route - la présence d’un champ d’en-tête Record-Route dans une demande n’oblige pas ce mandataire à ajouter une valeur.
L’URI placé dans la valeur de champ d’en-tête Record-Route DOIT être un URI SIP ou SIPS. Cet URI DOIT contenir un paramètre lr (voir au paragraphe 19.1.1). Cet URI PEUT être différent pour chaque destination à laquelle la demande est transmise. L’URI NE DEVRAIT PAS contenir le paramètre de transport sauf si le mandataire a connaissance (comme dans le cas d’un réseau privé) que le prochain élément vers l’aval qui sera dans le chemin des demandes ultérieures prend en charge ce transport.
L’URI que fournit ce mandataire sera utilisé par un autre élément pour prendre une décision d’acheminement. Ce mandataire, en général, n’a aucun moyen de savoir les capacités de cet élément, de sorte qu’il doit se restreindre aux éléments obligatoires d’une mise en œuvre SIP : les URI SIP et les transports TCP ou UDP.
L’URI placé dans le champ d’en-tête Record-Route DOIT se résoudre aux élément qui l’insèrent (ou un remplaçant convenable) lorsque les procédures de localisation de serveur de [4] lui sont appliquées, de façon que les demandes ultérieures atteignent le même élément SIP. Si l’URI-de-demande contient un URI SIPS, ou si la valeur de champ tête Route la plus élevée (après le post traitement du point 6) contient un URI SIPS, l’URI placé dans le champ d’en-tête Record-Route DOIT être un URI SIPS. De plus, si la demande n’a pas été reçue sur TLS, le mandataire DOIT insérer un champ d’en-tête Record-Route. De façon similaire, un mandataire qui reçoit une demande sur TLS, mais génère une demande sans URI SIPS dans l’URI-de-demande ou la plus forte valeur de champ d’en-tête Route (après le post traitement du point 6), DOIT insérer un champ d’en-tête Record-Route qui n’est pas un URI SIPS.
Un mandataire sur un périmètre de sécurité doit rester sur ce périmètre tout au long du dialogue.
Si l’URI placé dans le champ d’en-tête Record-Route doit être réécrit lorsqu’il repasse à travers une réponse, l’URI DOIT être suffisamment distinct pour être localisé à ce moment. (La demande peut être en train de faire une spirale passant par ce mandataire, ce qui a pour résultat d’ajouter plus d’une valeur de champ d’en-tête Record-Route). Le point 8 du paragraphe 16.7 recommande un mécanisme pour rendre l’URI suffisamment distinct.
Le mandataire PEUT inclure des paramètres dans la valeur de champ d’en-tête Record-Route. Il leur sera fait écho dans certaines réponses à la demande comme les réponses 200 (OK) à INVITE. De tels paramètres peuvent être utiles pour la conservation de l’état dans le message plutôt que chez le mandataire.
Si un mandataire a besoin d’être sur le chemin d’un type de dialogue quelconque (tel que celui pour enjamber un pare-feu), il DEVRAIT ajouter une valeur de champ d’en-tête Record-Route à chaque demande ayant une méthode qu’il ne comprend pas car cette méthode peut avoir une sémantique de dialogue.
L’URI qu’un mandataire place dans un champ d’en-tête Record-Route n’est valide que pour la durée de vie de tout dialogue créé par la transaction dans laquelle il survient. Un mandataire de dialogue à états pleins, par exemple, PEUT refuser d’accepter les futures demandes avec cette valeur dans l’URI-de-demande après la fin du dialogue. Les mandataires de dialogue à état plein, bien sûr, n’ont aucune idée du moment où le dialogue se termine, mais ils PEUVENT coder suffisamment d’informations dans la valeur pour la comparer avec l’identifiant de dialogue des futures demandes et PEUT rejeter des demandes qui ne correspondent pas à cette information. Les points d’extrémité NE DOIVENT PAS utiliser un URI obtenu d’un champ d’en-tête Record-Route en-dehors du dialogue dans lequel il a été fourni. Voir à la Section 12 des informations complémentaires sur l’utilisation par les point d'extrémité du champ d’en-tête Record-Route.
Le Record-route peut être nécessaire à certains services où le mandataire a besoin d’observer tous les messages d’un dialogue. Cependant, cela ralentit le traitement et obère l’extensibilité et donc les mandataires ne devraient utiliser Record-route que si c’est demandé pour un service précis.
Le processus Record-Route est conçu pour fonctionner avec toute demande SIP qui initialise un dialogue. INVITE est la seule demande de cette sorte dans la présente spécification, mais les extensions au protocole PEUVENT en définir d’autres.
5. Ajout de champs d’en-tête supplémentaires
Le mandataire PEUT ajouter tout autre champ d’en-tête approprié à la copie à ce moment.
6. Post-traitement des informations d’acheminement
Un mandataire PEUT avoir une politique locale qui ordonne qu’une demande visite un ensemble spécifique de mandataires avant d’être livrée à sa destination. Un mandataire DOIT s’assurer que tous ces mandataires sont des routeurs souples. Généralement, ceci ne peut être connu avec certitude que si les mandataires sont au sein du même domaine administratif. Cet ensemble de mandataires est représenté par un ensemble d’URI (dont chacun contient le paramètre lr). Cet ensemble DOIT être poussé dans le champ d’en-tête Route de la copie avant toutes les valeurs existantes, s’il en est. Si le champ d’en-tête Route est absent, il DOIT être ajouté, contenant cette liste des URI.
Si le mandataire a une politique locale qui oblige que la demande visite un mandataire spécifique, une alternative à l’introduction d’une valeur de Route dans le champ d’en-tête Route est de sauter la logique de transmission du point 10 ci-dessous, et à la place d’envoyer simplement la demande à l’adresse, port, et transport de ce mandataire spécifique. Si la demande a un champ d’en-tête Route, cette alternative NE DOIT PAS être utilisée à moins qu’il soit connu que le prochain mandataire de saut est un routeur souple. Autrement, cette approche PEUT être utilisée, mais le mécanisme d’insertion de Route ci-dessus est préférable pour sa robustesse, sa souplesse, son caractère général et sa cohérence de fonctionnement. De plus, si l’URI-de-demande contient un URI SIPS, TLS DOIT être utilisé pour communiquer avec ce mandataire.
Si la copie contient un champ d’en-tête Route, le mandataire DOIT inspecter l’URI dans sa première valeur. Si cet URI ne contient pas de paramètre lr, le mandataire DOIT modifier la copie comme suit :
- Le mandataire DOIT placer l’URI-de-demande dans le champ d’en-tête Route comme dernière valeur.
- Le mandataire DOIT ensuite placer la première valeur de champ d’en-tête Route dans l’URI-de-demande et retirer cette valeur du champ d’en-tête Route.
Ajouter l’URI-de-demande au champ d’en-tête Route fait partie d’un mécanisme utilisé pour passer des informations dans cet URI-de-demande à travers des éléments à acheminement strict. "Sauter" la première valeur de champ d’en-tête Route dans l’URI-de-demande formate le message de la façon dont un élément à acheminement strict s’attend à le recevoir (avec son propre URI dans l’URI-de-demande et la prochaine localisation à visiter dans la première valeur de champ d’en-tête Route).
7. Déterminer l’adresse, port, et transport du prochain saut
Le mandataire PEUT avoir une politique locale d’envoi de la demande à une adresse, port, et transport IP spécifiques, indépendamment des valeurs de Route et URI-de-demande. Une telle politique NE DOIT PAS être utilisée si le mandataire n’est pas certain que l’adresse, port, et transport IP correspondent à un serveur qui soit un routeur souple.
Cependant, ce mécanisme d’envoi de la demande à travers un prochain saut spécifique N’EST PAS RECOMMANDÉ ; au lieu de cela, un champ d’en-tête Route devrait être utilisé à cette fin comme décrit ci-dessus.
En l’absence d’un tel mécanisme de substitution, le mandataire applique comme suit les procédures dont la liste figure en [4] pour déterminer où envoyer la demande. Si le mandataire a reformaté la demande pour l’envoyer à un élément à acheminement strict, comme décrit à l’étape 6 ci-dessus, le mandataire DOIT appliquer ces procédures à l’URI-de-demande de la l’URI-de-demande. Autrement, le mandataire DOIT appliquer les procédures à la première valeur dans le champ d’en-tête Route, s’il est présent, et autrement à l’URI-de-demande. Les procédures produiront un ensemble ordonné de tuplets (adresse, port, transport). Indépendamment de l’URI qui est utilisé comme entrée à ces procédures de [4], si l’URI-de-demande spécifie une ressource SIPS, le mandataire DOIT suivre les procédures de [4] comme si l’URI d’entrée était un URI SIPS.
Comme décrit en [4], le mandataire DOIT essayer de livrer le message au premier tuplet de cet ensemble, et continuer à travers l’ensemble dans l’ordre jusqu’à la réussite de la livraison.
Pour chaque tuplet essayé, le mandataire DOIT formater le message conformément au tuplet et envoyer la demande en utilisant une nouvelle transaction client comme précisé aux étapes de 8 à 10.
Comme chaque tentative utilise une nouvelle transaction client, elle représente une nouvelle branche. Et donc, le paramètre branche fourni avec le champ d’en-tête Via inséré dans l’étape 8 DOIT être différent à chaque tentative.
Si la transaction client rapporte l’échec de l’envoi de la demande ou une fin de temporisation de la part de l’automate à états, le mandataire continue avec l’adresse suivante de l’ensemble ordonné. Si l’ensemble ordonné est épuisé, la demande ne peut être transmise à cet élément dans l’ensemble cible. Le mandataire n’a pas besoin de placer quelque chose dans le contexte de réponse, mais agit comme si cet élément de l’ensemble cible avait retourné une réponse finale 408 (Délai de demande expiré).
8. Ajout d’une valeur de champ d’en-tête Via
Le mandataire DOIT insérer une valeur de champ d’en-tête Via dans la copie avant les valeurs de champ d’en-tête Via
existantes. La construction de cette valeur suit les mêmes lignes directrices qu’au paragraphe 8.1.1.7. Ceci implique que le mandataire va calculer son propre paramètre de branche, qui devra être mondialement unique pour cette branche, et contenir le témoin de connexion requis. Noter que ceci implique que le paramètre de branche soit différent pour les différentes instances d’une demande spiralée ou bouclée à travers un mandataire.
Les mandataires qui choisissent de détecter les boucles ont une contrainte supplémentaire par la valeur qu’ils utilisent pour la construction du paramètre de branche. Un mandataire qui choisit de détecter les boucles DEVRAIT créer un paramètre de branche séparable en deux parties par la mise en œuvre. La première partie DOIT satisfaire aux contraintes du paragraphe 8.1.1.7 comme décrit ci-dessus. La seconde sert à effectuer la détection de boucle et distinguer les boucles des spirales.
La détection de boucle est effectuée en vérifiant que, lorsqu’une demande retourne au mandataire, les champs qui ont un impact sur le traitement de la demande n’ont pas changé. La valeur placée dans cette partie du paramètre de branche DEVRAIT refléter tous ces champs (y compris tout champs d’en-tête Route, Proxy-Require et Proxy-Authorization).
Ceci est destiné à s’assurer que si la demande est renvoyée au mandataire et qu’un de ces champs change, elle est traitée comme une spirale et non une boucle (voir au paragraphe 16.3). Une façon commune de créer cette valeur est de calculer un hachage cryptographique de l’étiquette To, de l’étiquette From, du champ d’en-tête Call-ID, de l’URI-de-demande de la l’URI-de-demande reçue (avant traduction), de l’en-tête Via le plus élevé, et du numéro de séquence provenant du champ d’en-tête CSeq, en plus de tout champ d’en-tête Proxy-Require et Proxy-Authorization qui pourrait être présent.
L’algorithme utilisé pour calculer le hachage dépend de la mise en œuvre, mais MD5 (RFC 1321 [35]), exprimé en hexadécimal, est un choix raisonnable. (La Base64 n’est pas admissible pour un jeton.)
Si un mandataire souhaite détecter les boucles, le paramètre "branch" qu’il fournit DOIT dépendre de toutes les informations qui affectent les traitement d’une demande, y compris l’URI-de-demande entrant et tout champ d’en-tête affectant l’admission ou l’acheminement de la demande. Ceci est nécessaire pour distinguer les demandes en boucle des demandes dont les paramètres d’acheminement ont changé avant de revenir à ce serveur.
La méthode de la demande NE DOIT PAS être incluse dans le calcul du paramètre branch. En particulier, les demandes CANCEL et ACK (pour les réponses non 2xx) DOIVENT avoir la même valeur branch que la demande correspondante qu’elles annulent ou dont elles accusent réception. Le paramètre branch est utilisé pour corréler ces demandes au serveur qui les traite (voir au paragraphes 17.2.3 et 9.2).
9. Ajout d’un champ d’en-tête Content-Length si nécessaire
Si la demande va être envoyée au prochain saut en utilisant un transport fondé sur le flux et que la copie ne contient aucun champ d’en-tête Content-Length, le mandataire DOIT en insérer un avec la valeur correcte pour le corps de la demande (voir au paragraphe 20.14).
10. Transmission de la demande
Un mandataire à états pleins DOIT créer une nouvelle transaction client pour cette demande comme indiqué au paragraphe 17.1 et ordonner à la transaction d’envoyer la demande en utilisant l’adresse, le port et le transport déterminés dans l’étape 7.
11. Etablir le temporisateur C
Afin de traiter le cas où une demande INVITE ne génère jamais une réponse finale, le TU utilise un temporisateur qu’on appelle temporisateur C. Le temporisateur C DOIT être établi pour chaque transaction client lorsqu’une demande INVITE est passée par un mandataire. Le temporisateur DOIT être supérieur à 3 minutes. Le paragraphe 16.7, point 2 discute de la façon dont ce temporisateur est mis à jour avec les réponses provisoires, et le paragraphe 16.8 discute du traitement lorsqu’il arrive à expiration.