Jitsi Best Practice und Skalierung

Seit nun mehr als zwei Wochen wird dort wo es möglich ist von Zu Hause aus gearbeitet. Home-Office für ALLE! Naja mindest für die die es können.

Damit ist auch von einem Tag auf den anderen der Bedarf an Kommunikations-Werkzeugen vor allem für Video-Konferenzen gestiegen.

Hierfür gibt es einige Plattformen welche mittels Jitsi Video- und Audiokommunikation als Service anbieten. Darunter auch NETWAYS Web Services

Jitsi ist eine Freie Software welche auch selbst betrieben werden kann.

Beim Betrieb von Jitsi jedoch zeigt sich das Jitsi sehr schwierig in der Skalierung ist. Es benötigt die richtigen Ressourcen und die richtigen Clients für die Nutzung, um nicht ab einer zweistelligen Zahl von Nutzern in einen reinen Ton- und Bildsalat zu enden. Die technischen Dokumentationen jedoch sind nicht sehr ausgeprägt und durch ihre Zerstreuung sehr schwer zu einem ganzen zusammen zu fügen.

Daher werden wir uns folgend mit den Punkten Anforderungen, Skalierung und Nutzung auseinander setzen.

Empfehlung für einen eigenen Jitsi Server/Videobridge

Nach meinen Tests und der Güte an vorhandenen Quellen zur Hilfe und Dokumentation komme ich zu folgendem Ergebnis:

Betriebssystem: Debian 10 oder Ubuntu 1 8.04.4 LTS

Soviel CPU wie geht

(klingt komisch ist aber so) CPU: bei durchschnittlich 10 Teilnehmer pro Konferenz kommen ich mit 2vCPU für die Videobridge ganz gut klar. Mehr zur Skalierung der CPU findet ihr hier:

CPU: bei durchschnittlich 10 Teilnehmer pro Konferenz kommen ich mit 2vCPU für die Videobridge ganz gut klar. Mehr zur Skalierung der CPU findet ihr hier: jitsi-videobridge-performance-evaluation CPU Jitis/Jifico/Prosody: Hier würde auch eine (v)CPU ausreichen, hängt jedoch auch wieder von der Frequentierung ab.

RAM: 4-8 GB für beide Server-Varianten

Speicherplatz: max. 50 GB SSD für beide Server-Varianten

Eine hohe Bandbreite

Die Unstable Version von Jitsi:

# install the key wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add - # add the unstable repo sh -c "echo 'deb https://download.jitsi.org unstable/' > /etc/apt/sources.list.d/jitsi-unstable.list" apt update

Eine gute Installations-Anleitung dazu gibt es zum einen von Jan Doberstein auf seinem Blog jalogisch.de

oder auch sehr hilfreich und weiterführend auf der Seite lw1.at guides

Skalierung einer Jitsi Infrastruktur

Ausgangslage

Wir haben einen vollständig installierten Jitsi Server Namens jitsi.example.com auf Basis von Debian. Jetzt wollen wir mehr mehr Ressourcen bereit stellen, so müssen wir weitere jitsi-videobridge Instanzen aufsetzen.

In der vollständigen Installation eines Jitsi-Servers auf Basis von Debian 10 sind folgende Pakete installiert:

ii jitsi-meet 1.0.4314-1 all WebRTC JavaScript video conferences ii jitsi-meet-prosody 1.0.3914-1 all Prosody configuration for Jitsi Meet ii jitsi-meet-web 1.0.3914-1 all WebRTC JavaScript video conferences ii jitsi-meet-web-config 1.0.3914-1 all Configuration for web serving of Jitsi Meet ii jitsi-videobridge2 1132-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)

Der Part jitsi-videobridge ist der Teil der den jtisi-meet mit der Video und Audio Übertragung versorgt. Er schließt sich an jitsi-meet und dem verwendeten prosody (XMPP-Server) an.

Anbindung einer Videobridge

Dazu binden wir die die Paketquellen auf dem zweiten Server vb1.example.com ein und installieren die Videobridge:

# install the key wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add - # add the unstable repo sh -c "echo 'deb https://download.jitsi.org unstable/' &gt; /etc/apt/sources.list.d/jitsi-unstable.list" apt update apt install jitsi-videobridge2

Sollte eine Firewall auf dem Server jitsi.example.com aktiviert sein so müssen wir den Port 5222 für eingehende Kommunikation öffnen.

Auf dem zweiten Server vb1.example.com passen wir jetzt die Datei “/etc/jitsi/videobridge/config” an:

# Jitsi Videobridge settings # sets the XMPP domain (default: none) JVB_HOSTNAME=jitsi.example.com # sets the hostname of the XMPP server (default: domain if set, localhost otherwise) JVB_HOST=jitsi.example.com ....

Dann kommen wir zu Datei für die SIP-Kommunikation. Diese sollte vom Hauptserver jitsi.example.com übernommen werden und die UUID sollte hierbei auf jedem Server unterschiedlich gesetzt sein.

Die Datei “/etc/jitsi/videobridge/sip-communicator.properties” wird wie folgt eingestellt:

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true org.jitsi.videobridge.ENABLE_STATISTICS=true # Notwendig falls der Server hinter einem NAT steht. org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=local-ip org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=public-ip org.jitsi.videobridge.STATISTICS_TRANSPORT=muc org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=jitsi.example.com org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.jitsi.example.com org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb org.jitsi.videobridge.xmpp.user.shard.PASSWORD= org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.jitsi.example.com #UUID am besten mit "uuidgen" neu gernieren muss auf beiden Servern Einzigartig sein. org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=9a6187f0-6d3f-46df-b1ff-ce7d2d69513a org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Auf Debian 10 tritt mit Java 11 folgender Fehler auf:

VB 2020-03-21 19:29:23.687 SEVERE: [16] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception. java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not "opens com.sun.management.internal" to unnamed module @54ca3634 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198) at java.base/java.lang.reflect.Method.setAccessible(Method.java:192) at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138) at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703) at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450) at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321) at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87) at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216) at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292) at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36) at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

Dieser kann beseitigt werden mittels folgender Ergänzung am Ende der Java System Properties in der Datei “/etc/jitsi/videobridge/config”:

JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED"

Nun können wir die Videobridge starten:

systemctl enable jitsi-videobridge && systemctl start jitsi-videobridge

An der Stelle geht auch ein Dank an Jan Doberstein der mich auf diese Spur gebracht hat und in seinem Blog-Folge Artikel zu Scaling Jitsi

Nutzung

Das Protkoll WebRTC, welches Jitsi nutzt, wird zur Zeit nur sauber von Google Chrome unterstützt. Somit sollte allen Nutzern dieser Browser, für die Anwendung am Notebook empfohlen werden. Für Androide und iOS Geräte gibt es Applikationen den jeweiligen App-Stores. Sehr schöne Zusammenfassung und eine ausführliche Benutzer-Anleitung hierzu gibt es auch auf der Seite des Freifunk München.

Sicherheit

Zum Thema Sicherheit empfiehlt es sich am Besten zuerst die Stunning-Server von Google in der Datei “/etc/jitsi/meet/jitsi.example.com-config.js zu ersetzen. Eine geeignete Stunning-Server Konfiguration kann wie folgt lauten:

stunServers: [ { urls: 'stun:stun.schlund.de:3478' }, { urls: 'stun:stun.t-online.de:3478' }, { urls: 'stun:stun.1und1.de:3478' }, { urls: 'stun:stun.hosteurope.de:3478' }, { urls: 'stun:stun.gmx.de:3478' }, ],

Zustätzlich wenn Ihr nicht eine gänzlich freie Plattform, sondern eine mit Moderaten oder sogennante Host per Raum gestützte Instanz betreiben wollt, empfiehlt es sich in prosody und jitsi-meet die Benutzerauthentifzierung für das erstellen von Räumen zu aktivieren.

In der Datei für die prosody-Konfiguration “/etc/prosody/conf.avail/jitsi.example.com.cfg.lua”, setzen wir den Wert für “authentication” auf “internal_plain” und fügen einen neuen VirtualHost darunter ein ein:

VirtualHost "jitsi.yourdomain.example" -- enabled = false -- Remove this line to enable this host authentication = "internal_plain" -- Properties below are modified by jitsi-meet-tokens package config -- and authentication above is switched to "token" --app_id="example_app_id" --app_secret="example_app_secret" -- Assign this host a certificate for TLS, otherwise it would use the one -- set in the global section (if any). -- Note that old-style SSL on port 5223 only supports one certificate, and will always -- use the global one. ssl = { key = "/etc/prosody/certs/jitsi.yourdomain.example.key"; certificate = "/etc/prosody/certs/jitsi.yourdomain.example.crt"; } -- we need bosh modules_enabled = { "bosh"; "pubsub"; "ping"; -- Enable mod_ping } c2s_require_encryption = false VirtualHost "guest.jitsi.example.com" authentication = "anonymous" c2s_require_encryption = false

In der Datei “/etc/jitsi/meet/jitsi.example.com-config.js” geben wir nun den neuen VirtualHost an:

var config = { hosts: { // XMPP domain. domain: 'jitsi.yourdomain.example', // When using authentication, domain for guest users. anonymousdomain: 'guest.jitsi.yourdomain.example', } }

Nun müssen wir noch jifico dazu veranlassen auch eine Authentifizierung durchzuführen und die Klasse in der “/etc/jitsi/jicofo/sip-communicator.properties” laden:

org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com

Danach müssen die Dienste neu gestartet werden:

sudo systemctl restart prosody.service sudo systemctl restart jicofo.service

Für die Anbindung einer Authentifizierung in Prosody gibt es auch Enterprise fähige Funktionen für LDAP und Co. Die obige Lösung beschreibt es für ein überschaubares Setup, denn die Benutzer hier müssen dann im Anschluss mit der prosodctl generiert werden:

prosodyctl register jitsi-meet.example.com

Abschließend bleibt zusagen…

Es ist nicht leicht gute Dokumentationen zu Jitsi und dessen Betrieb zu finden, eben so wie für das Scalling. Eine einheitliche Dokumentation gibt es nicht und somit macht es einen Gesamtüberblick nicht sehr leicht.

Neben der Jitis-Community und der Docs auf GitHub gibt es eine paar bereits schon erwähnte Artikel aber auch die sind rah. Daher die Bitte wenn jemand verbesserungen hat, meldet euch gerne!

Wenn Ihr eine Instanz dringend benötigt und euch nicht mit dem Betrieb ausseinandersetzen könnt oder naja vielleicht nicht wollt, dann schaut doch einfach bei unseren Kollengen von NWS vorbei. Dort bekommt Ihr aktuell mit dem Code #StayAtHome eine kostenlose Jitsi-Instanz für drei Monate und das ganz ohne Abo-Falle!

Also bleibt Zuhause und fragt euch gerade in diesen Tagen doch mindestens einmal am Tag:

1. Ist es wahr?

2. Ist es fair für alle Beteiligten?

3. Wird es Freundschaft und guten Willen fördern?

4. Wird es dem Wohl aller Beteiligten dienen?”

(Das sollten wir uns bei allem Fragen, was wir denken, sagen oder tun IMHO!)