Zusammenfassung

  • RFC 3015 definierte einen Context als gateway-lokale Verbindung von Terminations samt Medientopologie. Er war weder eine globale Anrufkennung noch das vollständige Protokoll eines Gesprächs.
  • TransactionReply, Audit und At-Most-Once-Ausführung belegten jeweils begrenzte Steuerungsereignisse. Externe Zustellung, Wiedergabe beim Empfänger und menschliche Verständigung benötigten eigene Nachweise.

Ein Controller weist ein Gateway an, einen leitungsvermittelten Kanal mit einem RTP-Strom zu verbinden. Das Gateway erstellt einen Context, vergibt eine Kennung und bestätigt Add. Damit ist etwas Reales geschehen: Die lokale Assoziation besteht. Ob am entfernten Ende ein Wort hörbar wurde, hat diese Antwort nicht beobachtet.

RFC 3015 erschien im November 2000 als Megaco Protocol Version 1.0 und teilte seinen Text mit ITU-T H.248. Das Protokoll verband einen Media Gateway Controller (MGC) mit einem physisch getrennten Media Gateway (MG). Der Controller bestimmte den gewünschten Verbindungszustand; das Gateway besaß die Medienressourcen und setzte Befehle um. Diese Aufteilung vereinheitlichte Steuerung, verteilte aber auch das Wissen.

Die Kennung gehörte zu einem Gateway

Das Verbindungsmodell beruhte auf zwei Objekten. Eine Termination erzeugte oder verbrauchte einen oder mehrere Medien- oder Steuerströme. Ein Context verband mehrere Terminations und beschrieb, wer wen hören oder sehen sollte. Bei größeren Gruppen kamen Misch- oder Vermittlungsparameter hinzu.

Die MG vergab den ContextID; eindeutig musste er nur innerhalb dieses Gateways sein. Darum war er ohne weitere Belege keine globale Kennung für Anruf, Teilnehmer, Abrechnung oder Gespräch. Ein Dienst konnte mehrere Gateways durchlaufen. Ein Context konnte nur eine Wartesituation, einen Konferenzabschnitt oder eine vorübergehende Medienanordnung darstellen.

Auch die Lebensdauer war lokal. Physische Terminations, etwa eingerichtete TDM-Kanäle, konnten langfristig bestehen. Ephemere Terminations für RTP-Flüsse existierten gewöhnlich nur während ihrer Nutzung. Der null Context enthielt physische Terminations, die mit keiner anderen verbunden waren. Add konnte implizit einen Context anlegen, Move verschob eine Termination, Subtract entfernte sie. Verließ das letzte Mitglied den Context, wurde er automatisch gelöscht.

Ein solches Objekt war kein unzuverlässiges Abbild. Es war präziser laufender Zustand. Gerade deshalb durfte es nicht als dauerhafte Chronik sämtlicher Ereignisse außerhalb des Gateways behandelt werden.

Topologie war keine Empfangsbestätigung

RFC 3015 trennte die Topologie eines Context vom Modus einer Termination. Topologie regelte Medienbeziehungen zwischen den Mitgliedern. Der Modus beschrieb den Fluss am Ein- oder Ausgang des Gateways.

Wenn die Topologie festlegte, dass T1 T2 hören konnte, war dies eine programmierte Beziehung im MG. Der entfernte Hörer hatte damit nichts bestätigt. Das Gateway konnte korrekt vermitteln und Pakete aussenden, die später verloren gingen. Das Ziel konnte sie empfangen, aber wegen Codec, Stummschaltung, falschem Ausgabegerät oder fehlender Wiedergabe keinen Ton erzeugen.

SDP konnte Sitzungsparameter beschreiben; RTP lieferte Sequenz, Zeitstempel und gegebenenfalls Empfangsberichte. Diese Quellen ergänzten einander. Sie verschmolzen Beschreibung, Konfiguration, Aussendung, Ankunft, Decodierung, Wiedergabe und Verstehen jedoch nicht zu einem einzigen Fakt.

Der Begriff „verbunden“ brauchte deshalb ein Subjekt. Verbunden konnte die lokale Context-Struktur sein. Daraus folgte noch nicht, dass der externe Pfad, das Zielgerät oder die Gesprächspartner denselben Zustand hatten.

Innerhalb der Transaction gab es Ordnung

Megaco gruppierte Commands in Actions und Actions in Transactions. Eine Action bezog sich normalerweise auf einen Context. Commands innerhalb derselben Transaction wurden der Reihe nach ausgeführt. Die TransactionReply enthielt Ergebnisse erfolgreicher Commands und den Fehler am Abbruchpunkt.

Zwischen verschiedenen Transactions entstand keine automatische Gesamtordnung. Ein MGC, der konsistent arbeiten wollte, musste eigene Regeln einhalten. Auf einer Termination sollte normalerweise höchstens ein Add, Modify oder Move ausstehen, außer die Commands lagen in derselben Transaction. Subtract durfte eingreifen. Ein Subtract mit Wildcard konnte ausstehenden Adds zuvorkommen und den Controller zu nachträglicher Bereinigung zwingen.

Damit war die Zuständigkeit geteilt. Das MG war Zeuge seiner lokalen Ausführung. Der MGC trug Verantwortung für die Reihenfolge der Absichten. Eine erfolgreiche Antwort belegte nicht, dass ein zweiter Controllerprozess dasselbe Anrufmodell besaß oder dass die nächste Transaction den Zustand erhalten würde.

TransactionPending sagte lediglich, dass Verarbeitung aktiv, aber nicht abgeschlossen war. Die Nachricht setzte einen Wiederholungstimer neu. Sie garantierte weder endgültigen Erfolg noch Ressourcen außerhalb des Gateways oder Medienfluss.

Ein Audit fror die Zeit nicht ein

AuditValue lieferte aktuelle Werte von Eigenschaften, Ereignissen, Signalen und Statistiken. AuditCapabilities lieferte mögliche Werte. Fähigkeit war nicht aktuelle Konfiguration, und aktuelle Konfiguration war nicht Dienstergebnis.

Bei Wildcards konnte eine Antwort die Vereinigung der Werte mehrerer Terminations enthalten. Das sparte Daten, verlor aber möglicherweise die Zuordnung. Eine Fähigkeit in der Vereinigungsmenge durfte weder jedem Mitglied noch dessen momentaner Nutzung zugeschrieben werden.

Entscheidend war die Zeitgrenze: AuditValue und AuditCapabilities unterlagen keiner Sequenzierung. Während ein Modify noch lief, konnte das Audit einen wahren Zustand vor oder nach der Änderung erfassen. „Aktuell“ bedeutete aktuell für die Beobachtung des MG, nicht linearisiert mit allen Transactions des Controllers.

Subtract konnte Statistiken über die Teilnahme einer Termination am Context zurückgeben. Dieser letzte lokale Beleg war nützlich. Er bewies dennoch nicht, wie viele Pakete das entfernte Ende erhielt, ob Sprache verständlich wiedergegeben wurde oder ob ein Gespräch stattfand.

At-Most-Once hatte einen Aufbewahrungsrand

Über UDP konnten Anfrage oder Antwort verloren gehen. Die meisten Commands waren nicht idempotent; ein zweimal ausgeführtes Add konnte den Gatewayzustand unvorhersehbar machen. RFC 3015 verlangte daher eine At-Most-Once-Funktion.

Die Gegenstellen speicherten jüngst gesendete Antworten und laufende Transactions. Sie verglichen TransactionID und Senderidentität mit diesem Gedächtnis. Für ein abgeschlossenes Duplikat wurde die gespeicherte Antwort erneut gesendet, ohne neu auszuführen. Für ein laufendes Duplikat wurde die zweite Ausführung unterdrückt; TransactionPending konnte den Stand anzeigen. Eine Response Acknowledgement erlaubte, die Antwort freizugeben, während die Kennung für LONG-TIMER erhalten blieb, um verspätete Kopien zu verwerfen.

Die Zusage hing von eindeutigen Kennungen, gespeichertem Zustand, Timer und laufender Epoche ab. Nach Ablauf oder Neustart sprach das alte Gedächtnis nicht weiter. Selbst bei perfekter Funktion bedeutete At-Most-Once nur, dass dieselbe Gateway-Transaction im Vergleichsfenster nicht zweimal ausgeführt wurde. Es bedeutete nicht, dass der Anruf genau einmal stattfand.

Auch TCP hob die Fehlergrenze nicht auf. Rund um Prozessausfall und Neuverbindung konnte Transaktionskontext verschwinden, weshalb die RFC weiterhin Anwendungslogik empfahl. Ein zuverlässiger Bytestrom rekonstruierte keinen verlorenen Context.

Geschützte Steuerung war kein Medienzeugnis

Unbefugte Megaco-Commands konnten Anrufe einrichten oder legitime Verbindungen stören. Für IP-Umgebungen verlangte die RFC Schutz und sah IPsec für Herkunftsauthentisierung, Integrität, Wiederholungsschutz und bei Bedarf Vertraulichkeit vor. Diese Sicherung schützte die Beziehung zwischen MGC und MG. Sie authentisierte nicht die Wiedergabe am entfernten Lautsprecher.

RFC 3525 ersetzte RFC 3015 im Jahr 2003. RFC 3435 führte MGCP als Informational-Spezifikation fort und verwies auf Megaco/H.248 als standardsbasierte Richtung. Diese Dokumente belegen Abstammung, nicht Implementierung eines Produkts, Verbreitung bei Netzbetreibern, Interoperabilität oder Erfolgsquote.

Die historische Leistung von RFC 3015 lag in einem bewusst begrenzten Objekt. Das Protokoll konnte eine lokale Verbindung benennen, erzeugen, verändern, prüfen und entfernen, Befehle dort ordnen, wo die Ordnung definiert war, und Duplikate in einem bekannten Fenster abwehren. Ein verbundener Context blieb ein starker Fakt. Er war nur nicht der ganze Anruf.

Quellen