17. Transaktionen (Transactions)
SIP ist ein Transaktionsprotokoll: Die Interaktionen zwischen Komponenten erfolgen in einer Reihe unabhängiger Nachrichtenaustausche. Genauer besteht eine SIP-Transaktion aus einer einzelnen Anfrage und allen Antworten auf diese Anfrage, die null oder mehr vorläufige Antworten und eine oder mehr finale Antworten umfassen. Im Fall einer Transaktion, deren Anfrage ein INVITE war (bekannt als INVITE-Transaktion), umfasst die Transaktion auch das ACK nur dann, wenn die finale Antwort keine 2xx-Antwort war. War die Antwort eine 2xx, wird das ACK nicht als Teil der Transaktion angesehen.
Der Grund für diese Trennung wurzelt in der Bedeutung, alle 200 (OK)-Antworten auf ein INVITE an den UAC zuzustellen. Um sie alle an den UAC zuzustellen, übernimmt allein der UAS die Verantwortung, sie zu retransmitieren (siehe Abschnitt 13.3.1.4), und allein der UAC übernimmt die Verantwortung, sie mit ACK zu bestätigen (siehe Abschnitt 13.2.2.4). Da dieses ACK nur vom UAC retransmitiert wird, wird es effektiv als eigene Transaktion betrachtet.
Transaktionen haben eine Client-Seite und eine Server-Seite. Die Client-Seite wird Client-Transaktion genannt und die Server-Seite Server-Transaktion. Die Client-Transaktion sendet die Anfrage, und die Server-Transaktion sendet die Antwort. Client- und Server-Transaktionen sind logische Funktionen, die in einer beliebigen Anzahl von Elementen integriert sind. Genauer existieren sie innerhalb von User Agents und zustandsbehafteten Proxy-Servern. Betrachten Sie das Beispiel aus Abschnitt 4. In diesem Beispiel führt der UAC die Client-Transaktion aus und sein Outbound-Proxy führt die Server-Transaktion aus. Der Outbound-Proxy führt auch eine Client-Transaktion aus, die eine Anfrage an eine Server-Transaktion im Inbound-Proxy sendet. Dieser Proxy führt auch eine Client-Transaktion aus, die wiederum eine Anfrage an eine Server-Transaktion im UAS sendet. Dies ist in Abbildung 4 dargestellt.
+---------+ +---------+ +---------+ +---------+ | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | | |C||------->||S| |C||------->||S| |C||------->||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||Response||s| |s||Response||s| |s||Response||s| | | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | +---------+ +---------+ +---------+ +---------+ UAC Outbound Inbound UAS Proxy Proxy
Abbildung 4: Transaktionsbeziehungen
Ein zustandsloser Proxy enthält keine Client- oder Server-Transaktion. Die Transaktion existiert zwischen dem UA oder zustandsbehafteten Proxy auf der einen Seite und dem UA oder zustandsbehafteten Proxy auf der anderen Seite. Hinsichtlich der SIP-Transaktionen ist der zustandslose Proxy effektiv transparent. Der Zweck der Client-Transaktion ist es, eine Anfrage von dem Element zu empfangen, in das der Client integriert ist (nennen wir dieses Element den „Transaction User“ oder TU; es kann ein UA oder ein zustandsbehafteter Proxy sein), und die Anfrage zuverlässig an eine Server-Transaktion zuzustellen.
Die Client-Transaktion ist auch dafür verantwortlich, Antworten zu empfangen und sie an den TU zu liefern, wobei sie alle Retransmissionen von Antworten oder nicht autorisierte Antworten (wie eine Antwort auf ein ACK) herausfiltert. Zusätzlich ist die Client-Transaktion im Fall einer INVITE-Anfrage dafür verantwortlich, die ACK-Anfrage für jede finale Antwort zu erzeugen, die eine 2xx-Antwort akzeptiert.
Ebenso besteht der Zweck der Server-Transaktion darin, Anfragen von der Transportschicht zu empfangen und sie an den TU zu liefern. Die Server-Transaktion filtert alle Retransmissionen von Anfragen aus dem Netzwerk heraus. Die Server-Transaktion akzeptiert Antworten vom TU und liefert sie an die Transportschicht zur Übertragung über das Netzwerk. Im Fall einer INVITE-Transaktion absorbiert sie die ACK-Anfrage für jede finale Antwort außer einer 2xx-Antwort.
Die 2xx-Antwort und ihr ACK erhalten eine spezielle Behandlung. Diese Antwort wird nur von einem UAS retransmitiert, und ihr ACK wird nur vom UAC erzeugt. Diese End-to-End-Behandlung ist notwendig, damit ein Anrufer die vollständige Menge der Benutzer kennt, die den Anruf angenommen haben. Aufgrund dieser speziellen Behandlung werden Retransmissionen der 2xx-Antwort vom UA-Kern und nicht von der Transaktionsschicht behandelt. Ebenso wird die Erzeugung des ACK für die 2xx vom UA-Kern behandelt. Jeder Proxy auf dem Pfad leitet einfach jede 2xx-Antwort auf das INVITE und das entsprechende ACK weiter.
17.1 Client-Transaktion (Client Transaction)
Die Client-Transaktion stellt ihre Funktionalität durch die Aufrechterhaltung einer Zustandsmaschine bereit.
Der TU kommuniziert über eine einfache Schnittstelle mit der Client-Transaktion. Wenn der TU eine neue Transaktion initiieren möchte, erstellt er eine Client-Transaktion und übergibt ihr die zu sendende SIP-Anfrage sowie eine IP-Adresse, einen Port und einen Transport, an die sie gesendet werden soll. Die Client-Transaktion beginnt die Ausführung ihrer Zustandsmaschine. Gültige Antworten werden von der Client-Transaktion an den TU übergeben.
Es gibt zwei Arten von Client-Transaktions-Zustandsmaschinen, abhängig von der Methode der vom TU übergebenen Anfrage. Eine verarbeitet Client-Transaktionen für INVITE-Anfragen. Diese Art von Maschine wird INVITE-Client-Transaktion genannt. Eine andere Art verarbeitet Client-Transaktionen für alle Anfragen außer INVITE und ACK. Sie wird nicht-INVITE-Client-Transaktion genannt. Es gibt keine Client-Transaktion für ACK. Wenn der TU ein ACK senden möchte, übergibt er es direkt an die Transportschicht zur Übertragung.
Die INVITE-Transaktion unterscheidet sich von der anderer Methoden aufgrund ihrer langen Dauer. Normalerweise ist eine menschliche Eingabe erforderlich, um auf ein INVITE zu antworten. Die bei der Antwort erwarteten langen Verzögerungen sprechen für einen Three-Way-Handshake. Andererseits werden Anfragen anderer Methoden erwartungsgemäß schnell abgeschlossen. Aufgrund der Abhängigkeit der nicht-INVITE-Transaktion von einem Two-Way-Handshake SOLLTEN TUs schnell auf nicht-INVITE-Anfragen antworten.
17.1.1 INVITE-Client-Transaktion (INVITE Client Transaction)
17.1.1.1 Überblick über die INVITE-Transaktion (Overview of INVITE Transaction)
Die INVITE-Transaktion besteht aus einem Three-Way-Handshake. Die Client-Transaktion sendet ein INVITE, die Server-Transaktion sendet Antworten, und die Client-Transaktion sendet ein ACK. Bei unzuverlässigen Transports (wie UDP) retransmitiert die Client-Transaktion die Anfragen in einem Intervall, das bei T1 Sekunden beginnt und nach jeder Retransmission verdoppelt wird. T1 ist eine Schätzung der Round-Trip-Zeit (RTT) und hat standardmäßig 500 ms. Fast alle hier beschriebenen Transaktionstimer werden mit T1 skaliert, und eine Änderung von T1 passt ihre Werte an. Die Anfrage wird über zuverlässige Transporte nicht retransmitiert. Nach dem Empfang einer 1xx-Antwort stoppen alle Retransmissionen vollständig, und der Client wartet auf weitere Antworten. Die Server-Transaktion kann zusätzliche 1xx-Antworten senden, die jedoch von der Server-Transaktion nicht zuverlässig übertragen werden. Schließlich entscheidet sich die Server-Transaktion, eine finale Antwort zu senden. Bei unzuverlässigen Transports wird diese Antwort periodisch retransmitiert, bei zuverlässigen Transports einmal gesendet. Für jede finale Antwort, die bei der Client-Transaktion empfangen wird, sendet die Client-Transaktion ein ACK, dessen Zweck es ist, die Retransmissionen der Antwort zu löschen.
17.1.1.2 Formale Beschreibung (Formal Description)
Die Zustandsmaschine für die INVITE-Client-Transaktion ist in Abbildung 5 dargestellt. Der Anfangszustand „calling“ MUSS betreten werden, wenn der TU eine neue Client-Transaktion mit einer INVITE-Anfrage initiiert. Die Client-Transaktion MUSS die Anfrage an die Transportschicht zur Übertragung übergeben (siehe Abschnitt 18). Wenn ein unzuverlässiger Transport verwendet wird, MUSS die Client-Transaktion den Timer A mit dem Wert T1 starten. Wenn ein zuverlässiger Transport verwendet wird, SOLLTE die Client-Transaktion den Timer A nicht starten (der Timer A steuert die Retransmissionen der Anfrage). Bei jedem Transport MUSS die Client-Transaktion den Timer B mit einem Wert von 64*T1 Sekunden starten (der Timer B steuert das Transaktions-Timeout).
Wenn Timer A abläuft, MUSS die Client-Transaktion die Anfrage an die Transportschicht übergeben, um sie zu retransmitieren, und MUSS den Timer mit einem Wert von 2*T1 zurücksetzen. Die formale Definition von Retransmission im Kontext der Transaktionsschicht ist, die zuvor an die Transportschicht gesendete Nachricht zu nehmen und sie erneut an die Transportschicht zu übergeben.
Wenn Timer A 2*T1 Sekunden später abläuft, MUSS die Anfrage erneut retransmitiert werden (unter der Annahme, dass sich die Client-Transaktion noch in diesem Zustand befindet). Dieser Prozess MUSS fortgesetzt werden, sodass die Anfrage mit Intervallen retransmitiert wird, die nach jeder Übertragung verdoppelt werden. Diese Retransmissionen SOLLTEN nur erfolgen, solange sich die Client-Transaktion im Zustand „calling“ befindet.
Der Standardwert von T1 ist 500 ms. T1 ist eine Schätzung der RTT zwischen Client- und Server-Transaktion. Elemente DÜRFEN (obwohl NICHT EMPFOHLEN) kleinere Werte von T1 in geschlossenen privaten Netzen verwenden, die keine allgemeine Internetverbindung zulassen. T1 darf größer gewählt werden, und dies wird EMPFOHLEN, wenn die RTT im Voraus als größer bekannt ist (z. B. bei Zugangsleitungen mit hoher Latenz). Welcher Wert von T1 auch immer gewählt wird, die exponentiellen Backoffs bei Retransmissionen aus diesem Abschnitt MÜSSEN verwendet werden.
Wenn die Client-Transaktion noch im Zustand „Calling“ ist, als Timer B abläuft, SOLLTE die Client-Transaktion den TU informieren, dass ein Timeout aufgetreten ist. Die Client-Transaktion DARF KEIN ACK erzeugen. Der Wert von 64*T1 entspricht der Zeit, die zum Senden von sieben Anfragen bei einem unzuverlässigen Transport benötigt wird.
Wenn die Client-Transaktion im Zustand „Calling“ eine vorläufige Antwort empfängt, geht sie in den Zustand „Proceeding“ über. Im Zustand „Proceeding“ SOLLTE die Client-Transaktion die Anfrage nicht weiter retransmitieren. Zusätzlich MUSS die vorläufige Antwort an den TU übergeben werden. Jede weitere vorläufige Antwort MUSS an den TU übergeben werden, solange man sich im Zustand „Proceeding“ befindet.
Wenn man sich im Zustand „Calling“ oder „Proceeding“ befindet, führt der Empfang einer Antwort mit Statuscode 300-699 dazu, dass die Client-Transaktion in „Completed“ übergehen MUSS. Die Client-Transaktion MUSS die empfangene Antwort an den TU übergeben und MUSS eine ACK-Anfrage erzeugen (selbst wenn der Transport zuverlässig ist; Richtlinien zum Aufbau des ACK aus der Antwort finden sich in Abschnitt 17.1.1.3) und MUSS das ACK an die Transportschicht zur Übertragung übergeben. Das ACK MUSS an dieselbe Adresse, denselben Port und denselben Transport gesendet werden wie die ursprüngliche Anfrage. Die Client-Transaktion SOLLTE beim Eintritt in den Zustand „Completed“ den Timer D mit einem Wert von mindestens 32 Sekunden für unzuverlässige Transporte und null Sekunden für zuverlässige Transporte starten. Timer D spiegelt die Zeit wider, die die Server-Transaktion bei Verwendung unzuverlässiger Transporte im Zustand „Completed“ bleiben kann. Dies ist gleich dem Timer H in der INVITE-Server-Transaktion, dessen Standardwert 64*T1 ist. Da die Client-Transaktion den von der Server-Transaktion verwendeten Wert von T1 nicht kennt, wird ein absolutes Minimum von 32 s verwendet, anstatt Timer D auf T1 zu basieren.
Jede Retransmission der finalen Antwort, die im Zustand „Completed“ empfangen wird, MUSS dazu führen, dass das ACK erneut an die Transportschicht zur Retransmission übergeben wird, die neu empfangene Antwort darf jedoch NICHT an den TU übergeben werden. Eine Retransmission der Antwort ist definiert als jede Antwort, die gemäß den Regeln des Abschnitts 17.1.3 mit derselben Client-Transaktion übereinstimmen würde.
|INVITE from TU
Timer A fires |INVITE sent
Reset A, V Timer B fires
INVITE sent +-----------+ or Transport Err.
+---------| |---------------+inform TU
| | Calling | |
+-------->| |-------------->|
+-----------+ 2xx |
| | 2xx to TU |
| |1xx |
300-699 +---------------+ |1xx to TU |
ACK sent | | | resp. to TU | 1xx V | | 1xx to TU -----------+ | | +---------| | | | | |Proceeding |-------------->| | +-------->| | 2xx | | +-----------+ 2xx to TU | | 300-699 | | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300-699 V | | ACK sent +-----------+Transport Err. | transitions | +---------| |Inform TU | labeled with | | | Completed |-------------->| the event | +-------->| | | over the action | +-----------+ | to take | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+
Abbildung 5: INVITE-Client-Transaktion
Wenn Timer D abläuft, während sich die Client-Transaktion im Zustand „Completed“ befindet, MUSS die Client-Transaktion in den beendeten Zustand übergehen.
Wenn man sich im Zustand „Calling“ oder „Proceeding“ befindet, führt der Empfang einer 2xx-Antwort dazu, dass die Client-Transaktion in den Zustand „Terminated“ eintreten MUSS, und die Antwort MUSS an den TU übergeben werden. Die Verarbeitung dieser Antwort hängt davon ab, ob der TU ein Proxy-Kern oder ein UAC-Kern ist. Ein UAC-Kern wird die Erzeugung des ACK für diese Antwort übernehmen, während ein Proxy-Kern das 200 (OK) immer stromaufwärts weiterleitet. Die unterschiedliche Behandlung des 200 (OK) zwischen Proxy und UAC ist der Grund, warum diese Verarbeitung nicht in der Transaktionsschicht stattfindet.
Die Client-Transaktion MUSS zerstört werden, sobald sie in den Zustand „Terminated“ eintritt. Dies ist tatsächlich notwendig, um ein korrektes Verhalten sicherzustellen. Der Grund ist, dass 2xx-Antworten auf ein INVITE unterschiedlich behandelt werden; jede wird von den Proxys weitergeleitet, und die ACK-Verarbeitung in einem UAC ist unterschiedlich. Daher muss jede 2xx an einen Proxy-Kern (damit sie weitergeleitet werden kann) und an einen UAC-Kern (damit sie bestätigt werden kann) übergeben werden. Es findet keine Transaktionsschicht-Verarbeitung statt. Jedes Mal, wenn eine Antwort von der Transport-Schicht empfangen wird, wenn die Transport-Schicht keine entsprechende Client-Transaktion findet (unter Verwendung der Regeln des Abschnitts 17.1.3), wird die Antwort direkt an den Kern übergeben. Da die entsprechende Client-Transaktion durch die erste 2xx zerstört wird, finden die folgenden 2xx keine Übereinstimmung und werden daher an den Kern übergeben.
17.1.1.3 Aufbau der ACK-Anfrage (Construction of the ACK Request)
Dieser Abschnitt legt den Aufbau der ACK-Anfragen fest, die in der Client-Transaktion gesendet werden. Ein UAC-Kern, der ein ACK für eine 2xx erzeugt, MUSS stattdessen den Regeln aus Abschnitt 13 folgen.
Die von der Client-Transaktion erbaute ACK-Anfrage MUSS Werte für Call-ID, From und Request-URI enthalten, die gleich den Werten dieser Headerfelder in der an die Transportschicht übergebenen Anfrage (nennen wir dies die „ursprüngliche Anfrage“) sind. Das To-Headerfeld im ACK MUSS gleich dem To-Headerfeld in der bestätigten Antwort sein und unterscheidet sich daher normalerweise vom To-Headerfeld in der ursprünglichen Anfrage durch das Hinzufügen des tag-Parameters. Das ACK MUSS ein einziges Via-Headerfeld enthalten, und dieses MUSS gleich dem obersten Via-Headerfeld der ursprünglichen Anfrage sein. Das CSeq-Headerfeld im ACK MUSS dieselbe Sequenznummer wie in der ursprünglichen Anfrage enthalten, aber der Methodenparameter MUSS „ACK“ sein.
Wenn die INVITE-Anfrage, deren Antwort bestätigt wird, Route-Headerfelder hatte, MÜSSEN diese Headerfelder im ACK erscheinen. Dies stellt sicher, dass das ACK über einen beliebigen nachgelagerten zustandslosen Proxy korrekt geroutet werden kann.
Obwohl jede Anfrage einen Nachrichtentext enthalten darf, ist ein Nachrichtentext in einem ACK besonders, da die Anfrage nicht abgelehnt werden kann, wenn der Text nicht verstanden wird. Daher wird das Platzieren eines Nachrichtentexts in ein ACK für Nicht-2xx nicht EMPFOHLEN, aber wenn dies getan wird, sind die Texttypen auf alles beschränkt, was im INVITE erschien, unter der Annahme, dass die Antwort auf das INVITE keine 415 war. War sie es, darf der Text im ACK ein beliebiger im Accept-Headerfeld der 415 aufgeführter Typ sein.
Betrachten Sie zum Beispiel die folgende Anfrage:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
Die ACK-Anfrage für eine nicht 2xx finale Antwort auf diese Anfrage sähe so aus:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:[email protected]>;tag=99sa0xk
From: Alice <sip:[email protected]>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
17.1.2 Nicht-INVITE-Client-Transaktion (Non-INVITE Client Transaction)
17.1.2.1 Überblick über die nicht-INVITE-Transaktion (Overview of the non-INVITE Transaction)
Nicht-INVITE-Transaktionen verwenden kein ACK. Sie sind einfache Anfrage-Antwort-Austausche. Bei unzuverlässigen Transports werden die Anfragen in einem Intervall retransmitiert, das bei T1 beginnt und bis zum Erreichen von T2 verdoppelt wird. Wenn eine vorläufige Antwort empfangen wird, werden die Retransmissionen bei unzuverlässigen Transports fortgesetzt, aber mit einem Intervall von T2. Die Server-Transaktion retransmitiert die zuletzt gesendete Antwort (vorläufig oder final), nur wenn eine Retransmission der Anfrage empfangen wird. Dies ist der Grund, warum die Retransmissionen der Anfrage auch nach einer vorläufigen Antwort fortgesetzt werden müssen; sie stellen die zuverlässige Zustellung der finalen Antwort sicher.
Im Gegensatz zu einer INVITE-Transaktion hat eine nicht-INVITE-Transaktion keine spezielle Behandlung für die 2xx-Antwort. Dies führt dazu, dass nur eine einzige 2xx-Antwort auf eine nicht-INVITE-Anfrage jemals an einen UAC zugestellt wird.
17.1.2.2 Formale Beschreibung (Formal Description)
Die Zustandsmaschine für die nicht-INVITE-Client-Transaktion ist in Abbildung 6 dargestellt. Sie ist der für INVITE sehr ähnlich.
Der Zustand „Trying“ wird betreten, wenn der TU eine neue Client-Transaktion mit einer Anfrage initiiert. Beim Eintritt in diesen Zustand SOLLTE die Client-Transaktion den Timer F so setzen, dass er in 64T1 Sekunden abläuft. Die Anfrage MUSS an die Transportschicht zur Übertragung übergeben werden. Wenn ein unzuverlässiger Transport verwendet wird, MUSS die Client-Transaktion den Timer E so setzen, dass er in T1 Sekunden abläuft. Wenn Timer E in diesem Zustand abläuft, wird er zurückgesetzt, diesmal mit einem Wert von MIN(2T1, T2). Wenn er erneut abläuft, wird er auf MIN(4*T1, T2) zurückgesetzt. Dieser Prozess setzt sich fort, sodass Retransmissionen mit einem exponentiell wachsenden Intervall auftreten, das bei T2 gedeckelt wird. Der Standardwert von T2 ist 4 s und stellt die Zeit dar, die eine nicht-INVITE-Server-Transaktion benötigt, um auf eine Anfrage zu antworten, wenn sie nicht sofort antwortet. Für die Standardwerte von T1 und T2 ergibt dies Intervalle von 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s usw.
Wenn Timer F abläuft, während sich die Client-Transaktion noch im Zustand „Trying“ befindet, SOLLTE die Client-Transaktion den TU über das Timeout informieren und SOLLTE in den Zustand „Terminated“ übergehen. Wenn im Zustand „Trying“ eine vorläufige Antwort empfangen wird, MUSS die Antwort an den TU übergeben werden, und die Client-Transaktion SOLLTE in den Zustand „Proceeding“ übergehen. Wenn im Zustand „Trying“ eine finale Antwort (Statuscodes 200-699) empfangen wird, MUSS die Antwort an den TU übergeben werden, und die Client-Transaktion MUSS in den Zustand „Completed“ übergehen.
Wenn Timer E im Zustand „Proceeding“ abläuft, MUSS die Anfrage an die Transportschicht zur Retransmission übergeben werden, und Timer E MUSS mit einem Wert von T2 Sekunden zurückgesetzt werden. Wenn Timer F im Zustand „Proceeding“ abläuft, MUSS der TU über ein Timeout informiert werden, und die Client-Transaktion MUSS in den beendeten Zustand übergehen. Wenn im Zustand „Proceeding“ eine finale Antwort (Statuscodes 200-699) empfangen wird, MUSS die Antwort an den TU übergeben werden, und die Client-Transaktion MUSS in den Zustand „Completed“ übergehen.
Sobald die Client-Transaktion in den Zustand „Completed“ eingetreten ist, MUSS sie den Timer K für unzuverlässige Transporte in T4 Sekunden und für zuverlässige Transporte in null Sekunden ablaufen lassen. Der Zustand „Completed“ existiert, um etwaige zusätzliche Retransmissionen von Antworten zu puffern, die empfangen werden könnten (daher bleibt die Client-Transaktion dort nur bei unzuverlässigen Transports). T4 stellt die Zeit dar, die das Netzwerk benötigt, um Nachrichten zwischen Client- und Server-Transaktion zu löschen. Der Standardwert von T4 ist 5 s. Eine Antwort ist eine Retransmission, wenn sie gemäß den Regeln des Abschnitts 17.1.3 mit derselben Transaktion übereinstimmt. Wenn Timer K in diesem Zustand abläuft, MUSS die Client-Transaktion in den Zustand „Terminated“ übergehen.
Sobald die Transaktion im beendeten Zustand ist, MUSS sie sofort zerstört werden.
17.1.3 Abgleich von Antworten mit Client-Transaktionen (Matching Responses to Client Transactions)
Wenn die Client-Transportschicht eine Antwort empfängt, muss sie bestimmen, welche Client-Transaktion diese Antwort verarbeitet. Dadurch findet die Verarbeitung der Abschnitte 17.1.1 und 17.1.2 statt. Zu diesem Zweck wird der branch-Parameter des obersten Via-Headerfelds verwendet. Eine Antwort stimmt mit einer Client-Transaktion überein, wenn:
1. Der Wert des branch-Parameters im obersten Via-Headerfeld der Antwort gleich dem Wert des branch-Parameters im obersten Via-Headerfeld der die Transaktion erstellenden Anfrage ist.
2. Der Methodenparameter des CSeq-Headerfelds mit der Methode der die Transaktion erstellenden Anfrage übereinstimmt. Die Methode ist notwendig, da eine CANCEL-Anfrage eine andere Transaktion bildet, aber denselben branch-Parameterwert teilt.
Wenn eine Anfrage über Multicast gesendet wird, können mehrere Antworten von verschiedenen Servern generiert werden. Alle diese Antworten werden denselben branch-Parameter im obersten Via haben, aber unterschiedliche To-Tags. Die zuerst empfangene Antwort wird gemäß den obigen Regeln verwendet, und die anderen werden als Retransmissionen behandelt. Dies ist kein Fehler. SIP-Multicast bietet nur einen rudimentären „Single-Hop-Discovery-ähnlichen“ Dienst, der auf die Verarbeitung einer einzelnen Antwort beschränkt ist. Einzelheiten siehe Abschnitt 18.1.1.
17.1.4 Umgang mit Transportfehlern (Handling Transport Errors)
|Request from TU
|send request
Timer E V
send request +-----------+
+---------| |-------------------+
| | Trying | Timer F |
+-------->| | or Transport Err.|
+-----------+ inform TU |
200-699 | | |
resp. to TU | |1xx |
+---------------+ |resp. to TU |
| | |
| Timer E V Timer F |
| send req +-----------+ or Transport Err. |
| +---------| | inform TU |
| | |Proceeding |------------------>|
| +-------->| |-----+ |
| +-----------+ |1xx |
| | ^ |resp to TU |
| 200-699 | +--------+ |
| resp. to TU | |
| | |
| V |
| +-----------+ |
| | | |
| | Completed | |
| | | |
| +-----------+ |
| ^ | |
| | | Timer K |
+--------------+ | - |
| |
V |
NOTE: +-----------+ |
| | |
transitions | Terminated|\<------------------+
labeled with | |
the event +-----------+
over the action
to take
Abbildung 6: Nicht-INVITE-Client-Transaktion
Wenn die Client-Transaktion eine Anfrage an die Transportschicht zur Übertragung übergibt und die Transportschicht einen Fehler meldet, gehen Sie wie folgt vor.
Die Client-Transaktion SOLLTE den TU informieren, dass ein Transportfehler aufgetreten ist, und die Client-Transaktion SOLLTE direkt in den Zustand „Terminated“ übergehen. Der TU wird die in [4] beschriebenen Failover-Mechanismen behandeln.
17.2 Server-Transaktion (Server Transaction)
Die Server-Transaktion ist verantwortlich für die Zustellung von Anfragen an den TU und die zuverlässige Übertragung von Antworten. Dies wird durch eine Zustandsmaschine erreicht. Die Server-Transaktion wird vom Kern erstellt, wenn eine Anfrage empfangen wird, und wenn eine Transaktionsverarbeitung für diese Anfrage gewünscht wird (was nicht immer der Fall ist).
Wie bei der Client-Transaktion hängt die Zustandsmaschine davon ab, ob die empfangene Anfrage eine INVITE-Anfrage ist.
17.2.1 INVITE-Server-Transaktion (INVITE Server Transaction)
Das Zustandsdiagramm der INVITE-Server-Transaktion ist in Abbildung 7 dargestellt.
Wenn für eine Anfrage eine Server-Transaktion gebildet wird, tritt sie in den Zustand „Proceeding“ ein. Die Server-Transaktion MUSS eine 100 (Trying)-Antwort erzeugen. Sie darf jedoch die 100 (Trying)-Antwort nicht erzeugen, wenn sie weiß, dass der TU innerhalb von 200 ms eine vorläufige oder finale Antwort senden wird (sie weiß dies, weil sie die 100-Antwort auf eine frühere Anfrage in derselben Transaktion gesendet hat). Diese vorläufige Antwort ist notwendig, um Retransmissionen der Anfrage schnell zu löschen, um Netzwerküberlastung zu vermeiden. Die 100 (Trying)-Antwort wird gemäß den Verfahren des Abschnitts 8.2.6 aufgebaut, mit der Ausnahme, dass das Einfügen des Tags in das To-Headerfeld der Antwort (wenn es in der Anfrage nicht vorhanden war) von MAY auf SHOULD NOT herabgestuft wird. Die Anfrage MUSS an den TU übergeben werden.
Der TU kann eine beliebige Anzahl vorläufiger Antworten an die Server-Transaktion übergeben. Solange sich die Server-Transaktion im Zustand „Proceeding“ befindet, MUSS jede davon an die Transportschicht zur Übertragung übergeben werden. Sie werden von der Transaktionsschicht nicht zuverlässig übertragen (nicht retransmitiert) und verursachen keinen Zustandswechsel der Server-Transaktion. Wenn im Zustand „Proceeding“ eine Retransmission der Anfrage empfangen wird, MUSS die zuletzt vom TU empfangene vorläufige Antwort an die Transportschicht zur Retransmission übergeben werden. Eine Anfrage ist eine Retransmission, wenn sie gemäß den Regeln des Abschnitts 17.2.3 mit derselben Server-Transaktion übereinstimmt.
Im Zustand „Proceeding“, wenn der TU eine 2xx-Antwort an die Server-Transaktion übergibt, MUSS die Server-Transaktion diese Antwort an die Transportschicht zur Übertragung übergeben. Sie wird von der Server-Transaktion nicht retransmitiert, und die Retransmission von 2xx-Antworten wird vom TU behandelt. Die Server-Transaktion MUSS dann in den Zustand „Terminated“ übergehen.
Im Zustand „Proceeding“, wenn der TU eine Antwort mit Statuscode 300 bis 699 an die Server-Transaktion übergibt, MUSS diese Antwort an die Transportschicht zur Übertragung übergeben werden, und die Zustandsmaschine MUSS in den Zustand „Completed“ eintreten. Bei unzuverlässigen Transports wird Timer G auf Ablauf in T1 Sekunden gesetzt, bei zuverlässigen Transports nicht.
Dies ist eine Änderung gegenüber RFC 2543, die Antworten auch bei zuverlässigem Transport immer retransmitierte.
Beim Eintritt in den Zustand „Completed“ MUSS Timer H für alle Transports auf Ablauf in 64T1 Sekunden gesetzt werden. Timer H bestimmt, wann die Server-Transaktion die Retransmissionen der Antwort aufgibt. Sein Wert wird gleich dem Timer B gewählt (der Zeit, die die Client-Transaktion weiter versucht, die Anfrage zu senden). Wenn Timer G abläuft, wird die Antwort erneut an die Transportschicht zur Retransmission übergeben, und Timer G wird auf Ablauf in MIN(2T1, T2) Sekunden gesetzt. Danach wird bei jedem Ablauf von Timer G die Antwort erneut an den Transport zur Übertragung übergeben, und Timer G wird auf einen verdoppelten Wert zurückgesetzt, der jedoch bei T2 gedeckelt wird, wenn dieser Wert T2 überschreitet. Dies ist identisch mit dem Retransmissionsverhalten der Anfrage im Zustand „Trying“ der nicht-INVITE-Client-Transaktion. Zusätzlich SOLLTE der Server im Zustand „Completed“, wenn eine Retransmission der Anfrage empfangen wird, die Antwort an den Transport zur Retransmission übergeben.
Wenn die Server-Transaktion ein ACK empfängt, während sie sich im Zustand „Completed“ befindet, MUSS die Server-Transaktion in den Zustand „Confirmed“ übergehen. In diesem Zustand wird Timer G ignoriert, sodass alle Retransmissionen der Antwort stoppen.
Wenn Timer H im Zustand „Completed“ abläuft, bedeutet dies, dass kein ACK empfangen wurde. In diesem Fall MUSS die Server-Transaktion in den Zustand „Terminated“ übergehen und MUSS dem TU anzeigen, dass ein Transaktionsfehler aufgetreten ist.
|INVITE
|pass INV to TU
INVITE V send 100 if TU won't in 200ms
send response+-----------+
+--------| |--------+101-199 from TU
| | Proceeding| |send response
+------->| |\<-------+
| | Transport Err.
| | Inform TU
| |--------------->+
+-----------+ |
300-699 from TU | |2xx from TU |
send response | |send response |
| +------------------>+
| |
INVITE V Timer G fires |
send response+-----------+ send response |
+--------| |--------+ |
| | Completed | | |
+------->| |\<-------+ |
+-----------+ |
| | |
ACK | | |
- | +------------------>+
| Timer H fires |
V or Transport Err.|
+-----------+ Inform TU |
| | |
| Confirmed | |
| | |
+-----------+ |
| |
|Timer I fires |
|- |
| |
V |
+-----------+ |
| | |
| Terminated|\<---------------+
| |
+-----------+
Abbildung 7: INVITE-Server-Transaktion
Der Zweck des Zustands „Confirmed“ besteht darin, zusätzliche ACK-Nachrichten zu absorbieren, die durch Retransmissionen der finalen Antwort ausgelöst wurden. Beim Eintritt in diesen Zustand wird Timer I für unzuverlässige Transports auf Ablauf in T4 Sekunden und für zuverlässige Transports auf null Sekunden gesetzt. Wenn Timer I abläuft, MUSS der Server in den Zustand „Terminated“ übergehen.
Sobald die Transaktion in den Zustand „Terminated“ eintritt, MUSS sie sofort zerstört werden. Wie bei der Client-Transaktion ist dies notwendig, um die Zuverlässigkeit der 2xx-Antworten auf ein INVITE sicherzustellen.
17.2.2 Nicht-INVITE-Server-Transaktion (Non-INVITE Server Transaction)
Die Zustandsmaschine für die nicht-INVITE-Server-Transaktion ist in Abbildung 8 dargestellt.
Die Zustandsmaschine wird im Zustand „Trying“ initialisiert und erhält bei der Initialisierung eine Anfrage außer INVITE oder ACK. Diese Anfrage wird an den TU übergeben. Einmal im Zustand „Trying“ werden weitere Retransmissionen der Anfrage verworfen. Eine Anfrage ist eine Retransmission, wenn sie gemäß den im Abschnitt 17.2.3 angegebenen Regeln mit derselben Server-Transaktion übereinstimmt.
Im Zustand „Trying“, wenn der TU eine vorläufige Antwort an die Server-Transaktion übergibt, MUSS die Server-Transaktion in den Zustand „Proceeding“ eintreten. Die Antwort MUSS an die Transportschicht zur Übertragung übergeben werden. Im Zustand „Proceeding“ MUSS jede weitere vom TU empfangene vorläufige Antwort an die Transportschicht zur Übertragung übergeben werden. Im Zustand „Proceeding“, wenn eine Retransmission der Anfrage empfangen wird, MUSS die zuletzt gesendete vorläufige Antwort an die Transportschicht zur Retransmission übergeben werden. Wenn der TU eine finale Antwort (Statuscode 200-699) im Zustand „Proceeding“ an den Server übergibt, MUSS die Transaktion in den Zustand „Completed“ eintreten, und die Antwort MUSS an die Transportschicht zur Übertragung übergeben werden.
Sobald die Server-Transaktion in den Zustand „Completed“ eingetreten ist, MUSS sie den Timer J für unzuverlässige Transports auf Ablauf in 64*T1 Sekunden und für zuverlässige Transports auf null Sekunden setzen. Im Zustand „Completed“ MUSS die Server-Transaktion die finale Antwort bei jeder empfangenen Retransmission der Anfrage an die Transportschicht zur Retransmission übergeben. Jede andere finale Antwort, die im Zustand „Completed“ an die Server-Transaktion vom TU übergeben wird, MUSS verworfen werden. Die Server-Transaktion bleibt in diesem Zustand, bis Timer J abläuft, woraufhin sie in den Zustand „Terminated“ übergehen MUSS.
Die Server-Transaktion MUSS zerstört werden, sobald sie in den Zustand „Terminated“ eintritt.
17.2.3 Abgleich von Anfragen mit Server-Transaktionen (Matching Requests to Server Transactions)
Wenn ein Server eine Anfrage aus dem Netzwerk empfängt, muss er sie mit einer vorhandenen Transaktion abgleichen. Dies wird wie folgt erreicht.
Der branch-Parameter des obersten Via-Headerfelds der Anfrage wird untersucht. Wenn er vorhanden ist und mit dem Magic-Cookie „z9hG4bK“ beginnt, wurde die Anfrage von einer Client-Transaktion erzeugt, die dieser Spezifikation entspricht. Daher ist der branch-Parameter eindeutig unter allen von diesem Client gesendeten Transaktionen. Eine Anfrage stimmt mit einer Transaktion überein, wenn:
1. Der branch-Parameter in der Anfrage gleich dem im obersten Via-Headerfeld der die Transaktion erstellenden Anfrage ist, und
2. Der sent-by-Wert im obersten Via der Anfrage gleich dem in der die Transaktion erstellenden Anfrage ist, und
3. Die Methode der Anfrage mit der die Transaktion erstellenden Methode übereinstimmt. Für ACK ist jedoch die die Transaktion erstellende Methode INVITE.
Diese Abgleichsregel gilt gleichermaßen für INVITE- und nicht-INVITE-Transaktionen.
Der sent-by-Wert wird als Teil des Abgleichsprozesses verwendet, da zufällige oder böswillige Duplikate des branch-Parameters von verschiedenen Clients möglich sind.
Wenn der branch-Parameter des obersten Via-Headerfelds fehlt oder das Magic-Cookie nicht enthält, werden die folgenden Verfahren verwendet. Sie existieren, um die Abwärtskompatibilität mit RFC-2543-konformen Implementierungen zu behandeln.
Eine INVITE-Anfrage stimmt mit einer Transaktion überein, wenn Request-URI, To-Tag, From-Tag, Call-ID, CSeq und oberstes Via-Headerfeld mit denen der die Transaktion erstellenden INVITE-Anfrage übereinstimmen. In diesem Fall ist das INVITE eine Retransmission des ursprünglich die Transaktion erstellenden. Eine ACK-Anfrage stimmt mit einer Transaktion überein, wenn Request-URI, From-Tag, Call-ID, CSeq-Nummer (nicht Methode) und oberstes Via-Headerfeld mit denen der die Transaktion erstellenden INVITE-Anfrage übereinstimmen und das To-Tag im ACK mit dem To-Tag der vom Server gesendeten Antwort übereinstimmt. Der Abgleich erfolgt basierend auf den für jedes dieser Headerfelder definierten Abgleichsregeln. Das Einschließen des Tags des To-Headerfelds in den ACK-Abgleich hilft, die Mehrdeutigkeit beim Proxy zwischen einem ACK für eine 2xx und einem ACK für eine andere Antwort aufzuheben. Der Proxy könnte beide Antworten weitergeleitet haben (dies kann unter anormalen Bedingungen geschehen, insbesondere wenn der Proxy die Anfrage forkt und dann abstürzt, könnten die Antworten an einen anderen Proxy zugestellt werden, der mehrere Antworten stromaufwärts weiterleitet). Eine ACK-Anfrage, die mit einer zuvor durch ein ACK abgeglichenen INVITE-Transaktion übereinstimmt, wird als Retransmission jenes früheren ACK behandelt.
|Request received
|pass to TU
V
+-----------+
| |
| Trying |-------------+
| | |
+-----------+ |200-699 from TU
| |send response
|1xx from TU |
|send response |
| |
Request V 1xx from TU |
send response+-----------+send response|
+--------| |--------+ |
| | Proceeding| | |
+------->| |\<-------+ |
+\<--------------| | |
|Trnsprt Err +-----------+ |
|Inform TU | |
| | |
| |200-699 from TU |
| |send response |
| Request V |
| send response+-----------+ |
| +--------| | |
| | | Completed |\<------------+
| +------->| |
+\<--------------| |
|Trnsprt Err +-----------+
|Inform TU |
| |Timer J fires
| |-
| |
| V
| +-----------+
| | |
+-------------->| Terminated|
| |
+-----------+
Abbildung 8: Nicht-INVITE-Server-Transaktion
Für alle anderen Anfragemethoden stimmt eine Anfrage mit einer Transaktion überein, wenn Request-URI, To-Tag, From-Tag, Call-ID, CSeq (einschließlich Methode) und oberstes Via-Headerfeld mit denen der die Transaktion erstellenden Anfrage übereinstimmen. Der Abgleich erfolgt basierend auf den für jedes dieser Headerfelder definierten Abgleichsregeln. Wenn eine nicht-INVITE-Anfrage mit einer vorhandenen Transaktion übereinstimmt, ist sie eine Retransmission der die Transaktion erstellenden Anfrage.
Da die Abgleichsregeln den Request-URI einschließen, kann ein Server eine Antwort nicht mit einer Transaktion abgleichen. Wenn der TU eine Antwort an eine Server-Transaktion übergibt, muss er sie an die spezifische Server-Transaktion übergeben, für die die Antwort bestimmt ist.
17.2.4 Umgang mit Transportfehlern (Handling Transport Errors)
Wenn die Server-Transaktion eine Antwort an die Transportschicht zur Übertragung übergibt und die Transportschicht einen Fehler meldet, gehen Sie wie folgt vor.
Folgen Sie zunächst den Verfahren in [4], um zu versuchen, die Antwort über ein Backup zuzustellen. Wenn alle fehlschlagen, SOLLTE die Server-Transaktion dem TU auf Basis der Fehlerdefinition in [4] melden, dass ein Fehler aufgetreten ist, und SOLLTE in den beendeten Zustand übergehen.