WebRTC vs WebSocket para IA de voz em tempo real

WebSocket e WebRTC mantêm uma conexão aberta para que o áudio flua nos dois sentidos sem uma nova requisição a cada trecho. A diferença está no que acontece quando a rede falha. Um WebSocket roda sobre TCP, então cada byte chega em ordem, mesmo que isso signifique esperar. O WebRTC costuma rodar sobre UDP e foi feito para mídia, então descarta ou disfarça um pacote atrasado e continua tocando.

Num agente de voz, essa diferença decide onde cada um entra. O WebRTC é para o trecho entre o dispositivo de uma pessoa e seus servidores, onde Wi-Fi e redes móveis perdem pacotes. O WebSocket é para os trechos entre servidores, onde isso não acontece, e para tudo o que precisa de um fluxo de mensagens simples e ordenado. A maioria dos agentes de voz em produção usa os dois.

Este guia é para engenheiros que escolhem o transporte de um agente de voz ou de um recurso de voz em tempo real. Ele explica como cada protocolo funciona, a comparação que importa para áudio e as arquiteturas que as equipes de fato colocam em produção.

WebRTC vs WebSocket num relance

Como funciona um WebSocket

Um WebSocket começa como uma requisição HTTP comum com um cabeçalho Upgrade. Se o servidor aceitar, a mesma conexão TCP fica aberta e qualquer um dos lados pode enviar mensagens a qualquer momento. O protocolo é definido na RFC 6455, e todo navegador tem uma API WebSocket.

O WebSocket não sabe nada de áudio. Uma mensagem é um frame de texto ou binário, e a aplicação decide o que ele contém. As APIs de voz costumam enviar eventos JSON com PCM codificado em base64, ou frames binários brutos. Seu código captura o microfone, codifica os trechos, envia e, do outro lado, enfileira o áudio recebido para reprodução.

A graça está na simplicidade. Um WebSocket passa pela maioria dos proxies e balanceadores de carga, funciona em qualquer linguagem e é fácil de depurar: dá para ler as mensagens. O preço é a garantia de entrega do TCP. Quando um pacote se perde, o TCP o reenvia, e nada do que vem depois chega à aplicação até lá. Para baixar um arquivo, é exatamente o certo. Para voz ao vivo, um reenvio de 200 milissegundos significa 200 milissegundos de silêncio e, em seguida, uma rajada de áudio chegando de uma vez.

Como funciona o WebRTC

O WebRTC é um conjunto de padrões (a visão geral é a RFC 8825) para enviar áudio, vídeo e dados entre pares em tempo real. O navegador faz quase todo o trabalho com a mídia:

• Codecs. Os navegadores precisam suportar Opus e G.711 para áudio (RFC 7874). O Opus comprime bem a voz e adapta a taxa de bits à rede.
• Transporte. A mídia trafega por SRTP (RFC 3711), normalmente sobre UDP, com chaves negociadas via DTLS. A criptografia é obrigatória.
• Buffer de jitter e ocultação de perdas. O receptor guarda algumas dezenas de milissegundos de áudio para suavizar chegadas irregulares e preenche pequenas lacunas em vez de parar.
• Travessia de NAT. O ICE tenta primeiro os caminhos diretos, usa STUN para descobrir endereços públicos e recorre a um relay TURN quando nada mais passa.
• Cancelamento de eco e supressão de ruído. Os navegadores aplicam os dois por padrão em chamadas WebRTC.

O que o WebRTC não define é a sinalização: como dois pares trocam a descrição da sessão e os candidatos de rede antes que a mídia possa fluir. Essa parte você mesmo constrói, e muitas vezes ela é um WebSocket. Por isso “WebRTC vs WebSocket” é uma comparação meio estranha. Muitos apps WebRTC têm um WebSocket dentro.

O outro porém é o lado do servidor. O WebRTC foi projetado para chamadas de navegador para navegador. Quando o outro “par” é o seu agente de voz, você precisa de um servidor que fale WebRTC: um servidor de mídia (uma SFU) como o LiveKit, ou uma plataforma hospedada como a Daily. Operar seus próprios servidores TURN e de mídia é trabalho de infraestrutura de verdade.

Qual importa para IA de voz

Um agente de voz tem pelo menos três trechos de rede, e eles não precisam do mesmo transporte.

Do dispositivo do usuário até seus servidores. É o trecho pelo Wi-Fi de casa, pelas redes de escritório e pelos celulares no trem. Aqui, perda de pacotes e jitter são normais. O WebRTC foi feito para este trecho: o áudio continua fluindo mesmo com um pacote perdido, o Opus reduz a taxa de bits quando a banda cai e o navegador remove a voz do agente do microfone do usuário. Se seus usuários falam com um agente por um navegador ou app móvel, é aqui que o WebRTC compensa o custo de configuração.

Dos seus servidores até os modelos de voz. Seu agente envia áudio para um modelo de fala para texto e texto para um modelo de texto para fala. Essas conexões ligam data centers, onde a perda de pacotes é rara, então a entrega ordenada do TCP quase não custa nada. Você também quer o que o WebSocket oferece: eventos de texto e controle ordenados junto com o áudio, contextos de requisição e autenticação simples. É por isso que as APIs de voz, incluindo a da Cartesia, transmitem por WebSocket.

Ligações telefônicas. Quem liga de uma linha telefônica chega até você pela rede telefônica, depois por SIP e RTP, ou pelo fluxo de mídia de um provedor. O Twilio Media Streams, por exemplo, encaminha o áudio da ligação ao seu servidor por um WebSocket em μ-law a 8 kHz. Nem o WebRTC nem o WebSocket ficam do lado de quem liga. Se você está escolhendo o transporte para agentes telefônicos, leia sobre SIP trunking.

Então a pergunta útil é onde está a rede pouco confiável. Coloque WebRTC nesse trecho e use WebSocket em todos os outros.

Quando um WebSocket basta no cliente

O WebRTC não é obrigatório para todo recurso de voz no navegador. Um WebSocket direto do cliente é uma escolha razoável quando:

• A rede é previsível. Ferramentas internas, quiosques, apps desktop em redes de escritório e demos.
• Você está prototipando. Uma conexão, sem servidor de mídia, sem TURN, e dá para registrar cada evento.
• O áudio não é conversacional. Texto para fala em streaming para leitura em voz alta, ou ditado em que um travamento curto não quebra uma conversa.
• O cliente é um servidor. Um backend ou uma função edge que retransmite áudio de outro lugar.

Se for por esse caminho, envie trechos de áudio pequenos, mantenha um buffer de reprodução curto e pare a reprodução assim que o usuário interromper. Teste numa rede com perdas antes de lançar. As ferramentas de desenvolvedor do navegador conseguem limitar banda e latência, mas não descartar pacotes, então use um condicionador de rede no nível do sistema operacional ou um hotspot do celular.

Arquiteturas que funcionam

Front end com WebRTC, back end com WebSocket. A configuração de produção mais comum. O navegador ou app do usuário entra numa sala WebRTC no LiveKit ou na Daily. Seu agente roda num servidor, entra na mesma sala e transmite para os modelos de voz por WebSocket. O LiveKit Agents e o Pipecat funcionam assim, e os plugins da Cartesia de ambos abrem um WebSocket para a Cartesia a partir do servidor. A LiveKit e a Daily, empresa por trás do Pipecat, são clientes da Cartesia. O CEO da Daily, Kwindla Hultman, resumiu assim: “Cartesia Sonic is the best voice model today for real-time multimodal use cases.”

WebSocket de ponta a ponta. O navegador envia áudio ao seu servidor por um WebSocket, e o servidor também fala com os modelos de voz por WebSocket. É a pilha mais simples e funciona bem para protótipos e redes controladas. Os Cartesia Managed Agents também aceitam uma conexão WebSocket direta, então um servidor confiável ou um navegador com um token de acesso de curta duração pode falar com um agente hospedado sem rodar código de agente.

Telefone na entrada, WebSocket por dentro. Em agentes telefônicos, a ligação chega por SIP ou por um provedor de telefonia, e as conexões do agente com os modelos de voz continuam em WebSocket. Os Managed Agents cuidam do lado telefônico para você, com números da Cartesia, Twilio ou seu próprio tronco SIP.

Transmitir áudio para a Cartesia por WebSocket

As APIs em tempo real da Cartesia transmitem por WebSocket:

• Texto para fala: wss://api.cartesia.ai/tts/websocket recebe texto à medida que ele chega do seu LLM e devolve trechos de áudio. Uma conexão pode carregar vários contextos, e as continuações permitem que o Sonic fale uma frase antes de o LLM terminar a resposta.
• Fala para texto: o Ink-2 transcreve um fluxo de PCM bruto por WebSocket e detecta turnos nativamente.
• Managed Agents: wss://api.cartesia.ai/v1/agents/websocket/{agent_id} conecta uma aplicação a um agente hospedado. Você envia eventos audio_input com áudio em base64 em trechos de 20 a 100 milissegundos e reproduz os eventos audio_output. Quando o usuário começa a falar por cima do agente, a Cartesia envia audio_output_clear e seu cliente para a reprodução.

O WebSocket do agente aceita áudio mono sem cabeçalho em pcm_16000, pcm_24000, pcm_44100 ou mulaw_8000, e devolve áudio no mesmo formato:

{
	"type": "session_create",
	"audio": {
		"input_format": "pcm_16000",
		"output_delivery": "speaking_pace"
	}
}

Num navegador, nunca coloque uma chave de API no código do cliente. Navegadores não conseguem definir cabeçalhos de WebSocket, então seu servidor gera um token de acesso de curta duração e o cliente o envia como parâmetro de consulta. O guia da API WebSocket tem um exemplo de sessão completo.

Para experimentar, crie um agente no playground da Cartesia, ou pegue uma chave de API e transmita seu primeiro áudio com o guia rápido de texto para fala.

Guias relacionados

• Crie um agente de voz com Pipecat e Cartesia
• O que é SIP trunking e como usar com IA de voz
• Detecção de atividade vocal: VAD para agentes de voz
• Agente de voz com IA: o que é e como criar um
• Conversão de texto em fala em JavaScript com SpeechSynthesis