Session Initiation Protocol

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
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[Bearbeiten]

Im Gegensatz zu H.323, das von der ITU-T stammt, wurde SIP von der IETF entwickelt. H.323 kann stark vereinfacht als ISDN over 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 alle Ströme sein, die sich über ein Netzwerk übertragen lassen. Das Haupteinsatzgebiet findet sich in der Audio- und Video-Übertragung, einige Online-Spiele greifen zur Verwaltung der Übertragung ebenfalls auf SIP zurück.[1]

SIP signaling.svg

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 EnglischenSitzungs-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 durch die Einbettung eines weiteren Protokolls in SIP erreicht. 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.

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:

Verschlüsselung und Sicherheit[Bearbeiten]

Durch die Trennung von Sitzung und Medien können beide Datenströme auch unabhängig voneinander verschlüsselt werden. Man kann SIP über das TLS-Protokoll, auch SIPS genannt, verschlüsseln und den Medienstrom (Sprachdaten) ebenfalls über das SRTP-Protokoll. Jede Kombination davon ist möglich, allerdings in Hinsicht auf eine sichere Verschlüsselung nicht sinnvoll.

Zwecks einer sicheren Verschlüsselung müssen beide Datenströme (also Sitzung und Medien) gleichzeitig verschlüsselt werden. Die symmetrischen Schlüssel des Medienstroms werden über SDP (also SIP) ausgetauscht und wären damit über ein unverschlüsseltes SIP angreifbar. Die symmetrischen Schlüssel von TLS werden zwar am Anfang der Sitzung auch ausgetauscht, jedoch greifen hier die Mechanismen der SSL-Zertifikate, bei denen die symmetrischen Schlüssel durch die asymmetrischen Schlüssel der SSL-Zertifikate wiederum verschlüsselt sind.

Netzwerk-Elemente[Bearbeiten]

  • User Agent
Der User Agent ist eine Schnittstelle zum Benutzer, die Inhalte darstellt und Befehle entgegennimmt. Auch ein SIP-Telefon ist ein SIP User Agent, der die traditionellen Ruffunktionen eines Telefons, wie Zifferblatt, Annehmen, Abweisen und Halten bietet.
  • Proxy Server
Ein Proxy Server ist eine Kommunikationsschnittstelle in einem Netzwerk. Er arbeitet als Vermittler (Routing) der auf der einen Seite Anfragen entgegennimmt, um dann über seine eigene Adresse eine Verbindung zu einer anderen Seite herstellt. Es ist seine Aufgabe sicherzustellen, dass Anfragen gezielt an den Benutzer gesendet werden. Proxys sind auch für die Durchsetzung der Hierarchie nötig.
  • Registrar Server
Der Registrar Server dient als zentrale Schaltstelle in der Systemarchitektur von SIP. Er übernimmt das Registrieren von Anfragen für die Domain, die er verarbeitet. Er bearbeitet ein oder mehrere IP-Adressen zu einer bestimmten SIP-URI, die durch das SIP Protokoll übermittelt werden.
  • Redirect Server
Der Redirect Server entlastet den Proxy Server. Er übergibt die Routing-Informationen direkt an den User Agent Client. Er erzeugt Weiterleitungen, um eingehende Anträge in einer alternativen Gruppe von URIs kontaktieren zu können. Der Redirect Server ermöglicht es SIP-Session Einladungen an externe Domänen zu übermitteln.
  • Session Border Controller
Ein Session Border Controller ist eine Netzwerkkomponente zur sicheren Kopplung von Rechnernetzen mit unterschiedlichen Sicherheitsanforderungen. Er dient als mittlerer Knoten zwischen User Agent und SIP-Server für verschiedene Arten von Funktionen, einschließlich der Unterstützung der Network Address Translation (NAT)
  • Gateway
Ein Gateway kann ein SIP-Netz mit anderen Netzen, wie beispielsweise dem öffentlichen Fernsprechnetz, das unterschiedliche Protokolle oder Technologien verwendet, als Schnittstelle verbinden.[2]

Verbreitung[Bearbeiten]

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[Bearbeiten]

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 werden 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[Bearbeiten]

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[Bearbeiten]

Spezifikationen[Bearbeiten]

  • RFC 2543 – SIP (veraltete Version)
  • RFC 3261 – SIP
  • RFC 3265 – SIP Erweiterung: Specific Event Notification
  • RFC 3515 – SIP Update: SIP Refer Method
  • RFC 3665 – SIP Basic Call Flow Examples
  • RFC 3851 – SIP Update: Symmetric Response Routing
  • 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

Weblinks[Bearbeiten]

Literatur[Bearbeiten]

Ulrich Trick, Frank Weber: SIP, TCP/IP und Telekommunikationsnetze. Next Generation Networks und VoIP - konkret, Oldenbourg Wissenschaftsverlag, 2007, ISBN 9783486582284

Einzelnachweise[Bearbeiten]

  1. Using Session Initiation Protocol to build Context-Aware VoIP Support for Multiplayer Networked Games (PDF; 283 kB) von Aameek Singh und Arup Acharya
  2. SIP-Session Initiation Protocol-Aufbau - abgerufen am 14. November 2013