Sie sind auf Seite 1von 2

Know-how | WebRTC

Herbert Braun

Anruf aus dem WWW


Echtzeit-Kommunikation zwischen Browsern mit WebRTC

Bisher bernehmen Anwendungen wie Skype, Google Hangouts oder AOL Instant Messenger die Echtzeit-Kommunikation. Sie sind fest verdrahtet mit ihren Diensten und eher in eigenen Programmen und Apps als im Web zu Hause. WebRTC hat das Zeug dazu, sie durch dezentrale Kommunikationsnetzwerke auf Grundlage offener Standards zu ersetzen.

gal, ob Chat bei der gemeinsamen Arbeit an Dokumenten, Screen Sharing bei technischen Problemen oder MultiplayerOnlinespiele WebRTC knnte alles wesentlich vereinfachen und vereinheitlichen. Dieses Bndel von Protokollen und Programmierschnittstellen soll es Entwicklern ermglichen, Echtzeitanwendungen ins Web zu bringen direkt im Browser und ohne Plug-in oder Zusatzsoftware. Neben (Video-) Telefonie soll das auf Peer-to-Peer-Verbindungen (P2P) setzende WebRTC auch andere Anwendungen ermglichen, beispielsweise Dateiaustausch. Die Kommunikation per WebRTC luft zudem grundstzlich verschlsselt ab, was in Verbindung mit dem P2P-Prinzip vor dem derzeitigen politischen Hintergrund stark fr WebRTC und gegen proprietre MessagingLsungen spricht. ber SIP gibt es ein Tor zur Welt der Festnetz- und Mobiltelefone statt Telefonnummern umstndlich von Websites abzutippen, ruft der Benutzer einfach per Browser an.

Grobaustelle
WebRTC ist in vielerlei Hinsicht noch eine Baustelle. So knnen bislang berhaupt nur Chrome und Firefox per WebRTC kommunizieren, auch in den aktuellen Android-Versionen der Browser, sowie Chrome OS. Bildschirmaufzeichnung zwecks Screen Sharing beherrscht bislang nur Chrome, und auch bei diesem muss man dieses Feature erst in chrome://flags unter Untersttzung fr Bild-

schirmaufzeichnung in getUserMedia() aktivieren freischalten. Firefox liegt beim Datenkanal vorne, mit dem man sich parallel zum Chat beispielsweise Dateien oder Spielstnde eines Multiplayer-Games zuschicken kann. Dieser existiert zwar ebenfalls in Chrome, kann dort aber keine Binrdaten und offenbar nur circa 1000 Bytes auf einmal bermitteln. Anders als in diversen Foren zu lesen, versteht Opera weder in Version 12 mit PrestoEngine noch in Version 15 oder 16 auf Chromium-Basis WebRTC; die Norweger knnen mit Presto einzig die Kamera ansprechen. Bei der WebKit-Gemeinde sitzen einige Entwickler an einer WebRTC-Implementierung ob und wann diese Teil von Safari wird, kann nur Gegenstand von Spekulationen sein. iOS-Gerte vermgen durchaus ber WebRTC zu kommunizieren, allerdings nicht durch den Browser, sondern durch Apps: Diverse SDKs bringen Entwicklern die notwendigen Funktionen. Mit dem Open-SourceProjekt webrtc4all [1] knnen Windows-Anwender ein Browser-Plug-in nachrsten, das auch Internet Explorer, Opera und Safari WebRTC beibringen soll; auf unserem Testrechner funktionierte das allerdings nicht. Die Zurckhaltung beim Internet Explorer hat nicht nur mit der traditionellen Zgerlichkeit Microsofts bei neuen Internettechniken zu tun. Tatschlich hat der Software-Konzern sogar einen konkurrierenden Standard (CU-RTC-Web) entworfen, was sich schwerlich anders interpretieren lsst denn als Versuch, WebRTC aufzuhalten. Auf dem Spiel stehen immerhin 8,5 Milliarden US-Dollar

diesen Betrag gab Microsoft im Herbst 2011 fr Skype aus. brigens macht Google sich mit WebRTC auch selbst Konkurrenz, denn schlielich betreibt das Unternehmen mit Hangouts einen vielgenutzten Chat- und VideokonferenzDienst. Das scheint es jedoch nicht davon abzuhalten, WebRTC engagiert voranzutreiben. Google hat den Standard ursprnglich beim W3C eingereicht. WebRTC hat derzeit den Status eines sogenannten Editors Draft, ist also alles andere als fertig, erfhrt aber breite Untersttzung durch die Industrie. So ist auch die IETF mit ihrer Rtcweb-Arbeitsgruppe an Bord. Einen Eindruck davon, wie komplex es ist, WebRTC in Browser einzubauen, gibt die Liste bekannter Einschrnkungen, die Mozilla zum Start der WebRTC-Untersttzung mit Firefox 22 verffentlichte[2]: Gruppen-Chats leiden an lahmer Performance, im Rechner abgespielte Klnge verursachen Echos, Audio und Video sind nicht immer synchron und bei Nutzern von Netzwerken mit besonders restriktiven Richtlinien funktioniert WebRTC gar nicht. Dazu kommen noch kleine Inkompatibilitten zwischen Firefox und Chrome.

Komplexer Unterbau
Hauptproblem bei der Umsetzung von WebRTC ist, die vielen daran beteiligten Protokolle umzusetzen und aufeinander abzustimmen, damit der Webentwickler mglichst viel Freiheit bei den Details der Datenbermittlung bekommt. So kann die Ver-

170
Copyright by Heise Zeitschriften Verlag

ct 2013, Heft 19

Know-how | WebRTC

bindungsanfrage und -besttigung ber beliebige Transportprotokolle laufen. Typische Kandidaten wren das fr VoIP viel genutzte SIP sowie Jingle, eine P2P-Erweiterung des Chat-Protokolls XMPP (Jabber). Eine Alternative wre zum Beispiel Socket.io mit einem Node.js-Server; selbst Ajax lsst sich einsetzen. Das Gesprchsangebot selbst ist in Form einer SDP-Anfrage formuliert. Das Session Description Protocol enthlt unter anderem Informationen ber Ports und Protokolle fr die verwendeten Medien-Streams, ber Routing und Bandbreiten. Auch die Besttigung muss in Form von SDP kommen. Ein Problem fr alle P2P-Dienste ist die Network Address Translation (NAT): Wegen der Knappheit der alten IPv4-Adressen weisen Router ihren Clients interne IP-Adressen zu und bersetzen diese in eine einzige nach auen sichtbare. Eine P2P-Verbindung muss NAT berwinden (NAT-Traversal), wozu WebRTC wie einige bereits etablierte VoIPTechniken das Framework Interactive Connectivity Establishment (ICE) nutzt. ICE hat zwei Tricks in petto, von denen STUN (Session Traversal Utilities for NAT) der bevorzugte ist. Damit fragt der Client bei einem ffentlichen STUN-Server an, welche IP-Adresse bei diesem angekommen ist, und versucht mit dieser, eine P2P-Verbindung aufzubauen erst ber UDP, dann ber TCP. Laut Google-Statistiken klappt das in sechs von sieben Fllen. Fr die brigen weicht ICE auf TURN (Traversal Using Relays around NAT) aus, bei dem sich ein Server zwischen die Peers klemmt und den gesamten Verkehr durchleitet; dies funktioniert unter fast allen Netzwerkkonfigurationen, verursacht jedoch Last auf dem Server. Wer eine professionelle WebRTC-Anwendung baut, sollte ber einen eigenen STUN/TURN-Server nachdenken. Lsungen gibt es sogar als Fertigpakete fr die Amazon-Cloud-Dienste. brigens ist auch abgesehen von TURN nicht jede WebRTC-Verbindung im strengen Sinn P2P. Bei Konferenzen mit mehreren Teilnehmern msste sonst jeder seine Daten an alle anderen senden, was erheblich Bandbreite und Gerteleistung erforderte. Stattdessen kann ein einzelner Teilnehmer mit leistungsfhiger Hardware als zentraler Verteiler agieren oder man schaltet einen Sternverteiler (MCU, Multipoint Control Unit) dazwischen.

Mit WebRTC lassen sich zum Beispiel Screensharingdienste wie talky realisieren.

Algorithmus. Beim Verschlsselungsprotokoll setzte Chrome anfangs auf das etwa in Skype eingesetzte SDES, bei dem die vermittelnde Website die Schlssel verwaltet. Mozilla und schlielich auch Google wechselten aber zu DTLS, einen fr UDP geeigneten Ableger von TLS. Hier handeln die Peers untereinander die Schlssel aus, was mehr Sicherheit verspricht. Nach harten Auseinandersetzungen hat die IETF im August 2013 DTLS fr WebRTC vorgeschrieben.

Live is live
Lizenz- und Patentprobleme bei Audio- und Video-Codecs fhrten im W3C schon einmal zu Zerwrfnissen letztlich berlie man das Problem den Browser-Herstellern, was Multimedia in HTML5 erheblich behindert. Bei WebRTC scheint es anders zu laufen: In den Spezifikationsentwrfen der IETF vorgeschrieben ist der Audio-Codec Opus, der unter der Regie der IETF aus zwei unabhngigen Entwrfen von Skype/Microsoft und der fr das Ogg-Format bekannten Stiftung Xiph.org entstand. Trotz seiner komplizierten Vorgeschichte ist aus Opus ein hervorragender Codec geworden, der bei groer Bandbreite den Vergleich mit den blichen Musik-Codecs nicht zu scheuen braucht, aber auch schon mit 6kBit/s nutzbar ist. Die zwei von Google vorgeschlagenen Codecs iLBC und iSAC sind ein wenig ins Hintertreffen geraten, aber ebenfalls an Bord. Die IETF verlangt Kompatibilitt
Video Audio JavaScriptAPI Protokolle/ V8 Codecs: W3C IETF ITU andere getUserMedia iSAC, iLBC Opus PCMA/PCMU DTMF Daten

zu den Telefonnetzen daher untersttzt WebRTC auch das dort gngige ITU G.711 mit den Codecs A-law (PCMA) und -law (PCMU) sowie das Tonwahlverfahren DTMF. Bei Video-Codecs gibt es noch keine Einigung. Aktuelle Implementierungen nutzen VP8, das Google eingekauft und unter OpenSource-Lizenz gestellt hat. Das Paket mit quelloffenen Techniken, das Google Anwendungsentwicklern unter www.webrtc.org zur Verfgung stellt, enthlt alle die genannten Codecs und Programmierbibliotheken fr diverse Zwecke. RTCDataChannels, der Kanal fr den mglichst verzgerungsfreien Austausch von Daten, sttzt sich mageblich auf eine verwandte Webtechnik: WebSockets. Die Spezifikation lsst dem Entwickler die Wahl zwischen einer Variante auf UDP- und TCP-Basis. Erstere ist schneller, kann aber nicht gewhrleisten, dass alle Daten garantiert beim Empfnger ankommen fr Multiplayer-Onlinespiele, wenn Spielereignisse rasch durch die Leitung gehen mssen, kann das zum Beispiel die bessere Variante sein. Die zuverlssige Datenbertragung dagegen gewhrleistet TCP. (jo) Literatur
[1]webrtc4all: http://code.google.com/p/webrtc 4all/ [2]WebRTC in Firefox 22: https://hacks.mozilla. org/2013/06/webrtc-comes-to-firefox/

www.ct.de/1319170
Transport Session Management RTCPeerConnection SRTP ICE (STUN + TURN) UDP ROAP JSEP SDP XMPP/Jingle SIP WebSockets

Sendung luft
Das Protokoll fr die bertragung der Audiound Videodaten, das Real-time Transport Protocol (RTP), hat sich bereits bei anderen VoIPTechniken wie SIP bewhrt. Das seit den 90erJahren etablierte Protokoll setzt in der Transportschicht auf IP und (meistens) UDP. RTP eignet sich fr Einzel- wie fr Gruppengesprche und kommt auch viel bei Streaming Media zum Einsatz, etwa im Flash Player. Genauer gesagt ist es die verschlsselte RTP-Variante SRTP, welche die Streams transportiert. Fr Abhrsicherheit sorgt der AESRTCDataChannels

Der Entwickler greift ber das JavaScript-API auf WebRTC zu und muss sich nicht mit den vielen beteiligten Protokollen auseinandersetzen.

c
171

ct 2013, Heft 19
Copyright by Heise Zeitschriften Verlag