Desenvolvimento WebRTC em 2026: arquitetura, custo e escopo

O WebRTC entrega áudio, vídeo e dados criptografados e de baixa latência entre navegadores e apps nativos, de graça e sem plugins. O que ele não entrega é um produto: sinalização, travessia de NAT (STUN/TURN), servidor de mídia para chamadas em grupo, autenticação, gravação e monitoramento ficam por sua conta, para construir ou comprar. A maior parte do custo e do risco no desenvolvimento WebRTC está nessas peças, não na API em si.

O que o WebRTC resolve e o que sobra para você

A API WebRTC no navegador cobre quatro coisas:

• Captura de mídia (getUserMedia, getDisplayMedia), com seleção de dispositivos e constraints.
• Codecs e transporte: Opus para áudio; VP8, VP9, H.264 e, cada vez mais, AV1 para vídeo; RTP sobre DTLS-SRTP com controle de congestionamento embutido.
• Conectividade: ICE, que testa caminhos de rede candidatos obtidos via STUN e TURN.
• Data channels: SCTP sobre DTLS para mensagens arbitrárias, com entrega confiável ou não confiável.

Todo o resto é deixado em aberto de propósito: sinalização (troca de SDP e candidatos ICE), servidores STUN e TURN, servidor de mídia para chamadas em grupo, identidade e permissões de sala, gravação, monitoramento (getStats devolve números brutos, não um pipeline) e interoperabilidade SIP/PSTN. "A sinalização é sua" é a primeira coisa a internalizar: o navegador não tem opinião sobre como dois peers se encontram, o que é má notícia para times que assumem que a parte difícil acabou quando a demo funciona no localhost.

Opções de arquitetura: mesh P2P vs SFU vs MCU

A decisão de arquitetura depende de um único número: quantos participantes enviam vídeo ao mesmo tempo.

Mesh P2P. Cada participante se conecta diretamente a todos os outros. Não há servidor de mídia, mas banda de upload e CPU crescem linearmente com o número de participantes; degrada rápido no mobile acima de três ou quatro emissores de vídeo.

SFU (Selective Forwarding Unit). Cada participante envia um único upstream (com camadas de simulcast) ao servidor, que encaminha os streams assinados por cada participante sem decodificar. Pouca CPU no servidor, latência próxima do P2P. É o padrão para chamadas em grupo em 2026.

MCU (Multipoint Control Unit). O servidor decodifica todos os streams, compõe um layout e recodifica. Os clientes recebem um único stream, independentemente do tamanho da sala. Caro e mais lento, mas certo para endpoints legados, clientes limitados ou quando você precisa de uma saída composta de qualquer forma.

Critério	Mesh P2P	SFU	MCU
Participantes na prática (vídeo)	2–4	Dezenas a centenas por sala (com simulcast e paginação)	Dezenas, limitado pela transcodificação no servidor
Custo de servidor	Nenhum (só STUN/TURN)	Moderado: limitado por banda, pouca CPU	Alto: limitado por CPU/GPU
Banda por cliente	Upload: N-1 streams; Download: N-1 streams	Upload: 1 stream (com camadas); Download: streams assinados	Upload: 1; Download: 1
Latência adicional	A menor	Pequena (só encaminhamento)	A maior (decodificar, mixar, codificar)
Gravação	Só no cliente, desajeitada	Por track no servidor, composição depois	Nativa, o composto já existe
Melhor para	Chamadas 1:1, consultas de telemedicina, reuniões pequenas	Reuniões, salas de aula, webinars, salas de áudio ao vivo	Interop com SIP/H.323 legado, broadcast, clientes fracos

Híbridos são comuns: P2P para 1:1, com upgrade para SFU quando entra o terceiro participante. Na dúvida, comece com um SFU; ele cobre a maior faixa de produtos sem exigir refazer a arquitetura depois. Sobre o transporte por baixo da sinalização, veja WebSockets vs Server-Sent Events.

STUN, TURN e por que TURN é obrigatório em produção

O ICE coleta candidatos host, server-reflexive (IP público descoberto via STUN) e relay (TURN), e os peers testam pares até um funcionar. STUN é barato e funciona quando os dois NATs cooperam. Falha atrás de NATs simétricos, da maioria dos firewalls corporativos, de algumas operadoras móveis e de qualquer rede que bloqueie UDP. Aí o único caminho é um relay via TURN.

Por que obrigatório: você não vai ver essas falhas em desenvolvimento. As redes do seu escritório e da sua casa conectam bem; uma parcela dos usuários reais, e uma parcela bem maior dos usuários corporativos, não. Sem TURN, essas chamadas ficam em "conectando" para sempre. Todo deploy sério roda TURN, normalmente com:

• coturn self-hosted, ou um relay gerenciado (Twilio Network Traversal, Cloudflare Calls TURN, Xirsys, Metered).
• TURN sobre TCP e TLS na porta 443 como fallback para redes que bloqueiam UDP por completo.
• Credenciais de curta duração geradas por sessão (o padrão REST API da especificação TURN: username = expiry:userId, senha = HMAC dessa string com um segredo compartilhado). Nunca embarque usuário e senha TURN estáticos no bundle do cliente; eles serão extraídos e usados como proxy gratuito.
• Posicionamento regional. Um único TURN em Frankfurt adiciona um round trip para usuários em São Paulo. Coloque os relays perto dos usuários.

Reserve orçamento: tráfego de relay é o único custo WebRTC que escala com o uso mesmo em arquiteturas P2P, e a fatia relayed é maior em ambientes corporativos.

Plataformas gerenciadas vs servidores de mídia self-hosted

Esta é a maior decisão de build vs buy em um projeto WebRTC. Plataformas gerenciadas vendem um SDK, uma frota global de SFUs, TURN e gravação, cobrados por minuto. Self-hosting significa rodar um SFU open source e pagar por computação e egress.

Opção	Tipo	Modelo	Pontos fortes	Fique atento a
LiveKit	SFU open source (Go) + LiveKit Cloud	Self-host ou gerenciado	SDKs modernos para web, iOS, Android, Flutter, React Native; simulcast, SVC, egress e ingress, framework de agentes para IA	Preço do Cloud em escala; self-hosting ainda exige infra de TURN e egress
mediasoup	SFU open source (biblioteca Node/C++)	Self-host	Excelente desempenho, controle fino, abstração enxuta	É biblioteca, não servidor: você escreve sinalização, salas, escala e gravação
Janus	Servidor open source de propósito geral (C)	Self-host	Maduro, arquitetura de plugins (video room, SIP, streaming), forte interop SIP	API mais antiga; escalar entre instâncias é problema seu
Jitsi	Stack open source completa de reuniões (Jitsi Videobridge, Prosody, cliente web)	Self-host ou 8x8 JaaS	Produto completo pronto para uso, bom para ferramentas internas de reunião	Customizar a UI a fundo é mais difícil do que construir sobre um SFU puro
Twilio Video	Gerenciado	Por participante-minuto	Boa documentação, PSTN e SIP no mesmo ecossistema	Custo em escala; roadmap de features irregular
Daily	Gerenciado	Por participante-minuto	UI pronta, primeira chamada rápida, gravação e transcrição embutidas	Lock-in via SDK; menos controle sobre o pipeline de mídia
Agora	Gerenciado	Por minuto, por faixa de resolução	Rede de borda global enorme, forte em mobile e regiões de banda baixa	Dúvidas de residência de dados para cargas na UE; preço complexo

Um jeito prático de decidir:

• Escolha gerenciado quando time to market importa mais que custo unitário, o uso é incerto, não há ninguém para operar infraestrutura de mídia, ou o vídeo é secundário no produto.
• Escolha self-hosted quando os minutos por mês são altos o suficiente para a cobrança por minuto dominar sua margem, quando residência de dados na UE ou deploy on-premise é exigência contratual, ou quando você precisa de controle sobre o pipeline de mídia (codecs customizados, processamento no servidor, agentes de IA na chamada).
• LiveKit é o meio-termo mais comum: comece no LiveKit Cloud e mantenha a opção de hospedar o mesmo servidor depois, sem reescrever os clientes.

Se for self-host, lembre que o servidor de mídia é uma carga stateful e pesada em banda: salas ficam presas a instâncias, o autoscaling segue banda e contagem de tracks, deploys rolling derrubam chamadas se não houver drain, e os pods precisam de host networking ou de uma faixa ampla de portas UDP.

Segurança: DTLS-SRTP é a parte fácil

A criptografia da mídia está resolvida: o WebRTC negocia DTLS entre os peers, deriva as chaves SRTP a partir dele e se recusa a enviar mídia sem criptografia. O fingerprint DTLS viaja no SDP, então a integridade do seu canal de sinalização é o que protege a mídia contra substituição. O resto é segurança de aplicação comum, em três superfícies:

Sinalização. Rode sobre WSS. Autentique a conexão com um token de curta duração emitido pelo seu provedor de identidade (veja OAuth 2.0, JWT e zero trust). Restrinja o token a uma sala e a um papel (publisher, subscriber, moderador). Valide toda mensagem no servidor; o que o cliente afirma sobre a sala em que está não é evidência. Aplique rate limit em joins e em trocas de offer/answer.

TURN. Credenciais HMAC efêmeras como descrito acima, com TTL de minutos, não de dias. Restrinja o relay à faixa de IP do seu servidor de mídia quando o SFU for o único peer com quem os clientes falam. Monitore contagem de alocações e bytes relayed por usuário para detectar abuso.

Servidor de mídia. Mantenha a API de controle do SFU fora da internet pública e emita tokens de sala do seu backend, nunca do cliente. Onde o servidor não pode ver a mídia (alguns casos de saúde e jurídicos), Insertable Streams / SFrame oferecem criptografia ponta a ponta, ao custo de perder gravação e transcrição no servidor.

O compliance decorre do mapa de dados: quem pode entrar, o que é gravado, onde e por quanto tempo. O guia de GDPR para empresas europeias cobre a documentação; no caso específico do WebRTC, trate endereços IP em candidatos ICE e logs de sinalização como dados pessoais.

Qualidade: simulcast, estimativa de banda e mobile

Qualidade de chamada é, em grande parte, um problema de gestão de banda. As ferramentas:

• Simulcast. O emissor codifica duas ou três resoluções; o SFU encaminha a camada que cada receptor consegue lidar. Sem isso, um participante em link lento derruba todo mundo. Habilite em todo publisher em chamadas em grupo.
• SVC com VP9 ou AV1 faz o mesmo com um único stream codificado e camadas temporais/espaciais. Mais eficiente, suporte de dispositivos mais restrito.
• Estimativa de banda. O controlador de congestionamento do navegador (TWCC) ajusta o bitrate do encoder continuamente, e o SFU troca camadas no downstream. Não brigue com ele: um maxBitrate fixo alto demais gera perda de pacotes; baixo demais gera vídeo borrado em redes boas.
• Áudio primeiro. Use Opus com forward error correction e DTX. Uma reunião sobrevive a vídeo ruim, não a áudio picotado.
• Mobile. Encoders de hardware variam, a bateria esgota rápido em 720p e a troca de Wi-Fi para celular exige tratamento de ICE restart. SDKs nativos cuidam da maior parte disso; um WebView, não. Teste em Android de entrada de verdade.
• Meça. Consulte getStats() periodicamente e envie round-trip time, jitter, perda de pacotes e camada selecionada para o seu analytics. Sem isso, não dá para distinguir "a rede estava ruim" de "a release estava ruim".

Gravação e compliance

Gravação parece feature; é componente de infraestrutura. Gravação por track (o SFU grava cada stream separadamente) é barata e flexível. Gravação composta (um navegador headless ou MCU renderiza a sala) entrega um arquivo pronto para reproduzir, ao custo de um worker de renderização por sala. Gravação no cliente (MediaRecorder) é frágil e depende de um upload grande depois.

O compliance define a escolha: consentimento exibido antes de a gravação começar, retenção aplicada por política, armazenamento na região que seus contratos exigem e acesso controlado como a própria chamada. Para setores regulados, veja regulamentos e segurança no desenvolvimento de aplicativos de saúde; o pipeline de gravação costuma ser o que entra no DPIA.

Um fluxo mínimo de sinalização

O protocolo entre dois peers e o seu servidor é pequeno. O que importa é ordenação e idempotência. Uma troca mínima sobre WebSocket:

A -> server: join { room, token }
B -> server: join { room, token }
server -> A: peer-joined { peerId: B, iceServers: [...TURN with ephemeral creds] }
A -> server: offer  { to: B, sdp }
server -> B: offer  { from: A, sdp }
B -> server: answer { to: A, sdp }
server -> A: answer { from: B, sdp }
A <-> server <-> B: ice-candidate { to, candidate }   (many, in both directions)

No cliente, a sequência do lado que faz a offer:

const pc = new RTCPeerConnection({ iceServers });
stream.getTracks().forEach((t) => pc.addTrack(t, stream));

pc.onicecandidate = ({ candidate }) => {
  if (candidate) ws.send(JSON.stringify({ type: "ice-candidate", to: peerId, candidate }));
};
pc.ontrack = ({ streams }) => (remoteVideo.srcObject = streams[0]);

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
ws.send(JSON.stringify({ type: "offer", to: peerId, sdp: pc.localDescription }));

ws.onmessage = async ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.type === "answer") await pc.setRemoteDescription(msg.sdp);
  if (msg.type === "ice-candidate") await pc.addIceCandidate(msg.candidate);
};

Dois detalhes causam a maioria dos bugs reais: candidatos ICE chegando antes de a remote description ser definida (enfileire-os) e os dois lados enviando offer ao mesmo tempo (glare; use o padrão perfect negotiation da especificação WebRTC). Com um SFU você não escreve nada disso: o SDK fala com o servidor e seu backend só emite tokens de sala.

Escopo de um projeto WebRTC: o que define custo e prazo

Times que buscam desenvolvimento WebRTC costumam pedir orçamento antes de ter uma arquitetura. Um punhado de variáveis define a estimativa, e elas pesam muito mais do que o tamanho da UI.

Variável	Extremo baixo	Extremo alto
Tamanho da sala	1:1	Salas grandes com paginação, active speaker, salas paralelas
Plataforma de mídia	SDK gerenciado	SFU self-hosted com autoscaling e frota de TURN
Clientes	Só web	Web + iOS + Android nativos, mais desktop
Gravação	Nenhuma	Gravação composta, transcrição, políticas de retenção
Interop	Nenhuma	Discagem SIP/PSTN, equipamentos de conferência legados
Compliance	GDPR padrão	DPIA de saúde/financeiro, dados só na UE, criptografia ponta a ponta
Observabilidade	Logs básicos	Dashboards de qualidade por chamada, alertas de taxa de sucesso de conexão
Extras	Chat via data channel	Compartilhamento de tela com anotações, whiteboard, agentes de IA na chamada

Ordem aproximada de esforço:

1. Chamadas 1:1 ou em grupo pequeno em plataforma gerenciada, só web. Semanas. A maior parte do trabalho é auth, ciclo de vida da sala e UI.
2. Chamadas em grupo com gravação em plataforma gerenciada, web e mobile. Alguns meses, com os testes em mobile como gargalo.
3. SFU self-hosted com TURN, gravação, observabilidade e compliance. Vários meses com time dedicado, mais operação após o lançamento. Faça teste de carga com participantes sintéticos antes do go-live; é aí que capacidade subdimensionada de TURN e SFU aparece.

O custo operacional é dominado por banda (egress do SFU, relay TURN), depois computação do servidor de mídia, depois armazenamento de gravações. Em plataforma gerenciada, modele a conta por minuto contra os minutos mensais esperados; o ponto em que o self-hosting compensa fica claro assim que você tem dados reais de uso. Para premissas de equipe e taxa horária, veja quanto custa desenvolver software personalizado na Europa. Nosso serviço de desenvolvimento de aplicações em tempo real cobre escopo e entrega desse tipo de sistema.

Checklist de decisão

Antes de escrever código, responda:

• Máximo de emissores de vídeo simultâneos por sala? Se mais de quatro, planeje um SFU.
• Plataforma gerenciada ou self-hosted? Decida por minutos mensais, residência de dados e capacidade do time.
• TURN: qual provedor, quais regiões, credenciais efêmeras emitidas pelo seu backend?
• Sinalização: transporte, validade do token de auth, escopo de sala e papel, tratamento de glare?
• Simulcast ou SVC habilitado em todos os publishers?
• Dispositivos-alvo: quais navegadores, mobile nativo ou WebView, qual o Android mais básico suportado?
• Gravação: por track, composta ou nenhuma; UI de consentimento; retenção; região de armazenamento?
• Criptografia ponta a ponta obrigatória? Se sim, aceite perder gravação e transcrição no servidor.
• Métricas: coleta de getStats, taxa de sucesso de conexão, tempo até o primeiro frame, fatia de relay?
• Interop: SIP/PSTN necessário agora ou depois?
• Plano de teste de carga com participantes sintéticos antes do lançamento?

Recomendação

Para um produto novo em 2026: construa sobre um SFU desde o primeiro dia, habilite simulcast e comece gerenciado (ou LiveKit Cloud), a menos que você já saiba que seus minutos tornam o self-hosting mais barato. Rode TURN com credenciais efêmeras desde o primeiro deploy. Emita todo token de sala do seu backend e mantenha a API de controle do SFU privada. Instrumente getStats antes de ter usuários. Na Arvucore, costumamos recomendar LiveKit para times que querem começar gerenciado com um caminho crível para self-hosting, e mediasoup ou Janus puros só quando o time tem capacidade interna de engenharia de mídia.