Session Initiation Protocol

SIP (Session Initiation Protocol)
Familie:	Internetprotokollfamilie
Einsatzgebiet:	Verwaltung von Streaming-Sitzungen
Port:	5060 5061 (Verschlüsselung)
SIP im TCP/IP‑Protokollstapel: Anwendung SIP Transport UDP TCP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Token Ring FDDI …
Standards:	RFC 3261 (SIP, 2004)

Das Session Initiation Protocol (SIP) ist ein Netzprotokoll zum Aufbau, zur Steuerung und zum Abbau einer Kommunikationssitzung zwischen zwei und mehr Teilnehmern. Das Protokoll wird u. a. im RFC 3261 spezifiziert. In der IP-Telefonie ist das SIP ein häufig angewandtes Protokoll.

Funktionsweise

Im Gegensatz zu H.323, das von der ITU-T stammt, wurde SIP von der IETF entwickelt. H.323 kann stark vereinfacht als „ISDN über IP“ bezeichnet werden. Dies erlaubte zwar insbesondere den Telefonanlagenherstellern, vergleichsweise schnell und einfach die Kommunikation auf IP-Netzwerke umzustellen, andererseits wurden aber die Stärken und Schwächen von IP-Netzen nicht genügend berücksichtigt. Augenscheinlich wird dies insbesondere im Zusammenhang mit NAT, der vor allem bei Firewalls und Endkundennetzen (zum Beispiel DSL-Routern) notwendigen Übersetzung von Netzwerkadressen, welche bei H.323 nur mit viel Aufwand erreicht werden kann.

Das Design des SIP dagegen lehnt sich an das Hypertext Transfer Protocol an (ist zu diesem aber nicht kompatibel) und ist deutlich besser für IP-Netze geeignet. Der Aufbau von SIP erlaubt es, auf einfache Weise neue Erweiterungen einzufügen, ohne dass alle involvierten Geräte diese verstehen müssen. Auch ist es allgemeiner gehalten: Während H.323 nur für Telefonie gedacht ist, können mit SIP Sitzungen beliebiger Art verwaltet werden. Die „Nutzlast“ der Sitzung, also die eigentlichen zu übertragenden Datenströme, können vom Prinzip alle Ströme sein, die sich über ein Netzwerk übertragen lassen. Am verbreitetsten sind Audio- und Video-Übertragungen, aber beispielsweise auch einige Online-Spiele greifen auf SIP zurück, um die Übertragung zu verwalten.^[1]

Um ein Internet-Telefonat zu führen, braucht man mehr als nur SIP, denn es dient lediglich dazu, die Kommunikationsmodalitäten zu vereinbaren bzw. auszuhandeln – die eigentlichen Daten für die Kommunikation müssen über andere, dafür geeignete Protokolle ausgetauscht werden. Hierzu wird häufig in SIP das Session Description Protocol (SDP, RFC 4566, die Übersetzung aus dem Englischen „Sitzungs-Beschreibungs-Protokoll“ ist nicht gebräuchlich) eingebettet, um die Details der Video- und/oder Audio-Übertragung auszuhandeln. Dabei teilen sich die Geräte gegenseitig mit, welche Methoden der Video- und Audio-Übertragung sie beherrschen (die sogenannten Codecs), mit welchem Protokoll sie das tun möchten und an welcher Netzadresse sie senden und empfangen wollen.

Diese Medien-Aushandlung ist also kein direkter Bestandteil von SIP, sondern wird dadurch erreicht, dass in SIP ein weiteres Protokoll mit eingebettet wird. Diese Trennung von Sitzungs- und Medienaushandlung ist einer der Vorteile von SIP, da sie eine große Flexibilität bei der unterstützten Nutzlast erlaubt: Möchte zum Beispiel ein Hersteller SIP für eine spezialisierte Anwendung verwenden, so kann er dafür eine eigene Medienaushandlung entwerfen, falls dafür noch kein Protokoll existiert.

Bei der Internet-Telefonie findet für die Medienübertragung das Realtime Transport Protocol (RTP, deutsch Echtzeit-Transportprotokoll, RFC 3550) Verwendung. SIP handelt hier die Sitzung aus, das eingebettete SDP handelt die Medien-Details aus, und RTP ist dann dasjenige Protokoll, welches letztendlich die Video- und Audio-Ströme überträgt. Um die Ströme verschlüsselt übertragen zu können, steht als Alternative auch SRTP zur Verfügung.

Teilnehmer-Adressen werden im URI-Format geschrieben, welches auch in E-Mails und WWW-Adressen Verwendung findet. Solch eine Teilnehmer-Adresse folgt meist einem folgender drei Schemata:

• Unverschlüsselte SIP-Verbindung: sip:user@domain.
• Verschlüsselte SIP-Verbindung: sips:user@domain.
• Telefonnummer: tel:nummer, zum Beispiel tel:[phone]. Dieses Schema wird vor allem von Geräten verwendet, die eine Schnittstelle in das „normale“ Telefonnetz bereitstellen und kann bei Bedarf in eine SIP-URI gewandelt werden, beispielsweise sip:[phone]@domain.

Zu beachten ist, dass durch die Trennung von Sitzung und Medien diese auch getrennt verschlüsselt werden können. Man kann SIP unverschlüsselt oder verschlüsselt übertragen (über das TLS-Protokoll) und davon unabhängig auch die Medien (also zum Beispiel das Telefongespräch) ebenfalls jeweils unverschlüsselt oder verschlüsselt. Jede Kombination davon ist möglich.

Unterstützung findet SIP bereits in vielen Geräten diverser Hersteller und es scheint sich zum Standard-Protokoll für Voice over IP (VoIP) zu entwickeln. SIP wurde auch vom 3rd Generation Partnership Project (3GPP) als Protokoll für Multimediaunterstützung im 3G-Mobilfunk (UMTS) ausgewählt. Auch die Spezifizierung des Next Generation Network (NGN) beim European Telecommunications Standards Institute (ETSI) der Projektgruppe Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) stützt sich auf SIP.

Vor- und Nachteile

Zu den Vorteilen von SIP gehört, dass es sich hierbei um einen offenen Standard handelt, der mittlerweile sehr weite Verbreitung gefunden hat. Da SIP-Server verteilt sind, betrifft ein Angriff nur den jeweiligen Anbieter und nicht die gesamte über SIP vermittelte Telefonie. Ein weiterer Vorteil von SIP ist die Möglichkeit, eine bereits etablierte Sitzung modifizieren zu können. Dazu wird einfach innerhalb der Sitzung eine weitere INVITE-Message mit den neuen SDP-Sitzungseigenschaften an die Gegenseite gesendet. Somit kann ein neues Medium hinzugefügt oder ein bestehendes Medium modifiziert bzw. entfernt werden. Die entsprechende Nachricht wird auch als Re-INVITE Request bezeichnet.

Ein Nachteil von SIP ist, dass es zur Übertragung der Sprachdaten auf RTP zurückgreift. Die dafür verwendeten UDP-Ports werden dynamisch vergeben, was die Verwendung von SIP in Verbindung mit Firewalls oder Network Address Translation (NAT, RFC 2663) schwierig macht, da die meisten Firewalls bzw. NAT-Router die dynamisch vergebenen Ports nicht der Signalisierungsverbindung zuordnen können. Abhilfe für dieses Problem schafft der Einsatz von STUN (Session Traversal Utilities for NAT), welches NAT-Router erkennt und durchdringt, aber auch andere Protokolle wie IAX (InterAsterisk eXchange). Durch den Einsatz des STUN-Protokolls wird die IP-Adresse und der Port ermittelt, mit dem die NAT-Firewall bzw. der NAT-Router nach außen (d.h. in das öffentliche Internet) geht. Eine deutlich einfachere Methode dieses Problem zu umgehen ist, dass der Proxyserver bzw. der gerufene Teilnehmer direkt auf die IP-Adresse und den verwendeten Port im IP-Header zurückgreift, wodurch der NAT-Mechanismus auch ohne STUN-Server wieder greift. IAX kombiniert Signalisierung und Mediendaten auf einer UDP-Verbindung. Wie H.323 ist IAX ein binäres Protokoll, weshalb die Fehlerbehebung schwieriger als bei SIP ist. Zudem befindet sich IAX erst in der Standardisierungsphase.

Ein neueres Verfahren der IETF zur Lösung des NAT-Traversal-Problems stellt Interactive Connectivity Establishment (ICE) dar, welches schon von einigen SIP-Clients unterstützt wird und meist per Firmware-Upgrade installiert werden kann.

Eine weitere Lösung für das NAT-Traversal-Problem stellen sogenannte Application Layer Gateways (ALG) dar. Diese sind zwischengeschaltete SIP-Proxys, die – auf einem NAT-Router bzw. einer Firewall installiert – für reibungslosen Transfer der SIP-Signalisierung und -Medienströme sorgen. Ein ALG kann bei SIP-Telefonaten automatisch für die Öffnung der notwendigen Ports auf einer Firewall sorgen sowie RTP-Medienströme mit DiffServ-Bits markieren. Dadurch können die Medien-Pakete mit höherer Priorität über IP-Netze transportiert werden, wenn ein Netz dieses unterstützt. Das Internet bietet grundsätzlich keine Priorisierung, s. Netzneutralität

Beispiele

So könnte ein SIP-Request aussehen:		Und so eine SIP-Response:
Startzeile INVITE sip:8495302002@192.168.2.25 SIP/2.0 Header Via: SIP/2.0/UDP 192.168.3.250:5060; branch=1 From: sip:8495305005@192.168.2.25;tag=29ae1249 Max-Forwards: 70 To: sip:8495302002@192.168.2.25 Call-ID: 48c7df2a9b4@myvoip1 Cseq: 1 INVITE Contact: sip:8495305005@192.168.3.250 Content-Length: 202 Supported: 100rel Content-Type: application/sdp Leerzeile Body v=0 o=Anonymous 1234567890 1234567890 IN IP4 192.168.3.250 s=SIGMA is the best c=IN IP4 192.168.3.250 t=0 0 m=audio 6006 RTP/AVP 8 3 0 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000		Startzeile SIP/2.0 200 OK Header Via: SIP/2.0/UDP 192.168.2.25:5060;branch=z5K8DSbCGCL8593033654 From: sip:8495305005@192.168.2.25;tag=6248550609-457625817474016 To: <sip:8495302002@192.168.3.251;user=phone>;tag=2e679cbc Call-ID: 6248550609-781762546450147 Cseq: 15 INVITE Contact: sip:8495302002@192.168.3.251 Content-Length: 191 Content-Type: application/sdp Leerzeile Body v=0 o=Anonymous 1234567890 7894561230 IN IP4 192.168.3.251 s=SIGMA is the best c=IN IP4 192.168.3.251 t=0 0 m=audio 6006 RTP/AVP 8 0 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000

Siehe auch

• IP-Telefonie
• SIP-Status-Codes
• SIP-Telefon
• Telephone Number Mapping (ENUM)
• IP Multimedia Subsystem

Weblinks

• SIP Core Working Group
• RFC 2543 – SIP (veraltete Version)
• RFC 3261 – SIP
• RFC 3265 – SIP Erweiterung: Specific Event Notification
• RFC 3515 – SIP Update: SIP Refer Method
• RFC 3853 – SIP Update: Benutzung von AES statt 3DES
• RFC 4320 – SIP Update: Issues with the SIP Non-INVITE Transaction
• RFC 4916 – Connected Identity in the Session Initiation Protocol
• RFC 3665 – SIP Basic Call Flow Examples
• SIP Protocol Overview
• SIP/IMS Technical Portal
• RADVISION – SIP: Protocol Overview (PDF, 112 KiB)

Einzelnachweise

1. ↑ Using Session Initiation Protocol to build Context-Aware VoIP Support for Multiplayer Networked Games von Aameek Singh und Arup Acharya