ie Covid-19-Pandemie hat den größten Teil der Büroangestellten ins Home Office verbannt. Dennoch konnten viele Unternehmen, hier und da mit Einschränkungen, den Geschäftsbetrieb aufrechterhalten. Bei manchen Firmen funktionierte das sogar so gut, dass diese nach dem Ende der Pandemie ihre Mitarbeiter gar nicht mehr zwangsweise zurück in die Büroräume beordern wollen. Damit Teams weiter zusammenarbeiten können, benötigen sie die passenden virtuellen Kollaborationstools. Eine sehr wichtige Komponente ist dabei die Videokonferenz.

Gehostete Dienste wie Xoom, Google Meet, Webex oder Bluejeans verzeichneten während der Pandemie enorme Zuwächse. Es gibt aber auch Anwender, die den kommerziellen Closed-Source-Angeboten skeptisch gegenüberstehen. In der Vergangenheit sind bei mehreren der Dienste Sicherheitslücken publik geworden, die Hackern Zugriff zu den Konferenzen oder Teilnehmerdaten erlaubten. Auch lässt sich nicht komplett ausschließen, dass die Anbieter Konferenzen mitschneiden. Wieder andere Lösungen wie Ciscos Webex jubeln den Anwendern einen proprietären Client unter, der sich ungefragt als Systemdienst in Windows nebst Autostart einnistet.

Neben den kommerziellen Plattformen existieren aber auch freie Tools wie beispielsweise Jitsi Meet [1]. Diese Anwendung gibt es nicht nur als frei nutzbaren Dienst bei verschiedenen Anbietern im Internet. Die Umgebung basiert auf einer Gruppe von Open-Source-Programmen. Damit können Unternehmen und Privatpersonen ihren eigenen Videokonferenz-Server betreiben. Für ein simples Setup genügt dazu bereits eine VM bei Amazon oder in der Google Cloud. Komplexere Setups laufen dann besser auf einem Root-Server, physisch oder als VM.

Das Aufsetzen eines Jitsi-Servers ist prinzipiell recht simpel, doch leider kommen Sie dabei mit sehr vielen Konfigurationsdateien in den unterschiedlichsten Formaten in Kontakt. Wir berücksichtigen daher nur Auszüge der möglichen Konfiguration, um nicht den Rahmen zu sprengen. Die nahezu vollständige Beschreibung der Konfig-Dateien finden Sie in der Onlinedokumentation von Jitsi [2]. Als Plattformen verwenden wir dazu einerseits eine VM auf AWS und eine auf einem gehosteten Root-Server bei Hetzner. VMs auf AWS oder in der Google-Cloud lassen sich für Jitsi aber nur mit Einschränkungen nutzen oder bedürfen eines modifizierten Kernels.

Hyperscaler wie Amazon Web Services und Google Cloud (GCP) nutzen angepasste und funktionsreduzierte Kernel für ihre Linux-VMs. Dabei werfen die Anbieter diverse Funktionen und Kernel-Module aus den Distributionen, die aus der Betreibersicht in der Cloud nicht nötig sind. Bei den Debian- und Ubuntu-Templates entfernen Amazon und Google beiespielsweise alle Audiofunktionen und auch die dazugehörigen Treiber.

Das ergibt auf den ersten Blick Sinn, denn wer möchte schon auf einer Cloud-VM Audiodateien wiedergeben? Allerdings braucht Jibri, das Recording- und Streaming-Modul von Jitsi, sehr wohl Audiofunktionen. Es leitet den Real-Time-Audiostream einer Videokonferenz via virtueller Soundkarte zu ffmpeg weiter. Dazu bedarf es eines Dummy-Soundkartentreibers. Vereinfacht gesagt stellt dieser dann nur ein Mischpult mit Ein- und Ausgängen für Programme dar, ohne dabei jedoch Mikrofone und Lautsprecher zu haben. Unter Linux macht das die "Advanced Linux Sound Architecture" (ALSA) mit dem Loopback-Device "snd-aloop".

Die Debian-Kernel von AWS- und GCP-Maschinen kommen allerdings ohne das Kernelmodul "snd-aloop" daher. Ein Jitsi-Server kann so zwar Videokonferenzen verwalten, aber nicht aufzeichnen oder streamen. Der User muss hier entweder Jibri auf einem anderen System betreiben (beispielsweise einer VM im Datacenter) oder auf AWS/GCP eine VM mit einem Generic-Kernel oder einem eigenen Image betreiben. Bei AWS gibt es die Option, den funktionsreduzierten AWS-Kernel einer Debian-VM gegen den Generic-Kernel zu tauschen in "/etc/default/grub".

Jitsi selbst läuft nicht als eine große monolithische Applikation, sondern als kollaborierende Gruppe verschiedener Dienste. Nicht alle Services müssen dabei auf ein und derselben Maschine arbeiten. Wir beschränken uns an dieser Stelle jedoch auf den All-in-one-Betrieb.

Ein zentraler Bestandteil ist der XMPP-Server "Prosody". Der Instant-Messaging-Dienst verwaltet nicht nur die Chatfunktion der Videkonferenzen, er vermittelt auch die Kommunikation der Jitsi-Komponenten untereinander. Zudem kann er als Benutzerverzeichnis und Authentisierungsdienst auftreten. Die Komponente "Jitsi Meet" stellt in erster Linie den Content für den Webserver (Nginx) und damit die Portalanwendung (JavaScript) bereit. Die eigentliche Videokonferenz vermittelt die "Jitsi-Videobridge" (Java) via WebRTC mit Unterstützung des "turnserver"-Diensts. Letzterer kümmert sich darum, dass die UDP-Echtzeit-Kommunikation die NAT-Dienste der Clients passieren darf.

Der Dienst "Jibri" sorgt dafür, dass Nutzer einzelne Konferenzen aufzeichnen oder in Echtzeit via Youtube streamen können. Im Text beschreiben wir das Recording-, nicht aber das Broadcast-Feature. Ebenfalls außen vor bleibt das Modul "Jigasi", das zwischen der Videokonferenz und SIP-Diensten (Internet-Telefonie) vermittelt. Jigasi sorgt dafür, dass Nutzer ohne Computer und Smartphone via Telefon und Audio-only an Konferenzen teilnehmen dürfen. Nur sehr wenige Anwender benötigen diese Funktion heute noch, daher gehen wir nicht weiter darauf ein. "Jicfolo" als weiterer Core-Service kümmert sich um das Session-Handling und Loadbalancing.

Das Jitsi-Projekt empfiehlt Debian oder Ubuntu als Plattform, daher nutzen wir für unseren Workshop eine VM mit einer Debian-10-Minimalinstallation. Alternativ lässt sich die Umgebung via Docker-Compose in fünf bis sechs Containern betreiben. Wir setzen auf die klassische Setupvariante. Wie üblich fügen Sie zunächst die Repositories für Prosody und Jitsi in die Debian-Konfiguration ein, installieren die Tools und die Dependencies und öffnen dann ein paar Firewall-Ports.

Jitsi benötigt für den Webserver die Ports 80 und 443, wobei Zugriffe via Port 80 nur einen direkten Rewrite auf 443 erhalten. Dennoch sollte Port 80 offen bleiben, damit das Tool "certbot" von Let's Encrypt ein Zertifikat erhalten kann. Der eigentliche Videostream erfolgt über den UDP-Port 10.000. Die Dokumentation beschreibt zwei weitere Ports: 3478 UDP und 5349 TCP. Diese sind optional und kommen nur dann zum Einsatz, wenn die Clients Firewallprobleme mit UDP-Verbindungen auf Port 10.000 haben. Unser Testsetup funktionierte auch ohne die beiden Ports zuverlässig.

Da die Dienste untereinander via Namen kommunizieren, muss die Namensauflösung funktionieren. Hier müssen Sie eventuell von der Dokumentation abweichen. In den meisten Fällen binden Sie den Jitsi-Server nicht direkt an die externe IP-Adresse Ihres gehosteten Servers an, sondern verwenden für die VM eine interne IP-Adresse und nutzen die Firewall des Hosts, um die benötigten Ports per NAT an die VM weiterzuleiten. Das gilt auch bei AWS- oder GCP-Setups. Laufen alle Komponenten inklusive Jibri auf einer VM, geben Sie in der Datei "/etc/hosts" zwar den externen DNS-Namen der virtuellen Maschine an, verweisen dabei aber auf die interne und nicht die externe IP-Adresse. Andernfalls versuchen Komponenten wie Jibri den Jitsi-Dienst über die externe IP-Adresse zu erreichen, was aufgrund von NAT in den meisten Setups dann nicht funktioniert. Führen Sie in diesem Fall dann auch den in der Dokumentation angegebenen Schritt für den NAT-Harvester der Jitsi-Videobridge aus.

Installieren Sie abschließend, falls vorhanden, ihr SSL-Zertifikat in den Nginx-Server oder rufen Sie das mitgelieferte Let's-Encrypt-Skript auf. Sie können im Anschluss die Jitsi-Dienste direkt starten und haben bereits einen lauffähigen Videokonferenz-Server. Für den weiteren Verlauf nehmen wir an, Ihr Server heißt "video.example.com" und ihre Domain ist entsprechend "example.com". Das vereinfacht die Konfigurationsbeispiele.

Ohne zusätzliche Konfiguration steht Jitsi zwar sofort zur Verfügung, ist aber für jeden uneingeschränkt zugänglich. Auf der Homepage Ihres Servers kann ein Nutzer einfach einen Konferenznamen eintippen und das passende Meeting startet. Das funktioniert auch ohne das Portal, indem Sie der URL einen Meetingnamen anhängen, wie etwa "https://video.example.com/meeting1". Über das XMPP-Tool Prosody lässt sich eine Authentisierung erzwingen, dann wiederum müsste sich jeder Nutzer anmelden. In der Praxis bewährt sich ein Mischbetrieb: Nur authentisierte Nutzer (Moderator) können eine neue Videokonferenz starten. Dieser dürfen dann aber auch anonyme Nutzer ohne Eingabe eines Passworts beitreten. Damit verhindern Sie, dass Fremde Ihren Server verwenden, machen Ihren Teilnehmern aber den Zugang so einfach wie möglich. Doch gestaltet sich das Setup für Einsteiger damit ein wenig komplex. Da Jitsi aus mehreren Tools besteht, müssen Sie Änderungen an der Konfiguration in der Regel in mehreren Dateien umsetzen, die leider auch sehr unterschiedliche Syntax verwenden. Wir beleuchten dies nachfolgend anhand der Komponenten Prosody, Jitsi Meet und Jicofo.

Der XMPP-Server Prosody ist in der Skriptsprache LUA geschrieben. Die Konfiguration liegt unter "/etc/prosody/conf.avail" in der Datei "video.example.com.cfg.lua". Die verschiedenen Benutzergruppen teilt Prosody in Authentication Domains auf. Dabei dient der Servername als "MUC_Base", also als "Root" der "Multi User Chat"-Umgebung. In der langen Konfigurationsdatei deklariert Prosody zunächst die verschiedenen Chaträume und -gruppen, die hier auch als Kommunikationskanäle der verschiedenen Komponenten zum Einsatz kommen. Im Abschnitt

fügen Sie zunächst den Parameter

ein. Jetzt dürfen nur noch authentisierte Nutzer mit dem Jitsi-Server kommunizieren. Optional könnten Sie in einer Enterprise-Umgebung hier auch einen externen Authentication-Provider wie LDAP oder ein AD verwenden anstatt "internal_hashed". Für das simple Setup belassen wir die interne Authentication via XMPP-Protokoll und Prosody. Jetzt hätten Sie aber alle Gäste ausgesperrt, also deklarieren Sie in Prosody eine weitere Domain namens

Je nachdem, ob sich ein Nutzer authentisiert oder nicht, gehört er dann entweder zur Domain "video.example.com" oder "guest.video.example.com". Weitere Domains fügen Sie später für Jibri und die Recoder-Funktion ein. Im nächsten Schritt muss Jitsi den Domains verschiedene Rechte einräumen.

Die Konfiguration von Jitsi Meet liegt im Verzeichnis "/etc/jitsi/meet/" und heißt "video.example.com-config.js". Da das Jitsi-Frontend ein JavaScript-Programm ist, nutzt es auch die entsprechende Syntax für die Konfiguration. Die Datei deklariert die Variable "config" und darin auch "config.hosts", die die Domains festlegt. Hier fügen Sie nun die verschiedenen Prosody-Domains hinzu:

Jetzt kann Jitsi zwischen authentisierten und nicht authentisierten Nutzern unterscheiden. Wer eine Konferenz-URL öffnet, gilt zunächst als Gast, bis er sich authentifiziert. Dazu muss letzten Endes aber der Dienst "Jicofo" als Session-Handler wissen, wie und wo eine Authenisierung erfolgt. Also folgt im dritten Schritt die Konfiguration des Session-Handlers.

Die Konfiguration dieses Dienstes finden Sie in "/etc/jitsi/jicofo/jicofo.conf". Diese nutzt eine eigene "conf"-Syntax, die JSON ähnelt, aber die Kommas weglässt. Hier geben Sie für unser Beispiel Folgendes an:

Auch hier wäre eine abweichende Konfiguration nötig, sollten Sie den Dienst via eines externen Auth-Providers (etwa LDAP) verwenden. In unserem Beispiel mit der internen Authentifizierung legen Sie einfach Benutzer via prosody in der passenden Domain an:

Nach einem Neustart aller drei Dienste (prosody, jicofo, jitsi-videobridge) müssen sich Nutzer nun authentisieren, um neue Videokonferenzräume zu öffnen. An bereits geöffneten Konferenzen können dann aber anonyme Benutzer teilnehmen.

Um Konferenzen mitschneiden zu können oder diese live zu streamen, bedarf es eines weiteren Moduls namens "Jibri" (Jitsi Broadcast Infrastructure). Wie bereits erwähnt, kann Jibri auf demselben Server wie Jitsi oder auf einem externen System laufen. Die Installation und Konfiguration ist unter [3] gut beschrieben, aber leider nicht ganz vollständig, weswegen wir hier etwas genauer auf die Details eingehen. Jibri verwendet den Chrome-Browser sowie ffmpeg. Chrome benötigt eigentlich eine grafische Oberfläche, die ein Server-OS normalerweise nicht bereitstellt. Daher installieren Sie auf Ihrem Server zunächst eine "dummy"-UI und die benötigten Encoder-Tools:

Fügen Sie das Google-Chrome-Repository ein und installieren Sie den Browser:

Dann braucht Chrome eine Policy, die Warnmeldungen unterdrückt, weil es ja ohne UI läuft:

Zudem braucht das Setup den "Chromedriver". Dieses Werkzeug dient eigentlich für automatisierte Website-Tests. Jibri nutzt den Chromedriver jedoch, um die Browser-Instanz ohne UI fernsteuern zu können:

Installieren Sie Jibri und nehmen Sie den Jibri-User in den benötigten Gruppen auf mit den Befehlen

Jibri braucht wie erwähnt die Loopback-Soundkarte und muss dafür den Kernel-Treiber "snd-aloop" laden:

Damit Sie das System nicht neu starten müssen, laden Sie den Treiber interaktiv:

und prüfen Sie im Anschluss, ob die Loopback-Soundkarte läuft. Der Befehl

muss das Modul auflisten. Für den Recorder braucht Prosody wiederum eine eigene Domäne, die Sie in "/etc/prosody/conf.avail/video.example.com.cfg.lua" anhängen:

Zudem brauchen Sie einen User mit Moderator-Privilegien für den Dienst Jibri und einen User für den Recoder:

Die Konfigration des Jitsi-Servers muss nun wissen, dass Aufnahmen erlaubt sind und Ihren Recoder als "Hidden Domain" auflisten. Damit erscheint der "Recoder" nicht als separater Benutzer in Ihrer Konferenz. Sie tragen daher in "/etc/jitsi/meet/video. example.com-config.js" Folgendes ein:

Alternativ fügen Sie den Schalter "liveStreamingEnabled: true" ein. Darüber könnten Sie eine Konferenz etwa via YouTube live streamen. Auf diese Funktion gehen wir an dieser Stelle allerdings nicht weiter ein.

Die Konfiguration von Jibri selbst nehmen Sie in der Datei "/etc/jitsi/jibri/jibri.conf" vor. Verschiedene Anleitungen im Internet verweisen auf die "config.json"-Datei, was allerdings nur für alte Jibri-Versionen gilt. Eine vollständige "jibri.conf"-Datei finden Sie unter [4]. An dieser Stelle zeigen wir nur Ausschnitte der Konfigurationsdatei, auf die es ankommt:

Entgegen der Beschreibungen funktioniert in unserem Setup der Recoder nur dann, wenn das "id=" Feld nicht leer ist:

Der "Nickname" hat keine Bedeutung, der "Room-Name" samt Domain muss allerdings mit der weiter unten gelisteten Jicofo-Konfiguration übereinstimmen:

Die Passwörter und Usernamen für Jibri und Recoder müssen mit den zuvor via prosodyctl definierten Nutzern übereinstimmen:

Das angegebene Verzeichnis muss natürlich auf dem Server existieren (mkdir /srv/recordings) und dem Benutzer "Jibri" gehören (chown jibri:jibri /srv/recordings). Das optionale finalize-script startet am Ende der Aufnahme. Das könnten Sie unter anderem dazu nutzen, die Record-Datei auf ein Netzlaufwerk oder ein Cloudlaufwerk hochzuladen:

Der "Chrome"-Abschnitt gibt die Start-Flags an, mit denen der via Chromedriver ferngesteuerte Browser startet. Abschließend muss der Session-Handler Jicofo noch wissen, was er tun muss, wenn der Moderator in der Konferenz den "Record"-Knopf drückt. Dazu fügen Sie in der Konfiguration "/etc/jitsi/jicofo/sip-communicator.properties" die folgenden Zeilen ein, wobei Sie natürlich Ihre eigene Domain verwenden:

Startet der Moderator nun die Aufnahme, schickt Jicofo eine Nachricht an Jibri. Der Dienst hat dann 90 Sekunden Zeit, via Chromedriver und ffmpeg die Aufnahme zu starten, sonst gibt Jitsi einen Fehler aus.

Wenn Sie nun alle Dienste neu starten und als Moderator eine Sitzung öffnen, können Sie diese mitschneiden. Wie vorgeschrieben, benachrichtigt Jibri alle Teilnehmer über eine Audiodurchsage "Recording is on", dass der Mitschnitt läuft, und zeigt das auch in der Jitsi-UI mit einem roten "REC"-Symbol an.

Strenggenommen ist die Konfigration des Jitsi-Servers logisch und einfach, auch wenn das hier auf den ersten Blick komplex erscheint. Aufgrund der vielen verteilten Dienste mit eigenen Konfigurationsdateien schleichen sich aber gern Konfigurationsfehler ein. Alle Jitsi-Dienste und Prosody schreiben ausführliche Log-Dateien nach "/var/log/jitsi", "/var/log/jitsi/jibri" und "/var/log/prosody". Wenn in Ihrem Setup etwas nicht wie gewünscht funktioniert, finden Sie in diesen Logs genaue Hinweise auf die Ursachen.

Wer seine eigene Videokonferenz-Plattform betreiben will, bekommt mit Jitsi das passende Open-Source-Werkzeug. Auf den angebundenen PCs kommt es ohne proprietären Client nur mit dem Browser aus. Für Mobiltelefone und Tablets gibt es passende Apps, wobei eine Jitsi-Konferenz auch dort ohne App im Browser funktioniert. In unseren Versuchen hielt sich der Ressourcenbedarf der Server-VM in Grenzen. Unser Setup mit vier vCPUs und 16 GByte RAM genügte locker für Konferenzen mit einem Dutzend Teilnehmer. Dann muss das System aber mit geringer Latenz an das Internet angebunden sein und über ausreichend Bandbreite verfügen.