Résolution des problèmes de déconnexion lors de la réunion Jitsi : « Vous avez été déconnecté »

Une réunion Jitsi Meet peut afficher le message « Vous avez été déconnecté » en cas de coupure de la connexion de signalisation, d'impossibilité pour le trafic multimédia WebRTC d'atteindre le pont vidéo, ou d'interruption de la session par le réseau local ou le navigateur. Commencez par vérifier si le problème affecte un seul participant ou tous. Cette distinction vous permettra généralement de déterminer s'il faut dépanner un appareil et le réseau ou le serveur Jitsi.

Liste de contrôle de triage rapide

Ne modifiez pas plusieurs paramètres simultanément. Testez une modification, rejoignez la même réunion si possible et notez si le problème persiste.

Identifiez d'abord quelle connexion a échoué.

Jitsi Meet utilise WebRTC pour l'audio et la vidéo en temps réel. Le bon déroulement d'une réunion ne se limite pas au chargement de la page : le navigateur doit maintenir la communication avec le serveur et établir un flux vidéo vers Jitsi Videobridge. Il arrive qu'un participant reste visible dans la salle malgré une interruption du flux vidéo ; un message complet « Vous avez été déconnecté » peut indiquer une interruption plus générale de la session ou de la communication. Ce seul message ne permet pas de déterminer la cause exacte du problème.

Notez l'heure de la déconnexion, si le navigateur a affiché une invite de reconnexion, si d'autres participants ont été affectés et si la réunion était hébergée sur meet.jit.si ou sur un domaine Jitsi privé. Évitez de publier publiquement l'URL d'une réunion privée, le nom de la salle, le jeton d'accès ou les journaux non expurgés.

Vérification de la présence d'un participant utilisant un navigateur

1. Reconnectez-vous une fois et confirmez le lien de la réunion.

Utilisez l'option de reconnexion à l'écran si elle apparaît. Si la réunion ne se rétablit pas, ouvrez à nouveau le lien d'invitation initial dans un nouvel onglet et rejoignez-la. Vérifiez que le nom de la salle et le domaine de l'hôte correspondent bien à l'invitation ; une faute de frappe ou un lien obsolète peuvent vous rediriger vers une autre salle ou un autre hôte. Si tous les participants sont déconnectés, patientez quelques instants et demandez à l'organisateur si le service est toujours disponible avant d'actualiser la page.

2. Testez un navigateur compatible et à jour

Mettez à jour votre navigateur, fermez-le complètement et réessayez la réunion. Si la déconnexion persiste, essayez un autre navigateur compatible avec Jitsi. La liste des navigateurs compatibles avec Jitsi contient des informations sur la prise en charge et les plateformes ; consultez-la régulièrement car ces informations peuvent évoluer. Sur iPhone et iPad, différents navigateurs utilisent le même moteur de rendu, il est donc possible que le problème ne provienne pas de ce moteur.

Pour une comparaison objective, essayez une fenêtre de navigation privée ou désactivez temporairement les extensions qui filtrent les scripts, bloquent les traqueurs ou modifient les requêtes réseau. Si cela résout le problème, réactivez les extensions une par une pour identifier celle qui est en conflit. Ne désactivez pas les protections de sécurité de façon permanente.

3. Comparer les réseaux

Rapprochez-vous du point d'accès Wi-Fi, suspendez les téléchargements volumineux et les sauvegardes cloud, puis effectuez un test sur un autre réseau auquel vous êtes autorisé à accéder. Le partage de connexion de votre téléphone peut aider à distinguer un problème lié à votre réseau domestique ou professionnel d'un problème de navigateur ou de serveur. Si Jitsi fonctionne sur l'autre réseau mais se déconnecte régulièrement sur le réseau d'origine, indiquez à l'administrateur réseau l'heure du test et demandez-lui si le trafic WebRTC en temps réel est filtré.

Un VPN, un proxy, un portail captif ou un pare-feu peut interrompre la transmission des données. Si votre organisation exige un VPN, ne contournez pas sa politique ; demandez au service informatique si l’utilisation de Jitsi est autorisée. Si vous êtes autorisé à effectuer des tests avec le VPN désactivé, faites-le brièvement et réactivez-le ensuite.

4. Vérifiez l'état de l'appareil et de l'application

Sur un téléphone, gardez l'application Jitsi ou le navigateur au premier plan pendant le test et désactivez les restrictions d'économie d'énergie si votre appareil le permet. Les systèmes d'exploitation mobiles peuvent suspendre l'activité réseau en arrière-plan. Vérifiez également que l'application et le système d'exploitation sont à jour, puis redémarrez l'appareil si la connexion continue d'échouer. Un problème d'autorisation d'accès au microphone ou à la caméra affecte généralement l'accès à l'appareil plutôt que de provoquer une déconnexion réseau ; traitez donc ces symptômes séparément.

Lorsque l'audio/la vidéo ne fonctionne pas mais que la page de réunion reste ouverte

Désactivez temporairement la caméra et vérifiez si le son se stabilise. Cela peut réduire la consommation de bande passante, mais ne résout pas un problème de routage serveur. Si l'audio et la vidéo ne fonctionnent pas simultanément sur un réseau et fonctionnent ailleurs, examinez les restrictions du pare-feu ou du NAT. Le guide d'auto-hébergement de Jitsi indique le port TCP 443 pour l'accès web général, le port UDP 10000 pour les réunions audio/vidéo normales et le port TCP 5349 comme port de secours pour coturn lorsque le protocole UDP est bloqué ; l'utilisation optionnelle de STUN peut également impliquer le port UDP 3478. Il s'agit d'exigences de déploiement côté serveur, et non de ports que les participants doivent ouvrir sur leur appareil personnel. Consultez les recommandations actuelles de Jitsi concernant le pare-feu et le NAT .

Si la réunion fonctionne avec une autre connexion, signalez-le à l'administrateur réseau. Demandez-lui de vérifier les règles de l'organisation concernant le nom d'hôte Jitsi et le trafic WebRTC plutôt que de demander une désactivation générale du pare-feu.

Vérifications concernant un administrateur Jitsi auto-hébergé

Vérifier l'accessibilité et le parcours des médias

Vérifiez que le nom DNS public pointe bien vers le serveur attendu, que le certificat TLS est valide et que le trafic requis atteint l'hôte approprié. Si le serveur se trouve derrière un routeur ou un pare-feu cloud, examinez à la fois le pare-feu hôte et les règles de groupe de sécurité ou de redirection de ports en amont. Une règle dans UFW est inutile si le pare-feu cloud bloque toujours le même trafic.

sudo ufw status verbose
sudo ss -lntup

Ces commandes affichent les règles du pare-feu local et les sockets d'écoute ; elles ne prouvent pas que les participants externes peuvent accéder au service. Effectuez un test depuis un réseau externe et vérifiez que le routeur ou le fournisseur d'accès achemine bien le trafic vers Jitsi Videobridge. Jitsi indique que les déploiements derrière un NAT peuvent nécessiter une configuration correcte des adresses IP publiques et locales lorsque les appels ne fonctionnent pas depuis l'extérieur.

Vérifiez les paramètres TLS, de proxy inverse et Docker

Pour le déploiement d'un proxy inverse, vérifiez que le protocole HTTPS fonctionne et que le proxy transmet correctement la signalisation WebSocket. Le guide Docker officiel documente la /xmpp-websocketroute et les en-têtes nécessaires dans son exemple Nginx. Un proxy qui sert la page mais bloque la connexion WebSocket peut empêcher les utilisateurs de poursuivre la session de réunion.

Avec Docker Compose, vérifiez que PUBLIC_URLle domaine public utilisé par les visiteurs correspond bien à l'URL et que les ports hôtes publiés sont compatibles avec votre pare-feu et votre proxy. Le guide Jitsi indique que diffuser une réunion directement via HTTP au lieu de HTTPS peut entraîner des problèmes WebRTC. Évitez de copier des extraits de configuration d'une autre version de Jitsi sans vérifier la version et la méthode de déploiement que vous utilisez.

Corréler les journaux du serveur avec l'heure de l'incident

Comparez l'heure de la déconnexion avec les journaux de service. Sur les installations de paquets Debian ou Ubuntu, Jitsi documente les fichiers journaux, notamment `<log_json>` /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log`<log_json>` et /var/log/prosody/prosody.log`<log_json>`. Les déploiements Docker stockent les journaux via leurs conteneurs ; examinez donc la sortie du conteneur concerné et le répertoire de configuration de votre version installée.

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

Recherchez, aux alentours de l'horodatage de l'incident, les redémarrages de service, les modifications d'enregistrement de pont, les échecs WebSocket, les erreurs de certificat ou les délais d'expiration de connexion répétés. Avant de partager les journaux, masquez les identifiants des participants, les noms de salle, les adresses IP et les jetons. Le guide d'auto-hébergement Debian/Ubuntu recommande également d'essayer un autre navigateur, de vérifier la compatibilité WebRTC et de revoir les règles de pare-feu/NAT comme étapes de débogage de base.

Liste de contrôle d'escalade

• Notez l'hôte Jitsi, l'horodatage approximatif et le fuseau horaire, l'appareil, le système d'exploitation, la version du navigateur ou de l'application, et si le problème affecte une seule personne ou toute la réunion.
• Notez si un navigateur ou un réseau différent modifie le résultat.
• Pour les serveurs auto-hébergés, veuillez inclure les mises à jour récentes du proxy, du pare-feu, du DNS, du certificat ou de Jitsi.
• Ne partagez que les informations diagnostiques minimales nécessaires, en supprimant les détails et les identifiants de la chambre privée.
• Si vous utilisez meet.jit.si ou un autre hébergeur géré, veuillez envoyer le rapport à l'organisateur de la réunion ou au service d'assistance ; les participants ne peuvent pas modifier le pare-feu ou la configuration du serveur de cet hébergeur.

Comment confirmer la correction

Rejoignez une réunion test depuis l'appareil et le réseau d'origine, restez connecté suffisamment longtemps pour couvrir la période durant laquelle le problème survient habituellement, et vérifiez que l'audio et la vidéo restent fonctionnels. Répétez l'opération avec un autre participant si le problème affecte tous les participants. Pour un déploiement auto-hébergé, vérifiez la signalisation du navigateur et les flux multimédias provenant de l'extérieur du réseau du serveur. Le simple fait que la page se charge correctement ne suffit pas ; la réunion doit rester connectée et les participants doivent pouvoir échanger de l'audio et de la vidéo.