Remediați întreruperile de conexiune de tip Jitsi Meet „Ați fost deconectat”

Un apel Jitsi Meet poate afișa mesajul „Ați fost deconectat” atunci când conexiunea de semnal a întâlnirii se întrerupe, când traficul media WebRTC nu poate ajunge la puntea video sau când o rețea locală sau un browser întrerupe sesiunea. Începeți prin a verifica dacă problema afectează un participant sau pe toți. Această distincție vă spune de obicei dacă trebuie să depanați un dispozitiv și o rețea sau serverul Jitsi.

Listă de verificare rapidă pentru triaj

Nu modificați mai multe setări simultan. Testați o modificare, reluați aceeași întâlnire, dacă este posibil, și observați dacă simptomul se schimbă.

Mai întâi identificați care conexiune a eșuat

Jitsi Meet folosește WebRTC pentru audio și video în timp real. O întâlnire depinde de mai mult decât încărcarea paginii: browserul trebuie să mențină semnalizarea cu serverul și să stabilească o cale media către Jitsi Videobridge. Un participant poate rămâne uneori vizibil în cameră în timp ce media se blochează; un mesaj complet „Ați fost deconectat” poate indica o întrerupere mai amplă a sesiunii sau a semnalizării. Cauza exactă nu poate fi determinată doar din acel mesaj.

Notează ora întreruperii conexiunii, dacă browserul a afișat o solicitare de reconectare, dacă alți participanți au fost afectați și dacă întâlnirea a fost găzduită pe meet.jit.si sau pe un domeniu Jitsi privat. Evită să publici adresa URL a unei întâlniri private, numele sălii, token-ul de acces sau jurnalele needitate.

Verifică prezența unui participant utilizând un browser

1. Reconectați-vă o dată și confirmați linkul întâlnirii

Folosește acțiunea de reconectare de pe ecran dacă apare. Dacă întâlnirea nu se recuperează, deschide din nou linkul invitației originale într-o filă nouă și reia legătura. Confirmă dacă numele sălii și domeniul gazdei corespund invitației; o greșeală de scriere sau un link vechi poate duce la o altă sală sau gazdă. Dacă toată lumea este deconectată, așteaptă puțin și întreabă organizatorul întâlnirii dacă serviciul este încă disponibil înainte de a actualiza în mod repetat.

2. Testați un browser actualizat și compatibil

Actualizați browserul, închideți-l complet și încercați din nou întâlnirea. Dacă deconectarea se repetă, testați un alt browser curent acceptat de Jitsi. Referința browserelor acceptate de Jitsi listează notele despre asistența pentru browsere și platformă; verificați pagina respectivă, deoarece detaliile de asistență se pot schimba. Pe iPhone și iPad, diferite mărci de browsere utilizează același motor de browser subiacent, așa că încercarea unei alte mărci s-ar putea să nu izoleze o problemă a motorului de browser.

Pentru o comparație clară, încercați o fereastră privată sau dezactivați temporar extensiile care filtrează scripturile, blochează instrumentele de urmărire sau modifică solicitările de rețea. Dacă acest lucru rezolvă problema, reactivați extensiile pe rând pentru a identifica conflictul. Nu lăsați protecțiile de securitate dezactivate ca soluție permanentă.

3. Comparați rețelele

Mută-te mai aproape de punctul de acces Wi-Fi, întrerupe descărcările mari sau copiile de rezervă în cloud și testează o dată pe o altă rețea pe care ești autorizat să o utilizezi. Un hotspot telefonic poate ajuta la distingerea unei probleme de rețea de acasă sau de la locul de muncă de o problemă de browser sau server. Dacă Jitsi funcționează pe rețeaua alternativă, dar se deconectează în mod repetat pe cea originală, comunică administratorului de rețea ora testului și întreabă dacă traficul WebRTC în timp real este filtrat.

Un VPN, un proxy, un portal captiv sau un firewall pot întrerupe semnalizarea sau conținutul media. Dacă organizația dvs. necesită un VPN, nu ocoliți politica acestuia; întrebați departamentul IT dacă gazda Jitsi este permisă. Dacă vi se permite să comparați cu VPN-ul deconectat, faceți acest lucru doar pentru scurt timp și reactivați-l ulterior.

4. Verificați starea dispozitivului și a aplicației

Pe un telefon, mențineți aplicația sau browserul Jitsi în prim-plan în timpul unui test și dezactivați restricțiile de economisire a bateriei pentru testul respectiv, dacă dispozitivul permite acest lucru. Sistemele de operare mobile pot suspenda activitatea de rețea în fundal. De asemenea, verificați dacă aplicația și sistemul de operare sunt actualizate, apoi reporniți dispozitivul dacă conexiunea continuă să eșueze. O problemă legată de permisiunea microfonului sau a camerei afectează de obicei accesul la dispozitiv, mai degrabă decât să demonstreze o deconectare de la rețea, așa că tratați aceste simptome separat.

Când sunetul/videoul eșuează, dar pagina întâlnirii rămâne deschisă

Opriți temporar camera și verificați dacă sunetul devine stabil. Acest lucru poate reduce utilizarea lățimii de bandă, dar nu repară o rută de server întreruptă. Dacă semnalele audio și video eșuează împreună într-o rețea și funcționează în altă parte, investigați restricțiile firewall sau NAT. Ghidul de auto-găzduire Jitsi identifică TCP 443 pentru acces web general, UDP 10000 pentru întâlniri audio/video normale și TCP 5349 pentru rezervă atunci când UDP este blocat; utilizarea opțională STUN poate implica și UDP 3478. Acestea sunt cerințe de implementare la nivel de server, nu porturi pe care un participant ar trebui să le deschidă pe un dispozitiv personal. Consultați ghidul actual Jitsi privind firewall-ul și NAT .

Dacă întâlnirea funcționează pe o conexiune diferită, raportați comparația administratorului de rețea. Rugați-l să revizuiască regulile organizației pentru numele de gazdă Jitsi și traficul WebRTC, în loc să solicite o închidere generală a firewall-ului.

Verifică existența unui administrator Jitsi auto-găzduit

Confirmați accesibilitatea și calea media

Verificați dacă numele DNS public se rezolvă la serverul așteptat, dacă certificatul TLS este valid și dacă traficul necesar ajunge la gazda corectă. Dacă serverul se află în spatele unui router sau al unui firewall în cloud, inspectați atât firewall-ul gazdă, cât și grupul de securitate sau regulile de redirecționare a porturilor din amonte. O regulă în UFW nu ajută dacă firewall-ul în cloud blochează în continuare același trafic.

sudo ufw status verbose
sudo ss -lntup

Aceste comenzi afișează regulile firewall-ului local și socket-urile de ascultare; nu dovedesc că participanții externi pot accesa serviciul. Testați dintr-o rețea externă și confirmați că routerul sau furnizorul redirecționează traficul relevant către Jitsi Videobridge. Jitsi notează că implementările în spatele NAT pot necesita maparea corectă a adreselor publice și locale atunci când apelurile din exterior nu funcționează.

Verificați setările TLS, reverse-proxy și Docker

Pentru o implementare reverse-proxy, verificați dacă HTTPS funcționează și dacă proxy-ul redirecționează corect semnalizarea WebSocket. Ghidul oficial Docker documentează /xmpp-websocketruta și anteturile necesare exemplului său Nginx. Un proxy care deservește pagina, dar elimină WebSocket-ul, poate împiedica utilizatorii să mențină sesiunea de întâlnire.

Cu Docker Compose, verificați dacă PUBLIC_URLporturile de domeniu public se potrivesc cu cele utilizate efectiv de vizitatori și dacă porturile gazdă publicate se potrivesc cu configurația firewall-ului și proxy-ului. Ghidul Jitsi avertizează că servirea unei întâlniri reale direct prin HTTP în loc de HTTPS poate cauza probleme WebRTC. Evitați copierea fragmentelor de configurare dintr-o altă versiune Jitsi fără a verifica versiunea și metoda de implementare pe care o executați.

Corelați jurnalele serverului cu ora incidentului

Comparați momentul deconectării cu jurnalele de service. La instalările de pachete Debian sau Ubuntu, Jitsi documentează fișierele jurnal, inclusiv /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, și /var/log/prosody/prosody.log. Implementările Docker stochează jurnalele prin containerele lor, așadar inspectați ieșirea relevantă a containerului și directorul de configurare pentru versiunea instalată.

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

Căutați în jurul marcajului temporal al incidentului reporniri de servicii, modificări ale înregistrării bridge-ului, erori WebSocket, erori de certificat sau expirari repetate ale conexiunii. Redactați identificatorii participanților, numele camerelor, adresele IP și token-urile înainte de a partaja jurnalele. Ghidul de auto-găzduire Debian/Ubuntu recomandă, de asemenea, încercarea unui alt browser, verificarea suportului WebRTC și revizuirea regulilor firewall/NAT ca pași de bază de depanare.

Listă de verificare pentru escaladare

• Înregistrați gazda Jitsi, marcajul orar aproximativ și fusul orar, dispozitivul, sistemul de operare, versiunea browserului sau a aplicației și dacă problema afectează o singură persoană sau întreaga întâlnire.
• Rețineți dacă un alt browser sau o altă rețea modifică rezultatul.
• Pentru serverele găzduite în regim self-host, includeți actualizări recente ale proxy-ului, firewall-ului, DNS-ului, certificatului sau Jitsi.
• Partajați doar informațiile de diagnostic minime necesare, eliminând detaliile camerei private și acreditările.
• Dacă utilizați meet.jit.si sau o altă gazdă gestionată, trimiteți raportul organizatorului întâlnirii sau serviciului de asistență; participanții nu pot modifica configurația firewall-ului sau a serverului gazdei respective.

Cum se confirmă remedierea

Alăturați-vă unei întâlniri de test de pe dispozitivul și rețeaua originale, rămâneți conectat suficient de mult timp pentru a acoperi perioada în care apare de obicei eroarea și confirmați că sunetul și video rămân utilizabile. Repetați cu un alt participant dacă problema i-a afectat pe toți. Pentru o implementare auto-găzduită, verificați atât semnalizarea browserului, cât și conținutul media din afara rețelei serverului. Încărcarea cu succes a paginii nu este suficientă; întâlnirea ar trebui să rămână conectată, iar participanții ar trebui să poată face schimb de sunet și video.