WebRTC. Web Real-Time Communication. WebRTC. Autor: Prof. Dr.-Ing. Anatol Badach

Transkript

1 Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN WebRTC Web Real-Time Communication Stellen Sie sich vor: Sie nutzen zu Hause als Terminal am Internetzugang eine Smart-TV-ähnliche Kommunikationsendeinrichtung. Diese ähnelt einem schnurlosen Web-Videotelefon (Web Video Phone), hat ein Display, eine integrierte Minikamera und einen Webbrowser. Sie können in diesem Terminal den Webbrowser öffnen und über diesen nicht nur, wie es heute über jeden anderen Rechner üblich ist, ganz normal googeln, sondern nach dem Mausklick auf ein Icon, welches die Funktion eines Web-Videotelefons symbolisiert, auch noch eine gleichzeitige Sprach- und Videokommunikation also Videotelefonie mit jemandem führen, dabei verschiedene Dokumente übermitteln und diese auch direkt besprechen. Um so etwas verwirklichen zu können, wird das als WebRTC bezeichnete Konzept entwickelt. WebRTC ist eine richtungsweisende Idee, die dazu dient, multimediale Echtzeitkommunikation mithilfe von HTLM5 1 -fähigen Webbrowsern also eine Web-Echtzeitkommunikation, Web- Videotelefonie (Web Video Telephony) einfach zu realisieren, ohne dafür zusätzliche Softwaremodule installieren zu müssen. Zur Unterstützung von WebRTC können bei Bedarf von einem Webserver verschiedene RTC-spezifische Funktionsmodule heruntergeladen und in diesen direkt, quasi automatisch, eingebaut werden. Welche Module hierfür nötig sind, soll im Weiteren noch detaillierter erläutert werden. Bei WebRTC kann ein spezieller Server um RTC-Funktionen erweitert werden hierzu eignet sich jeder Webserver und als Manager von multimedialen Verbindungen, von sog. Sessions, zwischen Browsern dienen. Es ist zu erwarten, dass eine große Akzeptanz von WebRTC in Smartphones, Tablet-Computern und in Smart-TV in der Zukunft zu großen Veränderungen der heutigen 1 Die Auszeichnungssprache HTML5 (Hypertext Markup Language 5) des W3C liefert u.a. neue und umfangreiche Elemente, um Videos auf einer Webseite darzustellen und Audio abzuspielen dank HTML5 sind die Browser also multimediafähig. 1

2 Kommunikationslandschaft führen wird und die Videotelefonie per Smart-TV nur eine Frage der Zeit ist. Auf diese Situation bereiten sich die führenden Browserhersteller u.a. Google (Chrome), Mozilla (Firefox) und Opera Software (Opera) heute schon vor; sie gelten als treibende Kräfte der Entwicklung der zur Realisierung von WebRTC benötigten funktionellen Komponenten (Protokollen, Softwareschnittstellen usw.). Die Ergebnisse dieser Entwicklungen werden beim World Wide Web Consortium (W3C) von der Working Group WebRTC 2 und bei der Internet Engineering Task Force (IETF) von der Working Group RTCWEB (Real-Time Communication in WEB-Browsers) 3 standardisiert. Es sei hervorgehoben, dass sich die Working Group WebRTC beim W3C schwerpunktmäßig mit der Standardisierung von Anwendungsprogrammierschnittstellen (Application Programming Interface, API) zur Zusammenarbeit von RTC-Funktionsmodulen innerhalb von Browsern beschäftigt. Dagegen liegt der Schwerpunkt der Aktivitäten der Working Group RTCWEB bei der IETF in der Standardisierung von Systemkonzepten und Protokollen für die Kommunikation zwischen Browsern. Auch die Firma Microsoft ist auf dem Gebiet Web-Echtzeitkommunikation aktiv. Sie verfolgt aber ein eigenes Konzept, bezeichnet als CU-RTC-Web (Customizable, Ubiquitous Realtime Communication over the Web) 4. Betrachtet man WebRTC rein vom technischen Standpunkt her, so stellt man aber fest, dass bei WebRTC im Grunde genommen weitgehend das Konzept von Voice over IP (VoIP) übernommen und um zusätzliche Funktionen erweitert wurde. Aus diesem Grund könnte man einige Systemlösungen für WebRTC auch als Extended VoIP over Web bezeichnen. Dies soll dieser Beitrag deutlich zum Ausdruck bringen und zugleich zeigen, dass WebRTC als Weiterentwicklung von VoIP angesehen werden kann. Folglich wird die Integration von WebRTC mit bestehenden VoIP-Systemen im

3 Hinblick auf den Einsatz von VoIP in Smartphones von großer Bedeutung sein. Das primäre Ziel dieses Beitrags soll es sein, eine Übersicht über die grundlegenden Ideen, Konzepte und zukünftigen Anwendungsmöglichkeiten von WebRTC zu geben. Die WebRTC betreffenden Standards sind zurzeit noch in der Entwurfsphase. Demzufolge sind die hier dargestellten Konzepte und Beispiele für Systemlösungen überwiegend noch als denkbare/realisierbare Visionen anzusehen. Browser mit Unterstützung von WebRTC Bei WebRTC kann ein Webbrowser im Weiteren kurz Browser genannt nicht nur als Software-Telefon (Softphone) dienen, sondern auch als eine universelle, multimediale Kommunikationsinstanz zur Unterstützung der Sprach-, Video- und Datenkommunikation zwischen per Internet kommunizierenden Personen, also als Web-Videotelefon (Web Video Phone). 5 Damit ein Browser die nötigen multimedialen Funktionen bereitstellen kann, muss er um eine RTC-spezifische Software erweitert werden; er muss also RTCfähig sein. Bild illustriert dies. Bild : Vereinfachtes Modell der Kommunikation zwischen WebRTC-Client und -Server HTTPS: Hypertext Transfer Protocol Secure 5 Ein Beispiel dafür, wie ein Web-Videotelefon aussehen kann, findet man unter 3

4 IP: SIG-P: TCP: WS(S): Internet Protocol Signaling Protocol (Signalisierungsprotokoll) Transmission Control Protocol (Secure) WebSocket Protocol Anmerkung: Weitergehende Informationen zu dem in Bild dargestellten Szenarium findet man auf der Website der IETF unter Real- Time Protocols for Brower-based Applications ( draft-ietf-rtcweboverview-08 ). Sollte der Browser in einem Rechner noch nicht RTC-fähig sein, so wird der Internetnutzer zukünftig in der Lage sein, mithilfe eines Links auf dem Browser zu veranlassen, dass über das sichere Hypertext-Übertragungsprotokoll HTTPS von einem Webserver eine RTC-spezifische Software heruntergeladen und in den Browser automatisch integriert wird. So einfach sollte der Browser RTCfähig gemacht werden und zusätzlich auch als Web-Videotelefon dienen können. In allen privaten Systemen, die Telefonie ermöglichen, werden Telefone als Endgeräte über zentrale Vermittlungsknoten für die Dauer der Kommunikation (des Telefonats) miteinander verbunden. Als Vermittlungsknoten fungiert bei VoIP in einem Unternehmen ein spezieller VoIP-Server. Bei WebRTC benötigt man einen funktionell ähnlichen Server, im Weiteren als WebRTC-Server bezeichnet, der als Vermittlungsknoten zwischen Web-Videotelefonen arbeitet. Eine RTC-spezifische die Funktion eines Web- Videotelefons erbringende Softwareinstanz im Browser kann somit als Client des WebRTC-Servers angesehen werden. Aus diesem Grund wird hier diese in den Browser integrierte Softwareinstanz als WebRTC-Client bezeichnet. Die grundlegende Idee von WebRTC (vgl. auch die Bilder , , und ) besteht darin, dass ein WebRTC- Server quasi als Manager multimedialer Verbindungen (Sessions) zwischen WebRTC-Clients fungiert. Über einen WebRTC-Server können zahlreiche, als Web-Videotelefone dienende WebRTC- Clients logisch/virtuell so verbunden werden, dass sie untereinander 4

5 über das Internet in IP 6 -Paketen Sprache, Video und Daten übermitteln können. Jeder WebRTC-Server dient somit als WebRTC Session Controller. Ein WebRTC-Server kann die Kommunikation zwischen Benutzern nur dann ermöglichen, wenn sie zur Initiierung der Kommunikation berechtigt und dem WebRTC-Server deren WebRTC-spezifischen Adressen bekannt sind. Hierfür müssen die Benutzer beim WebRTC-Server entsprechend registriert werden. Folglich muss im WebRTC-Server eine spezielle Funktion oft als Registrar bezeichnet 7 enthalten bzw. eine solche Funktion an ihn entsprechend angebunden sein. Um welche RTC-Funktionen Browser und Webserver erweitert werden müssen, wird aus den im Weiteren gezeigten Systemlösungen ersichtlich. Eine Grundlage für WebRTC bildet z.b. das im RFC 6455 spezifizierte WebSocket Protocol (kurz WS- Protokoll oder WSP). Darauf soll im Weiteren kurz eingegangen werden. WebRTC-Server Wo wird diese Funktion erbracht? Weil das WS-Protokoll normalerweise zwischen Browsern und Webserver eingesetzt wird, verweist man in diversen Publikationen zum Thema WebRTC oft darauf, dass die Funktion des WebRTC- Servers von einem Webserver erbracht wird. Aus der Sicht eines RTC-fähigen Browsers kann der WebRTC-Server als eine funktionelle Erweiterung eines Webservers angesehen werden. Für einen RTC-fähigen Browser bildet ein aus einem Web- und einem WebRTC-Server bestehendes Paar quasi einen RTC-fähigen Webserver. In diesem Beitrag wird aber keine Festlegung getroffen, wo und wie die Funktion des WebRTC-Servers erbracht wird, ob also in einem physischen Webserver oder in einem anderen dedizierten Server mit der Unterstützung des WS-Protokolls. 6 Internet Protocol 7 Diese Funktion entspricht weitgehend der Funktion Registrar beim bekannten Session Initiation Protocol (SIP). Für Näheres siehe Abschnitt 7.6 in [1]. 5

6 WS-Protokoll und dessen Bedeutung bei WebRTC Den klassischen Webanwendungen liegt eine Request-Responsespezifische Kommunikation zwischen Browser und Webserver zugrunde. Diese besteht darin, dass der Browser immer zuerst einen Request an den Webserver schickt und dieser dem Browser darauf mit einem Response antwortet. Dies bedeutet also, dass in den klassischen Webanwendungen immer der Browser die Kommunikation zum Webserver initiiert hat. Der Webserver bei klassischen Webanwendungen war also nicht fähig, eine Verbindung zum Browser zu initiieren. WebRTC ist aber keine klassische Webanwendung mehr. Bei WebRTC muss jeder Webserver, der zusätzlich u.a. die Funktion eines WebRTC-Servers erbringt, auch in der Lage sein, eine Verbindung zum Browser selbst zu initiieren. Genau betrachtet muss jeder WebRTC-Server fähig sein, eine Verbindung zum WebRTC- Client im Browser zu initiieren (vgl. Bild ). Ein wichtiges Ziel der Entwicklung des WS-Protokolls war es, die Webserver dazu zu befähigen, die Verbindungen zu Browsern selbst zu initiieren. Dank der Nutzung des WS-Protokolls können die Webserver die zusätzliche Funktion von WebRTC-Servern erbringen, dadurch zur Unterstützung von WebRTC verwendet werden, als Verbindungsmanager (Call Manager) dienen und u.a. multimediale Verbindungen zu Browsern initiieren. Anmerkung: Theoretisch gesehen kann jeder Webserver so um RTC-Funktionen erweitert werden, dass er RTC-fähig wird und als Verbindungsmanager fungiert. Sollte es aber der Fall sein, dass ein normaler Webserver eine große Anzahl von WebRTC-Benutzern unterstützen muss, es also einer großen Anzahl von Browsern ermöglichen muss, untereinander zu kommunizieren, dann ist es sinnvoller zu diesem Zweck einen separaten Server mit Unterstützung des WS-Protokolls als dedizierten WebRTC-Server zu verwenden. Signalisierungsprotokoll bei WebRTC Bei WebRTC handelt es sich um eine multimediale Kommunikation d.h. um eine Art Videotelefonie. Daher ist ein Protokoll nötig, um virtuelle Verbindungen zwischen WebRTC-Clients in Browsern nicht nur auf- und abzubauen, sondern den Benutzern ankommende Videotelefonieanrufe auch optisch anzuzeigen und bei Bedarf akustisch zu signalisieren; man benötigt also ein sog. 6

7 Signalisierungsprotokoll. Es ist zu erwarten, dass zu diesen Zwecken das in RFC 3261 spezifizierte Session Initiation Protocol (SIP) eingesetzt wird. Hierfür wurde bereits SIP in JavaScript (SIP-JS) implementiert. 8 Wie die Bilder und zeigen, wird das SIP zwischen einem WebRTC-Client und seinem -Server verwendet. Damit ein im Webserver installierter WebRTC-Server die zu einem WebRTC- Client im Browser führenden Verbindungen initiieren kann, muss zwischen Webserver und Browser das WS-Protokoll verwendet werden. Nach dem Aufbau einer WS-Verbindung zwischen Webserver und Browser (vgl. Bild ) werden über diese Verbindung SIP-Nachrichten in WS-Frames (vgl. RFC 6455) übermittelt; das bedeutet SIP over Websockets (SIP over WS), vgl. Bild Das WS-Protokoll nutzt für den Transport das verbindungsorientierte Transmission Control Protocol (TCP) und kann, um die Sicherheit der Kommunikation zwischen WebRTC-Client und -Server zu garantieren, auch das Sicherheitsprotokoll Transport Layer Security (TLS) nutzen. Ist das der Fall, dann spricht man vom Secure WebSocket Protocol (WSS). Um die Sicherheit bei der Übermittlung von SIP-Nachrichten zwischen WebRTC-Client und -Server zu garantieren, kann auch SIP over WSS, vgl. IETF-Draft draft-ietf-sipcore-sip-websocket-09, eingesetzt werden. Um die Installation von WebRTC-Clients und die Nutzung des SIP in Rechnern mit privaten IPv4-Adressen zu ermöglichen, soll das in RFC 5245 spezifizierte Protokoll Interactive Connectivity Establishment (ICE) zur Lösung des mit dem SIP verbundenen Problems bei Network Address Translation (NAT) nach RFC 3022 verwendet werden: Für eine fundierte Darstellung von ICE sei auf das Unterkapitel 10.6 in [1] verwiesen. Formen der Kommunikation bei WebRTC Es sei hervorgehoben, dass bei WebRTC alle Formen der Kommunikation zwischen Browsern realisiert werden können (vgl. Bild ), und zwar: 8 7

8 Videotelefonie, d.h. die gleichzeitige Sprach- und Videokommunikation bei einer multimedialen Session. Hier kommen das Realtime Transport Protocol (RTP) nach RFC 3550 und das RTP Control Protocol (RTCP) als Echtzeittransportprotokolle zum Einsatz. Für alle Applikationen ist aber die Nutzung des Secure RTP (SRTP) nach RFC erforderlich. Mit diesem Sicherheitsprotokoll können die Vertraulichkeit der Kommunikation, die Authentifizierung von Nachrichten und der Anti-Replay-Schutz garantiert werden. Für weitere Anforderungen an die Echtzeitkommunikation bei WebRTC sei auf den IETF-Draft draft-ietf-rtcweb-rtpusage verwiesen. Datenkommunikation über einen speziellen Datenkanal als Data Channel bezeichnet. Über diesen Datenkanal können mithilfe des Stream Control Transmission Protocol (SCTP) in beide Richtungen mehrere Datenströme übermittelt werden. Um die Sicherheit des Datentransports zu gewährleisten, soll hier das Datagram Transport Layer Security (DTLS) nach RFC 6347 als Sicherheitsprotokoll eingesetzt werden; also SCTP over DTLS realisiert werden. Für weitere Details sei auf folgende Drafts verwiesen: draft-ietf-rtcweb-transports, draft-ietf-rtcweb-data-channel und draft-ietf-rtcweb-dataprotocol. Anmerkung: Das in RFC 4960 spezifizierte SCTP ist ein verbindungsorientiertes und zugleich nachrichtenbasiertes Protokoll, welches einen gesicherten Transport von Nachrichten in mehreren SCTP-Streams bietet. Im SCTP werden die Vorteile des verbindungslosen User Datagram Protocol (UDP) und des verbindungsorientierten TCP vereint. SCTP erweitert den UDP-Dienst um Fehlersicherung und Multiplexing und realisiert dabei auch einige TCP-Konzepte. Damit die Kommunikation zwischen Benutzern, die bei verschiedenen WebRTC-Servern registriert sind, stattfinden kann, müssen diese Server untereinander kommunizieren und dabei entsprechende Signalisierungsnachrichten übermitteln. Als Signalisierungsprotokoll zwischen ihnen wird mit Sicherheit das SIP oder das SIP Security (SIPS) nach RFC 6216 eingesetzt. Bei einigen Anwendungen kann 9 aktualisiert durch RFC

9 auch das Extensible Messaging and Presence Protocol (XMPP) nach RFC 6120 oder Jingle verwendet werden. Anmerkung: Jingle ist eine von Google der XMPP Standards Foundation spezifizierte Erweiterung des XMPP um P2P-Funktionen (Peer-to-Peer). 10 Dreiecksmodell von VoIP mit SIP Um das Konzept von WebRTC anschaulich erläutern zu können, soll zuerst das in Bild illustrierte, allgemeine Konzept von VoIP mit SIP innerhalb einer DNS 11 -Domain (z.b. abc.de) kurz erläutert und dann gezeigt werden, dass es sich bei WebRTC in der Tat um eine ähnliche Idee handelt. Bild : Dreiecksmodell von VoIP mit SIP gilt innerhalb einer DNS-Domain (wie in SIP-Szenarien üblich, werden auch hier der Anrufer Alice und der Angerufene Bob genannt) DNS: MT: RTCP: RTP: SIG: SIP: Domain Name System Media Transport RTP Control Protocol Realttime Transport Protocol Signaling (Signalisierung) Session Initiation Protocol Domain Name System 9

10 Wie aus dem Bild ersichtlich ist, wird bei VoIP mit SIP ein spezieller VoIP-Server, oft auch VoIP-Proxy genannt, als Vermittlungsknoten zwischen als VoIP-Clients bezeichneten Telefonen eingesetzt. Demzufolge verläuft das SIP beim Aufbau einer Session für Transport von Audio (Sprache) und Video nach den Protokollen RTP/RTCP zwischen zwei VoIP-Clients entlang eines Dreiecks; man kann in diesem Zusammenhang somit vom Signalisierungsdreieck bzw. SIP-Dreieck (SIP-Triangle) sprechen. Im hier gezeigten Dreiecksmodell sind die zwei folgenden Planes hervorzuheben: Signalisierungs-Plane, in der das Signalisierungsprotokoll SIP verläuft, um zwischen den MT-Instanzen (Media Transport) in beiden VoIP-Clients eine Session für den Transport von Audio und Video nach den Protokollen RTP/RTCP einzurichten. Transport-Plane, innerhalb der die Echtzeitmedien Audio und Video über die zwischen den MT-Instanzen eingerichtete Session transportiert werden. Eine neue virtuelle Verbindung (Session) wird bei VoIP mit dem SIP mit der SIP-Nachricht INVITE initiiert, in der die als SIP-URI (Uniform Resource Identifier) bezeichnete Ziel-VoIP-Adresse enthalten ist. In Bild ist der als VoIP- Client A bezeichnete Rechner von Alice der Initiator der Session zu Bob. Beim Initiieren einer neuen Session wird INVITE an den SIP- Server übergeben und dieser muss INVITE zum Ziel hier zum VoIP-Client B weiterleiten. Hat INVITE den Rechner von Bob erreicht und die gewünschte Session kann zustande kommen, wird dies Bob akustisch durch Klingeln (Ringing) signalisiert und auch dem Rechner von Alice mittels der SIP-Nachricht 180 Ringing mitgeteilt. Hat Bob den Anruf entgegengenommen, wird dies dem Rechner von Alice mittels der SIP-Nachricht 200 OK angezeigt. Die beiden Nachrichten 180 Ringing und 200 OK werden über den SIP-Server übermittelt. Nach dem Empfang dieser Nachrichten kennt der Rechner von Alice bereits die IP-Adresse von Bobs Rechner und sendet daher die SIP- Nachricht ACK als Bestätigung des Empfangs von 200 OK direkt an diesen, ohne den VoIP-Server nutzen zu müssen. Dadurch entsteht ein SIP-Dreieck innerhalb der Signalisierungs-Plane. 10

11 Nach dem Eintreffen von 200 OK bei Bobs Rechner wird der Aufbau der Session beendet und die beiden Medien Audio und Video können mithilfe von RTP/RTCP in IP-Paketen zwischen MT- Instanzen über diese Session übermittelt werden. Dreiecksmodell von WebRTC ohne Transcoder-Einsatz Nachdem das in Bild gezeigte Modell der Kommunikation bei VoIP mit SIP erörtert wurde, soll das in Bild gezeigte Modell von WebRTC verdeutlichen, dass die beiden Konzepte VoIP mit SIP und WebRTC sehr ähnlich sind. Es gibt aber auch einige Unterschiede und auf diese soll im Folgenden eingegangen werden. Bild : Dreiecksmodell von WebRTC (vgl. hierzu Bild ) DTLS: HTTPS: RTCP: RTP: SCTP: SIG-P: SRTP: WS(S): Datagram Transport Layer Security (Datagram TLS) Hypertext Transfer Protocol Secure RTP Control Protocol Realtime Transport Protocol Stream Control Transmission Protocol Signaling Protocol Secure RTP (Secure) WebSocket Protocol Bei WebRTC soll in jedem Rechner, beispielsweise durch Anklicken eines Links bzw. eines Icons, die Möglichkeit bestehen, mithilfe des Protokolls HTTPS aus einem Webserver einen 11

12 WebRTC-Client herunterzuladen und diesen in den Browser quasi automatisch zu integrieren. Damit jeder Webserver auch als Vermittlungsknoten bei WebRTC, genauer gesagt als WebRTC-Server, dienen kann, wurde das WebSocket Protocol (WS-Protokoll) zur Übermittlung von Signalisierungsnachrichten zwischen WebRTC-Client und -Server entwickelt. Das WS-Protokoll ist ein verbindungsorientiertes Protokoll oberhalb des Transportprotokolls TCP. Beim WS kann auch das bereits erwähnte Sicherheitsprotokoll TLS verwendet werden; ist dies der Fall, so spricht man vom Secure WebSocket Protocol (WSS) Mithilfe des WS-Protokolls ist der WebRTC-Server, welcher auf einem normalen Webserver oder auf einem speziellen Server mit Unterstützung des WS-Protokolls installiert ist, in der Lage, eine Verbindung zum WebRTC-Client zu initiieren. Bei WebRTC verläuft das Signalisierungsprotokoll SIG-P (wie z.b. SIP) somit über WS oder WSS kurz als SIG-P over WS(S) bezeichnet. Die Nachrichten von SIG-P werden zwischen WebRTC-Client und - Server in WS-Frames transportiert: bei SIG-P over WS über eine normale, also ungesicherte TCP- Verbindung, bei SIG-P over WSS über eine mithilfe des Sicherheitsprotokolls TLS gesicherte TCP-Verbindung. Da das WS-Protokoll nur zwischen WebRTC-Client und -Server verwendet wird, können die Nachrichten eines Signalisierungsprotokolls bei WebRTC nur über WebRTC-Server übermittelt werden und nicht, so wie es bei VoIP mit SIP der Fall war, auch direkt zwischen SIP-Instanzen in Browsern. Demzufolge entsteht bei WebRTC, im Gegensatz zu VoIP, kein Signalisierungsdreieck (vgl. dazu die Bilder und ). Im Gegensatz zu VoIP mit SIP sind bei WebRTC die MT-Instanzen in der Lage, untereinander einen gesicherten Datenkanal (Data Channel) für den Transport von Daten einzurichten. Hier wird die Protokollkonstellation SCTP over DTLS verwendet, um verteilte Datenanwendungen und verschiedene Spiele zu ermöglichen. 12

13 Dreiecksmodell von WebRTC mit Transcoder-Einsatz Bei WebRTC soll die Anzahl der Audio- und Videocodecs sehr eingeschränkt sein. Es werden nur die folgenden Codecs verbindlich vorgesehen: für Audio der Codec nach dem Standard ITU-T G.711 der International Telecommunication Union (ITU) sowie der im RFC 6716 spezifizierte Opus Codec 12, für Video der Codec nach dem ITU-T H.264 und der lizenzgebührenfreie Codec VP8 nach RFC Um eine Kommunikation zwischen WebRTC-Clients, die nicht über die gleichen Audio- oder Videocodecs verfügen, zu ermöglichen, kann im WebRTC-Server ein Transcoding-Service eingerichtet werden. Wie Bild illustriert, muss in diesem Fall die Session für den Transport von Audio und Video über den Transcoder im WebRTC-Server verlaufen. Beim Einsatz des SIP als Signalisierungsprotokoll ist dies auch einfach realisierbar. Bild : Dreiecksmodell von WebRTC mit einem Transcoder der Audio- und Video-Formate Es ist zu erwarten, dass, um die Kommunikation zwischen VoIP- Telefonen und Web-Videotelefonen zu ermöglichen, die Transcoder-Services für die Umsetzung der Audio- und Video- Formate in VoIP/WebRTC-Gateways installiert sein werden. Dies wird wegen des Einsatzes von VoIP und der Unterstützung

14 verschiedener Audio-Formate in Smartphones von großer Bedeutung sein. Schritte vor und nach der WebRTC-Nutzung Damit im Rechner eines Benutzers ein Browser mit einem WebRTC-Client zusätzlich als Web-Videotelefon dienen kann, müssen seitens des Browsers sowohl vor als auch nach der WebRTC-Nutzung einige Schritte im Protokollverlauf durchlaufen werden. Bild illustriert diese Schritte für den Fall, dass zwischen WebRTC-Client und -Server das WS-Protokoll verwendet wird. Bild : Schritte vonseiten des Browsers vor und nach der WebRTC-Nutzung Req: Rsp: WS: Request Response WebSocket Die hier gezeigten Schritte sind kurz wie folgt zu charakterisieren: Schritt A: Aufbau einer TCP-Verbindung Das WS-Protokoll nutzt das verbindungsorientierte, zuverlässige 14

15 Transportprotokoll TCP. Aus diesem Grund muss zuerst mit dem WebRTC-Server eine TCP-Verbindung zwischen Browser und einem (Web-)Server aufgebaut werden. Anmerkung: Sollte aber das Secure WebSocket Protocol (WSS) zum Einsatz kommen, so wird in diesem Schritt noch zwischen Browser und (Web-)Server eine Vereinbarung nach dem Sicherheitsprotokoll TLS getroffen, um festzulegen, wie die TCP-Verbindung zwischen ihnen gesichert werden soll, d.h. wie die Vertraulichkeit und die Datenintegrität garantiert sowie die Authentifizierung durchgeführt werden sollen. Schritt B: Aufbau einer WS-Verbindung Nachdem die TCP-Verbindung zwischen dem WebRTC-Client im Browser und dem WebRTC-Server im (Web-)Server aufgebaut wurde, wird zwischen ihnen u.a. vereinbart, welches Signalisierungsprotokoll zum Einsatz kommt; genauer gesagt, von welchem Protokoll die Nachrichten in WS-Frames übermittelt werden. Diese Vereinbarung wird als WS- Verbindung angesehen. Sie wird seitens des WebRTC-Clients mit dem HTTP 13 -Request GET, welcher eine Zeile Upgrade: websocket enthält, initiiert. In dieser Zeile wird angegeben, dass es sich um eine WS-Verbindung handelt. Zusätzlich wird im Request GET z.b. in der Zeile Sec-WebSocket-Protocol: sip eingetragen, dass SIP als Signalisierungsprotokoll verwendet wird. Der WebRTC-Server antwortet auf den Request GET mit dem HTTP-Response 101 Switching Protocols, im dem u.a bestätigt wird, dass der WebRTC-Server das im GET vorgeschlagene Signalisierungsprotokoll SIP akzeptiert. Schritt C: Registrierung der aktuellen Lokation Diese Funktion entspricht der Registrar-Funktion bei VoIP mit SIP und soll bei WebRTC nach dem Beispiel von VoIP die Mobilität von Benutzern ermöglichen. Unter Registrierung 14 versteht man hier einen Vorgang, bei dem ein Benutzer in der SIP-Nachricht REGISTER dem Registrar angibt, wo und wie er aktuell erreichbar ist, z.b. mit dass er unter dem Hostnamen mond in der Domain abc.de erreichbar ist; oder mit dass er nur in der Domain abc.de 13 Hypertext Transfer Protocol 14 Für Näheres über die Registrierung bei VoIP sei auf den Abschnitt 7.6 in [1] verwiesen. 15

16 erreichbar ist. Bei WebRTC mit SIP sollte jeder Benutzer die Möglichkeit haben, verschiedene WebRTC-Clients als sog. User Agents (UAs) z.b. in allen seinen stationären Rechnern, in seinem Tablet-Computer und sogar in seinem Smart-TV wie seine Web-Videotelefone nutzen zu können; und diese können sich nicht nur in seiner DNS-Domain befinden, sondern auch in anderen Domains. Um so etwas erreichen zu können, muss dem permanenten Identifier SIP-URI des Benutzers in seiner Heimat- Domain oft als Address of Record (AOR) bezeichnet der URI eines aktuell genutzten WebRTC-Clients zugeordnet werden. Um das zu ermöglichen, soll das in RFC spezifizierte Konzept GRUU (Globally Routable User Agent URIs) bei WebRTC mit SIP unterstützt werden (vgl. IETF-Draft draft-ietf-sipcore-sip-websocket). Schritt D: Abbau der WS-Verbindung Wird der WebRTC-Client vorläufig nicht mehr benutzt, kann eine noch bestehende WS-Verbindung zum WebRTC-Server abgebaut werden. Den Abbau initiiert normalerweise der WebRTC-Client durch das Absenden von Close frame und darauf antwortet der WebRTC-Server ebenso mit Close frame. Nach dem Eintreffen von Close frame beim WebRTC- Client wird der Abbau der WS-Verbindung beendet; d.h. die beim Aufbau der WS-Verbindung zwischen WebRTC-Client und -Server getroffene Vereinbarung wird jetzt für nichtig erklärt. Schritt E: Abbau der TCP-Verbindung Nachdem die WS-Verbindung abgebaut wurde, wird die noch bestehende TCP-Verbindung abgebaut. Auf- und Abbau einer Session zwischen WebRTC-Clients Nachdem die vorbereitenden, in Bild gezeigten Schritte, zur WebRTC-Nutzung seitens beider WebRTC-Clients (entsprechend bei Alice und Bob) durchgeführt wurden, kann zwischen den beiden WebRTC-Clients eine Session für den Transport von Audio und Video aufgebaut werden. Bild zeigt, welche Schritte hierfür nötig sind. 15 siehe auch RFC

17 Bild : Auf- und Abbau einer Session zwischen WebRTC- Clients (SIP dient als Signalisierungsprotokoll) MT: SDP: Media Transport Session Description Protocol Es sei hervorgehoben, dass der hier gezeigte Verlauf den Einsatz des Signalisierungsprotokolls SIP bei WebRTC zeigt und demzufolge als Beispiel für SIP over WS oder auch für SIP over WSS betrachtet werden kann. 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: , Bestell-Nr. OL9142J 17