Résumé

  • RFC 3331 n’a pas déplacé un lien SS7 dans un terminal IP. MTP1 et MTP2 sont restés dans la passerelle de signalisation ; M2UA a transporté leur frontière avec MTP3 jusqu’au contrôleur distant.
  • Trois vérités sont demeurées indépendantes : l’association SCTP, l’activité de l’ASP et l’état du lien physique. Un voyant vert ne suffisait pas à prouver les deux autres.

L’utilisateur du lien était MTP3

L’expression « adaptation de l’utilisateur MTP2 » prête facilement à confusion. L’utilisateur est ici une couche de protocole. MTP3 est le seul utilisateur de MTP2. Dans l’architecture de rétrotransport, le circuit SS7, MTP1 et MTP2 se terminent dans un Signalling Gateway Process. MTP3 s’exécute plus loin, dans un Application Server Process hébergé par le Media Gateway Controller. M2UA transforme les primitives qui franchissaient autrefois une frontière locale en messages transportés sur SCTP.

Une unité de signalisation arrive donc sur une ligne réelle de la passerelle. MTP2 y assure ses fonctions de liaison. Le MTP3 distant ne possède pas une seconde ligne virtuelle : il reçoit les données et les indications d’état de la première, puis renvoie des demandes d’établissement, de libération, de récupération ou de transmission. La congestion et les pannes de processeur local ou distant traversent elles aussi cette frontière distribuée.

RFC 2719 avait posé le cadre SIGTRAN. Une passerelle rencontrait le réseau de signalisation à commutation de circuits, tandis que le contrôleur pouvait regrouper ailleurs la logique supérieure. RFC 3331 a choisi une coupure précise dans cette architecture. Ce n’était pas un tunnel indifférencié pour « SS7 sur IP », mais le déplacement de l’interface entre deux couches.

Cette précision change la lecture d’une panne. Le fil n’a pas bougé. Sa terminaison MTP2 n’a pas bougé. Ce qui a changé de lieu est le droit opérationnel de la couche supérieure à l’utiliser. En distribuant cette frontière, M2UA a aussi distribué les preuves nécessaires pour savoir si le service fonctionnait vraiment.

Un identifiant reliait une ressource physique à un chemin mouvant

La passerelle devait associer chaque Interface Identifier à une interface physique : ligne V.35, ligne T1 ou E1 et créneau temporel, par exemple. Elle devait aussi associer cet identifiant à une association SCTP et à un flux. Ces deux liens n’avaient pas la même stabilité. La relation avec la ligne était provisionnée. La relation avec l’association et le flux changeait lorsqu’un ASP devenait actif, se retirait ou était remplacé.

L’identifiant n’avait qu’une portée locale, coordonnée entre la passerelle et l’ASP. La valeur 17 vue dans une capture ne nomme pas universellement un circuit. Elle prouve qu’un pair a envoyé 17 dans ce contexte. Pour connaître la ligne visée, il faut aussi conserver la configuration qui liait cette valeur au port ou au créneau de la passerelle.

Les flux SCTP évitaient qu’un retard sur un lien bloque nécessairement les autres. Ils ne remplaçaient pourtant pas l’identifiant. Les flux SCTP sont unidirectionnels : le récepteur ne peut pas déduire le flux de retour à partir du seul flux d’arrivée. RFC 3331 a donc inclus l’Interface Identifier dans l’en-tête des messages MAUP. Le flux commun servait à la gestion, tandis que le trafic des liens devait être séparé.

La chaîne de contrôle comprenait ainsi plusieurs arêtes : ligne physique vers identifiant ; identifiant vers Application Server ; ASP actif vers association et flux. Une seule arête périmée pouvait donner au MTP3 distant une image différente de la réalité de la passerelle.

Une connexion, un processus et un lien avaient trois états

SCTP pouvait déclarer l’association établie. M2UA pouvait placer un ASP dans les états DOWN, INACTIVE ou ACTIVE pour un Application Server. MTP2 pouvait signaler que le lien était en service, hors service, congestionné ou touché par une panne du processeur distant. Ces états répondaient à des questions différentes.

Une association ouverte signifiait que les deux extrémités de transport se joignaient. Elle ne disait pas que l’ASP avait été activé pour l’identifiant concerné. ACTIVE indiquait que le processus avait été sélectionné selon un mode de trafic ; il ne certifiait pas la santé du câble. Et un lien SS7 sain ne garantissait pas qu’un contrôleur distant fût prêt à consommer ses messages.

RFC 3331 suivait aussi l’état de l’Application Server et une période PENDING lors de la récupération. Les modes Override, Loadshare et Broadcast déterminaient la répartition du trafic. Comme l’association dynamique pouvait devenir temporairement invalide pendant un basculement, la passerelle devait consulter les états AS et ASP pour chaque décision. Un seul SGP devait fournir le service de terminaison d’un lien donné, afin d’éviter deux propriétaires actifs du même support physique.

Confondre ces plans transforme un mécanisme de reprise en source d’erreur. Un basculement peut envoyer des messages vers un processus qui n’a pas encore réconcilié l’état du lien. Une application verte peut accumuler du trafic devant une ligne morte. Une ligne saine peut rester inutilisée parce qu’aucun ASP n’est prêt.

L’audit rétablissait un présent, pas toute l’histoire

STATUS_AUDIT permettait à l’ASP de demander l’état actuel du lien. La passerelle pouvait répondre hors service, en service, congestionné ou en panne de processeur distant. Après une reprise d’association ou une lacune dans les indications, cette réponse donnait au MTP3 distant un point de départ explicite.

L’audit reste un reçu daté. Il ne prouve pas qu’aucun événement n’est survenu ensuite et ne reconstruit pas les transitions perdues. Une enquête doit conserver la demande, la réponse, l’heure, l’identifiant, l’association, l’état de l’ASP et les indications suivantes. La formule « l’audit disait en service » n’est défendable qu’à ce moment et depuis ce point d’observation.

L’enregistrement dynamique ajoutait une autre séparation. Une Link Key pouvait être autorisée et recevoir un Interface Identifier. Le succès prouvait que la passerelle avait accepté la correspondance. Il ne prouvait ni l’état physique du lien, ni l’activation de l’ASP, ni le passage d’un trafic réel.

M2UA n’était pas M2PA

RFC 4165 a formulé la différence. Avec M2PA, chaque pair possède MTP3 et M2PA remplace MTP2 entre eux. Avec M2UA, le MTP3 du contrôleur utilise le véritable MTP2 de la passerelle grâce au transport des primitives de frontière. Les deux s’appuient sur SCTP, mais la propriété du lien et les pannes possibles ne sont pas les mêmes.

RFC 4666 pour M3UA et RFC 4233 pour IUA partagent des classes de messages et une gestion ASP. Cette parenté ne rend pas leurs frontières équivalentes. Une structure commune ne remplace pas l’analyse de la couche adaptée.

RFC 9260 est aujourd’hui la spécification SCTP de référence. Son existence ne démontre pas qu’un déploiement M2UA historique ait été mis à jour. De même, les registres IANA conservent l’identifiant de charge utile SCTP 2 pour M2UA et les classes MAUP et IIM. Ils prouvent des attributions, pas une utilisation actuelle ni une conformité.

La sécurité garde sa frontière. SCTP ne transforme pas un identifiant local en attestation de circuit. RFC 3788 a complété les considérations de sécurité SIGTRAN. L’opérateur devait encore authentifier les pairs, protéger les échanges selon sa politique et autoriser la correspondance avec la ligne. Une association fonctionnelle n’accorde pas, à elle seule, le droit d’actionner la ressource physique.

Conserver des reçus séparés

L’enseignement durable de M2UA tient à la séparation des preuves. Il faut conserver l’association et le flux SCTP, les états AS et ASP, la configuration de l’Interface Identifier, l’état MTP2 physique et le message de frontière qui portait l’ordre ou l’observation. Pour une question d’autorisation, il faut encore ajouter le contexte de sécurité.

RFC 3331 a rendu possible un contrôle distant en nommant précisément ce qui restait, ce qui traversait IP et ce qui devait les relier. Si ces pièces sont fusionnées, une simple connexion devient une fausse preuve de service téléphonique. Si elles restent distinctes, le basculement et l’audit peuvent être expliqués sans prétendre que le réseau IP a transporté le fil lui-même.

Sources