DAS Session-Initiation-Protocol soll im Folgenden

Transkript

1 DIE INTERNET-PROTOKOLLWELT, WINTERSEMESTER 2016/17 1 Session Initiation Protocol (SIP) Georg Rolapp, Student im Master Elektrotechnik/Informationstechnik Zusammenfassung In dieser Abhandlung wird das Session-Initiation-Protocol (SIP) vorgestellt. Das Internet- Protokoll dient zur Signalisierung multimedialer Kommunikation, wie z.b. Telefonie (VoIP) oder Streaming. Behandelt wird im Folgenden das Konzept, die Systemarchitektur, die Adressierung, der Aufbau der Nachrichten, sowie beispielhaft der Ablauf von Kommunikationsvorgängen der teilnehmenden Kommunikationspartner. Weiterhin wird gezeigt, warum das Protokoll von immer mehr Diensten genutzt wird. Index Terms Internet, Kommunikationsprotokoll, Anwendungsschicht, VoIP, Session, SIP. I. ÜBERSICHT DAS Session-Initiation-Protocol soll im Folgenden kurz SIP genannt werden. Es dient im Internet zur Signalisierung und wird zur Herstellung von Verbindungen zwischen zwei oder mehreren Kommunikationspartnern von verschiedenen multimedialen Diensten eingesetzt. Diese Dienste ermöglichen es z.b. in sogenannter Echtzeit, also mit Verzögerungen im unteren Millisekundenbereich digitalisierte Audio- bzw. Videoinformationen in Paketform zu übertragen. SIP wurde 1999 von der Internet Engineering Task Force (IETF) entwickelt und mittels RFC 2543 spezifiziert (HSSR99, S.1). Es stellt eine Alternative zu dem, von der International-Telecommunication- Union (ITU-T), entwickelten Standard H.323 dar. Während H.323 primär das Ziel hat Telefonie über das Internet zu ermöglichen, geht SIP weit darüber hinaus. Genutzt wird es für Voice-over-IP (VoIP), Audio- und Videostreaming, aber auch für Kurznachrichten- und Notruf-Dienste usw. (Bad09, S.273). SIP ist zwar keine Applikation, wird aber im TCP/IP- Modell häufig der Anwendungsschicht zugeordnet, da es auf den Protokollen der Transportschicht (TCP, UDP, SCTP) aufsetzt, siehe auch Abbildung 1 (RSC + 02, S. 3). Im ISO/OSI-Modell ist es natürlich der Kommunikationssteuerungsschicht, die für den Auf- und Abbau von Sitzungen zuständig ist, zuzuordnen. Diese Sitzungen können, bei Fehlern auf den transportorientierten Schichten, auch über mehrere Transportschichtverbindungen hinweg bestehen (Sei06, S. 42f). Die Abbildung 1 zeigt einen Überblick über die Protokolle, die für die multimediale Kommunikation via SIP benötigt bzw. verwendet werden. Zum Beispiel ist das Session-Description-Protokoll (SDP) für die Beschreibung der Mediatypen zuständig, also z.b. welches Medienformat (Codec) verwendet wird und kann an eine SIP-Nachricht (Kapitel II-G) angehängt werden (RSC + 02, S.9). Das in Abbildung 1 ebenfalls abgebildete Real-Time-Transport-Protokoll (RTP) übernimmt die Übertragung der Audio- und Videodaten über eine Ende-zu-Ende-Verbindung zwischen Sender und Empfänger, sobald die Verbindung via SIP hergestellt wurde (RSC + 02, S.8). Es sorgt durch eine fortlaufende Paketnummerierung und mit Zeitstempeln dafür, dass die Daten vom Zielgerät in der richtigen Reihenfolge wiedergegeben werden (HSCFJ96, S.22). Durch verschiedene Übertragungswege und Paketverluste treffen die Pakete, wie im Internet üblich, nach unterschiedlichen Laufzeiten und in einer ungeordneten Reihenfolge beim Empfänger ein (TW15, S. 90). 5.2 Protokolle für Sprachübermittlung 169 über IP-Netze können aber auch weitere Transportprotokolle darunter DCCP, TCP und sogar auch SCTP verwendet werden. Darauf geht Abschnitt detaillierter ein. ) E 8 E? A 8 A ) M K C A ) E 8 E? A 8 A) M K C I I? D E? D J 0!! 5 1 / 5, , 2, H = I F H J I? D E? D J 1 J A H A J 2 H J? 1 2 L " 1 2 L $ 8 A H E J J K C I I? D E? D J > A H E J J K C I A J A Abb : RTP/RTCP über die Transportprotokolle UDP, TCP und DCCP Abbildung SIG: SIGnalisierung, 1. Die SDP: Multimediaprotokolle Session Description Protocol, SIP: imsession Überblick, Initiation eingeordnet Protocol in das Internet-Schichtenmodell aus (Bad09, S.169) Die H.323-SIG dagegen nutzt ausschließlich das verbindungsorientierte und zuverlässige Transportprotokoll TCP. Man kann sich die H.323-SIG als eine Realisierung des D-Kanalprotokolls von ISDN über TCP-Verbindungen vorstellen. Dies erläutern wir in Abschnitt II. SYSTEMARCHITEKTUR 6.2 näher. Mit RTP werden sog. RTP-Pakete gebildet (s. Abb ), in denen verschiedene Echtzeitmedien bei VoIP Sprache als sog. Payload (Nutzlast) enthalten sind. Die RTP-Pakete werden dann während einer Session mit Hilfe eines wichtigsten enthaltenen Elemente vorgestellt. Transportprotokolls über IP-Netze transportiert. RTP nutzt standardmäßig das verbindungslose Transportprotokoll UDP. Da UDP keine Überlastkontrolle beim Transport von Echtzeitmedien über IP- Netze ermöglicht, wurde das neue verbindungslose Transportprotokoll DCCP (Datagram Congestion Control Protocol) entwickelt und in RFC 4340 (März 2006) spezifiziert. DCCP kann für den Transport von RTP-Paketen mit Echtzeitmedien und von RTCP-Paketen mit Kontrollinformationen verwendet werden. Den Einsatz von RTP und von RTCP über DCCP beschreibt der Internet- Draft draft-ietf-dccp-rtp-07, der bereits als RFC zur Veröffentlichung übergeben wurde. Im Folgenden werden die Systemarchitektur und die SIP arbeitet nach dem Client-Server-Modell. Der Server bietet dabei einen Dienst an und dieser kann von Clients in Anspruch genommen werden. Das Endgerät eines Nutzers wird als User-Agent (UA) bezeichnet und stellt eine Software- oder eine Hardwarekomponente dar (TW15, S.133). Abhängig von der eingenommen Falls es nötig ist, Echtzeitmedien über eine zuverlässige virtuelle Verbindung über ein IP-Netz zu transportieren, können RTP und RTCP hierfür das zuverlässige und verbindungsorientierte Transportprotokoll TCP verwenden. 2 Da TCP eine Ende-zu-Ende-Fehlerkontrolle zur Verfügung stellt, ist die Funktion von RTCP nicht mehr nötig, sodass bei RTP über TCP das Protokoll RTCP H.323-SIG über TCP Standardmäßig RTP über UDP RTP über DCCP RTP über TCP

2 2 DIE INTERNET-PROTOKOLLWELT, WINTERSEMESTER 2016/17 Rolle ist es im Falle des Anrufers der User-Agent- Client (UAC) und als Angerufener der User-Agent- Server (UAS) (RSC + 02, S.18). Die folgenden, in Abbildung 2 dargestellten, Netzwerkelemente bzw. Serverdienste werden für den mobilen Einsatz von SIP benötigt, also für den Fall, dass diese Teilnehmer ihr Heimatnetz verlassen und anschließend in einem Fremdnetz erreichbar sein sollen. Ebenfalls sind die Netzwerkelemente im stationären Einsatz nötig, wenn dem Internet-Anschluss regelmäßig wechselnde IP-Adressen zugewiesen werden. Dabei bleibt die Domain in der ständigen SIP-URI identisch, aber das SIP-Endgerät ist anschließend über eine andere IP- Adresse erreichbar (TW15, S.135). Dadurch ändert sich die temporäre SIP-URI und muss beim Registrar-Server erneut registriert werden. Ein weiterer Vorteil der Server außerhalb des eigenen Netzes ist die Möglichkeit der Umgehung der Network-Address-Translation (NAT) - Problematik. Bei dieser erhält der Client keine Anfragen von außen, da der Router Anfragen von außen nicht zuweisen kann und verwirft. Auf spezielle Techniken, wie das Session-Traversal-Utilities-for-NAT (STUN), welches nur mit UDP zusammenarbeitet, das Inter-Asterisk-eXchange (IAX), das ALG (Application- Layer-Gateways) oder das von der IETF entwickelte Interactive-Connectivity-Establishment (ICE), soll aus Gründen des Umfangs dieser Arbeit nicht eingegangen werden (FS16, S.208) (TW15, S.307ff). A. SIP-Proxy-Server Das zentrale Element bei der Kommunikation mit Nutzern, welche sich in verschiedenen Domains befinden, ist der SIP-Proxy-Server. Dieser ist am Auf- und Abbau einer SIP-Verbindung maßgeblich beteiligt und leitet SIP-Anfragen z.b. vom UAC zu einem weiteren Proxy-Server in der Domain des Ziel-UAS weiter (Sie13, S.365). Unterschieden wird zwischen Statelessund Stateful-Proxy-Servern. Ersterer ist ansatzweise vergleichbar mit einem Repeater, der eintreffende SIP- Nachrichten an ein weiteres Gerät weiterleitet und keine Verbindungsinformationen speichert (RSC + 02, S.116). Ein Stateful-Proxy-Server ist hingegen in der Lage eigene SIP-Nachrichten (z.b. Bestätigungen) zu erstellen und kann sich durch ein Log auf vergangene und bearbeitete SIP-Anfragen beziehen bzw. weitergeleitete Nachrichten bei Bedarf wiederholt senden. Möglich ist dies, da dieser Proxy-Server-Typ für jede eintreffende Anfrage eine SIP- Transaktion erstellt (RSC + 02, S.105). B. Redirect-Server Dieser Server kann zur Entlastung eines SIP-Proxy- Servers zur Anwendung kommen, indem er Rufumleitungen durchführt. Es ist ein logisches SIP-Netzelement und kann auf einem Endgerät eines Nutzers (UA) integriert werden. Ankommende SIP-Anfragen können so beispielsweise auf ein weiteres Gerät, wie z.b. auf einen zentralen Anrufbeantworter oder einen weiteren Nutzer, umgeleitet werden (TW15, S.201). C. Registrar-Server Der Registrar-Server ist für die Endgeräte- und Ortsunabhängigkeit eines Nutzers notwendig. Die ständige SIP-URI wird mit der temporären Adresse verbunden, indem sich der UAC des Nutzers bei dem Registrar- Server der Heimat-Domain per Register-Anfrage meldet (RSC + 02, S.16). Das Prinzip ähnelt dem Dynamischen- DNS (DDNS) -Verfahren (Sie13, S.102). Bei diesem Verfahren wird den Internet-Anschlüssen von Endkunden bei jeder Einwahl eine andere IP-Adresse zugewiesen, welche periodisch dem DDNS-Anbieter mitgeteilt wird. Dadurch kann gewährleistet werden, dass eine Domain immer mit einem Heimatnetz verknüpft wird, auch wenn sich dessen IP-Adresse häufig ändert. Vom Registrar- Server wird die Anfrage REGISTER mit 200 OK dem UAC bestätigt und an den Location-Server weitergeleitet. Der Server kann in integrierten Umgebungen auch im Proxy- oder Redirect-Server betrieben werden (Bad09, S.304). D. Location-Server Ein Location-Server besitzt eine Datenbank (DB) und stellt diese anderen Servern zur Verfügung. In dieser DB werden die Benutzer mit ihrer ständigen SIP-URI vermerkt, welche mit der jeweiligen temporären SIP-URI verbunden wird (RSC + 02, S.13). Es ist kein SIP-Netzelement, da die Kommunikation zwischen Registrar- bzw. Proxy-Server nicht mit SIP-Nachrichten, sondern z.b. über das Lightweight-Directory-Access- Protocol (LDAP) oder die Diameter-Applikation stattfindet (Cam01, S.106) (BPLCVT06, S.3). Häufig wird in kleineren Netzen der Location-Server direkt im SIP- Proxy- bzw. Registrar-Server integriert und ist nicht alleinstehend. E. SIP-Applikation-Server Die SIP-Applikation-Server (SIP-AS) sind normalerweise ortsfest und stellen u.a. Dienste zur Verfügung, die aus der Telefonie bekannt sind. Als Anwendungen kommen beispielsweise Streaming-Server für Audio- und Videoinhalte oder Anrufbeantworter, welche auch Voice- Mail-Server genannt werden, infrage (Bad09, S.301).

3 GEORG ROLAPP: SESSION INITIATION PROTOCOL 3 User-Agent I (UA) 4. Query & Response Location-Server 2. Registration User-Agent-Client (UAC) User-Agent-Server (UAS) 3. Invite SIP-Proxy-Server Registrar-Server 5. Invite Internet SIP-Applikation-Server (SIP-AS) 1. Registration Redirect-Server User-Agent-Server (UAS) User-Agent-Client (UAC) Telefonnetz/ PSTN User-Agent II (UA) VoIP-Gateway Abbildung 2. Auswahl von SIP-Netzwerkelementen mit vereinfachten Verbindungsaufbau in Anlehnung an (Tut17) F. SIP-Adressen Die Adressierung bei SIP wird durch die Uniform-Ressource-Identifier (URI) umgesetzt. Die Funktion ist vergleichbar mit einer Telefonnummer. Eine SIP-URI kann auch eine Telefonnummer zu Benutzeridentifizierung enthalten, über die der Nutzer mittels VoIP-Gateway in traditionellen Telefonnetz erreichbar ist (Sei06, S.301). Der Nutzeridentifikation wird, vergleichbar mit - Adressen, noch der jeweilige Host, also die IP-Adresse bzw. der Domainname z.b. des Providers oder des jeweiligen Unternehmens angehängt. Da sich IP-Adressen abhängig vom verwendeten Netzwerk ändern können und diese von Menschen schlecht zu merken sind, wird üblicherweise für sogenannte ständige SIP-URIs ein Domainname verwendet. Dieser Name wird von SIP-Netzelementen durch das Domain-Name-System (DNS) mit der gültigen IP-Adresse verbunden (RSC + 02, S.13). Die temporären SIP-URIs gibt es dennoch, da jedem Gerät im Internet eine IP-Adresse zugewiesen wird. Eine temporäre SIP- URI hat bspw. das Format SIP:Nutzer@ipv4adresse (Beispiel: SIP:alice@ ). Dementsprechend hat eine ständige SIP-URI das Format SIP:Nutzer@domain (Beispiel: SIP:alice@xyz.de ). Neben diesen zur Verbindungsherstellung essentiellen Informationen können optional auch Parameter, wie das zu verwendende Transportprotokoll oder Verschlüsselungsparameter angefügt werden (TW15, S.135). Sobald SIP das Transport-Layer-Security (TLS) Protokoll nutzt, wird ein verbindungsorientiertes Transportschichtprotokoll, wie z.b. TCP, verwendet. Diese SIP-Variante wird auch als Secure-SIP (SIPS) bezeichnet, welches bedingt, dass am Anfang einer SIP-URI SIPS: steht und nicht mehr SIP: (Bad09, S.279). G. SIP-Nachrichten Die SIP-Nachichten lassen sich in Requests und Response, also Anforderungen und Antworten unterteilen. Eine Auswahl von Request-Typen ist in Tabelle I zusammengestellt. Die insgesamt sechs Response-Klassen werden benutzt, um Anfragen zu beantworten. Dabei beginnen die Antworten immer mit einer dreistelligen Zahl, bei der die erste Ziffer zur Einordnung in die jeweilige Klasse dient. Positive Anfragen werden dabei mit 1xx oder 2xx beantwortet. Wenn ein Request nicht akzeptiert werden kann, wird ein 3xx, 4xx, 5xx oder 6xx Response gesendet (RSC + 02, S.77). Eine Auswahl der Klassen sind in Tabelle II zu sehen. Eine vollständige SIP-Nachricht ist textbasiert nach UTF-8-Codierung und zeilenweise aufgebaut (RSC + 02, S.25). Sie besteht aus einer Start-Line, einem Message-Header und einem Message-Body, wobei letzterer optional ist und durch SDP beschrieben wird. III. PROTOKOLLMECHANISMEN In diesem Kapitel wird auf den Ablauf der Kommunikation zwischen den SIP-Netzwerkelementen durch Verwendung der SIP-Nachrichten eingegangen.

4 tur hatten. Aus dem SIP-Verlauf zwischen zwei IP-Telefonen in verschiedenen Domains kann unmittelbar der SIP-Verlauf zwischen zwei IP-Telefonen innerhalb einer Domain abgeleitet werden. Abbildung DIE INTERNET-PROTOKOLLWELT, WINTERSEMESTER 2016/17 illustriert diesen SIP-Verlauf. Request-Typ INVITE BYE ACK Register OPTIONS Response-Klasse Provional Successful Client Error Server Error Tabelle I AUSWAHL VON REQUEST-TYPEN I E F = E? den A ( = > A + 02, S.11) (Bad09, S.293). Ein SIP-Proxy- I E F > > ( = A H N O, = E = A ) Server E? A wird in diesem Fall nicht benötigt. Sollte die * > Beschreibung SIP-URI jedoch neben 6 Hder O E Nutzeridentifikation C 5 A I I E ) K B > = K nur die Der Sitzungsinitiator lädt die Gegenstelle zu & 4 E C E C & 4 E C E C E C A Domain-Kennung beinhalten, ist ein SIP-Proxy-Server einer SIP-Sitzung ein. Die INVITE-Nachricht. H A E J enthält die SIP-URI des Absenders und des notwendig. ) + Wie in Abbildung 3 zu sehen ist, sendet Ziels sowie eine Sitzungsbeschreibung nach der Sitzungsinitiator 5 A I I E (Alice) = I 8zu 1 2Beginn 8 A H > E K CINVITE- ) K B C A A C J SDP wie unterstützte die Medienformate zur Nachricht * ; an- den Empfänger Bob und lädt diesen zu Gewährleistung der Kompatibilität (HSSR99, 5 A I I E ) > > = K einem Gespräch ein. Sofern sein Telefon/PC erreichbar S.14). Sobald ein Sitzungsteilnehmer eine Sitzung ist, sendet dieses/er eine 180 Ringing -Nachricht an Abb : SIP-Verlauf beim Auf- und Abbau einer Session innerhalb einer Domain beenden möchte, sendet er eine BYE-Nachricht Alice, woraufhin Alice einen Freiton hört. Außerdem wodurch der Sitzungsabbau eingeleitet wird. wird nun dem Nutzer Bob durch Klingeln mitgeteilt, Mit dem Senden der Bestätigung ACKSIP-Verlauf bestätigt der Initiator seinem Gegenüber, dass dass ohne eineproxy Einladung zu einem Gespräch eingegangen der Verbindungsaufbau abgeschlossen ist Falls und die beiden ist. Sobald IP-Telefone diesermit essip-uris annimmt, sip:user@ipv4address wird eine 200 OK - also nun die Multimedia-Daten übertragen werden, mit der Angabe Nachricht von IP-Adressen an Alice gesendet der Rechner undmit den Soft-IP-Telefonen Erhalt bestätigt adressiert werden, Alice verläuft wiederum Auf- mit und einem Abbau Acknowledgement einer Session, wie Abbildung (ACK) siehe auch 3 (RSC + 02, S.129). Der UAC meldet seine aktuelle temporäre zeigt, direkt IP-Adresse beim Registrar-Server (RSC + Die zwischen Audioübertragung den betreffenden viarechnern, RTP wirdohne nuneinen gestartet SIP-Proxy. und 02, S.56). Bei der Nutzung bleibt von so lange SIP-URIs bestehen, mit der bis Form einer sip:user@ipv4address der Teilnehmer das bzw. Ein SIP-Endgerät kann über diese Anfrage sip:user@hostname Gespräch beendet müssen keine und dies SIP-Proxies dem jeweils eingesetzt Anderen werden. per Diese Art nach den unterstützen Medientypen (Audio, von SIP-URIs BYE -Nachricht eignet sich daher signalisiert. für VoIP-Anwendungen Nach einer in Bestätigung kleinen Firmen oder Video) und die jeweiligen Kodierverfahren in privaten abgefragt werden (RSC + 02, S.68). durch Home-Networks. eine 200 OK -Nachricht ist die Sitzung beendet. Tabelle II AUSWAHL VON RESPONSE-KLASSEN A. Kommunikationsablauf 1) Verbindungsaufbau ohne Proxy-Server: Der einfachste Fall für den Einsatz von SIP zum Verbindungsaufbau liegt vor, wenn sich beide Teilnehmer einer Sitzung in dem identischen Netzwerk befinden und temporäre SIP-URIs benutzen, siehe Abbildung 3. Sollten sich Hostnamen in den SIP-URI befinden, würden diese von einem DNS-Server aufgelöst wer- ) E? A * > I E F = E? A ( # $ I E F > > (!. H A E J E C A Beschreibung & 4 E C E C 5 A I I E Der Sitzungsinitiator wird bei diesen Antworten über die Weiterbearbeitung seiner Anfrage ) K B > = K ) + ) > C A D > A informiert. Bespiele: 100 Trying, 180 Ringing (RSC + 02, S.182) 5 A I I E * ; - 5 A I I E = I A H > K ) K C B C A A C J Das Ziel eines Request teilt dem Absender mit, ) > > = K das dieses akzeptiert wurde. Wie in Abbildung 3 zu sehen ist, wird es z.b. gesendet sobald Abb : am SIP-Verlauf Abbildung zwischen 3. SIP-Verlauf zwei IP-Telefonen ohne Proxy-Server ohne SIP-Proxy aus (Bad09, zu nutzen S293) Zielgerät der Hörer abgenommen wurde. Beispiele: 200 OK, 202 Accepted (RSC + 02, S.183) 2) Verbindungsaufbau mit Proxy-Server: Diese Fehlermeldung teil dem Absender mit, In der Abbildung 2 ist bereits durch die orange gepunkteten und gestrichelten und beschrifteten Pfeile der dass die Syntax der Anfrage falsch ist oder vom SIP-Server nicht verarbeitet werden kann. mögliche Ablauf eines Verbindungsaufbaus zwischen Beispiele: 400 Bad Request, 406 Not Acceptable (RSC + 02, S.129) zwei SIP-Teilnehmern mittels SIP-Proxy-Server zu sehen. Zur Vereinfachung wurde der zweite Proxy-Server Hierbei wird dem Absender mitgeteilt, dass der SIP-Server nicht in der Lage ist, die Anfrage in Abbildung 2 nicht dargestellt, dafür aber in der Abb. 4. auszuführen. Der Unterschied zum Client Error ist, dass das Problem serverseitig besteht Die regelmäßige Registrierung der UAs beim Registrarund es nicht am Client liegt. Beispiele: 500 Server ist in Abb. 2 im Schritt 1 und 2 dargestellt. In beiden Abbildungen beginnt ein UAC den Sitzungsaufbau, Internal Server Error, 501 Not Implemented (RSC + 02, S.28). indem an den SIP-Proxy-Server der eigenen Domain eine INVITE-Nachricht mit der ständigen SIP-URI gesendet wird (Kan05, S.130). Die zugehörige INVITE-Nachricht ist auch in Tabelle III mit abweichenden Bezeichnungen dargestellt. Nachdem der erste Proxy-Server mittels DNS die IP-Adresse der Ziel-Domain ermittelt hat, wird die INVITE-Nachricht an den zweiten Proxy-Server und von diesem an den Ziel-UAS gesendet. Jede erfolgreiche Weiterleitung wird mittels 100 Trying -Nachricht an das jeweilige vorherige Gerät bestätigt. Mittels 180 Ringing -Nachricht wird den an der Sitzung beteiligten

5 4.3 Normalruf Der GEORG hier geschriebene ROLAPP: Normalruf SESSION besteht INITIATION aus dem Verbindungsauf- PROTOCOLund -abbau und erfolgt 5 zwischen den Teilnehmern "Leon" (UAC) und "Leonie" (UAS), wobei die Teilnehmer zu zwei verschiedenen Verwaltungsbereichen gehoren. Leon ist dem Verwaltungsbereich "mars.net" und Leonie dem Verwaltungsbereich,jupiter.net" zugeordnet. Eine erfolgreiche Registrierung der beiden Teilnehmer ist dem Normalruf bereits vorausgegangen, so dass Geräten die Teilnehmer signalisiert, in ihren Verwaltungseinheiten dass das Ziel-UAS dem jeweiligen den SIP-Proxy-Server Ruf annimmt und es auf sich z.b. durch Klingeln aufmerksam bekannt sind. Nach erfolgreichem Verbindungsaufbau unterhalten die Teilnehmer eine Sprachverbindung. AnschlieBend wird yom gerufenen Teilnehmer "Leonie" die Verbindung macht. wieder ausgelost. Der Initiator hört nun ein Freizeichen. Sobald der Angerufene den Hörer abnimmt, wird mittels 200 OK -Nachricht dies an den Initiator weitergeleitet, der Das denbild Empfang 4.5 zeigt den mit Nachrichtenablauf einer ACK -Nachricht eines Normalrufes. Die einzelnen bestätigt. Phasen Die der Rufverarbeitung sind in der Tabelle 4.3 aufgeftihrt. Multimedia-Sitzung per RTP wird nun gestartet. Nach Tabelle 4.3 Phasen der Rufverarbeitung erfolgter Sitzung wird die Terminierung von einem der Schritte der Rulverarbeitung Nr. der in Kapitel Verbindungsaufbau Teilnehmer durch Senden der BYE -Nachricht 1-14 eingeleitet und wiederum durch 200 OK bestätigt. Die Sitzung Obermittlung der Mediainformationen mit SOP (offer) 1,2,4 Obermittlung der Mediainformationen mit SOP (answer) 9, 10, 11 Aktive ist nun Verbindung ordnungsgemäß zwischen Leon und Leonie abgebaut zwischen (Kan05, 14 und 15 S.129ff) Nachrichtenablauf - Normalruf Verbindungsabbau Leon (sip:leon@mars.net) (Domain: mars. net) (Domain: jupiter.net) Leonie (sip:leonie@jupiter.net) I UAC I I SIP Prox Server I I Slp Prox Server I I UAS I Bild 4.5 Normalruf Abbildung 4. S.129) 1: INVITE 2: INVITE 3: 100 Trying 4: INVITE 5: Trying 6: 180 RinginQ 8: 180 Ringing 7: 180 Ringing 9: 200 OK 10: 200 OK 11:2000K 12: ACK 13: ACK 14: ACK.,.._._._._._._. RTP Media Session r'-'-'-'-'-'-'-._._._._._._ : BYE 18: 200 OK 16: BYE 19: 200 OK 15: BYE 20: 200 OK SIP-Nachrichtenablauf mit Proxy-Server aus (Kan05, IV. BEWERTUNG Eine Alternative zu SIP ist zumindest für die Anwendung Telefonie, wie in der Einleitung beschrieben, der Standard H.323. Da hinter H.323 die ITU-T steht, ist es nicht verwunderlich, dass dabei versucht wurde, das Telefonnetz internet-kompatibel zu machen. Sogenannte Gatekepper verwalten dabei die Zuordnung von IP-Adressen zu Telefonnummern, die Endgeräteregistrierung und verarbeiten außerdem Verbindungswünsche (TW15, S.108). Das bedeutet, dass ohne einen Gatekeeper keine Telefonie möglich ist, weshalb er redundant ausgelegt sein sollte. Ein Vorteil, der für SIP spricht, ist, dass für eine Verbindung zwischen zwei Nutzern außer der vorhandenen Infrastruktur des Internets keine weiteren Server benötigt werden, wenn die temporäre SIP-URI des Zielgerätes bekannt ist (Bad09, S.295). Wie bei SIP wird auch bei H.323 ein VOIP-Gateway benötigt, sollen Anrufe in das traditionelle Telefonnetz (Public-Switched- Telephone-Network (PSTN)) führen (Bur91, S.35). Unabhängig von SIP und H.323 werden VoIP-Gateways allgemein auch Media-Gateways (MG) genannt. Sobald sie leitungsvermittelte Telefone bzw. PSTNs über ein Tabelle III BEISPIEL EINER SIP-INVITE-NACHRICHT AN BOB@XYZ.DE ÜBER PROXY-SERVER AUS (BAD09, S.291) SIP-Nachricht Beschreibung Start-Line INVITE sip:bob@xyz.de SIP/2.0 Request-Typ, Ziel-URI, SIP- Version Message-Header Via: SIP/2.0/UDP sonne.abc.de SIP-Version/Transportprotokoll Absender-URI ;branch =z9hg4bknashds9 Transaktion-ID Route: <sip:nodel-sps.abc.de;lr> Proxy-Server von abc.de- Domain Max-Forwards: 70 max. Anzahl der zu nutzenden Proxy-Servern To: Bob<sip:bob@xyz.de> Ziel der Session - Empfänger- URI From: Alice <sip:alice@abc.de> Absender - Initiator-URI ;tag= Call-ID: a64b5431@sonne.abc.de Identifikation des Anrufs Cseq: 123 INVITE Sequenz-Nr. der Einladung Contact: <sip:alice@abc.de> Kontakt zum Initiator Content-Type: application/sdp Typ des Body-Inhalt Content-Length: 152 Länge des Body Body Beschreibung der Session (SDP) V=0 Session-Level o=alice Username Session-ID IN IP4 sonne.abc.de Netztyp: IN = Internet, Adresstyp s=schoene Gruesse Session Name c: INIP4sonne.abc.de t=0 0 zeitlicher Session Beginn: hier direkt nach dem Aufbau; Ende: jederzeit m=audio RTP/AVP 0 Media-Typ Ziel-Port-Protokoll: 0 = PCM a=rtpmap: 0 PCM/8000 Beschreibung des Media-Typ Codec/Port IP-Netz miteinander koppeln, müssen die Sitzungen zwischen den MGs gesteuert werden (Bad09, S.358f). Die Steuerung übernehmen Media-Gateway-Controller (MGC), unter Nutzung des Media-Gateway-Control- Protokolls (MGCP) oder seinem Nachfolger das Media-Gateway-Control (Megaco). Megaco beinhaltet Verbesserungen zu MGCP, wurde von der ITEF und der ITU-T gemeinsam entwickelt und als RFC3525 bzw. H.248 veröffentlicht (GPA03, S.1). Die Kommunikation verläuft bei Megaco wie auch bei SIP und H.323 über RTP (GPA03, S.80). Megaco ist außerdem wie SIP transportprotokollunabhänig und nutzt UDP oder TCP für die Übertragung der Protokollnachrichten (GPA03, S.149). Vorteilhaft für SIP ist die Ähnlichkeit zu anderen Internetprotokollen, wie dem Hypertext-Transport- Protocol (HTTP) und der modularen Architektur.

6 6 DIE INTERNET-PROTOKOLLWELT, WINTERSEMESTER 2016/17 Dadurch lässt es sich in Internet-Browsern und Webdiensten integrieren (HSSR99, S.8). Die Komplexität von SIP ist im Vergleich zu dem 1996 in erster Version erschienen H.323 wesentlich geringer. Da SIP auf der Transportschicht, anders als H.323, TCP und bevorzugt UDP verwenden kann, ist es durch den dabei entfallenden Verbindungsaufbau im Vergleich schneller (Bad09, S.275). Für SIP spricht auch die Möglichkeit der nomadischen Nutzung. Dies bedeutet, dass ein Nutzer innerhalb der eigenen (DNS-) Domain jeden PC als IP-Telefon nutzen kann (Bad09, S.295). Diese Domain kann sich über das ganze Internet erstrecken. Interessant ist auch die Möglichkeit der Anrufverzweigung (Bad09, S.299). Dabei registriert sich ein Nutzer bei mehreren Geräten gleichzeitig und auf Wunsch klingeln die Telefone im Büro, im Arbeitszimmer zu Hause und das Mobiltelefon bei Eingang eines Anrufs zeitgleich. SIP unterstützt die von der Telefonie z.b. im ISDN-Netz bekannten Dienstmerkmale (Supplementary-Services), wie Anrufumleitung und -weiterleitung, Halten einer Verbindung oder Wahlwiederholung (SCDS08, S.153). Auch Konferenzen sind über SIP kein Problem (SCDS08, S.101). Anders als H.321 ist auch Instant- Messaging durch SIP realisierbar (SCDS08, S.70). Als Internetprotokoll unterstützt SIP natürlich auch die Click-to-Dial-Funktion. Diese ermöglicht es, dass eine auf einer Webseite vorhandene SIP-URI, durch einfaches Anklicken vom zugeordneten Telefon gewählt wird (SCDS08, S.162). Obwohl H.323 und SIP in Konkurrenz stehen, ist eine Koexistenz möglich, da die Signalisierung von H.323 als ISDN-D-Kanal-Protokoll-Implementierung angesehen wird und SIP das ISDN-D-Kanal-Protokoll ansprechen kann (Bad09, S.353). V. ZUSAMMENFASSUNG UND AUSBLICK Das zur Signalisierung von Multimediadiensten im Internet entwickelte Session-Initiation-Protocol wird heute als Standardprotokoll für VoIP-Anwendungen genutzt. SIP wurde durch seine Offenheit und Flexibilität immer weiter erweitert, so dass es heute über 100 RFC-Beiträge dazu gibt. Die Client-Server-Struktur erlaubt eine beliebige Skalierung und Erweiterbarkeit abhängig von den angeboten Diensten und Nutzerzahlen. Der schrittweise Wechsel von leitungsvermittelten Telefonnetzen zu den effizienteren paketvermittelten IP- Netzen wird durch ausgereifte Protokolle wie SIP ermöglicht. Durch die Nutzung von Qualitiy-of-Service- Techniken durch die Netzbetreiber lässt sich eine vergleichbare und durch ausgefeilte Codierungen qualitativ höherwertige Sprachqualität erreichen (TW15, S.43). Eingesetzt wird SIP auch in den Next-Generation- Networks (NGN) -Mobilfunknetzstandards des 3rd- Generation-Partnership-Projects (3GPP) ab dem Release 5 im Universal-Mobile-Telecommunications-System (UMTS) und dem Folgestandard Long-Term-Evolution (LTE) mit dem Release 8 (TW15, S.453ff). Dieser allgegenwärtige Einsatz von SIP zeigt, dass es derzeit und auch in der Zukunft eine große Rolle bei Multimediaübertragungen in IP-Netzen spielen wird. LITERATUR [Bad09] BADACH, Anatol: Voice over IP - Die Technik. Hanser Fachbuchverlag, ISBN [BPLCVT06] BELINCHON, M. ; PALLARES-LOPEZ, M. ; CANALES-VALENZUELA, C. ; TAMMI, K. ; GARCIA-MARTIN, M. (Hrsg.): Diameter Session Initiation Protocol (SIP) Application. Version: nov RFC Editor, nov [Bur91] BURR, William E.: Security in ISDN. Version: National Institute of Standards and Technology (NIST), [Cam01] CAMARILLO, Gonzalo: Sip Demystified. MCGRAW HILL BOOK CO, ISBN [FS16] FISCHER, Jörg ; SAILER, Christian: VoIP Praxisleitfaden [GPA03] GROVES, C. ; PANTALEO, M. ; ANDERSON, T. ; TAYLOR, T. (Hrsg.): Gateway Control Protocol Version 1. Version: jun RFC Editor, jun [HSCFJ96] H. SCHULZRINNE and ; CASNER, S. ; FREDERICK, R. ; JACOBSON, V.: RTP: A Transport Protocol for Real-Time Applications. Version: jan RFC Editor, jan [HSSR99] HANDLEY, M. ; SCHULZRINNE, H. ; SCHOOLER, E. ; ROSENBERG, J.: SIP: Session Initiation Protocol. Version: mar

7 GEORG ROLAPP: SESSION INITIATION PROTOCOL 7 RFC Editor, mar [Kan05] KANBACH, Andreas: SIP - Die Technik: Grundlagen und Realisierung der Internet-Technik. Vieweg+Teubner Verlag, ISBN [RSC + 02] ROSENBERG, J. ; SCHULZRINNE, H. ; CAMARILLO, G. ; JOHNSTON, A. ; PETERSON, J. ; SPARKS, R. ; HANDLEY, M. ; SCHOOLER, E.: SIP: Session Initiation Protocol. Version: jun RFC Editor, jun [SCDS08] SPARKS, R. ; CUNNINGHAM, C. ; DONOVAN, S. ; SUMMERS, K. ; JOHNSTON, A. (Hrsg.): Session Initiation Protocol Service Examples. Version: oct RFC Editor, oct [Sei06] SEITZ, Jochen: Digitale Sprach- und Datenkommunikation. Hanser Fachbuchverlag, ISBN [Sie13] SIEGMUND, Gerd: Technik der Netze, Band 2. Vde Verlag GmbH, /gerd_siegmund_technik_der_ netze_band_2.html. ISBN [Tut17] TUTORIALSPOINT: SIP - Network Elements. com/session_initiation_protocol/images/ location_server.jpg. Version: letzter Stand: [TW15] TRICK, Ulrich ; WEBER, Frank: SIP und Telekommunikationsnetze. Gruyter, de Oldenbourg, ISBN