Zum Hauptinhalt springen

13. Initiating a Session

13 Initiieren einer Sitzung (Initiating a Session)

13.1 Überblick (Overview)

Wenn ein User Agent Client eine Sitzung (Sprache, Video oder Spiel) beginnen möchte, erstellt er eine INVITE-Anfrage. Die INVITE-Anfrage fordert beim Server die Etablierung einer Sitzung an. Diese Anfrage wird von Proxys weitergeleitet und erreicht schließlich einen oder mehrere UAS, die die Einladung akzeptieren könnten. Diese UAS müssen oft den Benutzer befragen, ob er die Einladung annimmt.

Nach einiger Zeit können diese UAS die Einladung akzeptieren, indem sie eine 2xx-Antwort senden (was die Sitzung etabliert). Wird die Einladung nicht akzeptiert, wird eine 3xx-, 4xx-, 5xx- oder 6xx-Antwort gesendet. Vor der endgültigen Antwort DARF ein UAS eine vorläufige Antwort (1xx) senden, um den Fortschritt anzuzeigen.

Nach dem Empfang einer oder mehrerer vorläufiger Antworten empfängt der UAC eine oder mehrere 2xx-Endantworten oder eine einzelne nicht-2xx-Endantwort. Wegen der möglichen Dauer für eine endgültige Antwort unterscheidet sich der Zuverlässigkeitsmechanismus der INVITE-Transaktion von dem anderer Anfragen. Bei Empfang einer Endantwort MUSS der UAC für jede empfangene Endantwort ein ACK senden.

Eine 2xx-Antwort auf ein INVITE etabliert die Sitzung und erstellt einen Dialog zwischen dem UA, der das INVITE gesendet hat, und dem UA, der die 2xx-Antwort generiert hat. Werden also mehrere 2xx-Antworten von verschiedenen entfernten UAs empfangen (da das INVITE geforkt wurde), etabliert jedes 2xx einen separaten Dialog. Alle diese Dialoge gehören zum selben Anruf.

Dieser Abschnitt beschreibt die Details der Sitzungsetablierung mit INVITE. Ein UA, der INVITE unterstützt, MUSS auch ACK, CANCEL und BYE unterstützen.

13.2 UAC-Verarbeitung (UAC Processing)

13.2.1 Erstellen des initialen INVITE (Creating the Initial INVITE)

Da ein initiales INVITE eine Anfrage außerhalb eines Dialogs darstellt, folgt sein Aufbau den Verfahren aus Abschnitt 8.1.1. Zusätzliche Verarbeitung ist für den Sonderfall INVITE nötig.

Ein Allow-Header-Feld SOLLTE in der INVITE vorhanden sein. Es gibt die Methoden an, die während der Dauer des Dialogs auf dem UA aufgerufen werden können. Ein Supported-Header-Feld SOLLTE vorhanden sein und alle verstandenen Erweiterungen aufzählen. Ein Accept-Header-Feld DARF vorhanden sein. Ein UAC DARF ein Expires-Feld hinzufügen, um die Gültigkeit der Einladung zu begrenzen.

Ein UAC DARF einen Nachrichtenrumpf hinzufügen. Sitzungsbeschreibungen haben Sonderregeln: Ihr Content-Disposition ist „session“. SIP verwendet ein Angebot/Antwort-Modell (Offer/Answer). Die Regeln für die initiale INVITE-Transaktion sind:

  o Das initiale Angebot MUSS in der INVITE oder, falls nicht, in der ersten zuverlässigen nicht fehlschlagenden Nachricht des UAS an den UAC (in dieser Spezifikation die 2xx-Endantwort) sein.
o Ist das initiale Angebot in der INVITE, MUSS die Antwort in einer zuverlässigen nicht fehlschlagenden Nachricht des UAS an den UAC sein (nur die 2xx-Antwort). Der UAC MUSS die erste Sitzungsbeschreibung als Antwort behandeln und spätere ignorieren.
o Ist das initiale Angebot in der 2xx, MUSS die Antwort im ACK auf diese Antwort sein.
o Nach dem Senden oder Empfangen der Antwort auf das initiale Angebot DARF der UAC ein Folgeangebot in einer späteren Anfrage generieren.
o Nach dem Senden oder Empfangen der Antwort auf das initiale Angebot DARF ein UAS KEINE Folgeangebote in Antworten auf die initiale Transaktion generieren.

Jeder UA, der INVITE unterstützt, MUSS diese beiden Austausche unterstützen: Angebot in INVITE und Antwort in 2xx, oder Angebot in 2xx und Antwort in ACK. SDP MUSS von allen User Agents unterstützt werden.

Wenn die Content-Disposition fehlt, hat ein application/sdp-Rumpf die Disposition „session“, andere Content-Types „render“.

Nach Erstellung des INVITE befolgt der UAC die Verfahren zum Senden einer Anfrage außerhalb eines Dialogs.

13.2.2 Verarbeitung von INVITE-Antworten (Processing INVITE Responses)

Wurde das INVITE an die INVITE-Client-Transaktion übergeben, wartet der UAC auf Antworten. Gibt die Transaktion statt einer Antwort einen Timeout zurück, verhält sich der TU wie beim Empfang einer 408-Antwort.

13.2.2.1 1xx-Antworten (1xx Responses)

Null, eine oder mehrere vorläufige Antworten können eintreffen, bevor eine oder mehrere Endantworten empfangen werden. Eine vorläufige Antwort auf eine INVITE-Anfrage KANN einen „frühen Dialog“ erstellen. Ein früher Dialog ist nur nötig, wenn der UAC vor Abschluss der initialen INVITE-Transaktion eine Anfrage im Dialog senden muss.

13.2.2.2 3xx-Antworten (3xx Responses)

Eine 3xx-Antwort KANN einen oder mehrere Contact-Header-Werte mit neuen erreichbaren Adressen enthalten. Je nach Statuscode DARF der UAC diese neuen Adressen ausprobieren.

13.2.2.3 4xx-, 5xx- und 6xx-Antworten (4xx, 5xx and 6xx Responses)

Es kann eine einzelne nicht-2xx-Endantwort empfangen werden. Alle frühen Dialoge gelten beim Empfang einer nicht-2xx-Endantwort als beendet. Nach dem Empfang einer nicht-2xx-Endantwort betrachtet der UAC core die INVITE-Transaktion als abgeschlossen; die INVITE-Client-Transaktion erzeugt das ACK.

13.2.2.4 2xx-Antworten (2xx Responses)

Wegen Forking-Proxys können mehrere 2xx-Antworten eintreffen. Stimmt die Dialog-ID der 2xx-Antwort mit einem vorhandenen Dialog überein, geht dieser in den „bestätigten“ Zustand über; andernfalls wird ein neuer bestätigter Dialog erstellt.

Der UAC core MUSS für jede 2xx-Antwort ein ACK generieren. Das ACK wird direkt an die Transportebene übergeben (nicht an eine Client-Transaktion). Enthält die 2xx ein Angebot, MUSS das ACK die Antwort im Rumpf tragen. Ist das Angebot nicht akzeptabel, MUSS der UAC core ein gültiges ACK mit Antwort erzeugen und danach ein BYE senden.

Der UAC core betrachtet die INVITE-Transaktion 64*T1 Sekunden nach der ersten 2xx-Antwort als abgeschlossen. Danach werden keine neuen 2xx-Antworten erwartet.

Nach Bestätigung einer 2xx-Antwort MUSS der UAC, falls er den Dialog nicht fortsetzen will, ein BYE senden.

13.3 UAS-Verarbeitung (UAS Processing)

13.3.1 Verarbeitung des INVITE (Processing of the INVITE)

Der UAS core empfängt die INVITE-Anfrage von der Transaktionsebene und führt zunächst die allgemeinen Anfrageverarbeitung aus Abschnitt 8.2 aus.

Danach führt der UAS core zusätzliche Schritte aus:

  1. Bei Expires-Feld in der INVITE eine Timer setzen; bei Ablauf 487 (Request Terminated) erzeugen.
2. Bei mid-dialog-Anfragen zunächst die methodenunabhängige Verarbeitung aus 12.2.2.
3. Hat das To-Feld eine Marke, stimmt die Dialog-ID aber mit keinem vorhandenen Dialog überein, ggf. Robustheitsbehandlung.

Enthält die INVITE eine Sitzungsbeschreibung, wird dem UAS ein Angebot präsentiert. Hat der UAC keine Beschreibung gesendet, MUSS der UAS das Angebot in der ersten zuverlässigen nicht fehlschlagenden Nachricht (2xx) liefern.

Der UAS kann Fortschritt anzeigen (101-199), annehmen (2xx), umleiten (3xx) oder ablehnen (4xx/6xx).

13.3.1.1 Fortschritt (Progress)

Kann der UAS nicht sofort antworten, DARF er mit vorläufigen Antworten 101-199 Fortschritt anzeigen. Er MUSS pro Minute eine Nicht-100-vorläufige Antwort senden, um das Abbrechen durch einen Proxy zu verhindern.

13.3.1.2 INVITE wird umgeleitet (The INVITE is Redirected)

Entscheidet sich der UAS zum Umleiten, wird eine 3xx-Antwort gesendet, die ein Contact-Feld mit neuen Adressen enthalten SOLLTE.

13.3.1.3 INVITE wird abgelehnt (The INVITE is Rejected)

Ist der Angerufene derzeit nicht verfügbar, SOLLTE 486 (Busy Here) zurückgegeben werden. Lehnt der UAS ein im INVITE enthaltenes Angebot ab, SOLLTE er 488 (Not Acceptable Here) mit Warning zurückgeben.

13.3.1.4 INVITE wird akzeptiert (The INVITE is Accepted)

Der UAS core erzeugt eine 2xx-Antwort, die einen Dialog etabliert. Sie SOLLTE Allow und Supported enthalten, Accept darf enthalten sein. Ist in der INVITE ein Angebot enthalten und noch keine Antwort gesendet, MUSS die 2xx eine Antwort enthalten; ist kein Angebot enthalten, MUSS die 2xx ein Angebot enthalten.

Die 2xx-Antwort wird periodisch an den Transport übergeben, bis das ACK empfangen wird. Erhält der Server 64*T1 Sekunden lang kein ACK, SOLLTE die Sitzung per BYE beendet werden.