Naprawa zrywania połączenia w Jitsi Meet z komunikatem „Zostałeś rozłączony”

Połączenie Jitsi Meet może wyświetlić komunikat „Zostałeś rozłączony”, gdy połączenie sygnalizacyjne spotkania zostanie zerwane, gdy ruch multimedialny WebRTC nie dotrze do mostka wideo lub gdy sieć lokalna lub przeglądarka przerwie sesję. Zacznij od sprawdzenia, czy problem dotyczy jednego uczestnika, czy wszystkich. To rozróżnienie zazwyczaj wskazuje, czy należy rozwiązać problem z urządzeniem i siecią, czy z serwerem Jitsi.

Szybka lista kontrolna triażu

Nie zmieniaj kilku ustawień naraz. Przetestuj jedną zmianę, dołącz ponownie do tego samego spotkania, jeśli to możliwe, i zanotuj, czy objawy się zmieniły.

Najpierw zidentyfikuj, które połączenie nie powiodło się

Jitsi Meet wykorzystuje WebRTC do przesyłania dźwięku i obrazu w czasie rzeczywistym. Spotkanie zależy od czegoś więcej niż tylko ładowania strony: przeglądarka musi utrzymywać łączność z serwerem i nawiązać ścieżkę multimedialną do Jitsi Videobridge. Czasami uczestnik może pozostać widoczny w pokoju, nawet gdy multimedia się zawieszają; pełny komunikat „Zostałeś rozłączony” może wskazywać na dłuższą sesję lub przerwanie sygnału. Dokładnej przyczyny nie można ustalić na podstawie samego komunikatu.

Zanotuj godzinę zerwania połączenia, czy przeglądarka wyświetliła monit o ponowne połączenie, czy dotyczyło to innych uczestników oraz czy spotkanie odbyło się na meet.jit.si, czy w prywatnej domenie Jitsi. Unikaj publikowania prywatnego adresu URL spotkania, nazwy pokoju, tokena dostępu ani nieocenzurowanych dzienników.

Sprawdzanie uczestnika za pomocą przeglądarki

1. Połącz się ponownie i potwierdź połączenie ze spotkaniem

Skorzystaj z opcji ponownego połączenia na ekranie, jeśli się pojawi. Jeśli spotkanie nie zostanie wznowione, otwórz oryginalny link z zaproszeniem ponownie w nowej karcie i dołącz ponownie. Sprawdź, czy nazwa pokoju i domena gospodarza są zgodne z zaproszeniem; literówka lub stary link może prowadzić do innego pokoju lub gospodarza. Jeśli wszyscy są rozłączeni, odczekaj chwilę i zapytaj organizatora spotkania, czy usługa jest nadal dostępna, zanim ponownie odświeżysz stronę.

2. Przetestuj obsługiwaną, zaktualizowaną przeglądarkę

Zaktualizuj przeglądarkę, zamknij ją całkowicie i spróbuj ponownie rozpocząć spotkanie. Jeśli problem z rozłączeniem będzie się powtarzał, przetestuj inną przeglądarkę, która jest obsługiwana przez Jitsi. Lista obsługiwanych przeglądarek Jitsi zawiera listę obsługiwanych przeglądarek i uwagi dotyczące platform; sprawdź tę stronę, ponieważ szczegóły dotyczące obsługi mogą się zmieniać. Na iPhonie i iPadzie różne marki przeglądarek korzystają z tego samego silnika, więc wypróbowanie innej marki może nie wykryć problemu z silnikiem przeglądarki.

Aby uzyskać dokładne porównanie, spróbuj otworzyć okno prywatne lub tymczasowo wyłącz rozszerzenia filtrujące skrypty, blokujące moduły śledzące lub modyfikujące żądania sieciowe. Jeśli to rozwiąże problem, włączaj rozszerzenia pojedynczo, aby zidentyfikować konflikt. Nie pozostawiaj wyłączonych zabezpieczeń jako trwałego obejścia.

3. Porównaj sieci

Zbliż się do punktu dostępu Wi-Fi, wstrzymaj pobieranie dużych plików lub tworzenie kopii zapasowych w chmurze i przetestuj raz w innej sieci, do której masz uprawnienia. Hotspot telefoniczny może pomóc odróżnić problem z siecią domową lub firmową od problemu z przeglądarką lub serwerem. Jeśli Jitsi działa w sieci alternatywnej, ale wielokrotnie rozłącza się w sieci pierwotnej, podaj administratorowi sieci godzinę testu i zapytaj, czy ruch WebRTC w czasie rzeczywistym jest filtrowany.

Sieć VPN, serwer proxy, portal uwierzytelniający lub zapora sieciowa mogą zakłócać sygnalizację lub media. Jeśli Twoja organizacja wymaga sieci VPN, nie omijaj jej zasad; zapytaj dział IT, czy host Jitsi jest dozwolony. Jeśli masz możliwość porównania z rozłączonym VPN, zrób to tylko na chwilę i włącz ponownie po rozłączeniu.

4. Sprawdź stan urządzenia i aplikacji

Na telefonie, podczas testu, pozostaw aplikację Jitsi lub przeglądarkę na pierwszym planie i wyłącz ograniczenia oszczędzania baterii dla tego testu, jeśli urządzenie na to pozwala. Mobilne systemy operacyjne mogą zawiesić aktywność sieciową w tle. Sprawdź również, czy aplikacja i system operacyjny są zaktualizowane, a następnie uruchom ponownie urządzenie, jeśli połączenie nadal będzie zrywane. Problem z uprawnieniami do mikrofonu lub kamery zazwyczaj wpływa na dostęp do urządzenia, a nie świadczy o rozłączeniu sieci, dlatego należy traktować te objawy oddzielnie.

Gdy dźwięk/obraz zawodzi, ale strona spotkania pozostaje otwarta

Wyłącz tymczasowo kamerę i sprawdź, czy dźwięk się ustabilizuje. Może to zmniejszyć zużycie pasma, ale nie naprawi uszkodzonego połączenia z serwerem. Jeśli dźwięk i obraz nie działają jednocześnie w jednej sieci i działają w innym miejscu, sprawdź ograniczenia zapory sieciowej lub NAT. Poradnik samodzielnego hostingu Jitsi identyfikuje protokół TCP 443 dla ogólnego dostępu do internetu, UDP 10000 dla normalnych spotkań audio/wideo oraz TCP 5349 dla awaryjnego coturn w przypadku zablokowania protokołu UDP; opcjonalne użycie STUN może również obejmować protokół UDP 3478. Są to wymagania dotyczące wdrożenia po stronie serwera, a nie porty, które uczestnik powinien otworzyć na urządzeniu osobistym. Zapoznaj się z aktualnymi wskazówkami dotyczącymi zapory sieciowej i NAT Jitsi .

Jeśli spotkanie odbywa się na innym łączu, zgłoś to porównanie administratorowi sieci. Poproś go o sprawdzenie zasad organizacji dotyczących nazwy hosta Jitsi i ruchu WebRTC, zamiast wnioskować o całkowite wyłączenie zapory sieciowej.

Sprawdzanie administratora Jitsi hostowanego samodzielnie

Potwierdź dostępność i ścieżkę multimediów

Sprawdź, czy publiczna nazwa DNS jest rozpoznawana przez oczekiwany serwer, czy certyfikat TLS jest ważny i czy wymagany ruch dociera do właściwego hosta. Jeśli serwer znajduje się za routerem lub zaporą sieciową w chmurze, sprawdź zarówno zaporę sieciową hosta, jak i nadrzędną grupę zabezpieczeń lub reguły przekierowywania portów. Reguła w UFW nie pomoże, jeśli zapora sieciowa w chmurze nadal blokuje ten sam ruch.

sudo ufw status verbose
sudo ss -lntup

Te polecenia pokazują lokalne reguły zapory sieciowej i gniazda nasłuchujące; nie dowodzą one, że zewnętrzni uczestnicy mogą uzyskać dostęp do usługi. Przetestuj z sieci zewnętrznej i upewnij się, że router lub dostawca przekierowuje odpowiedni ruch do Jitsi Videobridge. Jitsi zauważa, że ​​wdrożenia z wykorzystaniem NAT mogą wymagać poprawnego mapowania adresów publicznych i lokalnych, gdy połączenia z zewnątrz nie działają.

Przegląd ustawień TLS, odwrotnego serwera proxy i Dockera

W przypadku wdrożenia z odwrotnym serwerem proxy należy sprawdzić, czy protokół HTTPS działa i czy serwer proxy poprawnie przekazuje sygnał WebSocket. Oficjalny podręcznik Dockera dokumentuje /xmpp-websockettrasę i nagłówki wymagane w przykładzie Nginx. Serwer proxy, który obsługuje stronę, ale pomija WebSocket, może uniemożliwić użytkownikom utrzymanie sesji spotkania.

W Docker Compose sprawdź, czy PUBLIC_URLodpowiadają one faktycznie używanym przez użytkowników domeną publiczną oraz czy opublikowane porty hosta są zgodne z konfiguracją zapory sieciowej i serwera proxy. W przewodniku po Jitsi ostrzega się, że obsługa prawdziwego spotkania bezpośrednio przez HTTP zamiast HTTPS może powodować problemy z WebRTC. Unikaj kopiowania fragmentów konfiguracji z innej wersji Jitsi bez sprawdzenia wersji i metody wdrożenia.

Powiąż logi serwera z czasem wystąpienia incydentu

Porównaj czas rozłączenia z logami serwisowymi. W instalacjach pakietów Debian lub Ubuntu, Jitsi dokumentuje pliki logów, w tym /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.logi /var/log/prosody/prosody.log. Wdrożenia Dockera przechowują logi w kontenerach, dlatego sprawdź dane wyjściowe odpowiedniego kontenera i katalog konfiguracyjny dla zainstalowanej wersji.

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

Przeszukaj znacznik czasu zdarzenia pod kątem restartów usług, zmian rejestracji mostu, awarii WebSocket, błędów certyfikatów lub powtarzających się przekroczeń limitu czasu połączenia. Usuń identyfikatory uczestników, nazwy sal, adresy IP i tokeny przed udostępnieniem logów. Przewodnik po samodzielnym hostingu w systemie Debian/Ubuntu zaleca również wypróbowanie innej przeglądarki, sprawdzenie obsługi WebRTC oraz zapoznanie się z regułami zapory sieciowej/NAT jako podstawowe kroki debugowania.

Lista kontrolna eskalacji

• Zapisz gospodarza spotkania Jitsi, przybliżony znacznik czasu i strefę czasową, urządzenie, system operacyjny, wersję przeglądarki lub aplikacji oraz informację, czy problem dotyczy jednej osoby czy całego spotkania.
• Zwróć uwagę, czy inna przeglądarka lub sieć spowoduje zmianę wyniku.
• W przypadku serwerów hostowanych samodzielnie należy uwzględnić ostatnie aktualizacje serwera proxy, zapory sieciowej, serwera DNS, certyfikatu lub Jitsi.
• Udostępniaj wyłącznie niezbędne informacje diagnostyczne, usuwając szczegóły dotyczące pokoju prywatnego i dane uwierzytelniające.
• Jeśli używasz meet.jit.si lub innego zarządzanego hosta, wyślij raport do organizatora spotkania lub działu wsparcia technicznego. Uczestnicy nie mogą zmieniać konfiguracji zapory sieciowej ani serwera tego hosta.

Jak potwierdzić poprawkę

Dołącz do spotkania testowego z oryginalnego urządzenia i sieci, utrzymuj połączenie wystarczająco długo, aby pokryć okres, w którym zazwyczaj występuje awaria, i upewnij się, że dźwięk i obraz nadal działają. Powtórz z innym uczestnikiem, jeśli problem dotyczył wszystkich. W przypadku wdrożenia hostowanego samodzielnie, sprawdź zarówno sygnalizację przeglądarki, jak i media spoza sieci serwera. Samo pomyślne załadowanie strony nie wystarczy; spotkanie powinno pozostać połączone, a uczestnicy powinni mieć możliwość wymiany dźwięku i obrazu.