Passei seis anos construindo coisas em cima de WebRTC, e ainda acho que é uma das peças de infraestrutura web mais subestimadas por aí. Toda vez que você participa de uma chamada do Google Meet, compartilha sua tela no Discord, ou faz uma consulta de telemedicina pelo navegador -- WebRTC está fazendo o trabalho pesado. Mas a maioria dos desenvolvedores com quem converso a trata como uma caixa preta. Eles pegam uma biblioteca, conectam alguns manipuladores de eventos e torcem para dar certo.

Essa abordagem funciona até deixar de funcionar. E quando deixa -- quando as chamadas caem atrás de firewalls corporativos, quando a qualidade do vídeo cai em mobile, quando você não consegue descobrir por que há um atraso de dois segundos -- você realmente precisa entender o que está acontecendo por baixo. Então vamos abrir essa caixa.

Sumário

Como WebRTC Funciona em 2026: Uma Análise Profunda do Desenvolvedor

O Que É WebRTC, Realmente?

WebRTC (Web Real-Time Communication) é um conjunto de protocolos, APIs e padrões de código aberto que permite que navegadores e aplicativos móveis troquem áudio, vídeo e dados arbitrários em tempo real. O Google lançou originalmente o projeto em 2011, o W3C o padronizou em 2021, e em 2026 está incorporado em essencialmente todos os navegadores modernos -- Chrome, Firefox, Safari, Edge e seus equivalentes móveis.

A ideia-chave por trás de WebRTC é a comunicação ponto-a-ponto. Em vez de rotear sua videochamada através de um servidor central (o que adiciona latência e custa dinheiro), WebRTC tenta estabelecer uma conexão direta entre dois dispositivos. Seu laptop se comunica diretamente com o laptop do seu colega. O papel do servidor é mínimo -- ele apenas ajuda os dois pares a se encontrarem.

É claro, "tenta" está fazendo muito trabalho nessa frase. A realidade de NATs, firewalls e redes corporativas significa que conexões diretas nem sempre são possíveis. WebRTC tem um subsistema inteiro dedicado a resolver esse problema, que entraremos em detalhes.

Mas primeiro, os blocos de construção.

As Três APIs Principais

WebRTC expõe três principais APIs JavaScript. Entender o que cada uma faz é essencial antes de escrever uma única linha de código.

getUserMedia (MediaDevices API)

É assim que você acessa a câmera e o microfone. Ela retorna um objeto MediaStream contendo faixas de áudio e/ou vídeo.

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  },
  audio: {
    echoCancellation: true,
    noiseSuppression: true,
    autoGainControl: true
  }
});

Observe essas restrições de áudio. WebRTC lida com cancelamento de eco e supressão de ruído no nível do navegador -- você não precisa trazer seu próprio pipeline de processamento de áudio para casos de uso básicos. Em 2026, a supressão nativa de ruído do navegador ficou notavelmente boa, embora muitos aplicativos ainda utilizem modelos de IA por cima para obter melhores resultados.

Você também pode usar getDisplayMedia() para compartilhamento de tela, que segue o mesmo padrão mas solicita ao usuário que selecione uma tela, janela ou aberta.

RTCPeerConnection

Este é o cavalo de trabalho. RTCPeerConnection representa uma conexão entre seu dispositivo local e um peer remoto. Ele lida com:

  • Negociação de codec (quais formatos ambos os lados podem entender)
  • Coleta de candidatos ICE (descobrir caminhos de rede)
  • Handshake DTLS (criptografia)
  • Transporte de mídia SRTP (dados reais de áudio/vídeo)
  • Estimativa e adaptação de largura de banda
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:your-turn-server.com:443',
      username: 'user',
      credential: 'pass'
    }
  ]
});

// Adicionar faixas locais à conexão
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Lidar com faixas recebidas do peer remoto
pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0];
};

Um único RTCPeerConnection pode carregar múltiplas faixas de áudio e vídeo simultaneamente. Você não precisa de conexões separadas para áudio e vídeo.

RTCDataChannel

Este é frequentemente negligenciado, mas é incrivelmente útil. RTCDataChannel permite que você envie dados arbitrários entre pares -- mensagens de texto, pedaços de arquivo, estado do jogo, dados de sensores, o que você precisar.

const dataChannel = pc.createDataChannel('chat', {
  ordered: true,
  maxRetransmits: 3
});

dataChannel.onopen = () => {
  dataChannel.send(JSON.stringify({ type: 'message', text: 'Hello!' }));
};

dataChannel.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
};

Os canais de dados usam SCTP (Stream Control Transmission Protocol) sobre DTLS, e você pode configurá-los como ordenados ou desordenados, confiáveis ou não confiáveis. Para um recurso de chat, você deseja ordenado e confiável. Para estado de jogo em tempo real, você pode querer desordenado e não confiável para priorizar a atualidade sobre a completude.

Sinalização: A Parte Que WebRTC Não Lida

Aqui está o que confunde a maioria dos desenvolvedores quando eles encontram WebRTC pela primeira vez: a especificação deliberadamente não define como os pares se encontram um ao outro. WebRTC lida com tudo depois que dois pares sabem um do outro, mas a descoberta inicial -- chamada sinalização -- é deixada inteiramente a você.

A sinalização envolve a troca de dois tipos de informação:

  1. Descrições de sessão (SDP): Descrevem quais formatos de mídia, codecs e capacidades cada peer suporta.
  2. Candidatos ICE: São possíveis caminhos de rede que a conexão poderia usar.

A troca segue um modelo de oferta/resposta:

// Peer A cria uma oferta
const offer = await pcA.createOffer();
await pcA.setLocalDescription(offer);
// Enviar oferta para Peer B através de seu servidor de sinalização

// Peer B recebe a oferta e cria uma resposta
await pcB.setRemoteDescription(offer);
const answer = await pcB.createAnswer();
await pcB.setLocalDescription(answer);
// Enviar resposta de volta para Peer A

// Peer A recebe a resposta
await pcA.setRemoteDescription(answer);

Você pode implementar seu servidor de sinalização usando WebSockets, Server-Sent Events, poll HTTP, Firebase Realtime Database -- literalmente qualquer coisa que possa passar mensagens entre dois clientes. Já vi sistemas de produção usando tudo, desde Socket.io até APIs REST simples com polling.

O formato SDP em si é... bem, vamos ser honestos, é feio. É um formato de texto de décadas atrás que parece assim:

v=0
o=- 4611731400430051336 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 49170 RTP/SAVPF 111 103 104
a=rtpmap:111 opus/48000/2

Você raramente precisa analisar SDP manualmente, mas entender que ele carrega preferências de codec, parâmetros de criptografia e credenciais ICE ajuda enormemente ao depurar problemas de conexão.

Como WebRTC Funciona em 2026: Análise Profunda do Desenvolvedor - arquitetura

A Dança da Conexão: ICE, STUN e TURN

É aqui que WebRTC fica genuinamente inteligente -- e genuinamente complicado. O problema: a maioria dos dispositivos na internet fica atrás de NAT (Network Address Translation). Seu laptop não tem um endereço IP público. Nem seu telefone. Então, como dois dispositivos atrás de NATs diferentes falam um com o outro?

WebRTC usa um framework chamado ICE (Interactive Connectivity Establishment) para resolver isso.

STUN: Descobrindo Seu Endereço Público

Um servidor STUN (Session Traversal Utilities for NAT) é leve. Seu navegador envia uma solicitação para ele, e o servidor STUN responde com seu endereço IP e porta públicos -- o endereço como visto de fora. Pense nisso como perguntar a alguém na rua "qual é meu endereço?" quando você está dentro de um prédio.

Servidores STUN são baratos para operar e o Google fornece alguns gratuitos (como stun.l.google.com:19302). Eles não retransmitem nenhuma mídia -- eles apenas dizem a você qual é seu endereço virado para o público.

TURN: O Fallback de Retransmissão

Às vezes, conexões ponto-a-ponto diretas são simplesmente impossíveis. NATs simétricos, firewalls corporativos e certas configurações de operadores móveis bloqueiam conexões diretas. Quando isso acontece, você precisa de um servidor TURN (Traversal Using Relays around NAT).

Um servidor TURN realmente retransmite todo o tráfego de mídia entre pares. Isso significa:

  • Latência mais alta (o tráfego passa pelo relay em vez de diretamente)
  • Custos de banda mais altos (você está pagando todo esse tráfego de vídeo)
  • Mas funciona quando nada mais funciona

Em produção, aproximadamente 10-20% das conexões requerem retransmissão TURN, dependendo de sua base de usuários. Usuários corporativos atrás de firewalls corporativos atingem esse número muito mais -- às vezes 40-60%. Você deve executar servidores TURN se quiser WebRTC confiável em produção. Não posso enfatizar isso o suficiente. Vi startups lançar sem TURN e depois se perguntarem por que um quarto de seus usuários não consegue se conectar.

O Processo de Coleta de Candidatos ICE

Quando você cria um RTCPeerConnection, o ICE começa a coletar candidatos -- possíveis rotas de rede. Ele coleta três tipos:

Tipo de Candidato Fonte Latência Custo
Host Interface de rede local Mais baixa (apenas LAN) Gratuito
Server Reflexive (srflx) Descoberto via STUN Baixa Mínimo (STUN é barato)
Relay Alocado no servidor TURN Mais alta Significativo (custos de banda)

O ICE então testa esses candidatos em ordem de prioridade, tentando as opções mais rápidas primeiro. Se um candidato host funcionar (ambos os peers na mesma LAN), ótimo. Se não, ele tenta endereços descobertos por STUN. Se aqueles falharem, ele recua para retransmissão TURN.

Tudo isso acontece automaticamente, mas você pode observar:

pc.onicecandidate = (event) => {
  if (event.candidate) {
    console.log('New ICE candidate:', event.candidate.type);
    // Enviar este candidato para o peer remoto via sinalização
  }
};

pc.oniceconnectionstatechange = () => {
  console.log('ICE state:', pc.iceConnectionState);
  // Estados: new -> checking -> connected -> completed
  // Ou: new -> checking -> failed (uh oh)
};

Como a Mídia Flui de Verdade

Uma vez que o ICE estabelece um caminho, a mídia flui sobre RTP (Real-time Transport Protocol), especificamente SRTP (Secure RTP) já que WebRTC exige criptografia.

Aqui está o fluxo simplificado:

  1. A câmera captura um quadro
  2. O codificador o comprime usando o codec negociado (VP8, VP9, H.264 ou AV1)
  3. O quadro comprimido é dividido em pacotes RTP
  4. Cada pacote é criptografado com SRTP
  5. Os pacotes são enviados sobre UDP (geralmente) para o peer remoto
  6. O peer remoto descriptografa, remonta e decodifica o quadro
  7. O quadro é renderizado em um elemento <video>

Isso acontece 30 vezes por segundo para vídeo. Para áudio (tipicamente codec Opus), é cerca de 50 pacotes por segundo.

WebRTC usa UDP em vez de TCP para transporte de mídia. TCP garante entrega retransmitindo pacotes perdidos, o que soa bem até você perceber que um quadro de vídeo retransmitido de 500ms atrás é pior que inútil -- é ativamente prejudicial porque atrasa quadros mais novos. UDP deixa WebRTC priorizar a oportunidade sobre a completude, que é exatamente o que você quer para mídia em tempo real.

RTCP: O Loop de Feedback

Ao lado de RTP, WebRTC usa RTCP (RTP Control Protocol) para trocar estatísticas entre pares. Cada lado relata:

  • Taxa de perda de pacotes
  • Jitter (variância no tempo de chegada de pacotes)
  • Tempo de ida e volta
  • Estimativas de banda disponível

Esse feedback impulsiona o sistema de taxa de bits adaptativa, que cobriremos em seguida.

Codecs e Taxa de Bits Adaptativa em 2026

WebRTC suporta múltiplos codecs, e o cenário mudou significativamente nos últimos anos.

Codecs de Vídeo

Codec Suporte do Navegador (2026) Eficiência de Compressão Uso de CPU Notas
VP8 Universal Baseline Baixo Legado, mas ainda o codec obrigatório
VP9 Universal ~30% melhor que VP8 Médio Ótimo equilíbrio para a maioria dos casos
H.264 Universal Similar a VP8 Baixo (acelerado por hardware) Necessário para interop histórico com Safari
AV1 Chrome, Firefox, Safari 18+ ~30% melhor que VP9 Alto (melhorando) O futuro, mas o custo de CPU ainda importa em mobile

A adoção de AV1 acelerou em 2026. O suporte de codificação de hardware em dispositivos mais novos (Apple M4, chips Qualcomm Snapdragon recentes) resolveu a maior reclamação -- uso de CPU. Para novos projetos, eu padrionizaria VP9 com AV1 como uma opção preferida quando ambos os pares o suportam.

Codecs de Áudio

Opus é rei. É o codec de áudio obrigatório para WebRTC desde o início, e com razão -- ele lida com tudo, desde voz em banda estreita até música em banda completa, se adapta a condições de rede em mudança e tem excelente ocultação de erros. Você raramente precisará pensar em codecs de áudio.

Taxa de Bits Adaptativa

Este é um dos melhores recursos do WebRTC e acontece automaticamente. O remetente monitora continuamente as condições da rede via feedback RTCP e ajusta a taxa de bits de codificação em tempo real.

Quando a banda cai (digamos que você entra em um elevador com seu telefone), WebRTC vai:

  1. Reduzir a resolução do vídeo
  2. Diminuir a taxa de quadros
  3. Aumentar a compressão (reduzindo a qualidade)

Quando as condições melhoram, ele escala de volta. O algoritmo de controle de congestão do Google (GCC) lida com isso, e em 2026 foi refinado ao ponto de reagir em segundos a mudanças de rede. Você não precisa implementar nada disso -- está incorporado na pilha WebRTC do navegador.

Modelo de Segurança: Criptografia por Padrão

WebRTC foi projetado com criptografia obrigatória. Não há como desabilitá-la. Cada conexão WebRTC usa:

  • DTLS (Datagram Transport Layer Security): Lida com troca de chaves. Pense nisso como TLS mas para UDP.
  • SRTP (Secure Real-time Transport Protocol): Criptografa os pacotes de mídia reais usando chaves derivadas do handshake DTLS.

Para canais de dados, a criptografia é DTLS sobre SCTP.

Isso significa que mesmo se alguém interceptar os pacotes (como seu ISP ou alguém na mesma rede Wi-Fi), ele não consegue decodificar o conteúdo de áudio ou vídeo. A criptografia é de ponta a ponta entre pares -- com uma ressalva importante.

Se você estiver usando um servidor de retransmissão TURN, o servidor TURN pode ver os pacotes criptografados mas não consegue descriptografá-los. A criptografia termina nos pares, não no relay. No entanto, se você estiver usando um SFU (Selective Forwarding Unit) para chamadas em grupo -- que a maioria dos sistemas de produção faz -- o SFU tradicionalmente precisa descriptografar e criptografar novamente a mídia. É aqui que Insertable Streams (agora disponível em todos os navegadores principais em 2026) se torna importante, permitindo criptografia de ponta a ponta mesmo através de um SFU deixando você adicionar uma camada de criptografia adicional que o SFU não consegue retirar.

WebRTC vs. WebTransport vs. VoIP Tradicional

Perguntam sobre isso constantemente, então vamos delinear.

Funcionalidade WebRTC WebTransport VoIP Tradicional (SIP)
Transporte UDP (principalmente) QUIC (HTTP/3) UDP/TCP
Ponto-a-ponto Sim Não (cliente-servidor) Sim (em teoria)
Nativo no navegador Sim Sim Não (precisa de softphone/plugin)
Tratamento de mídia Incorporado DIY Incorporado
Criptografia Obrigatória (DTLS/SRTP) Obrigatória (TLS 1.3) Opcional (SRTP se configurado)
Canais de dados Sim (SCTP) Sim (fluxos QUIC) Não
Travessia NAT ICE/STUN/TURN Não necessária (baseado em servidor) STUN/TURN ou SBC
Latência Sub-segundo Sub-segundo Sub-segundo
Melhor para Chamadas P2P, conferências Streaming unidirecional, jogos Telefonia corporativa

WebTransport, construído sobre QUIC/HTTP/3, ganhou tração em 2026 para casos de uso específicos -- particularmente streaming unidirecional ao vivo onde você não precisa de todo o maquinário ponto-a-ponto. Não está substituindo WebRTC; é complementar. Se você estiver construindo videochamadas bidirecionais, WebRTC ainda é a escolha certa. Se você estiver construindo uma plataforma de transmissão onde uma fonte transmite para milhares, WebTransport (ou Media over QUIC, que se baseia nele) vale a pena avaliar.

VoIP tradicional baseado em SIP não vai embora, especialmente em empresas com infraestrutura PBX existente. Muitos sistemas de produção em 2026 executam gateways WebRTC-para-SIP para conectar clientes baseados em navegador com sistemas telefônicos tradicionais.

O Que Mudou em 2026

WebRTC em 2026 não é radicalmente diferente de WebRTC em 2023, mas vários desenvolvimentos importam:

Integração de IA Ficou Mainstream

Recursos de IA em tempo real agora rodam diretamente em fluxos WebRTC:

  • Supressão de ruído de fundo além do que os navegadores oferecem nativamente (ferramentas como Krisp ou modelos incorporados no Google Meet)
  • Transcrição e tradução em tempo real durante chamadas
  • Agentes de voz IA que participam de chamadas WebRTC como pares, lidando com atendimento ao cliente ou resumos de reuniões
  • Análise de sentimento em fluxos de áudio para aplicações de call center

O transporte de baixa latência que WebRTC oferece é exatamente o que esses modelos de IA precisam. Você não consegue rodar transcrição em tempo real em um fluxo com dois segundos de atraso.

Codificação de Hardware AV1 é Real

Mencionei isso na seção de codecs, mas merece repetição. O suporte de codificador de hardware AV1 em chips mais novos a tornou prática para uso em tempo real. Você obtém uso de CPU no nível VP9 com 30% melhor compressão. Para cenários com restrição de banda (mobile, mercados em desenvolvimento), isso é importante.

Maturidade da API WebCodecs

A API WebCodecs permite que você acesse o codificador/decodificador incorporado do navegador sem passar pela pilha WebRTC completa. Isso é útil quando você precisa de controle de baixo nível -- pipelines de processamento de vídeo customizados, codificação para gravação enquanto transmite, ou alimentação de quadros em modelos de ML. Funciona bem com Insertable Streams do WebRTC para processamento customizado.

Paridade de Navegador Melhorada

Safari foi historicamente o problema filho para WebRTC. Em 2026, Safari 18+ fechou a maioria das lacunas -- simulcast funciona adequadamente, Insertable Streams são suportados e decodificação AV1 está disponível. Você ainda precisa testar em navegadores, mas os dias de escrever workarounds específicos do Safari estão em grande parte atrás de nós.

Construindo Com WebRTC: Considerações Práticas

Se você estiver construindo um produto que usa WebRTC, aqui está o que eu pensaria:

Não Implemente Seu Próprio SFU (Provavelmente)

Para chamadas 1:1, peer-to-peer direto é bom. Para chamadas em grupo com mais de 3-4 participantes, você precisa de uma Selective Forwarding Unit. Construir uma do zero é um trabalho sério. Considere opções de código aberto como mediasoup, Janus ou Pion (baseado em Go), ou serviços gerenciados como Twilio, Daily.co, LiveKit ou Agora.

Orçamento para Servidores TURN

Use coturn (código aberto) ou um serviço TURN gerenciado. Execute TURN na porta 443/TCP como fallback -- alguns firewalls corporativos bloqueiam tudo, exceto portas HTTP/HTTPS. Orçamento de $200-500/mês para uma implantação modesta; a banda de retransmissão de vídeo se acumula rapidamente.

Teste em Redes Reais

WebRTC funciona lindamente em localhost. Falha de maneiras interessantes em Wi-Fi congestionado, redes móveis e atrás de proxies corporativos. O chrome://webrtc-internals do Chrome é seu melhor amigo para depuração -- mostra coleta de candidatos ICE, negociação de codec, estimativas de banda e perda de pacotes em tempo real.

Considere Sua Arquitetura Frontend

Se você estiver construindo um aplicativo web que inclui recursos WebRTC, a estrutura frontend importa. Construímos recursos de colaboração em tempo real em aplicações Next.js onde canais de dados WebRTC alimentam cursores ao vivo e estado compartilhado. Para sites com conteúdo denso com recursos ocasionais em tempo real, a arquitetura de ilhas do Astro permite carregar código WebRTC apenas quando necessário, mantendo o bundle inicial enxuto.

Se você precisar de uma solução WebRTC customizada integrada com um headless CMS -- digamos, para uma plataforma de telemedicina ou site de comércio ao vivo -- esse é o tipo de projeto onde acertar a arquitetura desde o início economiza meses de dor depois. Sinta-se à vontade para nos contatar se quiser conversar sobre sua configuração específica.

FAQ

WebRTC funciona sem um servidor de jeito nenhum?

Não exatamente. Você sempre precisa de um servidor de sinalização para ajudar os pares a trocar informações de conexão (ofertas/respostas SDP e candidatos ICE). Você também precisará no mínimo de um servidor STUN para travessia NAT, e realistically um servidor TURN para confiabilidade. Mas a mídia real pode fluir ponto-a-ponto sem tocar seus servidores.

Por que as conexões WebRTC às vezes falham atrás de firewalls corporativos?

Firewalls corporativos frequentemente bloqueiam tráfego UDP e restringem conexões de saída apenas às portas 80 e 443. Como WebRTC usa principalmente UDP em portas dinâmicas, isso pode prevenir conexões diretas e até bloquear STUN. A correção é executar um servidor TURN na porta 443 com TCP, que parece tráfego HTTPS regular ao firewall. Por isso a infraestrutura TURN é inegociável para implantações corporativas.

Como WebRTC lida com condições de rede ruins ou flutuantes?

WebRTC usa codificação de taxa de bits adaptativa. Monitora continuamente perda de pacotes, jitter e banda disponível através de feedback RTCP, e ajusta a qualidade de codificação em tempo real. Em uma conexão ruim, você verá resolução e taxa de quadros mais baixas em vez de vídeo congelado. O algoritmo de controle de congestão do Google (GCC) gerencia isso automaticamente -- você não precisa implementá-lo.

WebRTC consegue escalar para centenas ou milhares de espectadores?

Não com pure peer-to-peer -- cada participante precisaria de uma conexão direta com todos os outros. Para grupos grandes (mais de ~4 pessoas), você precisa de uma Selective Forwarding Unit (SFU) que recebe o fluxo de cada participante e o encaminha para todos os outros. Para transmissão para milhares, você emparelharia ingestão WebRTC com um CDN ou usaria uma plataforma de streaming baseada em WebRTC que lida com fan-out.

WebRTC é criptografado? Meu ISP pode ver minhas videochamadas?

Sim, toda mídia WebRTC é criptografada usando DTLS para troca de chaves e SRTP para transporte de mídia. Essa criptografia é obrigatória -- você literalmente não consegue desabilitá-la. Seu ISP pode ver que você está fazendo uma conexão WebRTC e quanto de dados está fluindo, mas não consegue decodificar o conteúdo de áudio ou vídeo real.

Qual é a diferença entre WebRTC e WebSockets para recursos em tempo real?

WebSockets são baseados em TCP e projetados para entrega confiável e ordenada de mensagens -- ótimo para chat, notificações e sinalização. WebRTC usa UDP para transporte de mídia, priorizando baixa latência sobre entrega garantida, e suporta conexões ponto-a-ponto. Use WebSockets para seu servidor de sinalização e recursos em tempo real baseados em texto; use WebRTC quando você precisa de áudio, vídeo ou canais de dados de baixa latência.

Devo usar WebRTC ou WebTransport para meu projeto de streaming em 2026?

Depende da direção da comunicação. Para streaming interativo bidirecional (videochamadas, telemedicina, comércio ao vivo com interação de público), WebRTC é a escolha clara. Para streaming de transmissão um-para-muitos onde sub-segundo de latência importa mas a interatividade é limitada, WebTransport (e o padrão emergente Media over QUIC) vale a pena avaliar. Muitas plataformas usam ambos -- WebRTC para ingestão e interação, WebTransport ou HLS/DASH para distribuição em larga escala.

Que hardware/banda eu preciso para videochamadas WebRTC?

Para uma videochamada 720p, espere aproximadamente 1.5-2 Mbps upload e download por participante. 1080p empurra isso para 2.5-4 Mbps. Qualquer dispositivo moderno (laptop, telefone, tablet dos últimos 5 anos) tem CPU suficiente para WebRTC. O gargalo é quase sempre qualidade de rede -- particularmente banda de upload e estabilidade de rede -- em vez de poder de processamento.