WebRTC sabotea los prompts de voz: por qué el protocolo de videollamadas es un mal transporte para LLMs

Cuando Discord intentó dar fiabilidad a sus paquetes de audio, descubrió que la especificación WebRTC lo impide de forma deliberada: no hay forma de retransmitir un paquete dentro del navegador, ni siquiera si el desarrollador lo pide explícitamente. Esa limitación, tolerable para una llamada de equipo, se convierte en un problema serio cuando el audio que se descarta es un prompt dirigido a un LLM.

Luke Curley, ingeniero que trabajó en esta problemática en Discord, lo resume con precisión incómoda en su post «WebRTC is the problem», recogido por Simon Willison en su blog el 9 de mayo: WebRTC está diseñado para degradar y descartar tu prompt en condiciones de red adversas. No es un bug; es la filosofía de diseño del protocolo.

El protocolo que elige la latencia sobre la exactitud

WebRTC fue concebido para comunicación en tiempo real: videoconferencias, llamadas de voz, streaming interactivo. En ese contexto, la prioridad absoluta es mantener baja la latencia. Si la red está congestionada, el protocolo descarta paquetes de audio en lugar de esperar a que lleguen; un pequeño glitch auditivo es preferible a un silencio de medio segundo que interrumpa el ritmo de la conversación.

Esa lógica tiene sentido cuando las dos personas al teléfono pueden repetir lo que no se entendió. No tiene ningún sentido cuando el receptor del audio es un modelo de lenguaje que va a generar una respuesta a partir de exactamente lo que escuchó. Un prompt corrupto produce una respuesta corrupta. No hay «¿puedes repetirlo?» automático; hay simplemente una salida incorrecta, cara y difícil de depurar.

Curley señala la ironía con toda su crudeza: el usuario está pagando por la inferencia, los modelos de lenguaje no son precisamente rápidos de por sí, y sin embargo el transporte que usa la aplicación de voz está optimizado para sacrificar exactitud en favor de unos milisegundos de latencia que, en este contexto, nadie pidió.

Por qué esto afecta especialmente a las interfaces de voz con LLMs

Las interfaces de voz sobre LLMs han ganado tracción considerable en el último año. Productos que permiten hablar directamente con modelos como Claude o sus competidores dependen de capturar el audio del micrófono, enviarlo a un servidor de transcripción o directamente al modelo en modo multimodal, y procesar la respuesta. Si el transporte descarta fragmentos del audio durante ese camino, el modelo recibe una entrada incompleta.

En una videollamada entre personas, perder 200 ms de audio es un inconveniente menor. En una instrucción a un agente de IA —«cancela el pedido número 4821 y notifica al cliente»—, perder esos 200 ms puede significar que el modelo escuche «cancela el pedido» sin el resto, con consecuencias potencialmente distintas.

El problema se agrava en entornos móviles o con conectividad irregular, precisamente los escenarios donde las interfaces de voz tienen más sentido como alternativa al teclado.

Alternativas en desarrollo: MoQ y el rediseño del transporte

La propuesta que subyace al post de Curley es MoQ (Media over QUIC), un protocolo en desarrollo dentro del IETF que usa QUIC como capa de transporte y permite configurar políticas de entrega más granulares: el desarrollador puede decidir si un flujo concreto prioriza la latencia o la fiabilidad, en lugar de tener ese comportamiento hardcodeado.

Para aplicaciones de voz con LLMs, eso significaría poder marcar el flujo del prompt como «espera a que llegue completo» y el flujo de la respuesta de audio sintetizada como «prioriza latencia». Dos políticas distintas para dos necesidades distintas dentro de la misma sesión.

MoQ no está listo para producción generalizada, y WebRTC sigue siendo el estándar de facto en los navegadores. A corto plazo, los equipos que construyen interfaces de voz sobre LLMs tienen opciones limitadas: usar WebSockets con su propio control de flujo, aceptar las pérdidas y añadir lógica de detección de prompts incompletos, o evitar el navegador y operar desde cliente nativo donde el control del transporte es mayor.

Opinión EP

Es tentador ver esto como un problema de nicho, pero con el crecimiento de los agentes de voz en entornos de trabajo reales, la falta de fiabilidad en el transporte de prompts va a convertirse en un punto de fricción con consecuencias prácticas. Merece más atención de la que recibe en los debates habituales sobre latencia de modelos y calidad de transcripción.