Seite 2: Architektur

Inhaltsverzeichnis

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.