VoIP : SIP

VoIP : SIP
Das Session Initiation Protocol
Johannes Jakob
20. Dezember 2004
Zusammenfassung
Das Session Initiation Protocol (SIP) stellt mit dem damit einhergehenden Session Description Protocol (SDP) und dem Real-time
Transport Protocol (RTP) eine Alternative zum etwas älteren H.323
dar. Es wird von verschiedensten aktuellen VoIP Anbietern verwendet
und kann für nahezu alle Internetanwendungen genutzt werden
1
1
Inhalt
Inhaltsverzeichnis
1 Inhalt
2
2 VoIP
2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
3 SIP
3.1
3.2
3.3
3.4
3.5
4
4
4
6
7
8
Allgemein .
Geschichte .
Methoden .
Telefonanruf
Beispiel . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 SDP
11
4.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Praxis
5.1 Einsatzmöglichkeiten
5.2 Einschränkungen . .
5.3 VoIP Anbieter . . .
5.4 Aussicht . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
16
16
6 Für Interessierte
17
A Literaturverzeichnis
19
2
2.1
VoIP
Allgemein
Unter Voice over IP versteht man das Telefonieren über das Internet
oder andere Datennetze. Telefongespräche werden hierbei nicht wie bei der
konventionellen Festnetztelefonie über dedizierte Telefonleitungen abgewickelt, sondern neben Daten jeglicher Art über eine (breitbandige) Internetverbindung übertragen.
Da hierfür in Gebäuden, national oder international nunmehr nur noch
ein einziges Netzwerk verlegt, gepflegt und verwaltet werden muss, rückt
VoIP immer mehr in den Vordergrund.
2
Telekommunikationsgesellschaften wickeln Transatlantikgespräche schon
lange nicht mehr über herkömmliche dedizierte Leitungen ab, sondern routen Telefongespräche schon länger resourcensparend über bestehende und
eigene Backbones des Internet ab.
Multinationale Konzerne wie Siemens oder SAP telefonieren innerhalb
des eigenen Konzerns über verschlüsselte VoIP Verbindungen und sparen
damit jährlich Unsummen an Telefongebühren.
Privatanwender zeigen stetig wachsendes Interesse an der neuen Alternative zur derzeit vergleichsweise teuren Festnetztelefonie innerhalb Deutschlands und von Deutschland ins Ausland. Da VoIP Anbieter Gespräche innerhalb der IP-Netze zum Nulltarif anbieten können, steigen immer mehr
Vieltelefonierer auf die neue Technik um, oder betreiben sie zumindest parallel.
Fazit Setzt sich diese Entwicklung weiterhin fort, kann man VoIP durchaus als Evolution der Festnetztelefonie betrachten, die nach analoger Technik
und ISDN nun zunehmend an Bedeutung gewinnt und noch großes Potential - man denke an den aus der Science Fiction altbekannten Traum von
alltäglicher Bildtelefonie - bereithält.
2.2
Kommunikation
Spricht man von VoIP über SIP, oder einem SIP-Telefon, so ist im Allgemeinen eine Kombination aus drei Protokollen gemeint, die nur im Zusammenspiel eine vollständige VoIP Implementierung darstellen.
Der Verbindungsaufbau bzw. die Signalisierung eines Anrufes wird bei
einer solchen Implementierung von dem Session Initiation Protocol (SIP)
(RFC 3261) übernommen. SIP kontaktiert den Gesprächspartner, signalisiert
dem Anrufer das Klingeln auf der Gegenseite und sorgt nach dem Abnehmen
für den Transport der nötigen Gesprächsparameter.
Der Datenaustausch selbst findet über das Real-time Transport Protocol
(RTP) (RFC 1889) statt, mit dem je nach Netzwerkverbindung zwischen den
beiden Parteien, nahezu in Echtzeit Audio und Video übertragen werden
können. Die Beschreibung des während einer Sitzung transportierten Mediums selbst wird vom Session Description Protocol (SDP) (RFC 2327) übernommen.
(Vergleiche hierzu die Quellen [5], [3], [4], [10], [1])
3
Auf SIP und SDP
werden.
3
soll nun im Folgenden etwas detaillierter eingegangen
SIP
3.1
Allgemein
Signalisierungsprotokoll In seiner Eigenschaft als Signalisierungsprotokoll dient das Session Initiation Protocol lediglich dem Verbindungsaufbau,
bzw. der Herstellung von Sessions und kann somit nur als Teil einer VoIP
Implementierung gesehen werden. Ähnlich dem Verbindungsaufbau im Bereich der konventionellen Festnetztelefonie wird durch SIP eine Anruf →
Klingeln → Abnehmen → Gespräch Signalisierung realisiert. Doch während
bestehende Systeme speziell für das Telefonnetz entwickelt worden waren,
wurde bei der Konzeption und Spezifikation von SIP speziell auf die Verwendung in Datennetzen geachtet.
Klartextprotokoll Bei SIP handelt es sich um ein Klartextprotokoll, welches von bereits bestehenden, populären Klartextprotokollen wie HTTP und
SMTP einige wesentliche header geerbt hat. Welche header dies im speziellen
sind, wird später an Hand von Beispielen erläutert (siehe 3.5 und 4.2).
Request → Response Ähnlich dem HTTP lassen sich SIP Anfragen als
Request → Response Pakete charakterisieren, wobei SIP auch hier auf bestehende Spezifikationen zurückgreift und im Allgemeinen die vom HTTP
verwendeten Response-Codes verwendet. So kann es einem VoIP Teilnehmer
durchaus passieren, den aus dem Web bekannten 404 - Not Found Fehler
auf seinem Telefondisplay vorzufinden.
(Vergleiche hierzu die Quellen [5], [3], [4], [1])
3.2
Geschichte
Februar 1996 Henning Schulzrinne, der Begründer der Entwicklung von
SIP, legte im Feburar 1996 erstmals Entwürfe vor, die zuerst von der MMUSIC1 Arbeitsgruppe der IETF aufgefasst und weiterentwickelt wurden. Später
wurde eine eigene Arbeitsgruppe mit der Weiterentwicklung von SIP beauftragt.
Februar 1999 Drei Jahre später war aus den ursprünglichen Etwürfen ein
erster Vorschlag für einen SIP-Standard hervorgegangen.
1
Multiparty Multimedia Session Control
4
März 1999 Dieser Vorschlag wurde im März 1999 in der RFC 2543 als
Standard spezifiziert.
November 2000 Den bis dahin größten Erfolg konnte SIP im November
2000 erringen, als es für UMTS, den Mobilfunkstandard der Zukunft, als
Signalisierungsprotokoll ausgewählt wurde.
Juni 2003 Um nur eine der jüngsten Entwicklungen aufzuzeigen, sei hier
nur ein Beispiel genannt: Im Juni 2003 hat Apple Computer Inc. eine Betaversion seiner Audio/Video Conferencing software iChat AV freigegeben, die
zwischen zwei Benutzern die Kommunikation auf Basis von SIP ermöglicht.
Gegenwart Gerade in den letzten Monaten ist die Entwicklung neuer SIP
fähiger Soft- und Hardware auf einem weiteren Höhepunkt angelangt. Nahezu wöchentlich ist über einen der vielen (SIP-) VoIP-Anbieter in den einschlägigen Zeitungen/Foren zu Lesen.
Die Charta In der von Henning Schulzrinne und der IETF niedergeschriebenen Charta (vgl. [3]) wurden als Ziele der SIP Entwicklung folgende
Grunsätze festgelegt:
1. Services and features are provided end-to-end whenever possible.
2. Extensions and new features must be generally applicable, and not
applicable only to a specific set of session types.
3. Simplicity is key.
4. Reuse of existing IP protocols and architectures, and integrating with
other IP applications, is crucial.
Erläuterungen
Services and features are provided end-to-end whenever possible.
Skalierbarkeit - Um eine aufwendige Netz-/Serverstruktur zu vermeiden, sollten die Clients den abzuwickelnden Datenverkehr unter sich
ausmachen und wenn möglich ohne Zwischenstationen direkt miteinander austauschen können. Sessions zweier VoIP Clients werden zwar
in der Praxis über einen SIP-Proxy der Anbieter ausgehandelt, die Verbindung inklusive Datenverkehr selbst kommen jedoch zwischen den
Gesprächsteilnehmern direkt zustande.
Extensions and new features must be generally applicable ... Flexibilität
- Die SIP Spezifikationen und alle zukünftigen Erweiterungen sollten
5
auf keinen Fall auf spezifische Dienste und Anwendungsprobleme bezogen sein, sondern in einem möglichst großen Spektrum an Anwendungen einsetzbar sein. (→ keine VoIP-spezifischen Methoden in SIP!)
Simplicity is key. Einfachheit - Je einfacher das Protokoll spezifiziert ist,
desto einfacher kann es implementiert werden und desto eher findet
es in der Praxis Verwendung. Die geringe Komplexität SIP’s spiegelt
sich vorallem in seiner Eigenschaft als Klartextprotokoll und der überschaubaren Anzahl spezifizierter Methoden wieder (→ 3.3)
Reuse of existing IP protocols and architectures ... Wiederverwendung
- Wieso das Rad neu erfinden, wenn auf bereits bestehende Protokolle
und Technologien zurückgegriffen werden kann? Da SIP als Protokoll
für das Internet entwickelt werden sollte, musste es sich in das existierende Gefüge aus Protokollen und Übertragungsstandards eingliedern.
Es lag somit nahe, bereits etablierte Protokolle wie SMTP und HTTP
zu analysieren und gegebenenfalls verwendbare Aspekte zu übernehmen. Die Wiederverwendung von Elementen aus SMTP und HTTP
wird an Hand der Beispiele zu SIP (→ 3.5) und SDP (→ 4.2) weiter
unten etwas detaillierter beschrieben.
3.3
Methoden
Die RFC 2543 (vgl [2]) spezifiziert für SIP sieben Methoden, die in jeder
SIP Implementierung enthalten sein müssen. Jede Methode stellt einen Request dar, der vom Empfänger des Requests, dem Peer mit einem ResponseCode beantwortet wird. Da eine dieser sieben Methoden nur eine Variation
einer Anderen darstellt, kann man folgende SIP Methoden unterscheiden:
REGISTER Mit REGISTER meldet ein SIP Client seinem SIP Registrar - ein Server, der eine Liste aller in seinem Zuständigkeitsbereich
verfügbaren Clients führt - dass er nun online, also verfügbar ist. Ein
VoIP Telefon beispielsweise meldet sich am Registrar des VoIP Anbieters an und signalisiert ihm damit, dass es ab dem Zeitpunkt der
Registrierung erreichbar ist. In Folge dessen wird eine etwaige Voicemailbox deaktiviert und ankommende Anrufe werden durchgestellt.
INVITE Ein INVITE stellt bei der Herstellung einer Verbindung zwischen
Clients den jeweils ersten Request dar. Er signalisiert dem Peer, dass
ein Verbindungsaufbau gewünscht wird und initiert damit den Verbindungsaufbau.
Wird ein INVITE während einer bestehenden Verbindung gesandt, so
nennt man diesen Request einen RE-INVITE. Ein solcher RE-INVITE
wird im Allgemeinen gesandt, wenn sich Sitzungs-Parameter geändert
haben (Beispielsweise falls im Lauf eines Gesprächs Videoübertragung
hinzu geschaltet werden soll).
6
ACK Kommt der Verbindungsaufbau zustande (abhängig vom ResponseCode des Peers), so schickt der ursprünglich initierende client ein ACK
an den Peer, um damit den Abschluss des Verbindungsaufbaus zu quittieren. Wurde das Zustandekommen der Sitzung zwischen den Clients
mit einem ACK bestätigt, so können nun beispielsweise Daten ausgetauscht, oder ein Gespräch geführt werden.
BYE Sendet einer der Clients während einer bestehenden Sitzung ein BYE,
so wird hiermit das Ende der Sitzung signalisiert. (→ das Auflegen bei
einem Telefonat)
CANCEL Soll ein abgeschickter, jedoch noch nicht bestätigter Request
abgebrochen werden, so schickt der Initiator des entsprechenden Requests ein CANCEL an den Peer und teilt ihm damit mit, dass der
vorangegangene Request für ungültig erklärt wurde. (→ Das Auflegen
des Hörers nach zu langer Wartezeit, oder weil der Anrufende gemerkt
hat, dass er sich verwählt hat)
OPTIONS Im Gegensatz zu H.323 muss bei SIP kein Verbindungsaufbau
stattfinden, um die Fähigkeiten des Peers in Erfahrung zu bringen.
Mit einem OPTIONS Request kann ein Client schon vor einem Verbindungsaufbau beim Peer anfragen, welche Inhalte dieser interpretieren kann. So kann unter anderem schon vor dem Anklingeln überprüft werden, ob der Angerufene ein Bildtelefon besitzt, oder ob er nur
Audio-Anrufe entgegennehmen kann.
Wie diese Methoden nun zusammenpassen, soll im Folgenden an Hand
eines schematischen Telefonanrufes beschrieben werden.
3.4
Telefonanruf
Angenommen es gebe zwei Benutzer A und B, die beide über einen SIP
VoIP-Anschluss verfügen. Nehmen wir weiter an, Benutzer A will (→ Abbildung 1) B anrufen. Er nimmt den Telefonhörer ab und wählt die Nummer
von B woraufhin sein Telefon einen INVITE Request an das Telefon von B
schickt. Dieses fängt an zu Klingeln und teilt es dem Telefon von A mit dem
Response Code 180: Klingelt mit sodaß A nun ganz nach Telefon-Manier
ein Tuten im Hörer hört. Nimmt B weiterhin nicht ab, schickt sein Telefon so lange 180: klingelt an A’s Telefon, bis B entweder abnimmt, A ein
CANCEL schickt, oder die Verbindung aus technischen Gründen zusammenbricht. Nehmen wir jedoch an, B nimmt den Anruf entgegen. Im Moment
des Abhebens, signalisiert sein Telefon dem von A mit einem Response-Code
200: OK, dass der Anruf entgegengenommen wurde und das Gespräch nun
zustande kommen kann. Da A geduldig gewartet und den Hörer noch nicht
wieder aufgelegt hat, schickt sein Telefon zur Quittierung des 200: OK einen
ACK -Request und schließt damit den Verbindungsaufbau ab. Das Gespräch
7
Abbildung 1: Schematischer Telefonanruf
SIP
Telefon
SIP
Telefon
Benutzer A
Benutzer B
wählt
INVITE
180: klingelt
nimmt
ab
200: OK
ACK
Sprachübermittlung via RTP
legt auf
BYE
200: OK
kann nun geführt und jederzeit durch Auflegen beendet werden. In unserem
Beispiel legt B schneller auf als A, sodaß B’s Telefon das Ende des Telefonats mit einem BYE Request signalisiert. Dieser wird ebenfalls mit 200:
OK bestätigt und somit das Gespräch beidseitig beendet.
An diesem Beispiel wird auch der Signalisierungscharakter von SIP deutlich. Aber wie sieht nun eine solche SIP-Kommunikation im Speziellen aus?
Im Folgenden werden zwei SIP Pakete exemplarisch analysiert.
3.5
Beispiel
Nehmen wir auch hier einen Telefonanruf als Beispiel, wobei aus diesen
Paketen nicht hervorgeht, welche Art von Sitzung zwischen den beiden Benutzern A und B stattfindet, bzw. welche Medien ausgetauscht werden. (→
Flexibilität von SIP (→ S. 6)!)
A ruft B an Betrachten wir zuerst die Seite des Anrufers A, der die
Verbindung wünscht und deshalb einen INVITE Request an B schickt (Vgl.
Abbildung 2):
INVITE sip:[email protected] SIP/2.0 In der ersten Zeile, steht ähnlich einem HTTP Request, der SIP Request, der im ersten Feld genauer
8
Abbildung 2: SIP-Paket von A an B; Variation des Beispiels aus der RFC
[2]
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 12.26.17.91:5060
Max-Forwards: 70
To: Benutzer B <sip:[email protected]
From: Benutzer A <sip:[email protected];tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
spezifiziert wird. Das zweite Feld enthält die Adresse des Angerufenen
B und im dritten Feld wird die Protokollversion angegeben, in welcher
dieses Paket formuliert ist.
Via: SIP/2.0/UDP 12.26.17.91:5060 Die Via: Zeilen ähneln sehr den
Received Zeilen der SMTP header. Sie enthalten zeilenweise eine Beschreibung des Weges, den ein Request gekommen ist und den eine
Antwort zurückgehen muss. Da wir im Moment das Paket betrachten,
wie es von A abgeschickt wird, enthält es bisher nur die Adresse von
A und damit das spätere Ziel von Response-Paketen.
Max-Forwards: 70 Hier wird das Maximum an möglichen Zwischenstationen (die in den Via Zeilen protokolliert werden) festgelegt. Wird
diese Obergrenze überschritten, wird das Paket ungültig und die Verbindung kommt nicht zu Stande.
To: Benutzer B <sip:[email protected] Auch die To: Zeile lehnt sich
an einem SMTP Header an und enthält die Adresse des RequestEmpfängers, in unserem Telefoniebeispiel dem Benutzer B.
From: Benutzer A <sip:[email protected];tag=1928301774 Äquivalent zur To: Zeile wird in der From: Zeile der Request-Ursprung,
hier der Benutzer A beschrieben. Zu beachten ist hierbei, dass nach
der Adresse des Request-schickenden Clients ein mit tag bezeichneter
Zufallswert steht, der vom Client zu lokalen Identifizierungszwecken
generiert wird.
Call-ID: [email protected] Mit Call-ID wird eine weltweit
eindeutige Identifizierung der SIP Session festgelegt, die sich aus einem
9
Zufallswert und der mit @ angeschlossenen IP-Adresse des Sitzungsinitialisierenden Benutzers A zusammensetzt.
Die Kombination aus To:, From: und Call-ID Zeilen bilden eine eindeutige Identifizierungsmöglichkeit dieser Sitzung. Diese Kombination
definiert einen absolut eindeutigen Dialog zwischen A und B.
CSeq: 314159 INVITE Innerhalb eines Dialoges erhält jeder gesendete
Request eine eindeutige Nummer, die hauptsächlich aus Gründen chronologischer Konsistenz nötig ist. Kommen bei einer Zwischenstelle aus
technischen Gründen zwei oder mehr, zum identischen Dialog gehörenden Requests an, kann die Zwischenstelle an Hand der CSeq entscheiden, welcher von ihnen der zeitlich nächste ist und diesen als erstes
weiterleiten.
Contact: <sip:[email protected]> Während die Via: Zeilen den Weg
beschreiben, den eine Antwort zu A, bzw. dem Request-sendenen Client zu nehmen hat, wird in der Contact: Zeile spezifiziert, an welche
Adresse neue Requests geschickt werden sollen. So ein Request kann
beispielsweise das BYE sein, um den bestehenden Dialog zu beenden.
Content-Type: application/sdp Der Content-Type beschreibt den im
SIP Paket enthaltenen Content, der im Body des Pakets mitgeschickt
wird. In den meisten Fällen, in denen SIP zur Übertragung von Audio, Video, oder sonstigen Multimedia-Inhalten dient, dürfte das SIP
Paket einen Inhalt vom Typ application/sdp transportieren, also im
Body ein Paket vom Typ SDP enthalten (→ 4).
Content-Length: 142 Wie groß das transportierte Paket ist, kann aus
derContent-Length Zeile abgelesen werden. Die Größenangabe ist hierbei in Bytes. In diesem Fall ist das SDP Paket also 142 Bytes groß.
B nimmt Anruf entgegen Obiges Paket von A ist nun also bei B eingetroffen, das Telefon hat geklingelt und B hat abgenommen. Das Klingeln
wurde hier zwar ausgelassen, doch ließe sich das entsprechende Paket analog
zum folgenden Beispiel (→ Abbildung 3), jedoch mit dem Response-Code
180: Ringing konstruieren.
Wie zuvor beim INVITE Request, findet sich in der ersten Zeile der eigentliche SIP-Teil, in diesem Fall die Versionsnummer des Protokolls (SIP/2.0)
und der Response-Code 200: OK. Die ersten beiden Felder, welche den Request selbst und die Adresse des Request-Peers enthielten, fehlen hier, da
das Paket als Response keinen Request enthält und die Zieladresse, bzw.
sogar der gesamte Weg zum Ziel, durch die Via: Zeilen festgelegt ist. Die
Zeilen To:, From: und Call-ID sind identisch (sie definieren den Dialog,
s.o.), jedoch hat nun auch Benuter B in der To: Zeile, einen Zufallswert
(tag) erhalten. Die Request-Nummer (CSeq:) ist unverändert, da es sich bei
10
Abbildung 3: Retour-SIP-Paket von B an A
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
Via: SIP/2.0/UDP 12.26.17.91:5060
To: Benutzer B <sip:[email protected];tag=a6c85cf
From: Benutzer A <sip:[email protected];tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131
dem betrachteten Paket um die Antwort auf den Request (INVITE ) handelt
und zwischenzeitig kein weiterer Request abgeschickt wurde. Die Contact:
Zeile jedoch beinhaltet nun die Adresse von B, welcher das Response-Paket
abschickt und zukünftige Requests (z.B. das vermutlich nun folgende ACK,
oder das mögliche CANCEL) erhalten möchte. Auch in diesem Beispiel beinhaltet das SIP Paket einen SDP-Inhalt, diesmal der Länge 131 Bytes.
Ähnlichkeiten zu SMTP und HTTP An Hand dieser Beispiele für SIP
Pakete sollte deutlich geworden sein, welche Elemente SIP von HTTP und
SMTP geerbt hat (Request-Zeile, Via, To und From von SMTP / ContentType, Content-Length und die Response-Codes von HTTP) und welche neu
hinzugekommen sind (Call-ID, CSeq, Contact). Der Aufbau der SIP Pakete
selbst ähnelt ebenfalls sehr den bereits bekannten Protokollen und macht
es damit Entwicklern und Administratoren einfach, sich an dieses ’neue’
Protokoll zu gewöhnen.
(Vergleiche hierzu die Quellen [2], [3], [4], [5], [1])
4
4.1
SDP
Allgemein
Das Session Description Protocol wird als Content der SIP Pakete übertragen und beschreibt die Medien, welche innerhalb des Dialoges übertragen
werden. Während das SIP Paket selbst nur für die Herstellung der Verbindung sorgt, beinhaltet das SDP Paket die Informationen darüber, ob Audio,
Video oder sonstige Inhalte, oder eine beliebige Kombination davon übertragen werden sollen.
11
Ein minimales SDP Paket enthält folgende Elemente (vgl. [6]):
• Beschreibung der Session allgemein
(v=) Protokollversion des SDP Paketes
(o=) Ursprung und Identifizierung - enthält Informationen über den
Benutzer der die Session initiiert hat
(s=) Session-Name - ein beliebiger Name für die Session
• Beschreibung des Zeitfaktors
(t=) Zeitgrenzen - Start- und Endzeit der Session. Ist kein definitives
Ende bekannt (bei VoIP Anrufen ist selten im Vorhinein bekannt,
wann das Telefonat vorrüber sein wird), so kann auf die Endzeit
verzichtet werden und auf 0 gesetzt werden. Die Startzeit muss
jedoch auf jeden Fall gegeben werden.
• Beschreibung der zu übertragenden Medien
(m=) Name, Typ und Übertragungsadresse - Hier wird jedes übertragene Medium gesondert beschrieben.
4.2
Beispiel
Das folgende Beispiel (→ Abbildung 4) beschreibt diesen Vortrag nach
SDP Standard. In diesem Beispiel werden neben der Mindest-Beschreibung
noch einige weitere Elemente besprochen:
Abbildung 4: SDP Paket, das diesen Vortrag beschreibt; Variation des Beispiels aus der RFC [6]
v=0
o=jjj 2890844526 2890842807 IN IP4 126.16.64.4
s=SIP Vortrag
i=Vortrag ueber VoIP:SIP
u=http://wwwbode.cs.tum.edu/[...]/seminars/WS04/PSTK
[email protected] (Johannes Jakob)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
12
Erklärung zum Beispiel
v=0 Protokollversion 0
o=jjj 2890844526 2890842807 IN IP4 126.16.64.4 Der Benutzer mit
Loginname jjj hat die Session initiiert. Das zweite Feld enthält die
Session-ID, das Dritte stellt eine Versionsnummer dieser Session dar.
Die Felder vier, fünf und sechs bezeichnen die Urpsrungsadresse der
Session. IN bezeichnet den Netzwerktyp, in diesem Fall Internet, IP4
den Adress-Typ (IP Version 4) und Feld sechs enthält die entsprechende Ursprungsadresse.
s=SIP Vortrag Der Name der Sitzung ist SIP Vortrag
i=Vortrag ueber VoIP:SIP Als Subtitle, bzw. zusätzliche Information
wird Vortrag ueber VoIP:SIP übertragen.
u=http://wwwbode.cs.tum.edu/[... /seminars/WS04/PSTK] Hier kann
ein URI zu weiteren Informationen im Internet definiert werden.
[email protected] (Johannes Jakob) Die eMail-Adresse des Autors
c=IN IP4 224.2.17.12/127 Mit c für Connection werden Verbindungsparameter beschrieben. So wird hier analog zur Adressdefinition im oHeader eine Internetadresse vom Typ IP Version 4 beschrieben. Diese
Adresse gibt an, WO man diese Sitzung finden kann, in diesem Fall
kann der Vortrag vom Server mit der Adresse 224.2.17.12 abgeholt
werden. Der Postfix /127 beschreibt eine Time to live (TTL), also eine Obergrenze der Latenzzeit die gestattet wird. Ein Zuhörer, der eine
größere Verzögerung hätte, kann Audio und Video nicht synchronisiert
empfangen, wird also ausgeschlossen aus dem Hörerkreis.
t=2873397496 2873404696 Da der Vortrag in einem festen zeitlichen
Rahmen stattfindet, können sowohl Start-, als auch Endzeit angegeben
werden.
a=recvonly Mit a werden Attribute übergeben, die für die Medien gelten. recvonly erklärt den Vortrag zu einem passiven Vergnügen für die
Zuhörer.
m=audio 49170 RTP/AVP 0 Hier werden nun die drei Mediastreams
definiert, welche von obigem Server empfangen werden können. Hier
wird ein Audiostream beschrieben, welcher vom Port 49170 empfangen
werden kann und im via RTP/AVP (Real-time Transport Protocol, mit
Audio/Video Protocol) übertragen wird. Die 0, bzw. das vierte Feld
bezeichnet einen vom Medium abhängigen Formatbezeichner. In unserem Beispiel wird hiermit die Stimme des Vortragenden übertragen.
13
m=video 51372 RTP/AVP 31 Hierbei handelt es sich um einen Videostream am Port 51372. Beschrieben wird hier der visuelle Aspekt des
Vortrages (Gestik, Erscheinung des Vortragenden).
m=application 32416 udp wb Und zu guter letzt werden hier die über
UDP übertragenen Folien beschrieben.
a=orient:portrait Diese sollen quer, also für Folien typisch angezeigt werden (Portrait - Orientierung)
Zusammenspiel von SIP, SDP und RTP SIP und SDP ergänzen sich
beim Aushandeln der Übertragungswege und der Art des Übertragungsinhaltes. Der Inhalt selbst jedoch wird nicht in den selben Nachrichten übertragen:
Host A
Host B
SIP/SDP (TCP oder UDP)
Audio durch RTP (UDP)
Audio durch RTP (UDP)
Video durch RTP (UDP)
Video durch RTP (UDP)
Host A baut mit SIP (über TCP, oder UDP) eine Verbindung zu B auf
und teilt B mit Hilfe des im SIP Paket enthaltenen SDP Paketes mit, welche Medien übertragen werden sollen. Die Daten selbst, im Fall von VoIP
hauptsächlich Audio (und Video) Ströme in beide Richtungen, werden mit
Hilfe des RTP über UDP Kanäle übermittelt. Hier wird ein weiteres mal
deutlich, dass SIP nur einen kleinen Teil einer eigentlichen VoIP Implementierung darstellt.
(Vergleiche hierzu die Quellen [10], [6], [7], [2], [8], [10])
14
5
Praxis
5.1
Einsatzmöglichkeiten
Auf Grund seiner Flexibilität und Skalierbarkeit findet SIP Verwendung
in verschiedensten Session-basierten Anwendungsbereichen. In folgenden Bereichen werden bereits SIP basierte, oder -gestützte Implementierungen verwendet:
• Instant Messaging
• Spiele
• Internet - Telefonie (→ Anbieter)
• Video Conferencing (Windows Messenger, Apple iChat)
Diese Auswahl ist jedoch keinesfalls representativ für die Verbreitung von
SIP in der heutigen Praxis. Da es nahezu in allen Peer-to-Peer Anwendungen
eingesetzt werden kann, sind seiner Verbreitung keinerlei Grenzen gesetzt
und so kommen wöchentlich neue Anwendungen oder Geräte hinzu.
5.2
Einschränkungen
Durch die grundlegend einfache Struktur von SIP/SDP und die uneingeschränkte Mobilität der Clients, unterliegt eine auf SIP basierende VoIP
Lösung zumindest zwei gravierenden Einschränkungen.
Betrieb hinter NAT-Firewalls NAT Firewalls werden in der Regel eingesetzt um kleineren internen Netzen mit inoffiziellen, sogenannten ’RFC
IPs’, die von ausserhalb der Firewall nicht erreichbar sind, den Internetzugang zu ermöglichen. Hierzu werden Anfragen von Clients innerhalb der
Firewall beim Durchwandern der Firewall manipuliert und in den IP-Paketheadern an Stelle der internen IP Adresse des Clients, die nach Aussen hin
offizielle IP Adresse der Firewall eingesetzt. Wird die Anfrage von einem
Rechner ausserhalb der Firewall beantwortet, erreicht die Antwort ebenfalls
die Firewall und wird von ihr an den ursprünglichen Client im internen Netz
weitergeleitet.
Da Clients im internen Netz nur ihre interne RFC IP-Adresse kennen,
können sie in die SIP und SDP Pakete nur diese interne IP-Adresse einsetzen.
Diese Pakete jedoch werden von einer herkömmlichen NAT-Firewall nicht
korrigiet. Würde ein solches Paket nun einen SIP-Peer erreichen, könnte dieser unmöglich darauf antworten, da er auf Grund der Spezifikation der RFC
Adressen keinerlei Kontakt zum ursprünglichen Client aufnehmen kann.
Um diesem Problem vorzubeugen, bieten VoIP-Anbieter in der Praxis
sogenannte STUN 3 Server an, die den internen Clients hinter einer NAT
3
Simple Traversal of UDP through NAT
15
Firewall die Möglichkeit geben, die nach Aussen hin gültige IP-Adresse der
Firewall und den für sie freigeschaltenen Port in Erfahrung zu bringen. Diese
nun auch außerhalb der Firewall gültigen Adressdaten, kann der Client nun
in die SIP und SDP Pakete schreiben und damit Peers außerhalb des internen
Netzes die Möglichkeit geben, auf seine Pakete zu antworten.
Alternativ zu solchen STUN Servern können auch neuere NAT Firewalls
eingesetzt werden, die SIP/SDP Pakete modifizieren und damit die internen
Adressen durch die korrekten externen ersetzen können.
(Vergleiche hierzu die Quellen [5], [2], [14], [13], [15])
Notruf Der Notruf stellt ein ganz anderes Problem dar. Da VoIP/SIP
Geräte ohne großen Aufwand an einen geographisch anderen Ort transportiert werden können, kann die Herkunft eines eventuellen Notruf-Anrufes
nicht lokalisiert werden, wie dies im konventionellen Telefonnetz möglich
ist. Hierdurch wäre keine schnelle und kompetente Hilfeleistung, realisiertbar, da beispielsweise nicht herauszufinden ist, welche Rettungsleitstelle die
geographisch nächste und zuständige ist.
Um auch reinen VoIP Haushalten den Notruf anbieten zu können, hat
sipgate als Pionier in dieser Angelegenheit im Raum Düsseldorf ein Pilotprojekt gestartet. Um an diesem ersten Test teilnehmen zu können, müssen
VoIP Kunden in diesem Raum authentische Adressdaten hinterlegen.
(Vergleiche hierzu die Quellen [16], [17])
5.3
VoIP Anbieter
Momentan sind in Deutschland unter Anderem folgende VoIP-Anbieter
aktiv, die auf SIP/SDP basierende Dienste anbieten:
Freenet http://www.freenet.de
Nikotel http://www.nikotel.de
PURtel http://www.purtel.de
sipgate http://www.sipgate.de
sipsnip http://www.sipsnip.de
web.de http://www.web.de
5.4
Aussicht
Derzeit sind im Telefoniebereich nach wie vor konventionelle Dienstanbieter aus den Sparten Festnetztelefonie und Mobilfunk führend, jedoch
ist gerade in den letzten Monaten ein deutlicher Trend in Richtung VoIP
zu erkennen. Sowohl in Deutschland, als auch in den USA können nahezu
wöchentlich Schlagzeilen zu VoIP Themen gelesen werden.
16
Regulierung Während in den USA aktuell noch debattiert wird, ob VoIP
momentan überhaupt reguliert werden soll, hat in Deutschland die Regulierungsbehörde für Telekommunikation und Post (RegTP) bereits ein erstes
Machtwort gesprochen. Zum Schutz der Orstgebundenheit von Vorwahlbereichen wurde am 20.08.2004 angeordnet, dass VoIP Betreiber keine ortsfremden Vorwahlen mehr vergeben dürfen. Diese Anordnung betrifft vorallem Bewohner von Kleinstädten und Dörfern, die bisher VoIP Vorwahlen
der nächst größeren Großstadt (oder einer beliebigen Anderen) benutzen
konnten. Um auch dieser Nutzergruppe weiterhin VoIP Dienste anbieten
zu können, wichen die Anbieter auf ortsunabhängige Vorwahlbereiche wie
01801 (sipgate) aus. Um VoIP Telefonie einen Schritt weiter zum Erfolg zu
bringen und Anrufern die Möglichkeit zu geben, an Hand der Rufnummer
auf den Anschlusstyp schließen zu können, wurde beschlossen, einen eigenen
Vorwahlraum für VoIP Anbieter zu begründen. So wird im ersten Halbjahr 2005 mit der Vergabe von Rufnummern aus dem Vorwahlbereich 032
begonnen und damit die Position der VoIP Anbieter im deutschen Markt
gefestigt.
Entbündelung des Internetanschlusses vom Festnetzanschluss Da
bisher in Deutschland kaum und nur in Großstädten die Möglichkeit besteht,
auch ohne einen bestehenden Festnetztelefonanschluss einen breitbandigen
Internetanschluss zu erhalten, wird neben der Regulierung des Vorwahlbereichs erwogen, breitbandige DSL Anschlüsse vom Festnetzanschluss zu
entbündeln und damit VoIP eine reelle Chance auf tatsächlichen kommerziellen Erfolg einzuräumen.
Fazit Da VoIP-Anbieter ein einzigartiges Preisleistungsverhältnis anbieten können und netzinterne Telefonate sogar gratis realisieren können (der
Betrieb eines eigenen Telefonnetzes entfällt), rückt VoIP gerade für Vieltelefonierer und preisbewusste Auslandstelefonierer zunehmend in den Vordergrund. Da vermehrt auch preiswerte SIP fähige VoIP Endgeräte auf den
Markt kommen, wird VoIP auch für technisch unversierte Anwender zunehmend interessant.
6
Für Interessierte
Für weitergehende Informationen und tiefergreifende Spezifikationen soll
hier eine Liste von Seiten für den tiefergreifenden Einstieg in die Themen
SIP, SDP, RTP und VoIP gegeben werden:
• SIP
– Henning Schulzrinne’s SIP page
http://www.cs.columbia.edu/sip/
17
– SIP RFC 3261
http://www.ietf.org/rfc/rfc3261.txt
– IETF Workgroup
http://www.ietf.org/html.charters/sip-charter.html
– SIP Forum
http://www.sipforum.org
– SIP Zusammenfassung
http://voip-info.org/wiki-SIP
• SDP
– SDP RFC 2327
http://www.rfc-editor.org/rfc/rfc2327.txt
– SDP Zusammenfassung
http://voip-info.org/wiki-SDP
• RTP
– RTP RFC 3550
http://www.rfc-editor.org/rfc/rfc3550.txt
– RTP Zusammenfassung
http://voip-info.org/wiki-RTP
• VoIP
– Sammlung von VoIP Informationen
http://voip-info.org
– Heise Newsticker zu VoIP
http://www.heise.de/newsticker/search.shtml?T=VoIP
18
A
Literaturverzeichnis
Literatur
[1] Henning Schulzrinne’s SIP page http://www.cs.columbia.edu/sip/
[2] SIP RFC 3261 http://www.ietf.org/rfc/rfc3261.txt
[3] IETF Workgroup http://www.ietf.org/html.charters/sip-charter.html
[4] SIP Zusammenfassung http://voip-info.org/wiki-SIP
[5] Englische Wikipedia Seite zu SIP http://en.wikipedia.org/wiki/Session
Initiation Protocol
[6] SDP RFC 2327 http://www.rfc-editor.org/rfc/rfc2327.txt
[7] SDP Zusammenfassung http://voip-info.org/wiki-SDP
[8] RTP RFC 3550 http://www.rfc-editor.org/rfc/rfc3550.txt
[9] RTP Zusammenfassung http://voip-info.org/wiki-RTP
[10] Englische Wikipedia Seite zu RTP http://en.wikipedia.org/wiki/Real-time
Transport Protocol
[11] Sammlung von VoIP Informationen http://voip-info.org
[12] Heise Newsticker zu VoIP http://www.heise.de/newsticker/search.shtml?T=VoIP
[13] SIP Clients hinter NAT http://graphics.cs.uni-sb.de/VoIP/config.html
[14] Englische Wikipedia Seite zu NAT http://en.wikipedia.org/wiki/NAT
[15] Englische Wikipedia Seite zu STUN http://en.wikipedia.org/wiki/STUN
[16] sipgate News-Artikel http://www.sipgate.de/user/news.php
[17] Teltarif.de Artikel http://www.teltarif.de/arch/2004/kw30/s14332.html
Bitte beachten: Bei [5] und [10] sind die Spaces in der URL durch Unterstriche ( ) zu ersetzen.
19