Zusammenfassung

  • RFC 3261 kennzeichnet einen Dialog mit Call-ID, lokalem Tag und entferntem Tag. Die Sicht kehrt sich beim Peer um: Das lokale Tag der einen Seite ist dort das entfernte.
  • Ein geforktes INVITE kann mehrere frühe oder bestätigte Dialoge erzeugen. Sie teilen Call-ID und Absender-Tag, während jeder Antwortende ein anderes To-Tag ergänzt.
  • Der Dialog trägt Reihenfolge, Route und Ziel in spätere Transaktionen. Seine Kennung korreliert Kontext; sie authentisiert keinen Menschen und beweist keine Medienübertragung.

Eine Adresse versprach noch keine einzelne Beziehung

Das Wort Anruf klingt nach einem singulären Ablauf: eine Adresse wählen, eine Antwort erhalten, mit einem Gegenüber sprechen. SIP-Routing konnte dasselbe INVITE über einen Proxy zugleich an Tischtelefon, Softclient und Gateway senden. Mehrere Geräte klingelten, und mehr als eines konnte antworten.

Die Kennung der ersten Transaktion reichte für die Folgen nicht aus. Eine Transaktion ordnete Anfrage, Wiederholungen und Antworten während eines Austauschs zu. Danach eröffneten ACK, Neuverhandlung oder BYE neue Transaktionen. Beide Endpunkte konnten die nächste Anfrage senden. Proxies mussten eventuell auf dem Pfad bleiben; ein Gerät konnte seine erreichbare Kontaktadresse ändern.

SIP brauchte deshalb einen Namen für gespeicherten Zusammenhang, nicht nur für eine Nachrichtenarbeit.

RFC 2543 vom März 1999 nannte diese fortdauernde Beziehung call leg und identifizierte sie mit Call-ID, To und From. Das Fork-Problem war bereits sichtbar: Wenn eine Anfrage mehrere User-Agent-Server erreichen konnte, sollte jede Antwort ein To-Tag erhalten, damit der Absender die Antwortenden auseinanderhielt. Mehrere unterschiedlich getaggte Antworten auf ein INVITE standen für verschiedene call legs.

Das Modell hing jedoch noch an den Adressfeldern als Ganzem. Ein From-Tag war optional; Route und Record-Route waren unzureichend bestimmt. SIP 2.0 behielt den Fork, grenzte aber seinen langfristigen Zustand deutlicher ab.

Der Anrufer schrieb nur die Hälfte des Namens

Der im Juni 2002 veröffentlichte RFC 3261 ersetzte call leg durch den Dialog: eine Peer-to-Peer-SIP-Beziehung zwischen zwei User Agents, die eine Weile fortbesteht. Sie liefert Kontext zur Interpretation von Nachrichten, ordnet beide Richtungen und enthält Daten für spätere Anfragen.

Bei jedem UA besteht die Dialog-ID aus Call-ID, lokalem und entferntem Tag. Die Wörter sind perspektivisch. Alices lokales Tag ist für Bob das entfernte; Bobs lokales Tag ist bei Alice das entfernte. Beide teilen zwei undurchsichtige Werte, nicht eine weltweit feste Richtung.

Die erste Anfrage liefert Call-ID und From-Tag – nach der Erklärung des RFC eine halbe Dialog-ID. Eine dialogbildende Antwort fügt das To-Tag hinzu. Für den Initiator wird sein From-Tag lokal und das empfangene To-Tag entfernt; beim Antwortenden kehren sich die Rollen um.

Genau diese Arbeitsteilung löste den Fork. Alle Zweige erbten Call-ID und Initiator-Tag, jeder antwortende Endpunkt erzeugte jedoch sein eigenes To-Tag. Der Anrufer konnte zusammengehörige Signalisierung gruppieren, ohne die Zustände mehrerer Peers zu verschmelzen.

Call-ID allein war absichtlich unvollständig. Tags waren ebenso wenig Benutzernamen oder Berechtigungsnachweise. RFC 3261 verlangte globale Eindeutigkeit und kryptografische Zufälligkeit mit mindestens 32 Zufallsbits. Das verringerte Mehrdeutigkeit; es authentisierte Alice nicht, autorisierte Bob nicht und bestätigte keinen Anzeigenamen.

Schon das Klingeln konnte einen Dialog besitzen

Bei INVITE erzeugt eine vorläufige Antwort von 101 bis 199 mit To-Tag einen early dialog. Der Initiator kann den Zustand dieses Antwortenden speichern, obwohl das Ergebnis offen ist. Eine 2xx-Antwort bestätigt den zugehörigen Dialog. Ein Fehlschlag oder ausbleibender Erfolg auf diesem Zweig beendet den frühen Dialog nach den Kernregeln.

In einem Fork können mehrere early dialogs zugleich existieren: Ein Gerät klingelt, ein anderes meldet Fortschritt, ein drittes lehnt ab. Sie teilen die Initiatorhälfte und unterscheiden sich durch entfernte Tags. Sogar mehrere 2xx können eintreffen und mehrere bestätigte Dialoge hinterlassen, die die Anwendung jeweils quittieren und anschließend auflösen muss.

PRACK beantwortet eine benachbarte, aber andere Frage. Mit RSeq und RAck macht es bestimmte vorläufige Antworten zuverlässig und geordnet. Tags sagen, zu welchem Peer-Kontext sie gehören. Zuverlässigkeit läuft in einem bereits benannten frühen Dialog und ersetzt dessen Namen nicht.

Auch der Via-Branch liegt eine Ebene tiefer. Er korreliert eine Transaktion und ihre Wiederholungen. Das Dialogtupel besteht nach ihrem Ende fort und erscheint in neuen Transaktionen. Eine Verwechslung löscht Beziehung zu früh oder fasst verschiedene Anfragen als einen Austausch zusammen.

Hinter dem Tupel lag ausführbarer Zustand

Der Dialog speicherte mehr als drei Headerwerte. RFC 3261 zählt lokale und entfernte Sequenznummern, beide URIs, ein entferntes Ziel, ein Sicherheitskennzeichen und ein geordnetes Route-Set auf.

Jede Richtung besitzt ihren eigenen CSeq-Verlauf. Ein UA erhöht seine lokale Sequenz für neue Anfragen im Dialog; der Peer merkt die entfernte und kann einen kleineren Wert als veraltet ablehnen. Eine Lücke ist nicht automatisch falsch: Ein früherer Versuch kann an einer Authentisierungsanforderung eines Vermittlers geendet haben. Die Sequenz belegt relative Ordnung, nicht das Erscheinen jeder Zahl.

Das Route-Set enthält Proxies, die im Signalisierungspfad bleiben sollen. Der UAS übernimmt es aus Record-Route der Anfrage, der UAC aus der Antwort in umgekehrter Reihenfolge. Die Abläufe in RFC 3665 zeigen Call-ID und beide Tags in ACK, BYE und Antworten, während Route die gewählten Proxies beibehält.

Das remote target beantwortet eine andere Frage: Unter welchem Contact ist der Peer jetzt erreichbar? Es wird bei der Dialogerzeugung gesetzt und kann durch eine erfolgreiche Target-Refresh-Anfrage ersetzt werden. Für INVITE-Dialoge definierte RFC 3261 re-INVITE als Kernmechanismus.

Ein neuer Contact ändert weder Dialog-ID noch Route-Set. Das Tupel sagt „welcher Kontext“, die Route „über welche Vermittler“, das Ziel „zu welcher aktuellen Adresse“. Diese Trennung verhinderte, dass eine einzige Zeichenfolge Korrelation, Pfadpolitik und Mobilität beherrschte.

Signalisierung war nicht das Gespräch

Nach der Einrichtung kann jeder Peer eine neue Transaktion beginnen. Der Sender wird dafür UAC, der Empfänger UAS, unabhängig von ihren Rollen im ursprünglichen INVITE. Die fortdauernde Beziehung ist symmetrischer als ein einzelner Client-Server-Austausch.

RFC 3264 überließ die Medienaushandlung SDP Offer/Answer. Angebote und Antworten beschreiben Streams, Codecs, Adressen und Ports; ein übergeordneter Kontext wie SIP verbindet die Austausche. Spätere Angebote können Medien im selben Dialog hinzufügen, entfernen oder ändern.

Ein bestätigter Dialog beweist daher weder Audioempfang noch eine bestimmte RTP-Quelle oder Qualität. Er ordnet Signalisierung. Der Medienpfad braucht eigene Belege.

RFC 4028 ergänzte ausgehandelte Session-Timer und Refreshes mit re-INVITE oder UPDATE. Dialoge aus demselben INVITE dürfen unterschiedliche Intervalle oder keinen Timer besitzen. Jeder Refresh ist eine neue Transaktion im bestehenden Kontext. Erfolg verlängert die Sitzung; ein fehlender Refresh kann zu BYE führen. Das Tupel ist kein ewiges Nutzungsrecht.

Ein Dialog konnte mehrere Nutzungen tragen

Erweiterungen widerlegten auch „ein Dialog, ein Anruf“. INVITE erzeugt eine invite usage; SUBSCRIBE oder REFER im Dialog kann weitere Nutzungen anlegen. RFC 5057 beschreibt, wie sie Call-ID, Tags, CSeq, Route-Set, Kontakte, remote target und secure flag teilen, aber eigenen Zustand wie Abonnementdauer behalten.

Das normale Ende einer Nutzung muss andere nicht löschen. BYE kann die invite usage beenden, während ein Ereignisabonnement weiterlebt. Dessen Ende zerstört nicht zwingend die Einladung. Der Dialog ist gemeinsamer Signalisierungsbehälter, keine gemeinsame Lebensdauer aller Anwendungen.

RFC 6665 macht die Grenze bei Ereignismeldungen greifbar. SUBSCRIBE und NOTIFY verwenden Dialogzustand, doch Event hilft, das konkrete Abonnement zuzuordnen. Ein geforktes SUBSCRIBE kann unabhängige, getrennt erneuerte Dialoge schaffen. Das Tupel findet den gemeinsamen Kontext, ist aber nicht der vollständige Schlüssel jeder Nutzung.

Die Stärke der dreiteiligen Kennung lag in ihrer Begrenzung. Sie benannte den Peer-Kontext, während Transaktionen endeten, Kontakte wanderten, Routen blieben, Medien wechselten und Anwendungen Zustand hinzufügten. Sie beanspruchte nicht, all dies selbst zu identifizieren.