Résumé

  • Dans RFC 3525, les commandes d’une même transaction étaient séquentielles, tandis que deux transactions pouvaient être traitées dans un ordre quelconque ou en parallèle.
  • Un message Pending, un accusé de réponse ou la protection « au plus une fois » bornait un fait de transport ; aucun ne prouvait l’ordre causal complet ni le résultat média.

Le mot « transaction » suggère volontiers une opération indivisible. Le texte de 2003 décrivait autre chose : une unité d’ordonnancement entre un Media Gateway Controller et un Media Gateway, avec des réponses détaillées, des arrêts sur erreur et une concurrence assumée hors de cette unité.

L’architecture séparait déjà la décision et l’exécution. Le contrôleur pilotait les Contexts ; la passerelle détenait les Terminations et les ressources média. Une Action visait un seul Context. Les commandes Add, Modify, Move, Subtract ou Audit traduisaient les décisions en changements locaux observables.

À l’intérieur d’une transaction, la règle était forte : les commandes s’exécutaient l’une après l’autre. La première erreur non optionnelle interrompait la suite. Une commande marquée Optional pouvait échouer sans empêcher les commandes suivantes. La position dans cette liste avait donc un effet réel.

La frontière s’arrêtait là. RFC 3525 refusait de garantir l’ordre des transactions. La passerelle pouvait traiter la seconde avant la première ou les deux simultanément. Cette liberté permettait à plusieurs processus de commander des Terminations indépendantes sans attendre une file globale.

Le message n’ajoutait aucune hiérarchie temporelle. Il transportait des transactions indépendantes et ne recevait pas lui-même d’accusé applicatif. Une requête contenant A, B et C pouvait provoquer une réponse regroupant A et C, puis une autre pour B. L’apparence linéaire de l’encodage ne formait pas un calendrier.

Imaginons alors qu’A crée une Termination et que B, transaction distincte, la modifie. L’émission d’A avant B ne prouvait pas que la passerelle avait créé la Termination avant de traiter B. Le contrôleur devait soit placer les commandes dépendantes dans la même transaction, soit attendre le reçu qui rendait la suite légitime.

Le document transformait cette prudence en règle d’exploitation : pour une Termination, il ne devait normalement rester qu’une seule commande Add, Modify ou Move en attente, sauf si les commandes figuraient dans la même transaction. La concurrence restait disponible ailleurs ; la dépendance devait être localisée.

Subtract compliquait délibérément l’histoire. Cette commande pouvait être envoyée à tout moment. Une Modify, pourtant émise plus tôt, pouvait atteindre une Termination déjà supprimée. La passerelle devait l’ignorer et renvoyer une erreur. Le journal d’envoi ne suffisait donc pas à reconstruire l’état.

Les notifications rendaient la course symétrique. Un Notify retardé pouvait arriver après qu’un nouveau EventsDescriptor avait été envoyé. Sur UDP, qui ne garantit pas la livraison séquentielle, RFC 3525 recommandait au plus un Notify en attente par Termination. Il fallait rattacher l’événement à son RequestID, à sa Termination et à sa transaction.

L’échec au sein d’une transaction n’était pas non plus un retour arrière global. La passerelle devait rétablir, autant que possible, l’état antérieur à la tentative de la commande fautive. Le texte ne promettait pas d’annuler les commandes précédentes déjà réussies. La TransactionReply conservait précisément leurs valeurs de retour et l’erreur de la commande défaillante.

Un identifiant de Termination générique pouvait produire plusieurs réalités dans la même commande. La passerelle essayait chaque correspondance et répondait pour chacune. Si l’une échouait, les commandes suivantes n’étaient pas tentées. Une étiquette « transaction en échec » aurait effacé la différence entre les correspondances réussies, l’erreur et le travail jamais commencé.

TransactionPending ne comblait pas ce manque. Il indiquait seulement qu’une transaction restait en cours et relançait la minuterie applicative. Il ne révélait ni la dernière commande exécutée, ni l’état qui survivrait, ni la place occupée par les autres transactions.

L’annexe de transport visait encore un autre risque : la perte d’une réponse pouvait provoquer une répétition. Les identifiants, la conservation des réponses, les retransmissions et les accusés aidaient à offrir un traitement au plus une fois. Éviter un doublon n’ordonnait pas deux intentions différentes.

Même la réponse finale restait un reçu intermédiaire. Elle attestait le traitement protocolaire et pouvait être complétée par un Audit des propriétés. Elle ne prouvait pas que le chemin média transportait les paquets, qu’un décodeur produisait du son ou qu’un interlocuteur entendait la conversation.

La chronologie institutionnelle interdit aussi de figer le document. RFC 3525 remplaça RFC 3015 et incorpora les corrections du travail commun IETF Megaco–UIT-T. RFC 5125 le classa Historic en 2008, l’UIT-T ayant poursuivi H.248.1. Il reste une source historique pour cette frontière d’ordre, non la description universelle des déploiements actuels.

Le registre IANA Megaco/H.248 subsiste avec des références plus récentes. Il prouve la coordination durable des noms de paquets, codes et profils. Il ne révèle ni la version exécutée par une passerelle ni l’ordre réel de ses transactions.

La leçon est une discipline de preuve : partager le minimum commun, puis renforcer localement ce qui dépend réellement d’un état antérieur. Les Terminations indépendantes peuvent avancer ensemble. Les commandes dépendantes doivent partager une transaction ou attendre un reçu. L’enveloppe ne doit jamais être promue en horloge.

Sources