Como calcular um VPS para videoconferência auto-hospedada

Videoconferência auto-hospedada em um 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 é um SFU (selective forwarding unit). Recebe um fluxo de vídeo de cada participante e encaminha uma cópia para todos os outros participantes. Por isso, o tráfego de saída do servidor cresce com o quadrado do número de participantes. Um VPS de 1 GB ou 2 GB num uplink partilhado executará 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 determina se alguém conseguirá ouvi-lo.

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

Comece por uma malha. Cada browser codifica a imagem da sua câmara e envia uma cópia diretamente para cada outro browser. Nenhum servidor de media toca no 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 individuais 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 browser 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 princípio. É por isso que 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 é reduzida. O custo de CPU é enorme. Atualmente, quase nada usa um MCU para vídeo. Este guia também não usa.

Agora, a aritmética de um SFU. Suponha que cada pessoa envia vídeo a 1.2 Mbps e que ninguém desligou a câmara. O servidor recebe N vezes 1.2 Mbps. Esse valor é linear e não causa problemas. 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 encerra projetos.

[
  {
    "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
  }
]

Essas linhas são cálculos, não medições de nenhum 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 a partir de uma única máquina. Trinta pessoas precisam de 1,044 Mbps. Quatro pessoas precisam de 14.4 Mbps, um valor que qualquer VPS suporta sem dificuldade. Entre a linha de quatro pessoas e a 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. É importante saber exatamente porquê. O Jitsi e o LiveKit usam simulcast: o remetente 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. As duas técnicas poupam muito tráfego. Nenhuma altera o formato da curva. Ambas deixam de ajudar no momento em que todos ligam a câmara e fixam os restantes participantes.

O que uma ligação de saída de um VPS oferece realmente?

A página do plano diz "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 clientes no mesmo host físico. Por isso, o débito sustentado durante um período de maior utilização é inferior à velocidade da porta, e 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 débito é reduzido ou são cobrados custos adicionais.

É nesse limite que a diferença 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 o que é necessário

Jitsi Meet é a opção pela qual 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 da firewall curtas. É necessário usar 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 nome de host e apresenta depois uma opção 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 um nome que aponte para outro local falha nessa etapa.

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 bloqueie:

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

TCP 80 e 443 servem a aplicação web e permitem renovar o certificado. UDP 10000 transporta todo o áudio e vídeo, e é a porta que as pessoas mais se esquecem de abrir. UDP 3478 e TCP 5349 pertencem ao servidor coturn que o pacote Jitsi instala juntamente com a bridge. Esse é o caminho de fallback para utilizadores cuja rede bloqueia 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 em UDP 10000. Se não apresentar nada, a bridge não arrancou e /var/log/jitsi/jvb.log indicará o motivo.

Para dimensionamento, o manual do Jitsi publica o seu próprio ponto de partida e o BigBlueButton publica um valor muito superior:

[
  {
    "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 sério. Uma ligação de rede de 1,000 Mbps costuma ser suficiente. O manual também indica que configurações menores funcionam com 4 GB ou 2 GB. Há um detalhe nessa página que vale a pena ter em conta: o Prosody, o servidor XMPP que trata da sinalização, pode usar apenas um core. Cores adicionais ajudam a bridge, mas não fazem nada pela 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 um endereço privado à máquina virtual e mapeia um endereço público para ele, o único endereço encontrado pelo JVB é o privado. Por isso, cada cliente tenta enviar multimédia para algo como 10.0.0.5 e os pacotes não chegam ao destino.

Informe ambos os 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 controlo 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. Essas chaves continuam a funcionar, mas as novas instalações devem usar o bloco de mapeamento acima.

A outra causa é uma firewall que não foi configurada. A maioria dos provedores executa uma firewall de rede no painel de controlo, separada do ufw no servidor, e a porta UDP 10000 tem de estar aberta em ambas. Para descobrir em que camada os pacotes são descartados, execute sudo tcpdump -ni any udp port 10000 no servidor enquanto alguém entra a partir do exterior. A ausência total de pacotes significa que nada chega à máquina. Nesse caso, o bloqueio está a montante do sistema operativo. Pacotes que chegam enquanto os mosaicos continuam pretos significam que o bridge está a responder com um endereço que o cliente não consegue alcançar. Nesse caso, o problema está no mapeamento. Se a parte que não sabe configurar for o próprio ufw, as regras de ufw de que uma VPS realmente precisa explica 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 trabalho, sondagens e uma área de apresentações. O pipeline de gravação também é uma funcionalidade principal, não um complemento. É ainda, por uma margem significativa, a opção mais pesada desta lista. 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 ativada, 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 o TLS de outros serviços, mova o BigBlueButton para outro servidor ou certifique-se de que compreende o que a configuração do reverse proxy nginx está a fazer antes de o script a alterar.

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

Galène: a opção simples

O Galène é um SFU compacto escrito em Go. É compilado para um único binário estático, inclui o seu próprio cliente Web e inclui um servidor TURN. Assim, não precisa de um servidor XMPP, de um runtime Java nem de uma aplicação Rails para manter em execução. Se precisar de uma chamada fiável com 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 resolver o problema com 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. Altere-as antes de a porta ficar acessível a partir de qualquer outro local. Para uma 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 escrever uma única regra de firewall para ele:

./galene -udp-range 40000-40100

A opção -turn é a mais importante num VPS. -turn ':1194' fica à escuta em todos os endereços IPv4 públicos. -turn '203.0.113.1:1194' indica ao Galène o endereço que os clientes irão efetivamente ver. É isso que precisa quando o endereço da própria 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 encaminhando a localização /ws com os cabeçalhos de upgrade 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. Assim, o reverse proxy trata apenas da página e da sinalização. Os media nunca passam por ele.

A documentação do Galène indica que precisa de recursos de servidor muito moderados e não publica nenhum valor específico. Por isso, não espere encontrar um número exato. 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 pertence ao SFU.

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

Muitos requisitos de «videoconferência» são, na realidade, uma pessoa a apresentar para um público que escreve no chat. Se esse for o seu caso, um SFU é a ferramenta errada e a relação de custos muda completamente. O Owncast recebe um stream 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 simples, pode colocá-la atrás de object storage ou de uma CDN e deixar de pagar esse tráfego no servidor de 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 este serviço não deve ser executado como root e que qualquer script remoto deve ser inspecionado antes de ser executado. Por isso, o download é uma etapa separada acima. O instalador obtém a versão atual e um binário do ffmpeg, caso ainda não exista um disponível. Execute ./owncast a partir do diretório de instalação e abra o painel de administração em /admin na porta 8080. O início de sessão predefinido usa o utilizador admin e a chave de stream 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 emissão em direto, porque o HLS envia segmentos completos. Por isso, não é possível manter uma conversa com interação nos dois sentidos. Além disso, não existe UDP nem TURN em qualquer ponto do percurso. Assim, o serviço alcanç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 stream recebido, executada durante toda a emissão. Num VPS pequeno, disponibilize uma ou duas qualidades. Cinco saturam a CPU enquanto a rede permanece sem utilização.

Element Call num servidor Matrix que já administra

Se já administra o Matrix, o vídeo é uma funcionalidade adicional, não um segundo produto para operar. Ainda assim, são necessários mais do que um pacote. O Element Call precisa de duas coisas atrás do seu homeserver. A primeira é um SFU LiveKit, que encaminha o tráfego de mídia. A segunda é o serviço de autorização MatrixRTC, element-hq/lk-jwt-service, que fornece ao cliente a URL do 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 possa ser alcançado pela federação.

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 rede UDP
• UDP 50000 a 60000 para mídia, com duas portas usadas por cada participante numa sala
• UDP 3478 e TCP 5349 se ativar o servidor TURN incorporado; a porta 5349 tem de ser transferida para 443, a menos que exista um balanceador de carga à frente

Duas portas por participante parecem preocupantes, mas não são. Um intervalo de 10,000 portas suporta milhares de participantes, e a ligação de saída fica saturada muito antes de o intervalo terminar. Abra o intervalo completo mesmo assim. Um intervalo parcialmente aberto falha para algumas pessoas e funciona para outras, o que cria o pior tipo de falha para diagnosticar. A configuração do homeserver é uma tarefa separada, abordada em administrar um homeserver Synapse numa VPS.

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

Primeiro, alguns termos, usados apenas uma 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 serviço pequeno que informa a um cliente qual é o seu 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 os seus media para o servidor TURN, que os encaminha.

Precisa de TURN para os participantes cujas redes não consegue controlar. Um deles pode estar numa rede empresarial ou académica 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 para cada destino. Isto chama-se NAT simétrico e torna inútil o endereço indicado pelo STUN.

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

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

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

Essas definições ficam em /etc/turnserver.conf. No Debian e no Ubuntu, o pacote inicia o coturn assim que é instalado, com a versão padrão desse ficheiro. Por isso, enable --now encontra-o já em execução e não altera nada. As suas definições entram em vigor quando executar sudo systemctl restart coturn. Todas as edições posteriores ao ficheiro precisam do mesmo restart. Guias antigos também indicam definir TURNSERVER_ENABLED=1 em /etc/default/coturn. Apenas o script init antigo lê essa opção. A unidade systemd usada pelos pacotes atuais não a lê. Portanto, essa linha não altera nada, e um coturn que nunca foi reiniciado continua a usar o ficheiro padrão.

Agora, o custo que quase ninguém documenta. Um relay transporta todo o media de cada participante relayed em ambas as direções. Quando o coturn partilha um servidor com o SFU, a maior parte desse tráfego atravessa o loopback e consome CPU, não o uplink. Além disso, o listener TLS cifra cada pacote uma segunda vez, para além do DTLS já usado pelo media. 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 media em tempo real num stream fiável. Assim, um pacote perdido é retransmitido em vez de ser ignorado, e um participante relayed numa ligação com perdas acumula atraso em vez de sofrer apenas uma falha breve. O relay é um fallback que permite estabelecer a ligação, mas com uma qualidade que o caminho direto teria superado.

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

Um SFU encaminha pacotes e nunca descodifica vídeo. É por isso que quatro núcleos podem servir uma sala que, à partida, parece exigir muito mais recursos. Duas funcionalidades quebram esta 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. Isso significa renderizar toda a reunião num navegador completo e executar continuamente um codificador de vídeo durante toda a chamada. 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. Integrar uma linha telefónica numa 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 para 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 ligação telefónica, um servidor VoIP autoalojado é o componente que realiza esse trabalho e deve ficar no seu próprio servidor pelo mesmo motivo que o Jibri.

De que tamanho de servidor precisa realmente?

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 volte a usar o bridge. Por isso, um VPS com 1 GB a executar o Jitsi é adequado para chamadas individuais, mas insuficiente para chamadas com quatro pessoas. É por isso que “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 sustentada da ligação de saída de um VPS comum. Dois 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 em vez do gráfico de CPU.

Para trinta pessoas, o pior caso é 1,044 Mbps sustentados, e vinte horas desse tráfego correspondem a 9.4 TB. A partir desta dimensão, calcule primeiro o custo da largura de banda e só depois o do servidor. Ative o last-N para que o bridge encaminhe apenas os participantes que falaram recentemente, defina as câmaras desligadas por padrão para os participantes e coloque o SFU num local com um limite de transferência que suporte estes cálculos.

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 deste valor, ou precisa de mais do que um videobridge atrás de uma única camada de sinalização. Nesse caso, trata-se de um projeto diferente daquele que iniciou.

Falta considerar um aspeto do encaminhamento. A maioria das equipas precisa de chat durante muito mais horas por dia do que precisa de vídeo. O chat é barato de alojar e fácil de manter em execução. Configurar uma alternativa autoalojada ao Slack para o tráfego diário e manter um servidor de conferência apenas para chamadas agendadas é a arquitetura que se mantém viável com o orçamento de um VPS pequeno.

FAQ

Por que as pessoas conseguem entrar na minha reunião do Jitsi, mas não conseguem ver nem ouvir umas às outras?

O chat e a lista de participantes usam o canal de sinalização, que funciona em 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á funcional. Verifique 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 seu 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 indica qual dos dois problemas existe. Se não houver pacotes, o bloqueio está a montante do sistema operativo.

Quanta largura de banda utiliza uma chamada de vídeo com 30 pessoas?

No pior caso, quando todos têm a câmara ligada e o SFU encaminha uma camada de qualidade total para todos, saem aproximadamente 1,044 Mbps do servidor, o que corresponde a 469.8 GB por hora. Este valor resulta do cálculo de N vezes (N menos 1) fluxos a 1.2 Mbps cada. Não é uma medição do seu ambiente. O simulcast e uma configuração last-N reduzem bastante o consumo em condições normais, porque a maioria dos participantes não aparece no ecrã a qualquer momento. Dimensione o sistema próximo do pior caso, porque esse caso ocorre quando 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á. Isto acontece em parte porque o Jitsi usa o modo peer to peer com exatamente dois participantes e não utiliza o videobridge. Não é um servidor adequado para chamadas de grupo. O Prosody, o videobridge e o runtime Java precisam de memória. A recomendação do próprio manual é 8 GB para uma implementação séria. Além disso, 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.

Ainda preciso 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 bloqueia UDP de saída, ou atrás de uma NAT de operadora que atribui uma porta de origem diferente a 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, para a firewall, se parece com tráfego web normal. A instalação do pacote do Jitsi configura o coturn para isto por predefinição. É por isso que as regras de firewall documentadas abrem UDP 3478 e TCP 5349.

Por que motivo 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, em comparação com 8 GB e 4 cores no manual do Jitsi. O BigBlueButton executa uma stack completa de conferência de áudio, uma camada de quadro branco e apresentações partilhados, 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 vêm da documentação dos respetivos projetos e servem como pontos de partida, não como medições da sua carga de trabalho.