Network Working Group A

Protocole d’initialisation de session pour téléphones (SIP-T) :
Contexte et architectures

Le présent document spécifie les bonnes pratiques actuelles de l’Internet pour la communauté de l’Internet, et appelle à la discussion et à des suggestions pour son amélioration. La distribution du présent mémoire n’est soumise à aucune restriction.

La popularité des passerelles qui interfonctionnent entre le réseau téléphonique public commuté (RTPC) et les réseaux SIP a motivé la publication d’un ensemble de pratiques courantes qui peuvent assurer un comportement cohérent des mises en œuvre. Le présent document établit la taxonomie des usages des passerelles RTPC-SIP, donne des cas d’utilisation et identifie les mécanismes nécessaires pour l’interfonctionnement. Les mécanismes précisent comment SIP assure à la fois l’encapsulation (pontage de la signalisation RTPC à travers un réseau SIP) et la 'traduction' (passerelle).

Table des Matières

1. Introduction 1

2. SIP-T pour interconnexions ISUP-SIP 3

3. Flux SIP-T 4

3.1 Pontage SIP (RTPC - IP - RTPC) 5

3.2 Origine RTPC – terminaison IP 6

3.3 Origine IP – terminaison RTPC 7

4. Rôles et comportement dans SIP-T 7

4.1 Origine 8

4.2 Terminateur 8

4.3 Intermédiaire 8

4.4 Résumé des exigences de comportement 9

5. Composants du protocole SIP-T 9

5.1 Cœur SIP 9

5.2 Encapsulation 9

5.3 Traduction 10

5.4 Prise en charge de la signalisation à mi appel 10

6. Négociation de contenu SIP 10

7. Considérations sur la sécurité 11

8. Considérations relatives à l’IANA 12

Références normatives 12

Références non normatives 12

Appendice A. Notes 12

Appendice B. Remerciements 12

Adresse des auteurs 13

Déclaration complète de droits de reproduction 13

Le protocole d’initialisation de session (SIP, Session Initiation Protocol) [RFC3261] est un protocole de contrôle de couche application qui peut établir, modifier et terminer des sessions ou appels multimédia. Ces sessions multimédia incluent des conférences multimédia, des applications de téléphonie Internet et des applications similaires. SIP est un des protocoles clés utilisés pour mettre en œuvre la voix sur IP (VoIP). Bien qu’effectuer la signalisation d’appel téléphonique et transporter le support audio associé sur IP présente des avantages significatifs par rapport à la téléphonie traditionnelle, un réseau VoIP ne peut pas exister en étant isolé des réseaux de téléphone traditionnels. Il est vital pour un réseau de téléphonie SIP d’interfonctionner avec le TRPC.

La popularité des passerelles qui assurent l’interfonctionnement du RTPC et des réseaux SIP a motivé la publication d’un ensemble de pratiques courantes qui peuvent assurer un comportement cohérent à travers les mises en œuvre. La rareté de l’expertise SIP en dehors de l’IETF suggère que l’IETF est le meilleur endroit pour présenter ce travail, en particulier parce que SIP est dans un état relativement fluctuant par rapport aux protocoles qui constituent le cœur du RTPC. De plus, les groupes de travail de l’IETF qui se concentrent sur SIP (SIP et SIPPING) sont les mieux placés pour juger si de nouvelles extensions à SIP sont justifiées ou non pour l’interfonctionnement avec le RTPC. Ce cadre s’adresse au contexte global dans lequel peuvent être déployées les passerelles d’interfonctionnement RTPC-SIP, il présente des cas d’utilisation et identifie les mécanismes nécessaires à l’interfonctionnement.

Une caractéristique importante de tout réseau de téléphonie SIP est la transparence des caractéristiques par rapport au RTPC. Les servies de télécommunications traditionnels comme l’appel en instance, les numéros verts, etc., mis en œuvre dans les protocoles du RTPC comme le système de signalisation n° 7 (SS7 [Q.764]) devraient être offerts par un réseau SIP d’une manière qui exclue toute différence rédhibitoire dans le ressenti de l’usager tout en ne limitant pas la souplesse de SIP. D’un côté, il est nécessaire que SIP prenne en charge les primitives pour la livraison de tels services lorsque le point de terminaison est un téléphone SIP normal (voir la définition à la Section 2 ci-dessous) plutôt qu’un appareil habile dans le maniement du SS7. Cependant, il est aussi essentiel que les informations du SS7 soient disponibles aux passerelles, les points d’interconnexion SS7-SIP, pour assurer la transparence de caractéristiques autrement non prises en charge dans SIP. Si possible, les informations du SS7 devraient être disponibles dans leur totalité et sans aucune perte aux parties de confiance dans le réseau SIP à travers l’interface RTPC-IP ; un besoin impérieux de faire ainsi résulte du fait que certains réseaux utilisent des paramètres SS7 non normalisés pour transmettre certaines informations à travers leurs réseaux.

Une autre caractéristique importante d’un réseau de téléphonie SIP est la possibilité d’acheminer des demandes SIP – une demande SIP qui établit un appel téléphonique devrait contenir des informations suffisantes dans ses en-têtes pour lui permettre d’être acheminé de façon appropriée à sa destination par les serveurs mandataires dans le réseau SIP. Très concrètement cela a pour conséquence que les paramètres d’un appel comme le numéro composé devraient être portés de la signalisation SS7 aux demandes SIP. L’acheminement dans un réseau SIP peut à son tour être influencé par des mécanismes comme TRIP [RFC3219] ou ENUM [RFC2916].

L’effort SIP-T (SIP for Telephones) fournit un cadre pour l’intégration de la signalisation téléphonique traditionnelle dans les messages SIP. SIP-T fournit les deux caractéristiques mentionnées ci-dessus par des techniques connues sous les noms respectivement de 'encapsulation' et de 'traduction'. À une passerelle SIP-ISUP, les messages ISUP du SS7 sont encapsulés au sein de SIP afin que les informations nécessaires pour les services ne soient pas éliminées dans la demande SIP. Cependant, des intermédiaires comme les serveurs mandataires qui prennent les décisions d’acheminement pour les demandes SIP ne peuvent pas comprendre l’ISUP, de sorte que simultanément, des informations critiques sont traduites d’un message ISUP en en-têtes SIP correspondants afin de déterminer comment la demande SIP sera acheminée.

Bien que e SIP pur ait tous les instruments requis pour l’établissement et l’achèvement des appels, il n’a aucun mécanisme de base pour porter les informations en cours d’appel (comme l’interrogation INF/INR de l’ISUP) le long du chemin de signalisation SIP durant la session. Ces informations en cours d’appel ne résultent en aucun changement de l’état des appels SIP ou des paramètres des sessions qu’initie SIP. On a aussi besoin d’une disposition pour transmettre de telles informations facultatives de couche application.

Définition du problème : assurer la transparence ISUP à travers l’interfonctionnement SS7-SIP

Possibilité d’acheminer les messages SIP Traduction des informations ISUP dans l’en-tête SIP

Transfert des messages de signalisation Utilisation de la méthode INFO pour la signalisation d’en cours d’appel

Tableau 1 : Caractéristiques SIP-T qui satisfont aux exigences d’interfonctionnement RTPC-IP

Bien que le présent document spécifie les exigences ci-dessus, qu’il fournisse des mécanismes pour les satisfaire – il sert cependant de cadre pour les documents qui fournissent ces mécanismes, qui sont tous référencés à la Section 5.

Noter que de nombreux modes de signalisation sont utilisés dans la téléphonie (ISUP du SS7, BTNUP, Q.931, MF, etc.). Le présent document se concentre sur l’ISUP du SS7 et vise seulement à spécifier le comportement à travers les interfaces ISUP-SIP. La portée de l’entreprise SIP-T peut au fil du temps en venir à englober aussi d’autres systèmes de signalisation.

SIP-T n’est pas un nouveau protocole – c’est un ensemble de mécanismes pour faire l’interface de la signalisation du téléphone traditionnel avec SIP. L’objet de SIP-T est de fournir une traduction de protocole et la transparence de caractéristiques à travers les points d’inter connexion RTPC-SIP. Il est destiné à être utilisé lorsque un réseau VoIP (un réseau SIP, pour les besoins du présent document) s’interface avec le RTPC.

Pour utiliser SIP-T, il y a trois modèles de base pour la façon dont les appels interagissent avec les passerelles. Les appels qui sont générés dans le RTPC peuvent traverser une passerelle pour se terminer à un point d’extrémité SIP, comme un téléphone IP. À l’inverse, un téléphone IP peut passer un appel qui traverse une passerelle pour se terminer dans le RTPC. Enfin, un réseau IP qui utilise SIP peut servir de réseau de transit entre des passerelles – un appel peut être généré et se terminer dans le RTPC, mais traverser un réseau fondé sur SIP quelque part sur son cours.

Les interfaces SS7 d’une passerelle particulière déterminent les variantes ISUP que prend en charge la passerelle. La prise en charge d’une version particulière de l’ISUP détermine si elle peut fournir la transparence des caractéristique lors de l’achèvement d’un appel.

o RTPC (Réseau téléphonique public commuté) : cela se réfère à la collection interconnectée entière de compagnies de téléphone local, longue distance et international. Dans les exemples ci-dessous, le terme opérateur de commutateur local (LEC, Local Exchange Carrier) est utilisé pour noter une portion (généralement une division régionale) du RTPC.

o Points d’extrémité IP : tout agent d’utilisateur SIP qui peut agir comme générateur ou receveur d’appels. Donc, les appareils suivants sont classés comme points d’extrémité IP :

* Passerelles : une passerelle de téléphonie fournit un point de conversion entre des protocoles de signalisation (comme ISUP et SIP) ainsi qu’un support audio de commutation de circuit et de paquets. Le terme de contrôleur de passerelle support (MGC, Media Gateway Controller) est aussi utilisé dans les exemples et diagrammes du présent document pour noter des grappes à grande échelle de passerelles et logique de contrôle décomposées qui sont fréquemment déployées de nos jours. De sorte que par exemple, une passerelle SIP-ISUP parle ISUP au RTPC et SIP à l’Internet et est chargée de la conversion entre les types de signaux, ainsi que de l’échange de tout support audio associé.

* Téléphones SIP : le terme utilisé pour représenter tous les appareils d’utilisateur final qui génèrent ou terminent les appels SIP VoIP.

* Points d’interface entre les réseaux où des politiques administratives sont mises en application (potentiellement des boîtiers de médiation, des serveurs mandataires, ou des passerelles).

o Serveurs mandataires : un serveur mandataire est un intermédiaire SIP qui achemine les demandes SIP à leur destination. Par exemple, un serveur mandataire peut diriger une demande SIP sur un autre mandataire, une passerelle ou un téléphone SIP.

Dans la Figure 2 un nuage VoIP sert de réseau de transit aux appels téléphoniques générés dans une paire de LEC, et SIP est employé comme protocole VoIP pour établir et supprimer ces appels VoIP. À la bordure du réseau décrit, un MGC convertit les signaux ISUP en demandes SIP, et les envoie à un serveur mandataire qui à son tour achemine les appels vers d’autres MGC. Bien que cette figure ne décrive que deux MGC, les déploiements de VoIP vont couramment avoir de nombreux points d’interconnexion semblables avec le RTPC (pour avoir normalement une certaine diversité de centres RTPC). Pour un appel généré par LEC1 et se terminant à LEC2, le générateur dans SIP-T est la passerelles qui génère la demande SIP pour un appel VoIP, et la terminaison est la passerelle qui est le consommateur de la demande SIP ; le MGC1 serait donc le générateur, et MGC2, la terminaison. Noter qu’un ou plusieurs mandataires peuvent être utilisés pour acheminer l’appel de l’origine à la terminaison.

Dans ce flux, afin d’intégrer en douceur le réseau IP avec le RTPC, il est important de préserver les informations du SS7 reçues au sein des demandes SIP à la passerelle d’origine et de réutiliser ces informations du SS7 lors de la signalisation au RTPC à la passerelle de terminaison. En encapsulant les informations ISUP dans la signalisation SIP, un réseau SIP peut s’assurer qu’aucune information critique du SS7 pour l’instance de dispositifs n’est perdue lorsque SIP ponte les appels entre deux segments du RTPC.

Ceci dit, si seul l’échange d’ISUP entre les passerelles était pertinent ici, tout protocole pour le transport d’informations de signalisation pourrait être utilisé pour le réaliser, évitant d’avoir besoin de SIP et par conséquent de SIP-T. SIP-T est employé afin de tirer parti des avantages intrinsèques de l’utilisation de SIP : acheminement des demandes et serveurs mandataires qui démultiplient le contrôle d’appel (incluant l’utilisation du fourchement), facilité de création de service SIP, systèmes de négociation des capacités de SIP, et ainsi de suite. La traduction des informations provenant des paramètres de message ISUP reçus aux champs d’en-tête SIP permet aux intermédiaires SIP de considérer ces informations lorsque ils traitent les demandes. SIP-T facilite donc l’établissement d’appel et l’activation de nouveaux services de téléphonie sur le réseau IP tout en fournissant simultanément une méthode d’interconnexion riche en dispositifs annexes avec le RTPC.

Finalement, le scénario de la Figure 2 est juste un des divers flux dans lesquels SIP-T peut être utilisé – les appels vocaux n’ont pas toujours leur origine et leur terminaison dans le RTPC (via des passerelles) ; les téléphones SIP peuvent aussi être des points d’extrémité dans une session SIP-T. Dans les sections qui suivent, les flux possibles suivants seront précisés :

1. Origine RTPC – terminaison RTPC : la passerelle d’origine reçoit l’ISUP du RTPC et elle préserve ces informations (via encapsulation et traduction) dans les messages SIP qu’elle transmet vers la passerelle de terminaison. La terminaison extrait le contenu ISUP du message SIP qu’elle reçoit et réutilise ces informations dans la signalisation qu’elle envoie au RTPC.

2. Origine RTPC – terminaison IP : la passerelle d’origine reçoit l’ISUP du RTPC et elle préserve ces informations ISUP dans les messages SIP (via encapsulation et traduction) qu’elle dirige vers l’agent d’utilisateur SIP de terminaison. La terminaison n’a pas l’usage de l’ISUP encapsulé et l’ignore.

3. Origine IP – terminaison RTPC : un téléphone SIP génère un appel VoIP qui est acheminé par un ou plusieurs serveurs mandataires à la passerelle de terminaison appropriée. La passerelle de terminaison le convertit en signalisation ISUP et dirige l’appel sur une interface RTPC appropriée, sur la base des informations qui sont présentes dans l’en-tête SIP reçu.

4. Origine IP – terminaison IP : c’est un cas de SIP pur. SIP-T (encapsulation ou traduction d’ISUP) n’entre pas en jeu car il n’y a pas d’inter fonctionnement avec le RTPC.

Les paragraphes qui suivent explorent en détail les flux SIP-T essentiels. Noter que parce que les serveurs mandataires sont généralement chargés d’acheminer les demandes SIP (sur la base de l’URI de demande) le point d’extrémité final auquel va finir une demande SIP n’est généralement pas connu de l’origine. Ainsi l’origine ne choisit pas à partir des flux décrits dans cette section, au titre de la configuration statique ou appel par appel – chaque appel est plutôt acheminé indépendamment par le réseau SIP, et elle peut instancier tout flux ci-dessous selon les directives de la logique du réseau.

Un scénario dans lequel un réseau SIP connecte deux segments du RTPC est appelé un "pontage SIP". Lorsque un appel destiné au réseau SIP a son origine dans le RTPC, un message ISUP SS7 va finalement être reçu par la passerelle qui est le point d’interconnexion avec le RTPC. Cette passerelle est, du point de vue du protocole SIP, le client d’agent d’utilisateur pour cette demande d’établissement d’appel. L’acheminement SIP traditionnel est utilisé dans le réseau IP pour déterminer le point de terminaison approprié (dans cette instance, une passerelle) et pour établir un dialogue SIP et commencer la négociation d’une session support entre les points d’extrémité d’origine et de terminaison. La passerelle de sortie signale alors l’ISUP au RTPC, réutilisant tout ISUP encapsulé présent dans la demande SIP qu’il reçoit, comme approprié.

Un flux d’appels très élémentaire pour un pontage SIP est montré ci-dessous.

Un appel est généré dans le RTPC et se termine sur un téléphone SIP. Noter que dans la Figure 5, le serveur mandataire agit comme registraire pour le téléphone SIP en question.

Un simple flux d’appels décrivant la signalisation ISUP et SIP pour un appel généré dans le RTPC se terminant à un point d’extrémité SIP est présenté maintenant.

Appel généré par un téléphone SIP se terminant dans le RTPC. À la différence des deux flux précédents, il n’y a donc pas d’encapsulation ISUP dans la demande – la passerelle de terminaison effectue donc la traduction sur les en-têtes SIP pour déduire les valeurs des paramètres ISUP.

On montre ci-dessous un simple flux d’appels illustrant les différentes branches de l’appel.

Il y a trois sortes d’éléments distincts (du point de vue fonctionnel) dans un réseau SIP VoIP qui s’interconnectent avec le RTPC :

3. Les intermédiaires qui acheminent les demandes SIP des générateurs au terminateur.

Les paragraphes 4.1, 4.2 et 4.3 décrivent le comportement des rôles intermédiaires dans un appel SIP-T.

La fonction du client d’agent d’utilisateur d’origine est de générer les demandes d’établissement d’appel SIP (c’est-à-dire, les INVITE). Lorsque un appel est généré dans le RTPC, une passerelle est l’UAC ; autrement, un point d’extrémité natif SIP est l’UAC. Dans l’un et l’autre cas, noter que l’origine ne peut généralement pas anticiper quelle sorte d’entité sera la terminaison, c’est-à-dire, si la destination finale de la demande est dans un réseau SIP ou dans le RTPC.

Dans le cas d’appels générés dans le RTPC (voir la Figure 3 et la Figure 5) la passerelle d’origine prend les mesures nécessaires pour préserver les informations ISUP en les encapsulant dans la demande SIP qu’elle crée. La passerelle d’origine est investie de la responsabilité de l’identification de la version de l’ISUP (ETSI, ANSI, etc.) qu’elle a reçue et de la fourniture de ces information dans l’ISUP encapsulé (usuellement en ajoutant un corps MIME multipart avec les en-têtes MIME appropriés). Elle formule ensuite les en-têtes de la demande SIP INVITE à partir des paramètres de l’ISUP qu’elle a reçus du RTPC comme approprié (voir la Section 5). Cela peut, par exemple, entraîner d’établir le champ d’en-tête 'To:' dans l’INVITE de façon à refléter le numéro composé (Numéro appelé) de l’IAM ISUP reçu.

Dans d’autres cas (comme celui de la Figure 7) un téléphone SIP est l’origine d’un appel VoIP. Normalement, le téléphone SIP envoie les demandes à un mandataire SIP qui est responsable de l’acheminement de la demande à une destination appropriée. Il n’y a pas d’ISUP à encapsuler chez le client d’agent d’utilisateur, car il n’y a pas d’interface RTPC. Bien que l’appel puisse se terminer dans le réseau téléphonique et ait besoin de signaler l’ISUP afin qu’il ait lieu, l’origine n’a pas de moyen pour anticiper cela et il serait téméraire d’exiger que tous les agents d’utilisateur SIP VoIP aient la capacité de générer l’ISUP. Il n’est donc pas de la responsabilité des points d’extrémité IP comme un téléphone SIP de générer de l’ISUP encapsulé. Donc, une origine doit générer la signalisation SIP tout en effectuant l’encapsulation et la traduction ISUP lorsque possible (c’est-à-dire lorsque l’appel a son origine dans le RTPC).

Exigences de l’origine : encapsuler l’ISUP, traduire les informations de l’ISUP en SIP, prendre en charge MIME multipart (seulement pour les passerelles).

Le terminateur SIP-T est un consommateur d’appels SIP. Le terminateur est un UA SIP standard qui peut être une passerelle qui inter fonctionne avec le RTPC ou un téléphone SIP.

Dans le cas de terminaisons RTPC (voir la Figure 3 et la Figure 7) la passerelle de sortie termine l’appel sur son interface RTPC. Le terminateur génère l’ISUP approprié pour la signalisation au RTPC à partir des messages SIP entrants. Les valeurs pour certains paramètres ISUP peuvent être glanés dans les en-têtes SIP ou extraits directement d’un corps ISUP encapsulé. Généralement parlant, une passerelle utilise tout ISUP encapsulé comme gabarit pour le message qu’elle va envoyer, mais elle efface les valeurs des paramètres dans le gabarit lorsque elle traduit les en-têtes SIP ou ajoute des valeurs de paramètres qui reflètent ses politiques locales (voir l’Appendice A, item 1).

Dans le cas d’une terminaison IP (Figure 5) l’UAS SIP qui reçoit les messages SIP avec de l’ISUP encapsulé ne prend normalement pas en considération le message ISUP. Cela introduit cependant une exigence générale que des appareils comme les téléphones SIP traitent les messages MIME multipart et les types MIME inconnus en douceur (c’est une exigence SIP de base, mais aussi un point sur lequel les fabricants sont connus pour l’avoir court-circuité).

Exigences du terminateur : traitement SIP standard, interprétation de l’ISUP encapsulé (seulement pour les passerelles), prise en charge de MIME multipart, traitement en douceur du contenu MIME inconnu (seulement pour les non passerelles).

Les intermédiaires comme les mandataires sont chargés d’acheminer les messages de l’un à l’autre, ainsi qu’aux passerelles et aux téléphones SIP. Chaque serveur mandataire prend une décision de transmission pour une demande SIP sur la base des valeurs des divers en-têtes, ou 'éléments acheminables' (incluant l’URI de demande, les en-têtes route, et éventuellement tous les autres éléments d’une demande SIP).

SIP-T introduit bien quelques considérations supplémentaires pour transmettre une demande, qui pourraient conduire à de nouvelles caractéristiques et exigences pour les intermédiaires. La transparence des caractéristiques de l’ISUP est cruciale pour la notion de SIP-T. La compatibilité entre les variantes ISUP des interfaces RTPC d’origine et de terminaison conduit automatiquement à la transparence des caractéristiques. Donc, les serveurs mandataires pourraient s’intéresser aux variantes de l’ISUP qui sont encapsulées avec les demandes - la variante elle-même pourrait devenir un élément acheminable. La terminaison d’un appel à un point qui résulte en une plus grande proximité de la destination finale (considérations de débit) est aussi une considération importante. La préférence de l’un sur l’autre résulte en un compromis entre simplicité de fonctionnement et coût. L’exigence de procurer un débit raisonnable peut imposer qu’un appel SIP-T s’étende sur des interfaces RTPC dissimilaires (SIP faisant un pontage à travers différentes passerelles qui ne prennent en charge aucune variante ISUP en commun). Afin d’optimiser au maximum la transparence des caractéristiques et le débit, certains opérateurs d’intermédiaires peuvent vouloir envisager des pratiques relevant des thèmes suivants :

a) Le besoin de transparence des caractéristiques ISUP peut nécessiter une traduction (conversion) de variante ISUP, c’est-à-dire, une conversion d’une variante de l’ISUP à une autre afin de faciliter la terminaison de cet appel sur une interface de passerelle qui n’accepte pas la variante ISUP de l’interface RTPC d’origine. (Voir à l’Appendice A, item 2.) Bien qu’en théorie la conversion puisse être effectuée en tout point du chemin de la demande, il est facultatif de l’effectuer en un point qui est le plus proche de la passerelle de terminaison. Cela pourrait se faire en délivrant l’appel à une application qui pourrait effectuer la conversion entre les variantes. La transparence des caractéristiques est dans ce cas contingente de la disponibilité des ressources nécessaires pour la conversion d’ISUP, et elle entraîne une augmentation du temps d’établissement de l’appel.

b) Une solution de remplacement serait de sacrifier la transparence ISUP en faisant traiter l’appel par une passerelle qui ne prend pas en charge la version de l’ISUP d’origine. Le MGC de terminaison ignorerait alors simplement l’ISUP encapsulé et utiliserait les informations de l’en-tête SIP pour terminer l’appel.

Ainsi, il peut être souhaitable que les serveurs mandataires aient l’intelligence pour faire un choix judicieux selon les options disponibles.

Exigences du mandataire : capacité d’acheminer sur la base du choix des éléments acheminables.

Si l’origine du SIP-T est une passerelle qui a reçu une demande ISUP, elle doit toujours effectuer l’encapsulation et la traduction ISUP, sans considération de l’endroit de terminaison que l’origine de la demande pouvait supposer.

Si le terminateur ne comprend pas l’ISUP, il l’ignore lorsque il effectue le traitement SIP standard. Si le terminateur comprend l’ISUP, et si il a besoin de le signaler au RTPC, il devrait réutiliser l’ISUP encapsulé si il comprend la variante. Le terminateur devrait effectuer les étapes suivantes :

o Extraire l’ISUP du corps du message, et utiliser cet ISUP comme gabarit de message. Noter que si il n’y a pas d’ISUP encapsulé dans le message, la passerelle devrait utiliser à la place un gabarit canonique pour le type de message en question (un message ISUP pré rempli configuré dans la passerelle).

o Traduire les en-têtes de la demande SIP en paramètres ISUP, en écrasant toutes les valeurs du gabarit de message.

Un intermédiaire doit être capable d’acheminer un appel sur la base du choix des éléments acheminables des en-têtes SIP.

Les mécanismes décrits dans les paragraphes qui suivent sont les composants de SIP-T qui fournissent les fonctions du protocole découlant des exigences.

SIP-T utilise les méthodes et procédures de SIP telles que définies par la [RFC3261].

L’encapsulation de la signalisation du RTPC est une des exigences majeures de SIP-T. SIP-T utilise des corps MIME multipart pour permettre aux messages SIP de contenir plusieurs charges utiles (protocole de description de session [RFC2327], ISUP, etc.). Il existe aujourd’hui de nombreuses variantes de l’ISUP ; le type ISUP MIME permet aussi aux receveurs de reconnaître le type ISUP (et donc de déterminer si ils prennent ou non en charge la variante) de la manière la plus expéditive possible. Un schéma pour effectuer l’encapsulation ISUP en utilisant MIME multi-part a été décrit dans la [RFC3204].

La traduction englobe tous les aspects de la conversion de protocole de signalisation entre SIP et ISUP. Il y a essentiellement deux composantes au problème de la traduction :

1. La transposition du message SIP en ISUP : cela décrit une transposition entre l’ISUP et SIP au niveau du message. Dans les déploiements de SIP-T les passerelles sont chargées de générer un message ISUP spécifique pour chaque message SIP reçu et vice versa. Il est nécessaire de spécifier les règles qui gouvernent la transposition entre message ISUP et SIP (c’est-à-dire,quels messages ISUP sont envoyés lorsque un message SIP particulier est reçu : un IAM doit être envoyé à réception d’un INVITE, un REL pour BYE, et ainsi de suite). Une transposition potentielle entre messages ISUP et SIP a été décrite dans la [RFC3398].

2. Transposition de paramètre ISUP en en-tête SIP : une demande SIP qui est utilisée pour établir un appel téléphonique devrait contenir les informations qui lui permettent d’être acheminé de façon appropriée à sa destination par les serveurs mandataires dans le réseau SIP - par exemple, le numéro de téléphone composé par l’usager générateur. Il est important de normaliser un ensemble de pratiques qui définissent la procédure de traduction des informations de l’ISUP en SIP (par exemple, le numéro appelé dans un IAM ISUP doit être transposé dans le champ d’en-tête SIP 'To' et dans l’URI de demande, etc.). Cette question devient intrinsèquement plus compliquée en vertu du fait que les en-têtes d’une demande SIP (en particulier un INVITE) peuvent être transformés par les intermédiaires, et par conséquent, les en-têtes SIP et les corps ISUP encapsulés en viennent à exprimer des valeurs contradictoires – en fait, une partie de l’ISUP encapsulé peut être rendu non pertinent et obsolète.

SIP pur n’a aucun dispositif pour porter les informations de contrôle en cours d’appel qui sont générées durant une session. La méthode INFO [RFC2976] devrait être utilisée à cette fin. Noter cependant que INFO ne convient pas pour gérer un dialogue en chevauchement (pour une façon de mettre en œuvre la numérotation en chevauchement, voir la [RFC3578]). Noter aussi que l’utilisation de INFO pour la signalisation des signaux DTMF en cours d’appel n’est pas recommandée (voir dans la [RFC2833] un mécanisme recommandé).

Le générateur d’une demande SIP-T peut conditionner à la fois des éléments SDP et ISUP dans le même message SIP en utilisant le format MIME multipart. Traditionnellement dans SIP, si l’appareil de terminaison ne prend pas en charge une charge utile multipart (multipart/mixte) et/ou le type MIME ISUP, il va alors rejeter la demande SIP avec une réponse 415 Type de support non accepté spécifiant les types de supports qu’il accepte (par défaut, 'application/SDP'). Le générateur va devoir renvoyer la demande SIP après avoir supprimé la charge utile ISUP (c’est-à-dire, avec seulement la charge utile SDP) et cela sera alors accepté.

C’est un flux assez étrange, et il est très souhaitable d’avoir un mécanisme par lequel le générateur puisse signifier les corps qui sont exigés et ceux qui sont facultatifs afin que le terminateur puisse éliminer en silence les corps facultatifs qu’il ne comprend pas (permettant à un téléphone SIP d’ignorer une charge utile ISUP lorsque le traitement de l’ISUP n’est pas critique). Cela dépend de ce que le terminateur prenne en charge un type de contenu de multipart/mixte et accède à l’en-tête Content-Disposition pour exprimer la criticité.

1. La prise en charge d’ISUP est facultative. Donc, UA2 accepte le INVITE sans considérer si il peut traiter l’ISUP.

2. La prise en charge de ISUP est préférée. UA2 n’accepte pas l’ISUP et rejette l’INVITE avec un 415 Type de support non accepté. UA1 supprime l’ISUP et renvoie l’INVITE avec seulement SDP et cela est accepté.

3. La prise en charge de l’ISUP est obligatoire pour l’établissement d’appel. UA2 ne prend pas en charge l’ISUP et rejette le INVITE avec un 415 Type de support non accepté. UA1 dirige alors sa demande sur UA3.

Noter que les échanges de messages ci-dessus ne sont pas complets ; seuls sont présentés les messages pertinents pour cet exposé. Les spécificités du type MIME ISUP peuvent être obtenues dans la [RFC3204]. Les paramètres 'version' et 'base' ne sont pas montrés ici, mais ils doivent être utilisés conformément aux règles de la [RFC3204].

SIP-T peut être employé comme mécanisme de signalisation inter domaine qui peut être soumis aux relations de confiance préexistantes entre des domaines administratifs. Dans de nombreux environnements réglementaires, la distribution de l’ISUP est restreinte aux opérateurs officiels ; SIP-T introduit certains défis dans la mesure où il forme un pont entre la signalisation d’opérateur et la signalisation de l’utilisateur d’extrémité. Tout domaine administratif qui met en œuvre SIP-T devrait avoir un dispositif de sécurité adéquat (incluant des éléments qui gèrent les politiques appropriées pour traiter la fraude et la facturation dans un environnement inter domaine) en place pour assurer que la transmission des informations ISUP ne résulte en aucune violation de la sécurité.

Transporter l’ISUP dans les corps SIP peut fournir des opportunités de tromperies, fraudes, et problèmes de confidentialité, en particulier lorsque les demandes SIP-T peuvent être générées, inspectées ou modifiées par des points d’extrémité SIP arbitraires. Les corps MIME ISUP devraient être sécurisés (de préférence avec S/MIME [RFC2633]) pour répondre à ce problème, comme il est décrit dans les considérations sur la sécurité de la spécification SIP centrale [RFC3261]. Les propriétés d’authentification fournies par S/MIME permettent au receveur d’un message SIP-T de s’assurer que le corps MIME ISUP a été généré par une entité autorisée. Le chiffrement assurera que seuls les transporteurs possédant une certaine clé de déchiffrement seront capables d’inspecter les corps MIME ISUP encapsulés dans une demande SIP.

Les points d’extrémité SIP-T DOIVENT prendre en charge les signatures S/MIME (CMS SignedData) et DEVRAIENT prendre en charge le chiffrement (CMS EnvelopedData).

Le présent document n’introduit aucune nouvelles considérations pour l’IANA.

[RFC2633] B. Rmasdell, "Spécification de message S/MIME version 3", juin 1999. (Obsolète, voir RFC3851) (P.S.)

[RFC2976] S. Donovan, "Méthode INFO pour SIP", octobre 2000. (P.S., Obsolète, voir RFC6086)

[RFC3204] E. Zimmerer et autres, "Types de support MIME pour objets ISUP et QSIG", décembre 2001. (MàJ par RFC3459) (P.S.)

[Q.764] Recommandation UIT-T Q.764, "Système de signalisation n° 7 ; Procédure de signalisation de la partie utilisateur RNIS", septembre 1997, < http://www.itu.int >.

[RFC2916] P. Faltstrom, "Numéros E.164 et DNS", septembre 2000. (Obsolète, voir RFC3761) (P.S.)

[RFC2833] H. Schulzrinne, S. Petrack, "Charge utile RTP pour chiffres DTMF, tonalités téléphoniques et signaux téléphoniques", mai 2000. (Obsolète, voir RFC4733, RFC4734) (P.S.)

[RFC3578] G. Camarillo et autres, "Transposition de la signalisation en chevauchement du sous-système utilisateur (SSU) du réseau numérique à intégration de services (RNIS) dans le protocole d'initialisation de session (SIP)", août 2003. (P.S.)

1. Certains MGC de terminaison peuvent altérer l’ISUP encapsulé afin de supprimer toutes les conditions spécifiques du circuit d’origine ; par exemple, les fanions d’essai de continuité dans la nature des indicateurs de connexion, etc.

2. Même ainsi, la pertinence des informations spécifiques de l’ANSI dans un réseau ETSI (ou vice versa) est problématique. Il est clair que la force de SIP-T est réalisée lorsque l’ISUP encapsulé implique l’utilisation de paramètres propriétaires.

Nous remercions Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan, Allison Mankin, Scott Bradner et Steve Bellovin de leurs précieux commentaires.

La proposition d’origine 'SIP+' pour les portions d’interconnection du RTPC avec le pontage SIP a été développée par Eric Zimmerer.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y 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 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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

Groupe de travail Réseau	A. Vemuri, Qwest Communications
Request for Comments : 3372	J. Peterson, NeuStar
BCP : 63	septembre 2002
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L’Isle

Aparna Vemuri-Pattisam	Jon Peterson
Qwest Communications	NeuStar, Inc.
6000 Parkwood Pl	1800 Sutter St
Dublin, OH 43016 US	Suite 570
mél : Aparna.Vemuri@Qwest.com	Concord, CA 94520 US
vaparna10@yahoo.com	téléphone : +1 925/363-8720
	mél : jon.peterson@neustar.biz
	URI : http://www.neustar.biz/