Videoconferência numa VPS: largura de banda e SFU

Videoconferência auto-hospedada numa VPS é um problema de largura de banda

A videoconferência auto-hospedada falha em servidores pequenos por um motivo, e quase nunca é a instalação. A componente do servidor usada por todas as ferramentas modernas é uma SFU (unidade de encaminhamento seletivo). Recebe um fluxo de vídeo de cada participante e encaminha uma cópia para todos os outros participantes, pelo que o tráfego de saída do servidor cresce com o quadrado do número de participantes. Uma VPS com 1 GB ou 2 GB, num uplink partilhado, executa o software sem problemas. Não conseguirá suportar a reunião geral que está a planear.

Por isso, faça o trabalho nesta ordem. Conte as pessoas, calcule os megabits e só depois escolha o servidor. A instalação demora vinte minutos de copiar e colar. É o uplink que determina se alguém conseguirá ouvi-lo.

Por que a largura de banda cresce com o quadrado do número de participantes?

Comece pela malha. Cada navegador codifica a imagem da sua câmara e envia uma cópia diretamente para cada outro navegador. Nenhum servidor de media processa o vídeo. Uma chamada em malha com duas pessoas precisa de um servidor de sinalização e de mais nada. É por isso que as chamadas um para um são quase gratuitas de alojar. A malha deixa de funcionar com cerca de quatro ou cinco pessoas, porque um portátil numa ligação doméstica tem de carregar quatro ou cinco cópias separadas do seu próprio vídeo ao mesmo tempo.

Um SFU funciona de forma diferente. Cada navegador carrega uma cópia para o servidor. O servidor lê os cabeçalhos RTP (real-time transport protocol) e reencaminha esses pacotes para os outros participantes sem descodificar o vídeo. Esse é todo o mecanismo. Por isso, um SFU exige pouco CPU e muita rede.

A arquitetura mais antiga é um MCU (multipoint control unit). Este descodifica cada stream recebido, compõe-os numa única imagem e volta a codificar essa imagem. A largura de banda de saída é pequena. O custo de CPU é enorme. Atualmente, quase nada usa um MCU para vídeo, e este guia não usa nenhum.

Agora, a aritmética de um SFU. Suponha que cada pessoa envia vídeo a 1.2 Mbps e que ninguém desliga a câmara. O servidor recebe N vezes 1.2 Mbps. Esse valor cresce de forma linear e não é problemático. O servidor envia N vezes (N menos 1) vezes 1.2 Mbps, porque cada uma das N pessoas tem de receber os outros N menos 1 streams. É esse segundo valor que faz muitos projetos terminarem.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Estas linhas mostram cálculos, não medições de um servidor específico. A coluna mensal assume vinte horas de chamadas num mês. Leia primeiro a última linha. Cinquenta pessoas com a câmara ligada precisam de 2,940 Mbps de tráfego de saída sustentado de uma única máquina. Trinta pessoas precisam de 1,044 Mbps. Quatro pessoas precisam de 14.4 Mbps, uma carga que qualquer VPS suporta sem dificuldade. Entre a linha de quatro pessoas e a linha de trinta pessoas, o número de participantes cresce sete vezes e meia, enquanto o tráfego de saída cresce mais de setenta vezes.

As implementações reais ficam abaixo destes valores, e é importante saber exatamente porquê. O Jitsi e o LiveKit usam simulcast: o emissor publica várias camadas de qualidade ao mesmo tempo, e o SFU reencaminha uma camada de baixa qualidade para quem não está no ecrã. O Jitsi também tem uma definição last-N que reencaminha vídeo apenas dos oradores mais recentes. Ambas as técnicas poupam muito tráfego. Nenhuma altera o formato da curva, e ambas deixam de ajudar quando todos ligam a câmara e fixam os vídeos uns dos outros.

O que um uplink de VPS oferece na prática?

Uma página de planos pode indicar uma "porta de 1 Gbps". Essa é a velocidade da placa de rede virtual, não uma garantia sobre o próximo salto. A ligação é partilhada com os outros tenants no mesmo host físico. Por isso, o débito sustentado durante um período de maior utilização é inferior à velocidade da porta. Uma chamada em conferência é precisamente uma carga sustentada. A maioria dos planos também inclui um limite mensal de transferência. Depois desse limite, o tráfego é limitado ou faturado.

É nesse limite que o problema aparece na fatura. Vinte horas da chamada com trinta pessoas num mês transferem 9.4 TB para fora do servidor, a 469.8 GB por hora. Vinte horas da chamada com cinquenta pessoas transferem 26.5 TB. Verifique o limite de transferência antes de verificar a quantidade de RAM. Se a página do plano for vaga sobre esse limite, essa falta de clareza já é a resposta. Ler corretamente uma oferta de VPS é mais importante para esta carga de trabalho do que para quase qualquer outra.

Jitsi Meet: a opção padrão e os requisitos

O Jitsi Meet é a opção por onde a maioria das pessoas deve começar. A instalação é feita a partir do repositório Debian do próprio projeto, configura o nginx e um certificado durante a instalação, e o videobridge (JVB) usa uma única porta UDP, o que mantém as regras de firewall curtas. Requer Debian 11 ou mais recente, ou Ubuntu 22.04 ou mais recente.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

O instalador pede um hostname e depois apresenta as opções de certificado. Escolha a opção Let's Encrypt e indique um nome de domínio que já resolva para o endereço público deste servidor. O certificado é emitido através de um desafio HTTP, por isso a instalação falha nessa etapa se o nome apontar para outro local.

Depois, abra as portas. Estas são as portas documentadas no manual, com o SSH em primeiro lugar para que ufw enable não o deixe sem acesso:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

As portas TCP 80 e 443 servem a aplicação web e permitem renovar o certificado. A porta UDP 10000 transporta todo o áudio e vídeo, e é a porta que mais frequentemente fica esquecida. A porta UDP 3478 e a porta TCP 5349 pertencem ao servidor coturn que o pacote Jitsi instala juntamente com a bridge. Esse servidor é o caminho alternativo para utilizadores cujas redes bloqueiam UDP.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

O primeiro comando deve indicar que o serviço está ativo. O segundo deve mostrar a bridge a escutar na porta UDP 10000. Se não apresentar nada, a bridge não iniciou, e /var/log/jitsi/jvb.log indicará o motivo.

Para dimensionamento, o manual do Jitsi publica o seu próprio ponto de partida, enquanto o BigBlueButton publica um requisito muito maior:

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

O manual do Jitsi recomenda 8 GB de RAM e 4 cores dedicados para um servidor com utilização significativa. Uma ligação de rede de 1,000 Mbps costuma ser suficiente. O manual também indica que instalações menores funcionam com 4 GB ou 2 GB. Há um detalhe importante nessa página: o Prosody, o servidor XMPP que gere a sinalização, pode usar apenas um core. Os cores adicionais ajudam a bridge, mas não melhoram a sinalização.

Por que todos entram na chamada, mas ninguém vê vídeo?

Esta é a falha padrão do Jitsi numa VPS. A lista de participantes é preenchida, o chat funciona e todos os mosaicos de vídeo permanecem pretos. O videobridge anuncia os endereços que encontra nas próprias interfaces. Num provedor que atribui à máquina virtual um endereço privado e mapeia um endereço público para ele, o único endereço que o JVB encontra é o privado. Assim, cada cliente tenta enviar mídia para algo como 10.0.0.5, mas os pacotes não chegam ao destino.

Informe os dois endereços ao bridge. Adicione um mapeamento estático a /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

Reinicie com sudo systemctl restart jitsi-videobridge2. Obtenha o endereço local em ip -4 addr show e o endereço público no painel de controle do provedor. Guias mais antigos definem a mesma configuração em /etc/jitsi/videobridge/sip-communicator.properties, usando as chaves org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS e org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Elas continuam funcionando, mas instalações novas devem usar o bloco de mapeamento acima.

A outra causa é um firewall que não foi configurado. A maioria dos provedores executa um firewall de rede no painel de controle, separado do ufw no servidor, e a porta UDP 10000 precisa estar aberta nos dois. Para descobrir qual camada está descartando os pacotes, execute sudo tcpdump -ni any udp port 10000 no servidor enquanto alguém entra de fora. A ausência total de pacotes significa que nada chega à máquina. Nesse caso, o bloqueio está antes do sistema operacional. Pacotes que chegam enquanto os mosaicos continuam pretos significam que o bridge está respondendo com um endereço que o cliente não consegue alcançar. Nesse caso, o problema está no mapeamento. Se você não tiver certeza sobre o próprio ufw, as regras de ufw realmente necessárias numa VPS explicam a ordem das regras que costuma causar problemas.

BigBlueButton: pesado, opinativo e exige o servidor inteiro

O BigBlueButton foi concebido para o ensino. Inclui quadro branco, salas de grupo, sondagens e uma área de apresentação. O pipeline de gravação é uma funcionalidade principal, não um complemento. Também é, por uma margem ampla, a opção mais pesada aqui. Não é um pacote que possa adicionar a um servidor existente.

Em agosto de 2026, o caminho suportado é o BigBlueButton 3.0 no Ubuntu 22.04, selecionado com o sinalizador de versão jammy-300. Os requisitos de produção indicados pelo projeto são 16 GB de memória com swap ativado, 8 núcleos de CPU com elevado desempenho por thread, 250 Mbps de largura de banda simétrica e 500 GB de disco se mantiver as gravações (50 GB se as desativar). As portas são TCP 80 e 443, além do intervalo UDP de 16384 a 32768.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Os próprios exemplos do projeto encaminham esse script diretamente para bash. Em vez disso, descarregue-o e leia-o primeiro, porque ele reescreve a configuração do nginx, instala a sua própria stack de multimédia e áudio, fixa versões dos pacotes e assume o hostname. Isso faz parte do desenho do produto, não é uma falha: o BigBlueButton espera ter controlo sobre a máquina. O sinalizador -w configura a firewall, -s é o hostname, -e é o endereço que o Let's Encrypt regista e -g adiciona o frontend Greenlight. Se o mesmo servidor também terminar TLS para outros serviços, mova o BigBlueButton para outro servidor ou certifique-se de que entende o que a configuração do reverse proxy nginx está a fazer antes de o script a alterar.

Compare cuidadosamente as duas linhas desse gráfico. O BigBlueButton requer o dobro da memória e o dobro dos núcleos sugeridos para o Jitsi, embora exija um quarto da largura de banda. Os dois valores não são medidos da mesma forma e pressupõem tamanhos de sala diferentes. Por isso, trate cada um como o ponto de partida do respetivo projeto, não como uma comparação direta. A diferença de CPU é real e resulta de tudo o que o BigBlueButton faz além de encaminhar vídeo.

Galène: a opção pequena

Galène é um SFU compacto escrito em Go. Compila para um único binário estático, inclui o seu próprio cliente Web e um servidor TURN, por isso não é necessário manter um servidor XMPP, um runtime Java ou uma aplicação Rails em execução. Se precisa de uma chamada fiável para dez pessoas num servidor modesto, experimente esta opção antes de concluir que precisa de mais hardware.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

O pacote golang-go no Ubuntu 24.04 é o Go 1.22. Se go build indicar que o módulo precisa de uma versão mais recente do Go, instale uma toolchain atual a partir de go.dev em vez de tentar contornar o pacote da distribuição.

Um grupo é o termo usado pelo Galène para uma sala, e um grupo é um ficheiro JSON:

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

Abra https://your.server:8443/group/night-watch/ e inicie sessão como vimes. Essas credenciais vêm diretamente do README do projeto, por isso altere-as antes de a porta ficar acessível a partir de qualquer outro local. Numa implementação real, o projeto documenta uma unidade systemd:

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

As portas são TCP 8443 para a interface Web, TCP e UDP 1194 para o servidor TURN integrado e um intervalo de portas UDP altas para os media. Fixe esse intervalo para poder criar uma única regra de firewall para ele:

./galene -udp-range 40000-40100

A opção -turn é a mais importante numa VPS. -turn ':1194' faz o Galène escutar em todos os endereços IPv4 públicos. -turn '203.0.113.1:1194' informa o Galène sobre o endereço que os clientes irão efetivamente ver, o que é necessário quando o endereço da máquina é privado. -turn '' desativa o servidor integrado para que possa apontar para um servidor externo através de data/ice-servers.json. O valor predefinido é auto, que se comporta como :1194 quando não existe ice-servers.json.

Pode colocar o nginx à frente da interface Web definindo proxyURL em data/config.json e fazendo proxy da localização /ws com os cabeçalhos de atualização do WebSocket. Tenha em conta o que isto abrange: os clientes continuam a abrir fluxos UDP diretos e ligações TCP diretas para a porta TURN, por isso o reverse proxy trata apenas da página e da sinalização. Os media nunca passam por ele.

A documentação do Galène afirma que são necessários recursos de servidor muito moderados e não publica nenhum valor específico, por isso não espere encontrar um. Os cálculos de largura de banda apresentados acima continuam a aplicar-se integralmente. O que poupa são a memória e os componentes adicionais de tudo o que não é o SFU.

Owncast: de um para muitos, com largura de banda linear

Muitos requisitos de "videoconferência" são, na prática, uma pessoa a apresentar para uma audiência que escreve no chat. Se esse for o seu caso, um SFU é a ferramenta errada e a economia muda completamente. O Owncast recebe um fluxo RTMP do OBS ou de um codificador semelhante e disponibiliza HLS através de HTTPS normal. A largura de banda por espectador é linear, e não quadrática. Como a saída consiste em segmentos HTTP normais, pode colocá-la atrás de armazenamento de objetos ou de uma CDN e deixar de pagar por esse tráfego na origem.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

A documentação do projeto indica que não deve executar isto como root e que deve inspecionar qualquer script remoto antes de o executar. Por isso, o download é uma etapa separada acima. O instalador obtém a versão atual e um binário ffmpeg, caso ainda não tenha um. Execute ./owncast a partir do diretório de instalação e abra o painel de administração em /admin na porta 8080. O login predefinido é o utilizador admin, com a chave de fluxo predefinida abc123 como palavra-passe. Altere-a antes de apontar um domínio para o servidor.

O design baseado em HLS tem duas consequências. Os espectadores ficam alguns segundos ou minutos atrás da transmissão em direto, porque o HLS disponibiliza segmentos completos. Por isso, não é possível manter uma conversa de ida e volta. Além disso, não há UDP nem TURN em nenhum ponto do percurso. Assim, o serviço chega a redes onde uma chamada WebRTC não consegue estabelecer ligação.

O Owncast também é a única ferramenta aqui que faz transcodificação de propósito. Cada qualidade de saída ativada corresponde a outra codificação ffmpeg do fluxo recebido, executada durante toda a transmissão. Num VPS pequeno, disponibilize uma ou duas qualidades. Cinco irão saturar a CPU enquanto a rede permanece ociosa.

Element Call num servidor Matrix que já gere

Se já gere o Matrix, o vídeo é uma extensão, não um segundo produto para administrar. Ainda assim, envolve mais de um pacote. O Element Call precisa de duas coisas atrás do seu homeserver. A primeira é um SFU LiveKit, que encaminha os meios de comunicação. A segunda é o serviço de autorização MatrixRTC, element-hq/lk-jwt-service, que fornece ao cliente o URL WebSocket do LiveKit e um JWT assinado (JSON Web Token) para estabelecer a ligação. Esse serviço usa a API de federação do Matrix. Por isso, precisa de um reverse proxy TLS à frente e de um nome que a federação consiga alcançar.

As portas documentadas do LiveKit:

• TCP 7880 para a API e o WebSocket do cliente, atrás de um proxy que termina o TLS
• TCP 7881 para ICE sobre TCP, usado quando um cliente não consegue sair pela UDP
• UDP 50000 a 60000 para os meios de comunicação; cada participante numa sala usa duas portas
• UDP 3478 e TCP 5349 se ativar o servidor TURN integrado; a porta 5349 tem de passar para 443, exceto quando existe um balanceador de carga à frente

Duas portas por participante parecem preocupantes, mas não são. Um intervalo de 10,000 portas cobre milhares de participantes, e a largura de banda de saída esgota-se muito antes do intervalo. Abra todo o intervalo mesmo assim. Um intervalo parcialmente aberto falha para algumas pessoas e funciona para outras, o que torna este tipo de falha especialmente difícil de diagnosticar. A parte do homeserver é uma tarefa separada, abordada em executar um homeserver Synapse numa VPS.

Por que uma pessoa nunca consegue ligar-se? TURN e as redes que bloqueiam UDP

Primeiro, alguns termos, usados uma única vez. ICE (interactive connectivity establishment) é o processo que dois endpoints WebRTC usam para encontrar um caminho funcional entre si. STUN (session traversal utilities for NAT) é um pequeno serviço que informa ao cliente qual é o seu próprio endereço público visto do exterior. TURN (traversal using relays around NAT) é um relay: quando não existe um caminho direto, ambos os lados enviam o respetivo tráfego multimédia para o servidor TURN, que o encaminha.

É necessário TURN para os participantes cujas redes não consegue controlar. Um deles pode estar numa rede empresarial ou universitária onde o UDP de saída está totalmente bloqueado. Outro pode estar atrás de um NAT de operadora que atribui uma porta de origem diferente a cada destino. Isso chama-se NAT simétrico e torna inútil o endereço que o STUN comunicou.

O sintoma é específico. A maioria das pessoas entra e tudo funciona. Uma pessoa vê a lista de participantes, vê o chat e recebe um mosaico preto com um indicador de carregamento. O browser recolheu candidatos, nenhum dos pares funcionou e o ICE terminou num estado de falha. No Chrome, chrome://webrtc-internals aberto durante a tentativa mostra os pares de candidatos e essa falha. Peça a essa pessoa que tente novamente a partir de um telemóvel com dados móveis. Se funcionar nesse dispositivo, a causa é a rede e TURN é a solução.

TURN sobre TCP nas portas 443 ou 5349 é o fallback que funciona praticamente em todo o lado, porque uma rede que bloqueie TLS na porta 443 bloqueou a Web. O pacote do Jitsi instala e configura o coturn automaticamente. É precisamente por isso que as regras de firewall documentadas incluem UDP 3478 e TCP 5349. O Galène inclui TURN na porta 1194. O LiveKit tem um servidor TURN integrado que pode ativar na configuração. Se executar o coturn por conta própria:

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

No Debian e no Ubuntu, o serviço fornecido pelo pacote não inicia até definir TURNSERVER_ENABLED=1 em /etc/default/coturn. Um coturn instalado mas nunca ativado parece, do exterior, exatamente igual a não ter TURN. Por isso, esta única linha pode fazer perder uma noite inteira.

Agora, o custo que ninguém regista. Um relay transporta todo o tráfego multimédia de cada participante encaminhado, nas duas direções. Quando o coturn partilha o servidor com o SFU, a maior parte desse tráfego atravessa o loopback e consome CPU, não uplink. Além disso, o listener TLS cifra cada pacote uma segunda vez, sobre o DTLS que o tráfego multimédia já utiliza. Quando move o TURN para uma máquina própria, essa máquina precisa de um plano de largura de banda dimensionado da mesma forma que o do SFU. TURN sobre TCP também transforma o tráfego multimédia em tempo real num stream fiável. Assim, um pacote perdido é retransmitido em vez de ser ignorado. Um participante encaminhado numa ligação com perdas acumula atraso em vez de sofrer apenas uma falha breve. O relay é um fallback que estabelece a ligação, mas com uma qualidade que o caminho direto teria superado.

Quando é que o SFU faz transcodificação e qual é o custo?

Um SFU encaminha pacotes e nunca descodifica vídeo. Por isso, quatro cores podem servir uma sala que, à primeira vista, parece exigir muito mais recursos. Duas funcionalidades quebram essa propriedade. Ambas surpreendem quem as ativou através de uma caixa de seleção.

A gravação é a primeira. O Jitsi grava com o Jibri, e a documentação do próprio Jibri descreve exatamente o que ele faz: inicia uma instância do Chrome renderizada num framebuffer virtual e captura e codifica a saída com o ffmpeg. Isto significa executar continuamente, durante toda a chamada, um browser completo a renderizar a reunião inteira, além de um codificador de vídeo. A mesma documentação indica que apenas uma gravação de cada vez é suportada num único Jibri e que o Jibri deve ser executado numa máquina ou máquina virtual separada, sem outras aplicações a utilizar os dispositivos de ecrã ou áudio. A gravação exige um segundo servidor. Não é apenas uma caixa de seleção.

A ligação telefónica é a segunda. Ligar uma linha telefónica a uma conferência implica converter Opus a 48 kHz para o formato aceite pela rede telefónica, normalmente G.711 a 8 kHz, nos dois sentidos e continuamente durante toda a chamada. A transcodificação de áudio é muito mais barata do que a transcodificação de vídeo, mas é executada por cada perna da chamada e nunca é interrompida. Por isso, o custo aumenta com o número de participantes que ligam por telefone. Se quiser um número de acesso telefónico, um servidor VoIP self-hosted é o componente que executa esse trabalho e deve ficar numa máquina própria pela mesma razão que o Jibri.

Qual é o tamanho de servidor de que realmente precisa?

Para duas pessoas, quase nada. O Jitsi ativa o modo peer-to-peer por padrão quando há exatamente dois participantes. Nesse modo, a conferência deixa de enviar dados pelo videobridge e usa a ligação direta. A entrada de uma terceira pessoa faz com que o tráfego volte a passar pelo bridge. Portanto, um VPS de 1 GB com Jitsi funciona bem como servidor para chamadas individuais, mas funciona mal com quatro pessoas. Por isso, “funcionou quando testei” é um relato tão comum.

Para até cerca de dez pessoas com as câmaras ligadas, 67.2 Mbps com oito participantes fica dentro da capacidade de uplink de um VPS comum. Duas CPUs virtuais e 4 GB são suficientes para executar o Jitsi ou o Galène nessa escala, desde que não esteja a gravar. Monitorize o contador de transferência, não o gráfico de CPU.

Para trinta pessoas, o pior caso é 1,044 Mbps sustentados, e vinte horas disso correspondem a 9.4 TB. Nesta escala, calcule primeiro o custo da largura de banda e só depois o custo do servidor. Ative o last-N para que o bridge encaminhe apenas os oradores recentes, defina as câmaras desligadas como comportamento padrão para os participantes e coloque o SFU num fornecedor com um limite de transferência que suporte esses valores.

Acima disso, um único VPS não é a arquitetura adequada. Ou o evento é, na realidade, uma transmissão, caso em que Owncast com uma CDN custa uma fração desse valor, ou precisa de mais de um videobridge atrás de uma única camada de sinalização. Isso já é um projeto diferente daquele que iniciou.

Falta uma consideração sobre o encaminhamento. A maioria das equipas precisa de chat durante muito mais horas do dia do que precisa de vídeo. O chat é barato de alojar e fácil de manter em execução. Implementar uma alternativa autoalojada ao Slack para o tráfego diário e manter um servidor de conferências apenas para chamadas agendadas é a configuração que continua a funcionar com um orçamento limitado para um VPS.

FAQ

Porque é que as pessoas conseguem entrar na minha reunião Jitsi, mas não se conseguem ver nem ouvir?

O chat e a lista de participantes passam pelo canal de sinalização, que usa TCP na porta 443. O áudio e o vídeo usam UDP na porta 10000 até ao videobridge. Se a lista de participantes fica preenchida e todos os mosaicos permanecem pretos, o caminho de media está interrompido, mas o caminho de sinalização está a funcionar. Verifique a porta UDP 10000 nas duas firewalls: a firewall do servidor e a firewall de rede separada no painel de controlo do fornecedor. Depois confirme se o bridge conhece o endereço público: numa máquina virtual com um endereço privado e outro público mapeado, adicione um mapeamento estático em ice4j.harvest.mapping, dentro de /etc/jitsi/videobridge/jvb.conf, e reinicie jitsi-videobridge2. Executar sudo tcpdump -ni any udp port 10000 enquanto alguém entra permite identificar qual dos dois caminhos está a falhar, porque a ausência total de pacotes indica que o bloqueio está a montante do sistema operativo.

Quanta largura de banda utiliza uma videochamada com 30 pessoas?

No pior caso, quando todos têm a câmara ligada e o SFU encaminha uma camada de qualidade total para cada participante, saem do servidor aproximadamente 1,044 Mbps, ou 469.8 GB por hora. Este valor resulta do cálculo de N vezes (N menos 1) streams a 1.2 Mbps cada. Não é uma medição da sua configuração. O simulcast e uma definição last-N reduzem bastante o consumo normal, porque a maioria dos participantes não aparece no ecrã em cada momento. Dimensione o servidor para algo próximo do pior caso, porque esse caso ocorre numa reunião geral em que todos ligam a câmara ao mesmo tempo.

Posso executar o Jitsi Meet numa VPS com 1 GB?

A instalação será concluída e uma chamada com duas pessoas funcionará, em parte porque o Jitsi usa o modo peer to peer com exatamente dois participantes e ignora completamente o videobridge. Não é um servidor adequado para chamadas de grupo. O Prosody, o videobridge e o runtime Java necessitam todos de memória. A própria documentação recomenda 8 GB para uma instalação séria, e o cálculo da largura de banda será um problema antes da memória. Se dispõe de um servidor com 1 GB, o Galène adapta-se melhor a esse tamanho do que o Jitsi.

Continuo a precisar de um servidor TURN se a minha VPS tiver um endereço IP público?

Sim. O problema resolvido pelo TURN está na outra extremidade da chamada. Um participante numa rede empresarial que bloqueie UDP de saída, ou atrás de um NAT de operadora que atribua uma porta de origem diferente para cada destino, não consegue criar um caminho de media direto, independentemente de o endereço do servidor ser público. TURN sobre TCP nas portas 443 ou 5349 fornece um relay que a firewall interpreta como tráfego web normal. A instalação do pacote do Jitsi configura o coturn desta forma por predefinição. Por isso, as regras de firewall documentadas abrem UDP 3478 e TCP 5349.

Porque é que o BigBlueButton precisa de muito mais hardware do que o Jitsi Meet?

Porque faz muito mais do que encaminhar vídeo. O requisito de produção publicado é de 16 GB de RAM e 8 cores, contra 8 GB e 4 cores no manual do Jitsi. O BigBlueButton executa uma stack completa de audioconferência, um quadro branco partilhado e uma camada de apresentações, um pipeline de gravação e pós-processamento e um frontend web com contas de utilizador, tudo na mesma máquina. Também impõe requisitos específicos para a plataforma: em agosto de 2026, a instalação suportada é a versão 3.0 no Ubuntu 22.04. Ambos os conjuntos de valores provêm da documentação dos respetivos projetos e servem como pontos de partida, não como medições da sua carga de trabalho.