SIP

1. Das Session Description Protocol (SDP)

    Aufgaben
    Aufbau
    Beispiel

2. Das Session Announcement Protocol (SAP)

    Erklärung

3. Das Session Initialization Protocol (SIP)

    Aufgaben
    Funktionsweise - Die Einladung
    Aufbau der SIP Nachrichten
    SIP Aufbau
    Headerfields

4. SIP Methoden

    SIP Methoden definiert durch SIP RFC
    SIP erweiterete Methoden definiert durch andere RFCs

5. SIP Cause Codes

    1xx Provisional
    2xx Success
    3xx Redirection
    4xx Client Error
    5xx Server Error
    6xx Global Failure

SDP - Session Description Protocol

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:

  • es stellt ein Mittel dar, mit dem die Existenz einer Sitzung bekannt gegeben wird
  • Es ermöglicht die Übermittlung relevanter Informationen an die (potentiellen) Teilnehmer einer Sitzung bekannt zu geben.


Die relevanten Informationen, die SDP übermittelt sind (u.a.):

  • Name und Zweck einer Sitzung
  • Zeitperiode, während der eine Sitzung abgehalten wird.
  • Das Medium, über das die Teilnahme ermöglicht wird (VIC, RAT.....MBone-Tools )
  • Informationen, wo das benötigte Medium zu erhalten ist (Adresse, Port, Format)
  • Informationen über die zu benutzende Bandbreite
  • Kontaktinformationen zu der für die Sitzung verantwortliche Person


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:

  • jeden Mittwoch um 10:00 Uhr für eine Stunde (für die zeitlich gebundene Variante)
  • eine Dauersendung in die man sich einklinken kann (zeitlich ungebunden)


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:

  • Sortierung resp. Verkündigung nach Interessensgebiet
  • Änderung des normalerweise verwendeten ISO 10646 Zeichensatzes in den ISO 8859-1 Zeichensatz.

SAP - Session Announcement Protocol

SAP dient dazu, Sitzungen auszurufen (bekanntmachen).
Dazu benutzt es folgende Features:

  • Periodischer Multicast-Rundruf an bekannte Adressen. (z.B.: 224.2.127.254/9875 (sap.mcast.net)
  • Gleicher Gültigkeitsbereich (TTL) wie die Sitzung selber.
  • Rückmeldung (Re-advertisement) hängt von drei Faktoren ab:

    • Der Gültigkeitsbereich (TTL) einer Sitzung
    • Anzahl der momentan ausgerufenen Sitzungen.
    • Die Größe des (eigenen) Datenpakets.

Für das Timeout gibt es zwei verschiedene Arten:

1. Expliziter Timeout:

  • Momentane Zeit ist zeitlich nach dem Ende der Sitzung
  • Es ist ein Sitzung-löschen -Paket eingetroffen

Dieses Paket muß folgende Informationen beinhalten:

>
  • Die Version der zu löschenden Sitzung
  • Die gleiche IP-Quell-Adresse der Sitzung

2. Impliziter Timeout:

  • Die SAP-Nachricht muß periodisch (von einem Multicast-Server) empfangen werden.
  • Die Zeitperiode kann vom Empfänger (Server) bestimmt werden.
  • Wenn die SAP-Pakete für 10 Perioden oder ½ Stunde nicht empfangen wurden wird die Sitzungsankündigung gelöscht.

Ä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.

SIP - Session Inititialization Protocol

Aufgaben von SIP

SIP lädt zu bevorstehenden Sitzungen ein. Es etabliert und kontrolliert Multimedia Sitzungen oder Aufrufe. Die Unterstützten Dienste sind:

  • Videokonferenzen
  • Internet-Telefonie
  • Unicast und
  • Multicast Sitzungen

SIP unterstützt alle fünf Mittel um Multicast Sitzungen zu eröffnen:

  • Ermittlung des Standorts des Empfängers
  • Ermittlung der Medien, die benutzt werden
  • Ermittlung der Bereitschaft des Empfängers
  • Etablierung der für den Aufruf benötigten Parameter
  • Sorgt für den Transfer und die Beendigung der Sitzung

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:

  • Media storage devices - um eine Sitzung aufzunehmen
  • Video-on-demand-Server, um Videos in eine (video)Konferenz einzuspielen.

  • SIP bietet keine Kontrolldienste für eine Sitzung an
  • SIP allokiert keine Multicast Adressen (dies wird dem SAP überlassen)
  • SIP reserviert keine Ressourcen, kann dem eingeladenen System aber die notwendigen Informationen liefern, um dies zu tun
  • SIP kann Benutzer zu einer Sitzung mit oder ohne Platzreservierung einladen

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:

  • Besteht aus User und Host-Teil
  • User ist ein Betriebssystem-Benutzername
  • Host ist entweder ein Domainname mit DNS-A Adresse oder eine Numerische (IP)

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.0
Via: SIP/2.0/UDP 239.128.16.254 16
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19
From: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. (Mark Handley)
Subject: SIP will be discussed, too
To: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. (Eve Schooler)
Call-ID: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
Content-type: application/sdp
CSeq: 4711
Content-Length: 187

v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e= Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0

Beispiel für den Server an den Client:

S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 239.128.16.254 16
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19 1
From: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
Call-ID: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
Location: sip:// Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
CSeq: 4711

SIP - Methoden

SIP 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

SIP - Cause Codes

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

100 Trying
180 Ringing
181 Call Is Being Forwarded
182 Queued
183 Session Progress


2xx SIP Response Codes: Klasse 2: Success

200 OK
202 accepted: Used for referrals

3xx SIP Response Codes, Klasse 3: Redirection

300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service

4xx SIP Response Codes, Klasse 4: Request Failures

400 Bad Request
401 Unauthorized: Used only by registrars. Proxys should use proxy authorization 407
402 Payment Required (Reserved for future use)
403 Forbidden
404 Not Found: User not found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout: Couldn't find the user in time
410 Gone: The user existed once, but is not available here any more.
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server
421 Extension Required
423 Interval Too Brief
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
491 Request Pending
493 Undecipherable: Could not decrypt S/MIME body part

5xx SIP Response Codes, Klasse 5: Server Failures

500 Server Internal Error
501 Not Implemented: The SIP request method is not implemented here
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported: The server does not support this version of the SIP protocol
513 Message Too Large

6xx SIP Response Codes, Klasse 6: Global Failures

600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable