SIP-Telefonie hinter NAT

Das Session Initiation Protocol (SIP) zählt neben Skype zu den populärsten Techniken, Voice-over-IP-Verbindungen aufzubauen. Durch seine offene Standardisierung (IETF RFC 3261 [1]) ist es zudem einfach, eigene Anwendungen für dieses Protokoll zu entwickeln.

SIP-Grundlagen

SIP ist nur für die Signalisierung, zum Beispiel beim Gesprächsauf- und -abbau zuständig. Den Transport der eigentlichen Sprachdaten übernimmt das ebenfalls offene Realtime Transfer Protocol (RTP), das RFC 3550 beschreibt [2].

Einen Grundlagenartikel zu SIP hat das Linux-Magazin in Ausgabe 08/2004 veröffentlicht [7].

Listing 1 zeigt den im SIP-RFC als Beispiel verwendeten SIP-»Invite«-Request, der ein VoIP-Telefonat einleitet und aus zwei Teilen besteht: Der erste Teil der Nachricht enthält die SIP-Header, im zweiten Teil - durch eine Leerzeile abgetrennt - folgt das Session Description Protocol (SDP) [3] als SIP-Payload. Dieser SDP-Teil beschreibt den Audio-Stream, enthält also Daten wie den Codec und den offenen Port (im »m«-Header) sowie die IP-Adresse oder den Namen des Hosts.

01 INVITE sip:bob@biloxi.com SIP/2.0
02 Via: SIP/2.0/UDP pc33.atlanta.com:5060;branch=z9hG4bKnashds8
03 Max-Forwards: 70
04 To: Bob <sip:bob@biloxi.com>
05 From: Alice <sip:alice@atlanta.com>;tag=1928301774
06 Call-ID: a84b4c76e66710
07 CSeq: 314159 INVITE
08 Contact: <sip:alice@pc33.atlanta.com:5060>
09 Content-Type: application/sdp
10 Content-Length: 142
11 
12   v=0
13   o=alice 53655765 2353687637 IN IP4pc33.atlanta.com
14   s=-
15   t=0 0
16   c=IN IP4 pc33.atlanta.com
17   m=audio 3456 RTP/AVP 0 1 3 99
18   a=rtpmap:0 PCMU/8000

Die erste Zeile der SIP-Nachricht definiert den Request und die zu kontaktierende URI (Uniform Resource Identifier, ähnlich einer Mailadresse). Der »Via«-Header speichert die einzelnen Hops, über welche die Pakete von Alice zu Bob laufen (Abbildung 1). Für jeden Hop entsteht ein zusätzlicher »Via«-Header. Diese Header machen es möglich, die Antwort über denselben Pfad zurückzusenden.

Abbildung 1: Wenn Alice mit dem »Contact«-Header in der Nachricht »200 OK« den SIP-Socket von Bob erhält, kann sie das ACK (8) direkt an Bob senden.

Der »To«-Header enthält die URI der kontaktierten Person, in der »From«-Zeile steht die öffentliche URI des Absenders.

»Call-ID« und »Cseq« sind eindeutige Identifier für den aktuellen Dialog. In »Contact« steht, unter welcher Adresse das Endgerät (User Agent, UA) derzeit auf SIP-Requests lauscht. Registriert der Anwender die URI »alice@atlanta.com« mehrfach auf verschiedenen Endgeräten, so enthält der »Contact«-Header die Daten des Endgeräts, das den Request abgesendet hat - im Beispiel »pc33.atlanta.com«. »Content-Type« und »Content-Length« definieren Typ und Größe des mitgesendeten Payloads. Abbildung 1 zeigt, wie zwei VoIP-Clients ein Gespräch über SIP initiieren: Die Botschaften laufen über mehrere Hops, und es sind mehrere Nachrichten notwendig.

Alice ruft Bob

Der Client mit der URI »alice@atlanta.com« möchte »bob@biloxi.com« anrufen. Er unterstützt mehrere Mediencodecs (erkennbar am SDP-Header »m= ? 0 1 3 99«) und hat einen für Medien offenen Socket »pc33.atlanta.com:3456«. Da Alice nicht weiß, an welchem Host Bob registriert ist, kontaktiert sie entweder zuerst den Proxy von Bob (wie in Abbildung 1, Schritt 1) oder sendet den SIP-Request zuerst an den eigenen Proxy.

Bobs Proxy stellt nun über seine Location-Datenbank den Standort von Bob fest und leitet den Request dorthin weiter (3). Eine alternative, aber unübliche Methode ist die direkte Kontaktaufnahme zwischen Alice und Bob ohne die Hilfe von Proxies. Die ist aber nur möglich, wenn Alice die aktuelle Location-Information von Bobs Client kennt.

Nachdem Alice den Request an den Proxy geschickt hat, erhält sie von ihm die Antwort »100 Trying« (2): Daran erkennt sie, dass der nächste Hop den Request erhalten hat. Trifft dieses »Trying« nicht ein, überträgt Alice erneut - unabhängig davon, ob sie die Message über UDP oder TCP verschickt hat. Hat Bob den Request empfangen, sendet er den Status »180 Ringing« (4), und sein Endgerät gibt ein Signal aus. Diese »Ringing«-Antwort läuft über die in den »Via«-Headern gesammelten Hops von Bob bis zu Alice zurück. Nimmt Bob den Anruf entgegen, sendet er »200 OK« (6). Das »OK« enthält anders als die früheren Antworten einen »Contact«-Header und einen SDP-Payload, der Alice die unterstützten Codecs und den für Medien offenen Socket mitteilt.

Erreicht das »OK« (7) Alice, sendet diese als Bestätigung eine »ACK«-Nachricht (8)direkt an die URI, die Bob im »Contact«-Header mitgesendet hat. Am »ACK« erkennt Bob, dass Alice sein »OK« erfolgreich empfangen hat. Nach diesem Drei-Wege-Handshake hat Alice nun den Medien-Socket von Bob, dieser hat den von Alice (durch den »Invite«-Request), und die Medienübertragung beginnt. Beendet Bob das Gespräch, sendet er einen »Bye«-Request (9) an die URI in Alices »Contact«-Header. Auch dabei lässt er die dazwischenliegenden Stationen aus.