Zusammenfassung

  • RFC 3525 garantierte die sequentielle Verarbeitung von Befehlen innerhalb einer Transaktion; verschiedene Transaktionen durften in beliebiger Reihenfolge oder gleichzeitig ausgeführt werden.
  • TransactionPending, Wiederholungsschutz, Antwortbestätigung und At-most-once-Verfahren belegten begrenzte Transportvorgänge, nicht die Kausalordnung zwischen Transaktionen oder den Medienerfolg.

Die Trennung begann in der Architektur. Der Media Gateway Controller hielt die Steuerlogik, das Media Gateway die mediennahen Ressourcen. Contexts verbanden Terminations; Actions bearbeiteten einen Context; Commands änderten oder prüften dessen Zustand.

Die Verschachtelung war sauber, aber nicht jede Klammer war eine Zeitschranke. Eine Message konnte mehrere Transactions tragen. Eine Transaction enthielt Actions. Erst innerhalb einer Transaction versprach das Protokoll eine eindeutige Befehlsfolge.

Commands wurden dort nacheinander ausgeführt. Beim ersten fehlerhaften, nicht optionalen Command endete die Verarbeitung der nachfolgenden Commands. Ein als Optional markierter Command durfte scheitern, ohne die restliche Folge zu stoppen.

Für Transactions galt das Gegenteil: Ihre Reihenfolge war nicht garantiert. Sie konnten vertauscht oder parallel ausgeführt werden. Das gemeinsame Verpacken in eine Message verlieh ihnen keine zusätzliche Abhängigkeit.

RFC 3525 bezeichnete die Message im Kern als Transportmechanismus. Requests A, B und C konnten gemeinsam eintreffen; Replies für A und C konnten zusammen zurückkehren, während B später folgte. Die äußere Reihenfolge war keine verborgene Sammeltransaktion.

Diese Freiheit schützte Parallelität. Verschiedene Terminations konnten von getrennten Prozessen oder Threads bearbeitet werden. Ein langsamer Vorgang musste unabhängige Ressourcen nicht aufhalten.

Abhängigkeiten musste der MGC selbst erkennen und ausdrücken. Auf einer Termination sollte normalerweise höchstens ein Add, Modify oder Move ausstehen, sofern die Commands nicht in derselben Transaction lagen. Wer erst hinzufügen und dann ändern wollte, musste beides zusammenfassen oder auf den ersten Beleg warten.

Subtract durfte jederzeit gesendet werden. Dadurch konnte ein früher abgesandtes Modify erst ankommen, nachdem die Termination entfernt war. Das MG sollte den Befehl ignorieren und einen Fehler liefern. Sendezeit und Zustandszeit waren verschiedene Achsen.

Auch Notify konnte einen alten Zustand nachtragen. Eine verzögerte Meldung mochte erst eintreffen, nachdem der MGC den EventsDescriptor geändert hatte. Bei UDP sollte pro Termination normalerweise nur ein Notify ausstehen. RequestID und angeforderter Ereigniszustand waren unverzichtbar.

Der Begriff Transaction versprach keine Datenbankatomizität. Scheiterte ein Command, sollte das MG den Zustand vor dem Versuch dieses Commands soweit wie möglich wiederherstellen. Eine Rücknahme aller zuvor erfolgreichen Commands wurde nicht zugesagt.

Die TransactionReply bewahrte diese Teilwirklichkeit. Sie enthielt Rückgabewerte erfolgreicher Commands und den Fehlerdeskriptor des gescheiterten Commands. Ein pauschales „fehlgeschlagen“ hätte angewandte, fehlgeschlagene und nie versuchte Arbeit vermischt.

Wildcard-TerminationIDs erzeugten mehrere Ergebnisse innerhalb eines Commands. Jeder Treffer wurde versucht und erhielt eine Antwort. Schlug ein Treffer fehl, unterblieben die nachfolgenden Commands. Erfolgreiche Treffer, ein Fehler und ein abgeschnittener Rest konnten nebeneinander stehen.

TransactionPending änderte daran nichts. Es meldete aktive, aber unvollendete Verarbeitung und setzte den Anwendungstimer zurück. Es sagte weder, welcher Command erreicht war, noch ob eine andere Transaction vorbeigezogen war.

Der Transportanhang löste Verlust und Wiederholung. TransactionIDs, gespeicherte Replies, Retransmissions und Response Acknowledgements unterstützten At-most-once-Verarbeitung. Eine Dublette zu erkennen bedeutete nicht, zwei eigenständige Transactions zu ordnen.

Authentisierung begrenzte eine weitere Frage: Wer sandte die Steuerung, und wurde sie verändert? Zwei authentische, unveränderte Commands konnten dennoch in einer unerwünschten Reihenfolge ausgeführt werden, wenn der Controller ihre Abhängigkeit nicht ausdrückte.

Selbst eine erfolgreiche Protokollantwort blieb vor dem Medienergebnis stehen. Ein Audit konnte Context- oder Termination-Eigenschaften lesen. Paketfluss, Decodierung, physischer Ton und menschliches Verstehen verlangten zusätzliche Beobachtung.

Auch der Status des Dokuments ist zeitgebunden. RFC 3525 ersetzte 2003 RFC 3015 und beruhte auf gemeinsamer Arbeit von IETF Megaco und ITU-T. RFC 5125 stufte ihn 2008 als Historic ein, weil H.248.1 unter ITU-T weiterentwickelt worden war. Der Mechanismus ist historische Evidenz, keine pauschale Aussage über heutige Anlagen.

Das IANA-Register für Megaco/H.248 besteht unter späteren Referenzen fort. Es koordiniert Package-Namen, Fehler, Gründe und Profile. Es belegt weder die laufende Version eines Gateways noch dessen tatsächliche Ausführungsfolge.

Die bleibende Regel lautet: Ordnung gehört an die kleinste echte Abhängigkeit. Unabhängige Terminations dürfen parallel laufen. Abhängige Commands gehören in dieselbe Transaction oder warten auf einen Beleg. Ein gemeinsamer Umschlag ist Koordination, keine Wirklichkeit.

Sources