Résumé

  • RFC 3435 donnait à chaque point terminal une seule NotifiedEntity, destinée à recevoir les commandes émises par la passerelle ; les réponses repartaient néanmoins vers la source de chaque commande.
  • Le basculement vers un agent de secours ne fournissait ni arbitrage entre contrôleurs, ni preuve de synchronisation complète, ni garantie que le média ou l’expérience de l’usager avaient continué.

Une destination n’était pas une autorité

Imaginons une passerelle d’accès dont l’agent d’appel ne répond plus. Un secours contacte les points terminaux et fournit une nouvelle NotifiedEntity. La passerelle sait désormais où envoyer son prochain événement. Elle ne sait pas pour autant si les deux contrôleurs partagent le même historique, si l’ancien reviendra avec un état concurrent, ni si le flux média a survécu.

C’est la frontière précise de RFC 3435, révision de MGCP 1.0 publiée en janvier 2003. Le texte brut, la notice RFC Editor, la fiche Datatracker, son historique, ses références et les errata prouvent le dossier documentaire, pas un déploiement ni un basculement réussi.

MGCP séparait l’intelligence d’appel, placée dans le Call Agent, des fonctions média exécutées par la passerelle. RFC 2705, remplacée par RFC 3435, supposait déjà que plusieurs agents se synchroniseraient sans définir le mécanisme. RFC 2805 formulait les exigences générales, tandis que RFC 3015 décrivait l’architecture Megaco/H.248 recommandée dans la note de l’IESG. RFC 3435 restait informative : sa précision ne prouve ni statut de norme Internet ni adoption universelle.

Ce que mémorisait le point terminal

Chaque point terminal possédait une entité notifiée courante. La dernière valeur explicite reçue l’emportait ; à défaut, une valeur provisionnée s’appliquait. Si aucune valeur n’existait et que le champ était vide, situation fortement déconseillée, la source de la dernière commande non audit devenait la destination. Un simple audit ne modifiait donc pas silencieusement le pointeur.

Mais les réponses suivaient la source de la commande, indépendamment de l’entité notifiée. Le texte admettait aussi que les commandes reçues par la passerelle puissent venir de n’importe quelle source. Il fallait donc conserver séparément : la destination des commandes de la passerelle, la source réseau d’une requête, la réponse renvoyée à cette source et l’autorité supposée du contrôleur. Les mots normatifs de RFC 2119 et la grammaire de RFC 2234 rendaient le fil précis sans combler l’absence d’arbitrage.

Plusieurs adresses, plusieurs états possibles

Un Call Agent était identifié par un nom de domaine et un port facultatif. Ce nom pouvait désigner plusieurs interfaces ou plusieurs machines formant un contrôleur logique. La passerelle essayait des adresses alternatives et ne devait pas fonder le basculement sur leur ordre DNS.

Cette indirection améliorait la joignabilité. Elle ne prouvait pas que les machines détenaient les mêmes connexions, la même séquence d’événements ou la même politique d’autorité. Une réponse DNS, un paquet reçu, un état répliqué et une relève légitime étaient quatre reçus différents.

Lorsque l’agent entier restait indisponible, les points terminaux finissaient par devenir « disconnected ». Un agent de secours pouvait les contacter avec une nouvelle entité notifiée. Le document supposait que l’ancien et le nouveau contrôleur communiqueraient et synchroniseraient leur état. Puis il reconnaissait explicitement qu’aucune résolution de conflit de relève entre agents séparés n’était fournie. AuditEndpoint pouvait lire la destination courante, pas reconstituer toutes les décisions ni désigner le titulaire légitime.

Auditer ou effacer

La déconnexion résultait d’une procédure bornée : retransmissions, repli exponentiel, adresses alternatives, rafraîchissement DNS, T-MAX puis deux fois T-HIST. Des délais aléatoires limitaient les avalanches de reprise. Le premier échange non audit devait signaler l’état déconnecté.

Informé, le contrôleur pouvait auditer le point terminal ou effacer toutes ses connexions. Auditer cherchait à rapprocher les états visibles ; effacer imposait une convergence destructive. Un accusé de succès ne prouvait ni continuité audio, ni absence de perte, ni expérience intacte. RFC 3661 clarifia ensuite l’usage des codes de retour, sans élargir leur portée jusqu’au résultat humain.

RFC 3991 ajouta un paquet de redirection et de réinitialisation ; RFC 3992 décrivit un mode lockstep limité. Les registres IANA des paquets MGCP et des LocalConnectionOptions conservent le vocabulaire coordonné. Aucun de ces registres ne mesure une mise en œuvre réelle.

La leçon durable

Le pointeur était nécessaire : sans destination, la passerelle ne pouvait rien notifier. Il demeurait insuffisant : la continuité exigeait l’autorité, la synchronisation, la réconciliation et l’observation du média.

La lecture ultérieure de Heng Lu sur les couches de réalité aide à ne pas attribuer au pointeur les preuves qu’il ne contient pas. La primauté du code exécuté distingue le mécanisme décrit de son résultat opérationnel. La spécification initiale minimale explique comment un noyau commun peut coordonner une destination tout en laissant l’arbitrage futur hors du protocole. Ce sont des lectures éditoriales rétrospectives, pas l’intention attribuée aux auteurs.

Sources