Ein offenes und föderales Video- und Audiokonferenztool

Kommunikation und Interaktion sind menschliche Bedürfnisse genau wie essen und trinken. Gerade in diesen Zeiten haben viele gemerkt, dass ihnen ohne soziale Kontakte etwas Entscheidendes fehlt. In der Berufswelt geht es meistens auch nicht alleine, denn nur im Team kann man größere Projekte verwirklichen und zu einem erfolgreichen Abschluss bringen. Durch Kommunikation können nicht nur unterschiedliche Fachgebiete, Wissensstände oder persönliche Einschätzungen zusammen gebracht werden, sondern sie erlaubt es ganz neue Ideen zu entwickeln. Wer kennt es nicht, dass die besten Ideen an der Kaffeemaschine entstehen? Genau dieser persönlich Austausch wird umso schwieriger je geografisch verteilter das jeweilige Team organisiert ist, oder je strikter die Kontaktbeschränkungen in z. B. einer Pandemie sind. Aus diesen Gründen sind Videokonferenzsysteme (VKS) gerade zuletzt immer populärer geworden. Wo früher spezielle Kameras gekauft werden mussten und nur in geschlossenen Systemen kommuniziert werden konnte, gibt es heute unzählige Lösungen die eine mehr oder weniger einfache Teilnahme über den jeweiligen PC ermöglichen.

Bei allen Produkten besteht aber weiterhin das Problem, dass man sich auf den jeweiligen Anbieter verlassen und sich in das jeweilige System einarbeiten muss. Das erste Problem lässt sich durch selbst betriebene Lösungen beheben, aber es bleibt der Umstand, dass alle Teilnehmer*innen sich an dem jeweiligen System anmelden und die Oberfläche sowie Funktionen erst einmal kennenlernen müssen. Von einer Möglichkeit ein Profil, inklusive Name und Profilfoto, für alle Remote-Besprechungen zu nutzen sind wir weit entfernt. Zumindestens bis jetzt, denn dieses Projekt hat dieses Problem gelöst. Durch ein föderiertes VKS ist es nun möglich, Besprechungen auch über Unternehmensgrenzen hinweg durchzuführen. In den nächsten Abschnitten möchten wir Ihnen genauer erklären, wie dies möglich ist, welche Hürden es in der Zukunft noch zu lösen gilt und wie Sie das System selbst testen können.

Figure * ARABIC 1: Darstellung einer Videokonferenz in JSXC mit drei Teilnehmer*innen

XMPP und JSXC

Offene digitale Kommunikation über Anbietergrenzen hinaus ist kein neues Problem und Lösungen hierfür gibt es seit dem Beginn des Internets. Eine der bekanntesten dürfte die gute alte E-Mail sein. Ohne Zwang kann jede*r den für sich besten Anbieter wählen und der Austausch von Nachrichten untereinander mit einem selbstgewählten E-Mail-Programm ist kein Problem. Das selbe Konzept nur für Echtzeitnachrichten (Chat-Nachrichten) bietet das etwas jüngere, aber doch etablierte XMPP (Extensible Messaging and Presence Protocol, gegründet unter dem Namen Jabber). Wie der Name vermuten lässt, ist dieses Protokoll einfach erweiterbar und somit auch für Anwendungen weit abseits von Mensch-zu-Mensch Kommunikation geeignet. Viele proprietäre Lösungen bauen auf XMPP auf, da es gut skaliert, es eine aktive Entwickler*innen-Community gibt und Enterprise Produkte existieren. Analog zu den verschiedenen E-Mail-Clients, die man benötigt um Nachrichten versenden und empfangen zu können, benötigt man auch bei XMPP ein entsprechendes Programm. Auch hier ist der Funktionsumfang abhängig von dem entsprechenden Produkt. Um beispielsweise Nachrichten verschlüsselt austauschen zu können, benötigen beide Kommunikationspartner*innen ein Programm, das diese Funktion unterstützt. Also ganz ähnlich wie beim Schreiben von E-Mails. Wenn beispielsweise nur ein*e Teilnehmer*in ein E-Mail-Programm mit der Unterstützung für verschlüsselte Nachrichten nutzt, kann keine Verschlüsselung eingesetzt werden. Aus diesem Grund ist es wichtig, die Wahl eines entsprechenden Programms gut zu überlegen.

Damit dies einfach ist, veröffentlicht die XMPP Software Foundation (XSF) jedes Jahr eine Liste von Erweiterungen, die die Community als verpflichtend für einen modernen Client ansieht. Somit muss man nur schauen, welches Programm mit einem entsprechenden Funktionsumfang wirbt. Eins davon ist der JavaScript XMPP Client (JSXC). Dieser web-basierte Client kann nicht nur in jede Webseite eingebunden, über unterschiedliche Apps in populäre Anwendungen wie Nextcloud integriert werden, sondern auch als Desktop-Variante bezogen werden. Mit seinem Funktionsumfang von verschlüsselter Ende-zu-Ende-Kommunikation, Dateitransfer, Gruppenchats und Video-/Audioanrufen bietet er sich für eine Vielzahl von Anwendungen an. Aus diesem Grund wollten wir ihm noch die letzte große Funktionslücke, die Möglichkeit von Audio- und Videokonferenzen, nachrüsten. Auch wenn das Bedürfnis nach Multimedia-Konferenzen groß ist, ist die Community bisher nicht über unterschiedliche Ansätze hierfür hinaus gekommen. Aus diesem Grund war das erste Problem, das es für uns zu lösen galt, eine entsprechende Protokollerweiterung zu entwickeln. Diese sollte sowohl einfach zu implementieren als auch effizient sein. Wie unsere Lösung strukturiert ist und wie sie funktioniert, erfahren Sie im nächsten Abschnitt.

Figure * ARABIC 2: Screenshot von JSXC mit geöffnetem Gruppenchat.

Architektur

Das Ziel einer Online-Konferenz ist es unterschiedliche Medien, wie Audio, Video, Folien, Bilder, oder Videos, mit mehreren Teilnehmenden zeitgleich zu teilen. Der einfachste Ansatz hierfür ist es, direkte Verbindungen zwischen allen Teilnehmer*innen aufzubauen (peer-to-peer, oder auch P2P abgekürzt). Dies bedeutet jede*r Teilnehmer*in sendet und empfängt einen Datenstrom an jede*n andere*n Teilnehmer*in (ein Mesh-Netzwerk). Der Vorteil dieser Methode ist, dass sie sehr einfach zu implementieren ist, wenn bereits Anrufe zwischen zwei Teilnehmenden möglich sind und keine weiteren Dienste involviert werden müssen. Ein Verbindungsaufbau ist also nur abhängig von den verwendeten Clients. Bei einer größeren Anzahl von Teilnehmer*innen stößt diese Methode aber schnell an ihre Grenzen, da ggf. der Datenstrom pro Teilnehmer*in unterschiedlich verarbeitet werden muss, was besonders bei mobilen Endgeräten oder Computern mit wenig Rechenleistung zu Problemen führen kann. Zusätzlich bieten die meisten privaten Internetanschlüsse eine asynchrone Übertragungsgeschwindigkeit, welche den Upload von Datenverbindungen, also das Senden von Medienpaketen, begrenzt. Gerade bei hochauflösenden Bildschirmübertragungen an viele Teilnehmende, kann dies zu einem limitierenden Faktor werden.

Aus diesem Grund empfiehlt es sich nach Möglichkeit, einen zentralen Vermittlungsdienst zu nutzen der die ein- und ausgehenden Medienverbindungen organisiert. Dies bedeutet, dass Clients Verbindungen zu diesem zentralen Service aufbauen und von dort die Daten von allen anderen Teilnehmer*innen erhalten. Je nach Implementierung spricht man von MCU (Multipoint Control Unit) oder SFU (Selective Forwarding Unit). MCU kombiniert beispielsweise alle Videosignale in ein einziges, indem es die Videos in einem vorgegebenen Raster anordnet und benötigt somit die geringste Bandbreite aller Möglichkeiten. Der Nachteil ist, dass das Layout der Videos vom Dienst vorgegeben wird und somit schlecht auf die jeweiligen Anforderungen des Endgeräts angepasst werden können. Zudem benötigt es für die Zusammenführung auf dem Server viel Rechenleistung. Aus diesen Gründen haben wir uns, neben der Implementierung der P2P Lösung, für die Nutzung eines SFU entschieden. Dieser Dienst verteilt alle eingehenden Signale an alle Teilnehmenden. Die*Der einzelne Teilnehmer*in sendet also nur einen Datenstrom, empfängt aber pro Teilnehmer*in einen. Dies sorgt für eine optimale Ausnutzung der asynchronen Bandbreite der meisten Internetanschlüsse. Zudem kann je nach Rechenleistung oder Verbindungsgeschwindigkeit nur ein Teil der z. B. Videosignale angefordert werden. Dies erlaubt es auch Personen mit schlechter Internetanbindung an einer Videokonferenz teilzunehmen.

Figure * ARABIC 3: Link eines Mesh-Netzwerks aus P2P-Verbindungen zwischen den Teilnehmenden. In der Mitte eine MCU, ber der alle Teilenehmenden exakt eine ausgehende und eingehende Verbindung haben. Bei einer SFU (rechts) muss jede*r Teilnehmende nur eine ausgehende Verbindung ausbauen, aber für jede*n Teilnehmende*n eine eingehende.

Implementierung

Das Ziel für die Implementierung war es, den Aufwand möglichst gering zu halten und auf bestehende Techniken wie Jingle (XEP-0166) zurück zu greifen. Jingle ist bereits weit verbreitet und wird genutzt um P2P-Media-Verbindungen auszuhandeln. Um diese Technik nun für mehrere Verbindungen gleichzeitig einsetzen zu können, bestand die Herausforderung darin, allen beteiligten Konferenzteilnehmer*innen mitzuteilen, wann die Sitzung startet und die Liste aller Personen zwischen allen Mitgliedern zu synchronisieren.

Hierfür nutzen wir als Basis den Multi-User Chat (XEP-0045) mit einer nicht anonymisierten Konfiguration, da hier das Benutzermanagement schon vorhanden ist und alle Personen die gegenseitige Benutzer ID (Jabber ID) bereits kennen. Wenn in einem dieser Räume nun eine Online-Konferenz gestartet werden soll, schickt ein Mitglied eine entsprechende maschinenlesbare Nachricht () in den Raum und damit an alle Mitglieder. Der Ablauf und Aufbau dieser Nachrichten ist angelehnt an Jingle Message Initiation (XEP-0353). Diejenigen, die teilnehmen möchten, senden nun eine passende “accept” Antwort. Da alle Nachrichten in derselben Reihenfolge bei allen Gruppenmitgliedern eingehen, wird nun diese genutzt um die Initiatoren der einzelnen Verbindungen festzulegen. Jedes Mitglied muss die Verbindung zu allen Personen initiieren, die ihre Antwort nach der eigenen geschickt haben. Zu beachten gilt, dass Personen nur Verbindungen von Benutzer*innen zulassen, die tatsächlich in diesem Raum sind und auch eine entsprechende Zustimmung zur Konferenz erteilt haben. Des Weiteren muss jede Nachricht eine Session ID enthalten, um mögliche Kollisionen zu unterbinden und jedes Mitglied muss seine vollständige User ID bei jeder dieser Nachrichten einfügen, da in MUC Räumen Nutzer*innen mit mehreren eigenen Geräten (multi-client support) angemeldet sein können. Zum Schließen einer Sitzung sendet jede Person eine dementsprechende Nachricht in den Raum um nachfolgenden Mitgliedern einen Überblick zu gewähren, wer gerade im Raum ist und wer nicht.

Unsere Implementierung für die Variante mit zentralem Dienst um Bandbreite zu sparen, funktioniert ähnlich wie der P2P-Ansatz. Es werden ähnliche Nachrichten in den Raum geschickt, aber die Nutzer*innen bauen nun nicht mit den anderen Mitgliedern eine Verbindung auf, sondern mit dem zentralen Server. Wir haben uns hier für den leicht zu erweiternden WebRTC Server Kurento entschieden der über eine Programmierschnittstelle konfiguriert werden kann. Sollte ein*e Nutzer*in sich nun dazu entscheiden, eine Konferenz zu starten, öffnet sie*er einen Kanal auf dem entsprechenden Server und startet eine Medienverbindung mit diesem. Im Anschluss veröffentlicht die Person die Kennung des Kanals im Raum. Alle Personen, die nun an der Konferenz teilnehmen möchten, öffnen selbst eine Medienverbindung mit dem Dienst und fragen alle Verbindungen von Personen, die ebenfalls teilnehmen möchten, am Server an. Im Anschluss wird in dem Raum wieder eine “accept” Nachricht gesendet, damit alle anderen Mitglieder wissen, dass sie nun die neue Verbindung anfordern können. Der Verbindungsabbau funktioniert analog zur P2P Variante.

Figure * ARABIC 4: Die linke Seite beschreibt den Ablauf in der P2P-Variante, bei der jedes Mitglied eine Verbindung zu allen Personen aufbaut, die nach ihr der Konferenz beitreten. Die rechte Seite zeigt den Ablauf einer SFU. Wie ersichtlich ist, werden im Raum die gleichen (propose, accept) Nachrichten gesendet. Nur der Verbindungsaufbau unterscheidet sich jeweils.

Nächste Schritte

Um unsere Protokollideen einer breiten Masse von Entwickler*innen zur Verfügung zu stellen, müssen wir diese nun in entsprechende Protokollentwürfe ausarbeiten und bei der XMPP Software Foundation einreichen. Daraufhin werden die Vorschläge innerhalb der Community diskutiert und unter Umständen weiter verbessert bzw. erweitert. Ein weiterer wichtiger Schritt ist die Vermittlung des SFU-Dienstes über XMPP. Zur Zeit findet das Erstellen und Verwalten von Kanälen noch über Websockets statt. Dies sollte in einem Produktivbetrieb nach Möglichkeit direkt über ein XMPP Server Modul möglich sein.

Veröffentlichungen

Weitere Informationen über JSXC erhalten Sie unter jsxc.org inklusive einer genaueren Protokollbeschreibung. Sollten Sie unsere Videokonferenzlösung testen wollen, können Sie dies unter jsxc.org/ptf machen. Den Quellcode des Clients sowie des SFU-Vermittlungsdienstes finden Sie unter github.com/jsxc

Fazit

In der Projektlaufzeit konnte ein Protokollentwurf sowohl entwickelt als auch implementiert werden. Hierbei hat sich gezeigt, dass XMPP ein gewachsenes Protokoll ist und ein tiefgreifendes Wissen nötig ist, um eine neue Erweiterung zu entwickeln. Die Hilfe aus der Community war hierbei sehr wichtig und die Beratung mit anderen Entwickler*innen hat des Öfteren neue Probleme in der Konzeption verhindert.

Über JSXC

Der JavaScript XMPP Client (JSXC) ist ein XMPP Client mit einem großen Funktionsumfang der sich sehr gut in bestehende Web-Anwendungen integrieren lässt. Über das duale Anmeldeverfahren ermöglicht er es, XMPP Verbindungen direkt bei der Anmeldung existierender Systeme aufzubauen ohne entsprechende Anpassungen auf dem Server. Im Zentrum der Entwicklung stehen Offenheit und maximale Kompatibilität. Mit seiner MIT Lizenz eignet er sich sowohl für den privaten wie auch geschäftlichen Einsatz.

Ich danke dem Bundesministerium für Bildung und Forschung für die Finanzierung des Projekts und dem Deutschen Zentrum für Luft- und Raumfahrt für die Unterstützung in der Förderzeit.