Zusammenfassung

  • RFC 3624 erweiterte das MGCP-Audit von einem Endpunkt pro Anfrage zu einem Sammelbericht, der sich bei Erreichen der Datagrammgrenze fortsetzen ließ.
  • 200 OK bestätigte nicht, dass der gesamte angeforderte Bereich erfasst war: BA/NE markierte den Fortsetzungspunkt, BA/EL ordnete kompakte Zustands- oder Verbindungswerte den jeweiligen Endpunkten zu.

2003 war das Problem konkret: Nach dem Failover eines Call Agents musste dieser womöglich seinen Überblick über ein Gateway mit Hunderten oder Tausenden Endpunkten wiederherstellen. Die Audit-Befehle des MGCP-Basisprotokolls prüften jeweils nur einen Endpunkt. RFC 3624 ergänzte das Bulk-Audit-Paket, mit dem sich Gruppen abfragen, Namensschemata erkennen und ausgewählte Zustands- oder Verbindungsdaten zurückgeben ließen. Das Dokument hat den Status Informational. Sein IESG-Hinweis stellt MGCP der standardbasierten Megaco-Alternative aus RFC 3015 gegenüber. Das ist eine historische Wiederherstellungsschnittstelle, kein Nachweis einer Nutzung durch einen bestimmten Netzbetreiber. Zum Kontext gehören das frühe MGCP in RFC 2705 und MGCP 1.0 in RFC 3435.

Das Paket trennte Fragen, die ein großzügiger Platzhalter leicht vermischt. BA/Z fragte nach dem konfigurierten Namensschema; BA/X nach den aktuell instanziierten, nicht persistenten virtuellen Endpunkten. Ein Muster wie conference/* konnte also bestehen, obwohl nur eine lückenhafte Teilmenge angelegt war. Wer das Schema mit dem Inventar gleichsetzt, macht aus möglichen Namen eine Behauptung über den gegenwärtigen Bestand.

Für vorhandene Endpunkte lieferte BA/C die Anzahl der Verbindungen in Reihenfolge. Eine Hexadezimalziffer codierte null bis fünfzehn; Z bedeutete mehr als fünfzehn, aber keine genaue Zahl. BA/M fasste Verbindungsmodi zusammen. BA/S prüfte angeforderte Endpunktbedingungen und gab T, F oder O (außer Betrieb) zurück. Das ist eine logische ODER-Auswertung der Kriterien, keine vollständige Zustandsbeschreibung sämtlicher Verbindungen. Die RFC stellt ausdrücklich klar, dass die Endpunktzustandsanzeige nichts über den Verbindungszustand aussagt. Keiner dieser Werte beweist ein abgeschlossenes Gespräch, laufende Medien, eine funktionierende Anwendung oder erreichbaren Kundendienst.

Dann greift die Datagrammgrenze. Wenn der vollständige Bericht das maximale Datagramm überschreiten würde, darf das Gateway weniger Endpunkte als angefordert zurückgeben, muss aber BA/NE mit dem nächsten lokalen Endpunktnamen senden. Der Call Agent kann diesen Namen in einer weiteren Anfrage als BA/SE verwenden. Der Erfolgsstatus bestätigt diese Antwort; der Cursor zeigt, dass das größere Audit noch weitergeht. (RFC 3624, Abschnitte 2.1.1.1 und 2.1.1.7.)

Zähler und Zustände brauchten noch eine zweite Grenze: die Zuordnung. BA/EL musste vor einer BA/C- oder BA/S-Liste stehen und angeben, welche Endpunkte die Positionen bezeichneten. Gerade die Bereiche instanziierter virtueller Endpunkte konnten Lücken aufweisen. Ohne ihre Karte lässt sich ein formal gültiger Vektor dem falschen Objekt zuordnen. Werden Anzahl und Zustand gemeinsam angefordert, müssen beide dieselben Endpunkte umfassen. (RFC 3624, Abschnitte 2.1.1.8 und 2.1.2.)

RFC 3624 beschreibt die Fortsetzung eines großen Audits, aber keinen atomaren Snapshot über mehrere Anfragen. Die Seiten können Beobachtungen aus unterschiedlichen Zeitpunkten enthalten; eine gemeinsame Epoche, die sie einfriert, gibt es im Protokoll nicht. Ein Call Agent kann also eine nützliche Kontrollsicht zurückgewinnen, ohne Vollständigkeit, Gleichzeitigkeit oder erfolgreichen Dienst zu belegen. Als offengelegte analytische Linse — nicht als technische MGCP-Evidenz — passt dazu Heng Lus Essay über Running-Code Primacy.

Die Berichtssyntax bleibt bewusst bescheiden: Sie sagt, was das Gateway gemeldet hat, zu welchen Namen die Werte gehören und wo die nächste Anfrage ansetzt. Eine Kontrollabfrage wird dadurch nicht zum Ende-zu-Ende-Service-Test. Verbindungen, Medien, Anwendungen und Kundenergebnisse brauchen jeweils eigene Belege.