Groupe de travail Réseau	T. Froment, Tech-invite	
Request for Comments: 5658	C. Lebel, Alcatel-Lucent	
Catégorie : Sur la voie de la normalisation	B. Bonnaerens, Alcatel-Lucent	
Traduction Claude Brière de L'Isle	octobre 2009	

Questions d'adressage de Record-Route 
dans le protocole d'initialisation de session (SIP)

Résumé
Une fonction typique d'un mandataire du protocole d'initiation de session (SIP, Session Initiation Protocol) est d'insérer un en-tête Record-Route dans les demandes initiales, créatrices de dialogue, afin de faire que les demandes suivantes, dans le dialogue, passent à travers ce chemin. Cet en-tête contient un identifiant de ressource universel (URI, Uniform Resource Identifier) SIP ou SIPS (SIP sécurisé) qui indique où et comment les demandes suivantes devraient être envoyées pour atteindre le mandataire. Ces URI SIP ou SIPS peuvent contenir des adresses IPv4 ou IPv6 et des paramètres d'URI qui pourraient influencer l'acheminement, comme le paramètre de transport (par exemple, transport=tcp) ou une indication de compression comme "comp=sigcomp". Quand un mandataire doit changer certains de ces paramètres entre ses interfaces entrantes et sortantes (mandataires multi-rattachements, commutation de protocole de transport, ou scénarios de IPv4 à IPv6, etc.) la question se pose de ce qui devrait être mis dans le ou les en-têtes Record-Route. Il n'est pas possible de faire qu'un en-tête ait les caractéristiques des deux interfaces en même temps. Le présent document vise à clarifier ces scénarios et à corriger les fautes déjà identifiées sur ce sujet ; il recommande formellement l'utilisation de la technique de double Record-Route comme solution de remplacement au texte de la RFC 3261, qui décrit seulement une solution de réécriture du Record-Route.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Table des matières
1. Introduction	2
2. Terminologie	2
3. Position du problème	2
3.1 Fondements : mandataires multi-rattachements	2
3.2 Problèmes identifiés	3
4. Réécriture de Record-Route	3
5. Double Record-Routing	4
6. Usage du paramètre Protocole de transport	6
6.1 Problèmes et recommandations de mise en œuvre à l'UA	6
6.2 Problèmes et recommandations de mise en œuvre chez le mandataire	9
7. Conclusion	9
8. Considérations sur la sécurité	10
9. Remerciements	10
10. Références	10
10.1 Références normatives	10
10.2 Références pour information	10
Adresse des auteurs	11

 	1.	Introduction

Au fil des ans, il a été remarqué dans des événements d'interopérabilité comme SIPit, que de nombreuses mises en œuvre avaient des problèmes d'interopérabilité en relation avec Record-Routing (enregistrement de chemin) ou à cause d'une mauvaise interprétation de la [RFC3261] ; en particulier, quand un changement survient entre le côté entrant et le côté sortant d'un mandataire : commutation de protocole de transport, mandataires "multi-rattachements" (incluant des changements d'interface d'IPv4 à IPv6) etc. Plusieurs documents ont traité de cette question, chacun d'eux fournissant généralement une recommandation adéquate pour son cas d'utilisation spécifique, mais aucun d'eux ne donne une solution générale ou ne fournit en ensemble cohérent de précisions :

-	La [RFC3486], Section 6, décrit le double Record-Route comme une solution de remplacement pour la réécriture du Record-Route dans les réponses. Ce document a une portée limitée au paramètre "comp=sigcomp" quand il fait la compression avec la compression de signalisation (SIGCOMP, Signalling Compression).

-	La [RFC3608], paragraphe 6.2, recommande l'usage du double Record-Route au lieu de la solution de réécriture décrite dans la [RFC3261] pour les mandataires "à double rattachement". Ceux-ci sont définis comme des "mandataires connectés à deux (ou plus) réseaux différents de sorte que les demandes sont reçues sur une interface et transmises à travers une autre interface réseau".

-	Le paragraphe 3.1.1 de la [RFC6157] rend obligatoire un double Record-Route pour les mandataires multi-rattachements qui font des transitions IPv4/IPv6, quand le mandataire insère des adresses IP dans l'en-tête d'URI Record-Route.

Les problèmes d'interopérabilité observés peuvent être expliqués par le fait que, en dépit de ces divers documents, la description de la RFC 3261 n'a pas été changée, et de nombreuses mises en œuvre ne prennent pas en charge les extensions comme Service-Route ([RFC3608]) ou SIGCOMP ([RFC3486]).

Le présent document vise aussi à préciser une erreur identifiée référencée dans [BUG664]. En particulier, il prend en compte la recommandation de [BUG664], qui dit que "le langage qui décrit cela, doit clairement exprimer que cela s'applique à tous les types d'interface différente sur chaque côté de sortie, y compris IPv4 d'un côté et IPv6 sur les autres".

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Position du problème
 	3.1	Fondements : mandataires multi-rattachements
Un mandataire multi rattachements est un mandataire connecté, comme un routeur, à deux ou plus réseaux différents, avec une interface dans chaque réseau, de telle sorte que le trafic vient "dans" un réseau et "sort" sur un réseau différent. Un exemple simple est montré ci-dessous :

                   +-----+
                   | UA1 |
                   +--+--+
                      | .66
       192.0.2.64/26  |
      ----------------+---+-...
                           |
                           | .65
                         +-+-+
                         | P |
                         +-+-+
                           | .129
                           |          192.0.2.128/26
                     ...---+------+------------------
                                  |
                                  | .130
                               +--+--+
                               | UA2 |
                               +--+--+

Figure 1 : Illustration de mandataire multi-rattachements

UA1 (agent d'utilisateur 1) a une interface avec l'adresse IP 192.0.2.66.

Le mandataire P a deux interfaces et deux adresses :
--192.0.2.65
--192.0.2.129

UA2 a une interface avec l'adresse 192.0.2.130. Il n'y a potentiellement pas de chemin de niveau IP entre UA1 et UA2 (un ping ou traceroute ne fonctionne pas entre ces deux hôtes). Ils vivent dans des sous réseux entièrement différents. Mais ils peuvent quand même échanger des messages SIP, parce que P est un mandataire SIP. Cela fonctionne dans SIP parce que P peut appliquer l'enregistrement de chemin (Record-Route).

Dans la plupart des cas, il y a quand même une certaine connexité IP entre UA1 et UA2, mais le mandataire SIP doit gérer le trafic SIP entre les deux différents "côtés", par exemple, avec deux adresses IP différentes, ou un côté qui utilise SIGCOMP et pas les autres, etc.

 	3.2	Problèmes identifiés
Le traitement de l'en-tête Record-Route dans les mandataires SIP est spécifié par les paragraphes suivants de la [RFC3261] :

Sur le côté qui traite la demande, le point 4 du paragraphe 16.6 de la [RFC3261] déclare que :

"L’URI placé dans la valeur de champ d’en-tête Record-Route DOIT être un URI SIP ou SIPS. [...] 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."

Suivant cette déclaration, on ne sait pas clairement comment décider quand le mandataire devrait insérer le paramètre de protocole de transport dans l'URI de Record-Route.

Sur le côté qui traite la réponse, la [RFC3261] recommande à l'étape 8 du paragraphe 16.7 que :

"Si la réponse choisie contient une valeur de champ d’en-tête Record-Route fournie à l’origine par ce mandataire, le mandataire PEUT choisir de réécrire la valeur avant de transmettre la réponse. Ceci permet au mandataire de fournir différents URI pour lui-même pour les prochains éléments amont et aval. Un mandataire peut choisir d’utiliser ce mécanisme pour n’importe quelle raison. Par exemple, il est utile pour les hôtes multi rattachements.

Si le mandataire a reçu la demande sur TLS, et l’a renvoyée sur une connexion non TLS, le mandataire DOIT réécrire l’URI dans le champ d’en-tête Record-Route pour que ce soit un URI SIPS."

Noter que la [RFC5630] a affaibli l'exigence de réécriture de l'URI SIP/SIPS dans l'en-tête Record-Route en supprimant ce second alinéa.

Bien sûr, la [RFC3261] suggère de réécrire l'en-tête Record-Route dans les réponses.

Cette liste souligne l'utilité des techniques de réécriture et de double Record-Route qui s'appliquent pour tout cas d'utilisation de mandataire multi rattachements : chaque fois que le mandataire change son adresse IP, le protocole de transport, ou le schéma d'URI entre les interfaces entrante et sortante. La réécriture et le double Record-Route sont décrites, comparées, et discutées dans les Sections 4 et 5 ; la question spécifique d'insérer ou non le paramètre de transport dans l'URI Record-Route est discutée à la Section 6.

 	4.	Réécriture de Record-Route

Comme fréquemment mentionné dans les discussions sur les listes de diffusion de l'IETF, la réécriture de Record-Route dans les réponses n'est pas la façon optimale de traiter les situations de multi-rattachements et de commutation de protocole de transport. De plus, la conséquence de la réécriture est que l'ensemble de chemins vu par l'appelant est différent de l'ensemble de chemins vu par l'appelé, et cela a au moins deux implications négatives :

1)	L'appelé ne peut pas signer l'ensemble de chemins, parce que il est édité par le mandataire dans la réponse. Par conséquent, la protection de bout en bout de l'ensemble de chemins ne peut pas être prise en charge par le protocole. Cela signifie que les principes d'ouverture et de connexité de bout en bout de l'Internet sont violés.

2)	Un mandataire doit mettre en œuvre une logique spéciale de "multi-rattaché". Durant la phase de transmission de la demande, il effectue un calcul d'interface de sortie et écrit les informations résolvant l'interface de sortie dans l'URI de l'en-tête Record-Route. Quand il traite les réponses, le mandataire doit inspecter le ou les en-têtes Record-Route, chercher une interface de sortie, et les éditer sélectivement pour faire référence à l'interface de sortie correcte. Comme cette recherche doit être faire pour toutes les réponses transmises par le mandataire, cette technique implique un ralentissement de l'unité centrale de contrôle.

Donc, le présent document recommande d'utiliser l'approche du double Record-Route pour éviter de réécrire le Record-Route. Cette recommandation s'applique à toutes les utilisations de réécriture de Record-Route par les mandataires, y compris de commutation de protocole de transport et de mandataires multi-rattachés.

 	5.	Double Record-Routing

Les sérieux inconvénients de la technique de réécriture expliquent pourquoi la solution de double Record-Route a par conséquent été recommandée dans les extensions SIP comme la [RFC3486] ou la [RFC3608].

Cette technique consiste à insérer avant tout en-tête Record-Route existant un en-tête Record-Route avec l'URI reflétant l'interface d'entrée, incluant les paramètres de schémas et/ou d'URI, et ensuite un en-tête Record-Route avec l'URI reflétant l'interface de sortie. Quand on traite la réponse, aucune modification du chemin enregistré n'est exigée. Ceci est complètement rétro compatible avec la [RFC3261]. D'une façon générale, la complexité de temps va être moindre dans le double Record-Route parce que, en traitant la réponse, le mandataire n'a pas à faire de réécriture (et donc, pas de recherche). De plus, le traitement des demandes et réponses dans le dialogue n'exige plus de traitement spécial.

Quand il fait un double Record-Route, le mandataire va devoir traiter la ou les demandes suivantes dans le dialogue comme une spirale, et par conséquent dédier des ressources pour maintenir les transactions exigées pour traiter la spirale. Ce qui est considéré comme étant une demande en spirale est expliqué à la Section 6 de la [RFC3261]. Afin d'éviter une spirale, le mandataire peut être intelligent et examiner un en-tête de chemin supplémentaire avant de déterminer si la demande va faire une spirale à travers lui. Si il le fait, il peut optimiser la seconde spirale à travers lui-même. Même si c'est une décision de mise en œuvre, c'est beaucoup plus efficace pour éviter les spirales. Donc, cela signifie qu'au paragraphe 16.4, "Traitement des informations de chemin" [RFC3261], les mises en œuvre peuvent choisir qu'un mandataire PEUT supprimer deux en-têtes de chemin au lieu d'un quand on utilise le double Record-Route.

L'exemple suivant est une extension de l'exemple donné dans la [RFC6157]. Il illustre un flux d'appels de base qui utilise un double Record-Route dans un mandataire multi-rattaché IPv4 à IPv6, et annote l'état de dialogue sur chaque agent d'utilisateur (UA). Dans cet exemple, le mandataire P1, responsable du domaine "biloxy.exemple.com", reçoit une demande provenant d'un client amont seulement IPv4. Il mandate cette demande à un serveur aval seulement IPv6. Le mandataire P1 fonctionne sur un hôte double pile ; sur l'interface IPv4, il a une adresse de 192.0.2.254. Sur l'interface IPv6, il est configuré avec une adresse de 2001:db8::1. Des en-têtes SIP obligatoires ont été omis pour faciliter la lecture.

       UA1            Mandataire "P1"            UA2
      (IPv4)            (IPv4/IPv6)             (IPv6)
        |                    |                    |
        |   F1 INVITE        |                    |
        |------------------->|      F2 INVITE     |
        |                    |------------------->|
        |    100 Trying      |                    |
        |<-------------------|                    |
        |                    |    F3 200 OK       |
        |    F4 200 OK       |<-------------------|
        |<-------------------|                    |
        |                    |                    |
        |       F5 ACK       |                    |
        |------------------->|       F6 ACK       |
        |                    |------------------->|
        |                    |                    |
        |                    |        F7 BYE      |
        |       F8 BYE       |<-------------------|
        |<-------------------|                    |

Figure 2 : Illustration de mandataire IPv4 à IPv6 multi-rattaché

F1 INVITE UA1 -> P1 (192.0.2.254:5060)
INVITE sip:bob@biloxi.exemple.com SIP/2.0
Route: <sip:192.0.2.254:5060;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>
Contact: <sip:alice@192.0.2.1>

F2 INVITE P1 (2001:db8::1) -> UA2
INVITE sip:bob@biloxi.exemple.com SIP/2.0
Record-Route: <sip:[2001:db8::1];lr>
Record-Route: <sip:192.0.2.254:5060;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>
Contact: <sip:alice@192.0.2.1>

État de dialogue à UA2 :
URI local = sip:bob@biloxi.exemple.com
URI distant = sip:alice@atlanta.exemple.com
Cible distante = sip:alice@192.0.2.1
Ensemble de chemins = sip:[2001:db8::1];lr
                                       sip:192.0.2.254:5060:lr

F3 200 OK UA2 -> P1 (2001:db8::1)
SIP/2.0 200 OK
Record-Route: <sip:[2001:db8::1];lr>
Record-Route: <sip:192.0.2.254:5060;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567
Contact: <sip:bob@[2001:db8::33]>

F4 200 OK P1 -> UA1
SIP/2.0 200 OK
Record-Route: <sip:[2001:db8::1];lr>
Record-Route: <sip:192.0.2.254:5060;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567
Contact: <sip:bob@[2001:db8::33]>

État de dialogue à UA1 :
URI local = sip:alice@atlanta.exemple.com
URI distant = sip:bob@biloxi.exemple.com
Cible distante = sip:bob@[2001:db8::33]
Ensemble de chemins = sip:192.0.2.254:5060:lr
                                        sip:[2001:db8::1];lr

F5 ACK UA1 -> P1 (192.0.2.254:5060)
ACK sip:bob@[2001:db8::33] SIP/2.0
Route: <sip:192.0.2.254:5060:lr>
Route: <sip:[2001:db8::1];lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567

F6 ACK P1 (2001:db8::1) -> UA2
ACK sip:bob@[2001:db8::33] SIP/2.0
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567
(les deux en-têtes Route ont été supprimés par le mandataire)

F7 BYE UA2 -> P1 (2001:db8::1)
BYE sip:alice@192.0.2.1 SIP/2.0
Route: <sip:[2001:db8::1];lr>
Route: <sip:192.0.2.254:5060:lr>
From: Bob <sip:bob@biloxi.exemple.com>;tag=4567
To: Alice <sip:alice@atlanta.exemple.com>;tag=1234

F8 BYE P1 (192.0.2.254:5060) -> UA1
BYE sip:alice@192.0.2.1 SIP/2.0
From: Bob <sip:bob@biloxi.exemple.com>;tag=4567
To: Alice <sip:alice@atlanta.exemple.com>;tag=1234

Figure 3 : Illustration de double Record-Route IPv4 à IPv6 multi-rattaché

 	6.	Usage du paramètre Protocole de transport

Cette section décrit un ensemble de problèmes en relation avec l'usage des paramètres d'URI de protocole de transport dans l'en-tête Record-Route. Dans certaines circonstances, des problèmes d'interopérabilité se produisent parce que il n'est pas clair si il faut ou non inclure le paramètre de transport dans l'URI de l'en-tête Record-Route. Cela a été identifié comme un problème fréquent dans les événements SIPit passés.

L'étape 8 du paragraphe 16.7 de la [RFC3261] dit :

"L'URI NE DEVRAIT PAS contenir le paramètre de transport sauf si le mandataire a connaissance (comme dans un réseau privé) que le prochain élément en aval qui va être dans le chemin des demandes suivantes prend en charge ce transport."

Cela semble ajouter à la confusion de ceux qui doivent le mettre en œuvre, avec pour  résultat que les mandataires insèrent un seul Record-Route sans paramètre d'URI de transport, d'où les problèmes décrits dans cette section.

 	6.1	Problèmes et recommandations de mise en œuvre à l'UA
Considérons le scénario suivant : un mandataire SIP, fait la commutation de protocole de transport de TCP à UDP.

Dans cet exemple, le mandataire P1, responsable du domaine biloxy.exemple.com, reçoit une demande provenant de l'UA1 d'Alice, qui utilise TCP. Elle mandate cette demande à l'UA2 de Bob, qui s'est enregistré avec un contact spécifiant UDP comme protocole de transport. Donc, P1 reçoit une demande initiale provenant d'Alice sur TCP et la transmet à Bob sur UDP. Pour les demandes suivantes, on suppose que TCP pourrait continuer d'être utilisé entre Alice et P1, et UDP entre P1 et Bob, mais cela peut ne pas arriver si une adresse IP numérique est utilisée et qu'aucun paramètre de transport n'est établi sur l'URI Record-Route. Cela arrive à cause des procédures décrites dans la [RFC3263].

Des en-têtes SIP obligatoires ont été omis pour faciliter la lecture.

     UA1 d'Alice === TCP === Mandataire P1 === UDP === UA2 de Bob
         |                        |                         |
         |       F1 INVITE        |                         |
         |----------------------->|         F2 INVITE       |
         |                        |------------------------>|
         |      100 Trying        |                         |
         |<-----------------------|                         |
         |                        |        F3 200 OK        |
         |       F4 200 OK        |<------------------------|
         |<-----------------------|                         |
         |                        |                         |
         |        F5 ACK          |                         |
         |--(envoyé sur UDP) X--->|            ACK          |
         |                        |------------------------>|
         |                        |                         |
         |                        |          F6 BYE         |
         |          BYE           |<------------------------|
         |<-----------------------|                         |

Figure 4 : Illustration d'une commutation de protocole de transport de TCP à UDP

F1 INVITE UA1 -> P1 (192.0.2.1/tcp)
INVITE sip:bob@biloxi.exemple.com SIP/2.0
Route: <sip:192.0.2.1;lr;transport=tcp>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>
Contact: <sip:alice@ua1.atlanta.exemple.com;transport=tcp>

F2 INVITE P1 -> UA2 (ua2.biloxi.exemple.com/udp)
INVITE sip:bob@ua2.biloxi.exemple.com;transport=udp SIP/2.0
Record-Route: <sip:192.0.2.1;lr> (NO transport param)
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>
Contact: <sip:alice@ua1.atlanta.exemple.com;transport=tcp>

État de dialogue à UA2 :
URI local = sip:bob@biloxi.exemple.com
URI distant = sip:alice@atlanta.exemple.com
Cible distante = sip:alice@ua1.atlanta.exemple.com;transport=tcp
Ensemble de chemins = sip:192.0.2.1;lr

F3 200 OK UA2 -> P1 (192.0.2.1/udp)
SIP/2.0 200 OK
Record-Route: <sip:192.0.2.1;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567
Contact: <sip:bob@ua2.biloxi.exemple.com>

F4 200 OK P1 -> UA1 (ua1.atlanta.exemple.com/tcp)
SIP/2.0 200 OK
Record-Route: <sip:192.0.2.1;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567
Contact: <sip:bob@ua2.biloxi.exemple.com>

État de dialogue à UA1 :
URI local = sip:alice@atlanta.exemple.com
URI distant = sip:bob@biloxi.exemple.com
Cible distante = sip:bob@ua2.biloxi.exemple.com
Ensemble de chemins = sip:192.0.2.1;lr

F5 ACK UA1 -> P1 (192.0.2.1/udp)
ACK sip:bob@ua2.biloxi.exemple.com SIP/2.0
Route: <sip:192.0.2.1;lr>
From: Alice <sip:alice@atlanta.exemple.com>;tag=1234
To: Bob <sip:bob@biloxi.exemple.com>;tag=4567

F6 BYE UA2 -> P1 (192.0.2.1/udp)
BYE sip:alice@ua1.atlanta.exemple.com;transport=tcp SIP/2.0
Route: <sip:192.0.2.1;lr>
From: Bob <sip:bob@biloxi.exemple.com>;tag=4567
To: Alice <sip:alice@atlanta.exemple.com>;tag=1234

Figure 5 : Description d'une commutation de protocole de transport de TCP à UDP

Comme le mandataire P1 n'insère aucun paramètre de transport dans l'URI Record-Route, les demandes suivantes dans le dialogue de UA1, comme le ACK envoyé en F5, vont être envoyées conformément au comportement spécifié au paragraphe 12.2 (demandes au sein d'un dialogue) de la [RFC3261]. Cela signifie que l'ensemble de chemins est utilisé, et ensuite, en appliquant la [RFC3263], le chemin "sip:192.0.2.1" va se résoudre en un transport UDP par défaut (car aucun paramètre de transport n'est présent ici) et aucune demande de pointeur d'autorité de dénomination (NAPTR, Naming Authority Pointer) ne va être effectuée car c'est une adresse IP numérique.

En général, les problèmes d'interopérabilité surviennent quand UA1 essaye d'envoyer le ACK : il n'est pas prêt à changer son protocole de transport pour une demande de mi-dialogue et ne le fait tout simplement pas, exigeant que la mise en œuvre de mandataire insère le protocole de transport dans l'URI Record-Route.

Que se passe t-il si le mandataire a enregistré le chemin de son nom logique (biloxi.exemple.com) ? Comme Bob va être contacté sur UDP, la commutation de protocole ne va être évitée que si le protocole de transport résultant des procédures de la [RFC3263] est UDP. Pour tous les autres protocoles de transport résultants, le problème de commutation de protocole de transport décrit ci-dessus va se produire. Aussi, si un des UA envoie une demande initiale en utilisant un transport différent de celui restitué du DNS, ce scénario va poser des problèmes.

En pratique, il y a plusieurs situations où les mises en œuvre d'UA n'utilisent pas les noms logiques et les enregistrements de NAPTR quand ils envoient une demande initiale à un mandataire. Cela arrive, par exemple, quand :

1)	Les UA offrent la capacité de "choisir" le transport à utiliser pour les demandes initiales, même si ils prennent en charge la [RFC3263]. C'est une fonctionnalité fréquente d'UA qui est justifiée par les cas d'utilisation suivants :
-	Quand il n'est pas possible de changer la configuration du serveur DNS et que la mise en œuvre ne prend pas en charge tous les protocoles de transport qui pourraient être configurés par défaut dans le DNS (par exemple, TLS).
-	Quand l'utilisateur d'extrémité veut choisir son protocole de transport pour une raison quelconque, par exemple, forcer TCP, éviter UDP ou l'encombrement, la retransmission, ou la fragmentation, etc.

Cette capacité de forcer le protocole de transport dans les UA pour les demandes initiales DEVRAIT être évitée : le choix du protocole de transport dans la configuration d'un mandataire sortant signifie que la procédure de la [RFC3263] est outrepassée pour les demandes initiales. Par conséquent, si le mandataire enregistre le chemin sans paramètre de transport comme c'est recommandé dans la [RFC3261], l'UA va de toutes façons être forcé d'utiliser le transport préféré de la [RFC3263] pour les demandes suivantes, ce qui nous amène au scénario problématique décrit à la Figure 4.

2)	Les UA décident de toujours conserver le même transport pour un dialogue donné. Ce choix est erratique, car si le mandataire est n'enregistre pas le chemin, l'appelé PEUT recevoir la demande suivante par un transport qui n'est pas celui mis dans son champ Contact. Si un UA veut réellement éviter la commutation de protocole de transport entre la demande initiale et les suivantes, il DEVRAIT s'appuyer sur les enregistrements du DNS pour cela ; donc, il DEVRAIT éviter de configurer statiquement le mandataire sortant avec une adresse IP numérique. Un nom logique, sans paramètre de transport, DEVRAIT être utilisé à la place.

3)	Les UA ne prennent pas du tout en charge la [RFC3263], ou n'ont pas de serveur DNS disponible. Dans ce cas, comme illustré précédemment, forcer UA1 à commuter de TCP à UDP entre la demande initiale et les suivantes est clairement le comportement non désiré par défaut, et il conduit normalement à des problèmes d'interopérabilité. Les mises en œuvre d'UA DEVRAIENT alors être prêtes à changer de protocole de transport entre la demande initiale et les suivantes. En théorie, tout UA ou mandataire utilisant UDP doit aussi être prêt à utiliser TCP pour les demandes qui excèdent la limite de taille de la MTU de chemin, comme décrit au paragraphe 18.1.1 de la [RFC3261].

 	6.2	Problèmes et recommandations de mise en œuvre chez le mandataire
Afin de prévenir des problèmes de mise en œuvre de l'UA, et maintenir un niveau raisonnable d'interopérabilité, la situation peut être améliorée du côté du mandataire. Donc, si le protocole de transport a changé entre ses côtés entrant et sortant, le mandataire DEVRAIT utiliser la technique du double Record-Route et DEVRAIT ajouter un paramètre de transport à chaque URI de Record-Route qu'il insère. Quand TLS est utilisé sur le transport de l'un ou l'autre côté du mandataire, l'URI placé dans le champ d'en-tête Record-Route DOIT coder un prochain bond qui va être atteint en utilisant TLS. Il y a deux façons de faire fonctionner cela. La première est que l'URI placé dans le Record-Route soit un URI SIPS. La seconde est que l'URI placé dans le Record-Route soit construit de telle façon que l'application des procédures de résolution de la [RFC3263] à cet URI résulte en le choix de TLS. Les mandataires conformes à la présente spécification NE DOIVENT PAS utiliser un paramètre "transport=tls" sur l'URI placé dans le Record-Route parce que l'usage de "transport=tls" a été déconseillé par la [RFC3261]. La réécriture de Record-Route PEUT aussi être utilisée. Cependant, la recommandation de mettre un paramètre de protocole de transport sur l'URI de Record-Route ne s'applique pas quand le mandataire a changé de protocole de transport à cause de la taille des demandes UDP conformément au paragraphe 18.1.1 de la [RFC3261]. Pour illustrer l'exemple précédent, cela signifie qu'un des traitements suivants va être effectué :

-	Double enregistrement de chemin : le mandataire insère deux en-têtes Record-Route dans la demande SIP. La première est réglée, dans cet exemple, à Record-Route : <sip:192.0.2.1;lr;transport=tcp>, la seconde est réglée à Record-Route : <sip:192.0.2.1;lr> sans transport, ou avec transport=udp, qui signifie fondamentalement la même chose.

-	Réécriture de Record-Route dans les réponses : dans la demande INVITE envoyée en F2, le mandataire met le protocole de transport sortant dans le paramètre de transport de l'URI Record-Route. Ce faisant, UA2 va envoyer correctement sa demande BYE dans F6 en utilisant le même protocole de transport que pour les messages précédents du même dialogue. Le mandataire réécrit le Record-Route quand il traite la réponse 200 OK, changeant le paramètre de transport "au vol" en "transport=tcp", afin que l'ensemble de chemins apparaisse comme étant <sip:192.0.2.1;lr;transport=tcp> pour UA1 et <sip:192.0.2.1;lr;transport=udp> pour UA2.

Il est de pratique courante dans les mises en œuvre de mandataire de prendre en charge le double Record-Route ET d'insérer le paramètre de transport dans l'URI Record-Route. Cette pratique est acceptable tant que tous les éléments SIP qui peuvent être dans le chemin des demandes suivantes prennent en charge ce transport. Cette restriction mérite une explication. Imaginons qu'on ait deux mandataires, P1 à "p1.biloxi.exemple.com" et P2 sur le chemin d'une demande initiale. P1 enregistre le chemin et change le transport de UDP en le protocole de transmission de commandes de flux (SCTP, Stream Control Transmission Protocol) parce que l'URI de P2 se résout en SCTP en application de la [RFC3263]. Par conséquent, le mandataire P1 insère deux en-têtes Record-Route :
Record-Route : <sip:p1.biloxi.exemple.com;transport=udp> et
Record-Route : <sip:p1.biloxi.exemple.com;transport=sctp>.

Un problème se pose si P2 n'enregistre pas le chemin, parce que il va être demandé à l'élément SIP en aval de P2 d'atteindre P1 en utilisant SCTP pour toute demande dans le dialogue suivant provenant de l'appelé, et cet élément SIP en aval peut ne pas prendre en charge ce transport.

Afin de traiter cette situation, le présent document recommande qu'un mandataire DEVRAIT appliquer la technique du double Record-Route aussitôt qu'il change le protocole de transport entre ses côtés entrant et sortant. Si le mandataire P2 dans l'exemple ci-dessus suit cette recommandation, il effectuera un double Record-Route et l'élément en aval ne sera pas forcé d'envoyer les demandes sur un transport qu'il ne prend pas en charge.

Par extension, un mandataire DEVRAIT aussi insérer un en-tête Record-Route pour toute situation de multi-rattaché (comme celles décrites dans le présent document : changements de schéma, sigcomp, IPv4/IPv6, changements de transport, etc.) cela peut impacter le traitement de mandataires qui se trouvent sur le chemin des demandes suivantes.

 	7.	Conclusion

En conclusion ode ce document, il est à noter que :

-	La réécriture de Record-Route est présentée comme une technique qui PEUT être utilisée, avec les inconvénients soulignés à la Section 4.

-	Le double Record-Route est présenté comme la technique qui DEVRAIT être utilisée, et est documenté à la Section 5.

-	Les problèmes d'interopérabilité d'en-tête Record-Route sur les scénarios de commutation de protocole de transport ont été soulignés et décrits à la Section 6. Cette dernière section donne des recommandations pour les mises en œuvre d'UA et de mandataire pour améliorer la situation. Les mandataires DEVRAIENT utiliser le double Record-Route pour toute situation de multi-rattaché qui PEUT impacter la suite du traitement , et ils DEVRAIENT mettre les paramètres de protocole de transport sur les URI de Record-Route dans certaines circonstances. Les UA NE DEVRAIENT PAS offrir l'option d'outrepasser  le transport pour les demandes initiales. De plus, les UA DEVRAIENT s'appuyer sur le DNS pour exprimer le transport désiré et DEVRAIENT dans ce cas éviter des adresses IP avec des paramètres de transport. Finalement, les UA DEVRAIENT être prêts à commuter les transports entre la demande initiale et les messages suivants dans le dialogue.

 	8.	Considérations sur la sécurité

Les recommandations de ce document décrivent une façon d'utiliser le protocole existant spécifié dans la RFC 3261 plutôt que d'introduire un nouveau mécanisme de protocole. À ce titre, elles n'introduisent aucun nouveau problème de sécurité, mais des considérations supplémentaires sur des problèmes déjà existants sont à prendre en compte. En particulier, quand un message transite entre deux interfaces, la technique du double enregistrement de chemin va porter des informations sur les deux interfaces de chaque point d'extrémité impliqué (et tous les intermédiaires entre ce mandataire et ces points d'extrémité) où la technique de réécriture va seulement exposer les informations sur l'interface la plus proche de chacun des points d'extrémité. Si des problèmes comme la dissimulation de la topologie ou de confidentialité (comme décrit dans la [RFC3323]) sont en cause, les valeurs d'URI placées dans l'enregistrement de chemin pour chaque interface devraient être construites avec soin pour éviter d'exposer plus d'informations que ce qui est voulu.

 	9.	Remerciements

Merci à Dean Willis, Vijay K. Gurbani, Joel Repiquet, Robert Sparks, Jonathan Rosenberg, Cullen Jennings, Juha Heinanen, Paul Kyzivat, Nils Ohlmeier, Tim Polk, Francois Audet, Adrian Farrel, Ralph Droms, Tom Batsele, Yannick Bourget, Keith Drage, et John Elwell pour leur relecture et leurs commentaires.

 	10.	Références
 	10.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3263]	J. Rosenberg, H. Schulzrinne, "Protocole d'initialisation de session (SIP) : Localisation des serveurs SIP", juin 2002. (Remplace RFC2543) (P.S. ; MàJ par RFC7984, RFC8898)

[RFC3323]	J. Peterson, "Mécanisme de confidentialité pour le protocole d'initialisation de session (SIP)", novembre 2002.

[RFC5630]	F. Audet, "Utilisation du schéma d'URI SIPS dans le protocole d'initialisation de session (SIP)", octobre 2009. (MàJ RFC3261, RFC3608) (P. S.)

 	10.2	Références pour information

[BUG664]	Sparks, RS., "Bug 664: Double record routing", http://bugs.sipit.net/show_bug.cgi?id=664, octobre 2002.

[RFC3486]	G. Camarillo, "Compression du protocole d'initialisation de session (SIP)", février 2003. (MàJ par RFC5049) (P.S.)

[RFC3608]	D. Willis, B. Hoeneisen, "Champ d'en-tête d'extension du protocole d'initialisation de session (SIP) pour la découverte de chemin de service durant l'enregistrement", octobre 2003. (P.S.)

[RFC6157]	G. Camarillo, K. El Malki, V. Gurbani, "Transition à IPv6 dans le protocole d’initialisation de session (SIP)", avril 2011. (MàJ la RFC3264) (P.S.)

 	Adresse des auteurs

Thomas Froment	Christophe Lebel	Ben Bonnaerens	
Tech-invite	Alcatel-Lucent	Alcatel-Lucent	
mél : thomas.froment@tech-invite.com	mél : christophe.lebel@alcatel-lucent.com	mél : ben.bonnaerens@alcatel-lucent.com