© Andriy Popov, 123RF

Wer bei Videokonferenzen die Qualität und den Datenschutz nicht an externe Unternehmen auslagern möchte, installiert Jitsi Meet auf den eigenen Servern.

Verzweifelte Admins griffen zu Beginn der Corona-Krise nach jedem Strohhalm, um möglichst schnell Videokonferenzen für die Mitarbeiter auf die Beine zu stellen. Doch inzwischen kristallisieren sich die Risiken und Nebenwirkungen der gewählten, meist proprietären Lösungen in Form von Sicherheits- und Performance-Einbußen heraus .

So machte Zoom, eine beliebte Videochat-Lösung für Gruppen, durch Hackerangriffe und Datenschutzverletzungen von sich reden. Die angepriesene Ende-zu-Ende-Verschlüsselung erwies sich als nicht existent [1]. Zwar verwies das Unternehmen auf die Zusicherungen Dritter, kein Schindluder mit den gesammelten Daten zu treiben. Dennoch sah sich die Firma am Ende genötigt, die Datenschutzregeln zu überarbeiten und die Videoräume besser zu schützen [2].

Auch bei anderen kommerziellen Anbietern wie Hangouts, Houseparty, Meet oder Skype war nicht alles Gold, was glänzte. Der anhaltende Home-Office-Trend verursacht nicht selten Einbrüche in der Video-Performance. Workarounds dafür erweisen sich jedoch als schwierig, denn die Server zur Software kontrollieren die Anbieter.

Meet Jitsi!

Die Videochat-Software Jitsi Meet [3] zeigt, dass es auch anders geht. Sie wurde ursprünglich von der Firma BlueJimp in einem Team von 8 bis 10 Personen entwickelt. 2015 erwarb Atlassian (bekannt für Jira und Confluence) die Software und änderte die Lizenz von der LGPL auf Apache. Das Unternehmen interessierte sich vor allem für die Jitsi Videobridge (JVB), um sie als Feature in das hauseigene Hipchat zu integrieren und so Videochats für Gruppen einzuführen. 2018 trennte sich Atlassian jedoch vom Enterprise-Chat und verkaufte Jitsi dabei an 8X8, einen Videokonferenz-Anbieter [4].

Die Open-Source-Software ist nach wie vor frei erhältlich und ermöglicht aktuell über WebRTC Videokonferenzen mit bis zu 35 Teilnehmern. Kaskadierende Bridges, Octo [5] und die Videobridge 2 sollen die Teilnehmerzahl noch erweitern. Neben den Chrome-basierten Browsern, Safari und Firefox unterstützen auch Apps für iOS- und Android-Geräte Jitsi Meet, das damit plattformübergreifend funktioniert.

Räume wie Schäume

Jitsi Meet arbeitet auf Basis von Chat-Räumen, die die Anwender dynamisch erzeugen. Läuft der Jitsi-Server unter https://jitsi.lm-online.de, öffnet ein Anwender einen Chat-Raum, indem er die URL »https://jitsi.lm-online.de/LinuxMagazin« aufruft. Er generiert so den Raum »LinuxMagazin« und lädt dann einfach die anderen Teilnehmer per URL ein.

Standardmäßig darf jeder Nutzer eines Jitsi-Servers beliebige Räume öffnen. Der Betreiber des Servers kann aber auch nur authentifizierten Anwendern erlauben, neue Räume anzulegen [6]. Dann fragt Jitsi Meet beim ersten Aufruf von https://jitsi.lm-online.de/LinuxMagazin nach einem Passwort. Nur wer es kennt, darf den Raum erzeugen.

Anwender, die einen Raum zuerst betreten, erhalten automatisch Moderatorenrechte. Sie dürfen dann zum Beispiel ein Passwort für den Raum setzen oder alle anderen Teilnehmer stummschalten, um etwa einen Vortrag zu halten. Verlässt der letzte Teilnehmer einen Chat-Raum, verschwindet dieser mit ihm.

Was Nutzer dürfen

Die Nutzer einer Videokonferenz dürfen in Jitsi Meet ihren Desktop mit anderen Anwendern teilen, Handzeichen geben (etwa bei Abstimmungen) und mit den Teilnehmern per Text-Chat kommunizieren. Externe Teilnehmer lassen sich über das SIP-Protokoll zuschalten, was serverseitig eine Installation von Jigasi [7] erfordert. Die Erweiterung erlaubt nicht nur ein- und ausgehende Telefonate, sondern auch Transkriptionen von Konferenzen, wofür sie aktuell das Speech-to-Text-API der Google Cloud verwendet.

Nutzer dürfen ihre Konferenz zudem an einen Youtube-Channel weiterleiten. Auf diese Weise können sie mehr externe Zuschauer zu einer Konferenz einladen, ohne die eigene Bandbreite zu belasten. Serverseitige Aufnahmen von Konferenzen sind ebenso möglich wie die Integration in den proprietären Instant Messenger Slack.

Brückenbau

Das Herzstück von Jitsi ist dabei die erwähnte Videobridge [8]. Sie läuft auf dem Server und verknüpft die Videokonferenz-Streams der Teilnehmer miteinander. Jitsi verwendet dazu eine Selective Forwarding Unit (SFU), einen bestimmten Typ von MCU (Multipoint Control Unit).

Grob vereinfacht gibt es drei Möglichkeiten, mehrere Videoteilnehmer zu verschalten. Bei einem Peer-to-Peer-basierten Mesh-Netzwerk redet potenziell jeder Client mit jedem anderem, was sehr schnell eine große Anzahl an Verbindungen nötig macht, aber keine MCU erfordert.

Wer weniger Verbindungen bevorzugt, muss eine MCU einsetzen, die als Zentrum fungiert, um das sich die Clients quasi sternförmig gruppieren. Es gibt verschiedene Sorten von MCUs: Die erste, oft auch einfach nur als MCU oder Mixing bezeichnet, kombiniert alle eingehenden Streams und errechnet daraus einen neuen Stream, der sämtliche Teilnehmer zeigt.

Jitsi nutzt hingegen eine Selective Forwarding Unit als MCU. Die leitet lediglich die eingehenden Streams an alle anderen Teilnehmer weiter. Konferieren also die drei Teilnehmer A, B und C, schickt A seinen Stream an die SFU, die ihn an B und C weiterleitet. Umgekehrt empfängt A die Streams von B und C als eingehende Verbindungen.

Beide MCUs haben Vor- und Nachteile. Weil die Mixing-Variante die Streams selbstständig kombiniert, entsteht eine recht hohe Server-Last, was die Videokonferenzen verteuert. Zugleich braucht das Zusammensetzen der Streams Zeit, was im Livestream mitunter für Verzögerungen sorgt. Allerdings müssen die Teilnehmer der Videokonferenz nur einen Stream (den eigenen) hochladen und einen zweiten (den kombinierten) herunterladen.

Bei Jitsi dekodieren hingegen die Nutzer die eingehenden Videostreams der anderen Nutzer auf ihren Rechnern und Mobilgeräten. Dabei empfangen sie mehrere eingehende Streams, was eine höhere Bandbreite erfordert. Dafür bestimmen die Clients darüber, wie sie die eingehenden Streams in der grafischen Oberfläche anordnen. Es ist auch möglich, Streams in abgestuften Auflösungen zu senden und zu empfangen, was Bandbreite einspart.

Dafür werkelt die Videobridge relativ entspannt vor sich hin, weil sie nur die Header der RTP-Pakete verändert, die Payload aber nicht anrührt. Jitsi Meet läuft dank der SFU also auch auf schwächeren Maschinen.

Abbildung 1: In der Basisvariante braucht Jitsi Meet den Server Nginx, den XMPP-Server Prosody, die Serverkomponente Jicofo sowie ein oder mehrere Instanzen der Jitsi Videobridge. Quelle: Jitsi-Meet-Dokumentation

Komponenten-Kleber

Jitsi Meet benötigt neben einem Webserver wie Nginx oder Apache weitere Komponenten, um verschiedene Dienste abzudecken. Nicht alle sind zwingend nötig: Die Architekturskizze aus dem Github-Repository zeigt die Basisinstallation (Abbildung 1). Der folgende Teil stellt einige Komponenten kurz vor.

Die in Javascript geschriebene WebRTC-Anwendung Jitsi Meet bindet als Basiskomponente alle weiter unten erwähnten Komponenten ein. Sie setzt unter anderem ein installiertes Node.js voraus. Wer Jitsi Meet optisch anpassen möchte, sollte es selbst aus dem Quellcode übersetzen.

Die Jitsi Videobridge 2 ist das (skalierbare) Herzstück von Jitsi Meet, die oben erwähnte SFU. Die erste Version der XMPP-basierten Serverkomponente ging noch auf den Jitsi-Desktop-Client zurück und war technisch nicht mehr auf dem neuesten Stand. Die überarbeitete Version 2 erlaubt nun mehr Teilnehmer.

Der in LUA geschriebene plattformübergreifende Server Prosody [9] zählt neben JVB zu den Hauptkomponenten von Jitsi Meet. Die Server-Entwicklung findet jedoch in einem eigenständigen Projekt statt. Prosody verwendet das Protokoll XMPP [10], das es vielen Teilnehmern erlaubt, in Echtzeit miteinander zu kommunizieren. Die Software bringt eine Reihe eingebauter Komponenten mit, darunter MUC (Multi-User Conference), um Konferenzräume zu betreiben.

Jicofo steht für Jitsi Conference Focus [11]. Es handelt sich um eine notwendige Server-Komponente, die JVB2 ergänzt und die Media Sessions zwischen den Teilnehmern und der JVB koordiniert. Betritt ein Nutzer einen Raum, erzeugt das eine neue Focus-Instanz, und Jicofo generiert eine sogenannte Jingle-Session zwischen Teilnehmer und JVB. Um die Benutzerrollen zu verwalten, braucht Jicofo Root-Rechte.

Die optionale TURN- und STUN-Server-Komponente Coturn [12] installiert Jitsi Meet zumindest auf Debian 10 automatisch mit. Sie leitet den Traffic auch zwischen Jitsi-Teilnehmern weiter, die hinter einem NAT-Gateway sitzen und nur private IP-Adressen verwenden. Auch Server kommunizieren so aus einem privaten Netzwerk heraus mit externen Teilnehmern. Jitsi Meet verwendet für die Verbindungen das Ice4j-Protokoll [13], an dem die Entwickler unter dem Dach des Projekts arbeiten. Nicht zuletzt stellt Coturn direkte und verschlüsselte P2P-Verbindungen zwischen zwei Teilnehmern her.

Jigasi erweitert Jitsi Meet um ein SIP-Gateway. Die Software meldet sich als SIP-Client an, über den die Anrufer Calls aus dem Chat-Raum heraus starten oder dort annehmen. Dabei ist Jigasi selbst kein SIP-Server, sondern verbindet lediglich existierende SIP-Server und Back-2-Back User Agents (B2BUAs) mit Jitsi Meet. Zudem erlaubt Jigasi Speech-to-Text-Transkriptionen.

Über Jibri, die Jitsi Broadcasting Infrastructure [14], lassen sich Videokonferenzen aufnehmen und streamen. Dazu startet Jibri eine Chrome-Instanz, die das AV-Signal in einen Framebuffer rendert und dann mit Ffmpeg konvertiert. Das setzt ein Ffmpeg mit X11-Capture-Möglichkeit voraus. Jibri soll man auf einer separaten Maschine oder in einer VM betreiben, auf der keine anderen Anwendungen laufen, die das Display oder die Audioausgabe benötigen.

Es gibt noch weitere Komponenten; eine recht umfangreiche Sammlung liefert Githubs Jitsi-Repository [15]. Nicht alle der Komponenten sind noch aktuell, vor dem Einsatz empfiehlt sich daher eine kurze Suche im Community-Forum.

Verschlüsselung

Eine Ende-zu-Ende-Verschlüsselung für zwei Nutzer einer Videokonferenz ist über den sogenannten P2P-Modus möglich, wenn also zwei Nutzer eine direkte P2P-Verbindung herstellen. Dabei verwendet Jitsi, wie von WebRTC vorgesehen, SRTP-DTLS [16].

Eine E2E-Verschlüsselung für Gruppenkonferenzen bietet Jitsi Meet bislang nicht an, doch die Entwickler arbeiten daran [17]. Schuld ist die SFU, die eingehende Streams entschlüsseln und wieder verschlüsseln muss. Wer allerdings die SFU auf On-Premise-Servern laufen lässt, kontrolliert damit auch diese unsichere Passage und erhält so eine Art Ende-zu-Ende-Verschlüsselung.

Für die Medieninhalte verwendet Jitsi Meet die WebRTC-Verschlüsselung, während die Transportverschlüsselung (HTTPS) das Signaling und die Kommunikation zwischen Server und Client absichert [18]. Praktischerweise hat Jitsi Meet gleich ein Let’s-Encrypt-Skript an Bord, das der Admin nach der Installation einfach ausführt, um Jitsi mit HTTPS abzusichern.

Fazit

Wer über einen eigenen Server mit begrenzten Kapazitäten verfügt, dem bietet Jitsi eine Alternative zu konventionellen Videokonferenz-Lösungen. Die SFU sorgt dafür, dass die Hauptlast bei den Clients liegt. Zugleich lässt sich auf dem eigenen Server der Datenschutz besser gewährleisten.

Jitsi Meet funktionierte in Tests plattformübergreifend mit verschiedenen Browsern und Mobilgeräten, Grenzen setzen eher die Internet-Anbindungen der Teilnehmer. Performance-Tuning verhilft in diesem Fall zu besseren Übertragungen auch mit mehreren Teilnehmern. Ein Artikel in der nächsten Ausgabe widmet sich der Installation und den Optimierungsmöglichkeiten.