Zusammenfassung

  • RFC 3435 gab jedem Endpunkt genau eine aktuelle NotifiedEntity; sie bestimmte das Ziel gatewayseitiger Befehle, während Antworten weiterhin an die Quelle des jeweiligen Befehls gingen.
  • Eine Übernahme durch den Ersatzagenten bewies weder Konfliktlösung zwischen Call Agents noch vollständige Zustandsübertragung oder unterbrechungsfreie Medien. Audit, Löschen, Erreichbarkeit, Befugnis und Ergebnis blieben getrennt.

Ein Ziel war noch keine Übergabe

Fällt der Call Agent eines Gateways aus, kann ein Ersatz eine neue NotifiedEntity setzen. Das Gateway weiß danach, wohin es sein nächstes Notify schickt. Es weiß nicht automatisch, ob der Ersatz alle Verbindungsentscheidungen besitzt, ob der alte Agent mit einem widersprüchlichen Stand zurückkehrt oder ob der Audiopfad weiterlief.

RFC 3435 dokumentierte diese Grenze 2003. Textfassung, RFC-Editor-Eintrag, Datatracker, Historie, Referenzen und Errata belegen den Dokumentstand, nicht einen Einsatz.

MGCP trennte Call-Control-Intelligenz vom Medien-Gateway. Die abgelöste RFC 2705 nahm Synchronisation zwischen Agenten an, definierte sie aber nicht. RFC 2805 formulierte allgemeine Anforderungen; RFC 3015 beschrieb Megaco/H.248, das der IESG-Hinweis als standardbasierten Weg nannte. RFC 3435 war Informational und kein Nachweis universeller Einführung.

Der enge Inhalt des Zeigers

Der letzte explizite Wert blieb am Endpunkt; ohne ihn galt die Provisionierung. Fehlten beide und war der Wert leer, ein stark abgeratener Fall, wurde die Quelle des letzten Nicht-Audit-Befehls zum Ziel. Ein Audit allein änderte den Zeiger nicht.

Antworten folgten einer anderen Regel: Sie gingen unabhängig vom aktuellen Ziel an die Befehlsquelle. Befehle durften aus beliebiger Quelle eintreffen. Deshalb waren Ziel gatewayseitiger Befehle, Netzwerkquelle, Antwortweg und Controllerbefugnis verschiedene Tatsachen. RFC 2119 und die Grammatik aus RFC 2234 präzisierten die Leitung, nicht die Legitimität.

Ein DNS-Name konnte mehrere Schnittstellen oder Rechner eines logischen Agenten bezeichnen. Das Gateway musste Alternativen versuchen und durfte Failover nicht von der DNS-Reihenfolge abhängig machen. Mehr Erreichbarkeit bedeutete aber nicht identische Verbindungslisten, Ereignisfolgen oder Autorisierungsregeln.

Die ausdrücklich fehlende Schlichtung

Nach Wiederholungen, exponentiellem Backoff, alternativen Adressen und den Grenzen T-MAX und T-HIST konnte ein Endpunkt disconnected werden. Ein Ersatzagent durfte ihn mit neuem Ziel kontaktieren. RFC 3435 nahm an, dass alter und neuer Agent kommunizieren und synchronisieren würden. Zugleich erklärte der Text, dass keine Konfliktlösung für die Übergabe zwischen getrennten Call Agents vorhanden sei.

AuditEndpoint konnte den aktuellen Zeiger lesen, nicht jede frühere Entscheidung rekonstruieren oder den rechtmäßigen Controller bestimmen. Ein einzelner Datenbankwert ist kein verteilter Konsens über seine Herkunft.

Nach der Disconnect-Meldung konnte der Controller auditieren oder alle Verbindungen löschen. Audit suchte Abgleich; Löschen erzwang Konvergenz durch Verlust. Ein erfolgreicher RestartInProgress belegte keinen hörbaren, ununterbrochenen Anruf. RFC 3661 klärte Rückgabecodes, ohne sie zu Nutzerergebnissen zu erweitern.

RFC 3991 ergänzte Redirect und Reset, RFC 3992 einen begrenzten Lockstep-Modus. Die IANA-Register für MGCP-Pakete und LocalConnectionOptions belegen koordiniertes Vokabular, nicht korrekte Laufzeit.

Die bleibende Grenze

Heng Lus spätere Analyse der Realitätsebenen verhindert, dass der sichtbare Zeiger fehlende Autorität leiht. Running-Code-Primat trennt Entwurf und Betrieb, während die minimale Anfangsspezifikation erklärt, warum ein gemeinsamer Kern nur das Ziel koordinieren kann. Das sind rückblickende redaktionelle Anwendungen.

Der Zeiger war nötig, damit der nächste Befehl ein Ziel hatte. Kontinuität verlangte zusätzlich Befugnis, Zustandssynchronisation, Konfliktregeln und Medienbeobachtung.

Quellen