SIP – Teil I: Grundlagen
von Olga Lyssenko und Georg Friedrich
Bereits seit einiger Zeit erfreuen sich Voice-over-IP-Anwendungen (VoIP) großer Beliebtheit. Entsprechend groß ist die Zahl der vorhandenen VoIP-Anwendungen, wie z. B. ICQ, AOL Instant Messenger, Windows Live Messenger, Yahoo! Messenger, Skype, Google Talk oder kPhone.
Manche dieser VoIP-Anwendungen verwenden proprietäre Protokolle für das VoIP-Session-Handling, andere hingegen nutzen die standardisierte Protokoll-Suite H.323. Immer häufiger zur Anwendung kommt jedoch das ebenfalls standardisierte Protokoll SIP. Dies nehmen wir zum Anlass, das SIP-Protokoll im Rahmen einer SWITCH!-Reihe dem Leser etwas näherzubringen.
Allgemeines zu SIP
Das von der IETF in der RFC 3261 bis RFC 3265 definierte Session Initiation Protocol (SIP) ist ein Signalisierungs- und Vermittlungsprotokoll für Voice over IP und generell für Multimedia-Anwendungen über IP vorgesehen. Mit SIP können sowohl Punkt-zu-Punkt-Verbindungen als auch Konferenzen mit drei oder mehr Teilnehmern aufgebaut, modifiziert und wieder beendet werden.
Neben der Session-Vermittlung unterstützt SIP viele weitere Kommunikationsmechanismen, wie z. B. das session-unabhängige Instant Messaging sowie die Zustandsabfrage eines Teilnehmers (Presence-Funktionalität).
SIP ist ein auf HTTP basierendes, textorientiertes Protokoll, das nach dem Client-Server-Prinzip arbeitet. Die Teilnehmer einer SIP-Session werden auch als User Agents (UA) bezeichnet, genauer noch als User Agent Client (UAC) und User Agent Server (UAS).
SIP ist einfacher aufgebaut als das von der ITU stammende H.323 und deshalb auch leichter zu implementieren. Die SIP-Informationen können sowohl über TCP als auch über UDP transportiert werden.
SDP, RTP und RTCP
Neben SIP kommen weitere Protokolle während der Kommunikation zwischen den Session-Teilnehmern zum Einsatz, so zum Beispiel das Session Description Protocol (SDP) nach RFC 2327 sowie das Realtime Transport Protocol (RTP) und das dazugehörige Steuerprotokoll RTCP, beide gemäß RFC 3550.
SDP wird für die Aushandlung der während einer Session übermittelten Medien (Video, Sprache, Text ...) und der verwendeten Codecs benutzt. Die Codec-Aushandlung zwischen zwei User Agents erfolgt dabei nach dem Offer-Answer-Modell nach RFC 3264, in dem der UAC dem die vom UAC unterstützten Codecs offeriert, die der UAS dann mit einer entsprechenden Answer ganz oder teilweise akzeptiert, abhängig davon, welche Codecs der UAS unterstützt.
Mit Hilfe von RTP werden nach erfolgreichem SIP-Session-Aufbau die eigentlichen Multimedia-Daten (Sprache ...) transportiert.
Bild 1 veranschaulicht das Zusammenspiel der einzelnen Protokolle für Voice over IP.
SIP-Messages
Bei SIP werden zwei Arten von Kommunikationselementen (Nachrichten) unterschieden: Requests und Responses. Ein Request formuliert eine geforderte Aktion, während die Response die Reaktion auf den Request oder die Quittierung des Request-Empfangs darstellt. Im Allgemeinen sendet ein Client (UAC) einen Re-quest, der vom Server mit einer Response beantwortet wird.
Requests
Die wichtigsten SIP-Requests nach RFC 3261 sind:
INVITE: Mit Hilfe des INVITE-Requests wird der Aufbau einer SIP-Session initiiert. Am Beispiel von VoIP ist dies der Wunsch des Aufbaus einer Sprachverbindung durch ein IP-Telefon. Eine INVITE-Nachricht enthält bereits einige Verbindungsparameter, wie z. B. die SIP-Adressen der Session-Teilnehmer und den mittels des Unterprotokolls SDP übermittelten gewünschten Codec zur Medienübertragung.
BYE: Mit BYE wird eine bestehende SIP-Session von einem der Teilnehmer abgebaut.
ACK: ACK dient als positive Bestätigung des Empfangs einer SIP-Response im Rahmen des sogenannten SIP-Dreiwege-Handshakes (INVITE -> Response -> ACK).
OPTIONS: Mit OPTIONS kann ein User Agent nach dessen Eigenschaften befragt werden, z. B. unterstützte Medien (Audio, Video ...) und Codecs. Mögliche Sprach-Codecs sind etwa PCMU, PCMA, GSM und G723.
CANCEL: Hiermit kann der Aufbau einer SIP-Session abgebrochen werden.
REGISTER: Mittels eines REGISTER-Re-quests registriert sich ein Session-Teilnehmer bei einem sogenannten SIP-Registrar und teilt ihm seine SIP-Adresse mit.
Darüber hinaus gibt es noch zusätzliche, in weiteren RFCs definierte SIP-Requests:
SUBSCRIBE: Hiermit kann ein SIP-Teilnehmer die Überwachung eines anderen SIP-Teilnehmers hinsichtlich des Eintretens eines bestimmten Ereignisses oder Zustandes (eines sogenannten Events) einleiten. Ein möglicher Zustand könnte der Online-Zustand eines Teilnehmers sein (Presence-Funktion).
NOTIFY: Die mit SUBSCRIBE eingeleitete Ereignisüberwachung kann mit NOTIFY-Requests beantwortet werden. Auf diese Weise kann der überwachte Teilnehmer Zustandsänderungen (z. B. Änderungen der Presence) anzeigen.
PUBLISH: Der PUBLISH-Request ermöglicht die aktive, d. h. unaufgeforderte Übermittlung von Zustands- oder Ereignisinformationen durch einen SIP-Teilnehmer.
UPDATE: Ein UPDATE ermöglicht die Veränderung bestimmter Session-Parameter noch während des SIP-Session-Aufbaus.
INFO: INFO ermöglicht den Austausch zusätzlicher Steuer- und Kontrollinformationen während einer Session zwischen den Session-Teilnehmern.
Responses
SIP-Responses (auch Statusinformationen genannt) dienen zur Quittierung und inhaltlichen Beantwortung von SIP-Requests. Im Gegensatz zu Requests tragen Statusinformationen keine eigenen Namen, sondern werden ähnlich dem HTTP-Protokoll durch dreistellige Nummern, den sogenannten Statuscode, gekennzeichnet.
Die SIP-RFC unterscheidet sechs Response-Klassen:
1xx – Informational: teilt dem Sender eines Requests mit, dass der Request weiterverarbeitet wird, z. B. 100 Trying oder 180 Ringing.
2xx – Success: Es gibt nur eine Response dieser Klasse: 200 OK. Sie teilt dem Initiator eines Requests den korrekten Empfang und das Akzeptieren des Requests seitens des Servers mit.
3xx – Redirection: Hiermit wird dem Absender eines Requests signalisiert, dass der Request nicht vollständig bearbeitet werden konnte und dass weitere Aktionen notwendig sind. Ursache kann eine geänderte SIP-Adresse eines SIP-Teilnehmers sein, z. B. 301 Moved Permanently oder 302 Moved Temporarily.
4xx – Client error: Der Request kann vom Server nicht bearbeitet werden. Ursache können falsche Syntax oder unvollständiger Inhalt des Requests sein. Beispiele für diese Response-Klasse sind 400 Bad Request, 401 Unauthorized, 403 Forbidden oder 408 Request Timeout.
5xx – Server error: Hiermit wird dem Absender eines Requests angezeigt, dass der Request aus serverbedingten Gründen nicht verarbeitet werden kann, z. B. 500 Server Internal Error.
6xx – Global failure: Kein Server kann den Request bearbeiten. Hiermit kann z. B. signalisiert werden, dass ein gerufener Teilnehmer einen Session-Aufbau zurzeit nicht akzeptiert: 600 Busy Everywhere.
Mit Ausnahme der Response-Klasse 1xx beantworten alle anderen Klassen einen eingehenden Request final.
Aufbau der SIP-Messages
SIP-Messages (Request oder Response) sind textbasiert und zeilenweise aufgebaut. Alle Nachrichten setzen sich zusammen aus einer Startzeile, gefolgt von einem ein- oder mehrzeiligen Message-Header und einem optionalen und durch eine Leerzeile abgetrennten Message-Body.
Bild 2 zeigt den prinzipiellen Aufbau eines SIP-Requests.
Der prinzipielle Aufbau einer SIP-
Response ist ähnlich dem eines SIP-Requests (Bild 3).
Startzeile
Die Startzeile (Request-Line) eines SIP-Requests setzt sich aus den drei folgenden, durch Leerzeichen getrennten Elementen zusammen:
Method: spezifiziert den Request-Typ, also z. B. INVITE oder ACK.
Request-URI: die Ziel-Adresse (URI = Uniform Resource Identifier) des Teilnehmers, für den der Request gilt.
SIP-Version: verwendete SIP-Version.
Für einen INVITE-Request kann eine Startzeile wie folgt aussehen:
INVITE sip:bob@domainB.de SIP/2.0
Die Startzeile (Status-Line) einer SIP-
Response enthält u. a. den dreistelligen Statuscode, gefolgt von der Reason-
Phrase. Beispiel:
SIP/2.0 180 RINGING
Header und Body
Der Aufbau des der Startzeile folgenden Message-Headers und -Bodys soll an einem kompletten INVITE-Request erläutert werden (Bild 4):
Message-Header
Via: Das Via-Feld im Header eines SIP-Requests enthält neben dem verwendeten Transportprotokoll (hier UDP) die IP-Adresse oder den DNS-Namen der Adresse des User Agent Clients, der den Request versendet.
From: Diese Header-Zeile enthält den Display-Namen (Alice) des UAC und dessen SIP-URI. Der UAS fügt diese From-Zeile wieder unverändert in seine Response-Nachrichten an den UAC ein. Der der SIP-URI folgende, zufällige Tag-Wert dient als Dialog-Identifier.
To: Die To-Zeile enthält den Display-Namen (Bob) und die SIP-URI des UAS, an den der SIP-Request gesendet wird. Auch die To-Zeile wird vom UAS unverändert in seine an den UAC gesendeten Responses eingefügt.
Call-ID: Die Call-ID besteht aus einem Zufallswert, der vom die SIP-Session initiierenden Teilnehmer vorgegeben wird. Optional kann dessen IP-Adresse oder Hostname folgen. Die Call-ID dient ebenso wie der tag-Wert der From-Zeile als Dialog-Identifier.
CSeq: Die Command Sequence dient der Nummerierung eines Request-Typs eines UAC. Im Beispiel sendet der UAC den ers-ten INVITE-Request innerhalb einer Session. Eine Response auf diesen Request enthält die gleiche CSeq-Zeile.
Max-Forwards: die maximale Anzahl Proxy-Server, die die SIP-Nachricht zwischen den beiden an der SIP-Session beteiligten Endsystemen durchlaufen darf.
Jeder Proxy-Server, der die Nachricht weiterleitet, dekrementiert diesen Zähler um 1. Ist der Zähler 0, wird die eingehende Nachricht vom Proxy verworfen.
Contact: Dies ist die direkte Kontakt-adresse des die Nachricht aussendenden SIP-Teilnehmers. Mit dieser Adresse kann ein anderer Teilnehmer den Nachrichten-initiator direkt, also ohne Umwege über Proxys, kontaktieren.
Content-Type: Hiermit wird der Datentyp der im Body befindlichen Daten dokumentiert. Im Beispiel sind dies Daten des SDP-Protokolls für eine Anwendung.
Content-Length: Die Content-Length gibt die Länge des Message-Bodys in Byte an. Ein fehlender Body wird mit der Länge 0 angezeigt.
Message-Body
Der im INVITE-Request enthaltene Message-Body dient zur Medienaushandlung gemäß dem SDP-Protokoll. Die Mediendaten werden durch Parameter mittels einer einfachen Syntax spezifiziert (<Parametertyp>=<Wert>), wobei der Parametertyp stets ein Kleinbuchstabe ist.
Der Message-Body setzt sich zusammen aus der die RTP-Session spezifizierenden v-, o-, s- und c-Zeile, der Zeitbeschreibung (t-Zeile) und den das Medium beschreibenden m- und a-Zeilen.
m-Zeile: Mit der m-Zeile (media name and transport address) spezifiziert der UAC ein von ihm unterstütztes Medium näher. Neben dem Medientyp (z. B. Audio) wird hier der Empfangsport für das Medium benannt. Darüber hinaus erfolgt hier die Angabe des Transport-Protokolls (hier RTP/AVP, Realtime Transport Protocol/Audio Video Profile nach RFC 3551) und die Liste der unterstützten Codecs.
a-Zeile: Die Einträge der Codec-Liste werden schließlich durch je eine a-Zeile (attribute line) näher beschrieben.
Einfacher SIP-Verlauf
An einem einfachen Beispiel soll nun der SIP-Rufablauf für Voice over IP veranschaulicht werden. Gegeben seien zwei in unterschiedlichen Domains domainA und domainB befindliche VoIP-Teilnehmer Alice und Bob, die beide mit dem Proxy-Server ihrer Domain in Kontakt stehen. Beide Teilnehmer seien zudem innerhalb ihrer Domain bei ihrem sogenannten Registrar (oder auch Location-Server) mittels SIP-REGISTER zuvor angemeldet und damit bekannt. Das obige Bild 6 zeigt den möglichen Rufablauf. Dabei stellen durchgezogene Linien SIP-Requests und gestrichelte Linien SIP-Responses dar.
Zunächst wählt Alice aus dem Adressbuch ihrer VoIP-Applikation auf ihrem PC Bobs Adresse aus und startet damit den VoIP-Call. Die SIP-Session beginnt mit einem SIP-INVITE, das von Alice‘ VoIP-Applikation ausgesandt wird. Da Bobs momentaner Aufenthaltsort nicht bekannt ist, wird der INVITE-Request zum Proxy A innerhalb Alice’ Domain gesandt. Der INVITE enthält u. a. Bobs SIP-Adresse, sip:bob@domainB, Alice‘ SIP-Adresse, alice@domainA und die gewünschte und mittels SDP-Protokoll angegebene Medienform (z. B. Sprache) sowie deren Codec.
Der Proxy-Server A sendet seinerseits die INVITE-Nachricht an den betreffenden Proxy-Server B der Domain domainB, wobei der dem Request seine eigene SIP-Adresse im sogenannten VIA-Header-Feld beifügt. Zusätzlich sendet er Alice’ Softphone eine 100-TRYING-Response und deutet damit an, dass der eingehende INVITE-Request verarbeitet wird.
Der Proxy-Server B sendet nach Empfang des INVITE von Proxy A ein 100 TRYING an Proxy A zurück und signalisiert diesem damit, dass der INVITE verarbeitet wird. Proxy B ermittelt daraufhin mit einer Anfrage beim Registrar der Domain domainB Bobs aktuelle SIP-Adresse, die als neue Ziel-Adresse in den INVITE-Request eingefügt wird. Zusätzlich fügt Proxy B seine eigene SIP-Adresse in ein VIA-Header-Feld ein und sendet danach den INVITE-Request an Bobs Softphone.
Bobs VoIP-Applikation empfängt den INVITE. Falls der INVITE verarbeitet werden kann (z. B. unterstützte Medienform und Codec), klingelt Bobs Telefon und zeigt damit Alices‘ Anruf an. Das Klingeln auf Bobs Seite wird durch eine Nachricht 180 RINGING signalisiert, die über die Proxy B und A Alice’ VoIP-Applikation erreichen. Da jeder Proxy beim Weiterleiten der INVITE-Nachricht seine eigene SIP-Adresse in einem VIA-Header-Feld eingefügt hat, ist der Rückweg für Bobs SIP-Response genau festgelegt. Nachdem Bobs RINGING-Nachricht Alice’ VoIP-Applikation erreicht hat, zeigt diese das Klingeln auf Bobs Seite z .B. mit einem Freiton-Zeichen auf Alice’ Softphone an.
Hebt nun Bob den Hörer ab, so wird dies in Richtung Alice mit einer SIP-Response 200 OK signalisiert. In dieser Response teilt Bob Alice die unterstützten Medienformen und Codecs mit.
Der Empfang der OK-Nachricht wird von Alice’ VoIP-Applikation durch eine ACK-Nachricht in Richtung Bob bestätigt, wobei von nun an die Kommunikation zwischen Alice und Bob direkt zwischen beiden Softphones, d. h. ohne die beiden Proxys, erfolgt. Dies ist möglich, da Bob Alice‘ Adresse aus dem initialen INVITE kennt und Alice Bobs Adresse aus der 200-OK-Nachricht.
Von nun an können Alice und Bob Mediendaten, d. h. Sprachdaten, über das RTP-Protokoll miteinander austauschen. Während einer Session können beide Teilnehmer mit Hilfe eines re-INVITE die Mediendaten (z. B. Codec) ändern. Dies kann vom anderen Teilnehmer akzeptiert werden (200 OK) oder nicht (488 Not
Acceptable Here).
Die VoIP-Verbindung zwischen Alice und Bob kann jederzeit von einem der beiden Teilnehmer beendet werden. Beendet einer der beiden Teilnehmer z. B. durch Auflegen des Hörers die Verbindung, sendet das zugehörige Softphone eine BYE-Nachricht direkt zum anderen Teilnehmer, die dieser mit einer 200-OK-Nachricht beantwortet. Hierbei wird kein ACK gesendet, da ein ACK nach RFC 3261 nur als Response auf eine Response zu einem INVITE gesendet wird.
