Corrigir problema de áudio que não conecta nas salas de discussão do BigBlueButton: um caminho confiável para solucionar problemas.

Quando o áudio da sala de discussão do BigBlueButton não conecta, a primeira pergunta mais útil não é "qual serviço devo reiniciar?", mas sim "o áudio falha apenas depois de entrar em uma sala de discussão ou também falha na reunião principal?". Essa distinção separa rapidamente um problema de transição de sala de um problema mais amplo de navegador, rede ou servidor de mídia.

Este guia foi escrito para o BigBlueButton 3.0, que permanece como a versão estável da documentação até outubro de 2026; o BigBlueButton 4.0 ainda está documentado como em desenvolvimento. O BigBlueButton 3.0 pode usar diferentes pontes de áudio, incluindo `audiobridge`, `audiobridge` bbb-webrtc-sfue livekit`audiobridge` freeswitchatravés da API de reuniões, portanto, evite presumir que todas as implementações tenham o mesmo caminho de mídia. A documentação oficial da API do BigBlueButton sobre essas opções de ponte, enquanto o guia de solução de problemas do BigBlueButton continua sendo o melhor ponto de partida para verificações no servidor.

Como seria uma boa solução?

Um resultado positivo vai além de simplesmente ver o ícone do microfone ficar verde. Após a correção, um participante deve conseguir entrar em uma sala de discussão, conectar-se ao áudio em poucos segundos, ouvir outro participante, falar e ser ouvido, ativar e desativar o microfone normalmente e retornar à sala principal sem ficar preso em um loop de reconexão. Se apenas um navegador ou uma rede ainda apresentar problemas depois que todos os outros conseguirem, pare de alterar o servidor e concentre-se no ambiente do cliente em questão.

Passo 1: Reproduza o problema de forma limpa.

Antes de alterar a configuração, reproduza o problema com um moderador e um participante. Confirme se o participante consegue entrar no áudio da sala principal e, em seguida, mova-o para uma sala separada e observe exatamente o que acontece. A mensagem "Conectando áudio..." que nunca é concluída é diferente de uma negação de permissão do navegador, da ausência de um microfone ou de um áudio que se conecta, mas não transmite som.

Se a sala principal funcionar, mas a sala de discussão não, tente sair da sala de discussão, voltar para a sala principal e entrar na sala de discussão novamente. Um estado de cliente desatualizado pontual pode ser resolvido após uma nova conexão. Se o problema persistir, continue com as verificações abaixo em vez de atualizar a página repetidamente.

Verificação de sucesso: o participante entra no áudio da sala de discussão uma vez, sai, entra novamente e o áudio volta a funcionar. Se isso ocorrer de forma consistente, o problema provavelmente foi temporário. Se a mesma transição falhar sempre, prossiga.

Passo 2: Verifique as permissões do microfone no navegador e no dispositivo selecionado.

O áudio do BigBlueButton é baseado em WebRTC no navegador, portanto, uma permissão de microfone negada pode parecer um problema específico da sala menor se o usuário só perceber depois de entrar nela. Abra as permissões do site no navegador para o hostname do BigBlueButton e verifique se o acesso ao microfone está permitido. Em seguida, confirme se o microfone desejado está selecionado e se outro aplicativo não está monopolizando o dispositivo.

Faça o teste com uma versão atual do Firefox ou de um navegador baseado no Chromium. Se o participante conseguir reproduzir a mesma falha em dois navegadores atuais, isso torna menos provável que seja um problema puramente relacionado ao perfil do navegador. Se um navegador funcionar e o outro apresentar falhas na mesma máquina e rede, redefina as permissões ou teste com um perfil de navegador limpo antes de alterar a configuração do BigBlueButton.

Verificação de sucesso: o indicador de atividade do microfone responde, o áudio entra na sala principal e o mesmo navegador consegue entrar no áudio da sala de discussão. Se a sala principal ainda apresentar problemas, a causa raiz do problema não está na sala de discussão.

Passo 3: Verifique o BigBlueButton antes de reiniciar qualquer coisa.

No servidor, execute o comando sudo bbb-conf --check. A própria documentação do BigBlueButton recomenda este como o primeiro diagnóstico do lado do servidor, pois verifica se os componentes principais foram iniciados corretamente e identifica problemas comuns de configuração. Analise tudo o que estiver listado em "Problemas potenciais" em vez de reiniciar todos os serviços imediatamente.

Execute e inspecione também sudo bbb-conf --statusos serviços systemd relevantes para sua ponte de áudio. As implementações do BigBlueButton 3.0 geralmente usam o FreeSWITCH bbb-webrtc-sfupara áudio por padrão, enquanto o LiveKit pode ser habilitado por reunião ou em todo o servidor. Se sua integração passar nos testes audioBridge=livekit, solucione problemas do LiveKit em vez de presumir que o caminho legado do FreeSWITCH está transportando o áudio do navegador.

A documentação oficial dos arquivos de configuração recomenda colocar as alterações locais em um diretório específico /etc/bigbluebuttonpara que as atualizações de pacotes não as sobrescrevam.

Verificação de sucesso: bbb-conf --check não apresenta erros inexplicáveis, os serviços de ponte de áudio ativos estão em execução e as novas reuniões de teste se comportam de forma consistente. Se a integridade do serviço estiver boa, mas uma rede ainda apresentar falhas, concentre-se no ICE, NAT e TURN.

Etapa 4: Diagnosticar problemas de ICE, NAT, firewall e TURN

O WebRTC precisa estabelecer um caminho de mídia utilizável entre o navegador e a infraestrutura de mídia do BigBlueButton. Se a sinalização for bem-sucedida, mas a mídia não encontrar um caminho de rede viável, os usuários podem sofrer falhas na negociação ICE ou ficar presos ao tentar conectar o áudio. A documentação do firewall do BigBlueButton aponta especificamente para anúncios IP externos incorretos e bloqueio de UDP como causas comuns.

No Firefox, about:webrtcé útil porque mostra os candidatos ICE e o estado da conexão. Se você vir o servidor anunciando um endereço interno onde um endereço externo é esperado, verifique a configuração de NAT e de IP anunciado. O guia de configuração de firewall do BigBlueButton explica como o mediasoup deve anunciar o endereço público quando o servidor estiver atrás de um NAT.

Se as falhas se concentrarem em redes corporativas, escolares, de hotéis ou VPNs restritivas, configure um servidor TURN. A documentação de instalação do BigBlueButton recomenda o uso do TURN para usuários atrás de firewalls restritivos. Uma validação útil é testar o mesmo usuário em uma rede diferente, como um ponto de acesso Wi-Fi de celular. Se o ponto de acesso funcionar e a rede gerenciada falhar, isso é uma forte evidência de que o caminho da rede — e não a lógica de salas de compartilhamento — é o fator limitante.

Não abra indiscriminadamente amplos intervalos de portas copiados de postagens antigas de fóruns. Utilize os requisitos de porta e bridge específicos para a sua versão do BigBlueButton e a topologia de implantação. Recomendações antigas, específicas para FreeSWITCH ou SIP.js, podem não se aplicar a uma instalação atual da versão 3.0.

Verificação de sucesso: o ICE atinge um estado conectado, o candidato público ou de retransmissão esperado aparece e o mesmo usuário afetado consegue entrar no áudio da rede que estava apresentando falhas anteriormente. Se o usuário ainda não conseguir se conectar enquanto outros usuários na mesma rede conseguirem, retorne às verificações de dispositivo/navegador.

Etapa 5: Compare a ponte de áudio configurada e teste novamente as transições de sala.

Se o áudio da sala principal funcionar, mas o áudio das salas de reunião falhar consistentemente para muitos usuários, verifique qual ponte de áudio a reunião está usando. O BigBlueButton 3.0 expõe o audioBridgeparâmetro `create` com valores válidos, incluindo bbb-webrtc-sfu`<nome_da_ponte>`, livekit`<nome_da_ponte>` e ` freeswitch<nome_da_ponte>`. Uma integração pode substituir o padrão do servidor por reunião, portanto, a configuração que você inspecionar pode não corresponder à ponte usada pela sessão com falha.

Crie uma nova reunião de teste sem configurações personalizadas por reunião e repita a mesma sequência: sala principal → sala de discussão → sala principal. Se a reunião sem essas configurações funcionar, mas as reuniões criadas pelo seu LMS ou aplicativo personalizado falharem, verifique os parâmetros da API enviados por essa integração. Se ambas falharem, o problema provavelmente está na configuração de mídia do servidor ou é um defeito específico da versão.

Após as alterações de configuração, reinicie o BigBlueButton somente quando necessário com o comando `npm sudo bbb-conf --restartstart`, e execute-o sudo bbb-conf --checknovamente. Evite acumular várias alterações antes de testar; fazer uma alteração por vez permite identificar qual ajuste realmente corrigiu o problema.

Verificação de sucesso: dois participantes conseguem conversar entre si em uma sala de discussão, retornar à sala principal e entrar novamente em uma sala de discussão sem problemas de conexão. Repita esse procedimento a partir de pelo menos uma rede externa antes de considerar o incidente encerrado.

Quando mudar de abordagem

Se o problema persistir após a verificação das permissões do navegador, integridade do servidor, ICE/TURN e seleção da ponte, colete evidências em vez de continuar a tentar adivinhar. Registre a versão do BigBlueButton, as versões do navegador e do sistema operacional, se o problema se reproduz na demonstração pública do BigBlueButton, a saída do comando `bigbluebutton test` sudo bbb-conf --check, a configuração da ponte de áudio da reunião e quaisquer diagnósticos relevantes do WebRTC do navegador. O guia de ajuda do BigBlueButton solicita explicitamente esse tipo de informação de rede e ambiente ao solucionar problemas de áudio ou vídeo.

Em outubro de 2026, a documentação do BigBlueButton 3.0 ainda era a versão estável, com atualizações da versão 3.0 disponíveis no GitHub, enquanto a documentação da versão 4.0 estava marcada como em desenvolvimento. Isso é importante porque o BigBlueButton 4.0 altera o framework de mídia padrão para LiveKit, portanto, as instruções específicas da versão 4.0 não devem ser aplicadas automaticamente a um servidor 3.0. Consulte a página oficial de lançamentos do BigBlueButton antes de seguir instruções que dependam da versão.

Lista de verificação final

• A conexão de áudio da sala principal é estabelecida para o participante afetado.
• A permissão para usar o microfone foi concedida e o dispositivo em questão apresenta atividade de entrada.
• bbb-conf --checkNão apresenta erros inexplicáveis ​​no serviço de mídia.
• O ICE atinge um estado conectado; redes restritivas possuem um caminho TURN utilizável quando necessário.
• A reunião utiliza a ponte de áudio que você imagina.
• Dois usuários conseguem se ouvir em uma sala separada, depois retornar à sala principal e se reconectar com sucesso.

Se todas as seis verificações forem aprovadas repetidamente, o reparo está produzindo o resultado que importa: áudio estável em diferentes ambientes, e não apenas um ícone verde temporário de microfone.