Jitsi, Websockets und nginx

Geschätzte Lesezeit: 2 Minuten

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.

Speakerstats 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“)