Zusammenfassung

  • RFC 3149 ließ einen entfernten MGCP Call Agent Nummern von Funktionstasten interpretieren, Beschriftungen und Lampen setzen, den Hook-Zustand erzwingen und eine XML-Anzeige steuern; die Meldung einer Taste blieb dennoch von Zuordnung und Anrufergebnis getrennt.
  • Weil der Anzeigezustand der Telefonsignalisierung zeitlich vor- oder nachlaufen konnte, erhielt die Anzeige einen eigenen Endpunkt mit dem Präfix disp/; gemeinsam genutzte Tasten gelangten zunächst an die XML-Schicht.
  • Klingel-, Hörer- und Freisprechlautstärke, der unmittelbare Wechsel des Audiowegs sowie Mikrofonstummschaltung und Kontrollleuchte blieben lokal. Externe Intelligenz beseitigte die physische Grenze des Endgeräts nicht.

Auf der Leitung stand eine Nummer, keine Geschäftsfunktion

Das Media Gateway Control Protocol ging von einer klaren Arbeitsteilung aus. Die Logik der Anrufsteuerung lag in einem Media Gateway Controller, meist Call Agent genannt; das Gateway setzte Ereignisse und Signale am Rand um. Für einen einfachen analogen Anschluss genügte ein kleiner Vorrat. Ein Geschäftstelefon brachte dagegen Halten, Weiterleiten, Wahlwiederholung, Konferenz, Nachrichtenanzeigen, programmierbare Tasten, Display, Softkeys, Lautsprecher und Stummschaltung mit.

RFC 3149 ergänzte dafür drei Paketfamilien. Feature Key (KY) beschrieb Nicht-DTMF-Tasten sowie deren Anzeigen und Beschriftungen. Business Phone (BP) definierte erzwungenes Abheben und Auflegen sowie einen Signalton. Display XML stellte eine kleine Schnittstelle zwischen Call Agent und Bildschirm bereit.

Das Tastenereignis war bewusst elementar. Das Telefon konnte melden, dass Taste 1 gedrückt worden war. Erst die im Call Agent aktive Programmierung machte daraus Halten, Weiterleiten, eine Leitungsbelegung oder etwas anderes. Bei einem anderen Modell konnte Halten auf Taste 23 liegen; womöglich fehlte die betreffende Taste ganz. Die physische Geste besaß daher keine modellübergreifend feste geschäftliche Bedeutung.

Für Belege ist diese Trennung entscheidend. Eine gültige Notification beweist, dass ein Endpunkt innerhalb einer angeforderten Ereignismenge eine Tastennummer gemeldet hat. Die Aussage „die Nutzerin drückte Halten“ verlangt die zu diesem Zeitpunkt aktive Zuordnung. Die Aussage „der Anruf wurde gehalten“ verlangt zusätzlich die Entscheidung des Call Agents, die ausgelösten Signale, den Übergang der Signalisierung und ein beobachtbares Medienergebnis.

Ein einzelnes Feld button=hold verschluckt diese Unterschiede. Ein belastbarer Beleg verbindet Telefonmodell und Firmware, Mapping-Version, Tastennummer, RQNT und NTFY, Entscheidungszweig, Signalisierung und Medienwirkung, ohne sie zu einer scheinbar atomaren Tatsache zu machen.

Beschriftung und Lampe waren Ausgaben

Der Call Agent konnte eine Tastenanzeige ein- oder ausschalten und bei geeigneter Anzeige freien Text neben einer Taste setzen. So konnte ein allgemeines Endgerät wie ein Geschäftstelefon wirken, dessen Bedienoberfläche sich mit der Anwendung änderte.

Damit entstand zugleich eine Naht zwischen Darstellung und Betrieb. Eine Aufschrift „Halten“ konnte nach einer geänderten Zuordnung stehen bleiben. Eine Lampe konnte leuchten, weil ein Signal angenommen worden war, obwohl die gewünschte Funktion scheiterte. Eine Taste konnte korrekt berichten, während die Person einen anderen Text las oder den benachbarten Knopf traf. Erfolgreiches Rendern war keine Quittung für einen erfolgreichen Anrufvorgang.

Das Dokument zielte auf eine minimale Menge niedrigstufiger Ereignisse und Signale. Unnötiger oder doppelter Verkehr sollte vermieden werden. Wenn der Call Agent nur wissen musste, dass gedrückt worden war, brauchte er nicht zwingend sowohl Druck als auch Loslassen gemeldet zu bekommen. Die schmale Drahtschnittstelle lieferte deshalb kein vollständiges Protokoll der Handbewegung, der Entprellung oder des Sichtfelds.

Die Beweiskette hält Lage und Nummer der Taste, aktive Zuordnung, sichtbare Beschriftung, Lampenzustand, Transaktionen, Entscheidung, Signalisierung, Medienpfad und sichtbares Ergebnis getrennt. Räumliche Nähe auf dem Gehäuse ersetzt keinen Join-Schlüssel.

Das Display bekam eine eigene Identität

Die Anzeige war in RFC 3149 nicht bloß Schmuck am Signalisierungsautomaten. Ihr Zustand konnte asynchron zur Telefonsignalisierung sein. Deshalb sollte sie einen eigenen MGCP-Endpunktnamen erhalten: Dem Namen des Telefonendpunkts wurde disp/ vorangestellt.

Das Beispiel im RFC zeigt den Grund. Ein Anruf trifft ein und klingelt, während das Display eine sofortige Weiterleitung an die Sprachmailbox anbietet. Eine Auswahl erzeugt einen XML-Post und kann Klingel-Timer abbrechen. Doch das Anzeigen der Option, der Tastendruck, das Eintreffen des Ereignisses, das Löschen eines Timers, die Signalisierungsänderung und die Erfahrung der Gegenstelle sind verschiedene Vorgänge mit verschiedenen Uhren.

Der Call Agent konnte auf Deck und Card verweisen, Ersetzungswerte liefern und Eingaben oder Auswahl empfangen. Karten konnten Text, Listen, Eingabefelder, Timer und Navigation enthalten. Teilten sich Display und Telefon eine Taste, sah die XML-Schicht den Druck zuerst. Sie verbrauchte ihn oder gab ihn an die Telefonschicht weiter.

Priorität bei der Zustellung war keine Autorität über das Ergebnis. Dass ein Skript eine Ziffer verbrauchte, bewies eine lokale Weiterleitungsentscheidung; es bewies weder die richtigen Pixel noch die Zustellung an den richtigen Controller noch die gewünschte Anrufänderung. Der separate Endpunkt machte asynchronen Zustand adressierbar, aber nicht automatisch konsistent.

Hersteller und Modell ersetzten keine Bestandsaufnahme

Der Call Agent musste wissen, welche Tasten und Anzeigefähigkeiten ein Telefon besaß. Eine vollständige Entdeckung wäre denkbar gewesen. Das Dokument wählte mit X-UA einen einfacheren experimentellen Parameter, der eine eindeutige Hersteller- und Modellzeichenfolge anforderte. Daraus konnte der Controller ein bekanntes Fähigkeitsprofil auswählen.

Die Zeichenfolge war ein sparsamer Index, keine Hardwarebeglaubigung. Sie konnte wegen fehlender Unterstützung ignoriert werden, gegenüber der Firmware veraltet sein, auf ein unvollständiges Profil zeigen oder nicht zu ausgetauschten Komponenten passen. Sie bewies weder Tastaturgeometrie noch Displaygröße, Lampenverdrahtung oder funktionierendes Audiogerät.

Das X markierte zudem eine Kompatibilitätsgrenze. Ein Gateway, das den experimentellen Parameter nicht verstand, sollte ihn ignorieren, statt den gesamten Vorgang abzulehnen. Eine ausbleibende Antwort bedeutete deshalb Ungewissheit, nicht ein Standardlayout. Ein Controller brauchte einen begrenzten Fallback, keine erfundenen Fähigkeiten.

Eine prüfbare Inventur bewahrt die gelieferte Zeichenfolge gemeinsam mit Geräteidentität, Firmware, Version des Fähigkeitsprofils und einer Beobachtung der realen Oberfläche. Eine Klasse kann Verhalten auswählen; laufende Hardware kann ihr widersprechen.

Die Hand behielt unmittelbare Gewalt

Abschnitt 4 zieht die schärfste Grenze. Klingel-, Hörer- und Freisprechlautstärke sollten lokal im Gateway implementiert werden. Bei aktivem Freisprecher sollte eine Nutzerin den Hörer aufnehmen, dorthin wechseln und später zum Freisprecher zurückkehren können, ohne mit dem Call Agent zu interagieren. Auch Mikrofonstummschaltung und ihre optionale Lampe sollten lokal sein.

Das widersprach dem Modell externer Intelligenz nicht; es bestimmte dessen Reichweite. Der Call Agent interpretierte Funktionen, deren Bedeutung zur Anrufanwendung gehörte und sich ändern konnte. Das Endgerät behielt Vorgänge, bei denen ein Mensch sofort auf den physischen Audioweg einwirken musste. Zentralisierung der Semantik wurde nicht zur Zentralisierung jeder Ausführung.

Man könnte Gründe wie geringe Latenz, Ausfallsicherheit, Privatsphäre oder Sicherheit ergänzen. Sie mögen als Designvorteile plausibel sein, doch der RFC liefert weder Messwerte noch eine vollständige Fehlertheorie. Belegt ist die engere Aussage: Diese Funktionen wurden lokal zugewiesen, und der Wechsel zwischen Hörer und Lautsprecher sollte ausdrücklich ohne Controllerkontakt funktionieren.

Auch lokal bedeutete nicht automatisch richtig. Der Druck auf Mute war nicht der Stummschaltzustand; die Lampe war nicht die Unterdrückung des Audios; ein intern gewählter Audioweg war nicht der Beweis dessen, was die Gegenstelle hörte. Physische Eingabe, lokaler Zustand, Anzeige und Medienresultat blieben eigene Realitätsschichten.

Ein Fernbefehl konnte vor Ort aufgehoben werden

Das BP-Paket konnte einen Freisprecher zwangsweise off-hook oder on-hook setzen und einen Signalton auslösen. So ließ sich etwa eine am Computer ausgewählte Nummer in einen Anruf überführen. Zugleich stellte die Spezifikation fest, dass der Nutzer ein erzwungenes Abheben durch Auflegen aufheben konnte.

Dieses Detail verhindert die Erzählung vom allmächtigen Controller. Eine entfernte Anforderung war nicht der Endzustand. Das Gateway deutete sie, Hardware änderte sich, der Anrufaufbau konnte beginnen, und eine lokale Handlung konnte den Zustand widerrufen. Drahtbefehl, Annahme, Hook-Zustand, Verbindungsaufbau und Nutzerhandlung liefen auf eigenen Uhren.

Auch die Sicherheitsformulierung verlangt Zurückhaltung. RFC 3149 erklärte, keine zusätzlichen Erwägungen über das Basis-MGCP hinaus einzuführen. Das sagte nicht, dass ferngeladenes XML, Tastenzuordnungen oder Hook-Signale aus sich heraus sicher waren. Authentisierung, Autorisierung, Integrität und Vertraulichkeit hingen von Basisprotokoll und Einsatz ab. Ein Passwortfeld verbarg Zeichen auf dem Display; es bestätigte weder Transportverschlüsselung noch sichere Verarbeitung beim Agenten.

Die IESG-Notiz setzt eine weitere Grenze. RFC 3149 dokumentierte ein damals in Produkten eingesetztes Nicht-IETF-Protokoll und verwies für denselben Problemraum auf Megaco/H.248 auf dem Standards Track. Dieser Statusbefund löscht die betriebliche Gestaltung nicht, beweist keine flächendeckende Migration und lässt einen späteren Standard nicht rückwirkend bestimmen, was ein Telefon tatsächlich tat.

Intelligenz wurde nach Wirkung verteilt

Die bleibende Lektion lautet weder „lokal ist immer besser“ noch „zentrale Steuerung ist gescheitert“. RFC 3149 verteilte unterschiedliche Befugnisse an unterschiedliche Orte. Zentrale Software hielt wechselnde Geschäftssemantik: Welche Nummer welchen Dienst meinte, welche Aufschrift und Karte erschien und wie eine Auswahl in die Anruflogik eingriff. Das Telefon behielt den unmittelbaren Zugriff auf Audiogerät und Stummschaltung.

Diese Aufteilung vermied, jeden Dienst fest in jedes Gerät einzubauen, und bewahrte eine kleine physische Bedienfläche, die nicht auf eine Controller-Rundreise warten musste. Sie schuf zugleich lose gekoppelte Fehler. Ein Telefon konnte lokal weiter stummschalten, während zentral vergebene Funktionen ausfielen. Ein Agenten-Upgrade konnte die Bedeutung einer Taste ändern, ohne das Gehäuse zu ändern. Eine Display-Card konnte der Signalisierung hinterherlaufen.

Laufender Code entscheidet solche Widersprüche. Wenn der Agent Taste 1 „Halten“ nennt, die Medien aber weiterlaufen, trat das behauptete Ergebnis nicht ein. Wenn die Mute-Lampe leuchtet und Mikrofonton hinausgeht, weichen Darstellung und Medienrealität voneinander ab. Wenn disp/ eine Umleitung zeigt, während es weiter klingelt, ist genau die vom Entwurf zugelassene Asynchronität sichtbar.

Die kleine Taste markiert damit eine verfassungsähnliche Grenze. Das Zentrum darf benennen und koordinieren. Allein der Empfang von Ereignissen überträgt ihm nicht die Verfügungsgewalt über jede körperliche Handlung.

Quellen