Résumé

  • La RFC 3372 confiait deux fonctions distinctes à SIP-T : encapsuler ISUP pour préserver la signalisation téléphonique, puis traduire certains paramètres en éléments SIP visibles par les mandataires chargés du routage.
  • La conservation ne prouvait ni le bon acheminement ni le service final ; l’acheminement ne prouvait ni la reconstruction fidèle d’ISUP, ni l’établissement du média, ni l’expérience de l’usager.

En 2002, le problème n’était pas seulement de faire passer une voix sur IP. Il fallait traverser un réseau SIP sans effacer les informations par lesquelles le réseau téléphonique traditionnel produisait ses services. La RFC 3372, publiée comme BCP 63, appela cet ensemble de pratiques SIP-T et précisa aussitôt qu’il ne s’agissait pas d’un nouveau protocole.

Une passerelle d’origine recevait un message ISUP. Elle l’insérait dans le corps MIME de la requête SIP afin qu’une passerelle distante puisse retrouver les paramètres hérités. La RFC 3204 définissait les types de média nécessaires. Cette encapsulation visait la transparence des fonctions : conserver ce que le monde SS7 avait effectivement dit.

Mais un mandataire SIP ne devait pas comprendre toutes les variantes ISUP. Pour acheminer la requête, il lui fallait des éléments SIP visibles, notamment l’adresse de destination. La passerelle traduisait donc certains paramètres ISUP dans l’URI et les en-têtes. Cette seconde opération visait la routabilité.

Les deux voies pouvaient diverger. Un corps ISUP parfaitement conservé pouvait accompagner un numéro mal traduit et parvenir à la mauvaise sortie. Une requête correctement orientée pouvait perdre son corps, rencontrer une variante inconnue ou atteindre une passerelle incapable de restituer une fonction. La conformité d’un contenant n’était pas le reçu de son interprétation.

À la sortie, la passerelle pouvait utiliser ISUP comme modèle, remplacer les valeurs traduites depuis SIP et appliquer sa politique locale. Sans corps ISUP, elle pouvait partir d’un modèle canonique configuré. La signalisation émise vers le PSTN était donc une reconstruction traçable, non la simple réapparition du message d’entrée.

La destination finale n’était pas toujours connue au départ. Un appel venant du PSTN pouvait terminer sur un téléphone SIP ; celui-ci ignorait normalement ISUP mais devait accepter proprement le multipart et les types inconnus. Un téléphone SIP initiateur, lui, n’avait aucune raison de fabriquer ISUP au cas où l’appel finirait plus tard dans le PSTN. Les règles MIME de la RFC 2046 et le cadre SIP de la RFC 3261 rendaient cette coexistence possible.

Les informations ISUP en cours d’appel posaient un autre problème : elles pouvaient ne modifier ni l’état de la session ni ses paramètres. SIP-T s’appuyait alors sur la méthode INFO de la RFC 2976. Transporter l’indication ne démontrait pourtant pas qu’une application l’avait comprise ou qu’un service visible avait été rendu.

TRIP, décrit par la RFC 3219, et ENUM, alors défini par la RFC 2916, pouvaient contribuer au choix d’une destination. Ils ne remplaçaient pas le contexte de service conservé dans ISUP. De même, la signature S/MIME exigée par SIP-T, dans la lignée de la RFC 2633, protégeait un objet transporté sans certifier la qualité de la traduction, la légitimité de la politique locale ou l’issue de l’appel.

La RFC 3398 détailla ensuite la correspondance SIP–ISUP. La RFC 3326 donna à SIP un champ Reason pour porter une cause qualifiée par protocole : expliquer une action n’était pas l’exécuter. Les RFC 3331 et 3332 traitaient, elles, du déplacement de fonctions SS7 sur SCTP. Elles sont voisines, mais leur question diffère : SIP-T organise les deux représentations nécessaires à un même appel.

Les archives officielles n’établissent ni part de marché, ni déploiement nommé, ni conservation effective des fonctions. Elles établissent une architecture intellectuellement honnête. La passerelle ne convertissait pas une vérité complète en une autre. Elle maintenait un enregistrement opaque pour le destinataire compétent et un enregistrement lisible pour les acteurs intermédiaires.

Les deux essais de Lu Heng renforcent cette lecture. « Minimum Initial Specification » invite à normaliser le noyau commun sans masquer les décisions locales. « On Reality Layers » interdit de confondre signal reçu, objet encapsulé, en-tête traduit, route choisie, signal reconstruit et expérience réelle. La RFC 3372 appartient à l’histoire de l’Internet précisément parce qu’elle a rendu cette frontière exploitable sans prétendre l’abolir.

Sources