Jitsi, Websockets und nginx
Diesen Beitrag schrieb ich 3 Jahre und 2 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
In diesem Artikel hatte ich euch dargelegt, wie ich Jitsi auf meinem Root-Server aus Docker-Containern heraus betreibe. Nach mehreren Überarbeitungen der Installation hier also ein kleines Update.
Es hat sich inzwischen ja leidlich herumgesprochen, dass ich für #tabsvongesternnacht eine eigene Jitsi-Instanz betreibe. Die tut im Großen und Ganzen auch genau das, was von ihr erwartet wird. Das Maximum gleichzeitiger Konferenzteilnehmer liegt bei 30, was auf einer 6-Core-Maschine ein wirklich ordentlicher Wert ist. Über die Monate habe ich natürlich regelmäßige Updates gemacht, und wie ich lernen durfte ist es dabei enorm wichtig, die gesamte Konfiguration einmal komplett durchzugehen. Das Projekt ist sehr in Bewegung, was sicherlich auch den Umständen geschuldet ist, und es ändert sich von Version zu Version häufig recht viel.
Was mir wirklich negativ aufstieß war die Tatsache, dass die Speakerstats plötzlich nicht mehr funktionierten – jenes nützliche Feature, das zumindest grob die Sprechzeiten der einzelnen Sprecher aufsummiert. Als ich darüber nachdachte fiel mir auf, dass auch der Indikator für den „dominant speaker“ nicht mehr funktionsfähig war. In den Fokus geriet nach einiger Recherche die Änderung von openBridgeChannel: seit Version 5142 ist die Default-Einstellung hierfür nämlich websocket, während sie in den Versionen zuvor lediglich true lautete.
Ich startete also eine Konferenz mit mir selbst und schaltete im Chrome die Developer Tools zu, und da wurde ich dann von Meldungen praktisch erschlagen: obgleich die Konferenz stand und sowohl Bild und Ton funktionierten, funktionierte im Hintergrund eine ganze Menge eben nicht. Hier eine (nicht notwendigerweise vollständige) Auswahl an Meldungen, die so durchrauschten (in den Logs der Docker-Container herrschte derweil übrigens verdächtige Ruhe):
SEVERE: EndpointMessageTransport still not connected.
Bridge Channel send: no opened channel.
Failed to send E2E ping request or response. undefined
Websocket connection to 'wss://....' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
Es kostete mich überraschend viel Zeit um zu kapieren, dass – zumindest in meinem Setup hier – nicht die Jitsi-Container bzw. deren Konfigurationen die eigentlichen Übeltäter waren, sondern der nginx, der als Reverse Proxy davor steht. Folglich musste ich auch nicht in den Containern herumstochern, sondern die Konfiguration des VHost korrigieren. Es gibt sogar ein nach wie vor offenes Issue auf GitHub dazu. Gut möglich, dass sich die Sachlage in anderen Setups ganz anders darstellt – mir hat folgende VHost-Konfig jedoch letztendlich alle Probleme behoben:
# file: "/etc/nginx/sites-enabled/meetup.conf"
server {
server_name meetup.unixe.eu;
listen [::]:443 ssl;
access_log /var/log/nginx/unixe.eu/meetup/access.log combined_vhost;
error_log /var/log/nginx/unixe.eu/meetup/error.log error;
ssl_certificate /etc/letsencrypt/live/unixe.eu/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/unixe.eu/privkey.pem;
client_max_body_size 512M;
location / {
proxy_pass http://127.0.0.1:8050;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
tcp_nodelay on;
}
}
Somit funktioniert die Ermittlung des „dominant speaker“ ebenso wieder wie die „Speaker Stats“ – was von den Konferenzwütigen mit Freude zur Kenntnis genommen wurde („Oh Mann, ich quatsche wirklich viel zu viel! :D“)
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
