Zusammenfassung

  • RFC 3326 übertrug den Protokollgrund einer SIP-Anfrage getrennt von der Anfrage selbst, sodass gleiche Abbruchaktionen unterschiedliche vorgelagerte Ereignisse erklären konnten.
  • Reason war optional und für die SIP-Verarbeitung wirkungslos, konnte aber für Oberfläche, Dienst und HERFP-Behandlung wichtig sein; ohne Herkunft und Integrität war der Wert keine beglaubigte Geschichte.

Ein endgültiger Fehler konnte im Fork verborgen bleiben

Ein Proxy konnte INVITE in mehrere Zweige aufteilen. Lehnte ein Zweig die Sitzung ab, während andere weiterliefen, musste seine endgültige Fehlerantwort nicht sofort zum Client gelangen. Gerade wenn die Ablehnung einen Aspekt der ursprünglichen Anfrage betraf, fehlte dem Client damit die Information, die er für eine Korrektur gebraucht hätte. Dieses Problem wurde als Heterogeneous Error Response Forking Problem bezeichnet.

RFC 3326 sah Reason als möglichen Behälter, um einen endgültigen Status in einer vorläufigen Antwort zu kapseln. Der Wert verband eine spätere Reaktion mit dem Ereignis, das sie ausgelöst hatte. Wer Reason entfernte oder fälschte, konnte verhindern, dass der Client seine frühere Anfrage richtig aktualisierte; im Extremfall wurde der Sitzungsaufbau unmöglich. Deshalb empfahl der RFC geeigneten Integritätsschutz.

Dass eine erklärende Angabe solche Folgen haben konnte, wirkt zunächst widersprüchlich. Clients und Server durften Reason ignorieren, und das Feld hatte keinen Einfluss auf die grundlegende Protokollverarbeitung. Eine Anfrage blieb gültig, wenn Reason fehlte. Doch Anwendungen, die den Kontext nutzten, konnten andere Entscheidungen treffen. Optional bedeutete interoperabel, nicht folgenlos.

Die gleiche Aktion löschte den sichtbaren Unterschied

Das anschauliche Beispiel war der Anruf auf mehreren Geräten. Antwortete ein Zweig mit 200 OK, stoppte der Proxy die noch klingelnden Zweige durch CANCEL. Gab der Anrufer vor einer Antwort auf, sahen die übrigen Geräte ebenfalls CANCEL. Das Klingeln endete in beiden Fällen.

Für die Anrufliste war der Unterschied wesentlich. Im ersten Fall hatte jemand den Anruf anderswo angenommen; ein verpasster Anruf wäre irreführend. Im zweiten Fall konnte der Eintrag sinnvoll sein. Die Methode bezeichnete die Aktion, nicht ihren Auslöser. Der Proxy konnte im ersten CANCEL einen SIP-Grund 200 und die Aussage „anderswo abgeschlossen“ mitführen.

Reason konnte in jeder Anfrage innerhalb eines Dialogs, in jedem CANCEL und in Antworten erscheinen, deren Statuscode es ausdrücklich erlaubte. Ein Client konnte eine unakzeptable Medienofferte in einer erfolgreichen Antwort mit ACK quittieren und die Sitzung sofort durch BYE mit Grund 488 beenden. Ein Drittanbieter-Controller konnte B als beschäftigt erkennen und den Dialog zu A mit BYE und Grund 486 schließen.

In jedem Fall lag die Beobachtung an einer anderen Stelle als die Folgeaktion. Reason verhinderte, dass die Kausalität vollständig am Übergang verloren ging.

Ein Zahlenwert brauchte seinen Protokollnamen

Die Syntax begann nicht mit einer Zahl, sondern mit protocol. SIP-Gründe verwendeten SIP-Statuscodes, Q.850-Gründe stammten aus ISUP. Danach konnten cause, ein zitierter text und Erweiterungen folgen. Wer nur die Zahl speicherte, vermischte verschiedene Namensräume.

Auch text war kein Ersatz. Eine lesbare Formulierung kann übersetzt, gekürzt oder falsch geschrieben werden. Maschinenbedeutung entsteht aus registriertem Protokoll und Ursache. Ein belastbares Archiv bewahrt beide strukturiert und hält den Originaltext daneben.

RFC 3326 erlaubte ursprünglich mehrere Reason-Werte nur, wenn jeder ein anderes Protokoll nannte. RFC 9366 änderte die Regel: Mehrere Werte desselben registrierten Protokolls sind zulässig, wenn dessen Definition die Mehrfachheit erklärt. Sonst bleibt es bei einem Wert pro Protokoll. Ein Empfänger darf nicht allein aus der Listenform ableiten, ob der erste, letzte oder strengste Wert gilt.

Die IANA-Registrierung ist damit Teil der Auslegung. Sie ordnet Protokollnamen und Parameter einer dokumentierten Semantik zu. Parser müssen unbekannte Werte tolerieren können, dürfen sie aber nicht stillschweigend in einen bekannten Zahlenraum umdeuten.

Die Übersetzung verschob die Herkunft

RFC 3398 beschrieb die Abbildung zwischen ISUP und SIP. Empfing ein Gateway eine ISUP-Freigabe, konnte es einen SIP-CANCEL erzeugen und den Q.850-Grund übernehmen. Die SIP-Seite erhielt mehr Kontext als die bloße Abbruchaktion.

RFC 6432 erlaubte Q.850-Gründe in SIP-Antworten außer 100 Trying. RFC 8606 fügte location hinzu, wenn die ISUP-Freigabestelle verfügbar war. Sie bezeichnet einen groben Netzbereich wie lokales, Transit- oder entferntes Netz, nicht den physischen Ort oder die Identität der Teilnehmer.

Mit jeder Übersetzung wuchs die Distanz zur ursprünglichen Beobachtung. Ein sichtbarer Wert konnte direkt übernommen, nach einer Tabelle abgebildet, lokal ergänzt oder von einem früheren Hop kopiert worden sein. Für eine prüfbare Aussage braucht man die externe Nachricht, Version der Abbildung, Gateway-Identität, Zeit und nachfolgende Veränderungen.

History-Info in RFC 7044 und Diversion in RFC 5806 behandeln den Weg der Umleitung. Reason behandelt den Auslöser einer konkreten Anfrage oder erlaubten Antwort. Eine Zielhistorie beweist keinen Freigabegrund; ein Grund rekonstruiert nicht alle Ziele.

Weitergabe bewahrte auch falsche Behauptungen

Erzeugte ein Proxy nach dem Empfang eines CANCEL mit Reason einen weiteren CANCEL, sollte er das Feld kopieren. Andernfalls reiste die Aktion weiter, während ihre Erklärung verschwand. Die letzte Oberfläche müsste wieder raten.

Ein kopierter Wert ist jedoch eine Aussage aus zweiter Hand. Der letzte Proxy kann das Ereignis nie gesehen haben. Verändert ein Zwischenelement text, Ursache oder Erweiterung, lässt sich das am Endpunkt nicht aus dem letzten Paket erkennen. Protokolle sollten direkte Beobachtung, lokale Erzeugung, Übersetzung und bloße Weiterleitung unterscheiden.

Integritätsschutz begrenzt einen Teil des Problems. Erfolgreiche Prüfung zeigt, dass geschützte Bytes zwischen benannten Endpunkten nicht verändert wurden. Sie bestätigt weder das reale Ereignis noch eine korrekte Zuordnung oder ehrliche erste Aussage. Fehlt Schutz, kann Reason weiterhin Diagnosekontext sein, darf aber weniger weitreichende Automation auslösen.

RFC 3326 hat deshalb nicht „den wahren Grund“ standardisiert. Es standardisierte eine Hülle, in der ein behaupteter Grund seine Protokollzugehörigkeit behalten konnte, nachdem die Aktion selbst alle Unterschiede eingeebnet hatte. Die historische Leistung liegt in dieser Trennung—und in der Warnung, dass Erklärungen geschützt werden müssen, ohne sie mit Beweisen zu verwechseln.

Quellen