Zusammenfassung

  • Replaces bezeichnet mit Call-ID, to-tag und from-tag genau einen durch INVITE entstandenen SIP-Dialog. Ein eindeutiger Treffer authentisiert den Initiator nicht und erteilt ihm keine Ersetzungsbefugnis.
  • Der empfangende UA muss erst autorisieren und den neuen INVITE zulassen. Erst danach folgt bei einem bestätigten Dialog BYE oder bei einem geeigneten early dialog CANCEL; scheitert die neue Sitzung, bleibt der alte Dialog unverändert.
  • REFER-Annahme, Referred-By-Herkunft, Replaces-2xx, Beendigung des alten Legs und Medien-, Aufzeichnungs- oder Abrechnungsergebnis sind getrennte Belege. Ein gemeinsames Erfolgsbit schafft eine unzulässige Entscheidungsabkürzung.

Der Transfer besteht aus Entscheidungen, nicht aus einem Status

Bei einem begleiteten Transfer spricht eine Mitarbeiterin mit einem Kunden und baut parallel ein Beratungsgespräch zu einem Spezialisten auf. Danach sendet sie REFER an den Kunden. Dessen Endgerät akzeptiert die Anfrage und erzeugt einen neuen INVITE zum Spezialisten. Im Refer-To kann der Replaces-Wert des Beratungsgesprächs kodiert sein.

Bis hierhin ist nur entschieden, dass der Kunde der Referenz folgt. Am Ziel beginnt eine neue Entscheidungskette. Der neue INVITE muss die richtige UA-Instanz erreichen. Das Tripel muss genau einen vorhandenen Dialog treffen. Der Spezialist beziehungsweise seine Policy muss den Initiator zur Ersetzung berechtigen. Schließlich müssen Medien, Schlüssel, QoS und Ressourcen des neuen Dialogs zulässig sein.

Wird die neue Sitzung abgelehnt, darf die bekannte Verbindung nicht vorsorglich zerstört werden. RFC 3891 ordnet den Ablauf deshalb bewusst: identifizieren, autorisieren, zulassen, Ressourcen umordnen, alten Dialog beenden.

Die gemeinsame Protokollschicht beschreibt die Koordinate und den gewünschten Vorgang. Sie ersetzt nicht die lokale Stelle, die die unmittelbare Auswirkung tragen muss.

Ein neuer INVITE statt stiller Umdeutung

Replaces bearbeitet den alten Dialog nicht in place. Das Feld steht in einem neuen INVITE; der entstehende Ersatzdialog besitzt eine neue Call-ID.

Das ist eine Sicherheits- und Klarheitsentscheidung. INVITE hat bereits die Semantik einer neuen Sitzungsaufnahme. Das explizite Feld zeigt die zusätzliche Absicht. Eine neue Call-ID verhindert implizite Zuordnungen, die verschiedene UAs unterschiedlich auslegen könnten. Ein UA ohne Erweiterungsunterstützung kann scheitern, ohne den laufenden Dialog versehentlich zu verändern.

Unterstützung wird mit Supported: replaces angezeigt. Wer eine explizite Fehlermeldung bei fehlender Unterstützung benötigt, kann Require: replaces senden. Das aktuelle IANA-Verzeichnis der SIP-Parameter führt Header und Option Tag.

Unterstützung ist jedoch nur eine Fähigkeit. Sie ist keine Vorabgenehmigung für jeden Benutzer, jeden Tenant oder jeden alten Dialog.

Auch REFER und Replaces bleiben eigenständig. REFER bittet den Empfänger, eine Ressource zu kontaktieren. Replaces sagt dem Ziel des neuen INVITE, welchen lokalen Dialog es ersetzen soll. Beim Transfer greifen beide Mechanismen ineinander, ohne zu einem einzigen Entscheidungsakt zu verschmelzen.

Tags müssen aus Sicht des Empfängers gelesen werden

Der Replaces-Wert enthält Call-ID, genau ein to-tag und genau ein from-tag. Der empfangende UAS vergleicht to-tag mit seinem lokalen und from-tag mit seinem entfernten Tag.

Die Perspektive lässt sich nicht durch die optische Reihenfolge einer älteren Nachricht ersetzen. In einem Trace stehen To und From aus Sicht dieser Nachricht. Wer sie unreflektiert kopiert, kann die lokale und entfernte Seite vertauschen.

Der Errata-Eintrag zu RFC 3891 zeigt den Fehler unmittelbar: Ein verifiziertes redaktionelles Erratum korrigiert vertauschte Tags in einem early-dialog-Beispiel. Eine weitere redaktionelle Korrektur ist Held for Document Update. Die normative Regel bleibt gleich; die Beispiele mahnen zu genauer Perspektive.

Der Treffer umfasst nur einen Dialog. RFC 3891 schließt mehrere Dialoge, einen ganzen Call, eine ganze Transaction und eine vollständige Proxy-Fork-Kette aus. Hat ein ursprünglicher INVITE mehrere frühe Branches erzeugt, ersetzt das Tripel nur einen. Retargeting des neuen INVITE zu anderen Contacts übernimmt nicht die alte Forking-Logik.

Geschäftssysteme aggregieren oft mehr: Kunden-Leg, Agenten-Leg, Beratung, Warteschlange, Aufzeichnung und Abrechnung. Das Ergebnis eines SIP-Dialogs darf diese Gesamtheit erst nach einer belegten Reconciliation verändern.

Ein Identifikator sagt nicht, welcher Eingriff erlaubt ist

Mehrere Replaces-Felder, Replaces außerhalb von INVITE oder widersprüchliche Call-Control-Semantik führen zu 400. Passt der Wert auf mehr als einen Dialog, behandelt der UA ihn wie keinen Treffer.

RFC 3911 verdeutlicht die Trennung. Join verwendet ebenfalls Call-ID und Tags, um einen Dialog zu finden. Es fordert aber, den neuen Dialog zum Conversation Space hinzuzufügen. Replaces fordert, den identifizierten Dialog zu schließen und zu ersetzen. Beides gleichzeitig ist widersprüchlich.

Das Tripel benennt das Objekt. Der Header benennt die vorgeschlagene Operation. Authentisierung benennt den Akteur. Autorisierung bestimmt seine Befugnis. Admission prüft die Durchführbarkeit. Spätere Signalisierung und Medien zeigen das Resultat.

Ohne Treffer oder bei einem nicht durch INVITE entstandenen Dialog folgt 481. Ein bereits beendeter Dialog sollte 603 ergeben, damit ein verspäteter Ersetzungsversuch nicht als normaler neuer Anruf klingelt.

481 ist kein automatisches Betrugsurteil. Vertauschte Tags, veralteter Zustand, falsche Instanz, verlorene Replikation, Retargeting oder ein Rennen mit der regulären Beendigung sind unterschiedliche Ursachen. Die Betriebsdaten müssen diese Ursachen auseinanderhalten.

Autorisierung beginnt erst nach dem Match

Trifft Replaces einen aktiven Dialog, verlangt RFC 3891, dass der UA die Berechtigung des Initiators prüft. Der Treffer erfüllt diese Pflicht nicht.

Als mögliche Grundlage nennt das RFC eine Identität, die als äquivalent zum ersetzten Nutzer authentisiert wurde, Referred-By im Zusammenhang mit REFER sowie andere lokale Policies. Der neue Dialog darf einer anderen Policy unterliegen als der alte.

Gemeinsame Credentials können mehrere Geräte einer Identität oder eine legitime Stellvertretung abbilden. Zu breit angelegt, geben sie einem Servicekonto Ersetzungsrechte über Nutzer und Tenants hinweg. Authentisierung beweist die Kontrolle über Credentials, nicht den aktuellen Willen einer Person, eine arbeitsrechtliche Befugnis oder eine vertragliche Vollmacht.

RFC 3892 begrenzt auch Referred-By. Der Referee überträgt Angaben des Referrers an das Ziel und kann sie daher sehen oder verändern. Ein ungeschützter Referred-By-Wert kann Policy-Input sein, ist aber verdächtig, wenn er Admission oder Nutzeranzeige beeinflusst. Das Ziel kann ein gültiges geschütztes Token verlangen.

Ein gültiges Token schützt konkrete Referral-Aussagen. Es beweist nicht automatisch die Übertragbarkeit von Recording Consent, medizinischer Verantwortung, Handelsmandat oder Vertragsanspruch. Diese Reichweite muss eine nachvollziehbare lokale Regel festlegen.

Dialogwissen ist bedingter Nachweis, kein Besitz

RFC 4538 definiert Target-Dialog für Anfragen, deren Autorisierung davon abhängen kann, dass der Absender einen bestehenden Dialog kennt. Bei SIPS, ausreichend zufälligen Identifikatoren und einer definierten Vertrauensbeziehung zum ursprünglichen Pfad kann dieses Wissen eine Entscheidung stützen.

Die Bedingungen gehören zum Beweis. Auf einem ungeschützten Pfad kann ein Lauscher die Werte kennen. Selbst bei geschütztem Pfad kann der UAS entscheiden, dass die nachgewiesene Beziehung für die verlangte Operation nicht genügt.

Kenntnis einer Koordinate ist daher nicht wertlos, aber auch keine Herrschaft. Methode, Identität, Pfadschutz, Policy und Schadensoberfläche bestimmen ihren Wert.

Hier wird Heng Lus Frage praktisch: Wer durfte die bindende Entscheidung autorisieren? Nicht derjenige, der bloß anwesend war oder die Kennung kannte, sondern die verantwortliche lokale Instanz, die den Dialog und die Folgen trägt.

Admission bleibt eine eigenständige Schranke

Nach erfolgreicher Autorisierung versucht der UAS, den neuen INVITE anzunehmen, Benutzeroberfläche und Ressourcen umzuhängen und den alten Dialog zu schließen.

QoS kann fehlen, Keying scheitern, Medien können inkompatibel sein oder Ressourcen fehlen. Dann muss der UAS einen passenden Fehler zurückgeben und den getroffenen alten Dialog unverändert lassen.

Diese Reihenfolge begrenzt Ausfälle. Ein Abbruch beim Match gibt geleakten Kennungen Zerstörungskraft. Ein Abbruch nach Authentisierung opfert die laufende Sitzung trotz technisch unbrauchbarer neuer Offerte. Erst die Annahme des neuen Dialogs schafft einen tragfähigen Ersatz.

Bei einem bestätigten Dialog ohne early-only sendet der UAS zuerst 2xx auf den neuen INVITE und danach BYE auf den alten Dialog. Bei einem early dialog, den er selbst initiiert hat, akzeptiert er den neuen und sendet CANCEL auf die alte Einladung.

early-only beschränkt die Absicht auf eine noch nicht bestätigte Branch. Ist sie bereits bestätigt, folgt 486. Wurde der frühe Dialog nicht vom empfangenden UA initiiert, folgt 481 und der alte Zustand bleibt bestehen; der Ein-Dialog-Mechanismus kann fremde Forking-Logik nicht nachbilden.

Ein 2xx ist starker Beleg für die Annahme des neuen Dialogs. Es belegt nicht allein, dass BYE ankam, ein B2BUA alle internen Legs entfernte, keine Forks verblieben, RTP fortgesetzt wurde, Recording korrekt wechselte oder die alte Abrechnung endete.

REFER besitzt Zustimmung und Ergebnis getrennt

RFC 3515 sieht vor, dass ein UA bei einem wohlgeformten REFER die Zustimmung des Nutzers einholt — interaktiv oder durch konfigurierte Policy. Erst danach kontaktiert er die Refer-To-Ressource nach deren normalen Regeln.

Beim begleiteten Transfer trägt Refer-To häufig einen escaped Replaces-Wert. Der Transferee erzeugt den neuen INVITE; das Transfer Target führt Match, Autorisierung und Admission selbst aus. Die Zustimmung zum REFER bindet das Ziel nicht.

REFER-Transaction und referenzierte Aktion haben getrennte Ergebnisse. NOTIFY meldet Fortschritt und Endstatus. RFC 7647 ersetzt den alten 202 bei Annahme durch 200, klärt GRUU und verlangt Target-Dialog, wenn ein bestehender Dialog identifiziert werden soll. Der 200 bleibt eine Antwort auf REFER, kein Gesamtattest.

RFC 5589 sagt ausdrücklich, dass eine erfolgreiche REFER-Transaction die Sitzung zwischen Transferor und Transferee nicht beendet. Dafür ist ein späteres BYE nötig. Bei Busy, No Answer oder Replaces-Ablehnung zeigen die Fehlerabläufe die Rückkehr aus Hold zur bestehenden Sitzung.

Ein belastbares Modell trennt daher REFER-Zustimmung, REFER-Antwort, Ergebnis des ausgelösten INVITE, Ende des alten Dialogs sowie Medien- und Geschäftsergebnis.

Beweiskette statt Erfolgslabel

Speichern Sie die Call-ID des neuen INVITE und das Replaces-Tripel getrennt. Hinzu kommen lokale/entfernte Tag-Perspektive des Empfängers, Dialogstatus beim Match, Contact, Route, Fork-Branch und early-only.

Dokumentieren Sie die Entscheidungsgrundlage: authentisierte Identität, Referred-By, Tokenprüfung, Policy-Version, Nutzer- oder Tenant-Regel, Freigabequelle und Begründung. authorized=true ohne Herkunft ist nicht auditierbar.

Admission benötigt Response Code, SDP-Fingerprint, Codecs und Directions, Keying, QoS, Zielinstanz und ACK. Nach einem 2xx werden BYE oder CANCEL, deren Antworten, Retransmissions und letzte beobachtete Signalisierung und Medien des alten Legs verknüpft.

REFER gehört mit Call-ID, CSeq, Target-Dialog, Refer-To-Fingerprint, Zustimmung, Antwort und NOTIFY in dieselbe Timeline, aber nicht in dasselbe Zustandsfeld. Ein gemeldeter Erfolg wird mit Zieltransaction und realen Legs abgeglichen.

Tests müssen vertauschte Tags, mehrdeutige Matches, beendete Dialoge, early-only-Rennen, fehlende Unterstützung, Autorisierungsablehnung nach korrektem Match, ungültige Tokens, Media/Key/QoS-Fehler, Busy/No Answer, verlorenes BYE nach 2xx, Rest-Forks, Retargeting, State-Verlust im Failover und nicht rekonstruierbare B2BUA-Mappings abdecken.

Das Ziel ist eine Chronologie, die getrennt beantwortet: Was wurde verlangt? Welcher Dialog war gemeint? Wer war befugt? Was wurde zugelassen? Was wurde beendet? Welche Leistung erreichte den Nutzer?

Quellen