Lorsque l'audio ne se connecte pas aux salles de réunion BigBlueButton, la première question utile n'est pas « quel service dois-je redémarrer ? » mais « le problème audio se produit-il uniquement après l'entrée dans une salle de réunion, ou également pendant la réunion principale ? » Cette distinction permet de différencier rapidement un problème de transition entre salles d'un problème plus général lié au navigateur, au réseau ou au serveur multimédia.
Ce guide concerne BigBlueButton 3.0, qui reste la version stable documentée à ce jour (octobre 2026). BigBlueButton 4.0 est encore documenté, car en développement. BigBlueButton 3.0 peut utiliser différents ponts audio, notamment bbb-webrtc-sfuvia livekitl' freeswitchAPI de réunion. Il est donc important de ne pas supposer que chaque déploiement utilise le même chemin média. La documentation officielle de l'API BigBlueButton détaille ces options de pont, tandis que le guide de dépannage de BigBlueButton reste le meilleur point de départ pour les vérifications côté serveur.
Un résultat positif ne se limite pas à voir l'icône du microphone devenir verte. Après la correction, un participant devrait pouvoir rejoindre une salle de réunion, activer l'audio en quelques secondes, entendre un autre participant, parler et être entendu, activer et désactiver son micro normalement, puis retourner à la salle principale sans être bloqué dans une boucle de reconnexion. Si un seul navigateur ou réseau rencontre toujours ce problème alors que tous les autres y parviennent, cessez de modifier le serveur et concentrez-vous sur l'environnement client concerné.
| Observation | Zone la plus probable | Prochaine étape |
|---|---|---|
| Le système audio de la salle principale et de la salle de réunion ne fonctionne pas. | Autorisation du navigateur, appareil, pare-feu, TURN ou pont multimédia | Commencez par les étapes 1 à 4 |
| La salle principale fonctionne, la salle de réunion reste bloquée sur « connexion ». | Transition de salle, état client obsolète, problème spécifique au pont | Commencez par les étapes 1, 2 et 5. |
| Seuls les utilisateurs d'un même réseau de bureau, d'école ou VPN rencontrent des problèmes. | Filtrage réseau ou itinéraire ICE/TURN | Prioriser l'étape 4 |
| De nombreux utilisateurs échouent simultanément. | Configuration du serveur ou du réseau | Prioriser les étapes 3 à 5 |
Avant de modifier la configuration, reproduisez le problème avec un modérateur et un participant. Vérifiez que le participant peut se connecter à l'audio dans la salle principale, puis déplacez-le dans une salle de sous-groupe et notez précisément ce qui se passe. Un message « Connexion audio… » qui ne se termine jamais est différent d'un refus d'autorisation du navigateur, d'un microphone manquant ou d'une connexion audio établie mais sans son.
Si la salle principale fonctionne mais pas la salle de sous-groupe, essayez de quitter cette dernière, de revenir à la salle principale, puis de rejoindre à nouveau la salle de sous-groupe. Un état client obsolète ponctuel peut disparaître après une nouvelle connexion. Si le problème persiste, poursuivez les vérifications ci-dessous plutôt que d'actualiser la page à répétition.
Test de réussite : le participant rejoint la session audio une fois, la quitte, la rejoint à nouveau et retrouve le son. Si ce test est fiable, le problème était probablement passager. Si la même transition échoue systématiquement, passez à l’étape suivante.
L'audio de BigBlueButton utilise WebRTC via navigateur. Par conséquent, un refus d'accès au microphone peut sembler être un problème spécifique à l'application si l'utilisateur ne le remarque qu'après y être entré. Ouvrez les autorisations du site BigBlueButton dans votre navigateur et assurez-vous que l'accès au microphone est autorisé. Vérifiez ensuite que le microphone souhaité est bien sélectionné et qu'aucune autre application n'utilise le périphérique de manière exclusive.
Effectuez le test avec une version récente de Firefox ou d'un navigateur basé sur Chromium. Si le participant parvient à reproduire le même problème sur deux navigateurs récents, il est moins probable qu'il s'agisse d'un problème lié au profil du navigateur. Si un navigateur fonctionne et l'autre échoue sur la même machine et le même réseau, réinitialisez les autorisations ou effectuez un test avec un profil de navigateur vierge avant de modifier la configuration de BigBlueButton.
Test de bon fonctionnement : le témoin d’activité du microphone est actif, l’audio est disponible dans la salle principale et le même navigateur permet de rejoindre les discussions de groupe. Si le problème persiste dans la salle principale, les discussions de groupe ne sont pas en cause.
Sur le serveur, exécutez la commande suivante sudo bbb-conf --check. La documentation de BigBlueButton recommande cette opération comme premier diagnostic côté serveur, car elle vérifie le bon démarrage des composants principaux et met en évidence les problèmes de configuration courants. Consultez la liste des « Problèmes potentiels » au lieu de redémarrer immédiatement chaque service.
Exécutez sudo bbb-conf --statuset examinez également les services systemd pertinents pour votre pont audio. Les déploiements BigBlueButton 3.0 utilisent généralement FreeSWITCH bbb-webrtc-sfupar défaut pour l'audio, tandis que LiveKit peut être activé pour chaque réunion ou pour l'ensemble du serveur. Si votre intégration réussit audioBridge=livekit, concentrez-vous sur le dépannage de LiveKit plutôt que de supposer que le chemin FreeSWITCH hérité gère l'audio du navigateur.
La documentation officielle relative aux fichiers de configuration recommande de placer les paramètres de remplacement locaux sous un emplacement /etc/bigbluebuttonapproprié afin que les mises à jour des paquets ne les écrasent pas.
Test concluant : bbb-conf --check aucune erreur inexpliquée n’est détectée, les services de pont audio actifs sont en cours d’exécution et les nouvelles réunions de test se comportent de manière cohérente. Si l’état du service est bon mais qu’un réseau présente toujours une défaillance, examinez les paramètres ICE, NAT et TURN.
WebRTC doit établir un chemin média fonctionnel entre le navigateur et l'infrastructure multimédia BigBlueButton. Si la signalisation réussit mais qu'aucun chemin réseau n'est disponible pour le média, les utilisateurs peuvent rencontrer des échecs de négociation ICE ou rester bloqués lors de la lecture audio. La documentation du pare-feu de BigBlueButton mentionne spécifiquement les annonces d'adresse IP externe incorrectes et le blocage du protocole UDP comme causes fréquentes.
Sur Firefox, about:webrtccette fonctionnalité est utile car elle affiche les candidats ICE et l'état de la connexion. Si le serveur annonce une adresse interne alors qu'une adresse externe est attendue, vérifiez la configuration NAT et l'adresse IP annoncée. Le guide de configuration du pare-feu BigBlueButton explique comment mediasoup doit annoncer l'adresse publique lorsque le serveur se trouve derrière un NAT.
Si les pannes se concentrent sur des réseaux d'entreprise, scolaires, hôteliers ou VPN restrictifs, configurez un serveur TURN. La documentation d'installation de BigBlueButton recommande l'utilisation de TURN pour les utilisateurs protégés par des pare-feu restrictifs. Pour valider le problème, testez le même utilisateur sur un réseau différent, comme un point d'accès Wi-Fi mobile. Si le point d'accès fonctionne et que le réseau géré échoue, cela indique clairement que le chemin réseau, et non la logique des salles de réunion virtuelles, est le facteur limitant.
N'ouvrez pas aveuglément de larges plages de ports copiées d'anciens messages de forum. Utilisez les exigences de port et de pontage spécifiques à votre version de BigBlueButton et à votre topologie de déploiement. Les anciens conseils relatifs à FreeSWITCH ou SIP.js peuvent ne pas s'appliquer à une installation 3.0 actuelle.
Vérification de réussite : ICE est connecté, le serveur public ou relais attendu apparaît et l’utilisateur concerné peut rejoindre la session audio du réseau précédemment défaillant. Si l’utilisateur ne parvient toujours pas à se connecter alors que d’autres utilisateurs du même réseau y parviennent, retournez aux vérifications du périphérique/navigateur.
Si l'audio de la salle principale fonctionne mais que l'audio des réunions en petits groupes échoue systématiquement pour de nombreux utilisateurs, vérifiez quel pont audio est utilisé par la réunion. BigBlueButton 3.0 expose le audioBridgeparamètre `create` avec les valeurs valides suivantes : `<nom_du_serveur>` bbb-webrtc-sfu, `<nom_du_serveur>` livekitet ` freeswitch<nom_du_pont>`. Une intégration peut remplacer la configuration par défaut du serveur pour chaque réunion ; par conséquent, la configuration que vous examinez peut ne pas correspondre au pont utilisé par la session défaillante.
Créez une nouvelle réunion de test sans aucune personnalisation, puis répétez la séquence salle principale → salle de sous-groupe → salle principale. Si la réunion sans personnalisation fonctionne, mais que les réunions créées par votre LMS ou votre application personnalisée échouent, examinez les paramètres API envoyés par cette intégration. Si les deux échouent, le problème provient probablement de la configuration du serveur multimédia ou d'un défaut spécifique à une version.
Après avoir modifié la configuration, redémarrez BigBlueButton uniquement lorsque cela est nécessaire sudo bbb-conf --restart, puis relancez- sudo bbb-conf --checkle. Évitez d'accumuler plusieurs modifications avant de les tester ; une modification à la fois permet d'identifier celle qui a réellement résolu le problème.
Test de réussite : deux participants peuvent discuter dans une salle de sous-groupe, retourner dans la salle principale et rejoindre une autre salle de sous-groupe sans interruption de connexion. Répétez cette opération depuis au moins un réseau externe avant de considérer l’incident comme résolu.
Si le problème persiste après vérification des autorisations du navigateur, de l'état du serveur, d'ICE/TURN et de la sélection du pont audio, rassemblez des preuves au lieu de continuer à faire des suppositions. Notez la version de BigBlueButton, les versions de votre navigateur et de votre système d'exploitation, si le problème se reproduit sur la démo publique de BigBlueButton, la sortie de la commande `bigblue-network` , les paramètres du pont audio de la réunion et tous les diagnostics WebRTC pertinents du navigateur. Le guide d'aidesudo bbb-conf --check de BigBlueButton demande explicitement ce type d'informations réseau et d'environnement lors du dépannage des problèmes audio ou vidéo.
En octobre 2026, la documentation de BigBlueButton 3.0 restait stable et des versions 3.0 étaient régulièrement publiées sur GitHub, tandis que la documentation de la version 4.0 était en cours de développement. Il est important de noter que BigBlueButton 4.0 utilise LiveKit comme framework multimédia par défaut ; par conséquent, les conseils spécifiques à la version 4.0 ne doivent pas être appliqués automatiquement à un serveur 3.0. Veuillez consulter la page officielle des versions de BigBlueButton avant de suivre des instructions spécifiques à cette version.
bbb-conf --checkne présente aucune erreur inexpliquée du service multimédia.Si les six vérifications sont réussies de manière répétée, la réparation produit le résultat qui compte : un son stable lors des changements de pièce, et non pas simplement une icône de microphone verte temporaire.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
