WebRTC ist eine Technologie, die es erlaubt, direkt aus Internet-Browsern heraus Audio- und Video-Verbindungen aufzubauen. Sie wurde im Jahr 2011 von Google als Open Source Projekt veröffentlicht und wird seither stetig weiterentwickelt und standardisiert. Diese Technik ist in modernen Browsern wie Opera, Chrome und Firefox von Haus aus enthalten. Und weil sie eine Kommunikation ohne anderweitige Geräte ermöglicht, erfreut sie sich immer grösserer Beliebtheit; der Browser benötigt lediglich Zugriff auf das Headset. Die Installation von Softphones oder Tischtelefonen entfällt. Doch wie funktioniert WebRTC eigentlich?
Architektur von WebRTC
WebRTC (Web Real-Time Communication) wird in Form von JavaScript-APIs zur Verfügung gestellt. Mit denjenigen Browsern, welche WebRTC unterstützen, lassen sich damit nicht nur Audio- und Video-Verbindungen bewerkstelligen, sondern auch anderes wie Chat, Screen-Sharing und Dateitransfers. Die dafür zuständigen APIs heissen:
- MediaStream -> Zugriff auf Kamera und Headset des Browsers
- RTCPeerConnection -> Audio- und Video-Übertragungen
- RTCDataChannel -> Übertragungsmöglichkeit für generische Daten
Allerdings funktionieren nicht alle diese APIs mit jeder Plattform; einige Browser haben bisher nur Teile davon umgesetzt. Den aktuellen Stand der Implementationen muss man jeweils den Release-Notes der einzelnen Browser entnehmen.
Zusätzlich zu den oben genannten Möglichkeiten benötigt WebRTC natürlich auch Signalisierung, um Übertragungen zu steuern, Netzwerkkonfigurationen auszutauschen und Codecs zu verhandeln. Diese Signalisierung ist im WebRTC-Standard explizit nicht enthalten. Es ist also freigestellt, welche Signalisierung man verwenden will. Zur Auswahl stehen einige, unter anderen SIP und XMPP. Übertragen werden diese Protokolle innerhalb gesicherter Verbindungen, die nur für die beiden in der Unterhaltung involvierten Computer zugänglich sind. Vielfach werden hierfür WebSockets eingesetzt. (WebSockets ist eine Technik, die Webservern ermöglicht, Verbindungen zu Clients offen zu halten und diesen darüber asynchrone Nachrichten senden zu können.)
Externe Server für WebRTC
Obwohl WebRTC Verbindungen eigentlich Peer-zu-Peer-Verbindungen sind, werden zumindest für den Verbindungsaufbau oft externe Server zu Hilfe gezogen. Diese sind:
- STUN-Server (Session Traversal Utilities for NAT)
Solche Server werden verwendet, um die eigene, öffentliche IP-Adresse (ausserhalb des eigenen Netzwerks) ausfindig zu machen, also «unter welcher Adresse sieht mich die Aussenwelt?» - ICE-Server (Interactive Connectivity Establishment)
Diese Server ermitteln die beste Verbindungsmöglichkeit für Verbindungen zwischen zwei Computern. Konkret versuchen sie die Computer zuerst direkt zu verbinden, wenn das aber nicht geht, ermitteln sie die öffentlichen IP-Adressen der Computer und versuchen es dann so. Schlägt das auch fehl, schalten sie einen TURN Server dazwischen. - TURN-Server (Traversal Using Relay NAT)
Ist keine direkte Verbindung zwischen zwei Computern möglich, kommen TURN-Server als Relais zum Einsatz. Der ganze (S)RTP Datenverkehr zwischen den Computern wird dann über solche Server geleitet.
Wie werden WebRTC Verbindungen aufgebaut?
Mit diesem Rüstzeug können Webbrowser nun Verbindungen zu anderen WebRTC-Partnern herstellen. Und zwar geht das (etwas vereinfacht) so:
Aufbau eines Signalisationskanals
- Unabhängig vom WebRTC baut Browser A zuerst auf irgendeine Art einen Signalisationskanal zu B auf. Bei diesem Vorgang kann ein Webserver involviert sein, über welchen die User die passende Gegenstelle auswählen können, das muss aber nicht so sein. Vielleicht kennt ja Browser A die IP-Adresse von B und kann so die Signalisations-Verbindung direkt aufbauen. Diese «Signalisierung» ist nicht im WebRTC-Standard enthalten und erfolgt somit unabhängig davon, auf nicht vorgeschriebene Art und Weise. Das Resultat dieses Vorgangs ist auf jeden Fall ein etablierter Signalisationskanal, über welchen die Gegenstellen Meldungen austauschen können.
Ermitteln der eigenen Zugänge
- Die Gegenstellen ermitteln dann ihre so genannten «ICE Kandidaten». ICE-Kandidaten sind Kombinationen von IP-Adressen und Ports, über welche die Computer von intern oder von extern, also von ausserhalb allfälliger Firewalls, erreicht werden können. Dazu müssen STUN- und ICE-Server involviert werden, nämlich um einerseits die eigenen, öffentlichen IP-Adressen zu ermitteln (STUN) und andererseits die externen Zugänge zu finden und zu testen (ICE).
- Bei diesem Vorgang kommt unter anderem auch eine als «Hole punching» bekannte Technik zum Einsatz. Die Server stellen dabei die Session-Daten, die sie für die Kommunikation mit einer der Gegenstellen verwenden, der anderen Gegenstelle zur Verfügung. Diese kann so den Rückkanal der Verbindung der anderen Gegenstelle zum Server nutzen, um eine allfällige Firewall zu durchbrechen.
- Resultat dieses Vorgangs ist also je eine Liste von IP-Adressen und Ports, welche für den Media-Kanal verwendet werden können.
Verständigung auf den Media-Stream
- Die beiden Peers verständigen sich in der Folge auf die zu verwendenden ICE-Kandidaten, also auf die zu verwendenden IP-Adressen und Ports für die Übertragung der Media-Daten. Das beinhaltet auch einige zusätzliche Verbindungseigenschaften wie z.B. den zu verwendenden Codec. Ziel ist eine möglichst schnelle Peer-zu-Peer-Verbindung, also möglichst ohne Umwege.
- Falls aber die gefundenen ICE-Kandidaten beider Seiten nicht zusammenpassen, kommt keine direkte Peer-zu-Peer-Verbindung zustande. In diesen Fällen involviert der Prozess einen TURN-Server als Relais, über welchen der Media-Stream laufen kann.
Aufbau der Media-Verbindung
- Sind obige Vorgänge erfolgreich abgeschlossen, können die gefundenen Media-Kanäle für die Kommunikation verwendet werden. Diese erfolgt dann mit einem der Protokolle RTP oder SRTP.
Möglichkeiten mit WebRTC
Anwendungen für WebRTC gibt es viele. Seien es einfache Browser-Browser-Kommunikationen, Online-Spiele, Screen-Sharing-Anwendungen oder vollwertige Vermittlungslösungen: es wird allgemein erwartet, dass sich die WebRTC-Technologie in der nächsten Zeit breit durchsetzt.
Weitere Artikel zum Thema WebRTC
Getting Started with WebRTC
WebRTC in the real world: STUN, TURN and signaling
An Intro to WebRTCs NAT/Firewall Problem
