Groupe de travail Réseau	V. Gurbani, Bell Laboratories, Alcatel-Lucent	
Request for Comments : 4904	C. Jennings, Cisco Systems	
Catégorie : Sur la voie de la normalisation	juin 2007	
Traduction Claude Brière de L'Isle		

Représentation des groupes de jonctions dans les identifiants de ressource universels tel/sip

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 copyright
Copyright (C) The Internet Society (2007). Tous droits réservés.

Résumé
Le présent document décrit un mécanisme normalisé pour porter des paramètres de groupe de jonctions dans les identifiants de ressource universels (URI, Uniform Resource Identifier) sip et tel. Une extension à l'URI tel est définie à cette fin.
Table des matières
1. Fondements	1
2. Position du problème	2
3. Conventions	3
4. Exigences et raisons	3
4.1 URI sip ou URI tel ?	3
4.2 Espace de noms de groupe de jonctions : global ou local ?	3
4.3 Groupe de jonctions d'origine et de terminaison	3
4.4 Traitement intermédiaire de groupes de jonctions	4
5. Identifiant de groupe de jonctions : ABNF et exemples	4
6. Comportement normatif des entités SIP qui utilisent des groupes de jonctions	5
6.1 Comportement du client d'agent d'utilisateur	5
6.2 Comportement du serveur d'agent d'utilisateur	6
6.3 Comportement de mandataire	6
7. Exemple de flux d'appels	6
7.1 Architecture de référence	6
7.2 Flux d'appels de base	7
7.3 Flux d'appels inter domaines	8
8. Considérations sur la sécurité	9
9. Considérations relatives à l'IANA	10
10. Remerciements	10
11. Références	10
11.1 Références normatives	10
11.2 Références pour information	10
Adresse des auteurs	10
Déclaration complète de droits de reproduction	11

 	1.	Fondements

L'acheminement d'appel dans le réseau téléphonique public commuté (RTPC) est réalisé par l'acheminement des appels sur des circuits spécifiques (couramment appelés des "jonctions") entre des commutateurs de circuits à multiplexage à répartition dans le temps (MRT). Dans les commutateurs, un groupe de jonctions qui connectent le même commutateur ou réseau cible est appelé un "groupe de jonctions". Par conséquent, les groupes de jonctions ont des étiquettes, qui sont utilisées comme principale indication pour le commutateur MRT précédent et suivant qui participent à l'acheminement de l'appel.

Formellement, on définit une jonction et un groupe de jonctions et la terminologie qui s'y rapporte comme suit (la définition de "jonction" et "groupe de jonctions " est tirée de [Telcordia]).

Jonction : dans un réseau, un chemin de communication connectant deux systèmes de commutation utilisés dans l'établissement d'une connexion de bout en bout. Dans certaines applications, les deux terminaisons peuvent être dans le même système de commutation.

groupe de jonctions : ensemble de jonctions, dont l'ingénierie du trafic est unitaire, pour l'établissement de connexions au sein ou entre des systèmes de commutation dans lesquels tous les chemins sont interchangeables. Un seul groupe de jonctions peut être partagé sur plusieurs commutateurs pour des besoins de redondance.

Signal numérique 0 (DS0, Digital Signal 0) : signal numérique X est un terme pour une série de taux de transmission numérique standard fondés sur DS0, un taux de transmission de 64 kbit/s (bande passante normalement utilisée pour un canal vocal téléphonique). Le système de transmission européen "E-carrier" opère aussi avec la série DS comme multiple de base.

Depuis l'introduction universelle des jonctions numériques, qui a résulté en l'allocation des DS0 entre les centraux d'extrémité en groupes minimum de 24 (en Amérique du Nord) il est devenu courant de se référer aux faisceaux de DS0 comme à des jonctions. Strictement parlant, une jonction est un seul DS0 entre deux centraux d'extrémité du RTPC ; cependant, pour les besoins du présent document, l'interface RTPC d'une passerelle agit effectivement comme un central d'extrémité (c'est-à-dire, si la passerelle fait l'interface avec le système de signalisation n° 7 (SS7, Signaling System 7) qui a son propre codet SS7, et ainsi de suite). Un groupe de jonctions est alors un faisceau de DS0 (qui n'ont pas besoin d'être numériquement contigus dans un schéma numérique de code d'identification de circuit de jonction SS7) qui sont groupés sous une politique administrative commune pour l'acheminement.

Une passerelle du protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC3261] au RTPC peut avoir des jonctions qui sont connectées à des transporteurs différents. Il est entièrement raisonnable qu'un mandataire SIP choisisse -- sur la base de facteurs qui ne sont pas énumérés dans le présent document -- à quel transporteur est envoyé un appel quand il relaye une demande d'établissement de session à la passerelle. Comme plusieurs transporteurs peuvent porter un appel à un numéro de téléphone particulier, le numéro de téléphone lui-même n'est pas suffisant pour identifier le transporteur à la passerelle. Un élément d'information supplémentaire sous la forme d'un groupe de jonctions peut être utilisé pour réduire les choix à la passerelle. Comme elles sont utilisées dans le présent document, les jonctions sont nécessairement liées aux passerelles, et un mandataire qui utilise des groupes de jonctions durant l'acheminement de la demande à une passerelle particulière sait et contrôle à quelle passerelle l'appel va être acheminé, et sait quelles ressources de jonctions sont présentes sur cette passerelle.

Pour un autre exemple, considérons le cas où un réseau IP est utilisé comme réseau de transit entre deux RTPC. Ici, un mandataire SIP peut appliquer le groupe de jonctions d'origine à sa logique d'acheminement pour s'assurer que le même transporteur d'entrée et de sortie est choisi.

Il sort du domaine d'application du présent document de décrire comment le mandataire choisit un groupe de jonctions particulier. (La [RFC5140] explique cela) ; cependant, une fois qu'un groupe de jonctions a été décidé, le présent document donne un moyen normalisé de le représenter dans les messages de signalisation.

 	2.	Position du problème

Actuellement, il n'y a aucun moyen normalisé de transporter des groupes de jonctions entre de entités de signalisation Internet. Cela conduit à des ambiguïté au moins sur deux fronts :

1. Ambiguïté de position : un mandataire SIP qui veut envoyer un appel à une passerelle de voix sur IP (VoIP, Voice over IP) de sortie peut insérer le groupe de jonctions comme paramètre dans la portion utilisateur de l'URI de demande (R-URI, Request-URI) ou il peut l'insérer comme paramètre du R-URI lui-même. Cette ambiguïté persiste dans la direction inverse aussi, c'est-à-dire, quand une passerelle VoIP de sortie veut envoyer une notification d'appel entrante à son mandataire de sortie par défaut.

2. Ambiguïté sémantique : l'absence de toute grammaire normalisée pour représenter les groupes de jonctions conduit au choix malencontreux de noms et valeurs ad hoc.

Les entités d'acheminement VoIP dans l'Internet, comme les mandataires SIP, peuvent être intéressées à utiliser des groupes de jonctions pour les opérations normales. Dans cette mesure, toutes les exigences fondées sur des normes vont permettre aux mandataires d'un fabricant d'interopérer avec les passerelles d'un autre fabricant. En l'absence de telles lignes directrices, l'interopérabilité va souffrir, car un fabricant de mandataire doit se conformer aux attentes d'une passerelle quand il s'attend à ce que des paramètres de groupe de jonctions soient présents (et vice versa).

Le but de la présente spécification est de preciser comment structurer et représenter les paramètres de groupe de jonctions comme une extension à l'URI tel [RFC3966] d'une manière standardisée.

 	3.	Conventions

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].

 	4.	Exigences et raisons

Cette Section décrit les motivations des décisions de conception de la spécification d'un groupe de jonctions. Ces motivations sont décrites comme un ensemble d'exigences qui sont utilisées pour guider la spécification éventuelle d'un groupe de jonctions dans le présent document.

 	4.1	URI sip ou URI tel ?
Recommandation 1: les paramètres de groupe de jonctions doivent être définis comme une extension à l'URI tel [RFC3966].

Les paramètres de groupe de jonctions peuvent être portés dans l'URI sip ou dans l'URI tel. Comme les groupes de jonctions sont intimement associés au RTPC, il semble raisonnable de les définir comme des extensions à l'URI tel (toute demande SIP qui va à une passerelle pourrait raisonnablement être supposée avoir un URI tel, en tout ou en partie, dans sa R-URI de toute façon). De plus, utiliser l'URI tel permet aussi que ce format soit réutilisé par des protocoles VoIP non SIP (qui pourraient inclure MGCP ou Megaco et H.323, si les éléments d'information appropriés sont créés).

Finalement, une fois le groupe de jonctions défini pour un URI tel, les procédures normatives du paragraphe 19.1.6 de la [RFC3261] peuvent être utilisées pour déduire un URI sip équivalent d'un URI tel, complété avec les paramètres de groupe de jonctions.

 	4.2	Espace de noms de groupe de jonctions : global ou local ?
Recommandation 2 : les collisions de nom de groupe de jonctions inter domaines doivent être empêchées.

En fonctionnement normal, les groupes de jonctions ne sont pertinents que dans un domaine administratif (c'est-à-dire, de portée locale). Cependant, étant donné que des collisions de nom de groupe de jonctions peuvent survenir par inadvertance en traversant des limites de domaine, il est souhaitable de les empêcher. Une utilisation judicieuse des espaces de noms est une solution à ce problème. Donc, il semble approprié de limiter la portée du groupe de jonctions à travers un espace de noms.

Note : à première vue, il apparaîtrait que l'utilisation du paramètre "téléphone-contexte" de l'URI tel donne un moyen satisfaisant d'imposer un espace de noms à un groupe de jonctions. Le paramètre "téléphone-contexte" identifie la portée de validité d'un numéro de téléphone local. Et c'est là que réside le problème. Sémantiquement, un paramètre d'URI tel "téléphone-contexte" n'est applicable qu'à un numéro de téléphone local et non à un numéro mondial (c'est-à-dire, un qui est précédé d'un '+'). Les groupes de jonctions, par ailleurs, peuvent apparaître dans des numéros de téléphone locaux ou mondiaux. Donc, ce qui est nécessaire est un nouveau paramètre avec une fonction équivalente du paramètre "téléphone-contexte" de l'URI tel, mais qui soit également applicable aux numéros de téléphone locaux et mondiaux.

 	4.3	Groupe de jonctions d'origine et de terminaison
Recommandation 3 : les groupes de jonctions d'origine et de destination doivent être capables d'apparaître séparément et concurremment dans un message SIP.

Les entités d'acheminement SIP peuvent prendre des décisions d'acheminement informées sur la base des groupes de jonctions d'origine ou de terminaison. Donc, il est exigé que ces deux groupes de jonctions soient portés dans les demandes SIP.

 	4.4	Traitement intermédiaire de groupes de jonctions
Recommandation 4 : les intermédiaires de  réseau SIP (serveurs mandataires et serveurs de redirection) devraient être capables d'ajouter l'attribut Groupe de jonctions de destination aux sessions SIP lorsque un chemin est choisi pour un appel.

 	5.	Identifiant de groupe de jonctions : ABNF et exemples

La syntaxe de forme Backus Naur augmenté [RFC4234] pour un identifiant de groupe de jonctions est donnée ci-dessous et étend la règle de production "par" de l'URI tel définie dans la [RFC3966] :

par = paramètre / extension /sous-adresse-rnis / groupe-de-jonctions / contexte-de-jonctions
groupe-de-jonctions = ";tgrp=" étiquette-de-groupe-de-jonctions
contexte-de-jonction = ";contexte-de-jonction=" descripteur
étiquette-de-groupe-de-jonctions = 1*( nonréservé / échappé / groupe-de-jonctions-nonréservé )
groupe-de-jonctions-nonréservé = "/" / "&" / "+" / "$"

descripteur est défini dans la [RFC3966].
nonréservé est défini dans la [RFC3261] et la [RFC3966].
échappé est défini dans la [RFC3261].

Les groupes de jonctions sont identifiés par deux paramètres : "tgrp" et "contexte-de-jonctions" ; les deux paramètres DOIVENT être présents dans un URI tel pour identifier un groupe de jonctions. Collectivement, ces deux paramètres sont appelés "paramètres de groupe de jonctions" dans la présente spécification.

Toutes les mises en œuvre conformes à la présente spécification DOIVENT générer ces deux paramètres quand elles utilisent des groupes de jonctions. Si une mise en œuvre reçoit un URI tel avec seulement un des paramètres "tgrp" ou "contexte-de-jonctions", il DOIT agir comme si aucun paramètre Groupe de jonctions n'était présent dans cet URI. Continuer ou non le traitement d'un tel URI est à la discrétion de la mise en œuvre ; cependant, si la décision est prise de le traiter, la mise en œuvre DOIT agir comme si il n'y avait aucun paramètre Groupe de jonctions présent dans l'URI.

Le paramètre "contexte-de-jonctions" impose un espace de noms au groupe de jonctions en spécifiant un numéro mondial ou tout nombre de ses chiffres de tête (par exemple, +33) ou un nom de domaine. Syntaxiquement, il est modélisé d'après le paramètre "téléphone-contexte" de l'URI tel [RFC3966], sauf qu'à la différence du paramètre "téléphone-contexte", le paramètre "contexte-de-jonctions" peut apparapitre dans un URI tel local ou mondial.

Sémantiquement, le paramètre "contexte-de-jonctions" établit une portée du groupe de jonctions spécifié dans le paramètre "tgrp", c'est-à-dire, si il est valide à une seule passerelle, un ensemble de passerelles, ou un domaine entier géré par un fournisseur de services. Le "contexte-de-jonctions" peut contenir quatre types de valeurs discrètes :

1.  La valeur dans le "contexte-de-jonctions" identifie littéralement un hôte (une passerelle) et dans ce cas, les groupes de jonctions sont de portée limitée à l'hôte spécifié.

2.  La valeur dans le "contexte-de-jonctions" est un sous domaine (par exemple, "nord.exemple.com") qui identifie un sous ensemble des passerelles dans un domaine à travers lequel les groupes de jonctions sont partagés.

3.  La valeur dans le "contexte-de-jonctions" est un domaine d'un fournisseur de services (par exemple, "exemple.com"), qui identifie toutes les passerelles dans le domaine spécifié.

4.  La valeur dans le "contexte-de-jonctions" est un numéro mondial ou tout nombre de ses chiffres de tête ; ceci est utile pour une portée au niveau du fournisseur et ne se prête pas bien lui-même à spécifier des groupes de jonctions à travers une passerelle ou un ensmble de passerelles.

Pour les besoins d'équivalence, deux URI contenant des paramètres groupe-de-jonctions sont équivalents en accord avec les règles de comparaison de base des URI. Les règles de base de comparaison d'un URI tel sont spécifiées à la Section 4 de la [RFC3966], et les règles de base de comparaison d'un URI sip sont spécifiées au paragraphe 19.1.4 de la [RFC3261].

Exemples :

1. Groupe de jonctions dans un numéro local, avec un paramètre téléphone-contexte :
tel:5550100;téléphone-contexte=+1-630;tgrp=TG-1;contexte-de-jonctions=exemple.com

Transformer cet URI tel en un URI sip donne :
sip:5550100;téléphone-contexte t=+1-630;tgrp=TG-1;contexte-de-jonctions=exemple.com@isp.exemple.net;user=phone

2. Groupe de jonctions dans un numéro mondial, avec un contexte-de-jonctions nom de domaine :
tel:+16305550100;tgrp=TG-1;contexte-de-jonctions=exemple.com

Transformer cet URI tel en un URI sip donne :
sip:+16305550100;tgrp=TG-1;contexte-de-jonctions=exemple.com@isp.exemple.net;user=phone

3. Groupe de jonctions dans un numéro mondial, avec un contexte-de-jonctions préfixe de numéro :
tel:+16305550100;tgrp=TG-1;contexte-de-jonctions=+1-630

Transformer cet URI tel en un URI sip donne :
sip:+16305550100;tgrp=TG-1;contexte-de-jonctions=+1-630@isp.exemple.net;user=phone

 	6.	Comportement normatif des entités SIP qui utilisent des groupes de jonctions

Les paramètres de groupe de jonctions de terminaison (ou d'entrée) DOIVENT être spécifiés dans l'URI de demande. C'est une indication provenant d'une entité SIP à la prochaine entité vers l'aval qu'un groupe de jonctions spécifique de terminaison (ou de sortie) devrait être utilisé.

Note : ceci est cohérent avec l'utilisation du R-URI comme élément d'acheminement ; les entités d'acheminement SIP peuvent utiliser le paramètre Groupe de jonctions dans l'URI de demande pour prendre des décisions d'acheminement intelligentes. De plus, cela satisfait aussi la Recommandation 4, car un intermédiaire de réseau SIP peut modifier le R-URI pour inclure des paramètres Groupe de jonctions.

À l'inverse, l'apparition des paramètres Groupe de jonctions dans l'en-tête URI Contact signifie le groupe de jonctions sur lequel d'appel est arrivé, c'est-à-dire, le groupe de jonctions d'origine (ou d'entrée). Donc, le groupe de jonctions d'origine (ou d'entrée) DOIT apparaître dans l'en-tête Contact d'une demande SIP.

Le comportement décrit dans cette section vise effectivement la recommandation 3.

 	6.1	Comportement du client d'agent d'utilisateur
Un client d'agent d'utilisateur (UAC, User Agent Client) qui initie un appel qui utilise des groupes de jonctions et prend en charge la présente spécification DOIT inclure les paramètres Groupe de jonctions dans l'en-tête URI Contact (un URI Contact DOIT être un URI sip ou sips ; donc, ce qui apparaît dans l'en-tête Contact est une traduction SIP de l'URI tel, complété avec les paramètres de groupe de jonctions). Les paramètres de groupe de jonctions dans l'en-tête Contact représentent le groupe de jonctions d'origine. En conséquence des règles de traitement de l'en-tête Contact définies dans la [RFC3261], les demandes suivantes dans le dialogue avec cet agent d'utilisateur vont contenir cet URI Contact dans le R-URI. Noter que la partie utilisateur de cet URI, qui contient les paramètres de groupe de jonctions, va être copiée par suite de ce traitement.

Note : Bien que ce soit discutable, le groupe de jonctions d'origine peut faire partie de l'URI From. Cependant, sémantiquement, l'URI dans un en-tête From est un identifiant abstrait qui repreéente la ressource identifiée à long terme. La présence d'un groupe de jonctions signifie par ailleurs un lien qui est valide seulement pour la durée de la session ; un groupe de jonctions n'a pas de signification une fois la session terminée. Donc, l'URI Contact est le meilleur endroit pour conserver ces informations car il a exactement cette sémantique.

Si l'UAC est informé de la topologie d'acheminement, il PEUT insérer les paramètres de groupe de jonctions de destination du R-URI de la demande. Cependant, dans la plupart des déploiements, l'UAC va utiliser les services d'un mandataire pour poursuive l'acheminement de la demande, et il va appartenir au mandataire d'insérer de tels paramètres dans le R-URI (voir le paragaphe 6.3).

 	6.2	Comportement du serveur d'agent d'utilisateur
Au serveur d'agent d'utilisateur (UAS, User Agent Server) traitant associé à une passerelle, les paramètres de groupe de jonctions dans le R-URI impliquent qu'il devrait utiliser le groupe de jonctions désigné pour l'appel sortant. Si un UAS prend en charge les groupes de jonctions, mais trouve que tous les codes d'identification de circuit pour ce groupe de jonctions particulier sont occupés, il PEUT envoyer une réponse finale 603 Refus.

Si un UAS prend en charge les groupes de jonctions mais n'est pas configuré avec le groupe de jonctions particulier identifié dans le R-URI, il NE DEVRAIT PAS utiliser un autre groupe de jonctions que celui spécifié dans les paramètres. Dans ce cas, il PEUT rejeter la demande avec une réponse finale 404 ; ou si il prend la décision de traiter quand même la demande, il DOIT ignorer les valeurs dans les paramètres "contexte-de-jonctions" et "tgrp".

Si le receveur d'une demande SIP n'a pas la responsabilité d'autorité pour la valeur spécifiée dans le "contexte-de-jonctions", il DOIT traiter la valeur dans le paramètre "tgrp" comme si elle n'était pas là. Traiter ou non la demande est à la discrétion de l'entité traitante ; la demande PEUT être rejetée avec une réponse finale 404. Autrement, si la décision de traiter la demande est prise, l'entité traitante DOIT ignorer les valeurs des paramètres "contexte-de-jonctions" et "tgrp" car il n'a pas la responsabilité d'autorité pour la valeur spécifiée dans "contexte-de-jonctions".

 	6.3	Comportement de mandataire
Un serveur mandataire qui reçoit une demande qui contient le paramètre Groupe de jonctions dans l'en-tête Contact NE DEVRAIT PAS changer ces paramètres lorsque la demande le traverse. Changer ces paramètres peut avoir des conséquences néfastes, car l'UAC qui a rempli les paramètres l'a fait avec une connaissance d'autorité que le mandataire ne peut pas avoir. Le mandataire DEVRAIT plutôt passer les paramètres de groupe de jonctions dans l'en-tête Contact inchangés à la transaction de client que le mandataire crée pour envoyer la demande vers l'aval.

Un mandataire qui connaît la topologie d'acheminement et prend en charge la présente spécification PEUT insérer des paramètres de groupe de jonctions de destination dans le R-URI si aucun n'est présent (voir des exemples aux paragraphes 7.1 et 7.2). Cependant, si des paramètres de groupe de jonctions de destination sont déjà présents dans le R-URI, le mandataire NE DEVRAIT PAS les changer sauf si il a plus d'informations d'autorité sur la topologie d'acheminement que n'avait le client en amont quand il a à l'origine inséré les paramètres de groupe de jonctions dans le R-URI.

Selon les spécificités de la situation, il est parfaitement raisonnable qu'un mandataire n'insère pas les paramètres de groupe de jonctions de destination dans le R-URI. Considérons, par exemple, un mandataire qui comprend les paramètres de groupe de jonctions d'origine et, en accord avec la politique locale, les utilise pour acheminer la demande à une destination autre qu'une passerelle RTPC.

 	7.	Exemple de flux d'appels
 	7.1	Architecture de référence
Considérons la Figure 1, qui décrit un mandataire SIP dans une relation d'acheminement avec trois passerelles dans son domaine, GW1, GW2, et GW3. Les demandes arrivent au mandataire SIP par GW1. Les passerelles GW2 et GW3 sont utilisées comme passerelles de sortie du domaine. GW2 a deux groupes de jonctions configurés, TG2-1 et TG2-2. GW3 a aussi deux groupes de jonctions configurés, TG3-1 et TG2-2 (TG2-2 est partagé entre les passerelles GW2 et GW3).

                                              +-----+ TG2-1
                                              |     |-------->  vers le
        TG1-1  +-----+    +-------+     +---->| GW2 | TG2-2     RTPC
   du    ----->|     |    |Mandat.|     |     |     |-------->
   RTPC        | GW1 |--->| SIP   |-----+     +-----+
         ----->|     |    +-------+     |     +-----+ TG3-1
               +-----+                  |     |     |-------->  vers le
                                        +---->| GW3 | TG2-2     RTPC
                                              |     |-------->
                                              +-----+

Architecture de référence

GW1 dans la Figure 1 a toujours connaissance de toutes les demandes qui arrivent sur le groupe de jonctions TG1-1. Si elle souhaite propager le groupe de jonctions d'entrée au mandataire, elle doit s'arranger pour que le groupe de jonctions apparaisse dans l'en-tête Contact de la demande SIP destinée au mandataire. Le mandataire va, à son tour, propager le groupe de jonctions d'entrée dans l'en-tête Contact plus loin vers l'aval.

Le mandataire utilise GW2 et GW3 comme passerelles d'entrée au RTPC. On suppose que le mandataire a accès à un tableau d'acheminement pour GW2 et GW3 qui inclut les groupes de jonctions appropriés à utiliser quand il envoie un appel au RTPC (comment de tableau  est exactement construit sort du domaine d'application de la présente spécification ; la [RFC5140] est une façon de le faire ; un tableau d'acheminement créé et maintenu manuellement en est une autre). Quand le mandataire envoie une demande à la passerelle d'entrée ou de sortie, et que le tableau d'acheminement de la passerelle est configuré de telle façon qu'un groupe de jonctions est exigé par la passerelle, le mandataire doit s'arranger pour que le groupe de jonctions apparaisse dans le R-URI SIP de la demande destinée à cette passerelle.

 	7.2	Flux d'appels de base
Cet exemple utilise l'architecture de référence de la Figure 1. Les passerelles GW1, GW2, et GW3, et le mandataire SIP sont supposés appartenir à un fournisseur de services dont le domaine est exemple.com.

         GW1        Mandataire SIP          GW2
du RTPC-->|               |                 |
          +---F1--------->|                 |
          |               +---F2----------->|
         ...             ...               ...
          |               |                 |     envoyé au RTPC
          |               |                 | --> et reçoit le message
          |               |                 |     Réponse terminée
         -----------------------------------------
         Appel en cours
         -----------------------------------------
          |               |                 |
          |               |<-----------F3---+
          +<--------------+                 |
         ...             ...               ...

Flux d'appels de base

Dans le flux d'appels ci-dessous, certain en-têtes et messages ont été omis pour faire court. Dans F1, GW1 reçoit une demande d'établissement d'appel provenant du RTPC sur un certain groupe de jonctions. GW1 s'arrange pour que ce groupe de jonctions apparaisse dans l'en-tête Contact de la demande destinée au mandataire SIP.

F1 :
INVITE sip:+16305550100@exemple.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=exemple.com;tgrp=TG1-1;
   contexte-de-jonctions=exemple.com@gw1.exemple.com;user=phone>
...

Dans F2, le mandataire SIP traduit le R-URI et ajoute un groupe de jonctions de destination au R-URI. La demande est ensuite envoyée à GW2.

F2 :
INVITE sip:+16305550100;tgrp=TG2-1;
   contexte-de-jonctions=exemple.com@gw2.exemple.com;user=phone SIP/2.0
...
Record-Route: <sip:proxy.exemple.com;lr>
Contact: <sip:0100;téléphone-contexte=exemple.com;tgrp=TG1-1;
    contexte-de-jonctions=exemple.com@gw1.exemple.com;user=phone>
...

Une fois l'appel établi, l'une ou l'autre extrémité peut supprimer l'appel. À des fins d'illustration, F3 décrit GW2 qui supprime l'appel. Noter que le Contact dans F1, incluant les paramètres de groupe de jonctions, est maintenant le R-URI de la demande. Quand GW1 reçoit cette demande, elle peut associer l'appel au groupe de jonctions approprié pour désallouer les ressources.

F3 :
BYE sip:0100;téléphone-contexte=exemple.com;tgrp=TG1-1;
     contexte-de-jonctions=exemple.com@gw1.exemple.com;user=phone SIP/2.0
Route: <sip:proxy.exemple.com;lr>
   ...

Il vaut la peine de documenter le comportement quand un appel entrant du RTPC est reçu à une passerelle sans le numéro de l'appelant. Considérons la Figure 1, et supposons que GW1 reçoive une demande d'appel venant du RTPC sans numéro d'appelant. Ce cas n'est pas rare, et peut arriver pour diverses raisons, incluant de confidentialité et d'inter fonctionnement entre différents protocoles de signalisation avant que la demande atteigne GW1. Dans des circonstances normales (c'est-à-dire, des instances où le numéro de l'appelant est présent dans la signalisation) GW1 déduirait un URI sip à insérer dans l'en-tête Contact. Cet URI sip va contenir, comme portion utilisateur, le numéro d'appelant venant des informations de la signalisation SS7 entrante. Les paramètres de groupe de jonctions font alors partie de la portion utilisateur comme expliqué précédemment.

Si une passerelle reçoit un appel entrant où le numéro d'appelant n'est pas disponible, elle DOIT créer un URI tel contenant un jeton qui est généré en local et a une signification locale pour la passerelle. Les détails de la génération d'un tel jeton dépendent de la mise en œuvre ; les candidats potentiels incluent le numéro de ligne ou numéro d'accès de la passerelle où l'appel a été accepté. Cet URI tel est ensuite converti en URI sip pour être inséré dans l'en-tête Contact de la demande SIP qui va vers l'aval de la passerelle.

Note : le schéma tel ne permet pas un URI vide ; donc, la règle de production numéro-mondial ou numéro-local de l'URI tel [RFC3966] ne peut pas contenir une chaîne vide. Par conséquent, le comportement du paragraphe ci-dessus est obligatoire dans les cas où un message de signalisation SS7 entrant ne contient pas de numéro d'appelant.

 	7.3	Flux d'appels inter domaines
Cet exemple montre les avantages d'un espace de noms dans les groupes de jonctions. Dans l'exemple de flux ci-dessous, GW1 et le mandataire SIP 1 appartiennent au domaine exemple.com, et le mandataire SIP 2 appartient à un autre domaine, exemple.net. Un appel arrive à GW1 (F1) et est acheminé au domaine exemple.net. Dans le flux d'appels ci-dessous, certains en-têtes et messages ont été omis pour faire plus court.

              exemple.com             exemple.net
       /-------------------------\   /-----------\
         GW1      Mandataire SIP 1    Mandataire SIP 2
du RTPC-->|               |                 |
          +---F1--------->|                 |
          |               +---F2----------->|
          |               |                 |
         ...             ...               ...
          |               +<--F3------------+
         ...             ...               ...
Flux d'appels inter domaines

F1 :
INVITE sip:+16305550100@exemple.com;user=phone SIP/2.0
...
Contact: <sip:0100;téléphone-contexte=exemple.com;tgrp=TG1-1;
      contexte-de-jonctions=exemple.com@gw1.exemple.com;user=phone>
...

Dans F2, le mandataire SIP exécute sa logique d'achemenement et recible le R-URI pour se référer à une ressource dans le domaine exemple.net.

F2 :
INVITE sip:+16305550100@exemple.net;user=phone SIP/2.0
...
Record-Route: <sip:proxy.exemple.com;lr>
Contact: <sip:0100;téléphone-contexte=exemple.com;tgrp=TG1-1;
      contexte-de-jonctions=exemple.com@gw1.exemple.com;user=phone>
...

Dans F3, le domaine exemple.net envoie une demande dans la direction inverse. Le domaine exemple.net n'interprète pas les paramètres de groupe de jonctions dans l'en-tête Contact car ils n'appartiennent pas à ce domaine. L'en-tête Contact, incluant les paramètres de groupe de jonctions, est simplement utilisé comme R-URI dans une demande suivante allant vers le domaine exemple.com.

F3 :
BYE sip:0100;téléphone-contexte=exemple.com;tgrp=TG1-1;
      contexte-de-jonctions=exemple.com@gw1.exemple.com;user=phone
Route: <sip:proxy.exemple.com;lr>
   ...

 	8.	Considérations sur la sécurité

Les paramètres de groupe de jonctions paramètres sont portés dans les R-URI et les en-têtes Contact ; ils sont simplement des modificateurs d'adresse. Toute relation de confiance existante entre l'origine d'une demande et un intermédiaire (ou receveur final) qui traite la demande n'est pas affectée par un tel modificateur.

La modification malveillante d'un groupe de jonctions d'un R-URI en transit peut être cause que l'entité receveuse (disons, une passerelle) va préférer une jonction à une autre, conduisant donc à des attaques qui utilisent des ressources non alloués exclusivement à l'appel. Par exemple, un attaquant qui connaît le nom d'un circuit gratuit sur une passerelle peut modifier le groupe de jonctions dans le R-URI pour recevoir effectivement le service gratuit, ou il peut modifier le groupe de jonctions dans un R-URI pour affecter le flux de trafic à travers les jonctions. De même, modifier le groupe de jonctions dans un en-tête Contact peut causer l'association erronée à l'acheminement intermédiaire d'un appel à une source différente de celle à laquelle il serait normalement associé.

Bien que la présente spécification implique plus d'informations au R-URI et à l'en-tête Contact sous la forme de groupes de jonctions, la classe des attaques et les mécanismes possibles de protection sont les mêmes que spécifié pour les systèmes SIP de base [RFC3261]. Les schémas du protocole sûr d'initialisation de session (SIPS, Session Initiation Protocol Secure) et le mécanisme résultant de la sécurité de couche de transport (TLS, Transport Layer Security) DEVRAIENT être utilisés pour assurer la protection de l'intégrité, atténuant ainsi ces attaques.

Une question surgit naturellement : comment le receveur détermine t-il si l'envoyeur est autorisé à utiliser les ressources représentées par les paramètres de groupe de jonctions ? Il y a deux cas à considérer : l'échange de signalisation intra domaine discuté au paragraphe 7.2, et l'échange de signalisation inter domaines discuté au paragraphe 7.3.

Dans le cas intra domaine, un mandataire qui reçoit des paramètres de groupe de jonctions d'un agent d'utilisateur en amont (normalement une passerelle) devrait seulement les accepter en utilisant le schéma d'URI SIPS ; de plus, il devrait utiliser le résumé HTTP pour mettre au défi et autoriser de façon appropriée l'envoyeur. Un agent d'utilisateur (ou une passerelle) qui reçoit les paramètres de groupe de jonctions d'un mandataire ne va pas être capable de mettre au défi le mandataire en utilisant le résumé HTTP, mais il devrait examiner le certificat X.509 du mandataire pour déterminer si il est autorisé à insérer les ressources représentées par les paramètres de groupe de jonctions dans le flux de signalisation.

Dans le cas inter domaines, un mandataire receveur peut dépendre de l'identité mémorisée dans le certificat X.509 du mandataire envoyeur pour déterminer si l'envoyeur est autorisé à insérer les ressources représentées par les paramètres de groupe de jonctions dans le message de signalisation.

À cause de ces considérations, les paramètres de groupe de jonctions sont seulement applicables au sein d'un ensemble de nœuds de réseau parmi lesquels existe une confiance mutuelle. Si un nœud reçoit une demande de signalisation d'appel d'un nœud en amont qui n'est pas de confiance, il DEVRAIT retirer les paramètres de groupe de jonctions.

Les informations confidentialité révélées par un groupe de jonctions n'annoncent généralement pas beaucoup d'informations sur un utilisateur particulier (humain). Elles portent cependant deux éléments d'informations potentiellement confidentielles qui peuvent être considérés comme sensibles par les transporteurs. D'abord, elles peuvent révéler comment un transporteur peut effectuer l'acheminement et l'échange de trafic au moindre coût, et ensuite, elles introduisent un moyen supplémentaire pour connaître la topologie du réseau et les informations sur un transporteur. Il appartient au jugement discrétionnaire du transporteur de décider si il veut inclure les paramètres de groupe de jonctions et révéler des informations potentiellement sensibles sur sa topologie de réseau. Si la confidentialité est désirée, TLS DEVRAIT être utilisé pour protéger ces informations dans le transit.

 	9.	Considérations relatives à l'IANA

La présente spécification n'exige aucune action de la part de l'IANA.

Les paramètres d'URI tel introduits dans le présent document sont enregistrés par l'IANA dans le document du registre du paramètre URI tel [RFC5341].

 	10.	Remerciements

Les auteurs tiennent à remercier de leurs efforts les participants aux groupes de travail SIPPING et IPTEL, en particulier Jeroen van Bemmel, Bryan Byerly, John Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, Takuya Sawada, Tom Taylor, et Al Varney.

Jon Peterson a aussi eu un rôle capital dans la formulation originale de ce travail.

Alex Mayrhofer a soulevé la question de l'ordre lexicographique des paramètres d'URI tel quand il est converti en URI sip ou sips.

Ted Hardie, Sam Hartman, et Russ Housley ont pris la peine de s'assurer que le texte des comparaisons d'URI et des considérations sur la sécurité était aussi peu ambigu que possible.

 	11.	Références
 	11.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. (MàJ par RFC8174)

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

[RFC3966]	H. Schulzrinne, "L'URI tel pour les numéros de téléphone", décembre 2004. (MàJ par RFC5341) (P.S.)

[RFC4234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplace RFC2234, remplacée par RFC5234)

 	11.2	Références pour information

[RFC5140]	M. Bangalore et autres, "Protocole d'enregistrement de routeur de téléphonie (TGREP)", mars 2008. (P.S.)

[RFC5341]	C. Jennings, V. Gurbani, "Registre des paramètres d'identifiant de ressource uniforme (URI) de l'IANA", septembre  2008. (MàJ RFC3966) (P.S.)

[Telcordia]	"Telcordia Notes on the Network", Telcordia SR-2275, Issue 04, octobre 2000, <http://telecom-info.telcordia.com>.

 	Adresse des auteurs

Vijay K. Gurbani	Cullen Jennings	
Bell Laboratories, Alcatel-Lucent	Cisco Systems	
2701 Lucent Lane	170 West Tasman Drive	
Rm 9F-546	Mailstop SJC-21/3	
Lisle, IL  60532	San Jose, CA  95134	
USA	USA	
téléphone :  +1 630 224 0216	téléphone :  +1 408 421 9990	
mél :  vkg@alcatel-lucent.com 	mél : fluffy@cisco.com 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est actuellement fourni par la Internet Society.