El jitter es la variación en cuándo llegan los paquetes de voz. Una llamada VoIP trocea tu voz en paquetes pequeños, envía uno cada 20 milisegundos y espera que lleguen con el mismo ritmo constante. Cuando llegan tarde, pronto o desordenados, esa irregularidad es el jitter, y quien está al otro lado la oye como palabras cortadas, audio robótico o huecos.
Si operas un agente de voz, el jitter importa dos veces. Degrada el audio de quien llama a la entrada, así que tu modelo de voz a texto recibe una señal peor, y degrada el audio del agente a la salida, así que quien llama concluye que tu producto está roto. Cuando un agente suena robótico por teléfono pero bien en el navegador, revisa la red antes de tocar el modelo.
Esta guía cubre qué es el jitter, qué lo causa, cómo medirlo en una llamada real y cómo corregirlo, incluidas las partes del camino que un desarrollador de agentes de voz sí controla.
El jitter de un vistazo
| Métrica | Cómodo | Perceptible | Inutilizable |
|---|---|---|---|
| Jitter | Menos de 30 ms | 30–50 ms | Más de 50 ms |
| Pérdida de paquetes | Menos del 1% | 1–3% | Más del 3% |
| Latencia unidireccional | Menos de 150 ms | 150–400 ms | Más de 400 ms |
Son reglas generales, no garantías. Las cifras de latencia de 150 ms y 400 ms vienen de la Recomendación G.114 de la UIT sobre el retardo unidireccional aceptable, y la cifra de 30 ms de jitter es la orientación que encontrarás en documentación de fabricantes como la nota sobre jitter de Cisco. Un buen buffer de jitter adaptativo puede enmascarar más de 30 ms de jitter, a costa de añadir retardo. La experiencia de escucha conjunta de estas métricas es lo que una mean opinion score intenta comprimir en un solo número.
Qué es realmente el jitter
La voz sobre IP viaja sobre RTP, el Real-time Transport Protocol. El emisor marca cada paquete con un número de secuencia y una marca de tiempo (RFC 3550), así que el receptor sabe tanto el orden en que se enviaron los paquetes como el instante exacto en que debe sonar cada porción de 20 ms de audio.
El jitter es la brecha entre ese horario y la realidad. Si el paquete 41 llega 20 ms después del 40, pero el 42 llega 60 ms después del 41, el flujo tiene jitter. La misma RFC define también cómo lo informan los extremos: cada flujo RTP va acompañado de mensajes de control RTCP, y el receptor devuelve periódicamente un informe de receptor cuyos campos incluyen el jitter entre llegadas medido. Por eso cualquier sistema telefónico serio puede darte su jitter sin instrumentación extra: el protocolo lleva la cuenta desde el principio.
Conviene separar dos vecinos, porque se parecen y se corrigen de forma distinta:
- Latencia. Es cuánto llegan tarde los paquetes en conjunto. Hace que la gente se pise al hablar sin querer, pero no distorsiona el audio en sí.
- Pérdida de paquetes. Son paquetes que nunca llegan (o llegan demasiado tarde para servir, lo que el receptor cuenta como perdidos). La pérdida elimina porciones de audio; el jitter solo las entrega de forma irregular. Una ráfaga de paquetes desordenados parece pérdida para el receptor, porque el decodificador no puede esperar a los rezagados.
Cómo suena el jitter
En una llamada con jitter creciente, la gente describe la misma progresión. Las palabras empiezan a cortarse por los bordes. Las voces se vuelven metálicas o robóticas cuando el decodificador interpola sobre tramas que faltan. Luego llegan los huecos: silencios de medio segundo mientras el receptor espera paquetes que aparecen en un grupo un momento después. En el extremo, la llamada se cae.
Todo esto es el buffer de jitter haciendo su trabajo y quedándose sin margen. Lo que plantea la pregunta obvia.
El buffer de jitter y su precio
Un buffer de jitter es una pequeña cola en el lado receptor. En vez de reproducir cada paquete en cuanto llega, el receptor retiene los paquetes un instante y los suelta con una cadencia uniforme, de modo que un paquete que llega 30 ms tarde aún alcanza su hueco. Los buffers típicos retienen de 30 a 50 ms de audio; los adaptativos crecen y se encogen con las condiciones, a veces hasta 100 o 200 ms.
El trato es retardo a cambio de suavidad. Cada milisegundo de buffer es un milisegundo añadido a la ida y vuelta, y pasados unos 150 ms de retardo añadido una conversación empieza a parecer un walkie-talkie: cada quien espera, habla y vuelve a esperar. Un buffer demasiado pequeño descarta los paquetes tardíos y se oyen cortes. Uno demasiado grande esconde el jitter y te deja latencia en su lugar. No hay un ajuste que te dé las dos cosas, y por eso arreglar la red gana a ajustar el buffer.
Dónde vive el buffer depende de la llamada:
- Llamadas de navegador y apps (WebRTC) incluyen un buffer de jitter adaptativo y ocultación de pérdidas por defecto, como explica la guía de WebRTC frente a WebSocket. Rara vez lo ajustas tú.
- Teléfonos SIP, PBX y session border controllers tienen buffers configurables, y el valor por defecto no siempre es el adecuado para tu red.
- Integraciones RTP en crudo te convierten en el autor del buffer. Si llevas audio de una troncal SIP a tu propio stack, dimensionar ese buffer es tu trabajo.
De dónde viene el jitter
El jitter es casi siempre un problema de colas: paquetes que esperan tiempos distintos en algún punto del camino.
- Congestión. Un puerto de router o switch que se llena y se vacía retiene los paquetes tiempos impredecibles. Es la causa clásica, y aparece en horas punta.
- Wi-Fi y celular. Los enlaces inalámbricos programan el tiempo de antena y retransmiten en silencio, así que los tiempos de llegada varían mucho más que en Ethernet. Quien llama desde el Wi-Fi de un hotel no se lo imagina.
- Falta de QoS. Sin marcado de calidad de servicio, los paquetes de voz hacen cola detrás de descargas masivas. Marcar el tráfico de voz (normalmente DSCP EF) permite a tus routers y a los backbones de muchos operadores priorizarlo, aunque el marcado a menudo no sobrevive a la internet pública.
- Cambios de ruta. Cuando el tráfico salta a otra ruta a mitad de llamada, el nuevo camino tiene tiempos distintos, y el flujo tartamudea hasta que el buffer se adapta.
- Buffers sobredimensionados. El bufferbloat es el primo discreto del jitter: una cola enorme en algún punto añade un retardo fijo que varía con la carga, y no aparece como pérdida de paquetes en ninguna parte.
Cómo medir el jitter
No necesitas equipamiento especial; la llamada ya se está midiendo a sí misma.
- Lee los informes de receptor RTCP. El campo de jitter es la cifra autorizada de lo que experimentó el otro extremo, expresada en las unidades de marca de tiempo del flujo: en una llamada G.711 divides entre 8 para obtener milisegundos (la mayoría de paneles ya hace la conversión). Las PBX, SBC y paneles CPaaS lo muestran por llamada.
- Captura el flujo en Wireshark. Telephony → RTP → Stream Analysis informa del jitter y la pérdida por dirección y te deja escuchar exactamente con lo que tuvo que trabajar el receptor.
- Para WebRTC, abre chrome://webrtc-internals durante la llamada y observa
jitter,packetsLostyjitterBufferDelayen vivo. - Como sonda rápida, haz ping al otro extremo. Una gran diferencia entre los tiempos de ida y vuelta medio y máximo sugiere jitter en el camino. Es una estimación, no la métrica, porque el jitter RTP se mide en las unidades de marca de tiempo del propio flujo de audio.
Mide durante llamadas reales en tu hora más ocupada. Medir un problema de martes congestionado un domingo tranquilo te dirá que todo va bien.
Cómo corregirlo
Trabaja desde el tramo que controlas hacia afuera:
- Prioriza la voz en tu propia red. Marca RTP con DSCP EF y asegúrate de que tus routers lo respetan. Pasa el tráfico de llamadas a conexiones por cable antes de tocar cualquier otra cosa.
- Dimensiona el buffer de jitter a propósito. Empieza cerca de 30–50 ms en los dispositivos que lo permiten, y prefiere buffers adaptativos cuando existan.
- Elige códecs que toleren la pérdida. En los tramos donde eliges códec, Opus lleva corrección de errores hacia adelante integrada (RFC 6716). En la red telefónica pública te tocará G.711, que no tiene esa protección y depende por completo del buffer.
- Acorta el camino. Elige proveedores con puntos de presencia cerca de tus usuarios. Cada segmento de red extra es otra cola que puede llenarse.
- Acepta la última milla. No puedes arreglar el Wi-Fi de la cafetería de quien llama. Lo que sí puedes es medirlo, para dejar de depurar tu propio stack por culpa de su router.
El jitter y los agentes de voz
Una llamada de agente tiene más eslabones que una llamada entre personas: el teléfono de quien llama, su operador, tu proveedor de telefonía o troncal SIP, luego tu stack de agente, y de vuelta. El jitter puede entrar en cualquier salto, y se suma a la latencia del modelo en la experiencia de quien llama. Nadie oye “la red añadió 120 ms de buffer y luego el modelo tardó 90 ms”. Oye un único agente lento y entrecortado.
Dos hábitos mantienen la red honesta:
- Mide por tramo. Lee las estadísticas RTCP de tu proveedor de telefonía y mide por separado los saltos de voz a texto y de texto a voz. Cartesia publica una latencia de modelo inferior a 90 ms para Sonic; eso es el modelo, y el tramo de red añade su propio retardo encima, justo el retardo que la medición de P95 y P99 existe para atrapar. Si el modelo es rápido y la llamada sigue lenta o distorsionada, estás viendo jitter.
- Prueba por la ruta telefónica real. El audio telefónico corre a 8 kHz sobre G.711 μ-law o A-law, a través del buffer de jitter de otra persona. Un agente que suena limpio en tu portátil puede sonar roto por una ruta de operador congestionada, así que haz llamadas de prueba desde números reales, en horas punta, antes de culpar al modelo de voz.
Del lado de Cartesia, Sonic devuelve μ-law o A-law en crudo a 8 kHz directamente ("encoding": "pcm_mulaw", "sample_rate": 8000), así que el audio de telefonía no pasa por una conversión extra, e Ink acepta los mismos formatos para reconocimiento de voz en streaming. Managed Agents atiende llamadas en números de Cartesia, Twilio o tu propia troncal SIP y opera el tramo telefónico por ti. Las llamadas de agente cuestan 0,03 $ por minuto, y el suplemento de telefonía de 0,014 $ por minuto solo aplica a números provisionados por Cartesia. Las regiones de despliegue son EE. UU., UE, Reino Unido, India y Australia para mantener corto el camino de red. Las troncales SIP conectan por TLS con medios SRTP, y la guía de troncales SIP cubre la configuración.
Y si tu jitter resulta estar bien y el agente sigue sonando robótico, entonces sí, tienes nuestro permiso para culpar al modelo.