Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3-8276-9142-2 SIP Guide Session Initiation Protocol Guide Das Session Initiation Protocol (SIP) wurde ursprünglich als Signalisierungsprotokoll für Voice over IP (VoIP) konzipiert, d.h. als Protokoll, nach dem die als Sessions bezeichneten virtuellen Verbindungen nach dem Realtime Transport Protocol (RTP) als eine Art virtueller Telefonverbindungen zuerst aufgebaut, dann während ihrer Nutzung in ihren Funktionen überwacht und schließlich abgebaut werden können. Als das SIP in der ersten Version im März 1999 in RFC 1 2543 veröffentlicht wurde, hätten dessen Entwickler nicht zu träumen gewagt, dass jenseits reiner VoIP-Anwendungen eine sehr breite Palette verschiedener audiovisueller Anwendungen wie Instant Messaging, Presence Services, diverse Event Notification Services usw. auf dem SIP basieren würden. Bereits drei Jahre später, im Juni 2002, wurde eine neue und erweiterte SIP-Kernspezifikation als RFC 3261 veröffentlicht. Seitdem wurden etliche SIP betreffende Internetstandards entwickelt und in Form von RFCs von der Internet Engineering Task Force (IETF) veröffentlicht. Neben dem Hypertext Transfer Protocol (HTTP) ist das SIP heute das wichtigste Anwendungsprotokoll im Internet. Zurzeit gibt es bereits über 200 RFCs, die das SIP in irgendeiner Weise betreffen. Sich in diesem großen Wald von Standards zurechtzufinden ist nicht einfach; aus diesem Grund ist eine Art SIP Guide unabdingbar. Dieser dient sowohl dazu, die SIP- Themengebiete zu benennen und kurz zu beschreiben, als auch dazu, einzelnen Themengebieten die ihnen entsprechenden Standards zuzuordnen. Das Ziel dieses Beitrags ist es, einen solchen SIP Guide zu präsentieren. Im hier vorgestellten Guide werden alle Anwendungs- bzw. Problembereiche des SIP, also dessen Themengebiete, zu zwölf Schwerpunkten zusammengefasst. Sie könnten der Anschaulichkeit halber als Stunden eines besonderen Uhrmodells hier als SIP-Uhrmodell (SIP Clock Model) bezeichnet angesehen werden. In diesem Bei- 1 Request for Comments 1
trag wird jedes SIP-Themengebiet, also jede Stunde des SIP- Uhrmodells, kurz charakterisiert. Die ihm entsprechenden, SIP betreffenden RFCs werden in Form von Grafiken dargestellt und kurz erläutert. SIP-Themengebiete als Stunden im SIP-Uhrmodell Die Möglichkeiten des Einsatzes des SIP sind so breit, dass das Protokoll kontinuierlich fortentwickelt und ständig um neue Funktionen erweitert wird. Um eine fundierte Übersicht über alle Aspekte des Protokolls zu geben, werden hier die SIP-Funktionen bzw. -Probleme entsprechend themenspezifisch gruppiert und mit dem SIP Core Concept (Kernkonzept) im Zentrum in Bild 007381 dargestellt. Bild 007381: SIP-Themengebiete als SIP-Uhrmodell dargestellt 3GPP: Third Generation Partnership Project ISDN: Integrated Services Digital Network NAT: Network Address Translation PSTN: Public Switched Telephone Network URI: Uniform Resource Identifier SIP-Themengebiete und ihre RFCs Das weite Spektrum an SIP-Einsatzmöglichkeiten zur Realisierung verschiedener Services hat zur ständigen Weiterentwicklung des SIP geführt. Dies belegt die Anzahl der auf allen SIP-Themengebieten 2
spezifizierten RFCs. Bild 007382 zeigt die Auflistung aller relevanten RFCs und deren Zuordnung zu einzelnen SIP-Themengebieten. Bild 007382: SIP-Themengebiete und ihre RFCs Zum besseren Verständnis der aufgelisteten RFCs soll im Folgenden kurz auf die Grundlagen des SIP eingegangen werden. SIP Core Concept Trapezoid-Modell Der grundlegende Verlauf des SIP beim VoIP kann wie im folgenden Bild in Form eines Trapezoids dargestellt werden. Es sei angemerkt, dass man bei SIP-Nachrichten zwischen Requests und Responses, also Antworten auf Requests, unterscheidet. 3
Bild 007383: Grundlegender SIP-Verlauf beim VoIP im Trapezoid- Modell A-P: E-P: Ausgangs-Proxy Eingangs-Proxy Als erste SIP-Nachricht wird vom Telefon des Anrufenden zuerst über den Ausgangs-Proxy und dann über den Eingangs-Proxy der Request INVITE an das Telefon des Angerufenen übermittelt. Der Empfang von INVITE wird von jedem Proxy jeweils mit der Response 100 Trying bestätigt. Hat INVITE das Telefon des Angerufenen erreicht, wird dem Angerufenen der ankommende Anruf durch ein Klingeln signalisiert und dieses dem Telefon des Anrufenden mit der Nachricht 180 Ringing angezeigt. Das Abheben des Hörers beim Angerufenen wird dem Telefon des Anrufenden mit der Nachricht 200 OK(ay) signalisiert. Dieses Telefon bestätigt dies mit der Nachricht ACK, die direkt also nicht über Proxies an das Telefon des Angerufenen übermittelt wird. Der Aufbau einer VoIP-Verbindung wird mit BYE initiiert. Die Gegenseite bestätigt BYE mit 200 OK. Anmerkung: Für eine gut illustrierte Darstellung typischer SIP-Verläufe und der Struktur von SIP-Nachrichten sei verwiesen auf: http://www.in2eps.com/fo-sip/tk-fo-sip-ex3261.html http://www.in2eps.com/fo-sip/tk-fo-sip-service-01.html Aufbau von SIP-Nachrichten Das folgende Bild zeigt den Aufbau von SIP-Nachrichten, d.h. sowohl Requests als auch Responses. Diese sind textbasiert und zeilenweise aufgebaut. Jede SIP-Nachricht setzt sich aus einer Start- Zeile, einem Message Header und einem Message Body zusammen. 4
Der Message Body ist optional, ausgenommen der Request INVITE, in dem als Body die Beschreibung der initiierten Session nach dem Session Description Protocol (SDP) enthalten ist. In der Startzeile von Requests ist deren Typ als Angabe Method enthalten. Daran erkennt man, ob es sich um einen Request oder Response handelt. Bild 007384: Aufbau von SIP-Nachrichten: a) Request, b) Response URI: Uniform Resource Identifier Struktur von SIP Requests SIP Requests haben die in Bild 007384a dargestellte Struktur. Jeder Request beginnt mit einer Request Line als Start-Zeile, in der folgende Angaben enthalten sind: Method repräsentiert den Request-Typ, wie z.b. INVITE, BYE, ACK, OPTIONS, REFER, UPDATE. Folglich werden oft auch Requests als Methods bezeichnet. Request URI stellt entweder SIP-URI oder SIPS 2 -URI dar. Hier wird die Zieladresse des Request angegeben. SIP-Version mit der Angabe SIP/2.0. Diese Angaben sind jeweils mit Leerzeichen voneinander getrennt. Nach der Request Line werden verschiedene Angaben als sog. Header Fields (HFs) gemacht, die den Message Header bilden. Jedes HF hat seinen Namen, wie z.b. Via, Route, Call-ID, From, To, mit dem auf seine Funktion bzw. Bedeutung hingewiesen wird. Es folgt die Angabe von HF-Werten. Falls nötig, kann sich ein HF über mehrere Zeilen erstrecken. 2 SIPS steht für Secure SIP bzw. für SIP Security. 5
Nach dem Header kann der Message Body kommen, welcher optional ist. Dies symbolisieren in Bild 007384 die Klammern [...]. Der Message Header wird vom Message Body mit einer Leerzeile getrennt. Struktur von SIP Responses SIP Responses werden ähnlich wie SIP Requests zeilenweise aufgebaut und haben die in Bild 007384b dargestellte Struktur. Die Startzeile in Responses wird als Status Line bezeichnet. Der Status-Code in der Status Line beginnt mit der Angabe der SIP-Version, also SIP/2.0, danach kommt eine dreistellige Zahl als Status-Code, mit der die Bedeutung des Response angegeben wird, und abschließend die Bezeichnung des Response im Klartext als Reason-Phrase. Die erste Ziffer im Status-Code gibt an, um welche Response-Klasse es sich handelt. Die Steuerungsangaben im Header von Responses erfolgen zeilenweise ebenso wie in Requests in Form festgelegter Header Fields. Für eine Auflistung aller Header Fields sei verwiesen auf: http://www.iana.org/assignments/sip-parameters/sipparameters.xhtml Message Body als Nutzlast in SIP-Nachrichten Der Message Body stellt eine Art Nutzlast von SIP-Nachrichten dar und kann in einigen Fällen auch einen nach den Konzepten Multipurpose Internet Mail Extensions (MIME) 3 oder Secure MIME (S/MIME) aus mehreren Teilen gebildeten Multipart Body darstellen. Im Message Body können enthalten sein: 3 MIME beschreibt das in RFC 822 spezifizierte Konzept, nach dem E-Mails mit Anhängen strukturiert werden können. Dieses Konzept wurde für SIP übernommen. Im Jahr 2008 wurde RFC 822 allerdings durch RFC 5322 ersetzt. S/MIME ist ein Standard zur Verschlüsselung und Signierung von nach MIME strukturierten E-Mails mittels hybrider Kryptosysteme (vgl. RCFs 1847, 2633, 3851 und 5751). 6
Angaben, die eine Session betreffen Der Aufbau jeder Session wird mit dem Request INVITE initiiert. Daher werden in INVITE als Message Body die Besonderheiten der einzurichtenden Session nach Protokoll SDP spezifiziert. Im Request UPDATE als Body können beispielsweise Angaben gemacht werden, die dazu dienen, die bestehende Session zu modifizieren, d.h. ihre Eigenschaften zu ändern. Angaben, die keine Session betreffen SIP wird auch zur Bereitstellung von Presence Services und E- vent Notification Services verwendet. In diesem Fall können in den Requests MESSAGE, PUBLISH, SUBSCRIBE und NOTIFY Informationen über bestimmte Objekte als Text bzw. XML 4 - Dateien übermittelt werden, die sich nicht auf eine Session beziehen. Multipart Body in SIP-Nachrichten Die breite Palette von SIP-Anwendungen kann u.a. dank der flexiblen Strukturierung von SIP-Nachrichten erreicht werden und dies betrifft sowohl den Header als auch den Body von SIP-Nachrichten. Wie Bild 007385 illustriert, kann der Body nach dem MIME- Konzept aufgebaut werden und aus mehreren Teilen bestehen. Ist das der Fall, wird er als Multipart Body bezeichnet. Es sei hierbei angemerkt, dass man den Inhalt des Body als Content bezeichnet. Falls eine SIP-Nachricht einen Multipart Body enthält, wird darauf am Ende des SIP Header im Header Field Content-Type mit multipart/mixed hingewiesen. In diesem Field wird festgelegt, wie der Beginn einzelner Teile und das Body-Ende sog. boundary bezeichnet wird. Bild 007385a illustriert dies. Bild 007385b verdeutlicht, dass die letzten zwei Fields am Ende des SIP Header den Typ des Message Body und dessen Länge angeben. Eine leere Zeile dient als Grenze zwischen dem SIP Header und dem Body, zwischen zwei Body-Teilen und zwischen den Angaben über den Content (Content-Type, Content-Disposition) und dem Bodynhalt, also dem eigentlichen Content. 4 Extensible Markup Language 7
Bild 007385: SIP-Nachricht mit Multipart Body: a) Bildung des Multipart Body, b) Struktur einer SIP-Nachricht mit zwei Body- Teilen C-T: Content-Type SIP-H: SIP Header SIP Core Extensions Die erste Version des SIP wurde in RFC 2543 mit einem Umfang von ca. 150 Seiten im März 1999 veröffentlicht. Die Vorteile dieses Protokolls traten schnell zutage, sodass es schon bald ausgebaut wurde. Schon im Juni 2002 wurde eine weiterführende SIP- Spezifikation als RFC 3261 mit einem Umfang von 265 Seiten veröffentlicht, die RFC 2543 ablöste. Die Spezifikation des SIP Core in RFC 3261 ist bis heute gültig, aber es wurden bereits in zahlreichen RFCs diverse SIP Extensions spezifiziert. Das folgende Bild zeigt die Schwerpunkte der Weiterentwicklung des SIP Core. 8
Bild 007386: Weiterentwicklung des SIP Core und dessen Erweiterungen (Extensions) MIME: Multipurpose Internet Mail Extensions General Aspects Neben der Spezifikation des SIP in RFC 3261 ist noch RFC 3665 mit der Präsentation typischer SIP-Verläufe zu erwähnen. Einen besonderen Stellenwert hat RFC 3263 mit der Beschreibung, wie der Proxy aus der Domain des Anrufenden (vgl. Bild 007383) anhand von SIP-URI mithilfe des Domain Name System (DNS) die IP- Adresse des Proxy in der Domain des Angerufenen bestimmt. SIP ist ein transaktionsorientiertes Protokoll. Wird eine Transaktion nicht mit dem Request INVITE, sondern mit einem anderen, wie z.b. CANCEL, initiiert, so wird sie als Non-INVITE-Transaktion bezeichnet. RFC 4320 zeigt, welche Besonderheiten beim SIP realisiert werden müssen, um Transaktionen solcher Art erfolgreich abschließen zu können. Beim SIP-Verlauf können verschiedene unvorhersehbare Wettlaufsituationen, als Race Conditions bezeichnet, vorkommen. Diese treten 9
oft auf, wenn eine Session zwischen zwei Benutzern seitens beider quasi gleichzeitig initiiert wird. RFC 5407 zeigt einige Beispiele für solche Situationen. Ein Proxy, der z.b. eine Firewall-Funktion für VoIP enthält, erzeugt im empfangenen Request INVITE das Header Field Record-Route, um seinen Namen anzugeben und darauf zu verweisen, dass der weitere SIP-Verlauf über ihn verlaufen muss. RFC 5658 zeigt, wie die Angaben in Record-Route erfolgen sollen. RFC 5954 beschreibt den Aufbau von SIP-URI beim IPv6-Einsatz. Die Behandlung von Responses 2xx und von Re-INVITE erläutern die RFCs 6026 und 6141. SIP Messages and their Extensions In RFC 3311 wurde zwecks einer möglichen Änderung der Eigenschaften einer bereits bestehenden Session der Request UPDATE definiert. In UPDATE wird eine modifizierte Beschreibung der Session nach SDP (Bild 007387) übermittelt. Die Kommunikation zwischen User Agent (UA) und Registrar kann über mehrere SIP-Proxies erfolgen. So etwas kommt bei der Mobilitätsunterstützung vor, wenn ein mobiler UA in einer Fremd-Domain auf den Registrar seiner Heimat-Domain zugreift. RFC 3327 definiert das Header Field Path, um dieses Problem zu lösen. Wie ein Multipart Body in SIP-Nachrichten nach dem MIME- Konzept gebildet werden kann, beschreibt RFC 5621. In RFC 6228 wird der Response 199 Early Dialog Terminated definiert, um das Ende vom sog. Early Dialog signalisieren zu können. RFC 7462 spezifiziert Uniform Resource Names (URNs), die man den Alerting-Tönen vergeben kann. Sie werden im Header Field Alert-Info eingetragen. Dies ermöglicht, ankommende Anrufe mittels verschiedener Töne/Ansagen zu signalisieren. Overload Control and Avoidance In SIP-Proxies muss man mit einer Überlastung (Congestion) rechnen. Diesem Problem widmen sich die RFCs 6257, 7339 und 7415. 10
Geolocation Conveyance Die Übermittlung der Angabe des Standortes von VoIP-fähigen Smartphones, der sog. Geolokation, nimmt ständig an Bedeutung zu. Sie ist insbesondere für die Bereitstellung verschiedener VoIPbasierter Notrufdienste fast unabdingbar. RFC 6442 spezifiziert die zu ihrer Realisierung notwendigen SIP Extensions. Stunden im SIP-Uhrmodell Stunde 1 Description of Sessions Die kommunizierenden Rechner müssen sich u.a. darüber verständigen, wie einzelne Medien codiert also in welchem Format sie übermittelt werden sollen. Diese Vereinbarung führt zum Aufbau einer Kommunikationsbeziehung zwischen ihnen. Sie wird als Session bezeichnet. Um eine Session vereinbaren zu können, ist ein Protokoll notwendig. Das bereits erwähnte Session Description Protocol (SDP) ist ein solches Protokoll und kann als Bestandteil des SIP betrachtet werden. Das nächste Bild zeigt den Einsatz von SDP beim Aufbau einer Session nach dem SIP. Bild 007387: SDP beim Aufbau einer Session nach dem SIP Der Rechner A initiiert durch das Absenden von INVITE eine Session zum Rechner B. INVITE setzt sich oft aus zwei Teilen zusammen. Der erste Teil stellt einen Header in Form von mehreren Zeilen dar, der nach dem SIP aufgebaut wird. Der zweite Teil ebenso in Form von mehreren Zeilen wird nach dem SDP strukturiert und als Message Body (kurz Body) übermittelt (Bild 007384). Im Body 11
wird die gewünschte Session genauer gesagt werden ihre Eigenschaften nach SDP beschrieben. Kann der Rechner B die ankommende Verbindung annehmen, d.h. kann er die vom Rechner A geforderten Charakteristika der Session seinerseits gewährleisten, so antwortet er dem Initiator der Session (Rechner A) mit 180 Ringing bzw. mit 200 OK. Wie Bild 007387 zeigt, verläuft eine Abstimmung von Eigenschaften einer Session nach dem Modell Offer/Answer. Anmerkung: Für eine detaillierte Darstellung von SDP sei verwiesen auf: http://www.in2eps.com/fo-abnf/tk-fo-abnf-sdp.html Das folgende Bild zeigt, welche RFCs die Beschreibung von Sessions betreffen. Bild 007388: Weiterentwicklung der Beschreibung von Sessions nach dem SDP AMR-WB: Adaptive Multirate Wideband ANAT: Alternative Network Address Types FEC: Forward Error Correction OMA: Open Mobile Alliance RTCP: Realtime Control Protocol TCP: Transmission Control Protocol 12
SDP General Aspects Diese beschreiben die RFCs 3264, 4317, 4566 und 6337. Sie erläutern u.a. SDP und dessen Prinzip Offer/Answer. RFC 6157 zeigt die Möglichkeiten der Kommunikation zwischen UAs mit den beiden Protokollen IPv4 und IPv6. Additional SDP Attributs Eine Session kann dann zustande kommen, wenn der Empfänger in der Lage ist, die vom Sender angebotenen Medienformate (Codierungsarten) zu empfangen. Daher ist es wichtig, dass die Kommunikationspartner sich ihre Fähigkeiten (Capabilities) in Bezug auf die Empfangsmöglichkeiten einzelner Medien mitteilen können. RFC 3407 zeigt, wie Angaben solcher Art mithilfe von SDP dargestellt werden können. In RFC 5939 wurde ein SIP Capability Framework spezifiziert. RFC 5939 wurde bereits durch RFC 6871 ergänzt. RFC 3605 zeigt, wie die RTCP 5 -Angaben in der Beschreibung von Sessions nach SDP gemacht werden können. Während einer Session muss die Möglichkeit einer zuverlässigen Übermittlung nicht zeitkritischer Medien, beispielsweise unbewegter Bilder, über einen Medienkanal mit Realtime Transport Protocol (RTP) also mithilfe des Transmission Control Protocol (TCP) bestehen. In RFC 4155 wird eine solche Möglichkeit präsentiert. Ein und derselbe Medienstrom kann in mehreren Sessions vorkommen, z.b. im Falle einer Videokonferenz. Um die Zuordnung eines Medienstroms zu mehreren Sessions zu koordinieren, ist es sinnvoll, diesen mit einem Label zu identifizieren. In RFC 4574 wurde hierfür das SDP-Attribut label spezifiziert. Falls eine multimediale Session mit mehreren und besonderen Medienströmen zu einem Rechner aufgebaut werden soll, so wie es bei der Realisierung verteilter Konferenzen der Fall ist, sollte die Möglichkeit existieren, das am bestens dafür geeignete Präsentationstool im Zielrechner dynamisch einzusetzen, RFC 4796 spezifiziert hierfür das SDP-Attribut content. 5 Realtime Control Protocol 13
Ist ein IP-Paket mit einem Sprachsegment verloren gegangen, muss statt des Originals ein Ersatz-Sprachsegment oft in Form von Hintergrundgeräuschen wiedergegeben werden. Um ein Sprachsegment schnell in den wiederzugebenden Sprachstrom einbetten zu können, muss man wissen, wie lang dieses Segment ist. RFC 4867 beschreibt die hierfür benötigten SDP-Attribute. RFC 5159 definiert die für den Einsatz des SIP beim Digital Video Broadcasting (DVB) erforderlichen Attribute. Grouping of Media Streams Eine Session kann mehrere Medienkanäle (Media Lines), z.b. einen für Audio und einen anderen für Video, enthalten. Falls mehrere dieser zu übermittelnden Medien zusammengehören, so wie es bei der Audio- und Videoübermittlung bei einer Konferenz der Fall ist, müssen diese Medienströme (Media Streams) synchronisiert werden. In RFC 3388 wurden die hierfür nötigen SDP-Attribute definiert. RFC 5888 beschreibt ein Grouping Framework und löst damit RFC 3888 ab. RFC 4756 liefert eine Ergänzung zu RFC 3388 und beschreibt die Semantik zur Gruppierung mehrerer Medienkanäle mit den nach FEC 6 codierten Medienströmen einer Session; RFC 5956 wird durch RFC 4756 ergänzt. Interactive Connectivity Establishment (ICE) In RFC 4091 wurden sog. Alternative Network Address Types (ANAT) Semantics beschrieben. Diese Idee ermöglicht es einem Rechner mit IPv4 und IPv6, einem anderen Rechner eine Session entweder mit IPv4 oder mit IPv6 anzubieten. Ein Rechner kann also einem anderen Rechner alternativ eine IPv4- oder eine IPv6-Adresse vorschlagen. RFC 4092 ergänzt RFC 4091. Die Lösung ANAT wurde durch das in RFC 5245 spezifizierte Konzept Interactive Connectivity Establishment (ICE) ersetzt (Bild 007392). 6 Forward Error Correction 14
Stunde 2 General SIP Extensions Bei der Entwicklung des SIP konnte man seinerzeit nicht voraussehen, für welche Dienste es später verwendet und was von ihm verlangt werden würde. Aus diesem Grund entstanden seit der Veröffentlichung der letzten Spezifikation des SIP in RFC 3261 (Juni 2002) immer wieder neue allgemeine SIP Extensions, die das folgende Bild auflistet. Bild 007389: Allgemeine SIP Extensions nach Kategorien geordnet SCTP: Stream Control Transmission Protocol UA: User Agent General Aspects In RFC 5049 wird die Art der Komprimierung von Angaben im SIP Header Signaling Compression genannt dargestellt. Um anzeigen zu können, wo, von wem bzw. warum ein Anruf umgeleitet wurde, definiert RFC 5806 die hierfür notwendigen SIP Extensions; diese erlauben es, mehrere Leistungsmerkmale zu realisieren. Angaben über Umleitungen können auch im Header Field History-Info gemacht werden; darauf geht RFC 7544 ein. 15
RFC 6050 definiert URNs, um die vom SIP erbrachten und mit Nachrichten INVITE initiierten Dienste und/oder Applikationen einheitlich identifizieren zu können. RFC 7092 liefert eine Taxonomie von Back-to-Back User Agents (B2BUAs), mit denen die beiden Funktionen User Agent Server (UAS) und User Agent Client (UAC) erbracht werden können. Beim Einsatz von B2BUAs können sog. SIP Request Routing Loops entstehen. Diese sind unerwünscht und müssen entdeckt werden; RFC 7332 zeigt, wie dies erfolgen kann. RFC 7206 spezifiziert die Anforderungen an den Session Identifier (Session-ID) zur besseren Unterstützung des Managements und Monitorings von Sessions. Um diese Angaben in SIP-Nachrichten zu übermitteln, definiert RFC 7329 das Header Field Session-ID. SIP Messages Durch die in RFC 2976 spezifizierte Nachricht INFO ist es möglich, während einer bereits bestehenden Session Angeben, die sich nicht direkt auf diese beziehen, zu übermitteln. In RFC 3262 wurde die Nachricht PRACK (Provisional Response ACK) eingeführt, die als Bestätigung vorläufiger Antworten dient. Mit PRACK wird mitgeteilt, dass auf eine endgültige Antwort gewartet wird. PRACK kommt z.b. beim Aufbau von Sessions mit Bandbreitenreservierung zum Einsatz. Mit dem SIP sind anonyme Anrufe möglich. Allerdings hat der Angerufene das Recht, einen anonymen Anruf abzulehnen. RFC 5079 definiert die Response 433 Anonymity Disallowed, um dem Anrufenden den Grund für die Ablehnung des Anrufs mitzuteilen. Extensions and Use of SIP Header Fields Nicht jede initiierte Session kommt zustande. Es ist wichtig, die Ursache dafür zu kennen. Hierfür spezifiziert RFC 3326 das Header Field Reason, in dem die Ursache angegeben werden kann. Die Nutzung von Reason erläutert RFC 6432. Oft (z.b. beim Call Transfer) ist es nötig, einen Teil einer SIP- Nachricht woanders als in ihrem Body zu transferieren. Auf den zu transferierenden Teil der SIP-Nachricht wird im Header Field Content-Type der als Container dienenden SIP-Nachricht mit message/sipfrag (fragment) verwiesen. Dies zeigt RFC 3420. 16
SIP definiert einen speziellen Server als Registrar, der Angaben hinsichtlich der Lokation von in seiner DNS-Domain beheimateten Benutzern enthält. Ein Benutzer kann mobil sein, sich also zwischen verschiedenen Endsystemen bewegen, die sogar zu verschiedenen Domains gehören können. Um die Kommunikation zwischen einem Benutzer, der sich aktuell in einer Fremd-Domain aufhält, und dem Registrar in seiner Heimat-Domain zu erleichtern, spezifiziert RFC 3608 das Header Field Service Route. Die RFCs 3840, 5688 und 6809 definieren Regeln, nach denen UAs ihre Leistungsmerkmale und andere Fähigkeiten Features and Capabilities also anzeigen können. In RFC 3840 werden z.b. Regeln definiert, nach denen die Beschreibung von UA Capabilities in das Header Field Contact eingetragen werden kann. Als Ergänzung dazu werden in RFC 3841 weitere Header Fields spezifiziert, in denen die Präferenzen des Anrufers angegeben werden können. RFC 4028 spezifiziert eine SIP-Erweiterung, die es erlaubt, eine bestehende Session durch Requests re-invite, d.h. erneutes Absenden von INVITE, oder UPDATE periodisch aufzufrischen bzw. zu aktualisieren, falls in dem Moment keine Übermittlung von Medien stattfindet. Um die Angabe bestimmter Informationen über den SIP-Verlauf als History Information bezeichnet zu ermöglichen, wurde das Header Field History-Info in RFC 4244 spezifiziert. Damit kann man z.b. darüber informieren, wie und warum eine Nachricht INVITE an ein Ziel weitergeleitet wurde. RFC 4244 wurde inzwischen durch RFC 7044 ersetzt und RFC 7044 später durch RFC 7131 ergänzt. SIP over X Zum Transport von SIP-Nachrichten kann auch das Stream Control Transmission Protocol (SCTP) eingesetzt werden. RFC 4168 beschreibt, wie dies erfolgen kann. Um Browser und Webserver um eine SIP-Funktionalität zu erweitern und dadurch Web Real-Time Communication (WebRTC) realisieren zu können, wurde das Web- Socket Protocol (WSP) in RFC 6455 spezifiziert. Man spricht auch von SIP over WebSocket (RFC 7118). 17
Guarantee of Privacy In RFC 3323 werden einige Möglichkeiten beschrieben, um die Anonymität eines Benutzers durch das Verbergen seiner Identität dem Angerufenem gegenüber zu gewährleisten und somit seine Privatsphäre zu schützen. Es wird zwischen Mechanismen beim User Agent (UA-driven) und Mechanismen im Netz (Networkdriven) durch den Einsatz von Proxies unterschieden. Den UAdriven-Mechanismen widmet sich RFC 5767. Stunde 3 Operability with PSTN/ISDN and 3GPP VoIP-Systeme und das Internet werden mit klassischen Netzen wie PSTN/ISDN und anderen Systemen zur Sprachkommunikation verbunden, insbesondere mit Mobilfunknetzen nach Spezifikationen der Standardisierungsorganisation 3GPP 7. Hierbei muss das SIP u.a. auf die Protokolle des ISDN, insbesondere auf ISDN User Part (ISUP) des Signaling System No. 7 (SS7), abgebildet werden. Das in Mobilfunknetzen eingesetzte IP Multimedia Subsystem (IMS) basiert auf dem SIP. Das folgende Bild zeigt, welche RFCs sich der Operabilität des SIP mit PSTN/ISDN und mit 3GPP-Netzen widmen. General Aspects RFC 3372 präsentiert das als SIP for Telephones (SIP-T) bezeichnete Konzept zur Integration von ISDN und PSTN mit VoIP- Systemen. Support of PSTN/ISDN-Services Zur Integration von PSTN/ISDN in das Internet wurden zwei SIPbasierende Konzepte vorgeschlagen: PINT (PSTN and Internet Interworking) in RFC 2848 und SPIRITS (Services in the PSTN Requesting Internet Services) in RFC 3910. PINT beschreibt, wie man das Internet als Zubringer zum PSTN/ISDN nutzen kann. Mit diesem Konzept können die Rechner am Internet z.b. Fax-Nachrichten im PSTN/ISDN versenden. 7 Third Generation Partnership Project, http://www.3gpp.org 18
SPIRITS spezifiziert, wie man Ereignisse aus dem PSTN/ISDN in Servern am Internet bearbeiten kann. So kann mit SPIRITS z.b. eine SMS-Umleitung zum Rechner am Internet erfolgen. Bild 007390: SIP Extensions für Operabilität mit PSTN/ISDN und 3GPP-Netzen ISUP: MIME: PINT: SPIRITS: UUI: ISDN User Part Multipurpose Internet Mail Extensions PSTN and Internet Interworking Services in the PSTN Requesting Internet Services User-to-User Information Support of ISDN-Signaling in SIP Bei der Integration des Internet mit ISDN kommt es vor, dass Angaben des ISDN-Protokolls ISUP in SIP-Nachrichten INVITE übermittelt werden müssen. RFC 3204 beschreibt, wie hierfür MIME (Bild 007385) genutzt werden kann. Die RFCs 3398 und 3578 zeigen, wie ISUP auf dem SIP abgebildet werden kann. Diese Abbildung ergänzt SIP-T (RFC 3372). In RFC 3666 werden verschiedene Beispiele für den SIP-Verlauf bei einer Integration von VoIP-Systemen mit PSTN/ISDN gezeigt. Wie die Übermittlung von User-to-User Information (UUI) des ISDN-D- Kanal-Protokolls im Body von SIP-Nachrichten erfolgen kann, wird in den RFCs 6657, 7433 und 7434 dargestellt. 19
RFC 6432 beschreibt, wie man Reason in Responses auf INVITE zur Übermittlung von im Dokument ITU-T Q.850 festgelegten Codes von Ausfallursachen in PSTN/ISDN nutzen kann. Early Media Support in SIP Beim SIP spricht man von einer Session, wenn diese bereits aufgebaut wurde, sodass ein Dialog zwischen Teilnehmern stattfinden kann. Während des Aufbaus einer Session können aber bestimmte Medien mit Ansagen über Verbindungspreise oder mit bestimmten Hinweistönen an den Anrufer übermittelt werden. Man bezeichnet solche Medien als Early Media. Für deren Übermittlung wird seitens des Angerufenen eine gerichtete Session (Early Session) zum Anrufenden aufgebaut; sie macht Early Media hörbar. In RFC 3959 wird der Option Tag early-session, der im Header Field Content-Description angegeben werden kann, eingesetzt, um auf die Übermittlung von Early Media zu verweisen. In RFC 3960 werden zwei Lösungsansätze für die Übermittlung von Early Media vorgeschlagen. Die RFCs 3959 und 3960 ergänzen sich gegenseitig. IMS-specific SIP Extensions Den SIP Header Fields P-Asserted-Identity und P-Preferred-Identity zur Unterstützung der Authentifizierung im IMS widmen sich die RFCs 3324, 3325 und 5876. Die SIP-Nutzung im IMS beschreibt RFC 4083. Weitere Header Fields werden in den RFCs 4457, 5002, 7315, 7316 definiert. RFC 7549 legt einige Parameter von SIP-URI zur Unterstützung von Roaming in Mobilfunknetzen fest. Stunde 4 Various Service Features In den der multimedialen Kommunikation dienenden Systemen müssen verschiedene ergänzende Dienstmerkmale (Supplementary Service) realisiert werden, wie Call Transfer, Call Forwarding und Call Hold. Verschiedene Erweiterungen des SIP wurden spezifiziert, um Dienstmerkmale dieser Art zu ermöglichen. Die diesen Aspekten gewidmeten RFCs zeigt das folgende Bild. General Aspects In zahlreichen RFCs werden allgemeine Aspekte diverser SIP Services bzw. Service Features dargestellt. An dieser Stelle seien folgen- 20
de neue Services hervorgehoben: Real-Time Text over IP in RFC 5194, Fax over IP in RFC 6913, Transcoding Services (u.a. Real- Time Voice Translation) in RFC 5369 und Media Recording in den RFCs 6341 und 7245. Bild 007391: SIP Extensions für verschiedene Service Features Ans-M: AOR: CCBS/NR: CLF: IP: Answering Mode Address of Record Call Completion to Busy Subscribers/No Reply Common Logfile Format Internet Protocol 21
IP-PBX: UA: IP Private Branch Exchange User Agent SIP Messages Ein wichtiges Dienstmerkmal beim VoIP ist die Anrufumlegung, auch Call Transfer (CT) genannt. Dieses Dienstmerkmal erlaubt es, eine bestehende Verbindung zwischen Teilnehmer A und Teilnehmer B beispielsweise durch den Teilnehmer B auf eine neue Verbindung zwischen Teilnehmer B und Teilnehmer C zu transferieren. Die RFCs 3515 und 7642 beschreiben, wie dies mittels der SIP- Nachricht REFER erfolgen kann. Extension and Use of SIP Header Fields In RFC 3891 wird das Header Field Replaces spezifiziert, welches dazu dient, eine bestehende Session durch eine andere Session zu ersetzen. Im Replaces wird die Identifikation einer Session eingetragen. Dadurch ist u.a. die Realisierung der Dienstmerkmale Call Park und Call Pickup möglich. In RFC 3892 wird das Header Field Referred-By spezifiziert, das in REFER und INVITE angegeben werden kann, um darauf zu verweisen, dass in deren Bodies bestimmte Angaben über den Absender von REFER z.b. über den Initiator von Call Transfer in Form von S/MIME enthalten sind. RFC 3892 ergänzt RFC 3515. RFC 4488 spezifiziert das Header Field Refer-Sub, das in der Nachricht REFER bzw. in einer Response 2xx auf REFER enthalten sein kann. Mit Refer-Sub:false wird der Empfänger von REFER darüber informiert, dass er REFER nicht weiterleiten darf. Damit lässt sich z.b. die Forking-Funktion im SIP-Proxy deaktivieren. Für die Fortsetzung siehe: Dreibändiges Loseblattwerk (Print und CD-Version) mit Update-Dienst: "Protokolle und Dienste der Informationstechnologie" Aktualisierungszyklus: 2 Monate, WEKA Media, Kissing ISBN-13: 978-3827691422, Bestell-Nr. OL9142J http://shop.weka.de/protokolle-und-dienste-derinformationstechnologie-online 22