Abstract
Web Real-Time-Communication (WebRTC) beinhaltet eine Reihe neuartiger Tech-
nologien und Standards zur qualitativ hochwertigen Audio-, Video- und Datenüber-
tragung zwischen Web-Nutzern und Nutzergruppen. Alles wird under der Prämisse
der Echtzeitkommunikation übertragen, so dass Interaktivität ermöglicht wird, also
der Dialog und Wechselbeziehung zwischen Nutzern für alle drei Arten der Übertra-
gung in WebRTC. So erlaubt WebRTC hiermit das Chatten, Telefonieren, Video-
Telefonieren, Screensharing, Webinars und Video-Games im Browser unabhängig
von der zugrunde liegenden Hardwareplattform, sei es mit Hilfe von Web- oder
mobilen Anwendungen ohne dass zusätzliche Plugins erforderlich sind. Hierfür ver-
wendet WebRTC eine Kommunikationsarchitektur die Datenübertragung auf zwei
Wegen ermöglicht. Eine Möglichkeit ist die Verwendung eines zentralen Servers,
der vom Dienstanbieter bereitgestellt werden muss. Daten an andere Clients in der
Session werden über den Server an die entsprechenden Empfänger weitergeleitet
(RELAY). Die zweite Möglichkeit ist die direkte Kommunikation der Clients unter-
einander (P2P). Da es aufgrund der Verwendung von Network Address Translation
(NAT) und Firewalls in der Regel unmöglich ist, direkt Daten an Clients in anderen
Netzwerken zu schicken, verwendet WebRTC Interactive Connectivity Establish-
ment (ICE), um direkte Kommunikation zu ermöglichen. WebRTC wird vom World
Wide Web Consorcium (W3C) und von der Internet Engineering Task Force (IETF)
entwickelt und standardisiert. Seit der initialen Veröffentlichung im Jahr 2011 wird
WebRTC von einer Vielzahl bekannter Dienste zur Bereitstellung von Echtzeitkom-
munikation verwendet. Zu diesen Diensten zählen u.a. Google Hangouts, Facebook
Messenger und Citrix GoToMeeting.
Diese Arbeit diskutiert Einflussfaktoren auf System und Netzwerkebene, welche
die Quality of Experience (QoE) im Kontext von WebRTC beeinflussen. Basierend
auf der Analyse bestehender Literatur zu den Themenbereichen Echtzeitkommu-
nikation und QoE wurde eine Reihe an Parametern, welche die Nutzererfahrung
beeinflussen, identifiziert. Mithilfe dieser Parameter wurden drei Metafaktoren Syn-
chronität, Stabilität und Qualität definiert, welche für die QoE relevant sind. Diese
werden mittels Key Performance Indikatoren (KPI) näher bestimmt. Jeder KPI be-
trachtet einen spezifischen Aspekt des Metafaktors, zu welchem er gehört. Um das
Verhalten der Metafaktoren zu untersuchen, wurde ein Mess-Framework implemen-
tiert. Dieses ermöglicht automatische und replizierbare Messungen von WebRTC-
Anwendungen im Browser. Im Rahmen dieser Messungen ist es möglich, das wie-
dergegebene Video, die Dauer einzelner Messungen, die Anzahl an Teilnehmern, so-
wie die Sendebandbreite zu definieren. Während der Messungen werden automatisch
Messdaten gesammelt. Im Anschluss werden die Daten aller Teilnehmer automatisch
auf einem Kontroll-PC gesammelt und für die Weiterverarbeitung organisiert. Das
Framework steht öffentlich zum herunterladen bereit. Mithilfe des Mess-Frameworks wurden mehrere Messreihen mit zwei und drei Teilnehmern durchgeführt, um QoE
Einflussfaktoren für WebRTC zu analysieren und näher zu bestimmen. Während der
Messreihen wurde die Bandbreite zwischen 250 kbit/s and 50 Mbit/s variiert.
Die allgemeine Evaluation der Messdaten zeigt, dass bei der Analyse der Einfluss-
faktoren von Nutzerzufriedenheit und QoE zwischen den verschiedenen möglichen
Kommunikationsmodi unterschieden werden muss. Falls an einer Session nur zwei
Teilnehmer teilnehmen, wird im Laufe der Session von RELAY zu P2P-Kommuni-
kation gewechselt. Gibt es hingegen drei Teilnehmer, wird während der gesamten
Session mittels RELAY kommuniziert. Dies trifft für die implementierte ICE- und
WebRTC-Serverinfrastruktur mit jitsi-Server und Chrome-Browser beim Client zu.
Hiermit wird die Datenmenge, welche von einem einzelnen Client gesendet werden
muss, reduziert. Vergleicht man die RELAY und die P2P-Phase von einer Messung
mit zwei Teilnehmern, ist auffällig, dass die RELAY-Phase unabhängig von der Netz-
werkbandbreite eine konstant hohe Stabilität der erfassten Parameter aufweist. Die
P2P-Phase hingegen benötigt eine gewisse Mindestbandbreite, um diese Stabilität
zu erreichen. In der P2P-Phase ist die maximal erreichbare Videobitrate allerdings
höher, was die Nutzerzufriedenheit laut QoE-Studien beeinflussen kann. Messungen
mit drei Teilnehmern weisen ein Verhalten vergleichbar mit der RELAY Phase von
Messungen mit zwei Teilnehmern auf.
Im Bezug auf den Metafaktor Synchronität ist auffällig, dass für alle Phasen
und sowohl mit zwei, als auch mit drei Teilnehmern, eine Mindestbandbreite von
500 kbit/s notwendig ist, um eine gute Bewertung der Synchronität zu erreichen.
Eine Ausnahme hiervon bildet die Audio/Video-Synchronisation. Diese erfordert im
Fall von zwei Teilnehmern eine Mindestbandbreite von 2.0 Mbit/s. Nehmen drei Cli-
ents an der Messung teil, sind die erreichten Werte für die Audio/Video-Synchronität
durchgängig schlechter als für zwei Clients.
Der zweite Metafaktor ist Stabilität. Für diesen gibt es größere Unterschiede be-
zogen auf das Verhalten von RELAY und P2P-Phase. Während der RELAY-Phase
werden durchgängig hohe Werte für die verschiedenen KPIs berechnet. Die berech-
neten Werte ändern sich zeitweise, allerdings sind sie dennoch konstant höher als die
Werte der P2P-Phase. Bezogen auf den KPI Auflösung, liegt der Haupgrund für die
schlechte Bewertung der P2P-Phase in der Art und Weise, wie die Videoauflösung
an die verfügbare Bandbreite angepasst wird. Im Fall des zweiten KPIs, welcher die
Videoauflösung betrachtet, zeigt die P2P-Phase ein Verhalten ähnlich zum ersten
Metaparameter. Geringe Bandbreiten führen zu schlechten Werten. Mit steigender
Bandbreite verbessern sich diese und bleiben nach dem Erreichen des Maximums
konstant. Aufgrund des beschriebenen Verhaltens wird die Stabilität der RELAY-
Phase konstant besser bewertet als die der P2P-Phase. Messungen mit zwei Teil-
nehmern zeigen ein Verhalten ähnlich der RELAY-Phase von Messungen mit zwei
Teilnehmern.
Qualität ist der dritter Metafaktor. Unabhängig von der konfigurierten Bandbrei-
te erreicht die P2P-Phase hier immer bessere Bewertungen als die RELAY-Phase,
was auch im angegeben Modell in der Arbeit durch Zahlen bestätigt wird. Zwi-
schen der Bewertung von Audio- und Videodaten gibt es signifikante Unterschiede.
Aufgrund technischer Einschränkungen unterstützt das Messframework keine Wie-
dergabe von Audio. Das führt dazu, dass automatisch eine regelmäßige Abfolge von Pieptönen wiedergegeben wird. Wir vermuten, dass dies dazu führt, dass der Audio
Adaptionsmechanismus von WebRTC nicht funktioniert. Aufgrund dieser Annahme
betrachten wir die Audioqualität als konstanten Faktor. Der zweite KPI, welcher
die Qualität betrifft, behandelt die Videoqualität. Sofern die verfügbare Bandbrei-
te größer als 2.0 Mbit/s ist, erreicht die P2P-Phase konstant bessere Werte als die
RELAY-Phase. Andernfalls sind die Werte der beiden Phasen vergleichbar. Hohe
Bandbreiten zeigen eine Limitierung der RELAY-Phase bezüglich der Videobitrate.
Wir vermuten, dass es sich hierbei um Limitierungen handelt, welche vom Betreiber
des Dienstes eingerichtet wurden. Die Messungen mit drei Teilnehmern zeigen ein
ähnliches Verhalten wie die RELAY Phase, allerdings sind die maximal erreichten
Bitraten pro Video geringer.
Zuletzt definieren wir eine simple Abschätzungsfunktion QoE simple für die QoE
von WebRTC aufgrund unserer bisherigen Analyse für die Infrastruktur unseres
Frameworks. Diese ist definiert als der Durchschnitt der Metafaktoren. Die berech-
neten Werte für QoE simple zeigen, dass die RELAY-Phase für geringe Bandbreiten
geringfügig bessere Werte erreicht. Im Fall höherer Bandbreiten ergibt sich ein Vor-
teil zugunsten der P2P-Phase. Das Modell erlaubt WebRTC-Anbietern und Provi-
dern die Abschätzung der QoE über eine simple Messung von Einflussfaktoren. Die
subjektive Validierung des Modells wird in einer nächsten Arbeit angegangen. Alle
Metafakotoren wurden aufgrund des bisherigen Stands der Technik in der Literatur
ausgewählt und eingebunden.
Links and resources
Tags