Zusammenfassung

  • RFC 5368 lässt Refer-To per Content-ID auf eine Zielmenge zeigen. Der REFER-Empfänger erzeugt pro wirksamem Ziel eine eigene SIP-Anfrage; seine erste Antwort ist kein Sammelergebnis dieser Anfragen.
  • norefersub und Refer-Sub: false unterdrücken den bei REFER üblichen impliziten Ergebnisdialog, weil message/sipfrag keine mehreren Zieltransaktionen abbildet. 420 zeigt fehlende Unterstützung der verlangten Erweiterung.
  • Belastbare Nachweise halten Erweiterung, Nichtverzweigung, zurückgegebenes Refer-Sub, referenziertes Objekt, Normalisierung, Kindtransaktionen und den getrennten Anwendungszustand fest.

420 gehörte zur Aushandlung

Ein SIP-Empfänger prüft Require, bevor er die gewünschte Operation als unterstützten Vertrag behandelt. Steht dort norefersub und beherrscht der Empfänger diese Erweiterung nicht, antwortet er mit 420 Bad Extension.

Diese Aussage ist präzise. Der adressierte REFER-Empfänger kann die verlangte Form „REFER ohne implizites Abonnement“ nicht erfüllen. Sie sagt nicht, dass ein Konferenzteilnehmer einen BYE ablehnte, dass eine eingeladene Person nicht erreichbar war oder dass die Anwendung keine andere Mehrzieloperation besitzt.

Ein automatischer Retry ohne norefersub ist daher keine bedeutungsneutrale Reparatur. Er ändert, ob ein implizites Abonnement entsteht und welche NOTIFY-Nachrichten erwartet werden. Für mehrere Ziele bleibt das alte Abonnement als Ergebnisfläche unzureichend. Die Wiederholung braucht zugleich eine neue Entscheidung über Beobachtung und Korrelation.

Das Monitoring sollte 420 nach Zielressource, Option-Tag und Zeitpunkt erfassen. Eine globale Produktmarke „Multiple REFER fehlgeschlagen“ wäre zu grob. Ebenso grob wäre „Zielgruppe hat abgelehnt“ — die Zielgruppe wurde in diesem Pfad womöglich nie angesprochen.

Eine erfolgreiche Elternantwort war noch kein Kindresultat

Der REFER-Empfänger ist gegenüber dem Herausgeber UAS. Nach der Annahme wird er für jedes Ziel zum UAC. Damit entstehen neue Transaktionen mit eigenen IDs, Dialogbezügen, Antworten und Zeitverläufen.

Das Ablaufbild der RFC zeigt 202 Accepted, bevor die einzelnen BYE-Anfragen gesendet werden. Die zeitliche Ordnung begrenzt die Beweiskraft: 202 bestätigt die Annahme des Auftrags. Es kann den Ausgang späterer BYE nicht bestätigen.

Ein Datenmodell mit nur einem Statusfeld wird diese Grenze fast zwangsläufig verletzen. Es benötigt einen Elternvorgang für Authentisierung, Autorisierung, Listeneingang und REFER-Antwort sowie ein Kindobjekt je normalisiertem Ziel. Ein Eltern-2xx kann mit erfolgreichen, abgelehnten, abgelaufenen und unbekannten Kindern koexistieren.

Auch die Normalisierung braucht einen Beleg. Die eingereichte Liste, die nach URI-Vergleich wirksame Menge und die erzeugten Anfragen können verschiedene Größen haben. Ohne dokumentierte Duplikatregel ist weder Reduktion noch Vollständigkeit prüfbar.

Der vertraute Ergebnisdialog wurde bewusst entfernt

Beim REFER mit einem Ziel entsteht gewöhnlich ein implizites Abonnement. NOTIFY mit message/sipfrag berichtet den Zustand der ausgelösten Transaktion.

Für mehrere Ziele existiert kein definierter einzelner Zustand. Transaktionen laufen parallel und enden unterschiedlich. RFC 5368 erklärt ausdrücklich, dass sie keinen Mechanismus bereitstellt, mit dem der Herausgeber alle Ergebnisse erfährt. Deshalb empfiehlt sie norefersub und Refer-Sub: false.

Bestätigt der Empfänger false in 200, entsteht kein implizites Abonnement. Ausbleibende NOTIFY sind dann erwartetes Verhalten. Sie sind kein Beleg für störungsfreie Ausführung.

Die gefährlichste Kennzahl lautet „keine Fehlermeldung“. In diesem Verfahren wurde der Meldekanal absichtlich abgeschaltet. Wer sein Schweigen als Erfolg wertet, erzeugt eine positive Tatsache ohne Quelle.

Ergebnisse müssen anwendungsspezifisch beobachtet werden. Für eine Konferenz kann der Conference-State zeigen, wen der Focus aktuell als Teilnehmer führt. Ein anderer Dienst braucht ein eigenes Ereignis oder ein Ausführungsjournal.

Request und Response entschieden gemeinsam

Refer-Sub: false in der Anfrage ist ein Wunsch. Erst false in der 2xx-Antwort zeigt, dass der Empfänger ihn gewährt. Fehlt das Feld oder steht es auf true, entsteht das normale implizite Abonnement.

Ein Nachweis muss beide Nachrichten paaren. Nur der Request verliert die Entscheidung des Empfängers. Nur die Response verliert Option-Tags, Refer-To, Listenobjekt und beabsichtigte Methode.

Zudem darf false nur verwendet werden, wenn der Herausgeber sicher ist, dass REFER nicht forkt. Das implizite Abonnement macht sonst mehrere entstandene Dialoge sichtbar. Die RFC verwendet im Beispiel eine GRUU, um genau einen Empfänger zu sichern.

Request-URI, Route-Set, Nichtverzweigungsgrund, Response-Branch und Empfängeridentität gehören deshalb zum Beleg. Ein interner Load Balancer beweist nicht automatisch, dass SIP keine unabhängigen Zweige erzeugen konnte.

Content-ID band den Auftrag an ein Objekt

Refer-To enthält einen cid:-URL; die Zielmenge liegt im Body. Damit die Autorisierung auf die tatsächlich ausgeführte Liste bezogen werden kann, müssen ID, MIME-Rahmen, Content-Type, Content-Disposition, Bytes und Hash zusammenbleiben.

RFC 8262 dokumentiert eine historische Unschärfe. Beispiele in RFC 5368 referenzierten einen vollständigen Message-Body, obwohl zuvor nur Body-Parts normativ abgedeckt waren. Die spätere Aktualisierung erlaubt ausdrücklich Part oder kompletten Body sowie MIME- oder SIP-Content-ID.

Bei alten Aufzeichnungen reicht ein passender ID-String nicht. Man muss feststellen, welches Objekt der damalige Parser auswählte. Gateways, die Multipart-Strukturen ändern, müssen Referenz und Objekt konsistent umschreiben.

Syntax war keine Methodenberechtigung

Das Listenformat kann copyControl und Anonymisierung enthalten. Für INVITE kann die Empfängerrolle sinnvoll sein. Für einen mid-dialog BYE hat dieselbe Markierung keine entsprechende Semantik.

Darum verlangt RFC 5368 Anwendungsverständnis. Der Empfänger darf keine Methoden akzeptieren, die er nicht versteht, und soll kein blinder Fan-out-Dienst sein. Er authentisiert den Herausgeber, prüft Autorisierung und Opt-in, bindet die Methode an den richtigen Dialog und entscheidet lokal.

Die IANA-Registrierung von multiple-refer und norefersub liefert gemeinsame Namen. Sie beweist weder Aktivierung noch Berechtigung, Annahme, Kindanforderung oder Ergebnis.

Conference-State war eine andere Evidenzfläche

Der Konferenzzustand kann später zeigen, ob der Focus eine Person noch als Teilnehmer führt. Diese Beobachtung gehört zur Anwendung, nicht zur REFER-Transaktion.

Benachrichtigungen sind versioniert, vollständig oder partiell und können Lücken haben. Das Verschwinden einer Person beweist nicht allein, dass genau der angeforderte BYE ursächlich war. Selbstständiges Verlassen oder ein anderer Controller bleiben möglich.

Anfrage, erzeugte Transaktionen, Zielantworten und Zustand müssen getrennt verknüpft werden. Abweichungen zeigen, ob Erzeugung, Policy, Netzwerk oder Beobachtung versagte.

Evidenzgrenze

Nach einem erfolgreichen Multiple REFER darf man sagen: Dieser Empfänger akzeptierte diesen Auftrag, dessen Content-ID auf diese wirksame Liste zeigte, unter dieser Abonnemententscheidung. Man darf nicht automatisch sagen, alle Ziele hätten die gewünschte Wirkung erreicht.

Der Mindestbeleg umfasst Herausgeber und Berechtigung, Anwendung, Nichtverzweigung, genaue Anfrage und Antwort, zurückgegebenes Refer-Sub, referenziertes Objekt, Original- und Effektivliste, jedes Kind, dessen Antwort, versionierte Servicebeobachtung und ein getrenntes menschliches oder geschäftliches Ergebnis.

Die aggregierte Steuerung spart Nachrichten. Sie hebt die getrennte Wahrheit der Zielvorgänge nicht auf.