WebRTC vs WebSocket para IA de voz en tiempo real

WebSocket y WebRTC mantienen una conexión abierta para que el audio fluya en ambos sentidos sin una petición nueva por cada fragmento. La diferencia está en lo que pasa cuando la red falla. Un WebSocket funciona sobre TCP, así que cada byte llega en orden, aunque haya que esperar. WebRTC suele funcionar sobre UDP y está hecho para medios, así que descarta u oculta un paquete que llega tarde y sigue reproduciendo.

En un agente de voz, esa diferencia decide dónde va cada uno. WebRTC es para el tramo entre el dispositivo de una persona y tus servidores, donde el wifi y las redes móviles pierden paquetes. WebSocket es para los tramos entre servidores, donde no se pierden, y para todo lo que necesite un flujo de mensajes simple y ordenado. La mayoría de los agentes de voz en producción usan los dos.

Esta guía es para ingenieros que eligen el transporte de un agente de voz o de una función de voz en tiempo real. Explica cómo funciona cada protocolo, la comparación que importa para el audio y las arquitecturas que los equipos llevan a producción.

WebRTC vs WebSocket de un vistazo

Cómo funciona un WebSocket

Un WebSocket empieza como una petición HTTP normal con una cabecera Upgrade. Si el servidor acepta, la misma conexión TCP queda abierta y cualquiera de los dos lados puede enviar mensajes en cualquier momento. El protocolo está definido en la RFC 6455, y todos los navegadores tienen una API WebSocket.

WebSocket no sabe nada de audio. Un mensaje es una trama de texto o binaria, y la aplicación decide qué contiene. Las API de voz suelen enviar eventos JSON con PCM codificado en base64, o tramas binarias en bruto. Tu código captura el micrófono, codifica los fragmentos, los envía y, en el otro extremo, pone en cola el audio recibido para reproducirlo.

Esa sencillez es su atractivo. Un WebSocket atraviesa la mayoría de los proxies y balanceadores de carga, funciona desde cualquier lenguaje y es fácil de depurar: puedes leer los mensajes. El precio es la garantía de entrega de TCP. Cuando se pierde un paquete, TCP lo reenvía, y nada de lo que viene detrás llega a la aplicación hasta entonces. Para descargar un archivo es exactamente lo correcto. Para voz en directo, un reenvío de 200 milisegundos significa 200 milisegundos de silencio y luego una ráfaga de audio que llega de golpe.

Cómo funciona WebRTC

WebRTC es un conjunto de estándares (la visión general está en la RFC 8825) para enviar audio, vídeo y datos entre pares en tiempo real. El navegador se encarga de casi todo el trabajo con los medios:

• Códecs. Los navegadores deben soportar Opus y G.711 para audio (RFC 7874). Opus comprime bien la voz y adapta su tasa de bits a la red.
• Transporte. Los medios viajan sobre SRTP (RFC 3711), normalmente por UDP, con claves negociadas mediante DTLS. El cifrado es obligatorio.
• Búfer de jitter y ocultación de pérdidas. El receptor guarda unas decenas de milisegundos de audio para suavizar las llegadas irregulares y rellena los huecos pequeños en lugar de detenerse.
• Paso de NAT. ICE prueba primero las rutas directas, usa STUN para descubrir direcciones públicas y recurre a un relé TURN cuando nada más funciona.
• Cancelación de eco y supresión de ruido. Los navegadores las aplican por defecto en las llamadas WebRTC.

Lo que WebRTC no define es la señalización: cómo dos pares intercambian la descripción de la sesión y los candidatos de red antes de que fluyan los medios. Esa parte la construyes tú, y muy a menudo es un WebSocket. Por eso “WebRTC vs WebSocket” es una comparación un poco extraña. Muchas aplicaciones WebRTC contienen un WebSocket.

El otro inconveniente es el lado del servidor. WebRTC se diseñó para llamadas de navegador a navegador. Cuando el otro “par” es tu agente de voz, necesitas un servidor que hable WebRTC: un servidor de medios (una SFU) como LiveKit, o una plataforma alojada como Daily. Operar tus propios servidores TURN y de medios es trabajo de infraestructura real.

Cuál importa en IA de voz

Un agente de voz tiene al menos tres tramos de red, y no necesitan el mismo transporte.

Del dispositivo del usuario a tus servidores. Es el tramo por el wifi de casa, las redes de oficina y los móviles en un tren. Aquí la pérdida de paquetes y el jitter son normales. WebRTC se creó para este tramo: el audio sigue fluyendo aunque se pierda un paquete, Opus baja su tasa de bits cuando cae el ancho de banda y el navegador elimina la voz del agente del micrófono del usuario. Si tus usuarios hablan con un agente desde un navegador o una app móvil, aquí es donde WebRTC compensa lo que cuesta configurarlo.

De tus servidores a los modelos de voz. Tu agente envía audio a un modelo de voz a texto y texto a un modelo de texto a voz. Estas conexiones van entre centros de datos, donde la pérdida de paquetes es rara, así que la entrega ordenada de TCP apenas cuesta nada. Además quieres lo que da WebSocket: eventos de texto y control ordenados junto al audio, contextos de petición y una autenticación sencilla. Por eso las API de voz, incluida la de Cartesia, transmiten por WebSocket.

Llamadas telefónicas. Quien llama desde una línea telefónica te llega por la red telefónica, luego por SIP y RTP, o por el flujo de medios de un proveedor. Twilio Media Streams, por ejemplo, reenvía el audio de la llamada a tu servidor por un WebSocket en μ-law a 8 kHz. Ni WebRTC ni WebSocket están del lado de quien llama. Si eliges el transporte para agentes telefónicos, lee sobre el troncal SIP.

Así que la pregunta útil es dónde está la red poco fiable. Pon WebRTC en ese tramo y usa WebSocket en todos los demás.

Cuándo basta un WebSocket en el cliente

WebRTC no es obligatorio para todas las funciones de voz en el navegador. Un WebSocket directo desde el cliente es una opción razonable cuando:

• La red es predecible. Herramientas internas, quioscos, apps de escritorio en redes de oficina y demos.
• Estás haciendo un prototipo. Una conexión, sin servidor de medios, sin TURN, y puedes registrar cada evento.
• El audio no es conversacional. Texto a voz en streaming para lectura en voz alta, o dictado donde una pausa corta no rompe una conversación.
• El cliente es un servidor. Un backend o una función edge que retransmite audio desde otro sitio.

Si eliges este camino, envía fragmentos de audio pequeños, mantén un búfer de reproducción corto y detén la reproducción en cuanto el usuario interrumpa. Prueba en una red con pérdidas antes de lanzar. Las herramientas de desarrollo del navegador pueden limitar el ancho de banda y la latencia, pero no descartar paquetes, así que usa un acondicionador de red a nivel de sistema operativo o un punto de acceso móvil.

Arquitecturas que funcionan

Front end con WebRTC, back end con WebSocket. La configuración de producción más común. El navegador o la app del usuario entra en una sala WebRTC de LiveKit o Daily. Tu agente corre en un servidor, entra en la misma sala y transmite a los modelos de voz por WebSocket. LiveKit Agents y Pipecat funcionan así, y sus plugins de Cartesia abren un WebSocket hacia Cartesia desde el servidor. LiveKit y Daily, la empresa detrás de Pipecat, son clientes de Cartesia. El CEO de Daily, Kwindla Hultman, lo resumió así: “Cartesia Sonic is the best voice model today for real-time multimodal use cases.”

WebSocket de extremo a extremo. El navegador envía audio a tu servidor por un WebSocket, y tu servidor también habla con los modelos de voz por WebSocket. Es la pila más sencilla y funciona bien para prototipos y redes controladas. Cartesia Managed Agents también aceptan una conexión WebSocket directa, así que un servidor de confianza o un navegador con un token de acceso de corta duración pueden hablar con un agente alojado sin ejecutar código de agente.

Teléfono al entrar, WebSocket por dentro. En los agentes telefónicos, la llamada llega por SIP o por un proveedor de telefonía, y las conexiones del agente con los modelos de voz siguen en WebSocket. Managed Agents se encargan del lado telefónico por ti, con números de Cartesia, Twilio o tu propio troncal SIP.

Transmitir audio a Cartesia por WebSocket

Las API en tiempo real de Cartesia transmiten por WebSocket:

• Texto a voz: wss://api.cartesia.ai/tts/websocket recibe texto a medida que llega de tu LLM y devuelve fragmentos de audio. Una conexión puede llevar varios contextos, y las continuaciones permiten que Sonic diga una frase antes de que el LLM termine la respuesta.
• Voz a texto: Ink-2 transcribe un flujo de PCM en bruto por WebSocket y detecta los turnos de forma nativa.
• Managed Agents: wss://api.cartesia.ai/v1/agents/websocket/{agent_id} conecta una aplicación con un agente alojado. Envías eventos audio_input con audio en base64 en fragmentos de 20 a 100 milisegundos y reproduces los eventos audio_output. Cuando el usuario empieza a hablar encima del agente, Cartesia envía audio_output_clear y tu cliente detiene la reproducción.

El WebSocket del agente acepta audio mono sin cabecera en pcm_16000, pcm_24000, pcm_44100 o mulaw_8000, y devuelve audio en el mismo formato:

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

Desde un navegador, nunca pongas una clave de API en el código del cliente. Los navegadores no pueden definir cabeceras de WebSocket, así que tu servidor genera un token de acceso de corta duración y el cliente lo pasa como parámetro de consulta. La guía de la API WebSocket tiene un ejemplo de sesión completo.

Para probarlo, crea un agente en el playground de Cartesia, o consigue una clave de API y transmite tu primer audio con la guía rápida de texto a voz.

Guías relacionadas

• Crea un agente de voz con Pipecat y Cartesia
• ¿Qué es un troncal SIP? Cómo funciona con IA de voz
• Detección de actividad de voz: VAD para agentes de voz
• Agente de voz de IA: qué es y cómo crear uno
• Texto a voz con JavaScript y SpeechSynthesis