Jitter y pérdida de paquetes en una llamada VPN: qué comparar

El habla robótica y las sílabas perdidas suenan distinto porque son fallos distintos. El jitter cambia cuándo llegan los paquetes; la pérdida significa que no llegan en absoluto. Cualquiera de los dos puede ocurrir mientras una prueba de velocidad informa de una descarga saludable, porque el caudal y la entrega puntual miden cosas diferentes. Haga coincidir las pruebas con el sonido antes de cambiar cualquier ajuste.

Por qué los paquetes tardíos y los que faltan suenan distinto

Los medios salen del emisor a un ritmo constante, y las redes reales los entregan con espaciados desiguales. Las aplicaciones almacenan un poco en búfer para suavizarlo, cambiando retardo por continuidad: suba el búfer y la conversación parece lenta, bájelo y aparecen huecos. Un paquete que llega después de su plazo de reproducción está efectivamente perdido, aunque nunca se haya descartado. Por eso dos conexiones con el mismo ancho de banda pueden producir llamadas muy distintas.

La dirección también importa. Los medios entrantes y salientes pueden seguir caminos distintos, sobre todo cuando un lado está en una red móvil.

Los números que hay que leer durante la ventana mala

Use las estadísticas de la propia aplicación cuando las ofrezca, y léalas mientras la llamada va mal, no cuando haya terminado. Un relé de medios suele ser un host distinto del sitio web del servicio, así que un ping a la página de inicio mide un camino que la llamada no usa. Mire el porcentaje de pérdida, el tiempo de ida y vuelta y el jitter por separado, y anote si el cliente envía o recibe el problema. Una reconexión de VPN durante la llamada es un tercer evento que registrar, no para fusionar con los demás.

Las capturas de pantalla del panel de estadísticas superan a un recuerdo de la llamada, porque los números se pueden comparar después. Veinte segundos de porcentaje de pérdida le dicen si la ruta está descartando paquetes ahora, pero no si la pérdida es a ráfagas o cuándo empezó.

Para eso, repita la medición en una segunda condición en lugar de leer una ventana como veredicto. Dos ventanas tomadas en condiciones distintas dicen más que una ventana larga tomada sin ninguna.

Qué hace un búfer de jitter con el plazo

Un búfer de jitter retiene brevemente los paquetes entrantes para que las llegadas desiguales — la variación de retardo que RFC 3393 define como métrica — se puedan reproducir con un reloj regular. El tamaño del búfer fija el plazo de reproducción: todo paquete posterior a ese plazo se descarta, sea cual sea su contenido. Los códecs difieren en cuánto pueden ocultar, y un códec que interpola una trama perdida puede esconder una pérdida, pero no una serie de ellas. Por eso el mismo porcentaje de pérdida da distinta calidad de llamada con códecs distintos.

Ajustar el búfer es un intercambio, no una solución. Un búfer mayor compra continuidad a costa de retardo en la conversación, y no puede recuperar paquetes que lleguen después del plazo.

Compare la radio y la carga antes de la salida

Mantenga fijos la salida y la aplicación mientras cambia una condición local cada vez. Un icono de señal fuerte no dice nada sobre la congestión del canal. Si el problema sigue a una habitación o a un punto de acceso, la radio es la siguiente investigación.

ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9

El ping da un recuento de pérdidas y una dispersión que puede comparar entre condiciones, y mtr muestra la pérdida por salto a lo largo del camino. Los saltos intermedios que fallan mientras los posteriores responden suelen dar menos prioridad a ICMP en lugar de descartar tráfico de usuario. Repita ambos mientras se ejecuta una subida controlada, porque un enlace que va bien en reposo y es inservible bajo carga apunta a la cola de espera, no a la VPN. Si solo una condición reproduce el problema, la otra condición acaba de quedar descartada.

Repare solo lo que respalde la comparación

Cada comparación respalda una reparación, y aplicar varias a la vez destruye la prueba. Un camino local débil pide un canal mejor o Ethernet, el tráfico competidor pide planificación o una disciplina de cola, y una salida mala pide comparar otra salida en las mismas condiciones. Cuando cambie el transporte de la VPN, mantenga el perfil válido y cambie una variable cada vez. Vuelva a probar la misma conversación con actividad de fondo normal en lugar de juzgar el éxito por si subió la puntuación de la prueba de velocidad.

Anote la dirección, la pérdida, el jitter, el tiempo de ida y vuelta y la condición en la que se midió cada uno. Ese registro convierte una queja vaga sobre la calidad de la llamada en un hallazgo sobre el que alguien puede actuar. Guárdelo con el tique para que la siguiente comparación empiece desde la misma línea base.