Häufige Fragen

Fragen zum Einsatz von melavi-WebRTC in Web-Anwendungen

Wie kann melavi-WebRTC in eine Web-Anwendung integriert werden?

Das melavi Produkt-Framework unterstützt direkt die folgenden Content Management Systeme (CMS):

  • Wordpress (die melavi Demonstrations-Site von MediaLan wurde mit WordPress erstellt)
  • Drupal
  • Typo3

Die Integration erfolgt mit so genannten Plugins, welche im entsprechenden CMS installiert werden. Die melavi-CMS Plugins erlauben eine einfache Integration von verschiedenen Gesprächsvarianten, wie z. B. als Basis-Gespräch oder als virtuelle Filiale.

Sie können die Seiten Ihrer Anwendung einfach festlegen, auf denen z. B. ein WebRTC-basierter Kundendialog möglich sein soll. Die sonstigen Teile Ihrer Web-Anwendung werden davon nicht beeinflusst. melavi bietet umfangreiche Anpassungsmöglichkeiten sowohl was die Formatierung der Präsentation als auch was die Beinflussung der Workflows betrifft. Über die Betriebsdatenerfassungs-Schnittstelle von melavi können Gesprächsdaten archiviert werden, welche z. B. für Abrechnungszwecke verwendet werden.

Welche CMS-Systeme werden von melavi-WebRTC unterstützt?

Folgende Content Managemen Systeme werden mittels Plugins direkt unterstützt:

  • Wordpress (die melavi Demonstrations-Site von MediaLan wurde mit WordPress erstellt)
  • Drupal
  • Typo3

Weitere CMS wie z. B. Joomla sind gegenwärtig in Arbeit. Falls Ihre Web-Anwendung ein anderes CMS nutzt oder auf statischen HTML-Seiten beruht, kann die Integration über den melavi-Javascript SDK erfolgen.

Was ist der Vorteil der Nutzung von HTTPS für WebRTC-Anwendungen?

melavi-WebRTC zwingt nicht dazu eine Web-Anwendung über HTTPS zu betreiben. Für Test-Anwendungen oder Web-Anwendungen, die keine hohen Sicherheitsansprüche haben, genügt der Einsatz von HTTP. Die Sicherheit der WebRTC basierten Datenübertragungen für Audio-, Video- und sonstiger WebRTC Live-Daten ist unabhängig vom Einsatz von HTTPS und wird vom WebRTC-Standard gefordert.

Nutzt man HTTPS anstelle von HTTP in einer professionellen Anwendung, so hat man die folgenden beiden Vorteile in Bezug auf die WebRTC-Funktion:

  • Die Freigabe der Web-Kamera für die Nutzung durch eine Web-Anwendung muss nur einmalig erfolgen. Bei HTTP muss bei jeder Verbindungsaufnahme ein Sicherheits-Dialog des Web-Browsers bestätigt werden, was oftmals übersehen wird und was andererseits die WebRTC-Funktionalität einschränken kann. So ist z. B. bei HTTP immer eine Interaktion des Anwenders nötig bevor er WebRTC nutzen kann, während er bei HTTPS-Anwendungen automatisch mit Öffnen der Gesprächs-Seite Empfangs- und Sende-bereit ist.
  • Bei HTTP basierten Web-Anwendungen werden auch die WebRTC-Verbindungs-Daten unverschlüsselt im Netz übertragen. Dies sind die Daten, die als Vorbereitung für die Aufnahme der eigentlichen WebRTC-Verbindung zwischen den Teilnehmern über den melavi-Signalisierungs-Server und gegebenenfalls den Web-Server der Anwendung ausgetauscht werden müssen. Bei HTTPS sind neben den WebRTC-Nutzdaten auch die Verbindungs-Daten verschlüsselt.

Fragen zur melavi-WebRTC Technik

Welche Browser- und Betriebssystem-Plattformen unterstützt melavi-WebRTC?

Die Grafik zeigt den gegenwärtigen Stand der WebRTC-Unterstützung durch Web-Browser und Betriebssysteme.

MelaviPlattforms

Bis auf Apple iOS-Geräte werden alle großen Betriebssystem-Plattformen unterstützt. Für mobile Anwendungen kann auf Android basierte Geräte mit Google-Chrome als Browser zurückgegriffen werden. Microsoft Internet Explorer unterstützt WebRTC nicht. Im Windows-Umfeld gibt es aber mit Google-Chrome, Mozilla-Firefox und Opera-Software genügend Alternativen. Der WebRTC-Standardisierungsprozess ist noch nicht vollständig abgeschlossen. Es gibt Hinweise, dass auch Microsoft WebRTC im neuen Web-Browser Spartan unterstützen wird. Wann es auf Apple iOS-Geräten eine Browser basierte WebRTC-Unterstützung geben wird, ist gegenwärtig nicht absehbar. Einzige Alternative sind hier im Moment native iOS-Anwendungen, was jedoch den Nutzen einer Browser-basierten Live-Daten Kommunikation stark reduziert.

Mit dieser bereits heute sehr großen Verfügbarkeit von WebRTC auf verschiedensten Plattformen sowohl auf stationären als auch mobilen Endgeräten kann melavi-WebRTC in breitem Umfang eingesetzt werden.

Probleme, mögliche Ursachen

Meine Bildqualität ist schlecht. Das Video zeigt Störungen und ruckelt.

Die erreichbare Übertragungsqualität ist von Ihrer Internet-Bandbreite und von der Bandbreite der Gegenstelle abhängig. Meist ist dabei die Upload-Bandbreite, also die Geschwindigkeit mit der Sie Daten ins Internet senden können, der problematische Faktor. Für eine gute Audio/Videoqualität benötigt melavi in den Standard-Einstellungen eine Bandbreite ab etwa 300 kbps (kilo bit per second). Ist viel Bewegung im Bild können auch höhere Bandbreiten nötig sein. WebRTC regelt die Qualität der Übertragung in Abhängigkeit von der verfügbaren Bandbreite. Bei niedriger Bandbreite wird automatisch die Qualität verringert.

Ein typischer ADSL-Internet-Zugang hat ca 10% Upload-Bandbreite im Vergleich zur Dowload-Bandbreite. Ein Internet-Zugang von 6 mpbs (mega bit per second) hat also meist nur 600 kbps Upload-Bandbreite. Die heute bei den meisten Internet-Anschlüssen verfügbaren Bandbreiten sind ausreichend für eine qualitativ hochwertige WebRTC-Kommunikation.

Meine Bildqualität schwankt. Perioden sehr guter Qualität wechseln sich mit schlechter Qualität und Ruckeln ab.

Die Qualität ist abhängig von der verfügbaren Bandbreite. Schwankt die Bandbreite, so schwankt auch die Übertragungsqualität, wenn nicht mehr genügend Übertragungsbandbreite verfügbar ist. Gründe für schwankende Bandbreiten sind sehr oft der parallele Betrieb anderer Internet-Anwendungen. Ein langer Download oder der Empfang einer größeren email können die für WebRTC verfügbare Bandbreite so einschnüren, dass es zu temporären Qualitäts-Schwankungen kommen. Für die volle Qualität sollten Sie währen einer Kommunikationssitzung keine weiteren Internet-Aktivitäten über Ihren Zugang betreiben.

Die Bandbreiten-Probleme können auf beiden Seiten der Kommunikation zustande kommen. Eine schlechte Empfangs-Qualität kann sowohl durch die niedrige Upload-Bandbreite des Senders als auch durch die niedrige Download-Bandbreite des Empfängers zustande kommen. Neben den bei Sender/Empfänger zu suchenden Ursachen für Bandbreitenschwankungen kann auch die Internet-Infrastruktur selbst eine Ursache sein. Das Internet und WebRTC machen keine so genannten QoS (Quality of Service) Angaben zu Übertragungs-Qualitäten und Bandbreiten. Mit steigender Verfügbarkeit hoher Bandbreiten an den Internet-Anschlüssen der Teilnehmer gehen derartige Probleme aber immer mehr zurück.

melavi funktioniert bei allen meinen Kontakten bis auf einen oder wenige Teilnehmer.

Wenn Sie im Allgemeinen WebRTC-Verbindungen aufbauen oder entgegen nehmen können, dann liegt das Problem am Internet-Zugang Ihres Gesprächspartners. Unter der Annahme, dass die grundsätzlichen Vorraussetzungen des Teilnehmers wie WebRTC-fähiger Web-Browser gegeben sind, ist die Ursache meist in den Eigenschaften des Internet-Zugangs zu suchen. Bei der Architektur des heutigen Internets sind die meisten Rechner nicht direkt erreichbar. Sie befinden sich in lokalen Intranets hinter Internet-Routern. Zwei Rechner hinter verschiedenen Routern können nur mit speziellen Hilfsmitteln Kontakt aufbauen. WebRTC stellt diese Hilfmittel in Form spezieller öffentlicher Server (STUN/TURN Server) zur Verfügung. Das Arbeitsprinzip ist das gleiche wie bei der klassischen Voice over IP (VoIP) Technik. Es gibt Internet-Zugänge (z. B. so genannte symmetrische NAT-Router), bei denen die "einfachen" WebRTC-Vermittlungstechniken versagen. In diesen Fällen kommen Medien-Router als Bestandteil der WebRTC/VoIP-Infrastruktur zum Einsatz. Dies sind so genannte TURN-Server. Stellt ein WebRTC-Anbieter aus Kostengründen keinen TURN-Server zur Verfügung, so können nach Schätzung von Google ca 10-15% der Verbindungen nicht aufgebaut werden, weil die Anschlüsse der Teilnehmer nicht direkt miteinander kommunizieren können.

Kommt trotz Angebots eines TURN-Servers keine Verbindung zustande, so muss eine Einzelfallanalyse des Teilnehmer-Anschlusses erfolgen. Weitere Ursachen können Firewall-Probleme auf dem Rechner des Teilnehmers sein.

Bei einigen melavi-Verbindungen habe ich Verzögerungen bei der Audio-Übertragung.

Bei der Masse der WebRTC-Verbindungen (ca 85-90%) erfolgt die Audio- und Bild-Übertragung nur mit sehr kleiner Verzögerung. Dies ist durch das Peer 2 Peer Prinzip der direkten Datenübertragung von Teilnehmer zu Teilnehmer ohne Umweg über einen Vermittlungs-Rechner garantiert. Einige WebRTC-Verbindungen müssen aber wegen der Eigenschaften der Internet-Zugänge der Teilnehmer über so genannte Relay-Server (TURN Server) geleitet werden. WebRTC entscheidet beim Verbindungsversuch automatisch ob ein derartiger Umweg der Übertragung notwendig ist. Relay basierte Übertragungen haben eine prinzipiell höhere Verzögerung. Die Audio-Video Daten werden von den Teilnehmern zunächst zum Relay Server und von dort zur Gegenseite geschickt. Es entstehen also zusätzliche Verzögerungen durch Übertragungswege. Weitere Verzögerungen entstehen im Relay Server selbst.

Verbesserungen können einerseits durch die Nutzung von in der Nähe befindlichen Relay Servern erreicht werden. Als Beispiel - wenn ein Relay Server auf der anderen Seite der Erde genutzt wird, so entsteht bei "gerader" Strecke allein durch die Lichtgeschwindigkeit eine zusätzliche Laufzeit von ca 0,1 Sekunde. Deren Effekt ist schon stark spürbar. Falls der Einsatz eines Relay Servers also notwendig ist, sollte auf dessen räumliche Nähe geachtet werden. Andererseits, sollte der Internet-Anschluss der Teilnehmer soweit möglich so umgestellt werden, dass Peer 2 Peer Verbindungen möglich sind.

Es wird kein lokales Video angezeigt.

Es gibt verschiedene Gründe warum kein lokales Video trotz angeschlossener Web-Kamera angezeigt werden kann. Die beiden häufigsten Ursachen sind:

  • Die Kamera ist durch eine anderen Anwendung blockiert. Es ist z. B. nicht möglich die Kamera gleichzeitig von Google-Chrome und Mozilla-Firefox aus zu nutzen. Eine parallele Nutzung mit Skype ist ebenfalls nicht möglich. Beenden Sie die Anwendung, welche die Web-Kamera blockiert.
  • Der Zugriff auf die Kamera wurde im Browser nicht freigegeben. Wird eine Web-Anwendung über das Protokoll HTTP betrieben (zu erkennen an der URL: http://Anwendungsadresse), so verlangen die Browser aus Sicherheitsgründen bei jedem neuen Aufbau einer WebRTC-Verbingung die Freigabe der Kameranutzung. Dazu zeigen die Browser nach Registrierung beim melavi-Signalisierungs-Server einen Dialog, der zur Bestätigung auffordert. Dieser Dialog wird oftmals übersehen. Außerdem unterscheidet sich die Ansicht dieses Dialogs von Browser zu Browser. Hier sehen Sie z. B. die Freigabe-Dialoge der Browser Google-Chrome, Mozilla-Firefox und Opera-Software: UnlockCamAccess
    UnlockCamAccessFirefox
    UnlockCamAccessOpera Wenn Ihre Web-Anwendung über das sichere HTTPS-Protokoll betrieben wird, fordert der Browser nur bei erstmaliger Verbindungsaufnahme die Bestätigung an. Wird die Anwendung zu einem späteren Zeitpunkt wieder geöffnet, so prüft der Browser ob für diese über HTTPS authentifizierte Anwendung der Kamera-Zugriff schon freigegeben wurde und unterdrückt die Sicherheitsabfrage. Für professionelle Web-Anwendungen ist die Nutzung von HTTPS heute meist Standard, so dass die Nutzung von melavi hier entsprechend komfortabler und weniger anfällig für Bedienfehler ist.
Warum muss ich bei jeder melavi-Verbindungsaufnahme die Nutzung der Kamera neu erlauben?

Dies ist eine Sicherheitsfunktion von WebRTC fähigen Web-Browsern. Sie soll verhindern, dass der Zugriff auf eine lokale Rechner-Ressource, wie die Web-Kamera, automatisch allein durch Öffnen einer Web-Seite erfolgt. Ohne diese Bestätigung könnte der Zugriff auf die Kamera sehr einfach mißbraucht werden.

Die Bestätigung ist bei HTTP-basierten Web-Anwendungen (zu erkennen an der URL: http://Anwendungsadresse) bei jeder neuen WebRTC-Verbindungsaufnahme nötig. Bei sicheren HTTPS-Verbindungen erfolgt die Abfrage nur einmalig, da der Browser hier automatisiert prüfen kann ob die Freigabe für eine derart abgesicherte Web-Anwendung schon erfolgt ist. Dies ist einer der Vorteile der Nutzung von sicherem HTTPS anstelle von HTTP in professionellen Web-Anwendungen.

Ich habe den Zugriff auf meine Web-Kamera versehentlich gesperrt. Wie gebe ich diesen wieder frei?

Der Web-Browser benötigt bei HTTP-Verbindungen für jede Verbindungsaufnahme und bei HTTPS-Verbindungen einmalig die Freigabe des Zugriffs auf die Web-Kamera. Wenn Sie diese im entsprechenden Freigabe-Dialog des Browsers sperren, so ist der Zugriff für diese Web-Anwendung dauerhaft gesperrt. Der Browser speichert diese Information. Wird die Web-Anwendung, welche die Kamera benötigt, wieder geöffnet, so prüft der Browser seine Sperrliste. Ist die Anwendung hier aufgelistet, so erfolgt keinerlei Meldung, dass die Kamera nicht genutzt werden kann.

Um eine solche Sperre wieder freizugeben, muss der Eintrag in der Sperrliste des entsprechenden Browsers gelöscht werden. Die entsprechenden Optionen sind Browser-abhängig und meist versteckt. Bei Google-Chrome findet man die Sperrliste z. B. in den erweiterten Einstellungen unter Datenschutz/Inhaltseinstellungen.

Wenn zwei Teilnehmer unterschiedliche Browser benutzen, ist die Videoübertragung gestört.

Die WebRTC-Standardisierung ist gegenwärtig noch nicht vollständig abgeschlossen. Es ist davon auszugehen, dass 2015 eine erste Finalisierung erfolgt, die dann auch von den WebRTC-fähigen Web-Browsern umgesetzt werden muss. Gegenwärtig gibt es noch kleinere Unterschied in der WebRTC-Funktionalität der Browser, die gegebenenfalls Probleme bei einer so genannten Cross-Browser-Kommunikation mit sich bringen. So werden z. B. bei der Kommunikation zwischen einem Google-Chrome-Anwender und einem Mozilla-Firefox-Anwender Qualitätsstörungen beobachtet. Es kommt nach einiger Zeit zu ruckeligem Video und zu Übertragungsverzögerungen.

Auch wenn Cross-Browser-Übertragungen meist funktionieren, sollten zum gegenwärtigen Zeitpunkt der WebRTC-Entwicklung die beiden Teilnehmer den gleichen Browser nutzen, um potentielle Probleme an dieser Stelle auszuschließen und um in Genuss der optimalen Qualität zu kommen.

Allgemeine Fragestellungen zum Thema WebRTC-Internet Live-Kommunikation

Welche Vorteile bietet WebRTC im Vergleich zu klassischen Verfahren wie Skype oder Adobe Flash?

Eine detailierte Übersicht ist hier gegeben. Zusammenfassend sind bietet WebRTC die folgenden wesentlichen Vorteile:

  • WebRTC-Datenübertragungen sind sicher. Im Vergleich zu anderen Verfahren, werden anerkannte, öffentliche Verschlüsselungsstandards eingesetzt. Ein Zugriff auf die Daten ist nur für die Teilnehmer einer Sitzung möglich.
  • WebRTC ist flexibel. Durch eine standardisierte Schnittstelle erlaubt WebRTC die Einbettung von Audio-, Video und sonstigen Live-Daten in eigene Web-Anwendungen. Damit lassen sich komfortable, neuartige Anwendungs-Szenarien relisieren, die bisherigen Lösungen nicht zugänglich waren.
  • WebRTC ist plattformübergreifend mit Standard-Browsern ohne Plugins- und Sonder-Software nutzbar. Durch die Unterstützung von WebRTC in den drei großen Browsern Google-Chrome, Mozilla-Firefox und Opera-Software ist heute schon ein sehr großer Verbreitungsgrad auf verschiedenen Betriebssystemen sowohl für mobile als auch stationäre Anwendungen gegeben.
  • WebRTC ermöglicht den Aufbau eigenständiger Kommunikations-Infrastrukturen, welche die Aufgaben klassischer Telefon-Provider kostengünstig, sicher und funktional hochwertiger für Firmen-interne Zwecke umsetzen können.
  • WebRTC ist ein wohldefinierter Internet-Standard. Dies bietet die Garantie für die Sicherheit von Investitionen in diesem Bereich - sei es einerseits für die Entwicklung von Produkten wie melavi und sei es andererseits für die Einführung neuartiger WebRTC-basierter Anwendungs-Szenarien und Geschäftsmodelle.

Im Fachbeitrag und in den melavi-Demonstrationen dieser Site werden eine Reihe von Anwendungs-Szenarien diskutiert, welche sich aus diesen technologischen Vorteilen ergeben.

Ist die Übertragung meiner Daten sicher?

Der WebRTC-Standard legt fest, dass sämtliche Nutz-Daten-Übertragungen verschlüssselt zu erfolgen haben. Dies betrifft sowohl die Video- und Audio-Daten als auch andere Daten, die mittels WebRTC zwischen zwei Teilnehmern übertragen werden. Die Schlüssel für die Absicherung der Übertragung werden für jede Verbindung individuell zwischen den Teilnehmern automatisiert ausgehandelt. Die Verfahren, die für die Aushandlung der Schlüssel und für die Übertragung der verschlüsselten Daten verwendet werden, sind international standardisiert. Es gibt keine proprietären, Hersteller-abhängigen Verfahren. Eine Entschlüsselung der übertragenen Daten ist nur im Browser des Empfängers mit den Verbindungs-spezifisch ausgehandelten Schlüsseln möglich. Das "Abhören" dieser Daten in Zwischenstationen auf der Übertragungsstrecke ist nicht möglich bzw. nutzlos, das in jedem Punkt der Übertragungsstrecke nur verschlüsselte Datenpakete vorligen. Durch den Plattform-übergreifenden, öffentlichen Verschlüsselungsstandard ist ein hoher Sicherheitsfaktor gegeben.

Diese Aussage gilt für die Nutzdaten einer WebRTC Verbindung. Um auch die Signalisierungs-Daten, also die Daten welche für die Aufnahme von Verbindungen zwischen zwei Teilnehmern im Vorfeld ausgetauscht werden müssen, abzusichern, ist die Nutzung von SSL basierten Web-Übertragungen empfohlen. Dies ist bei professionellen Web-Anwendungen meist gegeben.

Welche Arten von Daten überträgt WebRTC?

Zunächst muss zwischen:

  • Nutzdaten und
  • Verbindungsdaten

unterschieden werden.

WebRTC stellt Übertragungskanäle für Nutzdaten mit beliebigem Inhalt direkt zwischen den Web-Browsern der Teilnehmer einer WebRTC-Sitzung zur Verfügung. Dies können sein:

  • Audio- und Video-Daten
  • Beliebige andere Daten, die zwei Teilnehmer austauschen möchten. Dazu gehören z. B. Text-Daten, beliebige Dateien oder auf beliebige Art formatierte Live-Daten wie z. B. Mess-Daten von Sensoren oder Börsen-Ticker-Daten.

Prinzipiell sind alle Nutz-Daten einer WebRTC-Verbindung unabhängig von ihrem Inhalt verschlüsselt

Die Signalisierungs-Daten sind Informationen, welche zwei Teilnehmer einer WebRTC-Sitzung vor Aufnahme der eigentlichen WebRTC-Übertragung austauschen müssen. Dazu gehören Informationen zur Art der Nutz-Daten und zu den Adressen der Teilnehmer der Sitzung. Die Sicherheit der Signalisierungs-Daten muss bei Bedarf unabhängig von WebRTC sichergestellt werden. Nutzt die Web-Anwendung SSL für die Absicherung ihrer Datenübertragungen so werden auch die WebRTC-Signalisierungsdaten entsprechend verschlüsselt.