WebRTC e WebSocket aparecem juntos quando um time começa a desenhar agentes de voz, mas eles resolvem problemas diferentes. WebRTC é o caminho natural para mídia em tempo real no navegador, com áudio, vídeo, negociação de rede e baixa latência. WebSocket é uma conexão persistente com o servidor, boa para eventos, comandos e fluxos em que o backend precisa controlar a conversa.
A escolha não deveria partir de preferência por API. Ela deve partir de onde o áudio nasce, onde a lógica roda, quem pode ver credenciais, qual latência é aceitável e que tipo de controle o servidor precisa manter.
Quando WebRTC é o melhor ponto de partida
A documentação da MDN sobre WebRTC descreve a tecnologia como um conjunto de APIs e protocolos para capturar e transmitir áudio, vídeo e dados sem exigir plugin. Em um agente de voz no navegador, isso importa porque o usuário fala no cliente e espera resposta imediata.
WebRTC costuma fazer mais sentido quando a experiência é interativa e sensível a latência: atendimento por voz no browser, tutoria, colaboração, chamada com assistente ou interface em que interrupção natural é parte do produto. Ele também lida com conceitos próprios de mídia, como tracks, conexão, codecs, ICE, estatísticas e estados da sessão.
Quando WebSocket é suficiente
A MDN define WebSocket como uma API para criar e gerenciar conexão com um servidor, enviando e recebendo dados por essa conexão. Em agentes de voz, isso é útil quando o servidor é o ponto central: telefonia, integração com um provedor externo, automação interna, streams de eventos, logs e comandos de controle.
WebSocket é mais simples de observar no backend, mas não transforma áudio em uma experiência de mídia por si só. O time precisa definir framing, filas, reconexão, limites de payload e tratamento de backpressure. A própria MDN alerta que a API WebSocket tradicional não aplica backpressure automaticamente, então mensagens chegando mais rápido que o processamento podem estourar memória ou CPU.
O desenho híbrido é comum
Em muitos produtos, WebRTC e WebSocket coexistem. WebRTC cuida da mídia do usuário no navegador. WebSocket ou HTTP cuidam de eventos administrativos, estado de sessão, telemetria, histórico, autorização e comandos do backend. Essa separação evita misturar áudio sensível a latência com operações que podem tolerar alguns milissegundos a mais.
A documentação da Realtime API da OpenAI descreve um fluxo em que a sessão conecta por WebRTC no navegador ou por WebSocket no servidor. Esse exemplo mostra a diferença de fronteira: cliente precisa de credencial efêmera e transporte de mídia; servidor precisa de controle, política, logs e integração com ferramentas.
Critérios para decidir
Use WebRTC quando o cliente precisa capturar áudio ao vivo, reduzir latência percebida, lidar com interrupção e manter uma sessão de mídia rica. Use WebSocket quando o tráfego principal é evento, comando, transcrição, controle de ferramenta ou comunicação servidor-servidor.
Também olhe para operação. WebRTC exige entender negociação de rede, TURN/STUN, estatísticas de qualidade e diferenças de navegador. WebSocket exige disciplina de protocolo, versionamento de eventos, limite de fila, reconexão e proteção contra mensagens em excesso.
O que não deve ficar no cliente
Mesmo quando WebRTC roda no navegador, a credencial permanente e a decisão de executar ações sensíveis devem ficar no backend. O cliente pode receber uma credencial efêmera para sessão de voz, mas autorização de ferramenta, acesso a dados internos e confirmação de ações precisam de controle do servidor.
O post sobre GPT-Live-1 na API mostra por que essa distinção importa. Voz natural aumenta fluidez, mas a arquitetura continua responsável por separar mídia, intenção, ferramenta, permissão e auditoria.
