Tijdens een Jitsi Meet-gesprek kan de melding 'U bent losgekoppeld' verschijnen wanneer de signaalverbinding van de vergadering wegvalt, wanneer WebRTC-mediaverkeer de videobridge niet kan bereiken of wanneer een lokaal netwerk of browser de sessie onderbreekt. Controleer eerst of het probleem één deelnemer of alle deelnemers treft. Dat onderscheid geeft meestal aan of u de problemen met het apparaat en netwerk of met de Jitsi-server moet oplossen.
Snelle triage-checklist
| Wat je observeert | Eerste controle | Waarschijnlijk te onderzoeken gebied |
| Slechts één persoon verbreekt de verbinding. | Opnieuw verbinding maken vanaf een ander netwerk of apparaat | Deelnemer Wi-Fi, VPN, browser, app of lokale firewall |
| Meerdere mensen verbreken tegelijkertijd de verbinding. | Vraag of ze dezelfde Jitsi-host gebruiken. | Server-, reverse proxy-, firewall-, internetverbindings- of servicefout |
| De vergadering blijft open, maar het geluid/beeld loopt vast. | Schakel de camera even uit en controleer of het geluid terugkomt. | Mediapad, bandbreedte, UDP-filtering of apparaatbelasting |
| De verbinding wordt alleen verbroken op het netwerk van één bedrijf of school. | Herhaal dit eenmaal met een goedgekeurde hotspot. | Netwerkbeleid, proxy, VPN of geblokkeerd WebRTC-verkeer |
| Het probleem begint na een server- of proxywijziging. | Controleer de recente configuratie- en servicelogboeken. | Instellingen voor Jitsi-signalering, TLS, NAT of firewall op een zelfgehoste server |
Wijzig niet meerdere instellingen tegelijk. Test één wijziging, neem indien mogelijk opnieuw deel aan dezelfde vergadering en noteer of het probleem zich voordoet.
Identificeer eerst welke verbinding mislukt is.
Jitsi Meet gebruikt WebRTC voor realtime audio en video. Een vergadering is afhankelijk van meer dan alleen het laden van de pagina: de browser moet de communicatie met de server onderhouden en een mediapad naar de Jitsi Videobridge tot stand brengen. Soms blijft een deelnemer zichtbaar in de ruimte terwijl de media even vastloopt; een volledige melding "U bent losgekoppeld" kan duiden op een bredere sessie- of signaalonderbreking. De exacte oorzaak kan niet alleen uit die melding worden afgeleid.
Noteer het tijdstip waarop de verbinding wegviel, of de browser een melding gaf om opnieuw verbinding te maken, of andere deelnemers er last van hadden en of de vergadering plaatsvond op meet.jit.si of op een privé Jitsi-domein. Vermijd het openbaar maken van een URL van een privévergadering, de naam van de vergaderruimte, een toegangstoken of onbewerkte logbestanden.
Controleert of een deelnemer een browser gebruikt.
1. Maak opnieuw verbinding en bevestig de vergaderlink.
Gebruik de optie 'Opnieuw verbinding maken' op het scherm als deze verschijnt. Als de vergadering niet herstelt, open dan de oorspronkelijke uitnodigingslink opnieuw in een nieuw tabblad en probeer opnieuw deel te nemen. Controleer of de kamernaam en het hostdomein overeenkomen met de uitnodiging; een typefout of een oude link kan leiden naar een andere kamer of host. Als iedereen de verbinding kwijt is, wacht dan even en vraag de organisator van de vergadering of de service nog beschikbaar is voordat u de pagina herhaaldelijk vernieuwt.
2. Test een ondersteunde, bijgewerkte browser.
Update de browser, sluit deze volledig af en probeer de vergadering opnieuw. Als de verbinding opnieuw wordt verbroken, probeer dan een andere browser die door Jitsi wordt ondersteund. De lijst met ondersteunde browsers van Jitsi bevat informatie over browserondersteuning en platformspecifieke details; raadpleeg deze pagina, aangezien de ondersteuningsdetails kunnen veranderen. Op iPhone en iPad gebruiken verschillende browsermerken dezelfde onderliggende browserengine, dus het proberen van een ander merk is mogelijk niet voldoende om een probleem met de browserengine te isoleren.
Probeer voor een eerlijke vergelijking een privévenster te gebruiken of schakel tijdelijk extensies uit die scripts filteren, trackers blokkeren of netwerkverzoeken wijzigen. Als dat het probleem oplost, schakel de extensies dan één voor één weer in om het conflict te achterhalen. Laat beveiligingsmaatregelen niet permanent uitgeschakeld als tijdelijke oplossing.
3. Vergelijk netwerken
Ga dichter bij het wifi-toegangspunt staan, pauzeer grote downloads of cloudbackups en test het een keer op een ander netwerk waarvoor je geautoriseerd bent. Een hotspot op je telefoon kan helpen om een probleem met het thuis- of werknetwerk te onderscheiden van een probleem met de browser of server. Als Jitsi wel werkt op het alternatieve netwerk, maar herhaaldelijk de verbinding verliest op het oorspronkelijke netwerk, geef dan de netwerkbeheerder het tijdstip van de test door en vraag of realtime WebRTC-verkeer wordt gefilterd.
Een VPN, proxy, captive portal of firewall kan de signalering of mediaoverdracht verstoren. Als uw organisatie een VPN vereist, omzeil dan het beleid niet; vraag de IT-afdeling of de Jitsi-host is toegestaan. Als u mag vergelijken terwijl de VPN is uitgeschakeld, doe dit dan slechts kort en schakel deze daarna weer in.
4. Controleer de staat van het apparaat en de app.
Houd op een telefoon de Jitsi-app of -browser tijdens een test op de voorgrond en schakel de energiebesparende beperkingen voor die test uit als uw apparaat dit toelaat. Mobiele besturingssystemen kunnen netwerkactiviteiten op de achtergrond uitschakelen. Controleer ook of de app en het besturingssysteem zijn bijgewerkt en herstart het apparaat als de verbinding blijft mislukken. Een probleem met de microfoon- of cameratoegang heeft meestal betrekking op de toegang tot het apparaat en wijst niet op een verbroken netwerkverbinding, dus behandel deze symptomen afzonderlijk.
Als audio/video uitvalt, maar de vergaderpagina open blijft
Schakel de camera tijdelijk uit en controleer of het geluid stabiel wordt. Dit kan het bandbreedtegebruik verminderen, maar het lost een defecte serververbinding niet op. Als audio en video op het ene netwerk tegelijkertijd uitvallen en elders wel werken, onderzoek dan firewall- of NAT-beperkingen. De zelfhostinghandleiding van Jitsi noemt TCP 443 voor algemene webtoegang, UDP 10000 voor normale audio-/videovergaderingen en TCP 5349 voor coturn-fallback wanneer UDP geblokkeerd is; optioneel STUN-gebruik kan ook UDP 3478 omvatten. Dit zijn vereisten voor serverimplementatie, geen poorten die een deelnemer op een persoonlijk apparaat moet openen. Raadpleeg de actuele Jitsi-richtlijnen voor firewalls en NAT .
Als de vergadering via een andere verbinding wel werkt, meld dit dan aan de netwerkbeheerder. Vraag hem of haar om de regels van de organisatie voor de Jitsi-hostnaam en WebRTC-verkeer te controleren in plaats van een algehele uitschakeling van de firewall aan te vragen.
Controleert of er een zelfgehoste Jitsi-beheerder aanwezig is.
Controleer de bereikbaarheid en het mediapad.
Controleer of de openbare DNS-naam naar de verwachte server verwijst, of het TLS-certificaat geldig is en of het vereiste verkeer de juiste host bereikt. Als de server zich achter een router of cloudfirewall bevindt, controleer dan zowel de hostfirewall als de upstream-beveiligingsgroep of port-forwardingregels. Een regel in de UFW is niet nuttig als de cloudfirewall hetzelfde verkeer nog steeds blokkeert.
sudo ufw status verbose
sudo ss -lntup
Deze commando's tonen lokale firewallregels en luisterende sockets; ze bewijzen niet dat externe deelnemers de service kunnen bereiken. Test vanuit een extern netwerk en controleer of de router of provider het relevante verkeer doorstuurt naar de Jitsi Videobridge. Jitsi merkt op dat implementaties achter NAT mogelijk een correcte toewijzing van openbare en lokale IP-adressen vereisen wanneer gesprekken van buitenaf niet werken.
Controleer de TLS-, reverse-proxy- en Docker-instellingen.
Bij een reverse-proxy-implementatie moet u controleren of HTTPS werkt en of de proxy WebSocket-signalen correct doorstuurt. De officiële Docker-handleiding beschrijft de /xmpp-websocketroute en de benodigde headers voor het Nginx-voorbeeld. Een proxy die de pagina wel serveert, maar de WebSocket-verbinding blokkeert, kan ertoe leiden dat gebruikers de vergadering niet kunnen voortzetten.
Controleer met Docker Compose of PUBLIC_URLhet publieke domein overeenkomt met wat bezoekers daadwerkelijk gebruiken en of de gepubliceerde hostpoorten overeenkomen met uw firewall- en proxy-instellingen. De Jitsi-handleiding waarschuwt dat het rechtstreeks aanbieden van een echte vergadering via HTTP in plaats van HTTPS WebRTC-problemen kan veroorzaken. Vermijd het kopiëren van configuratiefragmenten van een andere Jitsi-release zonder de versie en implementatiemethode te controleren die u gebruikt.
Koppel de serverlogboeken aan het tijdstip van het incident.
Vergelijk het tijdstip van de verbindingsonderbreking met de servicelogboeken. Bij installaties via Debian of Ubuntu documenteert Jitsi logbestanden zoals /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, en /var/log/prosody/prosody.log. Docker-implementaties slaan logboeken op via hun containers, dus controleer de relevante containeroutput en de configuratiemap van uw geïnstalleerde versie.
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
Zoek rond het tijdstempel van het incident naar herstarts van services, wijzigingen in bridge-registraties, WebSocket-fouten, certificaatfouten of herhaalde verbindingsfouten. Verwijder deelnemers-ID's, kamernamen, IP-adressen en tokens voordat u logbestanden deelt. De Debian/Ubuntu-handleiding voor zelfhosting raadt ook aan om een andere browser te proberen, de WebRTC-ondersteuning te controleren en de firewall-/NAT-regels te bekijken als basisstappen voor het debuggen.
Escalatiechecklist
- Noteer de Jitsi-host, het geschatte tijdstempel en de tijdzone, het apparaat, het besturingssysteem, de browser- of appversie en of het probleem één persoon of de hele vergadering betreft.
- Let op of een andere browser of netwerkverbinding het resultaat beïnvloedt.
- Voor zelfgehoste servers dient u recente upgrades van uw proxy, firewall, DNS, certificaat of Jitsi mee te leveren.
- Deel alleen de minimaal noodzakelijke diagnostische informatie; details over de privékamer en inloggegevens worden verwijderd.
- Als u meet.jit.si of een andere beheerde host gebruikt, stuur het rapport dan naar de organisator van de vergadering of de serviceondersteuning; deelnemers kunnen de firewall- of serverconfiguratie van die host niet wijzigen.
Hoe kan ik de oplossing bevestigen?
Neem deel aan een testvergadering vanaf het oorspronkelijke apparaat en netwerk, blijf lang genoeg verbonden om de periode te overbruggen waarin de storing zich gewoonlijk voordoet, en controleer of audio en video bruikbaar blijven. Herhaal dit met een andere deelnemer als het probleem iedereen trof. Controleer bij een zelfgehoste implementatie zowel de signalering via de browser als de media van buiten het netwerk van de server. Een succesvolle paginalading alleen is niet voldoende; de vergadering moet verbonden blijven en deelnemers moeten audio en video kunnen uitwisselen.