Session Initiation Protocol

Das Sitzungs-Initiierungs-Protokoll (SIP), auch Einleitungs-Protokoll (engl. Session Initiation Protocol), 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^[1] spezifiziert. In der IP-Telefonie ist das SIP ein häufig angewandtes Protokoll.

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.^[2]

Um ein Internet-Telefonat zu führen, braucht man mehr als nur SIP, denn es dient lediglich dazu, die Bedingungen für die Verbindung 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,^[3] 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 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 wird für die Medienübertragung das Real-Time Transport Protocol (RTP, deutsch Echtzeit-Transportprotokoll, RFC 3550^[4]) verwendet. 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 der folgenden drei Schemata:

• Unverschlüsselte SIP-Verbindung: sip:user@domain.
• Verschlüsselte SIP-Verbindung: sips:user@domain.
• Telefonnummer: tel:nummer, zum Beispiel tel:+49-69-1234567. 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:+49-69-1234567@domain.

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. 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 TLS-Zertifikate, bei denen die symmetrischen Schlüssel durch die asymmetrischen Schlüssel der TLS-Zertifikate wiederum verschlüsselt sind.

Da bei SIP eine Übertragung über ein verbindungsloses Netzwerkprotokoll sinnvoller ist, wurde mit DTLS ein auf UDP basierendes Pendant zu TLS, welches auf TCP aufbaut, entworfen. Allerdings wird es gegenwärtig nur von einem SIP Stack (ReSIProcate) implementiert.

• 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 Zifferneingabe, 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 herzustellen. 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 eine 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.

• B2BUA

B2BUA - (auf Englisch Back-to-Back-User-Agent, wörtlich: der User-Agent "Rücken an Rücken") ist eine Middleware sowohl im SIP- als auch im RTP-Datenstrom. Gegenüber SIP-Clients verhält sich ein B2BUA wie ein User-Agent-Server auf der einen Seite der Verbindung und wie ein User-Agent-Client auf der anderen. Sinn ist es, die Datenströme manipulieren zu können.

Der B2BUA wird im RFC 3261^[1] spezifiziert.

Beispiele für die Anwendung:

• Gesprächsmanagement (u. a. Abrechnung, Anrufweiterleitung, automatische Abschaltung)
• Paarung unterschiedlicher Netzwerke (insbesondere die verschiedenen Dialekte der Protokolle anzupassen, je nach Hersteller)
• Ausblenden der Netzwerkstruktur (u. a. private Adressen, Netzwerktopologie)

Grundsätzlich lässt sich ein B2BUA zu einem Proxy mit integriertem Mediagateway ausbauen.

Die an einer SIP-Session beteiligten Clients und Server senden sich Anfragen (englisch „requests“) und beantworten diese mittels Antwort-Codes (englisch „responses“).

RFC 3261^[1] definiert sechs Anfragen: REGISTER, INVITE, ACK, CANCEL, BYE und OPTIONS.

1xx – Provisional

Vorläufige Statusinformationen, dass der Server weitere Aktionen durchführt und deshalb noch keine endgültige Antwort senden kann.

2xx – Successful

Die Anfrage war erfolgreich.

3xx – Redirection

Diese Nachrichten informieren über eine neue Kontaktadresse des Angerufenen oder über andere Dienste, die es ermöglichen die Verbindung erfolgreich aufzubauen.

4xx – Request Failures

Die vorangegangene Nachricht konnte nicht bearbeitet werden.

5xx – Server Failures

Ein an der Übermittlung beteiligter Server konnte eine Nachricht nicht bearbeiten.

6xx – Global Failures

Der Server wurde zwar erfolgreich kontaktiert, jedoch kommt die Transaktion nicht zustande.

Unterstützung findet SIP bereits in vielen Geräten diverser Hersteller und 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.

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^[5]) 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 Technik zum NAT-Traversal 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 sollen. 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, wodurch die Medien-Pakete mit höherer Priorität über IP-Netze transportiert werden können, wenn ein Netz dieses unterstützt. Das Internet bietet grundsätzlich keine Priorisierung, siehe Netzneutralität. In der Praxis werden die Pakete jedoch meist an eine nicht dafür vorgesehene IP-Adresse geliefert (an den Server resp. Proxy anstatt an das dafür vorgesehene Endgerät), weshalb in vielen Konfigurationen und als Vorgabe von vielen VoIP-Anbietern SIP-ALG abzuschalten ist, um überhaupt Verbindungen herstellen zu können.

Bei der Nutzung von IPv6 als Transportprotokoll entfällt in der Regel NAT und damit auch die Notwendigkeit die NAT-typischen Probleme zu umschiffen. Lediglich die Problematik der Firewall bleibt identisch.

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

• RFC2543 – SIP. (veraltete Version, englisch).
• RFC3261 – SIP: Session Initiation Protocol. Juni 2002 (aktuell, englisch).
• RFC3265 – Session Initiation Protocol (SIP) – Specific Event Notification. Juni 2002 (Erweiterung, englisch).
• RFC3515 – SIP Update: SIP Refer Method. (englisch).
• RFC3665 – SIP Basic Call Flow Examples. (englisch).
• RFC3581 – SIP Update: Symmetric Response Routing. (englisch).
• RFC3853 – SIP Update: Benutzung von AES statt 3DES. (englisch).
• RFC4320 – SIP Update: Issues with the SIP Non-INVITE Transaction. (englisch).
• RFC4916 – Connected Identity in the Session Initiation Protocol. (englisch).

• Ulrich Trick, Frank Weber: SIP und Telekommunikationsnetze. Next Generation Networks und Multimedia over IP - konkret. De Gruyter Oldenbourg, 2015, ISBN 978-3-486-77853-3.

• SIP Core Working Group. ietf.org
• SIP/IMS Technical Portal. tech-invite.com

1. ↑ ^{a b c d} RFC3261 – SIP: Session Initiation Protocol. Juni 2002 (englisch).
2. ↑ Aameek Singh, Arup Acharya: Using Session Initiation Protocol to build Context-Aware VoIP Support for Multiplayer Networked Games. (PDF; 277 kB) conferences.sigcomm.org
3. ↑ RFC4566 – SDP: Session Description Protocol. Juli 2006 (englisch).
4. ↑ RFC3550 – RTP: A Transport Protocol for Real-Time Applications. Juli 2003 (englisch).
5. ↑ RFC2663 – IP Network Address Translator (NAT) Terminology and Considerations. August 1999 (englisch).