Network Working Group G

Transposition du sous-sytème utilisateur RNIS (ISUP) dans le protocole d’initialisation de session (SIP)

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document décrit un moyen d’effectuer la transposition entre deux protocoles de signalisation : le protocole d’initialisation de session (SIP) et le sous-système utilisateur du réseau numérique à intégration de services (RNIS) du système de signalisation n° 7 (SS7). Ce mécanisme peut être mis en œuvre en utilisant SIP dans un environnement où une partie de l’appel implique d’interfonctionner avec le réseau téléphonique public commuté (RTPC).

Table des Matières

1. Introduction 2

2. Domaine d’application 2

3. Terminologie 3

4. Scénarios 3

5. Mécanismes SIP requis 4

5.1 Transit 'transparent' des messages ISUP 4

5.2 Comprendre les corps MIME multipart 4

5.3 Transmission des informations de bitonalité multifréquence (DTMF) 4

5.4 Transmission fiable de réponses provisoires 5

5.5 Support précoce 5

5.6 Transactions à mi appel qui ne changent pas l’état SIP 5

5.7 Protection de la confidentialité 5

5.8 Code de cause ANNULE 6

6. Transposition 6

7. Transposition de SIP en ISUP 6

7.1 Flux d’appels de SIP à ISUP 6

7.2 Automate à états 10

7.3 Accusé de réception reçu 17

8. Transposition d’ISUP en SIP 17

8.1 Flux d’appel d’ISUP à SIP 17

8.2 Automate à états 21

9. Suspend/Resume et Hold 26

9.1 Messages Suspend (SUS) et Resume (RES) 26

9.2 Hold (re-INVITE) 27

10. Libération normale de la connexion 27

10.1 Libération à l’initiative de SIP 28

10.2 Libération à l’initiative d’ISUP 28

11. Messages ISUP de maintenance 29

11.1 Messages Reset 29

11.2 Messages de blocage 29

11.3 Vérifications de continuité 29

12. Construction des URI Telephony 30

12.1 Transposition du format ISUP en URL tel 31

12.2 Transposition du format tel URL en ISUP 31

13. Autres nuances d’ISUP 32

13.1 Lignes directrices pour l’envoi d’autres messages ISUP 32

14. Acronymes 33

15. Considérations sur la sécurité 33

16. Considérations relatives à l’IANA 35

17. Remerciements 35

18. Références normatives 35

19. Références pour information 36

Adresses des auteurs 37

Déclaration complète de droits de reproduction 37

SIP [RFC3261] est un protocole de couche application pour établir, terminer et modifier des sessions multimédia. Il est normalement porté sur IP. Les appels téléphoniques sont considérés comme un type de sessions multimédia où seul de l’audio est échangé.

Le sous système utilisateur du réseau numérique à intégration de services (RNIS) (ISUP, Integrated Services Digital Network User Part) [Q.764] est un protocole de niveau 4 utilisé dans les réseaux du système de signalisation n° 7 (SS7, Signaling System No. 7). Il fonctionne normalement sur le sous-système de transfert de messages (MTP, Message Transfer Part) bien qu’il puisse aussi fonctionner sur IP (voir SCTP [RFC2960]). ISUP est utilisé pour contrôler les appels téléphoniques et pour la maintenance du réseau (blocage des circuits, rétablissement des circuits, etc.).

On se réfère généralement à un module qui effectue la transposition entre ces deux protocoles comme à un contrôleur de passerelle de supports (MGC, Media Gateway Controller) bien que les termes de commutateur logiciel (softswitch) ou d’agent d’appel soient aussi parfois utilisés. Un MGC a des interfaces logiques avec les deux réseaux, le réseau qui porte l’ISUP et le réseau qui porte SIP. Le MGC a aussi certaines capacités de contrôle du chemin de la voix ; il y a normalement une passerelle de supports (MG, Media Gateway) avec des interfaces de jonction E1/T1 (voix provenant du réseau téléphonique public commuté - RTPC) et avec des interfaces IP (Voix sur IP - VoIP). Le MGC et la MG peuvent être fusionnés en une seule boîte physique ou rester séparés.

Ces MGC sont fréquemment utilisés pour relier les réseaux SIP et ISUP afin que les appels générés dans le RTPC puissent atteindre les points d’extrémité de téléphone IP et vice versa. Ceci est utile pour les cas dans lesquels les appels du RTPC ont besoin de tirer parti des services du monde IP, dans lequel les réseaux IP sont utilisés comme réseaux de transit pour des appels de RTPC à RTPC, des architectures dans lesquelles des appels générés sur des téléphones logiques d’un micro ordinateur se terminent sur des terminaux du RTPC, et de nombreuses autres architectures similaires de la prochaine génération de téléphone.

Le présent document décrit la logique et les procédures que peut utiliser un MGC pour mettre en œuvre la transposition entre SIP et ISUP en illustrant les correspondances, au niveau message et au niveau paramètres, entre les protocoles. Il décrit aussi les interactions entre les automates à états parallèles pour ces deux protocoles comme des recommandations de mise en œuvre pour synchroniser les événements de protocole dans les architectures d’interfonctionnement.

Le présent document se concentre sur la traduction des messages ISUP en messages SIP, et sur la transposition des paramètres ISUP en en-têtes SIP. Pour les appels ISUP qui traversent un réseau SIP, l’objet de la traduction est de permettre aux éléments SIP comme les serveurs mandataires (qui normalement ne comprennent pas l’ISUP) de prendre des décisions d’acheminement sur la base de critères ISUP tels que le numéro appelé. Le présent document fournit par conséquent une transposition SIP pour les seuls paramètres ISUP qui pourraient être utilisés par des intermédiaires dans l’acheminement des demandes SIP. Par un effet collatéral de cette approche, la traduction augmente aussi l’interopérabilité globale en fournissant des informations critiques sur l’appel aux points d’extrémité SIP qui ne peuvent pas comprendre l’ISUP encapsulé, ou peut-être qui ne peuvent tout simplement pas comprendre la variante particulière d’ISUP encapsulée dans un message.

Le présent document ne prend en compte que les fonctionnalités d’appel de l’ISUP. Les messages de maintenance qui traitent des circuits du RTPC ne sont traités que dans la mesure où ils affectent le contrôle d’un appel sortant ; autrement, ces messages n’ont, ni n’exigent, aucun équivalent dans SIP.

Les messages qui indiquent une situation d’erreur ou d’encombrement dans le RTPC (MTP-3) et les mécanismes de récupération utilisés tels que les messages ISUP de sous-système utilisateur disponibles et d’essais du sous-système utilisateur, sortent du domaine d’application du présent document

Il y a plusieurs nuances de l’ISUP : l’ISUP international de l’Union Internationale des télécommunications – Secteur de la normalisation des télécommunications (UIT-T) [Q.764] est utilisé dans le présent document ; certaines différences avec l’ISUP de l’Institut national américain de normalisation (ANSI, American National Standards Institute) [T1.113] et l’ISUP du Comité des technologies des télécommunications (TTC, Telecommunication Technology Committee) sont aussi mentionnées. L’ISUP de l’UIT-T est utilisé dans le présent document parce qu’il est le plus largement connu de toutes les nuances de l’ISUP. Du fait du petit nombre de champs qui se transposent directement de l’ISUP en SIP, les différences de signalisation entre l’ISUP de l’UIT-T et les variantes nationales spécifiques de l’ISUP vont généralement avoir peu, sinon pas du tout, d’impact sur la transposition. Noter cependant, que l’UIT-T n’a pas substantiellement normalisé les pratiques pour la portabilité du numéro local (LNP, Local Number Portability) car la portabilité tend à être fondée sur les pratiques du plan de numérotation national, et que par conséquent, la LNP doit être décrite sur une base virtuellement nationale. Les pratiques de portabilité du numéro décrites dans le présent document sont présentées comme un mécanisme facultatif.

La transposition des en-têtes SIP en paramètres ISUP dans le présent document se concentre largement sur la transposition entre les paramètres trouvés dans le message ISUP d’adresse initiale (IAM, Initial Address Message) et les en-têtes associés au message SIP INVITE ; ces deux messages sont utilisés dans leurs protocoles respectifs pour demander l’établissement d’un appel. Une fois qu’un INVITE a été envoyé pour une certaine session, des en-têtes comme les champs To et From deviennent essentiellement fixes, et aucune autre traduction ne sera nécessaire durant la suite de la signalisation, qui est acheminée conformément aux en-têtes Via et Route. Donc, le problème de la transposition de paramètre en en-tête dans SIP-T se réduit plus ou moins à l’IAM et à l’INVITE. Quelques détails supplémentaires sont donnés dans le remplissage des paramètres dans les messages ISUP Adresse terminée (ACM) et Libération (Release, REL) sur la base des codes d’état SIP.

Le présent document décrit quand le chemin support associé à un appel SIP doit être initialisé, terminé, modifié, etc., mais il ne rentre pas dans des détails tels que la façon dont l’initialisation est effectuée ou quels protocoles sont utilisés à cette fin.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

La transposition ISUP-SIP a lieu selon plusieurs scénarios. La façon dont les messages sont générés est différente selon le scénario.

Lorsque il y a un seul MGC et que l’appel vient d’un téléphone SIP pour un téléphone RTPC, ou vice versa, le MGC génère les messages ISUP sur la base des méthodes décrites dans le présent document.

Le scénario où un appel est généré dans le RTPC, entre dans un réseau SIP et se termine à nouveau dans le RTPC est appelé un "pontage SIP". Le pontage SIP devrait assurer la transparence ISUP entre les commutateurs RTPC qui traitent l’appel. Cela se fait en encapsulant les messages ISUP entrants dans le corps des messages SIP (voir la [RFC3204]). Dans ce cas, les messages ISUP générés par le MGC de sortie sont ceux qui sont présents dans le corps SIP (éventuellement avec quelques modifications ; par exemple, si le numéro appelé dans l’identifiant de ressource universel - URI - est différent de celui présent dans l’ISUP à cause d’une redirection SIP, le message ISUP devra être ajusté).

SIP est utilisé au milieu des deux MGC parce que le chemin vocal doit être établi à travers le réseau IP entre les deux MG ; cette structure permet aussi à l’appel de tirer parti de certains services SIP. Les messages ISUP dans les corps SIP donnent des informations (comme les valeurs de cause et les paramètres facultatifs) au MGC homologue.

Dans les deux scénarios, le MGC d’entrée place les messages ISUP entrants dans le corps SIP par défaut. Noter que ceci a des implications pour la sécurité ; voir la Section 15. Si le receveur de ces messages (normalement un client d’agent d’utilisateur/serveur d’agent d’utilisateur SIP - UAC/UAS) ne les comprend pas, une négociation utilisant les en-têtes SIP 'Accept' et 'Require' va avoir lieu et ils ne seront pas inclus dans le prochain échange de message SIP.

Il peut y avoir une passerelle de signalisation (SG, Signaling Gateway) entre le RTPC et le MGC. Elle encapsule les messages ISUP sur IP de la manière décrite dans la [RFC2960]. La transposition décrite dans le présent document n’est pas affectée par le protocole de transport sous-jacent d’ISUP.

Noter que le mécanisme de numérotation en chevauchement (utilisation du message Adresse suivante (SAM, Subsequent Address Message)) sort du domaine d’application de ce document. Le présent document suppose que les passerelles qui font face aux réseaux ISUP dans lesquels est utilisée la numérotation en chevauchement vont mettre en œuvre des temporisateurs pour s’assurer que tous les chiffres ont été collectés avant de transmettre un INVITE à un réseau SIP.

Dans certaines instances, les passerelles peuvent recevoir des messages ISUP incomplets qui indiquent une segmentation du message due à sa longueur excessive. Ces messages seront habituellement suivis d’un message Segmentation (SGM, Segmentation Message) contenant le reste du message ISUP original. Un message incomplet ne peut pas contenir suffisamment de paramètres pour permettre une transposition appropriée dans SIP ; de même, l’encapsulation (voir ci-dessous) d’un message ISUP incomplet peut être source de confusion pour les passerelles de terminaison. Par conséquent, une passerelle DOIT attendre qu’un message ISUP complet soit reçu (ce qui peut impliquer d’attendre jusqu’à ce qu’un ou plusieurs SGM arrivent) avant d’envoyer un INVITE correspondant.

Pour une transposition correcte entre ISUP et SIP, certains mécanismes SIP au dessus et au delà de ceux disponibles dans la spécification SIP de base sont nécessaires. Ces mécanismes sont exposés ci-dessous. Si l’UAC/UAS SIP impliqué dans l’appel ne les accepte pas, il est encore possible de poursuivre, mais le comportement dans l’établissement de l’appel peut être légèrement différent de celui attendu par l’usager (par exemple, l’autre partie répond avant d’avoir reçu la tonalité de retour d’appel, l’usager n’est pas informé du renvoi de l’appel, etc.).

Pour permettre aux passerelles de tirer parti de la pleine gamme des services offerts par le réseau téléphonique existant lorsque elles passent des appels du RTPC au RTPC à travers un réseau SIP, les messages SIP DOIVENT être capables de transporter des charges utiles ISUP de passerelle à passerelle. Le format pour encapsuler ces messages ISUP est défini dans la [RFC3204].

Il est permis aux agents d’utilisateur SIP qui ne comprennent pas ISUP d’ignorer ces corps MIME facultatifs.

Dans la plupart des situations d’interfonctionnement de RTPC, les corps de message SIP devront transporter des informations de session (SDP – protocole de description de session) en plus des informations ISUP et/ou de facturation.

Les nœuds d’interfonctionnement du RTPC DOIVENT comprendre le type MIME de "multipart/mixed" comme défini dans la [RFC2046]. Les clients expriment leur prise en charge de cela en incluant "multipart/mixed" dans un en-tête "Accept".

La façon dont les tonalités DTMF (Dual-Tone Multifrequency, bitonalité multifréquence) exécutées par l’usager sont transmises par une passerelle est complètement indépendante de la façon dont SIP et ISUP interfonctionnent ; cependant, comme l’attelage DTMF est une composante d’une solution de passerelle complète, on offre ici quelques lignes directrices.

Comme le codec choisi pour la transmission de la voix peut n’être pas la solution idéale pour porter les informations DTMF, une méthode de transmission des symboles de ces informations dans la bande est souhaitable (car la transmission hors bande seule lancerait de nombreux défis de synchronisation des flux de supports pour la réinsertion des tonalités). Cette transmission PEUT être effectuée comme décrit dans la [RFC2833].

Les réponses provisoires (dans la classe 1xx) sont utilisées dans la transmission des informations de progression de l’appel. L’interfonctionnement avec le RTPC s’appuie en particulier sur ces messages pour le contrôle du canal de support et la synchronisation des événements d’appel.

Lors de l’interfonctionnement avec le RTPC, les messages SIP DOIVENT être envoyés fiablement de bout en bout ; la fiabilité des demandes est garantie par le protocole de base. Un mécanisme de fiabilité provisoire de couche application pour les réponses est décrit dans la [RFC3262].

Le support précoce note la capacité d’exécuter un support (audio pour la téléphonie) avant qu’une session SIP ait été établie (avant l’envoi d’un code de réponse 2xx). Pour la téléphonie, l’établissement d’un support dans la direction arrière est désirable afin que les tonalités et les annonces puissent être exécutées, en particulier lors de l’interfonctionnement avec un réseau qui ne peut pas signaler l’état d’appel hors bande (comme un réseau MF traditionnel). Dans les cas où l’interfonctionnent ne se fait pas, l’utilisation du support précoce est presque toujours indésirable car il consomme des ressources de cœur de réseau inter-machine pour exécuter des supports pour lesquels aucun revenu n’est collecté. Noter que comme un INVITE contient presque toujours le SDP requis pour envoyer les supports dans la direction arrière, et exige que les agents d’utilisateur se préparent eux-mêmes à recevoir les supports vers l’arrière aussitôt qu’un INVITE est transmis, le protocole SIP de base a assez de ressources pour permettre des systèmes rudimentaires de support précoce unidirectionnel. Cependant, ce mécanisme a un certain nombre de limitations - par exemple, les flux de supports offerts dans le SDP de l’INVITE ne peuvent pas être modifiés ou refusés, et le RTCP bidirectionnel requis pour la maintenance de session ne peut pas être établi.

Donc, les passerelles PEUVENT prendre en charge des systèmes de support précoce plus sophistiqués lorsque ils en viennent à être mieux compris. Un mécanisme qui donne le moyen d’initier un système de support précoce avec toutes ses caractéristiques est décrit dans la [RFC3311].

Noter que dans les réseaux SIP, non seulement les commutateurs mais aussi les agents d’utilisateur peuvent générer les codes de réponse 18x et initier le support précoce vers l’arrière, et que donc certaines passerelles peuvent souhaiter mettre en application des politiques qui restreignent l’utilisation de supports arrière par des agents d’utilisateur arbitraires (voir la Section 15).

Lors de l’interfonctionnement avec le RTPC, il y a des situations où les passerelles auront besoin de s’envoyer des messages l’une à l’autre sur SIP et qui ne correspondent à aucune opération SIP.

À l’appui de transactions de mi appel et d’autres événements ISUP qui ne correspondent à aucune méthode SIP existante, les passerelles SIP DOIVENT prendre en charge la méthode INFO, définie dans la [RFC2976]. Noter que le présent document ne prescrit ni n’endosse l’utilisation de INFO pour porter les numéros DTMF.

Les passerelles DOIVENT accepter "405 Méthode non admise" et "501 Non mis en œuvre" comme des réponses non fatales aux demandes INFO – c’est-à-dire qu’un appel en cours NE DOIT PAS être éliminé si une destination rejette ainsi une demande INFO envoyée par une passerelle.

ISUP a un concept de restriction de présentation - un mécanisme par lequel un usager peut spécifier qu’il ne voudrait pas que son numéro de téléphone soit affiché à la personne appelée (vraisemblablement quelqu’un avec Identifiant d’appel). Lorsque une passerelle reçoit une demande ISUP qui exige une restriction de présentation, elle doit donc d’une certaine façon cacher l’identité de l’appelant.

Le protocole SIP de base prend en charge une méthode pour spécifier qu’un usager est anonyme. Cependant, ce système a un certain nombre de limitations - par exemple, il révèle l’identité de la passerelle elle-même, ce qui peut être une divulgation qui impacte la confidentialité. Donc, les passerelles PEUVENT prendre en charge des systèmes de confidentialité plus sophistiqués. Un mécanisme qui donne un moyen de prendre en charge une négociation de confidentialité complète (ce qui interagit avec les systèmes de gestion de l’identité) est décrit dans la [RFC3323].

Il y a un moyen dans ISUP pour signaler qu’on voudrait arrêter une tentative d’établissement d’un appel - le message d’utilisation générale REL est envoyé vers l’avant. Il y a un concept similaire dans SIP – celui d’une demande ANNULE qui est envoyée afin d’arrêter l’établissement d’un dialogue SIP. Pour diverses raisons, cependant, les demandes ANNULE ne peuvent pas contenir de corps de message, et donc, pour porter des informations importantes dans REL (le code de cause) de bout en bout dans les cas de pontage SIP, l’encapsulation ISUP ne peut pas être utilisée.

Ordinairement, cela ne pose pas de gros problèmes, parce que pour des raisons pratiques, la seule raison de produire un REL pour annuler une tentative d’établissement d’appel est que l’usager raccroche le téléphone alors qu’il est encore en train de sonner (ce qui résulte en un code de cause "Libération normale"). Cependant, dans des conditions exceptionnelles, comme une défaillance catastrophique du réseau, un REL peut être envoyé avec un code de cause différent, et il serait utile qu’un réseau SIP puisse porter le code de cause de bout en bout. Les passerelles PEUVENT donc prendre en charge un mécanisme de livraison de bout en bout de telles causes d’échec. Un mécanisme qui fournit cette capacité est décrit dans la [RFC3326].

La transposition entre ISUP et SIP est décrite en utilisant des diagrammes de flux d’appel et des automates à états. Un automate à états traite les appels de SIP à ISUP et le second de ISUP à SIP. Certains détails, comme des retransmissions et des états (attente du message Libération achevée (RLC, Release Complete) attente d’un ACK SIP, etc.) qui ne sont pas montrés sur les figures afin de les rendre plus faciles à suivre.

Les boîtes représentent les différents états de la passerelle, et les flèches montrent les changements d’état. L’événement qui déclanche le changement d’état et les actions à entreprendre apparaissent sur la flèche : événement/paragraphe qui décrivent les actions à entreprendre.

Par exemple, 'INVITE / 7.2.1' indique qu’une demande INVITE a été reçue par la passerelle, et la procédure à réception est décrite au paragraphe 7.2.1 de ce document.

Il est RECOMMANDÉ que les passerelles mettent en œuvre une équivalence fonctionnelle avec les flux d’appel détaillés aux paragraphes 7.1 et 8.1. Des déviations par rapport à ces flux sont permises à l’appui des variantes nationales de l’ISUP, ou de toutes les politiques de prudence recommandées à la Section 15.

Les flux d’appel suivants illustrent l’ordre des messages dans les cas normaux de succès et d’erreur lors de l’établissement d’un appel initié depuis le réseau SIP. Les accusés de réception "100 Essai" aux demandes INVITE ne sont pas affichés ci-dessous bien qu’ils soient exigés dans de nombreuses architectures.

Dans ces diagrammes, toute la signalisation d’appel (SIP, ISUP) va et vient du MGC ; le traitement du support (par exemple, raccourci audio, libération de réseau) est effectué par la MG, sous le contrôle du MGC. Pour simplifier, elles sont montrées comme un seul nœud, marqué "MGC/MG."

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP.

3. Le nœud ISUP distant indique que l’adresse est suffisante pour établir un appel en renvoyant un message ACM.

4. Le code "État de l’appelant" dans le message ACM est transposé en une réponse provisoire SIP (comme décrit aux paragraphes 7.2.5 et 7.2.6) et est retourné au nœud SIP. Cette réponse peut contenir SDP pour établir un flux support précoce (comme le montre le diagramme). Si aucun SDP n’est présent, l’audio sera établi dans les deux directions après l’étape 8.

5. Si la variante ISUP le permet, le nœud ISUP distant peut produire divers messages Progression de l’appel (CPG, Call Progress) pour indiquer, par exemple, que l’appel est en cours de transmission.

6. À réception d’un message CPG, la passerelle va transposer le code d’événement en une réponse provisoire SIP (voir le paragraphe 7.2.9) et l’envoyer au nœud SIP.

7. Une fois que l’usager RTPC répond, un message Réponse (ANM, Answer Message) sera envoyé à la passerelle.

8. À réception de l’ANM, la passerelle va envoyer un message 200 au nœud SIP.

9. Le nœud SIP, à réception d’une réponse finale INVITE (200), va envoyer un ACK pour accuser réception.

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP.

3. Comme le nœud distant est configuré pour la réponse automatique, il va envoyer un message Connecte (CON) à réception de l’IAM. (Pour ANSI, ce message sera un ANM).

5. Le nœud SIP, à réception d’une réponse finale INVITE (200), va envoyer un ACK pour accuser réception.

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP. Le temporisateur ISUP T7 est lancé à ce moment.

3. Le temporisateur ISUP T7 arrive à expiration avant la réception d’un message ACM ou CON, de sorte qu’un message REL est envoyé pour annuler l’appel.

5. Le nœud SIP, à réception d’une réponse finale INVITE (504), va envoyer un ACK pour accuser réception.

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP.

3. Comme le nœud distant est configuré pour une réponse automatique, il va envoyer un message CON à réception de l’IAM. Dans les flux ANSI, plutôt qu’un CON, c’est un ANM (sans ACM) qui serait envoyé.

4. À réception de l’ANM, la passerelle va envoyer un message 200 au nœud SIP et lancer le temporisateur SIP T1.

5. La réponse est retransmise chaque fois que le temporisateur SIP T1 arrive à expiration.

6. Après sept retransmissions, l’appel est supprimé par l’envoi d’un REL au nœud ISUP, avec un code de cause de 102 (récupération après expiration du temporisateur).

7. Un BYE est transmis au nœud SIP pour tenter de clore l’appel. On ne montre pas la suite du traitement pour cette libération, car l’état du nœud SIP n'est pas facile à connaître dans ce scénario.

8. À réception du message REL, le nœud ISUP distant va répondre par un message RLC.

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP.

3. Comme le nœud ISUP distant n’est pas capable d’achever l’appel, il va envoyer un REL.

4. La passerelle libère le circuit et confirme qu’elle est disponible pour réutilisation en envoyant un RLC.

5. La passerelle traduit le code de cause du REL en une réponse d’erreur SIP (voir le paragraphe 7.2.4) et l’envoie au nœud SIP.

6. Le nœud SIP envoie un ACK pour accuser réception de la réponse finale à INVITE.

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP.

3. Comme le nœud ISUP n’est pas capable d’achever l’appel et veut générer lui-même la tonalité/annonce d’erreur, il envoie une ACM avec un code de cause. La passerelle lance un temporisateur d’interfonctionnement.

4. À réception d’une ACM avec cause (présence du paramètre CAI) la passerelle va générer un message 183 vers le nœud SIP ; il contient SDP pour établir un raccourci de support précoce.

5. Une réponse finale INVITE, fondée sur le code de cause reçu dans le message ACM précédent, est générée et envoyée au nœud SIP pour terminer l’appel. Voir au paragraphe 7.2.4.1 le tableau qui contient la transposition du code de cause en réponse SIP.

6. À expiration du temporisateur d’interfonctionnement, un REL est envoyé vers le nœud RTPC pour terminer l’appel. Noter que le nœud SIP peut aussi terminer l’appel en envoyant un ANNULE avant l’expiration du temporisateur d’interfonctionnement. Dans ce cas, la signalisation progresse comme au paragraphe 7.1.7.

7. À réception du message REL, le nœud ISUP distant va répondre avec un message RLC.

8. Le nœud SIP envoie un ACK pour accuser réception de la réponse INVITE finale.

1. Lorsque un usager SIP souhaite commencer une session avec un usager RTPC, le nœud SIP produit une demande INVITE.

2. À réception d’une demande INVITE, la passerelle la transpose en un message IAM et l’envoie au réseau ISUP.

3. Le nœud ISUP distant indique que l’adresse est suffisante pour établir un appel en renvoyant un message ACM.

4. Le code "État de l’appelant" dans le message ACM est transposé en une réponse provisoire SIP (comme décrit aux paragraphe 7.2.5 et 7.2.6) et retourné au nœud SIP. Cette réponse peut contenir SDP pour établir un flux de support précoce.

5. Pour annuler l’appel avant qu’il y soit répondu, le nœud SIP envoie une demande ANNULE.

7. À réception de la demande ANNULE, la passerelle envoie un message REL pour terminer l’appel ISUP.

8. La passerelle envoie un message "487 Appel annulé" au nœud SIP pour achever la transaction INVITE.

9. À réception du message REL, le nœud ISUP distant va répondre par un message RLC.

Noter que REL peut être reçu dans tout état ; le traitement est le même dans chaque cas (voir la Section 10).

| T9/7.2.8 +---------------+ | REL/7.2.4 | +<----------------+ Alerte |-|-------------------->|

Lorsque une demande INVITE est reçue par la passerelle, une réponse "100 Essaye" PEUT être renvoyée au réseau SIP indiquant que la passerelle traite l’appel.

Les ressources de matériel nécessaires pour le flux de support DOIVENT être réservées dans la passerelle lorsque l’INVITE est reçu, car un message IAM ne peut pas être envoyé avant que la réservation de ressources (en particulier la sélection TCIC) ait lieu. Normalement, les ressources consistent en un intervalle de temps dans un E1/T1 et un accès RTP/UDP sur le côté IP. Les ressources peuvent aussi inclure toutes dispositions de qualité de service (bien qu’aucune pratique de ce genre ne soit recommandée dans le présent document).

Après l’envoi de l’IAM, le temporisateur T7 est lancé. La valeur par défaut de T7 est entre 20 et 30 secondes. La passerelle passe à l’état 'Essaye'.

Ce paragraphe précise la transposition des en-têtes SIP de message INVITE en paramètres ISUP dans un message d’adresse initial (IAM). Une passerelle RTPC-SIP est chargée de créer un IAM lorsque elle reçoit un INVITE.

Cinq paramètres obligatoires apparaissent au sein du message IAM : le numéro de l’appelé (CPN, Called Party Number), la nature de l’indicateur de connexion (NCI, Nature of Connection Indicator), les indicateurs d’appel vers l’avant (FCI, Forward Call Indicators), la catégorie de l’appelant (CPC, Calling Party's Category), et finalement un paramètre qui indique les caractéristiques désirées du support pour l’appel – dans certaines variantes ISUP, les exigences sur le support de transmission (TMR, Transmission Medium Requirement) sont exigées, dans d’autres ce sont les informations de service d’utilisateur (USI, User Service Information) (ou les deux). Tous les messages IAM DOIVENT contenir ces cinq paramètres au minimum. Donc, chaque passerelle doit avoir un moyen de remplir chacun de ces cinq paramètres lorsque un INVITE est reçu. Beaucoup des valeurs qui vont apparaître dans ces paramètres (comme le NCI ou l’USI) vont très probablement être les mêmes pour chaque IAM créé par la passerelle. D’autres (comme le CPN) vont varier d’un appel à l’autre ; la passerelle extrait les informations de l’INVITE afin de remplir ces paramètres de façon appropriée.

Il y a aussi quelques paramètres facultatifs qui peuvent apparaître dans un message IAM ; la Recommandation UIT-T Q.763 [Q.763] en énumère 29 en tout. Cependant, chacun de ces paramètres n’a pas besoin d’être traduit pour réaliser la transposition SIP-ISUP. Comme on l’a dit plus haut, la traduction permet aux éléments de réseau SIP de comprendre le contexte RTPC de base de la session (pour qui elle est, et ainsi de suite) si ils ne sont pas capables de déchiffrer de l’ISUP encapsulé. Les paramètres qui n’ont de signification que pour le RTPC seront portés à travers les réseaux RTPC-SIP- RTPC via l’encapsulation – la traduction n’est pas nécessaire pour ces paramètres. Des 29 paramètres facultatifs susmentionnées, seuls les suivants sont immédiatement utiles pour la traduction : le numéro de l’appelant (CIN, qui est couramment présent), la sélection de réseau de transit (TNS, Transit Network Selection), le paramètre d’identification du transporteur (CIP, Carrier Identification Parameter) (qui est présent dans les réseaux ANSI), le numéro appelé à l’origine (OCN, Original Called Number), et les chiffres génériques (connus dans certaines variantes comme paramètre générique d’adresse (GAP, Generic Address Parameter)).

Lorsque un SIP INVITE arrive à une passerelle RTPC, la passerelle DEVRAIT tenter de faire usage de l’ISUP encapsulé (voir la [RFC3204]), si il y en a, au sein de l’INVITE pour aider à la formulation de la signalisation RTPC sortante, mais DEVRAIT aussi tenir compte des considérations pour la sécurité de la Section 15. Si possible, la passerelle DEVRAIT réutiliser les valeurs de chacun des paramètres ISUP de l’IAM encapsulé car il formule un IAM qu’elle va envoyer à travers son interface RTPC. Dans certains cas, la passerelle sera incapable d’utiliser cet ISUP - par exemple, si la passerelle ne comprend pas la variante ISUP et doit donc ignorer le corps encapsulé. Même lorsque il y a de l’ISUP encapsulé compréhensible, les valeurs pertinentes des champs d’en-tête SIP DOIVENT 'recouvrir' à travers le processus de traduction les valeurs des paramètres qui auraient été établies sur la base de l’ISUP encapsulé. En d’autres termes, les mises à jour des paramètres critiques de contexte de session qui sont créés dans le réseau SIP prennent le pas, dans les cas de pontage ISUP-SIP-ISUP, sur l’ISUP encapsulé. Cela permet de mettre en œuvre de nombreux services de base, incluant diverses sortes de renvoi et redirection d’appel, dans le réseau SIP.

Par exemple, si un INVITE arrive à une passerelle avec un IAM encapsulé avec un champ CPN qui indique le numéro de téléphone +12025332699, mais si l’URI de demande de l’INVITE indique 'tel:+15105550110', la passerelle DOIT utiliser le numéro de téléphone de l’URI de demande, plutôt que celui de l’IAM encapsulé, lorsque elle crée l’IAM qu’elle va envoyer au RTPC. D’autres détails suivent sur la façon dont les champs d’en-tête SIP sont traduits en paramètres ISUP.

Les passerelles DOIVENT être approvisionnées avec des valeurs par défaut pour les paramètres ISUP obligatoires qui ne peuvent pas être déduits de la traduction (tels que les paramètres NCI ou TMR) pour les cas où il n’y a pas d’ISUP encapsulé. Le paramètre FCI DOIT aussi avoir une valeur par défaut, car seul le bit 'M' de la valeur par défaut peut être changé durant le processus de traduction si le mécanisme facultatif de traduction de la portabilité du numéro décrit ci-dessous est utilisé.

La première étape dans la traduction des champs d’un message INVITE en paramètres d’un IAM est l’inspection de l’URI de demande.

Si les pratiques facultatives de portabilité du numéro sont prises en charge par la passerelle, les étapes suivantes relatives au traitement des paramètres 'npdi' et 'rn' de l’URI de demande devraient être suivies.

Si il n’y a pas de champ 'npdi=oui' dans l’URI de demande, le principal numéro de téléphone dans l’URL tel (les chiffres qui suivent immédiatement 'tel:') DOIVENT être convertis au format ISUP, suivant les procédures décrites à la Section 12, et utilisés pour remplir le paramètre CPN.

Si le champ 'npdi=oui' existe dans l’URI de demande, le bit du paramètre FCI pour 'numéro traduit' au sein de l’IAM DOIT alors refléter qu’une recherche dans une base de données de portabilité de numéros a été effectuée.

Si en plus du champ 'npdi=oui' il n’y a pas de champ 'rn=' présent, le principal numéro de téléphone dans l’URL tel DOIT alors être converti au format ISUP (voir la Section 12) et utilisé pour remplir le paramètre CPN. Cela indique qu’une recherche dans une base de données de portabilité de numéros à eu lieu, mais que le numéro appelé n’y était pas porté.

Si en plus du champ 'npdi=oui' un champ 'rn=' est présent, alors dans l’ISUP ANSI le champ 'rn=' DOIT être converti en format ISUP et utilisé pour remplir le CPN. Le numéro de téléphone principal dans l’URL tel DOIT être converti en format ISUP et utilisé pour remplir le paramètre Chiffres génériques (ou GAP dans ANSI). Dans certaines autres variantes ISUP, le numéro donné dans le champ 'rn=' sera plutôt ajouté devant le numéro de téléphone principal (avec ou sans préfixe ou séparateur) et le résultat combiné DOIT être utilisé pour remplir le CPN. Une fois que les paramètres 'rn=' et 'npdi=' ont été traduits, les pratiques de traduction de portabilité de numéro sont achevées.

Les pratiques de traduction obligatoires suivantes sont accomplies après les traductions de portabilité de numéro, s’il y en a.

Si les pratiques de portabilité du numéro ne sont pas prises en charge par la passerelle, le numéro de téléphone principal dans l’URL tel (les chiffres qui suivent immédiatement 'tel:') DOIT être converti en format ISUP, suivant les procédures décrites à la Section 12, et utilisées pour remplir le paramètre CPN.

Si le principal numéro de téléphone dans l’URI de demande et celui de l’en-tête To sont différents, l’en-tête To DEVRAIT être utilisé pour remplir un paramètre OCN. Autrement, l’en-tête To DEVRAIT être ignoré.

Certaines procédures de traduction facultatives sont fournies pour l’acheminement fondé sur le transporteur. Si le paramètre 'cic=' est présent dans l’URI de demande, la passerelle DEVRAIT consulter la politique locale pour s’assurer qu’il est approprié de transmettre le code d’identification de transporteur (CIC, Carrier Identification Code) (à ne pas confondre avec le code d’identification de circuit de MTP3) dans l’IAM ; si la passerelle prend en charge de nombreux circuits indépendants, elle peut devoir choisir un circuit particulier qui pointe sur le transporteur identifié par le CIC, ou une combinaison par laquelle ce transporteur est accessible.

Les politiques pour ces circuits (qui se fondent sur les préférences des transporteurs auxquels les circuits sont associés et la variante ISUP en usage) DEVRAIENT imposer le paramètre CIP ou TNS qui est utilisé pour porter le CIC. En l’absence d’une politique pré définie, le TNS devrait être utilisé lorsque le paramètre CPN est dans le format international (c’est-à-dire, la portion d’URL tel de l’URI de demande est précédée par un '+', qui va générer un CPN en format international) et (lorsque il est pris en charge) le CIP devrait être utilisé dans les autres cas.

Lorsque un appel SIP a été acheminé à une passerelle, l’URI de demande va très probablement contenir un URL tel (ou un URI SIP avec une portion usager d’URL tel) – les passerelles SIP-ISUP qui reçoivent des URI de demande qui ne contiennent pas de numéro de téléphone valide DEVRAIENT rejeter de telles demandes avec un code de réponse approprié. Les passerelles DEVRAIENT cependant continuer de traiter les demandes avec un champ d’en-tête From qui ne contient pas un numéro de téléphone, comme ce sera parfois le cas si un appel généré par un téléphone SIP qui emploie une convention d’URI SIP usager@hôte. Le paramètre CIN DEVRAIT être omis de l’IAM sortant si le champ From est inutilisable. Noter qu’en remplacement, les mises en œuvre de passerelles PEUVENT considérer des moyens non standard de transposer des URI SIP particuliers en numéros de téléphone.

Lorsque une passerelle reçoit un message avec de l’ISUP encapsulé (compréhensible) elle DOIT régler l’indicateur FCI dans l’IAM généré de telle sorte que tous les bits en rapport avec l’interfonctionnement aient les mêmes valeurs que leurs contreparties dans l’ISUP encapsulé. Dans la plupart des cas, ces indicateurs vont déclarer qu’aucun interfonctionnement n’a été rencontré, sauf si l’interfonctionnement s’est rencontré ailleurs dans le chemin de l’appel. Si de l’ISUP encapsulé utilisable n’est pas présent dans un INVITE reçu par la passerelle, il est fortement RECOMMANDÉ que la passerelle règle le bit Indicateur d’interfonctionnement du FCI à 'pas d’interfonctionnement' et l’indicateur de partie utilisateur RNIS à 'ISUP utilisé sur tout le chemin' ; la passerelle PEUT aussi régler l’indicateur d’accès d’origine à 'Accès d’origine non RNIS' (généralement, il n’est pas sûr de supposer que des téléphones SIP vont prendre en charge des services de point d’extrémité RNIS, et les procédures du présent document ne précisent pas les transpositions pour traduire tous ces services).

Noter que lorsque 'Interfonctionnement rencontré' est établi dans le paramètre FCI de l’IAM, cela indique que l’ISUP interfonctionne avec un réseau qui n’est pas capable de fournir autant de services que l’ISUP. Les réseaux ISUP ne vont donc pas employer certaines caractéristiques qu’ils emploieraient autrement normalement, incluant potentiellement l’utilisation de codes de cause RNIS dans des conditions de défaillance (par opposition à l’envoi d’ACM suivi par des annonces audibles). Si ils le désirent, les fabricants de passerelles PEUVENT fournir une option configurable, utilisable à la discrétion des fournisseurs de services, qui vont signaler dans le FCI que l’interfonctionnement a été rencontré (et que ISUP n’est pas utilisé sur tout le chemin) lorsque l’ISUP encapsulé n’est pas présent ; cependant, faire ainsi peut limiter significativement l’efficacité et la transparence de la traduction SIP-ISUP.

Revendiquer d’être un nœud RNIS peut faire que l’appelé demande des services d’usager à usager. Comme les services 1 et 2 d’usager à usager vont souvent être demandés par l’appelant, cela ne pose pas de problème (voir [Q.737]). Le service 3 d’usager à usager peut être demandé aussi par le demandé. Dans des situations qui ne sont pas de pontage SIP, le MGC devrait être capable de rejeter cette demande de service.

Comme aucune réponse n’a été reçue du RTPC, toutes les ressources de la MG sont libérées. Un '504 Fin de temporisation du serveur' DEVRAIT être renvoyé au réseau SIP. Un message REL avec une valeur de cause 102 (erreur de protocole, récupération sur expiration du temporisateur) DEVRAIT être envoyé au RTPC. Les passerelles peuvent s’attendre à ce que le RTPC réponde par un RLC et que le réseau SIP réponde par un ACK indiquant que la séquence de libération s’est achevée.

Si une demande ANNULE ou BYE est reçue avant qu’ait été envoyée une réponse finale SIP, un '200 OK' DOIT être envoyé au réseau SIP pour confirmer le ANNULE ou BYE; un 487 DOIT aussi être envoyé pour terminer la transaction INVITE. Toutes les ressources sont libérées et un message REL DEVRAIT être envoyé au RTPC avec la valeur de cause 16 (Libération normale). Les passerelles peuvent s’attendre à ce qu’un RLC soit reçu de la part du RTPC, indiquant que la séquence de libération est achevée.

Dans les situations de pont SIP, un REL peut être encapsulé dans le corps d’une demande BYE. Bien que BYE soit normalement transposé en code de cause 16 (Libération normale), dans des circonstances exceptionnelles le code de cause dans le message REL peut être différent. Donc, le paramètre Indicateur de cause du REL encapsulé devrait être réutilisé dans le REL envoyé au RTPC.

Noter qu’une demande BYE ou ANNULE peut contenir un en-tête Reason qui DEVRAIT être transposé en paramètre Indicateur de cause (voir au paragraphe 5.8). Si un BYE contient à la fois un en-tête Reason et de l’ISUP encapsulé, la valeur dans l’en-tête Reason DOIT être préférée.

Toutes les ressources de la passerelle DEVRAIENT être libérées avant que la passerelle envoie un message REL.

Ce paragraphe s’applique lorsque un REL est reçu avant qu’ait été envoyée une réponse finale SIP. Normalement, cette condition survient lorsque un appel a été rejeté par le RTPC.

Toutes les ressources de la passerelle DEVRAIENT être libérées immédiatement et un RLC DOIT être envoyé au réseau ISUP pour indiquer que le circuit est disponible pour réutilisation.

Si le INVITE qui a généré cette transaction contenait un message ISUP encapsulé légitime et compréhensible (c’est-à-dire, un IAM utilisant une variante acceptée par la passerelle, de préférence avec une signature numérique) l’ISUP encapsulé DEVRAIT être envoyé dans la réponse à l’INVITE lorsque possible (car cela suggère un cas de pont ISUP-SIP-ISUP) - donc, le message REL juste reçu DEVRAIT être inclus dans le corps de la réponse SIP. La passerelle NE DEVRAIT PAS retourner une réponse avec de l’ISUP encapsulé si le générateur de l’INVITE n’a pas lui-même inclus l’ISUP.

Noter que la réception de certains messages de maintenance en réponse à l’IAM tels qu’un message Blocage (BLO) ou Rétablissement (RSC) (ou leur équivalent en message de groupe de circuits) peut aussi résulter en une suppression d’appels dans cette phase de l’automate à états. Le comportement pour les messages de maintenance est indiqué à la Section 11.

L’utilisation du message REL dans le réseau SS7 est très générale, tandis que SIP a un certain nombre d’outils spécifiques qui, collectivement, jouent le même rôle que REL – à savoir BYE, ANNULE, et les divers codes d’état/réponse. Un REL peut être envoyé pour supprimer un appel qui est déjà en cours (BYE), pour annuler une demande d’établissement d’appel envoyée précédemment qui n’a pas encore été achevée (ANNULE), ou pour rejeter une demande d’établissement d’appel (IAM) qui a juste été reçue (correspondant à un code d’état SIP).

Noter qu’il n’est pas nécessairement approprié de transposer des codes de cause RNIS en messages SIP parce que ces codes de cause n’ont de sens que pour l’interface ISUP d’une passerelle. Un bon exemple en est le code de cause 44 "Circuit ou canal de demande non disponible." 44 signifie que le CIC pour lequel un IAM a été envoyé a été estimé par l’équipement receveur être dans un état incompatible avec une nouvelle demande d’appel - cependant, le comportement approprié dans ce cas est que le commutateur d’origine renvoie l’IAM pour un CIC différent, et non pour l’appel à supprimer. En clair, il n’y a pas de code d’état SIP (et il ne devrait pas y en avoir) qui indique qu’un nouveau CIC devrait être choisi – cette question est interne à la passerelle d’origine. Donc, la réception du code de cause 44 ne devrait pas résulter en l’envoi d’un code d’état SIP ; effectivement, le code de cause est intraduisible.

Si une valeur de cause autre que celles énumérées ci-dessous est reçue, la réponse par défaut '500 Erreur interne au serveur' DEVRAIT être utilisée.

Finalement, en plus du code de cause RNIS, le paramètre CAI contient aussi une cause 'localisation' qui donne un indice sur l’entité du réseau qui était responsable de la terminaison de l’appel (la distinction la plus importante étant entre l’usager et le réseau). Dans la plupart des cas, la localisation de la cause n’affecte pas la transposition d’un code d’état SIP ; quelques exceptions sont notées ci-dessous. Un champ Diagnostic peut aussi être présent pour certaines causes RNIS ; ce diagnostic va contenir des données supplémentaires relevant de la terminaison de l’appel.

(+) Si la localisation de cause est 'usager', le code 6xx pourrait alors être donné plutôt que le code 4xx (c’est-à-dire, 403 devient 603)

(=) procédure ANSI – dans les réseaux ANSI, 26 est surchargé pour signifier 'mauvais acheminement du numéro porté'. On peut supposer qu’une recherche dans une base de données de portabilité des numéros aurait dû être effectuée par un réseau antérieur. Autrement, la cause 26 n’est pas utilisée habituellement dans les procédures ISUP.

Un REL avec la cause RNIS 22 (numéro changé) peut contenir des informations sur un nouveau numéro où l’appelé pourrait être joignable dans le champ Diagnostic. Si le MGC est capable de traiter ces informations, il DEVRAIT être ajouté à la réponse SIP (301) dans un en-tête Contact.

Cette sorte de valeur de cause indique un échec temporaire. Un en-tête 'Réessayer après' PEUT être ajouté à la réponse si approprié.

Cette sorte de valeur de cause indique qu’il y a un problème avec la demande, plutôt que quelque chose qui va se résoudre avec du temps.

102 Récupération sur expiration temporisateur 504 Fin de temporisation de passerelle

Un message ACM est envoyé dans certaines situations pour indiquer que l’appel est en cours afin de satisfaire les temporisateurs ISUP, plutôt que pour signifier que l’appelé est alerté. Cela se produit par exemple dans les réseaux mobiles, lorsque l’itinérance peut retarder significativement l’établissement de l’appel. L’ACM précoce est envoyé avant que l’usager soit alerté pour rétablir T7 et lancer T9. Un ACM est considéré comme 'ACM précoce' si l’indicateur d’état de l’appelé est réglé à 00 (pas d’indication).

Après l’envoi d’un ACM précoce, on peut supposer que le réseau ISUP va indiquer la suite des progrès de l’appel en envoyant des CPG.

Lorsque un ACM précoce est reçu, la passerelle DEVRAIT envoyer une réponse 183 Session en cours (voir la [RFC3261]) au réseau SIP. Dans les situations de pontage SIP (où l’ISUP encapsulé est contenu dans le INVITE qui a initié cet appel) l’ACM précoce DEVRAIT aussi être inclus dans le corps de réponse.

Noter qu’envoyer un 183 avant qu’une passerelle ait confirmation que l’adresse est complète (ACM) crée des problèmes connus dans les cas de pont SIP, et il NE DEVRAIT donc PAS être envoyé.

Très couramment, à réception d’un ACM, une réponse provisoire (dans la classe 18x) DEVRAIT être envoyée au réseau SIP. Si le INVITE qui a initié cette session contenait de l’ISUP encapsulé légitime et compréhensible, l’ACM reçu par la passerelle DEVRAIT alors être encapsulé dans la réponse provisoire.

Si l’ACM contient un paramètre Indicateurs d’appel vers l’arrière avec une valeur de 'abonné libre', la passerelle DEVRAIT envoyer une réponse '180 Sonnerie'. Lorsque une 180 est envoyée, on suppose que, en l’absence d’extension de support précoce, toutes les tonalités de retour d’appel nécessaires seront générées en local par l’agent d’usager SIP (qui peut à son tour être une passerelle) auquel répond la passerelle.

Si le paramètre Indicateurs d’appel vers l’arrière (BCI, Backward Call Indicators) de l’ACM indique que de l’interfonctionnement a été rencontré (signifiant généralement que le réseau ISUP qui envoie l’ACM interfonctionne avec un réseau moins sophistiqué qui ne peut pas rapporter son état via la signalisation hors bande) il peut alors y avoir des annonces dans la bande de l’état d’appel comme une tonalité d’occupation audible ou un message "aller intercept", et si possible une transmission de support vers l’arrière DEVRAIT être initiée. Le support vers l’arrière DEVRAIT aussi être transmis si le champ du paramètre facultatif Indicateurs d’appel vers l’arrière est établi pour le support dans la bande. Pour plus d’informations sur le support précoce (avant le 200 OK/ANM) voir au paragraphe 5.5. Après l’initiation de la transmission de support précoce, la passerelle DEVRAIT envoyer un code de réponse 183 Session en cours.

Les passerelles PEUVENT avoir des moyens pour certifier la disposition de support audio dans la bande; par exemple, une façon de déterminer par inspection de la signalisation dans certaines variantes ISUP, ou en écoutant l’audio, que des sonneries, ou une tonalité d’occupation, sont exécutées sur le circuit. De telles passerelles PEUVENT choisir d’éliminer le support et d’envoyer carrément le code de réponse correspondant (comme un 180 ou 486). Cependant, la mise en œuvre d’une telle passerelle devrait surmonter un certain nombre de défis connus qui sortent du domaine d’application du présent document.

Lorsque ils reçoivent un ACM, les commutateurs de nombreux réseaux ISUP lancent un temporisateur connu comme "T9" qui dure habituellement entre 90 secondes et 3 minutes (voir [Q.118]). Lorsque le support précoce est exécuté, ce temporisateur permet à l’appelant d’entendre le support audio vers l’arrière (sous la forme de tonalités ou annonces de retour d’appel) d’un commutateur distant dans le réseau ISUP pendant cette période sans incomber aucun frais pour la connexion. Le commutateur ISUP local le plus proche possible de l’appelé génère la tonalité de retour d’appel ou les annonces. Si des annonces plus longues doivent être exécutées, le réseau doit envoyer un ANM, qui initie un support bidirectionnel de durée indéfinie. Dans la pratique courante du réseau, la facturation commence lorsque l’ANM est reçu. Certains réseaux ne prennent pas en charge le temporisateur T9.

Lorsque un message ANM ou CON est reçu, il est répondu à l’appel et donc une réponse '200 OK' DEVRAIT être envoyée au réseau SIP. Ce 200 OK DEVRAIT contenir une réponse au support offert dans le INVITE. Dans les situations de pontage SIP (lorsque le INVITE qui a initié cet appel contenait de l’ISUP encapsulé légitime et compréhensible) le message ISUP est inclus dans le corps de la réponse 200 OK. Si cela n’a pas été déjà fait, la passerelle DOIT établir à ce moment un flux de support bidirectionnel.

Lorsque il y a interfonctionnement avec des réseaux traditionnels, il est possible qu’un commutateur ISUP reçoive un ANM immédiatement après un ACM précoce (sans CPG ou aucun autre message vers l’arrière) ou sans recevoir du tout d’ACM (lorsque un automate répond à l’appel). Dans cette situation, l’usager SIP n’aura jamais reçu de réponse provisoire 18x, et par conséquent n’entendra jamais aucune sorte de tonalité d’appel avant que l’appelé ne réponde. Il peut en résulter des coupures sur le support de transmission initial provenant de l’appelant (car la transmission du support vers l’avant ne peut pas commencer avant que SDP ait été acquis de la destination). Dans le RNIS (voir [Q.764]) ceci se résout en connectant le chemin vocal vers l’arrière avant d’envoyer l’IAM.

L’expiration de ce temporisateur (qui n’est pas utilisé dans tous les réseaux) signifie qu’un ANM n’est pas arrivé un moment significatif après le début de l’alerte (avec la transmission d’un ACM) pour cet appel. Habituellement, cela signifie que le terminal de l’appelé a été alerté par de nombreuses sonneries mais qu’il n’y a pas eu de réponse. Cela peut aussi se produire dans des cas d’interfonctionnement lorsque le réseau envoie une annonce d’état (comme celles qui indiquent qu’un numéro n’est pas en service) qui est passée plusieurs fois. Quelle que soit la cause de l’inachèvement prolongé de l’appel, lorsque ce temporisateur arrive à expiration, l’appel DOIT être libéré. Toutes les ressources de la passerelle qui se rapportent au chemin du support DEVRAIENT être libérées. Un code de réponse '480 Temporairement indisponible' DEVRAIT être envoyé au réseau SIP, et un message REL avec la valeur de cause 19 (pas de réponse de l’usager) DEVRAIT être envoyé au réseau ISUP. On peut s’attendre à ce que le RTPC réponde par une RLC et que le réseau SIP réponde par un ACK indiquant que la séquence de libération a été achevée.

Un CPG est un message provisoire qui peut indiquer des informations de progrès, d’alerte ou dans la bande. Si un CPG suggère que des informations dans la bande sont disponibles, la passerelle DEVRAIT commencer à transmettre le support précoce et couper à travers le chemin de support unidirectionnel vers l’arrière.

Dans des situations de pontage SIP (lorsque le INVITE qui a initié cette session contenait de l’ISUP encapsulé légitime et compréhensible) le CPG DEVRAIT être envoyé dans le corps d’une réponse 18x particulière, déterminée à partir du code d’événement CPG comme suit :

Noter que si le CPG n’indique pas "Alerte", l’état en cours ne va pas changer.

À ce stade, l’appel est pleinement connecté et la conversation peut avoir lieu. Aucun message ISUP ne devrait être envoyé par la passerelle lorsque un ACK est reçu.

Les flux d’appels suivants illustrent l’ordre des messages dans les cas normaux de réussite et d’erreur lors de l’établissement d’un appel initié du réseau RTPC. Les accusés de réception "100 En essai" aux demandes INVITE ne sont pas montrés, car leur présence est facultative.

Dans ces diagrammes, toute la signalisation d’appel (SIP, ISUP) va et vient du MGC ; le traitement du support (par exemple, raccourci audio, libération de circuit) est effectué par la MG, sous le contrôle du MGC. Pour simplifier, ils sont montrés comme un seul nœud, marqué "MGC/MG".

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le réseau RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE, et l’envoie à un nœud SIP approprié.

3. Lorsque survient un événement signifiant que l’appel a des informations d’adressage suffisantes, le nœud SIP va générer une réponse provisoire de 180 ou plus.

4. À réception d’une réponse provisoire de 180 ou plus, la passerelle va générer un message ACM. Si la réponse n’est pas 180, l’ACM va porter une valeur "État de l’appelé" de "pas d’indication."

5. Le nœud SIP peut utiliser d’autres messages provisoires pour indiquer les progrès de la session.

6. Après l’envoi d’un ACM, toutes les réponses provisoires vont se traduire en messages CPG ISUP comme indiqué au paragraphe 8.2.3.

8. À réception du message 200 OK, la passerelle va envoyer un message ANM vers le nœud ISUP.

9. La passerelle va envoyer un ACK au nœud SIP pour accuser réception de la réponse finale à INVITE.

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le réseau RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE et l’envoie à un nœud SIP approprié sur la base d’une analyse du numéro demandé.

3. Comme le nœud SIP est réglé pour répondre automatiquement à l’appel, il va envoyer un message 200 OK.

4. À réception du message 200 OK, la passerelle envoie un message CON vers le nœud ISUP.

5. La passerelle envoie un ACK au nœud SIP pour accuser réception de la réponse finale à l’INVITE.

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le réseau RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE, et l’envoie à un nœud SIP approprié sur la base de l’analyse du numéro demandé. Le temporisateur ISUP T11 et le temporisateur SIP T1 sont lancés à ce moment.

3. Le message INVITE va continuer d’être envoyé au nœud SIP chaque fois que le temporisateur T1 expire. La norme SIP spécifie que la transmission d’INVITE sera effectuée 7 fois si aucune réponse n’est reçue.

4. Lorsque T11 expire, un message ACM est envoyé au nœud ISUP pour empêcher l’appel d’être supprimé par le T7 ISUP du nœud distant. Cet ACM contient une valeur 'État de l’appelé' de 'pas d’indication.'

5. Une fois que le nombre maximum de demandes INVITE a été envoyé, la passerelle envoie un REL (code de cause 18) au nœud ISUP pour terminer l’appel.

6. La passerelle envoie aussi un message ANNULE au nœud SIP pour terminer la tentative d’initiation si une réponse provisoire a été reçue.

7. À réception du REL, le nœud ISUP distant envoie un RLC pour accuser réception.

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE, et l’envoie à un nœud SIP approprié sur la base d’une analyse du numéro demandé. Le temporisateur ISUP T11 et le temporisateur SIP T1 sont lancés à ce moment.

3. Le message INVITE va continuer d’être envoyé au nœud SIP chaque fois qu’expire le temporisateur T1. La norme SIP spécifie que la transmission de INVITE sera effectuée 7 fois si aucune réponse n’est reçue. Comme SIP T1 commence à 1/2 seconde ou plus et double chaque fois qu’il est retransmis, il va s’écouler au moins une minute avant que SIP ne périme la demande INVITE ; comme SIP T1 peut initialement être supérieur à 500 ms, il est possible que 7 x SIP T1 soit plus long que ISUP T11 + ISUP T9.

4. Lorsque T11 arrive à expiration, un message ACM va être envoyé au nœud ISUP pour empêcher que l’appel soit éliminé par le T7 ISUP du nœud distant. Cet ACM contient une valeur 'État de l’appelé' de 'Pas d’indication.'

5. Lorsque ISUP T9 arrive à expiration dans le nœud RTPC distant, il va envoyer un REL.

6. À réception du REL, la passerelle va envoyer un RLC pour accuser réception.

7. Le REL va déclancher une demande ANNULE au nœud SIP si une réponse provisoire a été reçue.

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE, et l’envoie à un nœud SIP approprié sur la base de l’analyse du numéro appelé.

3. Le nœud SIP indique une condition d’erreur par une réponse avec un code de 400 ou plus.

4. La passerelle envoie un message ACK pour accuser réception de la réponse finale à l’INVITE.

5. Un message ISUP REL est généré à partir du code SIP, comme spécifié au paragraphe 8.2.6.1.

6. Le nœud ISUP distant confirme la réception du message REL avec un message RLC.

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE, et l’envoie à un nœud SIP approprié sur la base de l’analyse du numéro appelé.

3. Le nœud SIP indique que la ressource que l’usager tente de contacter est à une localisation différente en envoyant un message 3xx. Dans cette instance, on suppose que l’URL Contact spécifie un URL valide joignable par un appel SIP VoIP.

4. La passerelle envoie un CPG avec l’indication d’événement que l’appel est transmis à réception du message 3xx. Noter que cette traduction devrait pouvoir être désactivée par configuration, car certains nœuds ISUP n’acceptent pas la réception de messages CPG avant des messages ACM.

5. La passerelle accuse réception de la réponse finale à l’INVITE en envoyant un message ACK au nœud SIP.

6. La passerelle renvoie le message INVITE à l’adresse indiquée dans le champ Contact: du message 3xx.

7. Lorsque survient un événement signifiant que l’appel a des informations d’adressage suffisantes, le nœud SIP va générer une réponse provisoire de 180 ou plus.

8. À réception d’une réponse provisoire de 180 ou plus, la passerelle va générer un message ACM avec un code d’événement comme indiqué au paragraphe 8.2.3.

10. À réception du message 200 OK, la passerelle va envoyer un message ANM vers le nœud ISUP.

11. La passerelle va envoyer un ACK au nœud SIP pour accuser réception de la réponse finale à l’INVITE.

1. Lorsque un usager RTPC souhaite commencer une session avec un usager SIP, le RTPC génère un message IAM vers la passerelle.

2. À réception du message IAM, la passerelle génère un message INVITE, et l’envoie à un nœud SIP approprié sur la base de l’analyse du numéro demandé.

3. Lorsque survient un événement signifiant que l’appel a des informations d’adressage suffisantes, le nœud SIP génère une réponse provisoire de 180 ou plus.

4. À réception d’une réponse provisoire de 180 ou plus, la passerelle va générer un message ACM avec un code d’événement comme indiqué au paragraphe 8.2.3.

5. Si l’appelant raccroche avant que le nœud SIP réponde à l’appel, un message REL sera généré.

6. La passerelle libère le circuit RTPC et indique qu’elle est disponible pour une réutilisation en envoyant un RLC.

7. À réception d’un message REL avant une réponse finale à l’INVITE, la passerelle va envoyer un ANNULE vers le nœud SIP si une réponse provisoire a été reçue.

9. Le nœud SIP distant va envoyer un "487 Appel annulé" pour terminer la transaction INVITE.

10. La passerelle va envoyer un ACK au nœud SIP pour accuser réception de la réponse finale à l’INVITE.

Noter que REL peut arriver dans tout état. Chaque fois que cela se produit, les actions du paragraphe 8.2.7. sont entreprises. Ces transitions ne sont pas toutes montrées dans ce diagramme.

À réception d’un IAM, la passerelle DEVRAIT réserver les ressources internes appropriées (Processeurs à signal numérique (DSP, Digital Signal Processor) – et autres) nécessaires pour le traitement du côté IP de l’appel. Elle PEUT faire toutes les préparations nécessaires pour connecter l’audio dans la direction inverse (vers l’appelant).

Lorsque un IAM arrive à une passerelle RTPC-SIP, un message SIP INVITE DOIT être créé pour transmission au réseau SIP. Ce paragraphe détaille le processus par lequel une passerelle remplit les champs de l’INVITE sur la base des paramètres trouvés dans l’IAM.

Le contexte de la demande d’établissement d’appel lu par la passerelle dans l’IAM sera transposé principalement en deux URI dans l’INVITE, un représentant l’origine de la session et l’autre sa destination. Le premier va toujours apparaître dans l’en-tête From (après qu’il a été converti du format ISUP par la procédure décrite à la Section 12) et le dernier est presque toujours utilisé pour les deux en-têtes To et URI de demande.

Une fois que l’adresse du numéro de la partie appelée a été lue de l’IAM, elle DEVRAIT être traduite en un URL tel de destination qui va servir comme URI de demande de l’INVITE. Autrement, une passerelle PEUT d’abord tenter une interrogation de transposition de numéro de téléphone (ENUM) [RFC2916] pour résoudre le numéro de la partie appelée en un URI. Des champs ISUP supplémentaires PEUVENT être ajoutés à l’URL tel après l’achèvement de la traduction, à savoir :

o Si la passerelle accepte l’acheminement fondé sur le transporteur (qui est facultatif dans cette spécification) elle DEVRAIT assurer si le paramètre CIP (dans les réseaux ANSI) ou TNS est présent dans l’IAM. Si une valeur est présente, le CIC DEVRAIT être extrait du paramètre en question et analysé par la passerelle. Un champ 'cic=' avec la valeur de CIC DEVRAIT être ajouté à l’URL tel de destination, si cette pratique est conforme à la politique locale (c’est-à-dire, pourvu que le CIC n’indique pas le réseau qui possède la passerelle ou quelque condition similaire). Noter que si il est créé, le paramètre 'cic=' DOIT être ajouté en préfixe au code de pays utilisé ou impliqué dans le numéro de l’appelé, de sorte que CIC '5062' devient, aux États Unis, '+1-5062'. Pour plus d’informations sur le champ d’URL 'cic=' tel, voir [RFC4694].

o Si la passerelle prend en charge l’acheminement fondé sur la portabilité du numéro (qui est facultative dans la présente spécification) la passerelle devra alors chercher quelques autres champs. Pour transposer correctement le bit FCI 'numéro traduit' qui indique qu’une recherche de LNP a été effectuée dans le RTPC, un champ 'npdi=oui' DEVRAIT être ajouté à l’URL tel. Si un GAP est présent dans l’IAM, le contenu du CPN (le numéro d’acheminement de localisation (LRN, Location Routing Number) DEVRAIT être traduit du format ISUP (comme décrit à la Section 12) et copié dans un champ 'rn=' qui doit être ajouté à l’URL tel, tandis que le GAP lui-même devrait être traduit au format ISUP et utilisé pour remplir le champ Numéro de téléphone principal de l’URL tel. Noter que dans certains plans de numérotage nationaux, le LRN et le numéro composé peuvent tous deux être mémorisés dans le paramètre CPN, auquel cas ils doivent être séparés dans des champs différents pour être mémorisés dans l’URL tel. Noter que les LRN sont nécessairement nationaux dans leur portée, et par conséquent, ils NE DOIVENT PAS être précédés par un '+' dans le champ 'rn='. Pour d’autres informations sur ces champs d’URL tel , voir la [RFC4694].

Dans la plupart des cas, l’URL tel de destination résultant DEVRAIT être utilisé dans les deux champs To et URI de demande envoyés par la passerelle. Cependant, si le paramètre OCN est présent dans l’IAM, le champ To DEVRAIT être construit à partir de la traduction (du format ISUP suivant la Section 12 du paramètre OCN) et donc l’URI de demande et le champ To PEUVENT être différents.

La construction du champ d’en-tête From dépend de la présence d’un paramètre CIN. Si le CIN n’est pas présent, la passerelle DEVRAIT alors créer un champ d’en-tête From factice contenant un URI SIP sans portion usager qui ne communique que le nom d’hôte de la passerelle (par exemple, 'sip:gw.sipcarrier.com). Si le CIN est disponible, il DEVRAIT alors être traduit (conformément à la procédure décrite ci-dessus) en un URL tel qui devrait remplir le champ d’en-tête From. Dans l’un et l’autre cas, la politique locale ou les demandes de restriction de présentation (voir au paragraphe 12.1) PEUVENT résulter en une valeur différente pour le champ d’en-tête From.

Une réponse 100 NE DEVRAIT PAS déclancher de message d’interfonctionnement RTPC ; elle ne sert que pour les besoins de la suppression des retransmissions d’INVITE.

À réception d’une réponse provisoire 18x, si aucun ACM n’a été envoyé et si aucun ISUP légitime et compréhensible n’est présent dans le corps de message 18x, le message ISUP DEVRAIT alors être généré conformément au tableau qui suit. Noter que si un ACM précoce est envoyé, l’appel DOIT entrer dans l’état "En cours" plutôt que dans l’état "Alerte."

180 Sonnerie ACM (BCI = abonné libre)181 Appel en cours ACM précoce et CPG, événement=6

Si un ACM a déjà été envoyé et si aucun ISUP n’est présent dans le corps de message 18x, un message ISUP DEVRAIT être généré conformément au tableau suivant :

À réception d’une réponse 180, la passerelle DEVRAIT générer la tonalité de retour d’appel pour qu’elle soit entendue par l’appelant sur le côté RTPC (sauf si la passerelle sait que le retour d’appel sera fourni par le réseau sur le côté RTPC).

Noter cependant qu’une passerelle peut recevoir le support à tout moment après qu’elle a transmis une offre de SDP qu’elle a envoyée dans un INVITE, même avant de recevoir une réponse provisoire 18x. Donc, la passerelle DOIT être prête à exécuter ce support à l’appelant sur le côté RTPC (si nécessaire, en cessant toute tonalité de retour d’appel qu’elle pourrait avoir commencé à générer et en exécutant le support). Noter que la passerelle peut aussi recevoir des offres de SDP en réponse à une session de support précoce utilisant une extension SIP, voir au paragraphe 5.5. Si une passerelle reçoit une réponse 183 alors qu’elle exécute un support vers l’arrière, alors lorsque elle génère une transposition pour cette réponse, si il n’y a pas d’ISUP encapsule, la passerelle DEVRAIT indiquer que des informations dans la bande sont disponibles (par exemple, avec le paramètre Informations d’événement du message CPG ou le paramètre Indicateurs d’appel vers l’arrière facultatif de l’ACM).

Lorsque un ACM est envoyé, le paramètre obligatoire Indicateurs d’appel vers l’arrière doit être établi, ainsi que tous les paramètres facultatifs qu’impose la politique de la passerelle. Si de l’ISUP légitime et compréhensible est présent dans la réponse 18x, la passerelle DEVRAIT réutiliser les paramètres appropriés du message ISUP contenus dans le corps de réponse, y compris la valeur du paramètre Indicateur d’appel vers l’arrière, car il formule un message qu’il va envoyer à travers son interface RTPC. En l’absence d’un ACM encapsulé utilisable, le paramètre BCI DEVRAIT être réglé comme suit :

Indicateur d’informations de bout en bout : 0 Pas d’informations de bout en bout

Noter que lorsque le champ d’indicateur d’interfonctionnement ISUP Paramètre d’indicateur d’appel vers l’arrière est réglé à 'Interfonctionnement rencontré', cela indique que le RNIS interfonctionne avec un réseau qui n’est pas capable de fournir autant de services que le RNIS. ISUP peut donc ne pas employer certaines caractéristiques qu’autrement il utiliserait normalement. Les fabricants de passerelles PEUVENT cependant fournir une option configurable, utilisable à la discrétion des fournisseurs de service lorsque ils ont besoin de services ISUP supplémentaires, ce qui en l’absence d’ISUP encapsulé va signaler dans le BCI que de l’interfonctionnement a été rencontre, et que l’ISUP n’est pas utilisé tout le long du chemin, pour les opérateurs qui en matière de politique vont plutôt fonctionner dans ce mode. Pour plus d’informations sur les effets de l’interfonctionnement, voir au paragraphe 7.2.1.1.

Après réception d’une réponse 200 OK, la passerelle DOIT établir un chemin de support directionnel dans la passerelle et envoyer un ANM au RTPC ainsi qu’un ACK au réseau SIP.

Si la réponse 200 OK arrive avant que la passerelle ait envoyé un ACM, un CON est envoyé à la place de l’ANM, dans les variantes ISUP qui prennent en charge le message CON.

Lorsque un ANM légitime et compréhensible est encapsulé dans la réponse 200 OK, la passerelle DEVRAIT réutiliser tous les paramètres ISUP pertinents dans l’ANM qu’elle envoie au RTPC.

Noter que les passerelles peuvent parfois recevoir des réponses 200 OK pour des demandes autres que INVITE (par exemple, celles utilisées pour la gestion des réponses provisoires, ou la méthode INFO). Les procédures décrites dans ce paragraphe ne s’appliquent qu’aux réponses 200 OK reçues par suite de l’envoi d’un INVITE. La passerelle NE DEVRAIT PAS envoyer de message RTPC si elle reçoit un 200 OK en réponse à des demandes non INVITE qu’elle a envoyées.

Lorsque une réponse 3xx (redirection) est reçue, la passerelle DEVRAIT essayer d’atteindre la destination en envoyant une ou plusieurs nouvelles demandes d’établissement d’appel en utilisant les URI trouvés dans tous champs d’en-tête Contact présents dans la réponse, comme y oblige la spécification SIP de base. De telles réponses 3xx sont normalement envoyées par un serveur de redirection, et peuvent être vues comme similaires à un registre de localisation dans les réseaux RTPC mobiles.

Si un URL particulier présenté dans l’en-tête Contact d’une réponse 3xx est mieux accessible (selon les politiques d’acheminement de la passerelle) via le RTPC, la passerelle DEVRAIT envoyer un nouvel IAM et à partir de ce moment agir comme un commutateur RTPC normal (pas de SIP impliqué) – usuellement, ce sera le cas lorsque l’URI dans l’en-tête Contact est un URL tel, que la passerelle ne peut atteindre en local et pour lequel il n’y a pas de transposition ENUM.

Autrement, la passerelle PEUT envoyer un message REL au RTPC avec un indicateur de redirection (23) et un champ diagnostic correspondant au numéro de téléphone dans l’URI. Si, cependant, la nouvelle localisation est mieux accessible en utilisant SIP (si l’URI dans l’en-tête Contact ne contient pas de numéro de téléphone du tout) le MGC DEVRAIT envoyer un nouvel INVITE avec un URI de demande et éventuellement un nouvel IAM généré par le MGC dans le corps de message.

Pendant qu’elle explore une longue liste d’en-têtes Contact avec les demandes SIP, une passerelle PEUT envoyer un message CPG avec un code d’événement de 6 (Transmission) au RTPC afin d’indique que l’appel se poursuit (lorsque c’est permis par la variante ISUP en question).

Toutes les situations de redirection ont été traitées avec le plus grand soin car elles impliquent des situations de tarification très particulières. Dans le RTPC l’appelant paye normalement la première branche (jusqu’à la passerelle) et l’appelé paye la seconde (du commutateur de retransmission jusqu’à la destination).

Lorsque un code de réponse de 400 ou plus est reçu par la passerelle, le INVITE précédemment envoyé par la passerelle a alors été rejeté. Dans la plupart des circonstances, la passerelle DEVRAIT libérer les ressources dans la passerelle, envoyer un REL au RTPC avec une valeur de cause et envoyer un ACK au réseau SIP. Certaines circonstances particulières sont identifiées ci-dessous dans lesquelles une passerelle PEUT tenter de rectifier un problème spécifique de SIP communiqué par un code d’état sans libérer l’appel en réessayant la demande. Lorsque un REL est envoyé au RTPC, la passerelle s’attend à l’arrivée d’un RLC indiquant que la séquence de libération est achevée.

Lorsque un message REL est généré à cause d’une réponse SIP de rejet qui contient un message REL encapsulé, le paramètre Indicateur de cause (CAI, Cause Indicator) dans le REL généré DEVRAIT être réglé à la valeur du paramètre CAI reçu dans le REL encapsulé. Si aucun ISUP encapsulé n’est présent, la transposition ci-dessous entre code d’état et code de cause est RECOMMANDÉE.

Tous les codes d’état SIP qui ne sont pas cités ci-dessous (associés à des extensions SIP, des versions de SIP ultérieures à la publication du présent document, ou simplement omises) devraient se transposer en le code de cause 31 "Normal, non spécifié". Ces transpositions ne couvrent que les réponses ; noter que les demandes BYE et ANNULE, qui sont aussi utilisées pour supprimer un dialogue, DEVRAIENT être transposées en 16 "Suppression normale" dans la plupart des circonstances (voir cependant au paragraphe 5.8).

Par défaut, la localisation de cause associée au paramètre CAI devrait être codée de telle façon que les codes 6xx reçoivent la localisation 'usager', tandis que les codes 4xx et 5xx reçoivent la localisation 'réseau'. Les exceptions sont marquées ci-dessous.

Tout comme il y a certains codes de cause RNIS qui sont spécifiques de l’ISUP et n’ont pas de corollaire en action SIP, il y a des codes d’état SIP qui ne devraient tout simplement pas être traduits en ISUP – certaines actions spécifiques de SIP devraient être tentées d’abord. Voir la note sur l’étiquette (+) ci-dessous.

408 Fin de temporisation de la demande 102 Récupération après expiration du temporisateur

504 Fin de temporisation de serveur 102 Récupération après expiration du temporisateur

(*) Dans certains cas, il est possible qu’une passerelle SIP fournisse des accréditifs à l’UAS SIP qui rejette un INVITE à cause d’un échec d’autorisation. Si la passerelle peut s’authentifier, elle DEVRAIT évidement le faire et poursuivre l’appel ; c’est seulement si la passerelle ne peut pas s’authentifier que le code de cause 21 devrait être envoyé.

(+) Si c’est possible, une passerelle SIP DEVRAIT répondre à ces erreurs de protocole en remédiant aux comportements inacceptables et en tentant de générer à nouveau la session. C’est seulement si cela se révèle impossible que la passerelle SIP devrait faire échouer la moitié ISUP de l’appel.

Lorsque l’en-tête Avertissement (Warning) est présent dans un message SIP 606 ou 488, il peut y avoir des transpositions de code de cause spécifiques du RNIS appropriées au code Avertissement. Le présent document recommande que '31 Normal, non spécifié' DEVRAIT être utilisé par défaut pour la plupart des codes d’avertissement actuellement affectés. Si le code d’avertissement s’adresse à une capacité support indisponible, le code de cause '65 Capacité support non mise en œuvre' est une transposition RECOMMANDÉE.

Cette circonstance survient généralement lorsque l’utilisateur du côté RTPC raccroche avant que l’appel ait reçu une réponse ; la passerelle interrompt donc l’établissement de la session. Une demande ANNULE DOIT être produite (un BYE n’est pas utilisé, car aucune réponse finale n’est arrivée du côté SIP). Un 200 OK pour le ANNULE peut être attendu par la passerelle, et finalement un 487 arrive pour l’INVITE (dont la passerelle accuse réception à son tour).

La passerelle DEVRAIT mémoriser les informations d’état en rapport avec ce dialogue pendant un certain temps, car une réponse finale 200 pour l’INVITE envoyé à l’origine pourrait arriver (même après la réception du 200 OK pour l’ANNULE). Dans cette situation, la passerelle DOIT envoyer un ACK suivi par une demande BYE appropriée.

Dans les situations de pontage SIP, le message REL ne peut pas être encapsulé dans un message ANNULE (car ANNULE ne peut pas avoir un corps de message). Usuellement, le message REL va contenir une valeur de CAI de 16 "Libération normale". Si la valeur est autre que 16, la passerelle PEUT souhaiter utiliser d’autres moyens de communiquer la valeur de cause (voir au paragraphe 5.8).

Afin d’empêcher le temporisateur T7 du nœud ISUP distant d’arriver à expiration, la passerelle PEUT conserver son propre temporisateur de supervision ; ISUP définit ce temporisateur comme T11. La durée de T11 est soigneusement choisie afin qu’il soit toujours plus court que le T7 de tout nœud avec lequel la passerelle communique.

Pour préciser la pertinence du temporisateur T11 par rapport à l’interfonctionnement avec SIP, [Q.764] explique son utilisation comme suit : "Si en fonctionnement normal, on s’attend à un délai dans la réception d’un signal d’adresse complète de la part du réseau suivant, le dernier commutateur de signalisation de canal commun va générer et envoyer un message d’adresse complète 15 à 20 secondes [temporisateur (T11)] après avoir reçu le dernier message d’adresse." Comme les nœuds SIP n’ont pas l’obligation de répondre à une demande INVITE dans les 20 secondes, l’interfonctionnement SIP qualifie indiscutablement une telle situation.

Si la passerelle accepte ce mécanisme facultatif, et si T11 arrive alors à expiration, elle DEVRAIT envoyer un ACM précoce (c’est-à-dire, l’état du demandé réglé à "Pas d’indication") pour empêcher l’expiration du T7 du nœud distant (lorsque c’est permis par la variante ISUP). Voir au paragraphe 8.2.3 la valeur des paramètres d’ACM.

Si un message "180 Sonnerie" arrive ensuite, il DEVRAIT être envoyé dans un CPG, comme indiqué au paragraphe 8.2.3.

Voir au paragraphe 8.1.3 un exemple de flux d’appels qui comporte l’expiration de T11.

Dans les réseaux RNIS, un usager peut générer un SUS (temporisateur T2, à l’initiative de l’usager) afin de déconnecter le terminal de la prise et de le connecter à une autre. Un RES est envoyé une fois que le terminal a été reconnecté et que le temporisateur T2 n’est pas arrivé à expiration. SUS est aussi fréquemment utilisé pour signaler un état raccroché pour un terminal distant avant que soient lancés les temporisateurs conduisant à la transmission d’un message REL (ceci est de loin le cas le plus courant). Pendant qu’un appel est suspendu, aucun support audio n’est passé de bout en bout.

Lorsque un SUS est envoyé pour un appel qui a une branche SIP, une passerelle PEUT suspendre la transmission du support IP jusqu’à ce qu’un RES soit reçu. Mettre le support en garde assure que la bande passante est conservée lorsque du trafic audio n’a pas besoin d’être transmis.

Si la suspension du support est appropriée, lorsque un SUS arrive alors du RTPC, le MGC PEUT envoyer un INVITE pour demander que la transmission de l’extrémité distante du flux de support soit placée en garde. La réception ultérieure d’un RES venant du RTPC DEVRAIT alors déclancher un nouvel INVITE qui demande la reprise du flux de supports. Noter que le MGC peut choisir d’arrêter ou non lui-même la transmission de tout support lorsque il demande la cessation de la transmission à l’extrémité distante.

Si la suspension du support n’est pas exigée par le MGC qui reçoit le SUS du RTPC, la méthode SIP INFO [RFC2976] PEUT être utilisée pour transmettra un SUS encapsulé plutôt qu’un re-INVITE. Noter que le receveur d’une telle demande INFO peut être un simple téléphone SIP qui ne comprend pas ISUP (et ne prendrait donc aucune action à réception de ce message) ; si une destination éventuelle pour un SUS encapsulé dans INFO n’a pas utilisé d’ISUP encapsulé dans les messages qu’elle a envoyé précédemment, la passerelle NE DEVRAIT PAS s’appuyer sur la méthode INFO, mais devrait plutôt traiter le SUS et le RES correspondant sans signaler leur arrivée au réseau SIP.

Dans tous les cas, les messages RES suivants DOIVENT être transmis avec la même méthode que celle utilisée pour le SUS correspondant (c’est-à-dire, si un INFO est utilisé pour un SUS, INFO devrait aussi être utilisé pour le RES suivant).

Sans considération de l’utilisation du mécanisme INFO ou re-INVITE utilisé pour porter un message SUS, aucun n’a pour implication que le côté d’origine va cesser d’envoyer le support IP. Le receveur d’un message SUS encapsulé PEUT donc choisir d’envoyer lui-même un re-INVITE pour suspendre la transmission de supports à partir du côté MGC si il le désire.

L’exemple suivant utilise le mécanisme INVITE. Noter que ce flux est informatif, et non prescriptif ; les passerelles conformes sont libres de mettre en œuvre des flux fonctionnellement équivalents, comme décrit aux paragraphes précédents.

Le traitement d’un SUS initié par le réseau immédiatement avant la suppression de l’appel est traitée au paragraphe 10.2.2.

Après qu’un appel a été connecté, un re-INVITE pourrait être envoyé à une passerelle depuis le côté SIP afin de placer l’appel en garde. Ce re-INVITE va avoir une offre SDP indiquant que l’origine du re-INVITE ne souhaite plus recevoir le support.

Lorsque un tel re-INVITE est reçu, la passerelle DEVRAIT envoyer un CPG afin d’exprimer que l’appel a été placé en garde. Le CPG DEVRAIT contenir un indicateur de notification générique (ou, dans les réseaux ANSI, un indicateur de notification) avec une valeur de 'distant en garde'.

Si, suite à l’envoi du re-INVITE, le côté SIP souhaite reprendre l’extrémité distante et recommencer à recevoir les supports, il DEVRAIT répéter le flux ci-dessus avec un INVITE contenant une offre SDP avec une destination de support appropriée. L’indicateur de notification générique aurait dans cette instance une valeur de 'restitution distante' (ou dans certaines variantes 'garde libérée à distance').

Finalement, on note qu’un CPG avec des indicateurs de garde peut être reçu par une passerelle depuis le RTPC. Dans l’intérêt de la conservation de la bande passante, la passerelle DEVRAIT arrêter d’envoyer des supports jusqu’à ce que l’appel soit repris et DEVRAIT envoyer un re-INVITE à la branche SIP de l’appel demandant que le côté distant arrête l’envoi des supports.

Du point de vue d’une passerelle, le côté SIP ou le côté ISUP peut libérer un appel, sans considération du côté qui a initié l’appel. Noter que l’annulation d’une demande d’établissement d’appel (du côté ISUP ou du côté SIP) est discutée ailleurs dans ce document (respectivement aux paragraphes 8.2.7 et 7.2.3).

Les passerelles DEVRAIENT mettre en œuvre l’équivalence fonctionnelle avec les flux de cette section.

Pour une terminaison normale du dialogue (réception d’une demande BYE) la passerelle DOIT envoyer immédiatement une réponse 200. La passerelle DOIT alors libérer toutes les ressources de support dans la passerelle (DSP, verrous TCIC, et ainsi de suite) et envoyer un REL avec un code de cause de 16 (libération d’appel normale) au RTPC. La libération des ressources est confirmée par le côté RTPC avec un message RLC.

Dans les situations de pontage SIP, le code de cause de tout REL encapsulé dans la demande BYE DEVRAIT être réutilisé dans tout REL que la passerelle envoie au RTPC.

Si la libération de la connexion était causée par la réception d’un REL, le REL DEVRAIT être encapsulé dans le BYE envoyé par la passerelle. Que l’appelant ou l’appelé raccroche en premier, la passerelle DEVRAIT libérer toutes les ressources internes utilisées pour l’appel et DOIT ensuite confirmer que le circuit est prêt à être réutilisé par l’envoi d’un RLC.

Lorsque l’appelant raccroche, le dialogue SIP DOIT se terminer par l’envoi d’une demande BYE (qui est confirmée par un 200).

Dans certains scénarios RTPC, si l’appelé raccroche au milieu d’un appel, le commutateur local envoie un SUS au lieu d’un REL et lance un temporisateur (T6, SUS est à l’initiative du réseau). Lorsque le temporisateur arrive à expiration, le REL est envoyé. Cela nécessite un flux SIP légèrement différent ; voir à la Section 9 des informations supplémentaires sur le traitement de la suspension. Il est RECOMMANDÉ que les passerelles mettent en œuvre une équivalence fonctionnelle avec le flux suivant dans ce cas :

ISUP contient un ensemble de messages utilisés pour les besoins de la maintenance. Ils peuvent être reçus durant tout appel en cours. Il y a principalement deux sortes de messages de maintenance (à part la vérification de continuité) : les messages pour bloquer les circuits et les messages pour rétablir les circuits.

À réception d’un message RSC pour un circuit actuellement utilisé par la passerelle pour un appel, l’appel DOIT être libéré immédiatement (cela résulte normalement d’une condition de maintenance sérieuse). Il DOIT être répondu au RSC par un RLC après le rétablissement du circuit dans la passerelle. Il est répondu aux messages Rétablissement de groupe (GRS, Group reset) qui ciblent une gamme de circuits par un message Accusé de réception de rétablissement de groupe de circuits (GRA, Circuit Group Reset ACK) après le rétablissement de tous les circuits affectés par le message.

Les passerelles DEVRAIENT se comporter comme si un REL avait été reçu afin de libérer le dialogue sur le côté SIP. Un BYE ou un ANNULE sont envoyés, selon l’état de l’appel. Voir les procédures à la Section 10.

Il y a deux sortes de messages de blocage : les messages de maintenance et les messages de défaillance de matériel. Les messages de blocage de maintenance indiquent que le circuit doit être bloqué pour tous les appels suivants, mais ces messages n’affectent aucun appel en cours. Cela permet que les circuits soient graduellement réduits au silence et retirés du service pour leur maintenance.

Les messages de blocage en relation avec le matériel doivent être traités comme des messages de réinitialisation. Ils sont généralement envoyés seulement lorsque est survenue une panne matérielle. La transmission des supports pour tous les appels en cours sur ces circuits serait affectée par cette condition matérielle, et donc tous les appels doivent être immédiatement libérés.

BLO concerne toujours la maintenance et la passerelle y répond par un message d’accusé de réception de blocage (BLA, Blocking ACK) lorsque le circuit est bloqué – cela n’exige pas d’action correspondante de SIP. Les messages de blocage de circuit de groupe (CGB, Circuit Group Blocking) ont un "indicateur de type" à l’intérieur de l’indicateur de type de message de supervision de groupe de circuit. Il indique si le CGB concerne la maintenance ou la défaillance du matériel. Si le CGB résulte d’une défaillance de matériel, alors chaque appel en cours dans la gamme de circuits affectée DOIT être immédiatement terminée comme si un REL avait été reçu, suivant les procédures de la Section 10. On DOIT répondre aux CGB avec des accusés de réception de blocage de circuit de groupe (CGBA).

Une vérification de continuité est un essai effectué sur un circuit qui implique la réflexion d’une tonalité générée au commutateur d’origine par une boucle de retour au commutateur de destination. Deux variantes de la vérification de continuité apparaissent dans ISUP : la demande implicite de vérification de continuité au sein d’un IAM (auquel cas la vérification de continuité a lieu comme précondition avant le début de l’établissement de l’appel) et la vérification explicite de continuité signalée par un message de demande de vérification de continuité (CCR, Continuity Check Request). Les passerelles RTPC dans des régions qui prennent généralement en charge la vérification de continuité DEVRAIENT avoir un moyen pour s’accommoder de ces essais (si elles espèrent être utilisées par des fournisseurs qui s’interconnectent avec des transporteurs majeurs).

Lorsque un CCR est reçu par une passerelle RTPC-SIP, la passerelle NE DEVRAIT PAS envoyer de message SIP correspondant ; la portée de la vérification de continuité ne s’applique qu’aux circuits RTPC, et non aux chemins de supports IP au delà de la passerelle. Les messages CCR ne désignent non plus aucun numéro demandé, ni ne déterminent en aucune façon quel serveur d’agent d’utilisateur SIP devrait être joint.

Lorsque est reçu un IAM avec le fanion Indicateur d’essai de continuité établi au sein du paramètre NCI, la passerelle DOIT traiter la vérification de continuité avant d’envoyer un message INVITE (et de poursuivre normalement avec l’établissement d’appel) ; si la vérification de continuité échoue (un COT avec l’indicateur de continuité de 'échec' est reçu) un INVITE NE DOIT alors PAS être envoyé.

Les serveurs mandataires SIP PEUVENT acheminer les messages SIP sur tout critère de signalisation désiré par les administrateurs de réseau, mais généralement l’URI de demande est le critère d’acheminement le plus utilisé. Les en-têtes To et From sont aussi fréquemment intéressants pour prendre les décisions d’acheminement. La transposition SIP-ISUP suppose que les serveurs mandataires sont intéressés par au moins ces trois champs des messages SIP, qui contiennent tous des URI.

La transposition SIP-ISUP exige fréquemment la représentation de numéros de téléphone dans ces URI. Dans certaines instances, ces numéros vont être présentés en premier dans les messages ISUP, et les passerelles SS7-SIP vont avoir besoin de traduire le format ISUP de ces numéros en URI SIP. Dans d’autres cas, la transformation inverse sera requise.

Le format le plus commun utilisé dans SIP pour la représentation des numéros de téléphone est l’URI tel [RFC2806]. Lors de la conversion entre formats, l’URI tel PEUT constituer la totalité d’un champ d’URI dans un message SIP, ou il PEUT apparaître comme la portion utilisateur d’un URI SIP. Par exemple, un champ To pourrait apparaître comme :

Qu’une passerelle ou point d’extrémité particulier doive ou non formuler les URI dans le format tel ou SIP est une affaire de politique administrative locale – si la présence d’une portion hôte devait aider le réseau environnant à acheminer les appels, le format SIP devrait être utilisé. Une passerelle DOIT accepter de ses homologues les URI tel ou SIP.

Le signe '+' précédant le numéro dans les URL tel indique que les chiffres qui suivent constituent un numéro [E.164] pleinement qualifié ; essentiellement, cela signifie qu’un code de pays est fourni devant tout code de zone national spécifique, code de commutateur/ville, ou code d’adresse. L’absence d’un signe '+' PEUT signifier que le numéro est simplement significatif nationalement, ou peut-être qu’un plan de numérotage privé est utilisé. Lorsque le signe '+' est absent, mais qu’un numéro de téléphone est représenté par la portion utilisateur de l’URI, l’URI SIP DEVRAIT contenir le paramètre facultatif ';user=phone' ; par exemple,

Cependant, il est fortement RECOMMANDÉ que seuls les numéros E.164 internationalement significatifs soient passés entre les passerelles SIP-T, en particulier lorsque de telles passerelles sont dans des régions différentes ou des domaines administratifs différents. Dans de nombreux réseaux SIP-T, sinon tous ; les passerelles ne sont pas responsables de l’acheminement de bout en bout des appels SIP ; en pratique, les passerelles n’ont aucun moyen de savoir si l’appel va aboutir dans un domaine et/ou région administratif local ou distant, et donc les passerelles DEVRAIENT toujours supposer que les appels exigent un plan de numérotage international. Il n’est pas garanti que les receveurs de signalisation SIP seront capables de comprendre les plans de numérotage nationaux utilisés par les générateurs des appels – si la passerelle génératrice n’internationalise pas la signalisation, le contexte dans lequel les chiffres ont été numérotés ne peut pas être extrapolé par les éléments de réseau distant.

Dans la signalisation ISUP, un numéro de téléphone apparaît dans un format commun qui est utilisé dans plusieurs paramètres, incluant le CPN et le CIN ; lorsque il représente le numéro de l’appelant il arbore des informations supplémentaires (précisées ci-dessous). Pour les besoins du présent document, on se réfèrera à ce format sous le nom de 'format ISUP' – si les informations supplémentaires sur l’appelant sont présentes, le format sera appelé 'format d’appel ISUP'. Le format consiste en un octet appelé Indicateur de nature de l’adresse (INA) suivi par un autre octet qui contient l’indicateur de plan de numérotage (NPI, Numbering Plan Indicator) ; tous deux sont préfixés à une série d’octets de longueur variable qui contient les chiffres du numéro de téléphone en format décimal codé en binaire (BCD, Binary Coded Decimal). Dans le cas du numéro de l’appelant, l’octet de NPI contient aussi des champs de bits qui représentent les préférences de présentation de l’appelant et l’état de toutes les vérifications d’affichage d’appel effectuées jusqu’à ce point de l’appel.

Le champ NPI est généralement réglé à la valeur 'Plan de numérotage (téléphonie) RNIS (Recommandation E.164)' mais cela ne signifie pas que les chiffres qui suivent contiennent nécessairement un code de pays ; le champ INA impose si le numéro de téléphone est en format national ou international. Lorsque le numéro représenté n’est pas conçu comme un format international, l’INA donne généralement des informations spécifiques du plan de numérotation national - sur la base de ces informations, on peut généralement déterminer comment convertir le numéro en question en un format international. Noter que si le NPI contient une valeur autre que 'Plan de numérotage RNIS', l’URI tel peut alors ne pas convenir pour porter les chiffres de l’adresse, et le traitement de tels appels sort du domaine d’application du présent document.

Sur la base de ce qui est dit ci-dessus, la conversion du format ISUP en URL tel est comme suit. D’abord, pourvu que le champ NPI indique que le format du numéro de téléphone utilise E.164, le INA est consulté. Si le INA indique que le numéro est un numéro international, alors les chiffres du numéro de téléphone DEVRAIENT être ajoutés non modifiés à une chaîne 'tel:+'. Si le INA a la valeur 'numéro national (significatif)', alors un code de pays DOIT être ajouté en préfixe aux chiffres du numéro de téléphone avant qu’ils soient affectés à un URL tel ; si la passerelle qui effectue cette conversion s’interconnecte avec des commutateurs résidants sur plusieurs codes de pays différents, le code de pays approprié DEVRAIT vraisemblablement être choisi sur la base du commutateur ou groupe de circuits d’origine. Si le INA a la valeur de 'numéro d’abonné', on PEUT devoir ajouter à la fois un code de pays et tous les autres composants de numérotation nécessaires pour le plan de numérotation en question (comme des codes de zones ou de villes) afin que le numéro soit internationalement significatif - cependant, de telles procédures varient beaucoup d’un pays à l’autre, et donc ne peuvent pas être spécifiés ici en détail. C’est seulement si un code de pays ou une valeur spécifique d’un réseau est utilisé pour l’INA qu’un URL tel NE DEVRAIT PAS inclure un signe '+' ; dans ces cas, les passerelles DEVRAIENT simplement copier les chiffres fournis dans l’URL tel et ajouter un paramètre 'user=phone' si un format d’URI SIP est utilisé. Tous les mécanismes non standard ou propriétaires utilisés pour communiquer plus de contexte pour l’appel dans ISUP sortent du domaine d’application du présent document.

Si est présent un paramètre spécifique national qui permet la transmission du nom de l’appelant (comme le paramètre générique de nom dans l’ANSI) alors généralement, si la présentation n’est pas interdite, cette information DEVRAIT être utilisée pour remplir la portion Affichage du nom du champ From.

Si le format d’appel ISUP est converti plutôt que le format ISUP, deux éléments d’information supplémentaires doivent être pris en compte : les indicateurs de présentation et les indicateurs d’affichage. Si les indicateurs de présentation sont réglés à 'présentation interdite', un URL spécial est alors créé par la passerelle qui communique à l’extrémité distante que l’identité de l’appelant a été omise. Cet URI DEVRAIT être un URI SIP avec un nom d’affichage et un nom d’utilisateur de 'Anonyme', par exemple :

Pour plus d’informations sur la confidentialité dans SIP, voir au paragraphe 5.7.

Si la présentation est réglée à 'adresse indisponible', les passerelles devraient alors traiter le IAM comme si le paramètre CIN était omis. Les indicateurs d’affichage ne devraient pas être traduits, car il n’ont de sens que de bout en bout.

La conversion des URL tel au format ISUP est plus simple. Si l’URI est en format international, la passerelle DEVRAIT alors consulter le code de pays en tête de l’URI. Si le code de pays est local pour la passerelle (la passerelle a un ou plusieurs circuits qui pointent sur des commutateurs qui sont rattachés au code de pays en question) la passerelle DEVRAIT régler l’INA de façon à refléter 'numéro national (significatif)' et supprimer le code de pays de l’URI avant de remplir le champ de chiffres. Si le code de pays n’est pas local pour la passerelle, elle DEVRAIT régler l’INA à 'numéro international' et garder le code de pays. Dans l’un et l’autre cas, le NPI DOIT être réglé à 'Plan de numérotage RNIS'.

Si l’URI n’est pas au format international, la passerelle PEUT tenter de traiter le numéro de téléphone au sein de l’URI comme si il était approprié pour son plan de numérotation national ou spécifique du réseau ; si ce faisant cela donne lieu à des erreurs de passerelle internes ou si la passerelle n’accepte pas de telles procédures, la passerelle DEVRAIT alors répondre avec les codes d’état SIP appropriés pour exprimer que l’URI n’a pas pu être compris (si l’URI en question est l’URI de demande, un 484).

Lors de la conversion d’un URL tel en format d’appel ISUP, la procédure est identique à celle décrite aux paragraphes précédents, mais en plus, l’indicateur de présentation DEVRAIT être réglé à 'présentation permise' et l’indicateur d’affichage à 'fourni par le réseau', sauf si une politique de fournisseur de service ou un profil d’usager interdit spécifiquement la présentation.

D’autres nuances de l’ISUP différentes de l’ISUP de l’UIT-T ont des paramètres différents et plus de caractéristiques. Certains des paramètres ont plus de valeurs possibles et fournissent plus d’informations sur l’état de l’appel.

Le message d’interrogation de circuit (CQM, Circuit Query Message) et la réponse d’ interrogation de circuit (CQR, Circuit Query Response) sont utilisés dans de nombreuses variantes d’ISUP. Ces messages n’ont pas d’analogie dans SIP, bien que la réception d’un CQR puisse causer une réconciliation d’état si les commutateurs d’origine et de destination sont désynchronisés ; comme les états sont réconciliés, certains appels peuvent être terminés, ce qui peut être cause que des messages SIP ou ISUP sont envoyés (comme décrit à la Section 10).

Cependant, les différences dans les flux de messages sont plus importantes. Dans l’ISUP ANSI [T1.113], le message CON NE DOIT PAS être envoyé ; un ANM est envoyé à la place (alors qu’aucun ACM n’a été envoyé avant qu’il ne soit répondu à l’appel). Dans des situations de renvoi d’appel, des CPG PEUVENT être envoyés avant l’envoi de l’ACM. Des SAM NE DOIVENT PAS être envoyés ; la signalisation 'en-bloc' est toujours utilisée. Le message ANSI Exit (EXM) NE DEVRAIT PAS résulter en signalisation SIP dans les passerelles. ANSI utilise aussi le message de réservation de circuit (CRM, Circuit Reservation Message) et le message d’accusé de réception de réservation de circuit (CRA, Circuit Reservation Acknowledgment) au titre de ses procédures d’interfonctionnement - dans l’éventualité d’un MGC qui reçoit un CRM, un CRA DEVRAIT être envoyé en retour (dans certaines mises en œuvre, les transmissions de CRA pourraient idéalement se fonder sur un système de réservation de ressource) ; après l’envoi d’un CRA, le MGC DEVRAIT attendre un IAM à suivre et le traiter normalement. Tout autre mécanisme de réservation de circuit sort du domaine d’application du présent document.

Bien que la réception d’un message Confusion (CFN) soit une indication d’une erreur de protocole, les messages SIP correspondants NE DEVRAIENT PAS être envoyés à réception d’un CFN - le CFN devrait être traité avec des procédures spécifiques d’ISUP par la passerelle (usuellement par la retransmission du paquet auquel répond le CFN). C’est seulement si les procédures ISUP échouent de façon répétée que cela causerait l’apparition d’une condition d’erreur SIP (et un échec de l’appel).

Dans l’ISUP TTC, les CPG PEUVENT être envoyés avant l’envoi de l’ACM. Des messages tels qu’un message d’information de tarification (CHG, Charging Information Message) PEUVENT être envoyés entre un ACM et un ANM. La signalisation 'en-bloc' est toujours utilisée et il n’y a pas de temporisateur T9.

Certaines variantes ISUP envoient plus de messages que celle décrite dans le présent document. Des lignes directrices sont donc fournies ici à l’égard du transport et de la transposition de ces messages ISUP.

De l’appelant à l’appelé, d’autres messages ISUP DEVRAIENT être encapsulés (voir la [RFC3204]) à l’intérieur des messages INFO, même si la transaction INVITE n’est toujours pas terminée. Noter que SIP ne garantit pas que les demandes INFO sont livrées dans l’ordre, et donc dans de mauvaises conditions du réseau une passerelle de sortie pourrait traiter les INFO dans le désordre. Cette question, cependant, ne représente pas un problème important car il est peu probable qu’elle se pose et ses effets sont négligeables dans la plupart des situations. Les messages Information (INF) et Réponse d’information (INR) sont des exemples de messages qui devraient être encapsulés dans un INFO. Les mises en œuvre de passerelles pourraient aussi envisager de construire des systèmes qui attendent que chaque transaction INFO s’achève avant d’initier une nouvelle transaction INFO.

De l’appelé à l’appelant, si un message est reçu par une passerelle avant qu’il ait été répondu à l’appel (c’est-à-dire, l’ANM est reçu) il DEVRAIT être encapsulé dans un INFO, pourvu que ce ne soit pas le premier message SIP envoyé dans la direction arrière (auquel cas, il DEVRAIT être encapsulé dans une réponse provisoire 1xx). De même, un message qui est reçu du côté origine (probablement en réponse à un INR) avant la réception d’un 200 OK par la passerelle devrait être porté dans un INFO. Afin que ce mécanisme fonctionne correctement vers l’avant, toute étiquette Contact ou To nécessaire doit être apparue dans une réponse provisoire antérieure ou le message pourrait n’être pas acheminé correctement à sa destination. À ce titre, toutes les passerelles SIP-T DOIVENT envoyer toutes les réponses provisoires avec un en-tête Contact et toutes les étiquettes nécessaires pour permettre un acheminement approprié des nouvelles demandes produites avant la réception d’une réponse finale. Lorsque la transaction INVITE est terminée, les demandes INFO DEVRAIENT aussi être utilisées dans cette direction.

ANSI (American National Standards Institute) Institut national de normalisation des États-Unis

CGBA (Circuit Group Blocking ACK Message) message Accusé de réception de blocage de groupe de circuits

GRA (Circuit Group Reset ACK Message) message Accusé de réception de rétablissement de groupe de circuits

GRS (Circuit Group Reset Message) message Rétablissement de groupe de circuits

IETF (Internet Engineering Task Force) équipe d’ingénierie de l’Internet

ISDN (Integrated Services Digital Network) (RNIS) réseau numérique à intégration de servicesISUP (ISDN User Part) sous-système utilisateur RNIS

SCCP (Signaling Connection Control Part) sous-système connexion de signalisation

TTC (Telecommunication Technology Committee) Comité des technologies de télécommunication

UIT-T (Union Internationale des Télécommunications – Secteur de la normalisation des Télécommunications)

La traduction de paramètres ISUP en en-têtes SIP peut introduire des problèmes de confidentialité et de sécurité en plus et au delà de ceux qui ont été identifiés pour les autres fonctions de SIP-T [RFC3372]. Simplement sécuriser l’ISUP encapsulé, par exemple, ne fournirait pas la protection de confidentialité adéquate pour un usager qui demande l’interdiction de la présentation si le paramètre Numéro de l’appelant est ouvertement transposé en l’en-tête From. Le paragraphe 12.2 montre comment la confidentialité SIP [RFC3323] devrait être utilisée pour cette fonction. Comme la portée de la transposition de SIP en ISUP a été restreinte aux seuls paramètres qui vont être traduits en en-têtes et champs utilisés pour acheminer les demandes SIP, les passerelles révèlent par conséquent par la traduction la quantité minimum possible d’informations.

Une analyse de la sécurité d’ISUP sort du domaine d’application du présent document. Le pontage d’ISUP à travers SIP est discutée plus complètement dans la [RFC3372], mais le paragraphe 7.2.1.1 discute du traitement des valeurs ISUP traduites en relation avec tout ISUP incorporé dans une demande qui arrive à une passerelle RTPC. Le manque d’analyse de la sécurité d’ISUP peut exposer à des risques si l’ISUP incorporé est interprété aveuglément. En conséquence, les passerelles NE DEVRAIENT PAS faire une confiance aveugle à l’ISUP incorporé sauf si la demande a été authentifiée de façon forte [RFC3372], et si l’envoyeur est de confiance, par exemple, si c’est un autre MGC qui est autorisé à utiliser l’ISUP sur SIP en mode pontage. Lorsque les demandes sont reçues de points d’extrémité arbitraires, les passerelles DEVRAIENT filtrer tout ISUP reçu. En particulier, seuls des commandes et paramètres connus comme sûrs devraient être acceptés ou passés. Le filtrage par élimination des entités supposées être dangereuses ne fonctionne pas bien.

À beaucoup d’égards, les informations qui sont traduites de l’ISUP en SIP n’ont pas d’exigences de sécurité particulières. Pour que les paramètres traduits soient utilisés pour acheminer les demandes, ils devraient être lisibles par les intermédiaires ; la confidentialité de bout en bout de ces données serait inutile et très vraisemblablement désavantageuse. Il y a aussi de nombreuses circonstances dans lesquelles les intermédiaires peuvent légitimement changer les valeurs qui ont été fournies par traduction, et donc, l’intégrité sur ces en-têtes n’est pas non plus désirable.

Il y a cependant quelques soucis qui se font jour de l’autre direction de la transposition, la transposition des en-têtes SIP en paramètres ISUP, qui sont énumérés dans les paragraphes qui suivent. Lorsque les usagers finaux numérotent aujourd’hui dans le RTPC, leurs sélections remplissent la portion numéro de téléphone du paramètre Numéro demandé, ainsi que les portions chiffres des paramètres Code d’identification du transporteur et Sélection du réseau de transit d’un IAM ISUP. De même, l’URL tel et ses paramètres facultatifs dans l’URI de demande d’un SIP, qui peut être créé directement par les usagers finaux d’un appareil SIP, se transposent en ces paramètres à une passerelle. Cependant, dans le RTPC, la politique peut empêcher l’usager de numéroter certains numéros (invalides ou interdits) ou de choisir certains codes d’identification de transporteur. Donc, les opérateurs de passerelles PEUVENT souhaiter utiliser les politiques correspondantes pour interdire l’usage de certains URL tel, ou paramètres d’URL tel, lorsque ils autorisent un appel.

Les champs pertinents pour la portabilité du numéro, qui incluent dans l’ISUP ANSI la portion LRN du paramètre Adresse générique et le bit 'M' des Indicateurs d’appel vers l’avant, sont utilisés pour acheminer les appels dans le RTPC. Comme ces champs sont rendus comme des paramètres d’URL tel dans la transposition SIP-ISUP, les usagers peuvent régler la valeur de ces champs de façon arbitraire. Par conséquent, un utilisateur final pourrait changer le bureau d’extrémité auquel un appel serait acheminé (bien que si la valeur du LRN a été choisie au hasard, il est plus probable que cela va empêcher l’appel d’être livré). Le RTPC est cependant relativement résilient aux appels qui ont été mal acheminés à cause de la portabilité du numéro local. Dans certains réseaux, un message REL avec une sorte de code de cause "Numéro porté mal acheminé" est envoyé vers l’arrière lorsque survient une telle condition. Autrement, le commutateur RTPC auquel un appel a été mal acheminé peut transmettre l’appel au commutateur approprié après avoir effectué sa propre interrogation de portabilité de numéro – ceci est une pratique intermédiaire de portabilité de numéro qui est encore courante dans la plupart des segments du RTPC qui prennent en charge la portabilité. On ne prévoit pas que les utilisateurs finaux établissent normalement ces champs SIP, et les risques associés à la permission qu’un utilisateur aventureux ou malveillant règle le LRN ne semblent pas trop graves, mais ils devraient être notés par les opérateurs de réseau. Le niveau limité de la contribution de la signalisation SIP aux indicateurs d’interfonctionnement des paramètres Indicateur d’appel vers l’avant et Indicateur d’appel vers l’arrière ne fait courir aucun risque prévisible.

Quelques risques supplémentaires peuvent résulter de la transposition du code de réponse SIP en paramètre ISUP Code de cause. Les agents d’utilisateur SIP pourraient vraisemblablement répondre à un INVITE à partir d’une passerelle avec n’importe quel code de réponse SIP, et donc ils pourraient dicter (dans les limites de la transposition prise en charge par la passerelle) le code de cause Q.850 qui sera envoyé par la passerelle dans le message REL résultant. En général, il est improbable que la manière dont un appel est rejeté fournisse une opportunité de fraude ou de déni de service – à la connaissance des auteurs, il n’y a pas de code de cause identifié dans le présent document qui pourrait signaler qu’un appel ne devrait pas être taxé, ou que le réseau devrait mettre hors ligne des ressources critiques. Cependant, les opérateurs peuvent vouloir examiner avec attention l’ensemble des codes de cause qui pourraient être transposés des codes de réponse SIP (dont la liste figure au paragraphe 7.2.6.1) pour s’assurer qu’aucun comportement indésirable spécifique du réseau ne pourrait résulter du fonctionnement d’une passerelle qui prend en charge les transpositions recommandées. Dans certains cas, les opérateurs PEUVENT souhaiter mettre en œuvre des politiques de passerelle qui utiliseraient d’autres transpositions, peut-être fondées de façon sélective sur des données d’autorisation.

Si les champs d’en-tête URI de demande et To d’une demande reçue à une passerelle diffèrent, le paragraphe 7.2.1.1 recommande que l’en-tête To (si c’est un numéro de téléphone) devrait se transposer en le paramètre Numéro appelé à l’origine, et l’URI de demande en le paramètre Numéro demandé. Cependant, l’usager peut, au début d’une demande, choisir une valeur de champ To qui diffère de l’URI de demande ; il n’est pas exigé que ces deux valeurs de champ soient les mêmes. Cela permet essentiellement à un usager de régler arbitrairement le paramètre ISUP Numéro appelé à l’origine. Toutes les applications qui s’appuient sur le Numéro appelé à l’origine pour des besoins d’établissement pourraient être affectées par cette recommandation de transposition. On prévoit que de futurs travaux sur SIP dans cet espace vont arriver à une meilleure prise en compte générale du reciblage des demandes SIP qui peuvent être applicables à la transposition OCN.

Le remplissage arbitraire de l’en-tête From des demandes par les agents d’utilisateur SIP a des implications de sécurité bien comprises pour les appareils qui s’appuient seulement sur l’en-tête From comme représentation précise de l’identité de l’origine. Toute passerelle qui a l’intention d’utiliser l’en-tête From pour remplir le paramètre Numéro du demandé d’un IAM de message ISUP devrait authentifier le générateur de la demande et s’assurer qu’il est autorisé à prétendre être ce numéro appelant (ou s’assurer d’une méthode plus sûre pour certifier l’identité de l’appelant). Noter que les passerelles, comme tous les autres agents d’utilisateur SIP, DOIVENT prendre en charge l’authentification par résumé décrite dans la [RFC3261].

Il y a une autre classe de risques potentiels qui se rapporte au raccourci du chemin de supports vers l’arrière avant qu’il soit répondu à l’appel. Plusieurs pratiques décrites dans le présent document recommandent qu’une passerelle signale un ACM lorsque un agent d’usager appelé retourne un code de réponse provisoire 18x. À ce moment, le support vers l’arrière va passer en raccourci de bout en bout dans le réseau ISUP, et il est possible à l’agent d’utilisateur de l’appelé de jouer une tonalité audio arbitraire à l’appelant pendant une durée indéfinie avant la transmission d’une réponse finale (sous la forme d’un code de réponse 2xx ou supérieur). On peut imaginer des situations dans lesquelles cette capacité pourrait être utilisée de façon illégitime par l’agent d’utilisateur de l’appelé. C’est cependant aussi une caractéristique utile pour permettre l’exécution des tonalités et annonces de progression vers l’arrière dans l’état 'ACM envoyé' (afin que l’appelant ne soit pas facturé pour des appels qui en fait n’aboutissent pas mais pour lesquels la condition d’échec doit être communiquée à l’usager par de l’audio dans la bande). En fait, ISUP utilise couramment cette capacité de raccourci vers l’arrière afin de passer les tonalités et annonces qui se rapportent à l’état d’un appel lorsque un réseau ISUP interfonctionne avec des réseaux traditionnels qui ne sont pas capables d’exprimer les codes de cause Q.850.

L’intention des auteurs est que SIP n’introduise aucun risque à l’égard des supports vers l’arrière qui n’existent pas dans la transposition Q.931-ISUP, mais les mises en œuvre de passerelles PEUVENT développer un mécanisme facultatif (éventuellement quelque chose qui pourrait être configuré par un opérateur) qui écourterait un tel 'support précoce' au moyen d’un temporisateur bref – il est improbable que plus de 20 ou 30 secondes de support précoce soient nécessaires pour porter les informations d’état sur l’appel (voir au paragraphe 7.2.6). Une approche plus prudente serait de ne jamais faire passer de supports en raccourci vers l’arrière à travers la passerelle tant que n’a pas été reçu une réponse finale 2xx, pourvu que la passerelle mette en œuvre un moyen d’empêcher la coupure des supports initiaux associés à l’appel.

À la différence d’un téléphone RTPC traditionnel, un agent d’utilisateur SIP peut lancer plusieurs demandes simultanées afin de joindre une certaine ressource. Il serait trivial pour un agent d’utilisateur SIP de lancer 100 demandes SIP à 100 passerelles d’accès, ligotant ainsi tous ses accès. Un usager malveillant pourrait choisir de lancer des demandes à des numéros de téléphone qui ne sauront jamais répondre, ce qui saturerait indéfiniment les ressources et potentiellement sans subir aucune charge. Les passerelles PEUVENT donc prendre en charge des politiques qui restreignent le nombre de demandes simultanées générées de la même source authentifiée, ou des mécanismes similaires pour contrer ces possibles attaques de déni de service.

Le présent document n’introduit aucune nouvelle considération en rapport avec l’IANA.

Le présent document a existé comme projet Internet pendant quatre ans, et a reçu d’innombrables contributions de membres des divers groupes de travail de la zone Transport de l’IETF (incluant les groupes de travail MMUSIC, SIP et SIPPING). En particulier, les auteurs tiennent à remercier Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars Tovander, Al Varney et William T. Marshall de leur aide et de leurs retours sur ce document. Les auteurs tiennent aussi à remercier le SG11 de l’UIT-T de ses conseils sur les procédures de l’ISUP.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2806] A. Vaha-Sipila, "URL pour les appels téléphoniques", avril 2000. (Obsolète, voir RFC3966) (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.)

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

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

[RFC3326] H. Schulzrinne, D. Oran, G. Camarillo, "Champ d'en-tête Reason pour le protocole d'initialisation de session (SIP)", décembre 2002. (P.S.)

[Q.767] Union Internationale des Télécommunications, Recommandation UIT-T Q.767, "Application of the ISDN user part of CCITT Signaling System No. 7 for international ISDN interconnection", février 1991, <http://www.itu.int>.

[T1.113] American National Standards Institute, "Signaling System No. 7; ISDN User Part", ANSI T1.113, janvier 1995.

[Q.764] Union Internationale des Télécommunications, Recommandation UIT-T Q.764, "Signaling System No. 7; ISDN User Part Signaling procedures", décembre 1999, <http://www.itu.int>.

[Q.118] Union Internationale des Télécommunications, Recommandation UIT-T Q.118, "Abnormal conditions - Special release", septembre 1997, <http://www.itu.int>.

[Q.737] Union Internationale des Télécommunications, Recommandation UIT-T Q.737, "Specifications of Signaling System No. 7 - ISDN supplementary services", juin 1997, <http://www.itu.int>.

[Q.850] Union Internationale des Télécommunications, Recommandation UIT-T Q.850, "Usage of cause location in the Digital Subscriber Signaling System No. 1 and the Signaling System No. 7 ISDN User Part", mai 1998, <http://www.itu.int>.

[E.164] Union Internationale des Télécommunications, Recommandation UIT-T E.164, "The international public telecommunications numbering plan", mai 1997, <http://www.itu.int>.

[Q.763] Union Internationale des Télécommunications, Recommandation UIT-T Q.763, "Formats and codes of the ISDN User Part of Signaling System No. 7", décembre 1999, <http://www.itu.int>.

[RFC2960] R. Stewart et autres, "Protocole de transmission de commandes de flux", octobre 2000. (Obsolète, voir RFC4960) (P.S.)

[RFC3311] J. Rosenberg, "Méthode UPDATE du protocole d'initialisation de session (SIP) ", octobre 2002.

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 qui y sont contenues sont fournis 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	G. Camarillo, Ericsson
Request for Comments : 3398	A. B. Roach, dynamicsoft
Catégorie : En cours de normalisation	J. Peterson, NeuStar
	L. Ong, Ciena
Traduction Claude Brière de L’Isle	décembre 2002

Gonzalo Camarillo	Adam Roach	Jon Peterson
Ericsson	dynamicsoft	NeuStar, Inc.
Advanced Signalling Research Lab.	5100 Tennyson Parkway	1800 Sutter St
FIN-02420 Jorvas	Suite 1200	Suite 570
Finland	Plano, TX 75024	Concord, CA 94520 USA
téléphone : +358 9 299 3371	USA	téléphone : +1 925/363-8720
URI : http://www.ericsson.com/	URI : sip:adam@dynamicsoft.com	mél : jon.peterson@neustar.biz
mél : Gonzalo.Camarillo@Ericsson.com	mél : adam@dynamicsoft.com	URI : http://www.neustar.biz/