¿Qué es la fluctuación? Cómo comprobar la fluctuación y la pérdida de paquetes antes de una llamada

El jitter indica cuánto cambia la latencia de tu conexión de un momento a otro. La pérdida de paquetes es la proporción de datos que nunca llegan. En una llamada, un jitter alto hace que las voces suenen robóticas, y la pérdida hace que desaparezcan palabras y sílabas, incluso con una conexión rápida. Microsoft considera habituales para el audio de Teams un jitter inferior a 30 ms y una pérdida de paquetes inferior al 2 %. Zoom recomienda un jitter de 40 ms o menos y una pérdida del 2 % o menos. Puedes medir ambos en un navegador, desde la línea de comandos de Windows o en las estadísticas de la propia aplicación de reuniones.

La guía sobre las llamadas con retraso pese a tener internet rápido explica por qué la velocidad no lo es todo, y la comprobación de internet antes de una llamada explica cuándo hacer la prueba. Esta guía explica qué significan las dos cifras y cómo medirlas.

Jitter y pérdida de paquetes en una llamada

El audio y el video viajan en paquetes pequeños, muchos por segundo. Si cada paquete tardara lo mismo, 40 ms, la llamada simplemente tendría 40 ms de retraso y nadie lo notaría. El jitter es la irregularidad: un paquete tarda 20 ms y el siguiente, 70 ms. La aplicación de reuniones retiene los paquetes en un búfer para suavizar esas variaciones. Microsoft indica que Teams puede adaptarse a cierto nivel de jitter mediante el almacenamiento en búfer, y solo lo notas cuando el jitter supera lo que el búfer puede compensar.

La pérdida de paquetes es peor, porque un paquete perdido desaparece y la aplicación tiene que compensar el hueco. La guía de calidad de llamadas de Microsoft describe cómo se oye cada problema:

Qué se considera bueno

Las aplicaciones de reuniones publican sus propios valores de referencia. Son objetivos para el tráfico de llamadas de la propia aplicación; úsalos como referencia al consultar otras pruebas:

Una sola lectura por encima de estos valores no significa que la llamada vaya a fallar. Conviene solucionar el problema antes de la llamada si la lectura se mantiene alta durante varios minutos o aumenta cada vez que alguien más empieza a usar la conexión.

Cómo se calcula el jitter

Las herramientas miden el jitter de formas ligeramente distintas, así que compara los resultados de una misma herramienta. Por ejemplo, la prueba de velocidad de Cloudflare calcula el jitter como la diferencia media entre mediciones de latencia consecutivas. Con cinco mediciones de 20, 24, 19, 45 y 21 ms, las diferencias son 4, 5, 26 y 24 ms, así que el jitter es de unos 15 ms. La latencia media de 26 ms oculta que una medición tardó aproximadamente el doble que las demás.

Tres formas de hacer una prueba antes de una llamada

1. Una prueba en el navegador que informa de ambos valores

Abrir speed.cloudflare.com en el PC desde el que participarás. Cloudflare explica que su prueba mide el jitter tanto cuando la conexión está en reposo como cuando está ocupada descargando y cargando, y mide la pérdida de paquetes mediante el reenvío de paquetes a través de un servidor TURN de WebRTC. Observa la diferencia entre los resultados en reposo y bajo carga. Si el jitter aumenta cuando la conexión está ocupada, es posible que una copia de seguridad, la sincronización en la nube o la carga desde otro dispositivo esté saturando la línea, y una llamada sufriría el mismo problema.

2. Línea de comandos de Windows: ping y pathping

Abre el Símbolo del sistema o Terminal y ejecuta:

ping -n 100 1.1.1.1

De forma predeterminada, ping envía cuatro solicitudes; -n 100 envía cien, lo que tarda uno o dos minutos. La línea de resumen muestra cuántas se perdieron y el porcentaje. Los tiempos mínimo y máximo indican cuánto difieren la respuesta más rápida y la más lenta.

Para ver dónde comienza la pérdida, ejecuta:

pathping 1.1.1.1

pathping envía 100 solicitudes a cada router de la ruta y muestra la pérdida en cada uno. Tarda unos minutos. Lee los resultados con cuidado: el propio ejemplo de Microsoft muestra routers que descartan las solicitudes dirigidas a ellos, pero reenvían todo lo demás. Una pérdida que aparece en un router y no continúa hasta el final de la ruta no importa. Una pérdida que empieza en un router y continúa hasta el destino es real.

• La pérdida en el primer salto, que es tu propio router, apunta a un problema de Wi-Fi o de la red doméstica.
• La pérdida que empieza más adelante apunta a tu proveedor o a un punto posterior.

3. Las propias estadísticas de la aplicación de reuniones

Este es el único método que mide la propia llamada. En Teams, durante una llamada, abre Más acciones → Configuración → Estado de la llamada ; Microsoft indica que los valores se actualizan cada 15 segundos. En la aplicación de escritorio de Zoom, abre Configuración → Estadísticas. Basta con una llamada de prueba. La guía sobre Llamadas de prueba de Teams y reuniones de prueba de Zoom indica cómo iniciar una.

Para Teams, Microsoft también ofrece la herramienta gratuita Teams Network Assessment Tool. Envía paquetes al relay de Teams más cercano y de vuelta, y después informa de la pérdida, el jitter y el tiempo de ida y vuelta.

Qué cambiar cuando los valores son altos

Qué mide CallReady

CallReady comprueba la conexión como parte de su revisión previa a la llamada desde la bandeja del sistema de Windows. Mide la latencia, el jitter y el rendimiento aproximado de descarga y carga con Cloudflare, y muestra esos valores junto a los resultados de la cámara y el micrófono. No mide la pérdida de paquetes. Si te dicen que se pierden palabras, usa la prueba de Cloudflare pathping o las estadísticas de la aplicación de reuniones para comprobarlo.

CallReady mide la ruta hasta Cloudflare, no la ruta de los medios hasta un servidor de Teams o Zoom. Un buen resultado significa que tu conexión es estable. Para cualquier aspecto específico de Teams o Zoom, usa las estadísticas de la aplicación durante una llamada de prueba.

Preguntas frecuentes