1. Das Session Description Protocol (SDP)
2. Das Session Announcement Protocol (SAP)
3. Das Session Initialization Protocol (SIP)
4. SIP Methoden
5. SIP Cause Codes
Das Sitzungsbeschreibungsprotokoll SDP ist ein Beschreibungsprotokoll für bevorstehende Multimedia-Sitzungen. Das SDP geht unmittelbar einher mit dem SAP, das eine bevorstehende Sitzung ankündigt (für diese wirbt).
Allgemeine Verwendung von SDP und SAP für einen Anwender ist, eine bevorstehende Sitzung auszurufen, und die relevanten Setup-Informationen bekanntzumachen.Die Einladung selber erfolgt mit Hilfe des Session Initialization Protoclos (SIP). Das SAP sendet einen periodischen Multicast Rundruf, welcher die Ankündigung als Paket enthält (und in dessen Message-Body das SDP enthalten ist) und an eine bekannte Adresse (mit Port) gesendet wird.
Aufbau des SDP und SAP
SAP-Pakete sind UDP-Pakete (32bit lang) mit dem folgenden Format.
0 31
-----------------
| SAP-Header |
|---------------|
| |
| Text payload |
|/\/\/\/\/\/\/\/|
Die Ankündigungen werden per Email oder WWW ausgerufen.
Der MIME content type ist application/sdp. Der Empfänger einer Ankündigung muß die Sitzung nicht notwendigerweise empfangen können. (z.B. wenn er nicht über die bei der Sitzung ausgerufene Bandbreite verfügt oder die Sitzung privat ist.)
SDP bedient zwei primere Zwecke:
Die relevanten Informationen, die SDP übermittelt sind (u.a.):
Diese Informationen werden nach dem Schema = bekanntgegeben.
Sitzungs Beschreibung:
v= (Protokollversion)
o= (Eigentümer/Ersteller und Sitzungsidentifizierer).
s= (Sitzungsname)
i=* (Sitzungsinformation)
u=* (URI der Beschreibung)
e=* (email Adresse)
p=* (Telefonnummer)
c=* (connection information - nicht benötigt, wenn in allen Medien eingeschlossen)
b=* (Bandweite)
Eine oder mehr Zeitbeschreibungen (siehe unten)
z=* (Zeitzonenbeschreibung)
k=* (Krypto-Schlüssel für die Verschlüsselung)
a=* (Null oder mehr Zeilen für die Sitzungsbeschreibung)
Keine oder mehrere Medien-Beschreibungen
Zeitbeschreibung
t= (Zeit während der die Sitzung aktiv ist)
r=* (Keine oder mehrere Wiederholungszeiten)
Medienbeschreibung
m= (Medienname und Transportadresse)
i=* (Medientitel)
c=* (Verbindungsinformationen - optional, wenn im session-level beinhaltet)
b=* (Informationen zur Bandweite)
k=* (Kryptoschlüssel zur Verschlüsselung)
a=*(Keine oder mehrere Zeilen mit Medienattributen)
Beispiel:
v=0
o=MxSIP 0 89 IN IP4 195.69.183.122
s=SIP Call
c=IN IP4 195.69.183.122
t=0 0
m=audio 4864 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000..
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv
m=image 4866 udptl t38
a=sendrecv
Da SDP kein Transportprotokoll darstellt, hängt es sich an SAP (genauer gesagt in den Body oder Text-payload) und wird mit SAP zusammen per UDP übertragen.
Alle drei hier besprochenen Protokolle befinden sich in der Anwendungsschicht (nach OSI) Die darunterliegenden unterstützten Protokolle sind UDP und RTP bei SAP und
UDP, TCP und RTP bei SIP, wobei jedoch meistens nur UDP verwandt wird.
Weiterhin enthält das SDP-Paket noch zeitliche Informationen:
SDP unterstützt zeitlich abhängige sowie zeitlich unabhängige Sitzungen
Beispiele:
Die Zeitinformationen sind global gleich und nicht von der lokalen Zeit abhängig (GMT)
Die Sitzungen an sich können öffentlich oder privat abgehalten werden.
Bei privaten Sitzungen wird kryptographie verwandt, damit nur bestimmte Teilnehmer an der Sitzung partizipieren können. Private Sitzungen werden außerdem auch privat
verkündet, damit Informationen über die Art der Kryptoschlüssel informiert werden kann.
Weitere Möglichkeiten der Sitzungsbeschreibung:
SAP dient dazu, Sitzungen auszurufen (bekanntmachen).
Dazu benutzt es folgende Features:
Für das Timeout gibt es zwei verschiedene Arten:
1. Expliziter Timeout:
Dieses Paket muß folgende Informationen beinhalten:
>2. Impliziter Timeout:
Ähnlich läuft es ab, wenn per SAP geänderte Sitzungsinformationen bekannt gegeben werden sollen.
Eine vor-angekündigte Sitzung kann einfach durch bekanntgabe der Änderungen (der geänderten Werte) geändert werden. Die betroffene Sitzung wird eindeutig identifiziert durch das SDP-origin-Feld im Text payload. Für die Modifizierung gelten die gleichen Regeln, wie für die Löschung.
Aufgaben von SIP
SIP lädt zu bevorstehenden Sitzungen ein. Es etabliert und kontrolliert Multimedia Sitzungen oder Aufrufe. Die Unterstützten Dienste sind:
SIP unterstützt alle fünf Mittel um Multicast Sitzungen zu eröffnen:
Der Initiator einer Sitzung muß hierbei nicht notwendiger Weise auch an der Sitzung teilnehmen. Abgesehen von Personen kann SIP auch Programme (resp. Server) zu einer Sitzung einladen, zum Beispiel:
Funktionsweise des SIP
SIP initiiert eine Sitzung, kann aber auch dazu einladen. SIP wurde als Teil einer IETF* Multimedia Daten- und Kontrollarchitektur entwickelt.
*IETF = Internet Engineering Task Force, Zusammenschluss von verschiedenen Einzelpersonen, mit dem Zweck, das Internet weiterzuentwickeln.
SIP Adressierung:
Netzweradresse.
Beispiel:
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
root@[193.175.132.42]
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
Die Einladung:
Eine Erfolgreiche SIP Einladung besteht aus einem INVITE Request und dem dazugehörigen ACK Request des Clients. In dem INVITE Request ist das SDP Paket enthalten. Wenn der angerufene teilnehmen möchte, so wird ein SDP Protokoll zurückgesendet. Wenn der Client die Einladung annimmt sendet er einen ACK Request zurück. Im anderen Fall (Ablehnung der Einladung) wird Client-Seitig ein BYE Request zurückgesandt.
Caller SIP Proxy Callee
| | |
| INVITE | |
|--------------->| |
| 100 Trying | |
|<---------------| |
| INVITE | INVITE |
| |--------------->|
| | 100 Trying |
| |<---------------|
| | 180 Ringing |
| |<---------------|
| 180 Ringing | |
|<---------------| |
| | 200 OK |
| |<---------------|
| 200 OK | |
|<---------------| |
| ACK | |
|-------------------------------->|
| RTP Streams | |
o---------------------------------o
| |
Zuerst bekommt und akzeptiert der Proxy-Server einen INVITE Request, kontaktiert den location-service mit allen Teilen der Adresse und erfragt eine etwas präzisere Ortsangabe. Nun schickt der Proxy-Server einen SIP INVITE Request an die vom location-service zurückgelieferte Adresse. Der user-agent-server alarmiert nun
den Benutzer (der den INVITE abgesetzt hat) und übermittelt dem Proxy-Server die erfolgreiche Alarmierung des Benutzers. Der Proxy-Server wiederum gibt das erfolgreiche Resultat an den Anrufer zurück. Der Empfang dieser Nachricht wird seitens des Anrufers durch die Absetzung einer ACK Nachricht an den Angerufenen bestätigt. und nochmals kommt ein response zurück.
Aufbau von SIP Nachrichten
Eine SIP Nachricht ist eine Nachfrage vom Client an den Server oder eine Antwort des Servers an den Client. Die Pakete bestehen aus einem Header und einem Body. In dem Header stehen die Informationen, anhand derer erkannt werden kann, ob es sich um eine Client- oder Serverseitige Nachricht handelt.
Request:
Request Line = Method, Request-URL, SIP-Version
General Header
Request Header
Entity Header
[Message Body]
Method gibt die Art der Nachfrage an, z.B. INVITE, BYE, ACK
Response:
Status Line = SIP-Version, Status-Code, Reason-Phrase
General Header
Request Header
Entity Header
[Message Body]
Außerdem gibt es noch Status-Codes, die aus einem Zahlentripel bestehen, und das Resultat des Anrufs angeben:
1xx = Request erhalten und in Bearbeitung
2xx = Request erfolgreich empfangen
3xx = Weitere Aktionen sind notwendig
4xx = Client Fehler
5xx = Server Fehler
6xx = Request wird nicht akzeptiert.
Die Headerfields
general-header = Accept
| Accept-Encoding
| Accept-Language
| Call-ID
| Contact
| CSeq
| Date
| Encryption
| Expires
| From
| Record-Route
| Timestamp
| To
| Via
entity-header = Content-Encoding
| Content-Length
| Content-Type
request-header = Authorization
| Contact
| Hide
| Max-Forwards
| Organization
| Priority
| Proxy-Authorization
| Proxy-Require
| Route
| Require
| Response-Key
| Subject
| User-Agent
response-header = Allow
| Proxy-Authenticate
| Retry-After
| Server
| Unsupported
| Warning
| WWW-Authenticate
Das Format ist immer in der Form
Feldname : Feldwert
Der General Header bezieht sich auf die zu übermittelnde Nachricht
z.B.: Call- ID : 187602141351worcester.bell-telephone.com
Der Entity Header enthält Informationen über den Body
Der Request Header ermöglicht dem Client Informationen über sich oder über die Nachricht
an den Server zu senden.
z.B.: From :
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
Subject : A tornado is heading our way
Priority: urgent
Der Responce Header schließlich ermöglicht es dem Server, Informationen über den Responce
an den Client zu schicken. z.B.: Location: Bei einem 3xx-Responce enthält dieser Header
weitere SIP-URLs, die der Client anwenden sollte.
Die SIP-URL folgt den Richtlinien der RFC 1630
Es gibt zwei Arten von SIP-URLs: Kurzform und Langform.
Die Kurzform KANN ausschließlich innerhalb von SIP Nachrichten verwandt werden. In allen
anderen Fällen muß die Langform benutzt werden.
Beispiele für Kurz- und Langform SIP-URLs:
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
sip://
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
sip://j.doe:
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
;transport=tcp
sip://
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
?subject=project%20x&priority=urgent
sip://+1-212-555-1212:
Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
sip://alice@[10.1.2.3]
sip://alice@10.1.2.3
Der Messagebody (und Beispiele)
Der Message-Body enthält die Sitzungsbeschreibung (SDP)
C->S: INVITE Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. SIP/2.0SIP Methoden definiert durch SIP RFC
| INVITE | Einladen eines anderen UA zu einer Session |
| re-INVITE | Ändern einer bestehenden Session |
| REGISTER | Registrieren eines Standortes am Registrar |
| ACK | Bestätigung eines INVITEs |
| CANCEL | Abbruch eines INVITEs |
| BYE | Beenden einer Session |
| OPTIONS |
Host check |
SIP erweiterete Methoden definiert durch andere RFCs
| INFO | Erweiterung in RFC 2976 |
| NOTIFY | Erweiterung in RFC 2848 |
| SUBSCRIBE | Erweiterung in RFC 2848 |
| UNSUBSCRIBE | Erweiterung in RFC 2848 |
| UPDATE | Erweiterung in RFC 3311 |
| MESSAGE | Erweiterung in RFC 3428 |
| REFER | Erweiterung in RFC 3515 |
| PRACK | Erweiterung in RFC 3262 |
1xx Der Request wurde empfangen und wird nun verarbeitet
2xx Die Anfrage wurde erfolgreich empfangen und verarbeitet
3xx Der Anruf wird an einen anderen Server weitergeleitet
4xx Es ist ein Fehler auf der Clientseite aufgetreten
5xx Es ist ein Fehler auf der Serverseite aufgetreten
6xx Die Anfrage kann von keinem Server erfüllt werden
1xx SIP Response Codes, Klasse 1: Provisional Messages
2xx SIP Response Codes: Klasse 2: Success
3xx SIP Response Codes, Klasse 3: Redirection
4xx SIP Response Codes, Klasse 4: Request Failures
400 Bad Request5xx SIP Response Codes, Klasse 5: Server Failures
500 Server Internal Error6xx SIP Response Codes, Klasse 6: Global Failures
600 Busy Everywhere