Transposition de la signalisation en chevauchement du sous-système utilisateur (SSU) du réseau numérique à intégration de services (RNIS) dans le protocole d'initialisation de session (SIP)

Statut de ce mémoire

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.

Notice de copyright

Copyright (C) The Internet Society (2003). Tous droits réservés

Résumé

Le présent document décrit une façon de transposer la signalisation en chevauchement du sous-système utilisateur du réseau numérique à intégration de services (ISUP, Integrated Services Digital Network User Part) dans le protocole d’initialisation de session (SIP, Session Initiation Protocol). Ce mécanisme pourrait être mis en œuvre lorsque SIP est utilisé dans un environnement où des parties de l’appel impliquent un interfonctionnement avec le réseau téléphonique public commuté (RTPC).

1. Introduction

Une transposition entre le protocole d’initialisation de session (SIP, Session Initiation Protocol) [RFC3261] et le sous-système utilisateur du RNIS (ISUP, ISDN User Part) [Q.967] du système de signalisation n° 7 (SS7) est décrite dans la [RFC3398]. Cependant, celle-ci ne prend en compte que la signalisation en-bloc de l’ISUP. La signalisation en-bloc consiste en l’envoi du numéro de téléphone complet de l’appelé dans le premier message de signalisation. Bien que les commutateurs modernes utilisent toujours la signalisation en-bloc, certaines parties du RTPC utilisent toujours la signalisation en chevauchement.

La signalisation en chevauchement consiste en l’envoi de seulement quelques chiffres du numéro demandé dans le premier message de signalisation. D’autres chiffres sont envoyés dans les messages de signalisation suivants. Bien que la signalisation en chevauchement dans le RTPC soit la source de beaucoup de complexité supplémentaire, elle est toujours utilisée dans certains pays.

Comme les commutateurs modernes, SIP utilise la signalisation en-bloc. L’URI de demande d’une demande INVITE contient toujours l’adresse complète du demandé. Les points d’extrémité SIP ne génèrent jamais de signalisation en chevauchement.

Donc, la solution préférée pour une passerelle qui traite la signalisation en chevauchement du RTPC et SIP est de convertir la signalisation en chevauchement RTPC en signalisation en-bloc SIP en utilisant l’analyse du numéro et des temporisateurs. La passerelle attend que tous les messages de signalisation qui portent les parties du numéro de l’appelé arrivent, et à ce moment seulement, elle génère une demande SIP INVITE. La Section 2 décrit comment convertir la signalisation en chevauchement ISUP en en-bloc SIP de cette façon.

Cependant, bien que ce soit la solution préférée, la conversion de la signalisation en chevauchement en signalisation en-bloc résulte parfois en des délais d’établissement d’appel inacceptables (plusieurs secondes) pour l’utilisateur humain. Dans ces situations, une certaine forme de signalisation en chevauchement doit être utilisée dans le réseau SIP pour minimiser le délai d’établissement d’appel. Cependant, introduire la signalisation en chevauchement dans SIP introduit de la complexité et soulève des problèmes. La Section 3 analyse les problèmes qui se rapportent à l’utilisation de la signalisation en chevauchement dans un réseau SIP et décrit des moyens pour les résoudre dans certains scénarios de réseau particuliers. La Section 3 décrit aussi dans quels scénarios de réseau particuliers ces problèmes rendent inacceptable l’utilisation de la signalisation en chevauchement dans le réseau SIP.

2. Conversion de la signalisation en chevauchement ISUP en signalisation SIP en-bloc

Dans ce scénario, la passerelle reçoit un IAM (message d’adresse initiale) qui ne contient qu’une portion du numéro appelé. Le reste des chiffres composés arrive plus tard dans un ou plusieurs messages d’adresse ultérieurs (SAM, Subsequent Address Message).

2.1 Attente de la quantité minimum de chiffres

Si l’IAM contient moins que la quantité minimale de chiffres pour acheminer un appel, la passerelle débute le temporisateur T35 et attend jusqu’à ce que la quantité minimale de chiffres qui peut représenter un numéro de téléphone soit reçue (ou qu’un chiffre d’arrêt soit reçu). Si T35 arrive à expiration avant que la quantité minimale de chiffres (ou un chiffre d’arrêt) ait été reçue, un REL avec une valeur de cause de 28 est envoyé au côté ISUP. T35 est défini dans [Q.764] comme durant 15 à 20 secondes.

Si un chiffre d’arrêt est reçu, la passerelle peut déjà générer une demande INVITE avec le numéro appelé complet. Donc, l’appel se poursuit comme d’habitude.

2.2 La quantité minimum de chiffres a été reçue

Une fois la quantité minimale de chiffres qui peuvent représenter un numéro de téléphone reçue, la passerelle devrait utiliser l’analyse du numéro pour décider si le numéro qui a été reçu jusqu’à présent est un numéro complet. Si il l’est, la passerelle peut générer une demande INVITE avec le numéro appelé complet. Donc, l’appel se poursuit comme d’habitude.

Cependant, il y a des cas où la passerelle ne peut pas savoir si le numéro reçu est un numéro complet ou non. Dans ce cas, la passerelle devrait collecter les chiffres jusqu’à l’arrivée à expiration d’un temporisateur (T10) ou qu’un chiffre d’arrêt (comme #) soit entré par l’usager (noter que T10 est rafraîchi chaque fois qu’est reçu un nouveau chiffre). Lorsque T10 arrive à expiration, un INVITE avec les chiffres collectés jusqu’alors est envoyé au côté SIP. Après cela, tout SAM reçu est ignoré.

RTPC MGC/MG SIP

| | |

|-----------IAM----------->| T10 débute |

| | |

|-----------SAM----------->| T10 débute |

| | |

|-----------SAM----------->| T10 débute |

| | |

| | |

| T10 expire |---------INVITE---------->|

| | |

Figure 1 : Utilisation de T10 pour convertir la signalisation en chevauchement en en-bloc

Noter que T10 est défini pour la conversion entre la signalisation en chevauchement (par exemple, CAS) et l’ISUP en-bloc. Les commutateurs du RTPC mettent habituellement en œuvre une valeur du temporisateur T10 définie en local – qui peut n’être pas dans la gamme de 4 à 6 secondes recommandée par la Recommandation UIT-T [Q.764] -- pour convertir l’ISUP en chevauchement en ISUP en-bloc. Le présent document utilise T10 et recommande la gamme de valeurs définies dans [Q.764], qui semble convenable pour l’opération de conversion de la signalisation en chevauchement en SIP en-bloc. Le choix effectif de la valeur du temporisateur est une affaire de politique locale.

3. Envoi de signalisation en chevauchement à un réseau SIP

Cette section analyse les problèmes qui se rapportent à l’utilisation de la signalisation en chevauchement dans un réseau SIP et décrit une solution possible et la portée de son applicabilité. Il est important de noter que, si elle est utilisée en dehors de son domaine d’applicabilité, cette solution pourrait causer un ensemble de problèmes, qui sont identifiés dans cette section.

3.1 Une ou plusieurs transactions

Une passerelle d’entrée qui reçoit de la signalisation ISUP en chevauchement (c’est-à-dire, un IAM et un ou plusieurs SAM) a besoin de la transposer en signalisation SIP. Une approche possible consisterait à envoyer un INVITE avec les chiffres reçus dans l’IAM, et une fois qu’un dialogue précoce est établi, d’envoyer les chiffres reçus dans des SAM dans une demande SIP (par exemple, INFO) au sein de ce dialogue précoce.

Cette approche pose plusieurs problèmes. Elle exige que l’agent d’utilisateur SIP distant (qui peut être une passerelle) envoie une réponse provisoire non 100 aussitôt qu’il a reçu l’INVITE initial pour établir le dialogue précoce. Les passerelles actuelles, suivant les procédures de la [RFC3398], ne génèrent pas une telle réponse provisoire. Si les passerelles généraient une telle réponse (par exemple, 183 Session en cours) cela causerait la génération par les passerelles d’ACM précoces, créant la confusion dans les automates à états du RTPC même dans les appels qui n’utilisent pas la signalisation en chevauchement.

Dans cette approche, une fois que la demande INVITE initiale est acheminée, toutes les demandes suivantes envoyées au sein du dialogue précoce suivent le même chemin. C’est-à-dire, elles ne peuvent pas être réacheminées pour tirer parti des services fondés sur SIP. Donc, on ne recommande pas d’utiliser cette approche.

Une autre approche consiste à envoyer un nouvel INVITE qui contient tous les chiffres reçus jusqu’alors chaque fois qu’un nouveau SAM est reçu. Comme chaque nouvel INVITE envoyé représente une nouvelle transaction, ils peuvent être acheminée d’une façon différente. Ainsi, chaque nouvel INVITE peut tirer parti de tous les services SIP que le réseau peut fournir.

Cependant, avoir les INVITE suivants acheminés de façon différente amène de nouveaux problèmes aussi. Le premier INVITE, par exemple, peut être acheminé sur une certaine passerelle, et l’INVITE suivant sur une autre. Le résultat est que les deux passerelles génèrent un IAM. Comme un des IAM (ou les deux) a un numéro incomplet, il va échouer, ayant déjà consommé des ressource du RTPC. Il pourrait même arriver que les deux IAM contiennent des numéros complets, mais différents (c’est-à-dire, un numéro est le préfixe de l’autre).

L’acheminement dans SIP peut être contrôlé par l’administrateur du réseau. Donc, une passerelle peut être configurée de façon à générer la signalisation SIP en chevauchement de la façon décrite ci-dessous mais seulement si l’infrastructure d’acheminement SIP assure que les INVITE ne vont atteindre qu’une passerelle. Lorsque l’infrastructure d’acheminement n’est pas sous le contrôle de l’administrateur de la passerelle, les procédures de la Section 2 doivent être utilisés à la place.

Dans certains plans de numérotage du RTPC, un numéro de téléphone peut être un préfixe d’un autre numéro. Cette situation n’est pas courante, mais elle peut se produire. Lorsque la signalisation en-bloc est utilisée, cette ambiguïté est résolue avant que les chiffres soient placés dans la signalisation en-bloc. Si la signalisation en chevauchement est utilisée dans cette situation, il peut se trouver qu’un usager différent de celui que l’appelant entendait appeler soit contacté. C’est pourquoi dans les parties du RTPC où la numérotation en chevauchement est utilisée, un préfixe d’un numéro de téléphone n’identifie jamais un autre numéro valide. Donc, la signalisation SIP en chevauchement ne devrait pas être utilisée lorsque on tente de joindre des parties du RTPC où il est possible qu’un numéro et un préfixe plus court de ce même numéro soient tous deux des adresses valides de terminaux différents.

3.2 Génération de plusieurs INVITE

Dans ce scénario, la passerelle reçoit un IAM (message d’adresse initiale) et éventuellement un ou plusieurs SAM (message d’adresse suivant) qui fournissent plus que la quantité minimale de chiffres qui peut représenter un numéro de téléphone.

Aussitôt que la quantité minimale de chiffres est reçue, la passerelle envoie un INVITE et lance le temporisateur T10. Cet INVITE est construit suivant les procédures décrites dans la [RFC3398].

Si un SAM arrive à la passerelle, T10 est rafraîchi et un nouvel INVITE avec les nouveaux chiffres reçus est envoyé. Le nouvel INVITE a le même identifiant d’appel et le même champ d’en-tête From incluant l’étiquette que le premier INVITE envoyé, mais a un URI de demande mis à jour. Le nouvel URI de demande contient tous les chiffres reçus jusqu’à présent. Le champ d’en-tête To du nouvel INVITE contient tous les chiffre aussi mais n’a pas d’étiquette.

Noter qu’il est possible de recevoir une réponse au premier INVITE avant d’avoir envoyé le second INVITE. Dans ce cas, la réponse reçue va contenir une étiquette To et les informations (Record-Route et Contact) pour construire un champ d’en-tête Route. Le nouvel INVITE à envoyer (contenant les nouveaux chiffres) ne devrait pas utiliser ces en-têtes. C’est-à-dire que le nouvel INVITE ne contient ni l’étiquette To ni le champ d’en-tête Route. De cette façon, ce nouvel INVITE peut être acheminé de façon dynamique par le réseau qui fournit des services.

Le nouvel INVITE devrait, bien sûr, contenir un champ Cseq. Il est recommandé que le Cseq du nouvel INVITE soit plus élevé qu’aucun des précédents Cseq que la passerelle a générés pour cet identifiant d’appel (quel que soit le dialogue pour lequel le Cseq a été généré).

Lorsque un INVITE fait une fourche, les réponses provenant des différentes localisations peuvent arriver en établissant un ou plusieurs dialogues précoces. De nouvelles demandes comme PRACK ou UPDATE peuvent être envoyées au sein de tout dialogue précoce. Cela implique que les espaces de numéros de Cseq de différents dialogues précoces soient différents. L’envoi d’un nouvel INVITE avec un Cseq qui n’est encore utilisé par aucune des destinations distantes évite les confusions à la destination.

Si la passerelle encapsule les messages ISUP comme des corps SIP, elle devrait placer l’IAM et tous les SAM reçus jusqu’alors dans cet INVITE.

RTPC MGC/MG SIP

| | |

|-----------IAM----------->| Lance T10 |

| |---------INVITE---------->|

| | |

|-----------SAM----------->| lance T10 |

| |---------INVITE---------->|

| | |

|-----------SAM----------->| lance T10 |

| |---------INVITE---------->|

| | |

Figure 2 : Signalisation en chevauchement dans SIP

Si des réponses finales 4xx, 5xx ou 6xx arrivent (par exemple, 484 Adresse incomplète) pour les transactions INVITE en cours avant l’arrivée à expiration de T10, la passerelle ne devrait envoyer aucun REL. Un REL n’est envoyé que si aucun autre SAM n’arrive, que T10 expire, et que tous les INVITE envoyés ont reçu une réponse avec une réponse finale (différente de 200 OK).

RTPC MGC/MG SIP

| | |

|-----------IAM----------->| lance T10 |

| |---------INVITE---------->|

| |<---------484-------------|

| |----------ACK------------>|

| | |

| | |

| T10 expire | |

|<----------REL------------| |

Figure 3 : Génération de REL avec la signalisation en chevauchement

Le meilleur code d’état parmi toutes les réponses reçues pour tous les INVITE qui ont été générés est utilisé pour calculer la valeur de cause du REL comme décrit dans la [RFC3398].

Le calcul de la meilleure réponse est fait de la même façon que les mandataires de fourchement calculent la meilleure réponse à retourner au client pour un INVITE particulier. Noter que la meilleure réponse n’est pas toujours la réponse à l’INVITE qui contenait le plus de chiffres. Si l’usager compose un numéro particulier puis frappe par erreur un chiffre de trop, un code 486 (Occupé ici) pourrait être reçu pour le premier INVITE et un 484 (Adresse incomplète) pour le second (qui contenait plus de chiffres).

3.3 Réception de plusieurs réponses

Lorsque dans SIP la signalisation en chevauchement est utilisée, la passerelle d’entrée envoie plusieurs INVITE. En conséquence, elle va recevoir plusieurs réponses. Les réponses à tous les INVITE envoyés, sauf pour un (normalement, mais pas nécessairement le dernier) sont d’habitude des réponses de classe 400 (par exemple, 484 Adresse incomplète) qui terminent la transaction INVITE.

Cependant, une réponse 183 Session en cours avec une description des supports peut aussi être reçue. Le flux de supports va normalement contenir un message tel que "Le numéro composé n’est pas attribué".

La question de recevoir différentes réponses 183 Session en cours avec des descriptions des supports ne s’applique pas seulement à la signalisation en chevauchement. Lorsque le SIP de base est utilisé, plusieurs réponses peuvent aussi arriver à une passerelle si l’INVITE a fourché. Il appartient à la passerelle de décider quel flux de supports devrait être exécuté à l’usager.

Cependant, la signalisation en chevauchement ajoute une exigence à ce processus. En règle générale, un flux de support correspondant à la réponse à un INVITE avec un plus grand nombre de chiffres devrait recevoir une priorité supérieure aux flux provenant de réponses avec moins de chiffres.

3.4 Annulation de transactions INVITE en instance

Lorsque une passerelle envoie un nouvel INVITE contenant de nouveaux chiffres, elle ne devrait pas envoyer ANNULLE pour la première transaction INVITE. Ce ANNULLE pourrait arriver avant le nouvel INVITE à une passerelle de sortie et déclancher un REL avant que le nouvel INVITE soit arrivé. Les transactions INVITE se terminent normalement par la réception de réponses 4xx.

Cependant, une fois qu’une réponse 200 OK a été reçue, la passerelle devrait envoyer ANNULLE pour toutes les autres transactions INVITE qui ont été générées. Une passerelle peut mettre en œuvre un temporisateur pour attendre un certain temps avant d’envoyer aucun ANNULLE. Cela donne du temps à toutes les transactions INVITE précédentes pour se terminer en douceur sans générer plus de trafic de signalisation (des messages ANNULLE).

3.5 De SIP à ISUP

Dans ce scénario (l’origine de l’appel est dans le réseau SIP) la passerelle reçoit plusieurs INVITE qui ont le même identifiant d’appel mais ont des URI de demande différents. À réception du premier INVITE, la passerelle génère un IAM suivant les procédures décrites dans la [RFC3398].

Lorsque une passerelle reçoit un INVITE ultérieur avec le même identifiant d’appel et l’étiquette From du précédent, et un URI de demande mis à jour, un SAM devrait être généré plutôt qu’un nouvel IAM. À réception d’un INVITE suivant, l’INVITE reçu précédemment reçoit une réponse 484 Adresse incomplète.

Si la passerelle est rattachée au RTPC dans une zone où la signalisation en-bloc est utilisée, un REL devrait être généré pour l’IAM précédent et un nouvel IAM devrait être généré.

4. Considérations sur la sécurité

Lorsque la signalisation en chevauchement est employée, il est possible qu’un agresseur puisse envoyer plusieurs INVITE contenant une adresse incomplète à la même passerelle pour tenter d’occuper tous les accès disponibles et ainsi dénier le service aux appelants légitimes. Comme aucun de ces appels à adresse partielle ne va jamais s’achever, dans un schéma de facturation traditionnel, l’envoyeur des INVITE ne sera jamais taxé. Pour résoudre cette menace, les auteurs recommandent que les opérateurs de passerelle authentifient les envoyeurs de demandes INVITE, d’abord, afin d’avoir une forme de comptabilité de la source des appels (il est très imprudent de donner l’accès aux passerelles à des utilisateurs inconnus sur l’Internet) mais aussi, afin que la passerelle puisse déterminer quand des appels multiples sont générés de la même source dans une période brève. Une sorte de seuil de saisie d’appels se chevauchant devrait être établi par la passerelle, et après que la limite est excédée, les autres appels similaires devraient être rejetés pour empêcher la saturation des ressource de circuits de la passerelle.

5. Remerciements

Jonathan Rosenberg, Olli Hynonen, et Mike Pierce ont fourni d’utiles retours sur le présent document.

6. Références normatives

[Q.967] Recommandation UIT-T Q.967, "Application du sous-système utilisateur RNIS du système de signalisation CCITT n° 7 pour les connexions RNIS internationales", février 1991.

[Q.764] Recommandation UIT-T Q.764, "Système de signalisation n° 7 – procédures de signalisation du sous-système utilisateur RNIS", décembre 1999.

[RFC3261] J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC6665)

[RFC3398] G. Camarillo et autres, "Transposition du SSU RNIS en SIP", décembre 2002. (P.S.)

7. Propriété intellectuelle

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

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

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

8. Adresses des auteurs

Lyndon Ong

Ciena

5965 Silver Creek Valley Road

San Jose, CA 95138

USA

mél : lyong@ciena.com

9. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

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

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

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

Remerciement

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