Zusammenfassung

  • RFC 3326 erlaubt einer SIP-Anfrage, den Anlass ihres Versands mitzuführen: als SIP-Statusursache oder als Q.850-Wert aus der Telefonnetz-Interworking.
  • Das Feld ändert die SIP-Verarbeitung nicht. CANCEL bricht weiterhin ab; Reason kann mitteilen, dass ein anderer Zweig den Anruf bereits angenommen hat.

Ein Zweig nahm an; die anderen mussten trotzdem stoppen

Ein Proxy sendet INVITE über mehrere Zweige. Ein Ziel antwortet mit 200 OK, doch die anderen Telefone klingeln möglicherweise weiter. Der Proxy schickt daher CANCEL an diese Zweige. Das Klingeln endet wegen der SIP-Methode CANCEL, nicht wegen eines Headers, der den Anlass beschreibt.

RFC 3326 erschien im Dezember 2002 und gab dem Proxy eine Möglichkeit, die Erklärung anzuhängen: Reason: SIP;cause=200;text="Call completed elsewhere". Ein empfangender Dienst kann damit zwischen einem Anruf unterscheiden, der an einem anderen Zweig angenommen wurde, und einem, der vor der Antwort aufgegeben wurde. Das kann die Anzeige oder das Protokoll entgangener Anrufe beeinflussen, obwohl die unmittelbare Protokollaktion dieselbe bleibt.

Diese Trennung ist die zentrale Entwurfsentscheidung. SIP hatte Statuscodes für Antworten. Dieselbe Anfrage kann jedoch aus unterschiedlichen Gründen versendet werden und enthält gewöhnlich nicht die Antwort, die sie ausgelöst hat. Reason ordnet der handelnden Anfrage einen Anlass zu. Das ist erklärende Metadaten, kein zweiter Befehlsweg.

Der Grund gehört zu einem Protokollraum

RFC 3326 ordnet Werte einem Protokoll zu. SIP bedeutet, dass der Parameter cause einen SIP-Statuscode enthält; Q.850 bezeichnet einen dezimalen Ursachenwert des Telefon-Signalisierungssystems der ITU-T. Ein Gateway kann so einen Auslösungsgrund aus dem Telefonnetz in einer SIP-Nachricht bewahren. Die Zahl allein reicht nicht; der Protokollname nennt das zugrunde liegende Nummernsystem.

Der Parameter text hilft Menschen, entscheidet aber nicht über die Protokollverarbeitung. Die Ursache stammt aus dem Vokabular des genannten Protokolls; Methode, Status und Transaktionskontext bleiben in der Nachricht selbst. Wer cause=200 als Antwort behandelt oder einen Q.850-Wert für einen SIP-Status hält, vermischt getrennte Steuerungsebenen.

Auch ein allgemeines Verständnis ist nicht garantiert. RFC 3326 erlaubt Implementierungen, unbekannte Werte zu ignorieren, und hält ausdrücklich fest, dass Reason die Protokollverarbeitung nicht beeinflusst. Die Anfrage folgt weiterhin SIP, wenn ein Endpunkt die Erklärung verwirft. Die Erweiterung kann Diensten helfen, ohne Voraussetzung für den grundlegenden Anrufzustand zu werden.

Eine Antwort, die der Fork verdecken kann

Die Spezifikation verknüpfte Reason außerdem mit dem Problem unterschiedlicher Fehlerantworten bei Forking. Ein geforkter INVITE kann an verschiedenen Zweigen unterschiedliche endgültige Fehler erhalten. Da ein Proxy gewöhnlich auf Zweigergebnisse wartet, bevor er entscheidet, was er nach oben weitergibt, kann ein wichtiger Fehler unsichtbar bleiben, solange ein anderer Zweig aussteht. RFC 3326 nannte das Einkapseln eines endgültigen Status in einer vorläufigen Antwort als möglichen Einsatz von Reason.

Die Formulierung ist bewusst begrenzt: Es ist ein möglicher Mechanismus, kein Beleg dafür, dass jeder Fork jeden Fehler sichtbar macht oder ein eingesetzter Dienst das Problem gelöst hat. Der Header bietet einen Behälter für eine Ursache; er definiert weder eine allgemeine Rangfolge für Fehler noch ersetzt er die SIP-Antwortverarbeitung.

Spätere Erweiterungen hielten die Grenze sichtbar

RFC 8606 ergänzte später einen ISUP-Standortparameter für Q.850-Ursachen, um bei vorhandener Information zu erhalten, wo eine Auslösung stattfand. RFC 9366 lockerte die ursprüngliche Ein-Wert-pro-Protokoll-Regel nur für registrierte Protokolle, die die Bedeutung mehrerer Werte festlegen. Beide Erweiterungen präzisieren die Herkunft, machen Reason aber nicht zur Aktion selbst.

Das ist auch für die Protokollgeschichte wichtig. RFC 3087 betrachtete den Request-URI als lokalen Kontext zur Dienstauswahl; RFC 3326 fügte einer bereits gewählten SIP-Aktion eine Ursache hinzu. Das eine wählte das Ziel der Anfrage, das andere erklärte ihren Versand. Keines beweist Authentifizierung, Autorisierung, die vollständige Anrufgeschichte oder ein späteres Ergebnis.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html