Résumé

  • La RFC 3057 séparait la terminaison physique du canal D RNIS du lieu de traitement des appels Q.931 : la passerelle de signalisation terminait Q.921 et IUA acheminait les primitives de cette frontière vers un serveur d’applications par SCTP.
  • Le basculement entre processus ASP pouvait rediriger la signalisation, mais la reprise du transport ne restaurait pas l’état de l’appel. La RFC 4233, qui a remplacé la RFC 3057, indique que les appels en cours de transition peuvent échouer si les processus applicatifs ne partagent pas leur état en dehors d’IUA.

Déplacer la couche supérieure, pas le câble

Dans une architecture RNIS classique, le canal D transporte la signalisation qui permet aux terminaux d’établir et de gérer des appels à commutation de circuits. Q.921 fournit le service de liaison de données ; Q.931 et QSIG s’appuient sur ce service. Publiée en février 2001, la RFC 3057 a utilisé cette frontière pour séparer les lieux d’exécution.

La passerelle de signalisation (SG) recevait la signalisation depuis une interface RNIS standard et terminait Q.921. Un contrôleur de passerelle de médias (MGC), côté IP, hébergeait la couche Q.931 homologue et le traitement des appels. Entre les deux, la couche d’adaptation des utilisateurs de Q.921 — IUA — transportait les primitives de la frontière au moyen de SCTP. Ce n’était pas la transformation du câble d’abonné, du canal D ou de chaque circuit en objet IP : la passerelle conservait l’interface physique et la couche Q.921 locale.

La distinction avait des conséquences concrètes. La primitive DL-DATA transporte un message Q.931 ; l’établissement, la libération et les données non acquittées correspondent à d’autres issues de la liaison. IUA devait donc préserver l’identité de l’interface et le sens de chaque primitive. Le contrôleur distant pouvait traiter les messages d’appel sans prétendre avoir repris le canal D lui-même.

Un identifiant d’interface, une correspondance locale

L’identifiant d’interface reliait un message à l’interface physique concernée sur la SG. Sa représentation pouvait être un entier ou du texte, mais sa signification restait locale : la passerelle et son serveur d’applications coordonnaient la valeur. La RFC ne lui donnait aucune portée entre passerelles distinctes. Ce qui ressemblait à un nom de réseau était en réalité une clé de correspondance locale entre contextes de signalisation.

La SG associait cet identifiant à un serveur d’applications et à un processus ASP actif. Un serveur d’applications pouvait être un service logique composé d’une liste ordonnée d’ASP — contrôleur principal, secours et autres instances. La passerelle devait connaître le processus actif pour chaque interface ; cette affectation pouvait changer lors d’un basculement.

La RFC 3057 recommandait SCTP et un flux SCTP distinct par canal D, afin de réduire l’attente et le retard de mise en tampon entre canaux indépendants. Le flux restait une fonction de transport : l’identifiant d’interface précisait toujours à quelle interface physique se rapportait le message. État de l’association, séquencement du flux, correspondance locale et état actif de l’ASP étaient liés, mais aucun ne remplaçait les autres.

Un basculement ne partage pas l’historique des appels

Le modèle autorisait plusieurs choix de redondance. Une configuration 1+0 n’avait aucun ASP de secours ; en 1+1 actif/secours, un processus traitait le trafic et un autre pouvait prendre la relève. Le modèle plus général n+k décrivait n processus nécessaires à la charge et k processus disponibles pour remplacer ceux qui devenaient indisponibles. Les messages IUA permettaient à la SG et aux ASP d’échanger leur état et d’orienter la signalisation.

Mais une association encore active avec le processus de secours ne prouve pas qu’il connaît l’état d’un appel déjà en cours d’établissement. La RFC 4233, qui a remplacé la RFC 3057 en 2006, rend explicite cette différence. Dans un réseau de niveau opérateur, la panne d’un ASP ne DEVRAIT PAS libérer les appels stables ; atteindre cet objectif peut exiger que les ASP partagent l’état des appels. Les appels en cours de transition PEUVENT échouer. Une mémoire partagée ou un protocole ASP-à-ASP peut réduire ce risque, mais ce protocole est hors du périmètre d’IUA.

Ce n’était pas une faiblesse cachée de SCTP. SCTP peut rendre compte de l’état d’une association, séquencer des messages dans chaque flux et prendre en charge le multihoming. Ce sont des propriétés du transport ; elles n’indiquent pas au contrôleur de secours quelles décisions d’appel ont déjà été prises, quels messages sont arrivés au correspondant, ni si l’appel était stable ou encore en transition. IUA pouvait déplacer le chemin de signalisation ; la continuité applicative restait une responsabilité distincte.

Ce que la norme change — et ce qu’elle ne prouve pas

La RFC 3057 a fourni à l’architecture SIGTRAN une adaptation définie pour les utilisateurs de Q.921. Elle rendait possible un traitement des appels réparti sur un raccordement IP tout en conservant une frontière standard vers le réseau commuté. En 2006, la RFC 4233 l’a remplacée en affinant la même adaptation. Cette chronologie montre l’évolution des normes ; elle ne prouve ni quels opérateurs l’ont déployée, ni quels équipements ont été achetés, ni combien d’appels ont survécu à une panne réelle.

La leçon d’ingénierie est plus étroite que « la téléphonie est passée à IP ». Une frontière de service peut se déplacer alors que l’interface physique reste ailleurs. Terminaison de la liaison, adaptation des primitives, association de transport, processus destinataire et état applicatif doivent être vérifiés séparément. Une association SCTP rétablie ou un ASP actif ne constitue pas un reçu d’achèvement d’appel.

Sources