Résumé

  • Dans la RFC 3015, un Context associait des Terminations à l’intérieur d’une passerelle média et décrivait leur topologie ; il ne constituait ni l’identité universelle d’un appel ni son procès-verbal complet.
  • Les réponses de transaction, les audits et la protection « au plus une fois » prouvaient des faits locaux et bornés. La livraison distante, la restitution sonore et l’échange humain demandaient d’autres preuves.

Une commande Add peut réussir, deux Terminations peuvent apparaître dans le même Context et la topologie peut autoriser un flux dans les deux sens. Rien de cela n’est fictif. Pourtant, à l’autre extrémité, aucun son ne parvient nécessairement à l’auditeur. Le protocole a établi une association dans la passerelle ; il n’a pas observé toute la chaîne.

Cette différence est au cœur de la RFC 3015, publiée en novembre 2000 sous le titre Megaco Protocol Version 1.0. Le texte, commun avec la recommandation ITU-T H.248, organisait le dialogue entre un Media Gateway Controller (MGC) et une Media Gateway (MG) physiquement séparés. Il répondait aux exigences d’architecture de la RFC 2805. Son ambition était grande, mais son objet restait déterminé : commander les éléments locaux qui réalisent les connexions média.

Un Context n’était pas « l’appel »

Le modèle reposait sur deux noms. Une Termination produisait ou absorbait un ou plusieurs flux. Un Context associait plusieurs Terminations. Il décrivait qui pouvait entendre ou voir qui et, au-delà de deux participants, les paramètres de mélange ou de commutation.

Le ContextID était choisi par la passerelle et n’était unique que dans cette passerelle. Cette portée interdit de lui attribuer spontanément une identité commerciale ou humaine. Le même appel de signalisation pouvait mobiliser plusieurs équipements ; inversement, un Context pouvait servir une conférence, un appel en attente ou une association technique transitoire. Le protocole ne disait pas que le nombre local était un identifiant mondial de communication.

Le cycle de vie confirmait cette modestie. Les Terminations physiques, par exemple un canal TDM provisionné, pouvaient durer. Les Terminations éphémères représentant des flux RTP étaient normalement créées pour leur usage puis détruites. Le Context nul regroupait les Terminations physiques qui n’étaient reliées à aucune autre. Add pouvait faire naître implicitement un nouveau Context, Move déplacer une Termination et Subtract la retirer. Le départ de la dernière Termination supprimait implicitement le Context.

Un objet qui disparaît ainsi demeure un excellent état d’exécution. Il ne devient pas pour autant l’archive durable de la communication.

La topologie s’arrêtait à la frontière de la passerelle

La RFC distinguait deux dimensions souvent confondues. La topologie du Context définissait les relations internes entre Terminations. Le mode d’une Termination décrivait le flux au point d’entrée ou de sortie de la MG. Dire qu’une Termination « entend » une autre dans la topologie revenait à programmer une relation locale ; ce n’était pas recueillir le témoignage du destinataire.

Après cette relation, plusieurs événements restaient possibles. La MG pouvait émettre les paquets, mais le réseau pouvait les perdre. Le récepteur pouvait les recevoir sans les décoder, les décoder sans les restituer, ou les restituer sur une sortie muette. Une session SDP pouvait fournir des paramètres et RTP pouvait fournir ses propres séquences et rapports ; aucune de ces pièces ne se substituait à toutes les autres.

La bonne chaîne de preuve était donc plus longue : intention du contrôleur, commande admise, état local du Context, flux sortant, livraison du chemin, réception du terminal, restitution et résultat humain. Le mot « connecté » ne devait résumer que le maillon réellement observé.

L’ordre appartenait en partie au contrôleur

Megaco rangeait les Commandes dans des Actions, puis les Actions dans des Transactions. Une Action concernait normalement un seul Context. Les Commandes d’une même Transaction étaient exécutées dans l’ordre. La réponse retournait les résultats des opérations réussies et l’erreur rencontrée lorsque l’exécution échouait.

Entre Transactions différentes, le protocole ne fabriquait pas un ordre global. La RFC demandait au MGC soucieux de cohérence de respecter ses propres règles. Sur une Termination, il ne devait normalement y avoir qu’un Add, Modify ou Move en attente, sauf regroupement dans la même Transaction. Un Subtract pouvait néanmoins intervenir. Une suppression par joker pouvait dépasser des ajouts encore pendants, obligeant le contrôleur à nettoyer chaque Termination concernée.

La répartition du pouvoir était nette. La MG maîtrisait l’exécution locale et l’allocation de ses identifiants. Le MGC maîtrisait la suite des intentions. Une réponse positive ne prouvait pas que des processus de contrôle distincts partageaient le même état, ni que la prochaine Transaction conserverait la relation.

TransactionPending ne promettait pas davantage. Ce message signifiait que le travail continuait sans être achevé. Il réglait le comportement du minuteur et des reprises ; il ne réservait pas un chemin complet et ne constatait aucun média reçu.

L’audit était une observation, pas un arrêt du temps

AuditValue retournait les valeurs actuelles des propriétés, événements, signaux et statistiques. AuditCapabilities retournait les valeurs possibles. Une capacité décrivait ce que la Termination pouvait accepter, non ce qu’elle faisait à cet instant. Une valeur actuelle décrivait un état local, non la réussite du service.

Les jokers ajoutaient une subtilité. Une réponse pouvait réunir les valeurs de plusieurs Terminations. Cette union réduisait le volume d’échange, mais elle n’attribuait pas forcément chaque possibilité à un membre précis. Le périmètre de la question restait donc une partie du sens de la réponse.

Surtout, les deux formes d’audit n’étaient soumises à aucun séquencement. Si une modification était encore en cours, l’audit pouvait observer un état exact mais situé de l’autre côté de la décision que le contrôleur croyait mesurer. « Actuel » voulait dire actuel pour l’observation locale, pas instantané mondial ni linéarisé avec toutes les Transactions.

Lors d’un Subtract, la MG pouvait retourner les statistiques accumulées pendant la participation de la Termination au Context. Ce reçu était précieux avant la disparition de l’association. Il ne racontait pas si les paquets avaient atteint le terminal distant, si le son avait été intelligible ou si une conversation avait eu lieu.

« Au plus une fois » avait une mémoire et une durée

Sur UDP, une requête ou sa réponse pouvait disparaître. Or la plupart des commandes n’étaient pas idempotentes : répéter aveuglément un Add risquait de rendre l’état imprévisible. La RFC imposait donc une fonction d’exécution au plus une fois.

Chaque paire gardait les réponses récentes et les Transactions en cours. Elle comparait le TransactionID, dans la portée de l’identité émettrice, à cette mémoire. Un doublon déjà terminé recevait la réponse conservée ; un doublon encore actif n’était pas réexécuté et pouvait provoquer TransactionPending. L’accusé de réception autorisait ensuite la suppression de la réponse, tandis que l’identifiant restait conservé pendant LONG-TIMER afin d’écarter les copies retardées.

Cette propriété était bornée. Elle dépendait d’identifiants uniques, d’une mémoire disponible, d’une durée de conservation et de l’époque courante de la passerelle. Après redémarrage ou expiration, l’ancien historique ne détenait plus la même autorité. Même parfaite, la protection affirmait seulement qu’une Transaction locale n’avait pas été rejouée dans sa fenêtre. Elle n’affirmait pas qu’un appel avait été vécu exactement une fois.

Le recours à TCP ne supprimait pas le problème autour des pannes. La RFC recommandait encore une logique applicative de Transaction, car les requêtes ou réponses pouvaient se perdre lorsque les processus ou connexions changeaient d’époque. Transporter les octets avec fiabilité ne reconstituait pas l’état disparu.

Protéger la commande ne certifiait pas le service

Une instruction Megaco non autorisée pouvait établir ou interrompre des appels. La section de sécurité exigeait donc une protection, notamment IPsec dans l’environnement IP. Authentification d’origine, intégrité, anti-rejeu et confidentialité défendaient le canal de commande. Elles ne transformaient pas le MGC authentifié en témoin de l’écoute distante.

La RFC 3525 a remplacé la RFC 3015 en 2003. La RFC 3435 a poursuivi la lignée MGCP sur le plan informatif tout en orientant vers Megaco/H.248 pour l’approche normalisée. Ce sont des faits de filiation. Ils ne prouvent ni déploiement, ni conformité d’un produit, ni interopérabilité d’un opérateur.

La contribution historique de Megaco apparaît alors avec précision. Le protocole permettait de nommer, créer, déplacer, inspecter et supprimer une association locale, d’ordonner des commandes au bon endroit et de contenir les doublons. Il n’avait pas besoin d’appeler cette association « la conversation ». La discipline consiste justement à ne pas demander à un objet local de témoigner pour le monde entier.

Sources