Comment résoudre l'erreur « Échec de la connexion au pont » de Jitsi Meet ?

Vous ouvrez une salle Jitsi Meet, la page se charge normalement et la signalisation semble même fonctionner, mais la conférence n'établit jamais de flux vidéo. Jitsi affiche alors le message « Échec de la connexion au pont » ou se déconnecte de manière répétée lors de la tentative de connexion. Sur un déploiement auto-hébergé, ce message indique généralement un problème entre le navigateur et Jitsi Videobridge (JVB) , ou entre Jicofo et le pont lui-même.

La méthode la plus rapide pour résoudre ce problème est de procéder du serveur vers le client : vérifiez que JVB est en cours d'exécution et enregistré, que son port média est accessible, contrôlez la gestion des adresses NAT et publiques, et seulement ensuite, examinez les restrictions réseau côté client. Le guide officiel d'auto-hébergement de Jitsi indique le port UDP 10000 comme chemin média par défaut, tandis que Jicofo est responsable de la sélection d'un pont vidéo pour chaque conférence.

Que signifie généralement cette erreur ?

Jitsi Meet comprend plusieurs composants. L'interface web et Prosody gèrent la signalisation, Jicofo coordonne les conférences et Jitsi Videobridge transmet les flux audio et vidéo. Si le navigateur peut accéder à la page web mais ne parvient pas à établir la connexion multimédia avec JVB, ou si aucun pont Jicofo n'est disponible, la réunion peut échouer lors de l'établissement du pont.

Pour les installations Debian/Ubuntu actuelles, Jitsi documente les exigences réseau suivantes : TCP 80 pour la validation et le renouvellement des certificats, TCP 443 pour l’accès web, UDP 10000 pour l’audio/vidéo, UDP 3478 pour les requêtes STUN optionnelles et TCP 5349 pour la diffusion multimédia de secours (via coturn) lorsque UDP est bloqué. Consultez le guide d’auto-hébergement officiel de Jitsi pour Debian/Ubuntu . La configuration de référence actuelle de JVB indique également le port UDP 10000 comme port ICE/UDP par défaut dans la configuration de référence de Jitsi Videobridge .

1. Vérifiez que Jitsi Videobridge est en cours d'exécution.

Commencez par le composant mentionné dans l'erreur. Sur une installation standard basée sur des paquets, exécutez :

sudo systemctl status jitsi-videobridge2

Vous souhaitez voir active (running). Si l'unité est défaillante, son redémarrage peut rétablir temporairement le service, mais ne vous arrêtez pas là : consultez les journaux pour savoir pourquoi elle s'est arrêtée.

sudo systemctl restart jitsi-videobridge2
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager

Recherchez les échecs de liaison, les erreurs d'authentification, les échecs de connexion XMPP, les problèmes ICE récurrents ou les messages indiquant l'absence d'adresse valide. Ne présumez pas qu'un statut systemd actif garantit l'utilisation de JVB : un processus Java peut être en cours d'exécution alors que la connexion réseau ou l'enregistrement XMPP est interrompu.

2. Vérifiez que le port UDP 10000 est ouvert et autorisé par le pare-feu de l'hôte.

Le port média JVB par défaut de Jitsi est UDP 10000. Vérifiez d'abord que le serveur est à l'écoute :

sudo ss -lunp | grep ':10000'

Si aucun service n'est à l'écoute, consultez /etc/jitsi/videobridge/jvb.confles journaux JVB avant de modifier les règles du pare-feu. Si le port est à l'écoute, vérifiez le pare-feu de l'hôte.

sudo ufw status verbose

Sur un serveur Ubuntu utilisant UFW, le guide de Jitsi utilise :

sudo ufw allow 10000/udp
sudo ufw status verbose

Si vous utilisez firewalld, nftables, iptables ou un pare-feu cloud au lieu d'UFW, ajoutez-y la règle UDP entrante équivalente. Une erreur fréquente consiste à autoriser le port UDP 10000 sous Ubuntu tout en le laissant bloqué par un groupe de sécurité AWS, un groupe de sécurité réseau Azure, le pare-feu VPC de Google Cloud, le pare-feu de votre fournisseur VPS ou un pare-feu matériel en amont.

3. Vérifiez la redirection de ports du routeur lorsque le serveur se trouve derrière un NAT.

Si Jitsi s'exécute sur une adresse privée 192.168.x.x, l'ouverture d'UFW ne suffit pas. Votre routeur de périphérie doit rediriger le port média UDP externe vers la machine exécutant JVB. Dans une installation simple à serveur unique, cela implique généralement de rediriger le port UDP 10000 vers le port UDP 10000 du serveur Jitsi.

Si vous avez modifié le port de JVB, utilisez la valeur configurée plutôt que d'ouvrir le port 10000 sans précaution. Vérifiez également qu'aucun autre ordinateur ou conteneur n'utilise ce port. L'interface de redirection de ports varie selon les routeurs ; considérez donc l'illustration comme un exemple de configuration et non comme une représentation exacte de l'interface utilisateur de votre appareil.

4. Corriger la correspondance entre adresses publiques et privées

La NAT peut entraîner une défaillance plus subtile : JVB peut annoncer une adresse IP privée aux clients Internet même si le routeur redirige le port correct. La documentation de démarrage rapide de Jitsi présente une configuration statique /etc/jitsi/videobridge/jvb.confpour les systèmes nécessitant une traduction explicite des adresses locales vers publiques.

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "<Local.IP.Address>"
          public-address = "<Public.IP.Address>"
        }
      ]
    }
  }
}

Remplacez les espaces réservés par l'adresse privée réelle de l'hôte JVB et l'adresse publique accessible aux clients distants. Redémarrez ensuite JVB :

sudo systemctl restart jitsi-videobridge2

Utilisez cette configuration uniquement si elle correspond à votre topologie. Les serveurs avec adresse IP publique directe, les déploiements Docker, plusieurs cartes réseau, IPv6 ou une configuration NAT plus complexe peuvent nécessiter des paramètres différents. L'exemple de référence se trouve dans la section NAT du guide de démarrage rapide de Jitsi .

5. Pour Docker, vérifiez que le port UDP JVB est bien publié.

Dans Docker, une règle de pare-feu correcte sur l'hôte est inutile si le conteneur JVB ne publie pas son port média. La documentation Docker de Jitsi indique JVB_PORTune valeur par défaut de 10 000 et recommande aux administrateurs d'ouvrir le port UDP 10 000 sur l'hôte. Vérifiez votre déploiement en cours :

docker compose ps
docker compose logs --tail=200 jvb

Vérifiez ensuite vos fichiers Compose et d'environnement et assurez-vous que le service JVB expose bien le port UDP prévu. Si vous avez modifié la configuration JVB_PORT, le mappage hôte, la règle de pare-feu et toute redirection NAT doivent être cohérents. Consultez le guide officiel d'auto-hébergement Docker de Jitsi plutôt que de copier un extrait de code Compose provenant d'un tutoriel tiers.

6. Vérifiez que Jicofo peut voir un pont vidéo.

Un port UDP parfaitement accessible ne suffit pas si JVB ne s'enregistre jamais auprès du plan de contrôle XMPP. Jicofo sélectionne un pont vidéo pour une conférence, et le guide de déploiement évolutif de Jitsi recommande de consulter les journaux de Prosody et de Jicofo après le redémarrage des services afin de confirmer que les ponts sont bien connectés et pris en compte.

sudo journalctl -u jicofo -n 200 --no-pager
sudo journalctl -u prosody -n 200 --no-pager
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager

Si vous avez personnalisé des domaines XMPP ou si vous exécutez plusieurs nœuds, vérifiez que Jicofo et JVB utilisent le même serveur MUC de pont. La documentation officielle de Jitsi Videobridge indique que le serveur MUC de Jicofo jicofo.bridge.brewery-jiddoit pointer vers le même serveur MUC que celui utilisé par les instances Videobridge.

Ceci est particulièrement important après des changements de nom d'hôte, des migrations, des déploiements sur plusieurs hôtes ou des modifications manuelles de la configuration. Pour les installations de paquets standard créées avec l'installateur officiel, évitez de modifier la configuration XMPP, sauf si vos journaux indiquent un problème d'enregistrement ou d'authentification.

7. Éliminez la possibilité d'un réseau client restrictif, d'un VPN ou d'un proxy.

Si le serveur fonctionne pour certains utilisateurs mais pas pour d'autres, effectuez un test depuis un autre réseau avant de modifier sa configuration. Les réseaux d'entreprise, les réseaux Wi-Fi invités, les VPN et les serveurs proxy stricts peuvent bloquer le protocole UDP. Déconnecter temporairement un VPN ou un proxy constitue un test de diagnostic utile ; reconnectez-le ensuite si votre organisation l'exige.

Le guide Debian/Ubuntu de Jitsi indique que le port TCP 5349 est utilisé comme solution de repli pour l'audio/vidéo lorsque le protocole UDP est bloqué. Si vous souhaitez garantir une connexion fiable aux utilisateurs de réseaux restrictifs, vérifiez votre configuration TURN/coturn plutôt que de supposer que l'ouverture du port TCP 443 pour le site web assure automatiquement une solution de repli pour les médias.

8. Réessayez avec une session de navigateur vierge uniquement après que les vérifications du serveur aient été réussies.

Une session de navigation obsolète est moins probable qu'une route JVB défectueuse lorsque tous les participants rencontrent la même erreur de pont, mais elle est facile à résoudre. Rechargez la salle, essayez une fenêtre de navigation privée ou effacez les données de site de votre domaine Jitsi et reconnectez-vous si l'authentification est activée.

Si l'erreur se reproduit sur différents navigateurs et réseaux, revenez aux vérifications côté serveur plutôt que d'effacer à plusieurs reprises les données du navigateur.

Comment vérifier que la correction a bien fonctionné

Ne considérez pas le problème comme résolu simplement parce que le message d'erreur a disparu. Testez le chemin d'accès complet au média.

• Créez une nouvelle salle et rejoignez-la depuis deux appareils.
• Si possible, connectez les appareils à des réseaux différents, par exemple l'un à la connexion internet fixe et l'autre aux données mobiles.
• Vérifiez que l'audio et la vidéo circulent dans les deux sens pendant plusieurs minutes.
• Surveillez les journaux JVB et Jicofo pendant la connexion et vérifiez que la conférence est attribuée à un pont sans défaillances ICE ou de santé de pont répétées.
• Relancez sudo ss -lunp | grep ':10000'la vérification de l'état de votre pare-feu après tout redémarrage ou modification de celui-ci.

Pour les installations multi-ponts, testez plusieurs conférences. Le guide d'installation évolutif de Jitsi explique que Jicofo sélectionne un pont vidéo pour les nouvelles conférences ; par conséquent, un pont défaillant peut entraîner des pannes intermittentes même si un autre pont fonctionne correctement.

Tableau de diagnostic rapide

En résumé

Pour un serveur Jitsi Meet auto-hébergé, l'erreur « Échec de la connexion au pont » est généralement considérée comme un problème de chemin média ou d'enregistrement du pont. Vérifiez que Jitsi Videobridge fonctionne correctement, que le port UDP 10000 est ouvert et accessible à travers tous les pare-feu et couches NAT, que JVB diffuse une adresse IP publique valide en cas de NAT, et que Jicofo détecte le pont. Ce n'est qu'après ces vérifications que vous pourrez vous pencher sur le cache du navigateur ou les paramètres des clients.

La solution exacte dépend de votre topologie ; évitez donc d’appliquer d’anciennes clés de configuration Jitsi simplement parce qu’elles apparaissent dans d’anciens messages de forum. Les commandes et paramètres ci-dessus sont conformes au manuel Jitsi officiel et aux sources de configuration Jitsi Videobridge les plus récentes (vérifiées en octobre 2026).