WebRTC: Standard für die Web-basierte Echtzeitkommunikation

Inhaltsverzeichnis

Ende 2010 startete ein an Hangout arbeitendes Google-Team mit WebRTC. Es hatte erkannt, dass Web-basierte Echtzeitkommunikation nur realistisch war, wenn Protokolle und APIs auf allen Browsern standardisiert sind. Das Projekt sollte darüber hinaus eine Annäherung der unterschiedlichen Philosophien sowohl im Web als auch in der traditionellen Kommunikationsindustrie fördern.

Das Google-Team beschloss daher, die einschlägigen Standardisierungsexperten der IETF (Internet Engineering Task Force) und des W3C (World Wide Web Consortium) zu einem Workshop in ihre Zentrale in Mountain View einzuladen, um "das Feld abzustecken". Das Echo der Branche war wohl positiver als erwartet – und dafür gab es verschiedene Gründe: Viele Kommunikationsunternehmen versuchten bereits 2010 Unified Communications Services in der Cloud zu implementieren und den Kunden Dienste per Webbrowser bereitzustellen.

Ohne Standardisierung war das jedoch nur über proprietäre Plug-ins möglich. Diese ließen sich zum einen jedoch nicht so einfach implementieren – man bedenke die unterschiedlichen Plug-ins für die verschiedenen Browser und Plattformen – und wurden zum anderen von vielen IT-Abteilungen in Unternehmen abgelehnt oder stießen dort zumindest auf wenig Gegenliebe. Ein weiterer Faktor, der während des IETF80-Meetings im März 2011 zur Sprache kam, waren die kürzeren Innovationszyklen, die in der Telekommunikationsbranche gefordert wurden, damit sie mit der Webwelt Schritt halten konnte.

Das von der IETF entwickelte Session Initiation Protocol (SIP) war zwar erfolgreich und fand weite Verbreitung bei IP-Phones, vielen Softphones und im Rahmen der 3GPP-Standards (3rd Generation Partnership Project) sogar im Mobilfunk. Dennoch ermöglichte SIP den Telekommunikationsanbietern nicht, der gleichen Innovationsdynamik nachzukommen, wie sie aus der Webbranche bekannt ist. Bis heute ist die Mobilindustrie im Bereich der Innovationsleistung an das Telekommunikationsmodell gekettet. Innovationen sind in der Telekommunikation deshalb so schwerfällig, weil neue Services in diesem Sektor zunächst die Erarbeitung neuer Standards durch die Standardisierungsinstanzen und deren Implementierung durch die Anbieter voraussetzen.

Dieser Prozess braucht Zeit und bedeutet, dass die gleichen Services gleichzeitig allen Anbietern zur Verfügung stehen, die sich dann lediglich noch über den Preis differenzieren. WebRTC hält sich jedoch nicht mit der Standardisierung der Signalisierungsprotokolle auf, sondern fokussiert sich direkt auf das Echtzeit-Medien-Handling im Web.

Warum ist WebRTC so bedeutend?

Es wurde viel darüber geredet, dass WebRTC als Technik sowohl die Consumer- als auch die Unternehmenskommunikation, einschließlich des Mobilfunks, revolutionieren wird. Das ist ein großes Versprechen für eine Technik, die im Wesentlichen nur einen Realtime Media Stack mitangeschlossener JavaScript-API umfasst.

Grund für das prognostizierte Potenzial ist schlichtweg, dass mit WebRTC Echtzeitkommunikation und insbesondere Echtzeit-Videokonferenzen zu einem neuen Werkzeug für Millionen von Webanwendungsentwicklern werden. Seine APIs sorgen dafür, dass Webentwickler die komplexe Funktionsweise von Echtzeitkommunikation nicht mehr selbst zu beherrschen brauchen. Stattdessen erhalten sie eine API in einer für sie verständlichen Sprache, die es ihnen ermöglicht, Sprachausgabe, Videos und Daten in jede beliebige Applikation einzubetten, an der sie arbeiten.

Dank dieser Funktionen im Browser lässt sich Echtzeitkommunikation in jede beliebige Webapplikation einbinde – ganz gleich, ob es sich um eine komplexe Geschäftsprozessanwendung oder eine Social-Media-Applikation handelt. Das wird als kontextbezogene oder kontextuelle Kommunikation bezeichnet und bedeutet, dass Echtzeitkommunikation im Zusammenhang mit dem erfolgt, was man gerade tut, und nicht ein bestimmtes separates Tool erfordert.

Architektur

Die Architektur von WebRTC

Das Wesen der WebRTC-Architektur besteht darin, dass die Übertragung und der Empfang von Audio-, Video- und anderen Daten zwischen WebRTC-Clients und ihren Peers in Echtzeit erfolgt. Das unterscheidet WebRTC zum Beispiel von Dynamic Adaptive Streaming over HTTP (DASH), was etwa beim IP-TV-Broadcasting gut funktioniert, weil hier entstehende Latenzen keine große Rolle spielen. DASH ist aber eben keine wirkliche Echtzeitkommunikation zwischen mehreren Menschen, wie man sie vom guten alten Telefon kennt.

Audio und Video nutzen bei WebRTC Standard-Codecs und werden sicher über DTLS-SRTP (Datagram Transport Layer Security, Secure Real-Time Transport Protocol) übertragen. Das clientseitige Anwendungsskript (JavaScript) ruft eine von W3C spezifizierte API auf, die den Browser anweist, Audio oder Video zwischen den lokalen Ein-/Ausgabegeräten (Mikrofon, Lautsprecher oder Kamera/Display) und einem entfernten Endpunkt via IETF-definierten Protokollen zu übermitteln. Es gibt jedoch noch weitere Faktoren zu berücksichtigen, wie Signalisierung, Konnektivitätsprüfung, NAT Traversal, Sicherheit und Codecs. Abbildung 1 zeigt die Basisarchitektur.

In der Abbildung wird die "Signalisierung", also das Anrufsignal, das Klingeln, das Annehmen oder Auflegen eines Anrufs, zwischen Client und Server dargestellt. Nur durch eine Serversignalisierung können sich Teilnehmer überhaupt finden, die sich in unterschiedlichen Netzen aufhalten. Da WebRTC einem Webmodell folgt, in dem nur die Grundbausteine standardisiert sind, ist das eigentliche Signalisierungsprotokoll für WebRTC nicht spezifiziert und die WebRTC-Anwendungsentwickler entscheiden selbst über das Design.

Die Tatsache, dass die Signalisierung zwischen WebRTC-Client und -Server nicht spezifiziert ist, hat für viel Diskussionsstoff gesorgt. Vielen Seiten haben diese Eigenschaft als Schwäche ausgelegt. De facto handelt es sich aber wohl um eine Stärke und eine bewusste Designentscheidung der IETF-Arbeitsgruppe, weil das Signalisierungsprotokoll dem Anwendungsentwickler überlassen bleibt, der es dann so einfach oder so komplex wie nötig ausarbeiten kann. Aus welchem Grund sollte eine einfache Kommunikationsanwendung im Consumer-Bereich mit derselben Komplexität belastet werden wie eine professionelle und sichere Unternehmenssoftware? Dort wird zum Beispiel beim Wechsel von Wi-Fi auf 4G/3G der Medienstrom nahezu unterbrechungsfrei wiederhergestellt, weil eben alternative WebRTC-Medienkanäle dem Server von Client bereits signalisiert wurden.

Der Verzicht auf Standardisierung auf der Signalisierungsebene ermöglicht Innovationen in einem Tempo, die es sonst nur im Web gibt. Und die Branche kann sich nun endlich von den gewohnt langsamen Innovationszyklen traditioneller Telekommunikation befreien.

Ein weiteres Thema ist die Medienebene: WebRTC kann direkte Medienverbindungen zwischen Browsern herstellen. Die Funktion muss für alle Browser gleich sein und erfordert deshalb eine Standardisierung – eine Aufgabe der IETF. Die Tatsache, dass WebRTC direkte Verbindungen zwischen Browsern ohne ein Plug-in erlaubt, ist neu im Web. Das war bisher nicht denkbar. Damit gehen jedoch Sicherheitsimplikationen einher, die die Standardisierungsinstanzen in Angriff nehmen.

Eine weitere zu standardisierende Komponente der WebRTC-Architektur ist die Browser-API. Sie ist Voraussetzung dafür, dass WebRTC-Anwendungen browserunabhängig arbeiten können, und fällt unter die Zuständigkeit der WebRTC-Arbeitsgruppe des W3C.

Nächster Schritt Sicherheit

Bei internetspezifischer Standardisierung dreht sich alles um Sicherheit und Datenschutz. Auch im Zusammenhang mit WebRTC war das stets die größte Sorge von IETF und W3C. Wie erwähnt ist WebRTC die erste Technik, die direkte Verbindungen von Browser zu Browser unterstützt. Darüber hinaus erfordern WebRTC-Anwendungen möglicherweise Zugriff auf ein Mikrofon, eine Kamera oder – im Falle von Bildschirmfreigabe-Anwendungen – sogar auf den Bildschirm. Man braucht nicht viel Fantasie, um sich vorzustellen, dass der Missbrauch dieser Funktionen durch eine bösartige Webapplikation verheerende Folgen haben würde.

Das ist einer der Gründe, weshalb die WebRTC-Standardisierung so viel Zeit in Anspruch genommen hat. Die Browser-Anbieter mussten darauf vertrauen können, dass eine verlässliche Sicherheitslösung zur Verfügung steht. Um zu verhindern, dass bösartige Webserver einen Browser hacken und unerwünschte Medien an andere Browser versenden können, wurde ein besonderes Verfahren umgesetzt: Dabei muss der Sender-Browser zunächst das Einverständnis des Empfänger-Browsers einholen, bevor er Daten übertragen kann. Dieses Verfahren ist im RFC 7675 dokumentiert.

Nachdem eine Vertrauensbeziehung zwischen zwei WebRTC-Teilnehmern hergestellt wurde, muss aber noch der entstehende Medienstrom sicher verschlüsselt sein. Dazu werden WebRTC-Medien (Audio, Video und Daten) standardmäßig über das DTLS-SRTP-Verfahren verschlüsselt. Die zunehmende Verbreitung von Verschlüsselungstechniken in der Kommunikation ist ein heftig diskutiertes Thema, nicht zuletzt auf staatlicher Ebene. In den WebRTC-Standardisierungsinstanzen stand die Entscheidung über eine generelle Verschlüsselung nie zur Debatte. Die bisherigen Erfahrungen mit SIP hatten gezeigt, dass die Komplexität aufgrund optionaler Verschlüsselung eine Always-on-Politik für WebRTC zur einfachen Entscheidung machte. Es wird also keine unverschlüsselten WebRTC-Medienströme geben.

WebRTC wird mobil

Zu Beginn des WebRTC-Projekts stellten sowohl IETF als auch W3C die Browserinteroperabilität in den Mittelpunkt. Bald zeigte sich jedoch, dass das eigentliche Ziel darin bestand, WebRTC mobilfähig
zu machen. Und in der mobilen Welt sind native Anwendungen, nicht Webapplikationen, nach wie vor vorherrschend. Ferner beteiligte sich Apple, mit seinem erheblichem Marktanteil, nicht an der WebRTC-Initiative. Viele hegten deswegen die Befürchtung, dass dies die WebRTC-Implementierung bremsen könnte.

Diese Bedenken erwiesen sich jedoch als falsch. Die Wahrheit ist wohl eher, dass das Wegbleiben von Apple nur geringen oder überhaupt keinen Einfluss auf den Erfolg von WebRTC in mobilen Anwendungen hat. Viel wahrscheinlicher ist, dass bereits eine Reihe von Anwendungen auf dem Mobilgerät genutzt werden, die mit WebRTC arbeiten.

Google hatte frühzeitig erkannt, dass WebRTC ohne robuste Lösung für mobile Geräte, ob iOS- oder Android-basiert, nicht erfolgreich sein würde. Deshalb engagierte sich das Unternehmen massiv zugunsten dieser Plattformen. So sind viele WebRTC-Implementierungen, zumindest die der Open-Source-Browser, frei zugänglich. Das ermöglicht Entwicklern, mit wenig Aufwand einen WebRTC-Stack auch beispielsweise in einer Smartphone-App, außerhalb eines Browsers, zu implementieren.

Die fehlende Unterstützung durch Apple behinderte die Verbreitung von WebRTC auf mobilen Endgeräten also nicht. Gerüchte in der WebRTC-Standards-Community deuten vielmehr darauf hin, dass Apple seine Haltung allmählich ändert, und so ist es wahrscheinlich, dass 2016 eine Annäherung des Konzerns an WebRTC geschehen könnte.

Standardisierung und Implementierung heute

Mehr als fünf Jahre sind mittlerweile vergangen, seit der Startschuss für das WebRTC-Projekt fiel, und bisher sind die WebRTC-1.0-Standards noch nicht abschließend fertiggestellt. In der Webwelt wartet jedoch niemand auf die Ratifizierung von Standards. Man folgt stattdessen dem agilen Entwicklungsmodell, bei dem Erprobung, Implementierung und Standardisierung schrittweise nebeneinander verlaufen und auf diese Weise ein hohes Innovationstempo ermöglichen. Unify zum Beispiel begleitet den Prozess mit WebRTC seit mehreren Jahren. Die Erfahrungen aus der Prototyparbeit und der seit Oktober 2014 verfügbaren Kollaborations-Cloud Circuit fließen in den Standardisierungsprozess zurück.

Führend in puncto Browserunterstützung für WebRTC ist eindeutig Chrome, dicht gefolgt von Firefox und Opera, die alles daran setzen, mit Google Schritt zu halten. WebRTC 1.0 sollte in wenigen Monaten abgeschlossen sein. Bis Ende 2016 sind die ersten standardkonformen Implementierungen in den Browsern zu erwarten.

Microsoft hatte am Anfang Schwierigkeiten, eine klare Entscheidung bezüglich seiner WebRTC-Strategie zu fällen. Die Übernahme von Skype, gerade als WebRTC allmählich Fahrt aufnahm, erschwerte die Entscheidung zusätzlich, da Skype auf keinen offenen Standards setzt. Mittlerweile hat Microsoft jedoch deutlich gemacht, dass das Unternehmen als Teil der WebRTC-Initiative wahrgenommen werden möchte, auch wenn es einen etwas anderen Weg als die anderen Browseranbieter geht.

ORTC und cPaaS

Was ist ORTC, und was hat es mit WebRTC zu tun?

ORTC (Object-Based Real-Time Communications) ist eine W3C-Community-Gruppe, die mit verschiedenen Aspekten der WebRTC-Lösung, wie sie von der WebRTC-Hauptarbeitsgruppe vorgeschlagen wurden, nicht einverstanden ist. Vor allem aber wird ORTC als Community-Gruppe nicht durch das W3C bei der Erstellung einer Standard-Track-Spezifikation reglementiert. Microsoft beschloss deshalb rasch, die Arbeit von ORTC zu unterstützen und ORTC im eigenen Edge-Browser zu implementieren.

Einige Ergebnisse der ORTC-Bemühungen wurden mittlerweile in die WebRTC-Mainstream-API des W3C übernommen. Dennoch ist es nicht möglich, WebRTC-Anwendungen auf einem ORTC-basierten Browser wie Edge ohne zusätzliche JavaScript-Zwischenebene zur Emulation der WebRTC-API einzusetzen. Erfreulicherweise ist diese Zwischenebene derzeit in Arbeit.

ORTC und WebRTC sind hinsichtlich der Medienebene identisch. Deshalb sollten ORTC- und WebRTC-Implementierungen interoperabel sein. Gegenwärtig gibt es jedoch auf der Medienebene, insbesondere bei der Videointeroperabilität, verschiedene Kompatibilitätsprobleme zwischen Edge und anderen WebRTC-Browsern. Sobald die derzeit laufenden Arbeiten an WebRTC 1.0 abgeschlossen sind, ist zu erwarten, dass sich WebRTC Next Version (WebRTC NV) und ORTC weiter annähern.

Was ist WebRTC PaaS und eine kollaborative PaaS?

Die WebRTC-API des W3C erleichtert es einem hinreichend kompetenten Webentwickler, eine Anwendung zu schreiben, die eine Peer-to-Peer-Audio-, -Video- oder -Datenverbindung zwischen Browsern herstellen kann. Das WebRTC-Projekt von Google ermöglicht die Erweiterung einer entsprechenden Anwendung auf mobile Plattformen. Es ist jedoch deutlich komplexer, robuste Videokonferenzanwendungen zu entwickeln, die auch für große Teilnehmerzahlen funktionieren. Da ferner kein Signalisierungs-Stack in WebRTC eingebaut ist, sind Spezialkenntnisse notwendig, um Anwendungen zu entwickeln, die die Zusammenarbeit mit herkömmlichen Unternehmenssystemen oder der öffentlichen PSTN-Telefonie (Public Switched Telephone Network) unterstützen.

Eine Möglichkeit, diese Hindernisse zu umgehen und WebRTC-Applikationen zu implementieren, besteht darin, eine WebRTC-Plattform und -API einzusetzen, die ein Anbieter entwickelt hat, der über diese Fähigkeit verfügt und diesen Dienst auch anderen zur Verfügung stellt. Ein solcher Dienst wird als WebRTC Platform as a Service (PaaS) bezeichnet und ist bereits bei verschiedenen Anbietern im Programm.

Mithilfe von WebRTC PaaS kann ein Anwendungsentwickler eine API nutzen, die eine höhere Abstraktionsebene aufweist als die WebRTC-API des W3C. Komplexe Elemente wie das für traditionelles PSTN-Interworking benötigte Signalisierungssystem werden dabei verborgen. Der PaaS-Anbieter stellt zudem skalierbare, robuste Cloud-Services bereit, die zur Einrichtung zuverlässiger Multi-Party-Konferenzsysteme notwendig sind.

Möchte man die WebRTC-Kommunikation darüber hinaus in Bezug zu einer Team-Kollaboration, Dokumenten oder gar Business-Events aus ERP-, CRM- und IoT-Systemen bringen, benötigt man mehr als ein WebRTC PaaS. Eine Team-Kollaboration-Cloud muss ein Datenmodell zur Verfügung stellen, das diesen Business-Kontext sicherstellt. Das findet man beispielsweise bei Circuit und seiner collaborative PaaS (cPaaS) mit dem Konversationsansatz. Eine WebRTC-Videokonferenz findet zum Beispiel mit der gleichen Gruppe von Teilnehmern statt, die auch zusammen über ein bestimmtes Thema chattet oder Dokumente austauscht.

Fazit

WebRTC spielt zweifelsohne eine Schlüsselrolle in der Kommunikationsindustrie, die mobile Welt eingeschlossen. Die erste Phase der WebRTC-Standardisierung gilt es noch abzuschließen, jedoch hat sie schon heute irreversiblen Einfluss auf Hunderte von Unternehmen, die ihren Kunden WebRTC-Anwendungen anbieten. WebRTC hat den Trend in Richtung Cloud-Kommunikationsdienste wie Unified Communications as a Service (UCaaS) beschleunigt oder moderne Team-Kollaboration erst ermöglicht, Tendenz weiter steigend.

Die WebRTC-1.0-Standardisierung sollte noch 2016 abgeschlossen sein. Die Konvergenzen zwischen WebRTC und ORTC (Google und Microsoft) werden danach aller Voraussicht nach zunehmen und eine durch und durch standardisierte WebRTC-Technik für sämtliche Browser und Plattformen zur Folge haben.

Der Einfluss von WebRTC ist bereits erheblich. In den kommenden Jahren wird zu beobachten sein, wie WebRTC die Unternehmens- und mobile Kommunikationsbranche weiter verändern wird.

Andrew Hutton
ist Leiter der Standardisierung bei Unify. In dieser Rolle leitet er das Engagement von Unify in Organisationen IETF und W3C, die Standards wie WebRTC weiterentwickeln.

Referenzen & Links

• IETF-RTCWeb-Arbeitsgruppe
• W3C-WebRTC-Arbeitsgruppe
• IETF WebRTC in der Übersicht
• Googles WebRTC-Projekt
• WebRTC-Beispiele
• W3C-ORTC-Community-Gruppe
• Circuit von Unify

(ane)