Egal, ob Chat bei der gemeinsamen Arbeitan Dokumenten, Screen Sharing beitechnischen Problemen oder Multiplayer-Onlinespiele WebRTC knnte alles wesent-lich vereinfachen und vereinheitlichen. Die-ses Bndel von Protokollen und Program-mierschnittstellen soll es Entwicklern er-mglichen, Echtzeitanwendungen ins Webzu bringen direkt im Browser und ohnePlug-in oder Zusatzsoftware. Neben (Video-)Telefonie soll das auf Peer-to-Peer-Verbin-dungen (P2P) setzende WebRTC auch an -dere Anwendungen ermglichen, beispiels-weise Dateiaustausch.

Die Kommunikation per WebRTC luftzudem grundstzlich verschlsselt ab, was inVerbindung mit dem P2P-Prinzip vor demderzeitigen politischen Hintergrund stark frWebRTC und gegen proprietre Messaging-Lsungen spricht. ber SIP gibt es ein Tor zurWelt der Festnetz- und Mobiltelefone stattTelefonnummern umstndlich von Websitesabzutippen, ruft der Benutzer einfach perBrowser an.

GrobaustelleWebRTC ist in vielerlei Hinsicht noch eine Baustelle. So knnen bislang berhaupt nur Chrome und Firefox per WebRTC kommuni-zieren, auch in den aktuellen Android-Ver -sionen der Browser, sowie Chrome OS. Bild-schirmaufzeichnung zwecks Screen Sharingbeherrscht bislang nur Chrome, und auch beidiesem muss man dieses Feature erst in chrome://flags unter Untersttzung fr Bild-

schirmaufzeichnung in getUserMedia() akti-vieren freischalten. Firefox liegt beim Daten-kanal vorne, mit dem man sich parallel zumChat beispielsweise Dateien oder Spielstndeeines Multiplayer-Games zuschicken kann.Dieser existiert zwar ebenfalls in Chrome,kann dort aber keine Binrdaten und offenbarnur circa 1000 Bytes auf einmal bermitteln.

Anders als in diversen Foren zu lesen, ver-steht Opera weder in Version 12 mit Presto-Engine noch in Version 15 oder 16 auf Chro-mium-Basis WebRTC; die Norweger knnenmit Presto einzig die Kamera ansprechen. Beider WebKit-Gemeinde sitzen einige Entwick-ler an einer WebRTC-Implementierung obund wann diese Teil von Safari wird, kann nurGegenstand von Spekulationen sein.

iOS-Gerte vermgen durchaus berWebRTC zu kommunizieren, allerdings nichtdurch den Browser, sondern durch Apps: Diverse SDKs bringen Entwicklern die not-wendigen Funktionen. Mit dem Open-Source-Projekt webrtc4all [1] knnen Windows-An-wender ein Browser-Plug-in nachrsten, dasauch Internet Explorer, Opera und SafariWebRTC beibringen soll; auf unserem Test-rechner funktionierte das allerdings nicht.

Die Zurckhaltung beim Internet Explorerhat nicht nur mit der traditionellen Zger-lichkeit Microsofts bei neuen Internettechni-ken zu tun. Tatschlich hat der Software-Kon-zern sogar einen konkurrierenden Standard(CU-RTC-Web) entworfen, was sich schwer-lich anders interpretieren lsst denn als Ver-such, WebRTC aufzuhalten. Auf dem Spielstehen immerhin 8,5 Milliarden US-Dollar

diesen Betrag gab Microsoft im Herbst 2011fr Skype aus.

brigens macht Google sich mit WebRTCauch selbst Konkurrenz, denn schlielich be-treibt das Unternehmen mit Hangouts einenvielgenutzten Chat- und Videokonferenz-Dienst. Das scheint es jedoch nicht davon ab-zuhalten, WebRTC engagiert voranzutreiben.Google hat den Standard ursprnglich beimW3C eingereicht. WebRTC hat derzeit denStatus eines sogenannten Editors Draft, istalso alles andere als fertig, erfhrt aber breiteUntersttzung durch die Industrie. So istauch die IETF mit ihrer Rtcweb-Arbeitsgrup-pe an Bord.

Einen Eindruck davon, wie komplex es ist,WebRTC in Browser einzubauen, gibt dieListe bekannter Einschrnkungen, die Mozillazum Start der WebRTC-Untersttzung mit Firefox 22 verffentlichte[2]: Gruppen-Chatsleiden an lahmer Performance, im Rechnerabgespielte Klnge verursachen Echos, Audiound Video sind nicht immer synchron und beiNutzern von Netzwerken mit besonders res-triktiven Richtlinien funktioniert WebRTC garnicht. Dazu kommen noch kleine Inkompati-bilitten zwischen Firefox und Chrome.

Komplexer UnterbauHauptproblem bei der Umsetzung vonWebRTC ist, die vielen daran beteiligtenProtokolle umzusetzen und aufeinander ab-zustimmen, damit der Webentwickler mg-lichst viel Freiheit bei den Details der Daten-bermittlung bekommt. So kann die Ver-

170 ct 2013, Heft 19

Know-how | WebRTC

Herbert Braun

Anruf aus dem WWWEchtzeit-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.

ct.1913.170 171 19.08.13 10:20 Seite 170

Copyright by Heise Zeitschriften Verlag

bindungsanfrage und -besttigung berbeliebige Transportprotokolle laufen. Typi-sche Kandidaten wren das fr VoIP viel ge-nutzte SIP sowie Jingle, eine P2P-Erweite-rung des Chat-Protokolls XMPP (Jabber).Eine Alternative wre zum Beispiel Socket.iomit einem Node.js-Server; selbst Ajax lsstsich einsetzen.

Das Gesprchsangebot selbst ist in Formeiner SDP-Anfrage formuliert. Das SessionDescription Protocol enthlt unter anderemInformationen ber Ports und Protokolle frdie verwendeten Medien-Streams, ber Rou-ting und Bandbreiten. Auch die Besttigungmuss in Form von SDP kommen.

Ein Problem fr alle P2P-Dienste ist dieNetwork Address Translation (NAT): Wegender Knappheit der alten IPv4-Adressen wei-sen Router ihren Clients interne IP-Adressenzu und bersetzen diese in eine einzige nachauen sichtbare. Eine P2P-Verbindung mussNAT berwinden (NAT-Traversal), wozuWebRTC wie einige bereits etablierte VoIP-Techniken das Framework Interactive Con-nectivity Establishment (ICE) nutzt.

ICE hat zwei Tricks in petto, von denenSTUN (Session Traversal Utilities for NAT) derbevorzugte ist. Damit fragt der Client beieinem ffentlichen STUN-Server an, welcheIP-Adresse bei diesem angekommen ist, undversucht mit dieser, eine P2P-Verbindungaufzubauen erst ber UDP, dann ber TCP.Laut Google-Statistiken klappt das in sechsvon sieben Fllen.

Fr die brigen weicht ICE auf TURN (Tra-versal Using Relays around NAT) aus, beidem sich ein Server zwischen die Peersklemmt und den gesamten Verkehr durch -leitet; dies funktioniert unter fast allen Netz-werkkonfigurationen, verursacht jedoch Lastauf dem Server. Wer eine professionelleWebRTC-Anwendung baut, sollte ber eineneigenen STUN/TURN-Server nachdenken. L-sungen gibt es sogar als Fertigpakete fr dieAmazon-Cloud-Dienste.

brigens ist auch abgesehen von TURNnicht jede WebRTC-Verbindung im strengenSinn P2P. Bei Konferenzen mit mehreren Teil-nehmern msste sonst jeder seine Daten analle anderen senden, was erheblich Bandbrei-te und Gerteleistung erforderte. Stattdessenkann ein einzelner Teilnehmer mit leistungs-fhiger Hardware als zentraler Verteiler agie-ren oder man schaltet einen Sternverteiler(MCU, Multipoint Control Unit) dazwischen.

Sendung luftDas Protokoll fr die bertragung der Audio-und Videodaten, das Real-time Transport Pro-tocol (RTP), hat sich bereits bei anderen VoIP-Techniken wie SIP bewhrt. Das seit den 90er-Jahren etablierte Protokoll setzt in der Trans-portschicht auf IP und (meistens) UDP. RTPeignet sich fr Einzel- wie fr Gruppengespr-che und kommt auch viel bei StreamingMedia zum Einsatz, etwa im Flash Player.

Genauer gesagt ist es die verschlsselteRTP-Variante SRTP, welche die Streams trans-portiert. Fr Abhrsicherheit sorgt der AES-

Algorithmus. Beim Verschlsselungsproto-koll setzte Chrome anfangs auf das etwa inSkype eingesetzte SDES, bei dem die vermit-telnde Website die Schlssel verwaltet. Mo-zilla und schlielich auch Google wechseltenaber zu DTLS, einen fr UDP geeigneten Ab-leger von TLS. Hier handeln die Peers unter-einander die Schlssel aus, was mehr Sicher-heit verspricht. Nach harten Auseinanderset-zungen hat die IETF im August 2013 DTLS frWebRTC vorgeschrieben.

Live is liveLizenz- und Patentprobleme bei Audio- undVideo-Codecs fhrten im W3C schon einmalzu Zerwrfnissen letztlich berlie mandas Problem den Browser-Herstellern, wasMultimedia in HTML5 erheblich behindert.Bei WebRTC scheint es anders zu laufen: Inden Spezifikationsentwrfen der IETF vorge-schrieben ist der Audio-Codec Opus, derunter der Regie der IETF aus zwei unabhn-gigen Entwrfen von Skype/Microsoft undder fr das Ogg-Format bekannten StiftungXiph.org entstand.

Trotz seiner komplizierten Vorgeschichteist aus Opus ein hervorragender Codec ge-worden, der bei groer Bandbreite den Ver-gleich mit den blichen Musik-Codecs nichtzu scheuen braucht, aber auch schon mit6kBit/s nutzbar ist. Die zwei von Google vor-geschlagenen Codecs iLBC und iSAC sind einwenig ins Hintertreffen geraten, aber eben-falls an Bord. Die IETF verlangt Kompatibilitt

zu den Telefonnetzen daher untersttztWebRTC auch das dort gngige ITU G.711mit den Codecs A-law (PCMA) und -law(PCMU) sowie das Tonwahlverfahren DTMF.

Bei Video-Codecs gibt es noch keine Eini-gung. Aktuelle Implementierungen nutzenVP8, das Google eingekauft und unter Open-Source-Lizenz gestellt hat. Das Paket mitquelloffenen Techniken, das Google Anwen-dungsentwicklern unter www.webrtc.org zurVerfgung stellt, enthlt alle die genanntenCodecs und Programmierbibliotheken fr diverse Zwecke.

RTCDataChannels, der Kanal fr den mg-lichst verzgerungsfreien Austausch vonDaten, sttzt sich mageblich auf eine ver-wandte Webtechnik: WebSockets. Die Spezi-fikation lsst dem Entwickler die Wahl zwi-schen einer Variante auf UDP- und TCP-Basis.Erstere ist schneller, kann aber nicht gewhr-leisten, dass alle Daten garantiert beim Emp-fnger ankommen fr Multiplayer-Online-spiele, wenn Spielereignisse rasch durch dieLeitung gehen mssen, kann das zum Bei-spiel die bessere Variante sein. Die zuver -lssige Datenbertragung dagegen gewhr-leistet TCP. (jo)

Literatur

[1]webrtc4all: http://code.google.com/p/webrtc4all/

[2]WebRTC in Firefox 22: https://hacks.mozilla.org/2013/06/webrtc-comes-to-firefox/

www.ct.de/1319170

171

Know-how | WebRTC

ct 2013, Heft 19

Session ManagementJavaScript-API

Protokolle/Codecs:W3CIETFITUandere

Daten

RTCDataChannels

Video Audio

V8

getUserMedia

iSAC, iLBCOpusPCMA/PCMUDTMF

Transport

RTCPeerConnection

SRTPICE (STUN + TURN) UDP

ROAPJSEPSDPXMPP/JingleSIPWebSockets

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

Mit WebRTClassen sich

zum BeispielScreensharing-

dienste wietalky realisieren.

ct.1913.170 171 19.08.13 10:20 Seite 171

Copyright by Heise Zeitschriften Verlag