WebRTC, SFUs e codecs de voz explicados
Como o WebRTC transporta áudio, como o Opus comprime a voz e quando o vídeo em grupo precisa de um SFU. Guia para devs com a arquitetura do Voxal e RFCs.
O WebRTC transporta áudio e vídeo entre navegadores, um codec como o Opus comprime a voz para que ela caiba na rede, e uma Selective Forwarding Unit (SFU) é um servidor que encaminha o vídeo de cada participante para todos os outros em chamadas maiores. Essas três peças explicam a maior parte do que acontece entre um microfone e um alto-falante remoto.
Este guia é para desenvolvedores e curiosos que querem entender a mecânica: sinalização, ICE, STUN e TURN, RTP, Opus e o trade-off entre uma malha peer-to-peer e um SFU. Ele termina mostrando como o Voxal combina tudo isso: a voz continua peer-to-peer, enquanto a câmera e o compartilhamento de tela podem usar um SFU. Se você só quer entender o conceito, comece por o que é chat de voz peer-to-peer.
1. O que é WebRTC?
O WebRTC é um conjunto de padrões e APIs de navegador para comunicação em tempo real de áudio, vídeo e dados.
Ele permite que aplicações estabeleçam conexões de mídia entre dispositivos compatíveis sem que os desenvolvedores precisem implementar do zero cada mecanismo de transporte e de segurança.
O WebRTC não é um único protocolo. Vários componentes trabalham juntos.
Sinalização
Antes que dois dispositivos possam estabelecer uma conexão de mídia, eles precisam trocar informações sobre a sessão e sobre suas capacidades de conexão.
Esse processo se chama sinalização. Cada aplicação escolhe seu próprio mecanismo de sinalização; o WebRTC não prescreve um servidor ou protocolo de sinalização universal.
O Voxal usa a sinalização para coordenar a participação nas salas e o estabelecimento das conexões. O caminho da sinalização é separado do caminho da mídia.
ICE, STUN e TURN
Os dispositivos costumam ficar atrás de roteadores, firewalls ou tradução de endereços de rede (NAT). Descobrir um caminho de conexão viável pode, portanto, ser bem mais complicado do que conectar dois endereços IP públicos.
O WebRTC usa o Interactive Connectivity Establishment (ICE) para reunir e testar os caminhos de conexão possíveis.
- O STUN ajuda um dispositivo a descobrir como ele aparece na rede pública.
- O TURN oferece um caminho de retransmissão quando não é possível estabelecer uma conexão direta adequada.
Um relay TURN encaminha tráfego de mídia criptografado. Ele não é a mesma coisa que um SFU, que encerra as conexões de mídia e encaminha seletivamente os fluxos de mídia.
Uma conexão direta costuma ser desejável, mas um relay pode ser essencial para a conectividade.
RTP e transporte seguro de mídia
A mídia em tempo real é comumente transportada com o Real-time Transport Protocol (RTP), junto com o RTCP para controle e relatórios.
O WebRTC usa o RTP seguro (SRTP) para proteger a mídia. A camada de transporte ajuda a entregar os pacotes, enquanto o codec determina como o próprio áudio ou vídeo é representado.
São responsabilidades distintas: um codec não estabelece uma conexão de rede, e uma conexão de rede não determina como o som é comprimido.
2. O que é um codec de voz?
Um codec codifica e decodifica mídia. Na comunicação por voz, a função dele é representar a fala de forma eficiente, preservando a inteligibilidade e uma qualidade de áudio aceitável.
Sem compressão, transmitir áudio bruto pode consumir muito mais banda do que um aplicativo de voz precisa.
Um codec faz um trade-off entre vários fatores:
- Qualidade do áudio e inteligibilidade da fala.
- Taxa de bits e uso de banda.
- Complexidade de codificação e decodificação.
- Atraso e duração dos quadros.
- Comportamento sob condições de rede variáveis.
Não existe um codec melhor para todas as aplicações. Streaming de música, chamadas telefônicas, chat de jogos e conversas em grupo em tempo real têm prioridades diferentes.
Por que o Opus é tão usado
O Opus é um codec de áudio interativo projetado para aplicações como voz sobre IP, videoconferência e chat dentro de jogos.
Ele suporta uma ampla faixa de taxas de bits, taxas de amostragem e durações de quadro. Essa flexibilidade o torna adequado tanto para fala quanto para aplicações de áudio mais exigentes.
O Opus também é um codec de áudio de implementação obrigatória para endpoints WebRTC, segundo os requisitos de codecs de áudio do WebRTC.
Isso não significa que toda conexão WebRTC use sempre o Opus. A escolha real do codec depende das capacidades negociadas entre os endpoints participantes.
No Voxal, o pipeline de áudio WebRTC do navegador usa o Opus por padrão na arquitetura documentada. O navegador cuida de grande parte do trabalho de codificação, transporte e decodificação.
Em um aplicativo de voz em tempo real, o codec é apenas uma parte da experiência. A qualidade do microfone, o processamento de áudio, a perda de pacotes, a latência de rede, o jitter buffer e a reprodução no dispositivo também importam.
3. O que é um SFU?
SFU significa Selective Forwarding Unit.
Um SFU é um servidor de mídia muito usado para dar suporte a chamadas de vídeo em grupo. Em vez de exigir que cada participante envie um fluxo de vídeo separado diretamente a todos os outros, cada participante pode enviar sua mídia ao SFU, que encaminha os fluxos apropriados aos demais.
Imagine uma sala com seis pessoas, cada uma enviando um fluxo de câmera.
Em uma malha peer-to-peer completa, cada participante pode precisar enviar seu vídeo para outros cinco. Em uma topologia com encaminhamento por servidor, cada participante pode enviar um único fluxo ao SFU, que cuida da distribuição.
Isso pode reduzir significativamente o número de fluxos de vídeo de saída que cada participante precisa manter.
O que um SFU realmente faz?
Um SFU normalmente recebe fluxos de mídia codificados e os encaminha de forma seletiva. Dependendo da implementação e dos recursos negociados, ele pode escolher quais fluxos ou camadas de qualidade enviar a cada receptor.
Por exemplo, um participante que vê uma miniatura pequena pode não precisar da mesma qualidade de vídeo de quem exibe um orador em tela cheia.
Um SFU ajuda a gerenciar essas necessidades diferentes sem que cada emissor transmita, por conta própria, um fluxo separado para cada destinatário.
No entanto, um SFU não é gratuito. Ele traz infraestrutura, banda de servidor, custos operacionais e mais um componente no caminho da mídia.
Um SFU também tem um modelo de privacidade diferente do de um relay TURN. Como o SFU encerra o transporte de mídia e encaminha a mídia de forma seletiva, ele pode, tecnicamente, acessar a mídia que recebe. A criptografia entre um participante e um SFU não oferece, por si só, confidencialidade de ponta a ponta em relação a esse SFU.
4. Malha peer-to-peer vs. SFU
As duas arquiteturas resolvem problemas relacionados, mas diferentes.
Malha peer-to-peer
Cada participante estabelece conexões de mídia com os outros participantes.
Vantagens:
- Caminhos de mídia diretos são possíveis.
- Não é necessário um servidor central de mídia para redistribuir o conteúdo.
- Salas pequenas funcionam sem um serviço de encaminhamento de mídia.
Trade-offs:
- Cada emissor pode precisar enviar um fluxo separado a todos os outros participantes.
- O número de conexões de mídia cresce junto com a sala.
- A banda de upload e o gerenciamento das conexões podem virar fatores limitantes.
Distribuição baseada em SFU
Cada participante envia a mídia a um serviço central de encaminhamento, que a distribui aos demais.
Vantagens:
- Distribuição mais eficiente em muitos cenários de vídeo em grupo.
- Menos necessidade de cada emissor enviar cópias separadas a cada destinatário.
- Mais controle sobre quais fluxos de vídeo e camadas de qualidade os receptores recebem.
Trade-offs:
- Infraestrutura de servidor adicional e custos de banda.
- Um intermediário entra no caminho da mídia.
- O modelo de privacidade e confiança difere da comunicação peer-to-peer direta.
O ponto principal é não presumir que uma única topologia deva ser usada para todos os tipos de mídia. Áudio e vídeo têm padrões de tráfego e requisitos diferentes.
5. Por que o Voxal mantém a voz peer-to-peer, mas pode usar um SFU para vídeo
O Voxal separa o áudio de voz do vídeo da câmera e do compartilhamento de tela.
O áudio de voz sempre permanece peer-to-peer. Ele nunca passa pelo SFU de vídeo opcional.
Essa é uma decisão de arquitetura deliberada: a voz é o recurso central de comunicação, e o Voxal não usa o SFU como serviço central de distribuição de áudio.
O vídeo da câmera e do compartilhamento de tela é diferente. Em salas maiores, uma malha peer-to-peer completa pode exigir que cada participante envie vários fluxos de vídeo. Isso fica cada vez mais pesado conforme o número de participantes cresce.
Por isso, o Voxal pode usar o Realtime SFU da Cloudflare para vídeo e compartilhamento de tela quando a preferência de roteamento configurada permitir e a sala ultrapassar os limites práticos da malha.
A preferência de roteamento importa:
- Permitir relay em salas grandes: o Voxal pode usar o SFU quando a sala cresce além de uma topologia de vídeo peer-to-peer confortável.
- Preferir conexão direta: o Voxal tenta primeiro o peer-to-peer e pergunta antes de permitir um relay quando a malha deixa de ser adequada.
- Somente direta: o vídeo e o compartilhamento de tela nunca usam o SFU, mesmo que uma sala grande tenha dificuldade para estabelecer todas as conexões diretas.
Essas configurações afetam o vídeo e o compartilhamento de tela, não o áudio de voz.
Por que não passar tudo pelo mesmo servidor?
Porque a melhor topologia depende do tráfego que está sendo transportado.
Um fluxo de voz costuma ser muito menor que um fluxo de câmera. Enviar a voz por um serviço central de encaminhamento traria um trade-off diferente de infraestrutura e privacidade, sem ser necessário para a arquitetura de voz escolhida pelo Voxal.
O vídeo tem um perfil de banda mais exigente e pode se beneficiar bastante da distribuição assistida por servidor à medida que o grupo cresce.
Separar os dois permite que o Voxal mantenha seu modelo de voz peer-to-peer e, ao mesmo tempo, ofereça uma opção mais escalável para vídeo em grupo.
6. O que isso significa para a privacidade
Termos de rede às vezes são usados como se garantissem automaticamente um certo nível de privacidade. Não garantem.
Áudio peer-to-peer significa que a mídia de voz não passa por um servidor central de mídia, mas os servidores de sinalização ainda podem coordenar as conexões e processar metadados associados.
Um relay TURN encaminha mídia criptografada sem decodificá-la. Já um SFU encerra o transporte de mídia para encaminhar fluxos de forma seletiva e, tecnicamente, pode acessar o vídeo que recebe.
É por isso que a distinção do Voxal importa:
- A voz continua peer-to-peer, usando opcionalmente um relay TURN criptografado.
- O vídeo da câmera e do compartilhamento de tela pode usar um SFU em salas maiores, dependendo da preferência de roteamento.
- O processamento local de fundo virtual acontece no dispositivo de quem envia, mas isso, por si só, não significa que toda conexão de vídeo seja direta.
Entender o caminho real da mídia é mais útil do que simplesmente descrever um aplicativo como "sem servidor".
7. Juntando tudo
Um aplicativo de comunicação em tempo real combina várias camadas independentes:
- A sinalização coordena os participantes e a configuração da conexão.
- ICE, STUN e TURN ajudam a estabelecer um caminho de rede viável.
- O WebRTC e o transporte RTP seguro transportam a mídia em tempo real.
- Um codec como o Opus representa o áudio de forma eficiente.
- A topologia de rede determina se a mídia flui diretamente entre os pares ou por um serviço de encaminhamento.
O design do Voxal aplica essas escolhas separadamente à voz e ao vídeo. O resultado é uma arquitetura voltada à voz, na qual o áudio permanece peer-to-peer, enquanto o vídeo e o compartilhamento de tela podem usar um encaminhamento opcional assistido por servidor quando salas maiores precisam.
Essas distinções são importantes ao projetar qualquer sistema de comunicação em tempo real. O objetivo não é simplesmente minimizar servidores ou maximizar conexões diretas, e sim fazer trade-offs deliberados entre latência, banda, confiabilidade, escalabilidade e privacidade.
Experimente o Voxal
O Voxal combina chat de voz peer-to-peer, push-to-talk (pressionar para falar), modo mãos livres, supressão de ruído e vídeo e compartilhamento de tela opcionais.
Experimente o Voxal no navegador ou explore a implementação no repositório open source do Voxal.
Leitura relacionada: O que é chat de voz peer-to-peer? · O que é push-to-talk? Um guia prático · Documentação de roteamento de vídeo do Voxal
