Behebung des Jitsi Meet-Fehlers „Sie wurden getrennt“ bei Verbindungsabbrüchen

Bei einem Jitsi Meet-Anruf kann die Meldung „Sie wurden getrennt“ angezeigt werden, wenn die Signalisierungsverbindung des Meetings abbricht, der WebRTC-Mediendatenverkehr die Videobrücke nicht erreicht oder ein lokales Netzwerk oder ein Browser die Sitzung unterbricht. Prüfen Sie zunächst, ob das Problem nur einen Teilnehmer oder alle betrifft. Diese Unterscheidung gibt in der Regel Aufschluss darüber, ob Sie ein Gerät und das Netzwerk oder den Jitsi-Server überprüfen müssen.

Checkliste für die schnelle Triage

Ändern Sie nicht mehrere Einstellungen gleichzeitig. Testen Sie jeweils eine Änderung, nehmen Sie nach Möglichkeit erneut an derselben Besprechung teil und beobachten Sie, ob sich das Symptom ändert.

Zuerst ermitteln Sie, welche Verbindung fehlgeschlagen ist.

Jitsi Meet nutzt WebRTC für Audio und Video in Echtzeit. Für ein erfolgreiches Meeting ist mehr erforderlich als nur das Laden der Seite: Der Browser muss die Verbindung zum Server aufrechterhalten und einen Medienpfad zur Jitsi Videobridge herstellen. Es kann vorkommen, dass ein Teilnehmer im virtuellen Raum sichtbar bleibt, während die Medienübertragung einfriert. Die Meldung „Sie wurden getrennt“ kann auf eine Unterbrechung der gesamten Sitzung oder der Signalübertragung hinweisen. Die genaue Ursache lässt sich allein anhand dieser Meldung nicht ermitteln.

Notieren Sie den Zeitpunkt des Verbindungsabbruchs, ob der Browser eine Aufforderung zur erneuten Verbindung anzeigte, ob andere Teilnehmer betroffen waren und ob das Meeting auf meet.jit.si oder einer privaten Jitsi-Domain stattfand. Vermeiden Sie es, private Meeting-URLs, Raumnamen, Zugriffstoken oder ungeschwärzte Protokolle öffentlich zu posten.

Prüft, ob ein Teilnehmer einen Browser verwendet

1. Stellen Sie die Verbindung erneut her und bestätigen Sie den Meeting-Link.

Nutzen Sie die angezeigte Option zum Wiederverbinden. Falls die Verbindung nicht wiederhergestellt wird, öffnen Sie den ursprünglichen Einladungslink erneut in einem neuen Tab und treten Sie der Besprechung erneut bei. Vergewissern Sie sich, dass Raumname und Host-Domain mit der Einladung übereinstimmen; ein Tippfehler oder ein veralteter Link kann zu einem anderen Raum oder Host führen. Sollten alle Teilnehmer getrennt sein, warten Sie kurz und fragen Sie den Organisator der Besprechung, ob der Dienst noch verfügbar ist, bevor Sie die Seite wiederholt aktualisieren.

2. Testen Sie einen unterstützten, aktualisierten Browser

Aktualisieren Sie Ihren Browser, beenden Sie ihn vollständig und versuchen Sie erneut, an der Besprechung teilzunehmen. Sollte die Verbindung weiterhin unterbrochen werden, testen Sie einen anderen, von Jitsi unterstützten Browser. Die Jitsi- Referenzliste unterstützte Browser und Plattformen finden Sie dort; bitte prüfen Sie diese Seite regelmäßig, da sich die Support-Details ändern können. Auf iPhone und iPad verwenden verschiedene Browserhersteller dieselbe Browser-Engine. Daher kann die Verwendung eines anderen Browsers ein Problem mit der Browser-Engine möglicherweise nicht eingrenzen.

Um einen direkten Vergleich zu ermöglichen, versuchen Sie es mit einem privaten Fenster oder deaktivieren Sie vorübergehend Erweiterungen, die Skripte filtern, Tracker blockieren oder Netzwerkanfragen modifizieren. Falls das Problem dadurch behoben wird, aktivieren Sie die Erweiterungen nacheinander wieder, um den Konflikt zu identifizieren. Deaktivieren Sie die Sicherheitseinstellungen nicht dauerhaft als Notlösung.

3. Netzwerke vergleichen

Gehen Sie näher an den WLAN-Zugangspunkt heran, pausieren Sie größere Downloads oder Cloud-Backups und testen Sie die Verbindung einmal in einem anderen Netzwerk, für das Sie autorisiert sind. Ein mobiler Hotspot kann helfen, ein Problem mit Ihrem Heim- oder Firmennetzwerk von einem Browser- oder Serverproblem zu unterscheiden. Wenn Jitsi im alternativen Netzwerk funktioniert, aber im ursprünglichen Netzwerk wiederholt die Verbindung abbricht, teilen Sie dem Netzwerkadministrator den Zeitpunkt des Tests mit und fragen Sie, ob der WebRTC-Datenverkehr in Echtzeit gefiltert wird.

Ein VPN, Proxy, Captive Portal oder eine Firewall kann die Signalisierung oder die Medienübertragung unterbrechen. Falls Ihre Organisation ein VPN vorschreibt, umgehen Sie nicht die Richtlinien; fragen Sie die IT-Abteilung, ob der Jitsi-Host zugelassen ist. Wenn Sie einen Vergleich mit getrennter VPN-Verbindung durchführen dürfen, tun Sie dies nur kurz und aktivieren Sie die Verbindung anschließend wieder.

4. Geräte- und App-Zustand prüfen

Auf einem Smartphone sollte die Jitsi-App oder der Browser während eines Tests im Vordergrund laufen. Falls Ihr Gerät dies zulässt, deaktivieren Sie für diesen Test die Energiesparfunktionen. Mobile Betriebssysteme können die Netzwerkaktivität im Hintergrund unterbrechen. Prüfen Sie außerdem, ob App und Betriebssystem auf dem neuesten Stand sind, und starten Sie das Gerät neu, falls die Verbindung weiterhin fehlschlägt. Ein Problem mit den Mikrofon- oder Kameraberechtigungen beeinträchtigt in der Regel den Gerätezugriff und beweist keine Netzwerkunterbrechung. Behandeln Sie diese Symptome daher separat.

Wenn Audio/Video ausfällt, die Besprechungsseite aber geöffnet bleibt

Schalten Sie die Kamera vorübergehend aus und prüfen Sie, ob die Audioübertragung stabil ist. Dies kann die Bandbreitennutzung reduzieren, behebt aber keine Serverprobleme. Falls Audio und Video in einem Netzwerk gleichzeitig ausfallen, in einem anderen jedoch funktionieren, überprüfen Sie Firewall- oder NAT-Beschränkungen. Die Jitsi-Anleitung zum Selbsthosting nennt TCP 443 für den allgemeinen Webzugriff, UDP 10000 für normale Audio-/Videokonferenzen und TCP 5349 als Fallback für coturn, falls UDP blockiert ist; die optionale Verwendung von STUN kann auch UDP 3478 betreffen. Dies sind Anforderungen für die serverseitige Bereitstellung und keine Ports, die ein Teilnehmer auf einem persönlichen Gerät öffnen sollte. Beachten Sie die aktuellen Jitsi-Richtlinien zu Firewall und NAT .

Wenn das Meeting über eine andere Verbindung funktioniert, melden Sie dies dem Netzwerkadministrator. Bitten Sie ihn, die Organisationsrichtlinien für den Jitsi-Hostnamen und den WebRTC-Datenverkehr zu überprüfen, anstatt eine generelle Firewall-Abschaltung zu veranlassen.

Prüft, ob ein selbst gehosteter Jitsi-Administrator vorhanden ist.

Erreichbarkeit und Medienpfad bestätigen

Überprüfen Sie, ob der öffentliche DNS-Name zum erwarteten Server aufgelöst wird, das TLS-Zertifikat gültig ist und der erforderliche Datenverkehr den richtigen Host erreicht. Befindet sich der Server hinter einem Router oder einer Cloud-Firewall, prüfen Sie sowohl die Host-Firewall als auch die vorgelagerten Sicherheitsgruppen- oder Portweiterleitungsregeln. Eine UFW-Regel hilft nicht, wenn die Cloud-Firewall denselben Datenverkehr weiterhin blockiert.

sudo ufw status verbose
sudo ss -lntup

Diese Befehle zeigen lokale Firewall-Regeln und Listening-Sockets an; sie beweisen jedoch nicht, dass externe Teilnehmer den Dienst erreichen können. Testen Sie dies von einem externen Netzwerk aus und vergewissern Sie sich, dass der Router oder Provider den relevanten Datenverkehr an die Jitsi Videobridge weiterleitet. Jitsi weist darauf hin, dass bei Installationen hinter NAT möglicherweise eine korrekte Zuordnung von öffentlichen und lokalen Adressen erforderlich ist, wenn Anrufe von außerhalb nicht funktionieren.

Überprüfen Sie die Einstellungen für TLS, Reverse-Proxy und Docker.

Bei der Bereitstellung eines Reverse-Proxys überprüfen Sie, ob HTTPS funktioniert und der Proxy WebSocket-Signale korrekt weiterleitet. Die offizielle Docker-Anleitung beschreibt die /xmpp-websocketRoute und die benötigten Header für das Nginx-Beispiel. Ein Proxy, der die Seite zwar ausliefert, aber die WebSocket-Verbindung verwirft, kann dazu führen, dass Benutzer die Meeting-Sitzung nicht aufrechterhalten können.

Prüfen Sie bei Docker Compose, ob die angegebenen PUBLIC_URLPorts mit den tatsächlich von Besuchern verwendeten öffentlichen Domains übereinstimmen und ob die veröffentlichten Host-Ports mit Ihrer Firewall- und Proxy-Konfiguration kompatibel sind. Die Jitsi-Anleitung warnt davor, dass die direkte Bereitstellung eines Meetings über HTTP anstelle von HTTPS zu WebRTC-Problemen führen kann. Vermeiden Sie es, Konfigurationsabschnitte aus einer anderen Jitsi-Version zu kopieren, ohne die verwendete Version und Bereitstellungsmethode zu überprüfen.

Korrelieren Sie die Serverprotokolle mit dem Zeitpunkt des Vorfalls.

Vergleichen Sie den Zeitpunkt der Verbindungsunterbrechung mit den Dienstprotokollen. Bei Debian- oder Ubuntu-Paketinstallationen protokolliert Jitsi Protokolldateien wie `.js` /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log`.js` und /var/log/prosody/prosody.log`.js`. Docker-Bereitstellungen speichern Protokolle in ihren Containern. Überprüfen Sie daher die entsprechende Containerausgabe und das Konfigurationsverzeichnis Ihrer installierten Version.

sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.log

Suchen Sie im Umfeld des Vorfalls nach Neustarts von Diensten, Änderungen der Bridge-Registrierung, WebSocket-Fehlern, Zertifikatsfehlern oder wiederholten Verbindungsabbrüchen. Schwärzen Sie Teilnehmerkennungen, Raumnamen, IP-Adressen und Tokens, bevor Sie Protokolle weitergeben. Die Anleitung zum Selbsthosting unter Debian/Ubuntu empfiehlt außerdem, einen anderen Browser zu verwenden, die WebRTC-Unterstützung zu prüfen und die Firewall-/NAT-Regeln als grundlegende Schritte zur Fehlerbehebung zu überprüfen.

Eskalationscheckliste

• Notieren Sie den Jitsi-Host, den ungefähren Zeitstempel und die Zeitzone, das Gerät, das Betriebssystem, die Browser- oder App-Version und ob das Problem eine einzelne Person oder das gesamte Meeting betrifft.
• Beachten Sie, ob ein anderer Browser oder ein anderes Netzwerk das Ergebnis verändert.
• Bei selbstgehosteten Servern sollten Sie aktuelle Proxy-, Firewall-, DNS-, Zertifikats- oder Jitsi-Upgrades einbeziehen.
• Es werden nur die minimal notwendigen Diagnoseinformationen weitergegeben, wobei Details zum Privatzimmer und Zugangsdaten entfernt werden.
• Wenn Sie meet.jit.si oder einen anderen verwalteten Host verwenden, senden Sie den Bericht an den Organisator des Meetings oder den Service-Support; die Teilnehmer können die Firewall- oder Serverkonfiguration dieses Hosts nicht ändern.

So bestätigen Sie die Reparatur

Nehmen Sie von dem ursprünglichen Gerät und Netzwerk aus an einer Testbesprechung teil, bleiben Sie lange genug verbunden, um den Zeitraum abzudecken, in dem der Fehler üblicherweise auftritt, und prüfen Sie, ob Audio und Video weiterhin funktionieren. Wiederholen Sie den Vorgang mit einem anderen Teilnehmer, falls das Problem alle betrifft. Bei einer selbstgehosteten Installation überprüfen Sie sowohl die Browsersignalisierung als auch die Medienübertragung von außerhalb des Servernetzwerks. Ein erfolgreiches Laden der Seite allein reicht nicht aus; die Besprechung muss verbunden bleiben und die Teilnehmer müssen Audio und Video austauschen können.