Zusammenfassung

  • Eine erfolgreiche Antwort auf REFER bedeutete in RFC 3515, dass der Empfänger die Verarbeitung und Statusmeldung übernahm. Sie bedeutete nicht, dass die verwiesene Anfrage erfolgreich war.
  • Implizites refer-Abonnement, NOTIFY-Berichte im Format message/sipfrag und ausgeführte Aktion besaßen eigene Lebenszyklen. Das Ende der Beobachtung beendete die Ausführung nicht; verzweigte Abonnements durften nicht zusammengeführt werden.

Die geläufige Erzählung von REFER klingt wie ein einzelner Vorgang: Alice fordert Bob auf, Carol zu kontaktieren, Bob akzeptiert, Carol wird erreicht. Das im April 2003 veröffentlichte Protokoll bestand hingegen auf mehreren Vorgängen. Gerade weil Anweisung, Versuch, Bericht und menschliches Ergebnis auseinanderfallen konnten, erhielten sie getrennte Transaktionen.

RFC 3515 definierte als Standards-Track-Dokument den REFER-Methodennamen, das Header-Feld Refer-To und das Ereignispaket refer. Die Request-URI benennt den Empfänger der Anweisung. Genau ein Refer-To-Wert benennt die Ressource, die dieser Empfänger kontaktieren soll. Für deren URI-Schema gilt der normale Mechanismus: bei SIP etwa eine weitere Anfrage, bei einem anderen Schema dessen jeweiliges Verfahren.

Damit war REFER mehr als ein Telefontransfer. Eine Nachricht durfte einen Body enthalten, doch das Dokument gab ihm keine allgemeine Bedeutung. Ein Empfänger konnte ihn nach dem Content-Type interpretieren. Aus beliebigem Inhalt wurde dadurch aber keine standardisierte REFER-Anweisung.

Zuerst musste der Empfänger die Übernahme prüfen. Fehlerhafte Syntax, nicht unterstützte URI-Verarbeitung, gescheiterte Authentisierung oder lokale Regeln konnten zur Ablehnung führen. Bei einer wohlgeformten Anfrage sollte eine Nutzerentscheidung oder eine vorab konfigurierte Richtlinie die Ausführung erlauben. Falls keine andere endgültige Antwort galt, verlangte das ursprüngliche Verfahren rechtzeitig ein 202 Accepted.

Der entscheidende Irrtum steckt im Wort „Accepted“. Es beantwortete, ob der Empfänger den REFER-Auftrag zur Bearbeitung angenommen hatte. Es sagte nicht, dass ein nachfolgendes INVITE ein endgültiges 200 erhalten hatte, dass eine Nicht-SIP-Ressource reagiert hatte, dass Medien flossen oder dass eine beteiligte Person den gewünschten Vorgang abschloss. Zum Zeitpunkt des 202 konnte die verwiesene Anfrage noch ungesendet sein.

Im ursprünglichen Vertrag löste jede 2xx-Antwort zugleich ein implizites Abonnement des Ereignisses refer aus. Der akzeptierende Agent musste Statusmeldungen per NOTIFY senden. Dieser Kanal war keine Zusatzanzeige, sondern transportierte genau jene Fortschrittsbelege, die die REFER-Antwort noch nicht liefern konnte.

Das erste NOTIFY konnte eintreffen, bevor die REFER-Transaktion selbst abgeschlossen war. Der Absender musste mit dieser zeitlichen Umkehr umgehen. Ein noch offener Status konnte lediglich SIP/2.0 100 Trying melden. Das beschrieb den gegenwärtigen Bearbeitungsstand, nicht den Kontakt zum Ziel und erst recht nicht dessen Erfolg.

Jedes NOTIFY führte Event: refer und einen Body des Typs message/sipfrag, dessen erste Zeile ein SIP-Antwortstatus war. Die Antwortklasse stand für den Zustand der verwiesenen Aktion. Der Body war am jeweiligen Meldepunkt eine vollständige Zustandsangabe, nicht bloß ein Delta, das nur zusammen mit allen früheren Nachrichten verständlich wäre.

Eine minimale Umsetzung konnte 100 für „noch offen“, 200 für Erfolg, 503 für Scheitern oder 603 für eine nach der ursprünglichen Annahme verweigerte Zustimmung verwenden. Gerade diese Abfolge erklärt die begrenzte Bedeutung des 202. Die Zuständigkeit war angenommen; eine lokale Zustimmung oder die delegierte Operation konnte danach trotzdem scheitern.

Außerdem gab es zwei verschiedene 200er. Der Empfänger eines NOTIFY quittierte dessen eigene Transaktion mit 200 OK. Diese Quittung bestätigte den Empfang der Statusmeldung. Der Code im message/sipfrag berichtete dagegen über die verwiesene Anfrage. Wer beide in Protokollansichten als dasselbe „200“ darstellt, löscht eine für die Beweisführung zentrale Grenze.

Bei SIP durfte der Fragment-Body weitere Teile der referenzierten Antwort enthalten. Das konnte die Diagnose erleichtern, zugleich warnte RFC 3515 vor gravierenden Sicherheitsfolgen. Header, Netztopologie oder Identitätsangaben könnten an einen Referenten gelangen, der sie nicht sehen dürfte. Mehr Telemetrie verleiht keine zusätzliche Berechtigung.

Für Nicht-SIP-Ressourcen musste der Notifier den Zustand weiterhin als SIP-Statuszeile ausdrücken. Das schuf eine einheitliche Berichtsform, blieb aber die Darstellung eines Adapters. Ein gemeldetes SIP 200 musste weder die nativen Belege des anderen Protokolls noch das genaue Ziel, Nebenwirkungen oder physische Folgen vollständig abbilden.

Das Abonnement besaß eine eigene Dauer. Die REFER-Anfrage gab keine Laufzeit dafür vor. Der akzeptierende Agent wählte sie und kündigte sie im ersten NOTIFY an, üblicherweise lang genug für den Abschluss der verwiesenen Anfrage. Der Referent konnte verlängern oder vorzeitig beenden.

Das Ende des Abonnements war ausdrücklich kein Ende der Aktion. Ein Unsubscribe oder die Zurückweisung von NOTIFY bedeutete laut RFC nicht, dass die referenzierte Anfrage zurückgezogen oder aufgegeben werden sollte. Allein deshalb sollte der Empfänger kein CANCEL senden. Beobachtung und Ausführung blieben eigenständige Steuerflächen.

Diese Architektur ist über SIP hinaus bemerkenswert. Moderne Systeme deuten „keine weiteren Meldungen“ häufig als „Arbeit stoppen“ oder schließen aus einer verschwundenen Dashboard-Zeile auf ein beendetes Verfahren. RFC 3515 trennte beides: Das Abonnement regelte die Sichtbarkeit; die Aktion behielt ihre eigenen Abbruchregeln.

Verzweigung brachte eine weitere Grenze. Innerhalb eines bestehenden Dialogs sollte REFER nach den Regeln des Dokuments nicht verzweigen. Ein REFER außerhalb eines Dialogs konnte dagegen mehrere Agenten erreichen, die jeweils ein eigenes Abonnement erzeugten. Der Absender musste diese Zustände getrennt halten und durfte sie nicht verschmelzen. Ein 200 im einen und ein 503 im anderen Ast beschrieben zwei verschiedene Ausführungsversuche.

Dialogkennungen verbanden NOTIFY mit dem passenden Abonnement, ersetzten jedoch keine Autorisierung. Der Empfänger musste entscheiden, wer ihn zum Kontakt mit welcher Ressource veranlassen darf. Eine zu großzügige Richtlinie konnte REFER als indirekten Zugang zu geschützten SIP-, HTTP- oder anderen Zielen missbrauchen. Refer-To und lokale Zugriffsregeln waren deshalb Teil der Sicherheitsgrenze.

Spätere RFCs veränderten die Beobachtungsoptionen. RFC 4488 erlaubte die Unterdrückung des impliziten Abonnements, RFC 7614 beschrieb explizite Abonnements, und RFC 7647 ordnete REFER in das durch RFC 6665 erneuerte Ereignismodell ein. RFC 8217 präzisierte einschlägige Syntax. Keine dieser Änderungen machte Annahme und Ergebnis identisch. Sie erhöhen vielmehr die Bedeutung der Frage, welcher Vertrag für einen Trace galt.

Heng Lus Trennung symbolischer und operativer Realität liefert dafür ein nützliches Raster. Ein 202 ist ein symbolischer Beleg für eine begrenzte Zuständigkeit. Ein NOTIFY ist ein Bericht eines identifizierbaren Senders im Rahmen eines Abonnements. Die verwiesene Anfrage läuft unter ihrem eigenen Protokoll. Medienfluss, menschliche Zustimmung und Geschäftsergebnis liegen noch später. Eine korrekte Aussage auf einer Ebene erzeugt keine Belege für die nächste.

Die Beweiskette beginnt daher bei einem gültigen REFER und einem berechtigten Absender. Es folgen REFER-Antwort, Abonnementidentität oder vereinbartes Fehlen, die tatsächlich erzeugte Anfrage, korrelierte Fortschrittsberichte und die endgültige Protokollantwort. Erst danach kommt die Beobachtung durch Anwendung oder Mensch. Wer eine Stufe überspringt, erhebt einen begrenzten Protokollfakt zu einer Aussage, die der Trace nicht belegt.

Die historische Lehre des RFC 3515 lautet nicht, dass Delegation grundsätzlich unzuverlässig sei. Delegation braucht vielmehr getrennte Belege für Anweisung, Beobachtung und Ausführung. Das REFER war akzeptiert. Das war wahr und nützlich. Die Aktion musste trotzdem anderswo geschehen, und ihr Erfolg brauchte einen eigenen Nachweis.

Quellen