4. Überblick über den Betrieb (Overview of Operation)
4 Überblick über den Betrieb (Overview of Operation)
Dieser Abschnitt führt die Grundfunktionen von SIP anhand eines einfachen Beispiels ein. Dieser Abschnitt hat einen tutorialartigen Charakter und enthält keine normativen Aussagen.
Das erste Beispiel zeigt die Grundfunktionen von SIP: die Erkennung von Endpunkten, die Signalisierung des Wunsches zu kommunizieren, die Aushandlung der Sitzungsparameter zum Aufbau einer Session und den Abbau (teardown) der etablierten Session.
Figure 1 zeigt einen typischen SIP-Nachrichtenaustausch zwischen zwei Benutzern, Alice und Bob. (Jede Nachricht ist mit einem Buchstaben "F" und einer Zahl für Referenzen aus dem Text versehen.) In diesem Beispiel verwendet Alice eine SIP-Anwendung auf ihrem PC (softphone genannt), um Bob über das Internet anzurufen. Zwei SIP-Proxy-Server, die für Alice und Bob agieren, sind ebenfalls dargestellt. Diese typische Anordnung wird oft als "SIP-Trapez (SIP trapezoid)" nach der gestrichelten geometrischen Form in Figure 1 bezeichnet.
Alice "ruft" Bob unter Verwendung seiner SIP-Identität, einem Typ von Uniform Resource Identifier (URI), genannt SIP URI. Ein SIP URI ist in Abschnitt 19.1 definiert. Sein Format ähnelt einer E-Mail-Adresse und enthält normalerweise einen Benutzernamen und einen Hostnamen. In diesem Fall ist es sip:[email protected], wobei biloxi.com die Domäne von Bobs SIP-Dienstanbieter ist. Alices SIP URI ist sip:[email protected]. Alice hat Bobs URI möglicherweise eingegeben oder auf einen Hyperlink oder ein Adressbucheintrag geklickt. SIP stellt auch einen sicheren URI namens SIPS URI bereit. Ein Beispiel ist sips:[email protected]. Ein Anruf an einen SIPS URI stellt sicher, dass alle SIP-Nachrichten vom Anrufer zur Domäne des Gerufenen unter Verwendung eines sicheren und verschlüsselten Transports (d. h. TLS) übertragen werden. Von dort wird die Anfrage sicher an den Gerufenen gesendet, aber der Sicherheitsmechanismus hängt von der Richtlinie der Domäne des Gerufenen ab.
SIP basiert auf einem request/response-Transaktionsmodell ähnlich wie HTTP. Jede Transaktion besteht aus einer Anfrage, die eine bestimmte Methode (oder Funktion) auf einem Server aufruft, und mindestens einer Antwort. In diesem Beispiel beginnt die Transaktion, wenn Alices softphone eine INVITE-Anfrage an Bobs SIP URI sendet. INVITE ist ein Beispiel für eine SIP-Methode, die die Aktion angibt, die der Anforderer (Alice) vom Server (Bob) ausführen lassen möchte. Die INVITE-Anfrage (Nachricht F1 in Figure 1) enthält mehrere header fields. Header fields sind benannte Attribute, die zusätzliche Informationen über die Nachricht liefern. Die INVITE enthält: einen eindeutigen Anrufbezeichner, die Zieladresse, Alices Adresse und Informationen über den Typ der Session, die Alice mit Bob etablieren möchte. Die INVITE (Nachricht F1 in Figure 1) sieht so aus:
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|`<---------------| 100 Trying F5 |--------------->`|
| |\<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |\<---------------|
| 180 Ringing F8 |\<---------------| 200 OK F9 |
|\<---------------| 200 OK F10 |\<---------------|
| 200 OK F11 |\<---------------| |
|\<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|`<================================================>`|
| BYE F13 |
|\<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Figure 1: SIP session setup example with SIP trapezoid
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob `<sip:[email protected]>`
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Die erste Zeile der textkodierten Nachricht enthält den Methodennamen (INVITE). Die folgenden Zeilen sind die Liste der header fields. Dieses Beispiel enthält den minimal erforderlichen Satz. Die header fields werden kurz erläutert.
Via enthält die Adresse (pc33.atlanta.com), an der Alice die Antwort auf diese Anfrage erwartet. Sie enthält auch einen branch-Parameter, der diese Transaktion identifiziert.
To enthält den display name (Bob) und den SIP- oder SIPS-URI (sip:[email protected]), an den die Anfrage ursprünglich gerichtet war. Der display name ist in RFC 2822 [3] beschrieben.
From enthält ebenfalls den display name (Alice) und den SIP- oder SIPS-URI (sip:[email protected]), der den Initiator der Anfrage angibt. Dieses header field hat auch einen tag-Parameter mit einer zufälligen Zeichenkette (1928301774), die vom softphone an den URI angehängt wurde, zur Identifizierung.
Call-ID enthält einen global eindeutigen Bezeichner dieses Anrufs, erzeugt durch Kombination einer Zufallszeichenkette und des Hostnamens oder der IP-Adresse des softphones. Die Kombination aus To tag, From tag und Call-ID definiert vollständig die peer-to-peer-SIP-Beziehung zwischen Alice und Bob, genannt dialog.
CSeq (Command Sequence) enthält eine ganze Zahl und den Methodennamen. Die CSeq-Nummer wird für jede neue Anfrage in einem dialog inkrementiert; es ist eine klassische Sequenznummer.
Contact enthält einen SIP- oder SIPS-URI, der eine Route darstellt, um Alice direkt zu erreichen, normalerweise aus einem Benutzernamen auf einem voll qualifizierten Domänennamen (FQDN) bestehend. Der FQDN wird empfohlen, aber viele Endsysteme haben keinen registrierten Domänennamen, daher sind auch IP-Adressen erlaubt. Das Via header field weist andere Elemente an, wohin die Antwort zu senden ist, während das Contact header field anderen Elementen mitteilt, wohin zukünftige Anfragen zu senden sind.
Max-Forwards begrenzt die Anzahl der Hops, die die Anfrage vor Erreichen des Ziels durchlaufen kann. Es besteht aus einer ganzen Zahl, die bei jedem Hop um eins dekrementiert wird.
Content-Type enthält die Beschreibung des Nachrichtenrumpfs (hier nicht gezeigt).
Content-Length enthält die Anzahl der Oktette (Bytes) des Nachrichtenrumpfs.
Der vollständige Satz der SIP-header fields ist in Abschnitt 20 definiert.
Details des Medientyps, Codec oder Abtastrate werden nicht mit SIP beschrieben. Stattdessen enthält der Rumpf einer SIP-Nachricht eine Sitzungsbeschreibung, die in einem anderen Protokollformat kodiert ist. Ein solches Format ist das Session Description Protocol (SDP) (RFC 2327 [1]). Diese SDP-Nachricht (im Beispiel nicht gezeigt) wird von der SIP-Nachricht transportiert, ähnlich wie ein E-Mail eine Anlage oder ein HTTP eine Webseite transportiert.
Da das softphone weder Bobs Ort noch den SIP-Server in der Domäne biloxi.com kennt, sendet das softphone die INVITE an den SIP-Server, der einen Dienst in Alices Domäne atlanta.com bereitstellt. Die Adresse des SIP-Servers atlanta.com konnte auf Alices softphone konfiguriert oder etwa über DHCP entdeckt worden sein.
Der SIP-Server atlanta.com ist ein Typ von SIP-Server namens proxy server. Ein proxy server empfängt SIP-Anfragen und leitet sie im Auftrag des Anforderers weiter. In diesem Beispiel empfängt der proxy server die INVITE-Anfrage und sendet eine 100 (Trying)-Antwort an Alices softphone. Die 100 (Trying)-Antwort zeigt, dass die INVITE empfangen wurde und der Proxy sie für Alice zum Ziel routet. SIP-Antworten verwenden einen dreistelligen Code gefolgt von einer Phrase. Diese Antwort enthält dasselbe To, From, Call-ID, CSeq und den branch-Parameter in Via wie die INVITE, damit Alices softphone die Antwort der gesendeten INVITE zuordnen kann. Der proxy server atlanta.com findet den proxy server biloxi.com, wahrscheinlich durch eine bestimmte Art von DNS-Suche (Domain Name Service), um den SIP-Server zu finden, der einen Dienst in der Domäne biloxi.com bereitstellt, beschrieben in [4]. Er erhält die IP-Adresse des proxy server biloxi.com und leitet (proxy) die INVITE-Anfrage dorthin weiter. Vor dem Weiterleiten fügt der proxy server atlanta.com einen zusätzlichen Via-header field-Wert mit seiner eigenen Adresse hinzu (die INVITE enthielt bereits Alices Adresse im ersten Via). Der proxy server biloxi.com empfängt die INVITE und sendet eine 100 (Trying)-Antwort an den proxy server atlanta.com, die anzeigt, dass er die INVITE empfangen hat und verarbeitet. Der proxy server konsultiert eine Datenbank namens location service, die die aktuelle IP-Adresse von Bob enthält. (Die Einrichtung dieser Datenbank wird im nächsten Abschnitt gezeigt.) Der proxy server biloxi.com fügt einen weiteren Via-header field-Wert mit seiner eigenen Adresse zur INVITE hinzu und proxyed sie zum SIP-Telefon von Bob.
Bobs SIP-Telefon empfängt die INVITE, informiert Bob über den eingehenden Anruf von Alice und ermöglicht ihm zu entscheiden, ob er antwortet (d. h. ob Bobs Telefon klingelt). Bobs SIP-Telefon zeigt dies mit einer 180 (Ringing)-Antwort an, die über die beiden Proxys zurück geroutet wird. Jeder Proxy verwendet das Via header field, um zu bestimmen, wohin die Antwort zu senden ist, und entfernt seine eigene Adresse vom Anfang. So konnte die 180 (Ringing)-Antwort ohne Suche und ohne Zustand am Proxy zum Anforderer zurückgesendet werden, obwohl die ursprüngliche INVITE DNS- und location service-Suchen benötigte. Dies hat auch die wünschenswerte Eigenschaft, dass jeder Proxy, der die INVITE sieht, auch alle Antworten auf diese INVITE sieht.
Wenn Alices softphone die 180 (Ringing)-Antwort empfängt, informiert es Alice, wahrscheinlich durch Abspielen eines Ringback-Tons oder Anzeigen einer Nachricht auf dem Bildschirm.
In diesem Beispiel entscheidet Bob zu antworten. Wenn er abhebt, sendet sein SIP-Telefon eine 200 (OK)-Antwort, die anzeigt, dass der Anruf beantwortet wurde. Das 200 (OK) enthält einen Nachrichtenrumpf mit der SDP-Mediabeschreibung des Typs der Session, die Bob mit Alice etablieren möchte. So findet ein zweistufiger SDP-Austausch statt: Alice sendet einen an Bob, und Bob sendet einen an Alice. Dieser zweistufige Austausch bietet eine grundlegende Aushandlungsfunktion, basierend auf dem einfachen offer/answer-Modell des SDP-Austauschs. Wenn Bob nicht antworten möchte oder anderweitig beschäftigt ist, wird stattdessen eine Fehlerantwort gesendet, und die Mediasession wird nicht etabliert. Die vollständige Liste der SIP-Antwortcodes ist in Abschnitt 21. Das 200 (OK) (Nachricht F9 in Figure 1), das von Bob gesendet wird, sieht so aus:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob `<sip:[email protected]>`;tag=a6c85cf
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
Die erste Zeile der Antwort enthält den Antwortcode (200) und die Reason-Phrase (OK). Die restlichen Zeilen enthalten die header fields. Die Via-, To-, From-, Call-ID- und CSeq-header fields werden aus der INVITE-Anfrage kopiert. (Es gibt drei Via-header field-Werte - einer von Alices SIP-Telefon, einer vom Proxy atlanta.com und einer vom Proxy biloxi.com hinzugefügt.) Bobs SIP-Telefon hat einen tag-Parameter zum To header field hinzugefügt. Dieser tag wird von beiden Enden in den dialog eingebaut und ist in allen zukünftigen Anfragen und Antworten dieses Anrufs enthalten. Das Contact header field enthält den URI, unter dem Bobs SIP-Telefon direkt erreichbar ist. Content-Type und Content-Length beziehen sich auf den Nachrichtenrumpf mit Bobs SDP-Mediainformationen (nicht gezeigt).
Zusätzlich zu den in diesem Beispiel gezeigten DNS- und location service-Suchen kann ein proxy server flexible "Routing-Entscheidungen" treffen, um zu bestimmen, wohin eine Anfrage gesendet wird. Zum Beispiel kann, wenn Bobs SIP-Telefon eine 486 (Busy Here)-Antwort zurückgibt, der proxy server biloxi.com die INVITE zum Mailbox-Server (voicemail) von Bob proxen. Ein Proxy kann die INVITE auch gleichzeitig an mehrere Orte senden. Diese Art der parallelen Suche wird forking genannt.
In diesem Fall wird das 200 (OK) über die beiden Proxys zurückgeroutet und von Alices softphone empfangen, das den Rufton stoppt, um anzuzeigen, dass der Anruf beantwortet wurde. Schließlich sendet Alices softphone eine ACK-Bestätigungsnachricht an Bobs SIP-Telefon, um den Empfang der finalen Antwort (200 (OK)) zu bestätigen. In diesem Beispiel umgeht der ACK die beiden Proxys und wird direkt von Alices softphone an Bobs SIP-Telefon gesendet, da die Enden ihre Adressen über das Contact header field im INVITE/200 (OK)-Austausch gelernt haben, was beim Senden der ursprünglichen INVITE nicht bekannt war. Die von den beiden Proxys durchgeführten Suchen sind nicht mehr nötig, daher verlassen die Proxys den Anruffluss. Dies vervollständigt den INVITE/200/ACK-Drei-Wege-Handschlag, der zum Etablieren einer SIP-Session verwendet wird. Die vollständigen Details des Session-Aufbaus sind in Abschnitt 13.
Die Mediasession von Alice und Bob beginnt, und sie senden Mediapakete im im SDP-Austausch vereinbarten Format. Allgemein nehmen End-to-End-Mediapakete einen anderen Pfad als die SIP-Signalisierungsnachrichten.
Während der Session kann einer von Alice oder Bob entscheiden, die Merkmale der Mediasession zu ändern. Dies geschieht durch Senden eines re-INVITE mit einer neuen Mediabeschreibung. Da der re-INVITE auf einen bestehenden dialog verweist, weiß die Gegenseite, dass es sich um die Änderung einer bestehenden Session handelt, nicht um deren Etablierung. Die Gegenseite sendet ein 200 (OK), um die Änderung zu akzeptieren. Der Anforderer antwortet auf das 200 (OK) mit einem ACK. Wenn die Gegenseite die Änderung nicht akzeptiert, sendet sie eine Fehlerantwort wie 488 (Not Acceptable Here), die ebenfalls ein ACK erhält; aber das Fehlschlagen des re-INVITE führt nicht zum Fehlschlag des bestehenden Anrufs - die Session wird mit den zuvor ausgehandelten Merkmalen fortgesetzt. Die vollständigen Details der Sessionänderung sind in Abschnitt 14.
Am Ende des Anrufs legt Bob zuerst auf und erzeugt eine BYE-Nachricht. Dieses BYE umgeht ebenfalls die Proxys und wird direkt an Alices softphone geroutet. Alice bestätigt den Empfang des BYE mit einer 200 (OK)-Antwort, womit die Session und die BYE-Transaktion beendet sind. Es wird kein ACK gesendet - ein ACK wird nur als Antwort auf eine Antwort auf eine INVITE-Anfrage gesendet. Diese spezielle Behandlung der INVITE wird später erklärt, hängt aber mit dem Zuverlässigkeitsmechanismus von SIP, der Zeit, die ein Telefon zum Antworten benötigt, und dem forking zusammen. Daher wird die SIP-Anfragenverarbeitung oft als INVITE oder non-INVITE (sich auf alle Methoden außer INVITE beziehend) klassifiziert. Die vollständigen Details der Sessionbeendung sind in Abschnitt 15.
Abschnitt 24.2 beschreibt die Nachrichten der Figure 1 vollständig.
In einigen Fällen ist es nützlich, dass ein Proxy auf dem SIP-Signalisierungspfad alle Nachrichten zwischen den Enden während der Session sehen kann. Zum Beispiel, wenn der proxy server biloxi.com nach der ursprünglichen INVITE auf dem SIP-Signalisierungspfad bleiben möchte, fügt er ein obligatorisches Routing-header field namens Record-Route hinzu, das einen URI enthält, der zu seinem Hostnamen oder seiner IP-Adresse aufgelöst wird. Diese Informationen werden vom SIP-Telefon von Bob und (da der Record-Route im 200 (OK) zurückgesendet wird) von Alices softphone empfangen und für die Dauer des dialog gespeichert. Der proxy server biloxi.com empfängt dann und proxyed den ACK, das BYE und das 200 (OK) auf das BYE. Jeder Proxy entscheidet unabhängig, ob er die folgenden Nachrichten empfängt, und diese passieren alle Proxys, die sich zu ihrem Empfang entschieden haben. Diese Funktion wird oft für Proxys verwendet, die Mid-Call-Funktionen bereitstellen.
Die Registrierung (registration) ist eine weitere gängige SIP-Operation. Die Registrierung ist eine der Möglichkeiten, wie der Server biloxi.com den aktuellen Standort von Bob kennt. Bei der Initialisierung und in regelmäßigen Abständen sendet Bobs SIP-Telefon eine REGISTER-Nachricht an den registrar im Domäne biloxi.com. Die REGISTER-Nachricht ordnet Bobs SIP- oder SIPS-URI (sip:[email protected]) der Maschine zu, auf der er gerade angemeldet ist (im Contact header field als SIP- oder SIPS-URI mitgeteilt). Der registrar schreibt diese Zuordnung (auch binding genannt) in eine Datenbank namens location service, die vom Proxy in der Domäne biloxi.com genutzt werden kann. Oft ist der registrar-Server einer Domäne mit deren Proxy kolokalisiert. Es ist wichtig zu verstehen, dass die Unterscheidung zwischen SIP-Servern logisch und nicht physisch ist.
Bob ist nicht auf eine Registrierung von einem einzigen Gerät beschränkt. Zum Beispiel können sein SIP-Telefon zu Hause und sein SIP-Telefon im Büro beide Registrierungen senden. Diese Informationen werden gemeinsam im location service gespeichert, sodass der Proxy verschiedene Sucharten durchführen kann, um Bob zu finden. Ebenso können mehrere Benutzer gleichzeitig auf einem einzigen Gerät registriert sein.
Der location service ist eine Abstraktion. Er enthält allgemein Informationen, die es einem Proxy ermöglichen, durch Eingabe eines URI einen Satz von null oder mehr URIs zu erhalten, die angeben, wohin die Anfrage zu senden ist. Die Registrierung ist eine Möglichkeit, diese Informationen zu erstellen, aber nicht die einzige. Beliebige Mapping-Funktionen können nach Ermessen des Administrators konfiguriert werden.
Schließlich ist es wichtig zu beachten, dass in SIP die Registrierung für das Routing eingehender SIP-Anfragen verwendet wird und keine Rolle bei der Autorisierung ausgehender Anfragen spielt. Die Autorisierung und Authentifizierung werden in SIP durch einen challenge/response-Mechanismus pro Anfrage oder durch Verwendung von Unterschicht-Schemata behandelt, die in Abschnitt 26 beschrieben sind.
Die vollständigen Details der SIP-Nachrichten für dieses Registrierungsbeispiel sind in Abschnitt 24.1.
Weitere SIP-Operationen, wie das Abfragen der Fähigkeiten eines SIP-Servers oder -Clients mit OPTIONS oder das Abbrechen einer ausstehenden Anfrage mit CANCEL, werden in den folgenden Abschnitten vorgestellt.
<arg_key:6124c78e> <arg_key:6124c78e>explanation</arg_key:6124c78e> <arg_value:6124c78e>翻译 de 第4章 Overview of Operation