5. Struktur des Protokolls (Structure of the Protocol)
5 Struktur des Protokolls (Structure of the Protocol)
SIP ist als Schichtenprotokoll (layered protocol) strukturiert. Das bedeutet, sein Betrieb wird als eine Reihe ziemlich unabhängiger Verarbeitungsschritte beschrieben, mit lockerer Kopplung zwischen den Stufen. Die Beschreibung des Protokolls in Schichten dient der Darstellungsbequemlichkeit, um gemeinsame Funktionalitäten in einem einzigen Abschnitt über die Elemente hinweg zu beschreiben. Dies schreibt die Implementierung in keiner Weise vor. Dass ein Element eine Schicht "enthält", bedeutet, dass es den für diese Schicht definierten Regelsatz einhält.
Nicht alle durch das Protokoll spezifizierten Elemente enthalten alle Schichten. Zudem sind die durch SIP spezifizierten Elemente logische, keine physischen Elemente. Eine physische Realisierung kann verschiedene logische Elemente kombinieren, möglicherweise sogar transaktionsweise ausgewählt.
Die unterste Schicht von SIP ist seine Syntax und Kodierung. Seine Kodierung wird unter Verwendung einer erweiterten Backus-Naur-Form-Grammatik (BNF) spezifiziert. Das vollständige BNF ist in Abschnitt 25 angegeben. Ein Überblick über die Struktur der SIP-Nachrichten findet sich in Abschnitt 7.
Die zweite Schicht ist die Transportschicht (transport layer). Sie definiert, wie ein Client eine Anfrage sendet und eine Antwort empfängt und wie ein Server eine Anfrage empfängt und eine Antwort über das Netz sendet. Alle SIP-Elemente enthalten die Transportschicht. Die Transportschicht ist in Abschnitt 18 beschrieben.
Die dritte Schicht ist die Transaktionsschicht (transaction layer). Eine Transaktion ist der grundlegende Baustein von SIP. Eine Transaktion besteht aus einer Anfrage, die vom client transaction (unter Verwendung der Transportschicht) an das server transaction gesendet wird, und allen Antworten auf diese Anfrage, die vom server an den client gesendet werden. Die Transaktionsschicht behandelt Retransmissionen auf Anwendungsebene, das Zuordnen von Antworten zu Anfragen und Zeitüberschreitungen auf Anwendungsebene. Jede Aufgabe, die von einem user agent client (UAC) ausgeführt wird, erfolgt mittels einer Reihe von Transaktionen. Die Diskussion über Transaktionen befindet sich in Abschnitt 17. Ein user agent enthält die Transaktionsschicht, ebenso wie ein stateful proxy. Ein stateless proxy enthält keine Transaktionsschicht. Die Transaktionsschicht hat eine Client-Komponente (client transaction genannt) und eine Server-Komponente (server transaction genannt), die jeweils als endliche Zustandsmaschine (finite state machine) ausgedrückt werden, die zur Behandlung einer bestimmten Anfrage konstruiert ist.
Die Schicht über der Transaktionsschicht wird transaction user (TU) genannt. Jede SIP-Entität mit Ausnahme des stateless proxy ist ein transaction user. Wenn ein TU eine Anfrage senden möchte, erstellt er eine client transaction-Instanz und übergibt ihr die Anfrage sowie die Ziel-IP-Adresse, den Port und den Transport, an die sie gesendet werden soll. Der TU, der die client transaction erstellt hat, kann diese auch abbrechen. Wenn ein Client eine Transaktion abbricht, fordert er den Server auf, jedwede weitere Verarbeitung einzustellen und in den Zustand vor dem Start der Transaktion zurückzukehren, wobei er eine bestimmte Fehlerantwort für diese Transaktion erzeugt. Dies geschieht durch eine CANCEL-Anfrage, die selbst eine Transaktion darstellt, aber auf die abgebrochene Transaktion verweist (Abschnitt 9).
Die SIP-Elemente, nämlich user agent client und server, stateless- und stateful proxy sowie registrar, enthalten einen core, der sie unterscheidet. Mit Ausnahme des stateless proxy ist der core ein transaction user. Die Regeln des core für UAC und UAS hängen von der Methode ab, aber es gibt einige allen Methoden gemeinsame Regeln (Abschnitt 8). Für den UAC regeln diese den Aufbau der Anfragen. Für den UAS regeln sie die Verarbeitung der Anfragen und die Erzeugung der Antworten. Da die Registrierung in SIP eine wichtige Rolle spielt, erhält der UAS, der REGISTER verarbeitet, einen besonderen Namen, registrar. Abschnitt 10 beschreibt das Verhalten des UAC- und UAS-core der REGISTER-Methode. Abschnitt 11 beschreibt das Verhalten des UAC- und UAS-core der OPTIONS-Methode, die zur Bestimmung der Fähigkeiten eines UA verwendet wird.
Einige andere Anfragen werden in einem dialog gesendet. Ein dialog ist eine peer-to-peer-SIP-Beziehung zwischen zwei user agents, die für einige Zeit bestehen bleibt. Ein dialog erleichtert die Reihenfolge der Nachrichten und das angemessene Routing von Anfragen zwischen user agents. Die Methode INVITE ist die einzige in dieser Spezifikation definierte, um einen dialog zu etablieren. Wenn ein UAC eine Anfrage im Kontext eines dialog sendet, folgt er den gemeinsamen UAC-Regeln in Abschnitt 8 sowie den Regeln für Anfragen in einem dialog. Abschnitt 12 erörtert dialogs, stellt ihre Verfahren zum Aufbau und zur Wartung sowie den Aufbau von Anfragen in einem dialog vor.
Die wichtigste SIP-Methode ist INVITE, die verwendet wird, um eine Session zwischen Teilnehmern zu etablieren. Eine session ist eine Menge von Teilnehmern und Medienströmen zwischen ihnen, zur Kommunikation. Abschnitt 13 erörtert, wie eine Session startet und zu einem oder mehreren SIP-dialogs wird. Abschnitt 14 erörtert, wie die Merkmale dieser session durch die Verwendung von INVITE-Anfragen in einem dialog geändert werden. Schließlich erörtert Abschnitt 15, wie eine session endet.
Die Verfahren der Abschnitte 8, 10, 11, 12, 13, 14 und 15 behandeln nur den UA-core (Abschnitt 9 beschreibt den Abbruch, der auf den UA-core und proxy-core anwendbar ist). Abschnitt 16 erörtert das proxy-Element, das das Routing von Nachrichten zwischen user agents erleichtert.