Zum Hauptinhalt springen

12. Dialogs

12 Dialogs

Ein Dialog ist eine Peer-to-Peer-SIP-Beziehung zwischen zwei User Agents, die für einige Zeit bestehen bleibt. Dialoge werden als Mittel verwendet, um einen Anruf (Call) aufzubauen (Abschnitt 13) sowie Anrufe zu ändern und zu beenden (Abschnitte 14 und 15). Dialoge bilden die Grundlage für fortgeschrittenere Funktionen (z. B. PRESENCE und REFER [1] zur Referenzierung von Medienressourcen eines Teilnehmers für einen anderen), die später definiert werden.

Ein Dialog wird durch die Call-ID und die lokalen und entfernten Tags (bekannt als To- und From-Tags) identifiziert (diese bilden einen eindeutigen Dialogbezeichner). Die Reihe der innerhalb eines Dialogs gesendeten Nachrichten umfasst die Aufrechterhaltung des Dialogzustands, einschließlich des entfernten Ziels (Remote Target) des Dialogs (der URI zum Senden von Nachrichten im Dialog) und des Routensatzes (Route Set) (eine Menge von Proxys), die den im Dialog gesendeten Anfragen entspricht. Der Dialog wird durch die Verhaltensweisen des UAS und UAC erstellt, wie in diesem Kapitel beschrieben.

Dieser Abschnitt führt das Konzept des Dialogzustands ein. Dieser Zustand ist notwendig, um die im jeweiligen Dialog gesendeten Anfragen zu routen. Dieser Zustand wird von der „Seite“ jedes UA aus verfolgt. Das heißt, in einem bestimmten Dialog halten UAC und UAS jeweils einen unterschiedlichen Zustand. Ein UA zeichnet den Zustand unter Verwendung der Konzepte der „lokalen“ und „entfernten“ Seite des Dialogs auf. Der lokale URI, das entfernte Ziel-URI, die entfernte Sequenznummer und der entfernte Tag des UAS entsprechen dem entfernten URI, dem lokalen Ziel-URI, der lokalen Sequenznummer und dem lokalen Tag des UAC. Jede Seite des Dialogzustands besteht aus einem Paar von Dialogbezeichnern (Call-ID, lokales Tag und entferntes Tag), einer lokalen Sequenznummer (nur UAC), einer entfernten Sequenznummer, einem entfernten URI (vom UAS verwendet, um zu bestimmen, wohin Nachrichten gesendet werden), einem entfernten Ziel-URI und einem Routensatz.

  Die Begriffe „entfernt“ und „lokal“ in Kapitel 12 beziehen sich auf einen bestimmten Dialogzustand und nicht auf das allgemeine UAS- und UAC-Verhalten in Kapitel 8.

Die Seiten halten den Dialogzustand aufrecht, indem sie den Dialog erstellen und über die Verarbeitung der ursprünglichen INVITE-Antwort (erfolgreich oder nicht) sowie der später im Dialog gesendeten Anfragen.

12.1 Erstellung eines Dialogs

Der Dialog wird durch die Verhaltensweisen des UAS und UAC erstellt, die ihn erzeugen. Das UAS-Verhalten ist in Abschnitt 12.1.1 und das UAC-Verhalten in Abschnitt 12.1.2 beschrieben. Der Dialog wird durch die UAS-Antwort auf ein neues INVITE erstellt, vorausgesetzt, die Antwort hat ein Tag im To-Feld und die Antwort ist ein 2xx- oder 101-199-Antwortcode. Umleitende 3xx-Antworten erstellen keinen Dialog.

  Hinweis: In RFC 2543 wurde der Dialog als Call bezeichnet, heißt nun aber Dialog. Dies lässt den Begriff Call mit seiner informellen Bedeutung (z. B. Call-Setup). Der Dialog wird durch den anfänglichen INVITE-Austausch zum Aufbau einer Sitzung etabliert. Der Dialog entspricht jedoch nicht notwendigerweise 1:1 einer Sitzung. Mehrere Dialoge (und damit mehrere Anrufe) können derselben Sitzung zugeordnet sein. Wenn ein User Agent ein re-INVITE für dieselbe Sitzung sendet, wird wie in Abschnitt 12.2 beschrieben kein neuer Dialog erstellt. Wenn jedoch ein Benutzer ein neues INVITE sendet, das zu einem anderen Dialog führt und dieses INVITE auf einen anderen Benutzer in derselben Sitzung verweist, wird ein weiterer Dialog (und damit ein weiterer Anruf) erstellt. Dies geschieht beispielsweise, wenn der Benutzer während eines Anrufs Call Transfer verwendet, um den ersten Anruf zu beenden und einen neuen zu starten.

12.1.1 UAS-Verhalten

Ein UAS, das eine einen Dialog erstellende Antwort (d. h. 101-199- oder 2xx-Antwort) erzeugt, MUSS (MUST) ein Tag im To-Header-Feld der Antwort (Abschnitt 8.2.6.2) enthalten. Dieses Tag bildet zusammen mit dem in der Antwort enthaltenen Call-ID-Wert und dem vom Anrufer bereitgestellten From-Tag die UAS-Seite des Dialogbezeichners. Die UAC-Seite des Dialogbezeichners (das Gegenteil der To- und From-Tags) wird durch die den Dialog erstellende Anfrage etabliert. Daher muss (NEED NOT) der UAC, der die Anfrage sendet, wenn die Anfrage keinen Dialog erstellt (z. B. eine Nicht-INVITE-Anfrage), den im To-Tag der Antwort enthaltenen Wert nicht speichern. Die UAC-Seite des Dialogbezeichners wird durch das From-Tag in der Anfrage und das To-Tag in der Antwort gebildet (da er der Ersteller der Anfrage, nicht der Antwort ist). Eine spätere Anfrage wie eine BYE-Anfrage etabliert die UAS-Seite des Dialogbezeichners unter Verwendung des From-Tags in der Anfrage (da er der UAC dieser Anfrage ist).

Ein UAS, das einen Anruf aufbaut, DARF (MAY) Werte des Record-Route-Header-Felds in die einen Dialog erstellende Antwort aufnehmen. Diese werden dem Dialogzustand hinzugefügt, um sicherzustellen, dass spätere Anfragen durch sie hindurchgehen.

Die entfernte Sequenznummer (aus Sicht des UAS) des erstellten Dialogs wird auf den Wert der Sequenznummer im CSeq-Header-Feld der Antwort gesetzt. Der entfernte URI wird auf den URI im To-Header-Feld der Antwort gesetzt. Das entfernte Ziel-URI wird auf den URI im Contact-Header-Feld der Antwort gesetzt.

12.1.2 UAC-Verhalten

Ein UAC, der eine einen Dialog erstellende Antwort (d. h. 2xx- oder 101-199-vorläufige Antwort) empfängt, MUSS (MUST) den entfernten Tag-Teil des Dialogbezeichners aus dem To-Feld der Antwort kopieren. Ist die Antwort 2xx, MUSS (MUST) der entfernte Tag aus der die Anfrage erstellenden Antwort kopiert werden, da einige Anfragen den Dialogzustand aus später empfangenen 1xx-Antworten erstellen können (Abschnitt 13). Der entfernte URI wird auf den URI im To-Header-Feld der Antwort gesetzt. Das entfernte Ziel-URI wird auf den URI im Contact-Header-Feld der Antwort gesetzt.

  Sind Werte des Record-Route-Header-Felds in der Antwort vorhanden (vom UAS bereitgestellt), MUSS (MUST) der UAC sie als Anfangswert des Routensatzes beibehalten und MUSS (MUST) sie umkehren (da sie in der Reihenfolge umgekehrt erscheinen, in der die Record-Route-Header-Felder hinzugefügt wurden). Der UAC verwendet den Routensatz, um Anfragen im Dialog zu senden (Abschnitt 12.2.1.1). Wenn eine spätere Anfrage im Dialog gesendet wird, wird die lokale Sequenznummer pro UAC auf die Sequenznummer im CSeq-Header-Feld der Anfrage gesetzt. Diese Sequenznummer MUSS (MUST) für jede im Dialog gesendete Anfrage um eins erhöht werden.

  Hinweis: Eine umleitende 3xx-Antwort erstellt keinen Dialog. Eine umleitende 3xx-Antwort wird vom UAC gemäß der Standardanforderung verarbeitet.

12.2 Anfragen innerhalb eines Dialogs

Dieser Abschnitt beschreibt, wie Anfragen innerhalb eines Dialogs gesendet werden. Dies umfasst Anfragen, die in einem bestehenden Dialog gesendet werden, wie ein re-INVITE (ein INVITE zum Aktualisieren des entfernten Ziels des Dialogs) oder ein BYE. Diese Anfragen werden unter Verwendung der in Abschnitt 8.1.1 definierten allgemeinen UAC-Anfrageerstellungsverfahren erstellt. Daher beschreibt dieser Abschnitt nur die spezifischen Abweichungen von diesen Verfahren. Das Senden dieser Anfragen verwendet nicht die Anfrage-Sequenznummer (CSeq) im Dialog (Warnung: es gibt einige Ausnahmen). Ein Proxy DARF (MAY) die Routensatzinformationen in Form der Entitätsvorlage verwenden, um beim Routen von im Dialog gesendeten Anfragen zu helfen.

Notation: Dieser Abschnitt nimmt an, dass, da der Dialog bereits als UAS oder UAC konfiguriert wurde, bevor die empfangende Seite die Anfrage verarbeitet, die ursprüngliche INVITE-Anfrage, die ihn erstellt hat, nicht als Anfrage im Dialog behandelt wird, unabhängig vom Status der ursprünglichen INVITE.

12.2.1 UAC-Verhalten

Eine im Dialog gesendete UAC-Anfrage MUSS (MUST) unter Verwendung des Dialogzustands geroutet werden.

12.2.1.1 Erzeugung der Anfrage

Bei der Erstellung der Anfrage MÜSSEN (MUST) die Header-Felder To, From und Call-ID auf den entfernten URI, lokalen URI und Call-ID des Dialogzustands gesetzt werden, und das CSeq-Header-Feld MUSS (MUST) auf einen neuen Wert gesetzt werden, der um eins höher ist als der letzte im Dialog gesendete CSeq-Wert. Der Request-URI der Anfrage MUSS (MUST) auf das entfernte Ziel-URI des Dialogs gesetzt werden. Ist der Routensatz nicht leer, MÜSSEN (MUST) die Werte des Route-Header-Felds der Anfrage die Werte des Routensatzes sein. Ist der Routensatz leer, SOLLTE (SHOULD) der Route-Header-Feldwert weggelassen werden.

  Hinweis: Dies stellt sicher, dass, wenn der Routensatz nicht leer ist, die Anfrage durch einen Proxy geht (das ist der Zweck der Bereitstellung des Routensatzes). Das entfernte Ziel-URI wird verwendet, um Proxys zu umgehen, da es eine direkte Route zwischen UAC und UAS bietet.

Zum Beispiel, wenn ein UAC ein re-INVITE in einem durch einen einzelnen Record-Route (Proxy) erstellten Dialog sendet:

  Re-INVITE sip:[email protected] SIP/2.0
  Via: SIP/2.0/UDP host.ua1.example.com;branch=z9hG4bKvscx
  Max-Forwards: 70
  To: Bob `<sip:[email protected]>;tag=a6c85cf`
  From: Alice `<sip:[email protected]>`;tag=1928301774
  Call-ID: [email protected]
  CSeq: 314160 INVITE
  Contact: `<sip:[email protected]>`
  Route: `<sip:proxy.example.com>`

Hinweis: Der einzige Via-Wert ist der URI des Absenders. Der CSeq-Wert des re-INVITE MUSS (MUST) größer als der des ursprünglichen INVITE sein. Beachten Sie, dass ein CSeq-Sequenznummernwert NICHT (MUST NOT) wiederverwendet werden darf. Der Route-Header-Feldwert wird aus dem Routensatz abgerufen.

Die folgenden Verfahren gelten für das Senden einer Anfrage in einem Dialog. Wenn eine Ziel-Auffrischungsanfrage (in Abschnitt 12.2.2 definiert) vom UAC im Dialog erzeugt wird, MUSS (MUST) der Contact-Header-Feldwert dieser Anfrage das entfernte Ziel-URI des Dialogs aktualisieren.

  Im Allgemeinen wird ein re-INVITE verwendet, um das entfernte Ziel des Dialogs zu aktualisieren, aber eine UPDATE-Anfrage oder andere Ziel-Auffrischungsanfragen können ebenfalls verwendet werden. Die in diesem Abschnitt beschriebenen Verfahren (einschließlich Routing) sind allgemeine Regeln, die es einer Ziel-Auffrischungsanfrage ermöglichen, sich mittels eines Booleschen zu aktualisieren. Für eine INVITE-Anfrage MUSS (MUST) ein re-INVITE auch verwendet werden, um eine Änderung der Sitzungsbeschreibung (Abschnitt 14) zu initialisieren.

12.2.1.2 Verarbeitung der Antwort

Eine Antwort auf eine im Dialog gesendete Anfrage wird unter Verwendung der in Abschnitt 8.1.3 beschriebenen Verfahren verarbeitet.

Beim Empfang einer 2xx-Antwort auf eine Ziel-Auffrischungsanfrage (in Abschnitt 12.2.2 definiert) MUSS (MUST) der UAC das entfernte Ziel-URI des Dialogs unter Verwendung des URI im Contact-Header-Feld der Antwort aktualisieren.

12.2.2 Ziel-Auffrischungsanfragen

Eine Ziel-Auffrischungsanfrage ist definiert als eine im Dialog gesendete Anfrage, die das entfernte Ziel des Dialogs ändern kann. Die INVITE- und UPDATE-Anfragen dieser Spezifikation sind Ziel-Auffrischungsanfragen. Andere im Dialog gesendete Anfragen (z. B. BYE) SOLLTEN (SHOULD NOT) das entfernte Ziel-URI nicht ändern.

12.3 Beendigung eines Dialogs

Ein Dialog endet durch den Empfang eines erfolgreichen BYE (mit 2xx-Antwort) oder durch eine Nicht-2xx-Antwort (z. B. 408 oder 480 für ein abgelehntes INVITE) (siehe Abschnitt 15). In beiden Fällen MUSS (MUST) die empfangende Seite den Dialogzustand löschen. Der Sender eines erfolgreichen BYE MUSS (MUST) ihn erst löschen, nachdem er das BYE empfangen hat (wobei ein UAC mit fehlgeschlagenem INVITE den Dialogzustand sofort löschen darf (MAY)).

  Hinweis: Ein Dialog, der zu einem fehlgeschlagenen INVITE gehört, endet durch den Empfang der endgültigen Antwort (erfolgreich oder fehlgeschlagen). Ein Dialog, der zu einem erfolgreichen INVITE gehört, endet nur durch eine spätere BYE-Anfrage. Daher beendet ein re-INVITE den Dialog, der die ursprüngliche INVITE-Anfrage enthält, nicht.

  Ein fehlgeschlagenes INVITE wird als einfache Transaktion behandelt. Ein Dialog, der zu einem erfolgreichen INVITE gehört, endet nur über den Empfang einer BYE-Anfrage. Selbst nach dem Ende über den Empfang eines BYE darf (MAY) der UAC den alten Dialogzustand beibehalten, bis alle Transaktionen im Dialog abgeschlossen sind.