WebRTC, Anwendungen, Technologie, Infrastruktur, Demonstration melavi

WebRTC Demonstration - melavi

Bevor wir starten – eine kleine Demonstration, entsprechend dem Motto „ein Bild sagt mehr als 1000 Worte“. Schauen Sie hier einmal in das MediaLan Demo-Video Chat melavi und versuchen Sie den Aufbau einer Videoverbindung mit einem Partner. Lesen Sie vorher die Hilfe im Dialog, um die notwendigen Voraussetzungen für den Betrieb zu erfahren. melavi wurde als Nebenprodukt einer WebRTC Kunden-Integration entwickelt, um den realen WebRTC Betrieb unter den Bedingungen des Internets zu testen und daraus Empfehlungen für die Betriebsvoraussetzungen abzuleiten.

WebRTC Anwendungen

Auf den Seiten von Produktanbietern im Internet spürt man einen zunehmenden Trend der Einbettung von persönlicher Beratung und Service in die Geschäftslogik eigener Web Anwendungen. Dem Kunden wird ein Dialog angeboten, in dem er seine Fragen stellen kann, die von einem persönlichen Berater beantwortet werden. Dies erleichtert einerseits die Kaufentscheidung, andererseits bleibt eine gute persönliche Beratung im Gedächtnis. Diese menschliche Art der Kommunikation steht im Gegensatz zu austauschbaren, unpersönlichen Web-Präsentationen von erklärungsbedürftigen Produkten. Das „Gespräch“ mit einem Automaten wird wieder durch das Gespräch mit einem Menschen ersetzt. Der direkte Austausch von Mensch zu Mensch im Gegensatz zu den stereotypen Mitteln des heutigen Internets wird wiederbelebt und wieder als Mittel der Kundenbindung erkannt.

Wenn schon einfache Text-Chats eine kundenbindende Wirkung haben, welchen Stellenwert hat dann ein Gespräch von Angesicht zu Angesicht? Plötzlich ist die Firma, bei der man kauft, keine abstrakte Internet-Seite mehr sondern hat ein Gesicht und einen vielleicht sogar namentlich bekannten Gesprächspartner. WebRTC (Web Real Time Communication) schafft für solche Situationen die technischen Voraussetzungen.

Nehmen wir andere Beispiele – das sensible Gespräch zwischen Arzt und Patient oder zwischen einem Anwalt und seinen Mandanten. Nicht jedes Patienten- oder Mandanten-Anliegen erfordert eine direkte Präsenz beim Arzt oder Anwalt. Viele Kleinigkeiten des täglichen Lebens ließen sich in einer Online-Sprechstunde erheblich effizienter und für beide Seiten weniger belastend abwickeln. Lange Wartezeiten in Wartezimmern könnten vermieden werden, Reisekosten könnten gesenkt werden – die Präsenz des Arztes oder Anwaltes kann erhöht werden. Es könnten mehr Klienten in der verfügbaren Zeit bedient werden. Das indirekte Online-Gespräch kann die Vorstufe der Entscheidung bilden, ob ein direktes Gespräch notwendig ist. Text-Chats oder auch Telefongespräche sind nur Kompromisslösungen. Meist fehlt die notwendige Intimität des Gespräches von Angesicht zu Angesicht. Gerade bei sensiblen Inhalten ist der persönlichere Aspekt einer Videoverbindung ein wesentlicher Faktor, um das notwendige vertrauensvolle Verhältnis aufzubauen.

Die Palette möglicher Anwendungen, die auf interaktiven persönlichen Gesprächen von Angesicht zu Angesicht beruhen, ist groß. Im Bankenumfeld beispielsweise hat die klassische Filiale ausgedient. Es wachsen Kunden-Jahrgänge heran, die noch keine Bank von innen gesehen haben. Was ersetzt das Gespräch zwischen Kundenberater und Anleger oder Kreditnehmer - virtuelle WebRTC Filialen? Oder nehmen wir die Kommunikation zwischen einem Steuerberater und seinen Klienten. Viele Situationen des Alltags, die Beratungsleistungen beinhalten, sind eine potentielle Domäne für WebRTC-Anwendungen, so z. B. der Kontakt von Versicherungsmakler mit seinen Kunden. Auch ein Einsatz als Vertriebs-Werkzeug für das Direktmarketing eröffnet interessante Perspektiven, wie die visuelle Präsentation von Produkten, die Beratung von Kunden beim Einsatz von Produkten oder auch die erweiterte Stammdatenerfassung z. B. mit bei einem WebRTC-Chat erfassten Snapshots (das Einverständnis des Kunden sei vorausgesetzt) und direkter Ablage zusammen mit den Kundenstammdaten in einer Kontaktdatenbank.

WebRTC schafft die Grundlage für die Gründung und Betrieb autonomer Communities, welche neben bisherigen textuellen Kommunikationsmöglichkeiten auch eine audio-visuelle Komponente benötigen. Der Anbieter einer Dienstleistung kann selbst zum Provider werden. Interaktive Sprachkurse oder andere Online-Trainings-Maßnahmen sind vorstellbar. WebRTC ist in der Lage, vollständig neue Anwendungsdomänen zu schaffen. Insbesondere die direkte Verknüpfung der Video-Komponente mit der Geschäftslogik und den Geschäftsdaten eines Anbieters bietet dazu den Schlüssel.

Was ist neu an WebRTC?

Was macht WebRTC anders als Microsoft Skype, Apple Facetime oder Adobe Flash? Ist das nicht auch nur ein weiterer alternativer Weg für die Übertragung von Audio und Video? Etwas provokant kann man hier die Frage stellen – was machte den Unterschied zwischen Teletext/Btx und dem Web aus? In der Anfangszeit des Webs konnte man auf beiden Wegen auf Textinformationen zugreifen. Heute diskutiert den qualitativen Unterschied niemand mehr ernsthaft.

Der qualitative Unterschied und damit das Potential von WebRTC im Unterschied zu klassischen Multimedia- und Video-Chat-Lösungen liegt vor allem in folgenden Punkten begründet:

WebRTC ist ein wohldefinierter Standard

Die Standardisierung über die IETF und das W3C schafft die Voraussetzung für eine plattformübergreifende kompatible Kommunikation und für den Übergang in andere Kommunikations-Netze wie z. B. das VoIP Netz. Interaktive Live Audio- und Video-Kommunikation wird damit zum weltweiten Standard, eingebettet in die flexible Umgebung von Web-Browsern. WebRTC hat als erstes Live Video-Kommunikationsverfahren das Potential wirklich auf allen denkbaren Endgerätetypen homogen verfügbar zu sein und ermöglicht damit Gespräche ohne Plattform-Barrieren.

WebRTC ist voll integrierbar und an eigene Anforderungen anpassbar

Dieser Punkt ist wohl aus Sicht möglicher neuer Anwendungen der interessanteste im Vergleich zu bisherigen Technologien, die nur über sehr eingeschränkte Möglichkeiten der Umsetzung eigener Ideen und Lösungen verfügen.

Bestandteil des Standards ist eine wohldefinierte Javascript-Schnittstelle. Diese erlaubt es WebRTC in eigene Anwendungen zu integrieren. Der Bruch zwischen Geschäftslogik und autonomer Kommunikations-Software oder -Hardware verschwindet. Es muss kein separater Skype Client gestartet werden, um ein Kundengespräch zu führen. Die Stammdaten für das Herstellen von Verbindungen können direkt von der Web-Anwendung geliefert werden. Die Gesprächsfunktion wird damit integraler Bestandteil von Web-Anwendungen. Insgesamt erhält man eine geschmeidige, durchgängige und homogene Bedienbarkeit einer Web-Anwendung mit integrierter Realtime-Daten-Komponente.

Es können vollständig eigenständige Lösungen für die Einbettung der Gesprächsfunktion in eigene Portale geschaffen werden. Dies beginnt bei der Umsetzung des Corporate Designs eines Web-Auftritts und wird ergänzt um die Verknüpfung von Video Daten mit Geschäftsdaten der Lösung. Die Kombination von Live Video mit Zusatzdaten mannigfacher Art kann den Mehrwert der Web Anwendung erhöhen. So können Echtzeit-Messwerte, Börsenticker- oder Kontodaten direkt zwischen den Teilnehmern einer WebRTC-Verbindung übertragen und mit den Gestaltungsmitteln des Browsers visualisiert werden.

Die volle Integrierbarkeit erlaubt das Nachbilden geschäftstypischer Prozesse im Web Browser. Ein Beispiel sind Wartezimmersituationen und Online-Sprechstunden. Wie im täglichen Leben hat ein Online-Wartezimmer Status wie "geöffnet" oder "geschlossen" und eine Warteliste mit Klienten, die auf ein Gespräch mit ihrem Berater wie z. B. einem Anwalt warten. Die Verwaltung der dafür notwendigen Informationen und die Steuerung des Aufbaus von Berater/Klienten-Gesprächen kann vollständig an die Bedürfnisse des einzelnen Anwenders angepasst werden. Die Parameter der geführten Gespräche wie die Gesprächszeit, Notizen zum Verlauf oder Beginn und Ende können für Abrechnungszwecke einfach und vollautomatisiert erfasst und mit sonstigen Geschäftsdaten verknüpft werden. Im Vergleich zu den starren Lösungen, die z. B. Skype oder Facetime hier anbieten, ist dies ein gewaltiger Zugewinn an Flexibilität und Interaktivität.

Auf Basis der WebRTC-Standards und Integrations-Schnittstellen lassen sich vollautonome eigenständige Kommunikationsinseln aufbauen. Die Kommunikation kann auf bestimmte Nutzergruppen beschränkt werden. Ebenso kann eine Nutzer-abhängige Individualisierung der Bedienmöglichkeiten und Präsentation erfolgen. Die für WebRTC notwendige Internet-Infrastruktur kann sich jeder WebRTC-Nutzer bei Bedarf selbst aufbauen und damit eigene Provider-Strukturen realisieren. Dies bietet ein höchstmögliches Maß an Schutz von Kommunikations-Daten und an Flexibilität der Umsetzung eigener Lösungen.

WebRTC Daten sind sicher

Vertrauen Sie Skype, Flash oder Facetime wirklich?

Sämtliche Daten von WebRTC, seien es Video-, Audio-, Echtzeit-, Geschäfts- oder Signalisierungsdaten, sind mit standardisierten öffentlich anerkannten Verfahren verschlüsselt. Dies erlaubt die Nutzung von WebRTC auch für Anwendungen mit hohem Vertraulichkeitsgrad. Gerade diese Funktion ist die Voraussetzung der Zertifizierung von WebRTC in sensiblen Anwendungsfällen wie der Arzt/Patienten- oder Anwalts/Mandanten-Kommunikation. Andere Verfahren nutzen dagegen proprietäre Technologien und setzen auf Intransparenz in Bezug auf Sicherheits-relevante Datenübertragungen, was den Einsatz für die skizzierten Geschäftsfelder zumindest fragwürdig macht.

WebRTC arbeitet Plattform-übergreifend

Als Web-Standard ist WebRTC zumindest potentiell auf beliebigen Computern, Tablets oder Smartphones nutzbar, die über einen WebBrowser verfügen, der den WebRTC-Standard implementiert. Schon heute ist eine riesige Zahl von aktuellen Internet-Endgeräten für eine WebRTC-basierte Video- und Echtzeitdaten-Kommunikation zugänglich. Die Anzahl der Web Browser, die WebRTC unterstützen, wächst ständig und damit auch der Verbreitungsgrad der Technologie auf verschiedensten Endgerätetypen. Mittlerweile scheint selbst Microsoft auf den bereits in voller Fahrt befindlichen Zug aufspringen zu wollen, wobei es natürlich gerade unter Windows mit Google Chrome oder Mozilla Firefox bereits weitentwickelte Browser Alternativen gibt.

WebRTC benötigt keine Plugins

Diese Funktion wird direkt von den aktuellen Web Browsern geliefert. Es muss keine Zusatzsoftware installiert werden. Als vollständig browser-integrierte Lösung muss man sich nicht um ständige Sicherheits-kritische Updates von Plugins oder gar autonomer Software-Clienten wie bei Skype kümmern. Als reine Browser-Technologie steht einer WebRTC-basierten Video-Präsentation die volle Palette von Web Technologien wie CSS, Javascript oder HTML 5 zur Verfügung, um diese individuellen Bedürfnissen anzupassen. Die Plattform-Bindung von Technologien wie z.B. ActiveX und Internet Explorer entfällt. Man gelangt zu homogenen browser-übergreifenden Lösungen, die zudem noch erheblich einfacher zu implementieren und zu bedienen sind als bisherige Techniken. Während die komplette WebRTC-Entwicklung auf Browser-Seite homogen mit Javascript realisiert werden kann, erfordert z. B. die Einbettung eines Flash Video Chats die Schaffung von Brücken zwischen der Adobe ActionScript- und der browser-seitigen Javascript Welt, was erheblich höhere Entwicklungsaufwände mit sich bringt als durchgängige Browser-Lösungen mit Javascript.

WebRTC skaliert mit den Bedürfnissen

WebRTC ist eine so genannte Peer to Peer Technologie. Die Daten werden direkt zwischen den Browsern der Gesprächspartner ausgetauscht. Durch den Verzicht auf einen zentralisierten Server für den Austausch der Echtzeitdaten wird die Übertragungsqualität z.B. im Vergleich zu Flash-basierten Lösungen verbessert. Es entstehen keine Flaschenhälse durch die beschränkte Leistungsfähigkeit eines zentralisierten Servers und die Anzahl der Teilnehmer in einem WebRTC Netz ist nicht begrenzt.

Obwohl die Peer to Peer Kommunikation im Vergleich zu anderen Verfahren nichts grundsätzlich Neues darstellt, bietet WebRTC auch hier Vorteile gegenüber den proprietären Ansätzen. So werden z. B. eine Reihe von Technologien aus dem VoIP Sektor nachgenutzt. Dies dürfte einen zukünftigen nahtlosen Übergang zwischen WebRTC und VoIP Endgeräten erheblich vereinfachen. Gespräche zwischen Browser und Video- bzw. Soft-Phone oder gar klassischen PSTN (Public Switched Telephone Network)-Telefonen sind möglich.

Technologie

WebRTC ist ein Sammelbegriff für das Zusammenspiel einer großen Palette verschiedener Kommunikationstechnologien, wie im folgenden Bild (nicht vollständig) gezeigt. Teile der technologischen Basis von WebRTC überlappen sich mit anderen Standards, wie z. B. der Einsatz des RTP Transport-Protokolls oder des optionalen SIP-Protokolls zu Signalisierungszwecken, wie sie auch bei VoIP verwendet werden. Andere Anteile des Standards sind WebRTC-spezifisch, so die Javascript Programmier-Schnittstelle.

Einige Komponenten einer WebRTC-Lösung lässt der Standard bewusst offen, wie die gelben Blöcke in der Grafik zeigen, um hier die Flexibilität bezüglich der möglichen Anwendungs-Szenarien zu erhöhen.

Der Großteil der Bausteine von WebRTC wird vom Browser gekapselt. Der Web-Anwendungsentwickler hat keinen direkten Einfluss auf die Audio/Video-Kompression oder den Streaming-Transport. Auch Themen wie NAT Traversal oder Verschlüsselung werden weitgehend vom Browser selbst realisiert. Die größten Herausforderungen für den Anwendungsentwickler sind neben der Umsetzung der eigentlichen Workflows seiner Web-Anwendung das Füllen der Standard-„Lücke“ Signalisierung und der permanente Kampf mit Browser-Details und Inkompatibilitäten, welche aber mit zunehmendem Reifegrad des Standards reduziert werden.

Audio/Video Codecs

Der WebRTC-Standard legt die für die Audio/Video Kompression verwendeten Verfahren nicht fest. Es wird lediglich, definiert wie sich die Teilnehmer einer WebRTC-Session über die verwendeten Verfahren wechselseitig informieren. Dazu wird das aus VoIP bekannte SDP (Session Description Protocol) verwendet. Auch wenn der Standard keine explizite Vorgabe bezüglich der Wahl eines Codecs macht, schaffen die Browser Hersteller hier de facto Standards. Eine Freiheit des WebRTC Anwendungsentwicklers gibt es hier nicht, da er die vom Browser unterstützten Verfahren nutzen muss.

Aktuell hat der VP8 Video Codec den größten Verbreitungsgrad, da sich Google als treibende Kraft der WebRTC-Entwicklung für diesen Codec entschieden hat. Grund sind lizenzrechtliche Probleme beim Einsatz des H.264 Codecs. Bei homogenen WebRTC-Anwendungen ist die Beschränkung auf VP8 kein Problem. Problematisch ist VP8 heute, wenn die Grenzen von WebRTC verlassen werden. Eine Kommunikation mit VoIP-Endgeräten, die zumeist H.264 oder gar noch H.263 unterstützen, ist oft nicht möglich, da hierfür ein Transcodieren der Video-Daten notwendig wäre. Dies würde einen Großteil der Vorteile der WebRTC Peer to Peer Kommunikation in Frage stellen.

Wie alles bei WebRTC ist die gegenwärtige Entwicklung hier aber sehr dynamisch. So hat Mozilla in Bezug auf Firefox die zu VP8 alternative Unterstützung von H.264 ab Version 33 verkündet. Auch die neuesten Microsoft-Verlautbarungen lassen erwarten, dass ein zukünftiger WebRTC Support des Internet Explorers (nur) H.264 unterstützen wird – was natürlich wiederum eine direkte Kommunikation zwischen einem Chrome und einem Internet Explorer-Endpunkt unmöglich machen wird.

Medien Streaming

Die Transport-Verfahren für das Audio/Video Streaming legt der WebRTC-Standard mit RTP/RTCP wie bei VoIP auch fest. Da der Standard verschlüsselte Übertragungen vorgibt, kommt hier die verschlüsselte Variante sRTP zum Einsatz.

Verschlüsselung

Der Standard definiert die für die Verschlüsselung der Audio-, Video- und Anwendungsdatentransporte zu verwendenden Protokolle. Dazu gehören auch die Verfahren des Schlüsselaustausches.

Signalisierung

Der wohl für den Anwendungsentwickler zunächst verwirrendste Anteil von WebRTC ist das Thema Signalisierung bzw. dessen Fehlen in der Spezifikation. Der Zugriff auf die WebRTC-Funktionalität des Browsers über das WebRTC Javascript API ist eine relativ einfache Angelegenheit. Die üblichen WebRTC Hello World-Beispiele zeigen dies anhand weniger Javascript-Zeilen. Verschwiegen wird dabei, dass für das Zustandekommen realer WebRTC-Verbindungen ein relativ großer Implementations- und Infrastrukturaufwand betrieben werden muss.

Von Ausnahmen abgesehen (z. B. der Peer to Peer Kommunikation zwischen 2 Browsern im Intranet mit bekannten IP Adressen der Teilnehmer) erfordert WebRTC eine so genannte Signalisierung.

Die Signalisierung hat die Aufgabe den Peers einer WebRTC-Kommunikation die Informationen zu liefern, die sie für den Aufbau der eigentlichen Peer to Peer-Nutzdatenverbindung benötigen. Damit zwei WebRTC-Clients eine Peer to Peer-Verbindung zueinander aufbauen können, benötigen sie Information zu:

• ihren Adressen (so genannte ICE Candidates)
• zur Art der von beiden Seiten unterstützen Medien Daten – also Codec Informationen (mittels SDP)

Diese Informationen können die Browser nicht direkt austauschen, da sie beim Versuch des Aufbaus einer Verbindung ihre Adressen im Allgemeinen nicht kennen. Grund ist die Tatsache, dass die meisten Internet Teilnehmer weder über eine:

• öffentlich zugängliche noch über eine
• statische IP-Adresse verfügen

Wegen der Beschränkung des IP-Adressbereiches werden IP-Adressen den Internet-Teilnehmern meist dynamisch vergeben. Es ist also nicht garantiert, dass ein Internet-Teilnehmer bei aufeinanderfolgenden Verbindungen von seinem Provider immer die gleiche IP-Adresse bekommt. Schlimmer noch ist die Notwendigkeit des Einsatzes so genannter NAT (Network Address Translation) Technologie in den Internet-Zugangs-Routern von Teilnehmern. Während der Router noch eine aus dem Internet heraus ansprechbare IP-Adresse besitzt, haben die Teilnehmer hinter dem Router private (Intranet) Adressen. Zu privaten IP-Adressen können aber Internet-Teilnehmer an anderen Routern keine direkte Verbindung aufbauen. Es ist also im Allgemeinen nicht möglich, zwei beliebige Internet-Teilnehmer ohne weitere Werkzeuge direkt zu verbinden.

Damit die Teilnehmer trotzdem Peer to Peer Verbindungen aufbauen können, ist im Vorfeld eine Signalisierung über einen zentralen Server-Dienst notwendig. Über diesen tauschen die Teilnehmer bestimmte Daten aus, die für den Aufbau der direkten Audio/Video Verbindung notwendig sind.

Damit ist trotz des Peer to Peer Charakters von WebRTC eine zentralisierte Server Infrastruktur für den Austausch der Verbindungsdaten nötig. Der Standard regelt dabei lediglich die Art der auszutauschenden Daten (SDP und Adressinformationen in Form von ICE Candidates) – nicht aber die Art des Transportes oder die Vermittlung/Weiterleitung dieser Daten zwischen den Teilnehmern einer WebRTC Session.

Für den Transport können verschiedene Technologien eingesetzt werden. Eine der häufigsten Lösungen besteht gegenwärtig in der Nutzung eines proprietären Übertragungsprotokolls auf Basis der neuen HTML5-WebSockets. Alternativen sind SIP über WebSockets oder Ajax-basierte Ansätze.

NAT Traversal

Wie dargestellt, bietet die heutige Architektur des Internets eine Reihe von Herausforderungen, welche die direkte Peer to Peer Kommunikation zwischen zwei Teilnehmern behindern oder auch unmöglich machen können. NAT ist dabei sicher eines der schwerwiegendsten Architekturprobleme des IPv4-basierten Internets. WebRTC definiert die Techniken, die für den Aufbau direkter Peer to Peer-Verbindungen zwischen Rechnern hinter NAT-Routern zum Einsatz kommen. Diese Technologien stammen weitgehend aus dem VoIP-Bereich.

Für die Ermittlung von Adressinformationen, die WebRTC-Teilnehmer für die Aufnahme von Direkt-Verbindungen nutzen können, kommt STUN (Session Traversal Utilities für NAT) zum Einsatz. Dies erfordert das Hosten eines weiteren im öffentlichen Internet zugänglichen Servers, über den die Teilnehmer-Adressdaten ermitteln können. Bei einigen NAT-Typen (symmetrisches NAT) scheitert aber auch der STUN-Ansatz für den Aufbau von Direktverbindungen. In diesen Fällen kommen als letzte Rückfallebene TURN (Traversal Using Relays Around NAT)-Server zum Einsatz. In diesem Fällen (Schätzungen liegen bei 10-15% der WebRTC Verbindungsaufbauten) ist eine Peer to Peer Kommunikation nicht möglich. Die WebRTC-Nutzdaten werden über einen zentralen Relais-Server zwischen den Teilnehmern ausgetauscht. Dies hat eine Reihe negativer Konsequenzen in Bezug auf Skalierbarkeit und Übertragungsverzögerungen. Welche Kommunikationsart die Teilnehmer einer WebRTC-Verbindung wählen, ermitteln die Browser weitgehend selbständig über ein Try and Error-Verfahren (ICE – Interactive Connection Establishment).

Die Erläuterungen zeigen, dass die Anforderungen an die Infrastruktur einer WebRTC-Community relativ hoch sind. Neben dem Web-Server für die Web-Anwendung wird ein Signalisierungsserver und zusätzlich noch ein STUN- und TURN-Server benötigt, so dass eine voll ausgebaute WebRTC-Infrastruktur sich folgendermaßen darstellt:

STUN und TURN können zu einer Server-Instanz zusammengefasst oder auch getrennt betrieben werden. Sollen noch Übergänge ins VoIP Netz geschaffen werden, werden weitere Infrastrukturkomponenten wie Medien- und Protokoll-Transcoder Gateways benötigt. Als Alternative zu einer selbst gehosteten WebRTC Infrastruktur gibt es mittlerweile eine Reihe von Dienstleistern, welche die notwendigen Komponenten über Provider und SaaS Modelle zur Verfügung stellen.

WebRTC API

Spielwiese des WebRTC Anwendungsentwicklers ist neben der Implementation einer Signalisierungslösung das WebRTC Javascript API. Dieses API ist in Form von drei Javascript-Objekten standardisiert:

• getUserMedia realisiert den Zugriff auf die lokalen Audio- und Videoquellen
• RTCPeerConnection kapselt die Aspekte der Aufnahme einer WebRTC-Verbindung zu remote WebRTC-Teilnehmern. Das Objekt stellt die eigentliche WebRTC-Schnittstelle des Browsers dar. Wesentliche Aufgaben sind die Ermittlung von Adressdaten für den Verbindungsaufbau über STUN/TURN/ICE-Mechanismen die Steuerung der Audio- und Videoübertragung, z. B. durch Austausch der SDP Informationen mit Details über die Medien Codecs.
• RTCDataChannel erlaubt den Austausch beliebiger binärer oder textueller Nutzdaten zwischen den WebRTC Teilnehmern.

Die Freiheitsgrade des Anwendungsentwicklers für die Beeinflussung der WebRTC-Basis des Browsers sind gegenwärtig noch recht bescheiden. Außer der Wahl der Video-Auflösung stehen keine weiteren Qualitätsparameter für die Beeinflussung des Codec-Verhaltens zur Verfügung. Kompexere Aspekte der Nutzdatenkommunikation wie Verschlüsselung, Bandbreitenregelung oder Stauvermeidung sind vollständig dem Browser überlassen und sind über das Javascript API nicht zugänglich.

WebRTC – aktuelle Voraussetzungen

WebRTC funktioniert gegenwärtig mit den aktuellsten Versionen von Google Chrome, Mozilla Firefox und Opera. Mit Google Chrome besteht auch die Möglichkeit von WebRTC-Verbindungen mit mobilen Endgeräten unter Android. Der Microsoft Internet Explorer unterstützt WebRTC noch nicht, was aber zumindest unter Windows keine Einschränkung darstellt, da Chrome oder Firefox als Alternative genutzt werden kann. Eine WebRTC-Verbindung mit iOS-Endgeräten ist gegenwärt nur über einen WebRTC-Provider wie TokBox mittels nativer iOS-Apps möglich. Der Safari Browser unterstützt WebRTC nicht.

Für einen ersten Test der eigenen Plattform auf WebRTC-Tauglichkeit kann man die Google Referenz-Anwendung

apprtc.appspot.com

nutzen. Diese greift auf die notwendige Signalisierungs- und NAT-Traversal-Infrastruktur (STUN/TURN Server) von Google zurück.

Obwohl eine Cross-Browser-Kommunikation z. B. zwischen Chrome und Firefox prinzipiell funktioniert, kann es zu Störungen kommen. Die WebRTC-Funktionalität der Browser ist noch unterschiedlich. So erlaubt das Firefox WebRTC Javscript API keine Steuerung der Video-Auflösung. Bei der Kommunikation zwischen Chrome und Firefox wurden mit der Zeit zunehmende Störungen (Bildruckeln, Übertragungsverzögerungen und Abreißen von Audio-Übertragungen) beobachtet, die bei einer homogenen Kommunikation zwischen Chrome und Chrome bzw. Firefox und Firefox nicht auftraten. Um einer Enttäuschung vorzubeugen, sollte sich also zunächst auf eine homogene Browser Kommunikation beschränkt werden.

Zusammenfassung

Trotz des noch nicht vollständig abgeschlossenen Standardisierungsprozesses und politischer Streitigkeiten der großen Player scheint WebRTC nunmehr ca. 4 Jahre nach seinem Start das notwendige Momentum erreicht zu haben, um zu einem neuen Massenmedium zu werden – mit parallel hervorragenden Möglichkeiten der Individualisierung. Dies wird auch durch jüngere Meldungen zu Intentionen von Microsoft sichtbar, WebRTC im Internet Explorer zu unterstützen bzw. von Mozilla Firefox auch den H.264 Standard alternativ zum VP8 Codec anzubieten.

Die Anzahl der WebRTC-Infrastruktur- und Framework-Anbieter wächst. Trotz der noch notwendigen Anpassungen an Änderungen im laufenden Standardisierungsprozess sind eine Reihe von Web-Anwendungen mit integrierter WebRTC-Funktion in Betrieb. Die Investitionsunsicherheit, die in der Anfangsphase mit der Einführung einer neuen Technologie einhergeht, sinkt und die erzielbaren Mehrwerte beginnen sich bereits jenseits der üblichen Hype und Marketing-Euphorie-Phase zu manifestieren.

Wie gezeigt sind die möglichen Einsatzszenarien von WebRTC breit gefächert. Die Verknüpfung von Medien- und sonstigen Realtime-Informationen mit klassischen Web-Anwendungen und deren Workflows wird neue Potentiale für Kunden-Bindungs-, Akquise- und Vertriebsprozesse eröffnen. Die lange erträumten Einspar- und Nutzens-Effekte durch den Ersatz physischer Präsenz mittels einer remote Live Medien-Präsenz werden durch WebRTC einen großen Schritt vorangetrieben.

Der richtige Zeitpunkt, um in diese neue Technologie einzusteigen. Wir helfen Ihnen dabei mit Planung, Workflow-Analysen, Infrastruktur-Aufbau und Skalierung, und Software-Implementation.