Como configurar o Jitsi Videobridge para uma configuração escalável com vários servidores

Adicionar servidores Jitsi Videobridge (JVB) é a maneira mais comum de aumentar a capacidade de mídia em uma implementação do Jitsi Meet. Mantenha os serviços web, Prosody e Jicofo no host Meet existente e adicione máquinas bridge independentes que se registrem na mesma sala de descoberta de bridges do Prosody. O Jicofo poderá então colocar novas conferências em um bridge disponível. Para esse projeto básico, os participantes de uma conferência usam um bridge selecionado; não é necessário o Octo apenas porque a implementação possui vários servidores JVB.

Este guia segue a configuração escalável baseada em pacotes Debian/Ubuntu do Manual do Jitsi, verificada em 6 de outubro de 2026. As dependências exatas dos pacotes e a configuração gerada podem variar de acordo com a distribuição, a versão do pacote Jitsi e se o servidor foi instalado com Docker ou outro método. Use o guia de instalação oficial correspondente à sua implementação atual.

Entenda o que significa “multi-servidor” no Jitsi.

Verificado: Uma única instalação do Jitsi Meet pode usar várias Videobridges. O Jicofo monitora as bridges e atribui uma nova conferência a uma delas. O exemplo simplificado do Manual do Jitsi coloca os serviços do Meet em um servidor e três JVBs em servidores separados. Cada bridge deve ser acessível aos participantes da reunião para mídia e à infraestrutura do Meet para sinalização.

Conceito errôneo comum: "Preciso de um balanceador de carga na frente dos JVBs." No projeto multi-bridge documentado, o Jicofo seleciona uma ponte; os clientes então enviam mídia para essa ponte. Um balanceador de carga HTTP genérico na frente da mídia UDP não substitui a descoberta de pontes ou o posicionamento em conferência. Ação: Adicione cada JVB ao pool de pontes do Prosody/Jicofo e publique seu endereço de mídia acessível. Não direcione o tráfego de mídia de todas as pontes para um VIP UDP arbitrário.

Conceito errado comum: “Mais bridges fazem com que uma reunião abranja todos os servidores automaticamente.” Na configuração básica, o Jicofo atribui uma conferência a uma bridge. Distribuir os participantes de uma conferência por diferentes regiões ou bridges é uma topologia de retransmissão separada chamada Octo (relays seguros na documentação atual do JVB). Ação: Comece com o agrupamento de bridges comum se o seu objetivo for realizar mais reuniões simultâneas; considere o Octo somente quando uma conferência precisar usar bridges em vários locais ou quando você precisar desse comportamento de retransmissão.

Planeje a piscina da ponte antes da instalação.

Escolha um nome de host ou endereço público e estável para cada JVB. Atribua a cada VM uma identidade de sistema operacional exclusiva e um apelido de instância JVB exclusivo quando a configuração usar a presença XMPP MUC. Todas as bridges devem ser capazes de acessar o mesmo serviço Prosody e a mesma sala de bridge. Mantenha as versões alinhadas: o Jicofo não mistura bridges com versões diferentes na mesma conferência, e a documentação atual do relay repete essa restrição para o Octo.

Depende do seu ambiente: Não existe um número universal de participantes por máquina virtual. A própria documentação de requisitos do Jitsi enfatiza a capacidade da rede e a carga de trabalho em vez de um único número fixo para dimensionamento. Codec, resolução, simulcast, taxas de pacotes, conferências simultâneas e largura de banda do provedor afetam a capacidade. Ação: Estabeleça uma linha de base para sua carga de trabalho real e, em seguida, adicione uma ponte por vez e observe o uso da CPU, a taxa de transferência da rede, a perda de pacotes e a qualidade da conferência.

Configure vários servidores JVB passo a passo.

1. Confirme se o host da reunião atual está funcionando corretamente.

Antes de adicionar máquinas, verifique se a página do Meet existente carrega, se o Prosody e o Jicofo estão em execução e se uma chamada de teste é concluída com sucesso pela ponte atual. Anote as versões dos pacotes do Jitsi. Uma configuração de sinalização ou certificado incorreta no servidor principal fará com que uma nova ponte pareça mal configurada, mesmo que sua rede esteja funcionando corretamente.

Em uma instalação de pacote Debian/Ubuntu, inspecione os serviços systemctl status prosody jicofo jitsi-videobridge2e revise os logs de serviço. Use os nomes de serviço presentes em sua instalação; implantações em contêineres expõem comandos e locais de log diferentes.

2. Prepare as regras de DNS, roteamento e firewall.

Atribua a cada ponte seu próprio endereço público ou um mapeamento NAT um-para-um configurado corretamente. O guia de configuração escalável lista estes caminhos típicos: clientes públicos acessam o host web via TCP 80/443; servidores JVB acessam o Prosody via TCP 5222; e clientes acessam cada Videobridge via UDP 10000 para mídia. A porta TCP 80 geralmente é usada para configuração de certificado ou redirecionamento, enquanto um site Meet de produção deve usar HTTPS.

• Permita o tráfego UDP de entrada na porta 10000 para todas as pontes provenientes das redes participantes que seu serviço suporta.
• Permita o tráfego TCP 5222 da ponte para o Prosody a partir dos hosts JVB e restrinja-o a esses hosts quando o seu firewall o permitir.
• Mantenha o serviço Prosody/XMPP restrito à infraestrutura pretendida, sempre que possível.
• Não exponha publicamente os endpoints HTTP/de depuração privados do JVB. Se você habilitar ou usar um proxy para um endpoint WebSocket público do Colibri, siga a documentação atual do JVB e do proxy reverso para essa implementação específica.

Depende da sua rede: NAT, grupos de segurança na nuvem, IPv6, TURN e redes corporativas restritivas podem exigir candidatos ou caminhos adicionais. A lista de portas padrão não comprova que a mídia funciona através do seu firewall específico. Ação: Verifique o fluxo de pacotes para cada endereço de ponte pública a partir de uma rede cliente externa e teste uma chamada real; uma conexão XMPP bem-sucedida por si só não verifica a mídia UDP.

3. Instale o mesmo pacote Jitsi Videobridge em cada nó.

Utilize o repositório Jitsi e as instruções do pacote que correspondam à distribuição do host do Meet. Em cada novo nó Debian/Ubuntu, instale jitsi-videobridge2o pacote e responda às solicitações de configuração com o nome do host do Meet, conforme indicado na configuração escalável oficial. O Manual afirma que, para a configuração baseada em pacotes documentada, a ponte não requer nenhuma alteração adicional além da configuração padrão após a instalação.

Não instale uma segunda pilha completa do Jitsi Meet em cada servidor de ponte, a menos que você queira implantações independentes do Meet. Para um pool de servidores de ponte, mantenha os serviços web, Prosody e Jicofo no host principal e adicione os serviços JVB às outras máquinas. Use a mesma versão JVB compatível em todo o pool; faça as atualizações em etapas para não deixar um pool com versões diferentes por mais tempo do que o necessário.

4. Verificar o registo e a identidade da ponte

Na configuração baseada em pacotes, primeiro deixe que a configuração oficial do pacote gere as configurações esperadas. Os JVBs precisam se conectar ao Prosody e anunciar a presença da ponte para o mesmo MUC da cervejaria que o Jicofo monitora. Se você estiver usando o caminho de configuração atual do cliente XMPP, a documentação do JVB mostra as partes relevantes em videobridge.statse videobridge.apis.xmpp-client.configs; o Jicofo deve se conectar à cervejaria correspondente usando jicofo.bridge.brewery-jid.

Uma configuração moderna típica tem este formato; substitua todos os valores de exemplo pelos valores da sua instalação e proteja o segredo compartilhado:

videobridge {
  stats {
    enabled = true
    transports = [{ type = "muc" }]
  }
  apis {
    xmpp-client {
      configs {
        xmpp-server-1 {
          hostname = "meet.example.com"
          domain = "auth.meet.example.com"
          username = "jvb"
          password = "REPLACE_WITH_SECRET"
          muc_jids = "JvbBrewery@internal.auth.meet.example.com"
          muc_nickname = "bridge-01"
        }
      }
    }
  }
}

Use um nome diferente muc_nicknameem cada ponte (por exemplo, `<nome_da_ponte>` bridge-02e ` bridge-03<nome_da_ponte>`). O projeto JVB alerta que os apelidos devem ser únicos em todas as instâncias. O nome exato do arquivo de configuração e a necessidade deste bloco explícito dependem do seu pacote e da configuração existente; evite sobrepor uma configuração moderna escrita manualmente às configurações legadas geradas pelo pacote sem verificar a documentação da versão instalada.

5. Inicie o serviço e verifique os registros.

Reinicie ou inicie o JVB em cada novo host e verifique se ele permanece ativo e se conecta ao Prosody. O guia de configuração escalável recomenda verificar os logs do Prosody e do Jicofo para confirmar as conexões de ponte e se o Jicofo as detecta. Se alguma ponte não aparecer, verifique nesta ordem: resolução de DNS e acessibilidade da porta TCP 5222; credenciais e domínio XMPP; grafia exata do MUC da cervejaria; apelido duplicado; e, por fim, compatibilidade de versão do JVB/Jicofo.

6. Execute um teste de mídia externa em cada ponte.

Inicie várias novas reuniões de teste e confirme se o Jicofo as distribui entre as pontes disponíveis ao longo do tempo. É esperado que pelo menos uma reunião seja alocada em uma ponte; isso não indica falha no balanceamento. Use a interface de depuração do Jicofo, se habilitada e com acesso restrito, para inspecionar as pontes disponíveis e as conferências ativas. A documentação do JVB fornece curl http://localhost:8888/debugum exemplo de depuração local; vincule ou bloqueie as interfaces de diagnóstico para que permaneçam privadas.

Faça testes com clientes fora da rede do servidor. Confirme se o áudio e o vídeo funcionam e, em seguida, inspecione o endereço da ponte selecionada e o fluxo UDP. Se uma ponte aparecer no Jicofo, mas as chamadas falharem somente quando essa ponte for selecionada, investigue seu endereço público, mapeamento NAT, firewall UDP e candidatos anunciados. Mantenha uma ponte fora de rotação durante a manutenção somente por meio de um procedimento de remoção ou implantação compatível com a sua versão instalada; reiniciar uma ponte ativa pode interromper as reuniões atribuídas a ela.

Quando devo ativar o Octo?

O Octo é o tópico certo quando uma única conferência precisa usar várias pontes, geralmente porque os participantes estão espalhados por diferentes regiões. Ele não é um pré-requisito para adicionar JVBs para capacidade comum. A documentação atual sobre retransmissão de JVBs exige configuração de retransmissão em cada ponte participante, WebSockets Colibri para conexões entre pontes e uma estratégia adequada de seleção de ponte Jicofo. O comportamento com reconhecimento de região também depende do fornecimento de informações precisas sobre a região do cliente para a configuração do Meet.

Uma configuração de retransmissão inclui um nome de domínio relay-ide uma região exclusivos para cada ponte, enquanto o Jicofo habilita o Octo e seleciona uma estratégia, como [exemplo RegionBasedBridgeSelectionStrategyde estratégia]. Os endpoints WebSocket de retransmissão também precisam ser roteados corretamente por meio de qualquer proxy. Essas configurações mudam entre versões e topologias, portanto, siga o guia de retransmissão atual e valide os caminhos exatos do proxy antes da implementação.

Ação: Deixe o Octo desativado para um pool de pontes simples de uma única região. Se você tiver um requisito de múltiplas regiões, teste com a estratégia de divisão documentada em um ambiente de homologação, inspecione o seletor de pontes e o estado da conferência do Jicofo e, em seguida, configure as regiões do cliente e a seleção baseada em região. Não defina rótulos de região até saber como os clientes receberão os metadados da região correspondente.

O que monitorar à medida que você expande

• Rede: taxa de transferência de entrada e saída, perda de pacotes, jitter e se a porta UDP 10000 está acessível a partir de redes de clientes reais.
• Pressão do host: CPU, memória, integridade da JVM e taxa de pacotes sustentada. Dimensionamento com reuniões representativas em vez de uma contagem universal presumida de chamadas.
• Participação no pool: presença da ponte no Jicofo, consistência de versão e se as conferências recém-criadas podem ser executadas em todos os nós.
• Experiência do participante: continuidade de áudio, congelamentos de vídeo, reconexões e qualidade sob a simultaneidade máxima esperada.

Se os usuários relatarem problemas apenas em uma JVB, compare o caminho de rede e a configuração desse nó com um nó par em funcionamento antes de expandir todo o cluster. Se todas as bridges apresentarem degradação simultaneamente, o gargalo pode ser a largura de banda compartilhada, os serviços de sinalização principais ou a rede participante. O escalonamento funciona quando as novas bridges são acessíveis independentemente, registradas corretamente e reduzem a carga de forma mensurável durante testes realistas.

Referências oficiais

• Manual do Jitsi: Guia DevOps (configuração escalável)
• Manual do Jitsi: Requisitos
• Jitsi Videobridge: Configuração MUC
• Jitsi Videobridge: configuração do relé (outubro)
• Jitsi Videobridge: interfaces HTTP e REST