Pérdida de paquetes en VoIP: cómo afecta la calidad de las llamadas y cómo la mitiga el SBC

Cuando una llamada se entrecorta, pierde sílabas o se vuelve irregular a mitad de una frase, la causa es casi siempre la pérdida de paquetes. No un códec inadecuado, no una señal débil, no el teléfono de la otra persona. En algún punto entre los dos terminales, fragmentos del audio salieron de un lado y nunca llegaron al otro.

En este artículo le explicaremos qué es realmente la pérdida de paquetes en VoIP, por qué la voz se ve mucho más afectada que los datos convencionales, cómo se mide, los umbrales en los que las llamadas comienzan a deteriorarse y dónde encaja un controlador de borde de sesión (SBC) en la detección y contención del problema. Si usted administra infraestructura de voz y recibe tickets de “la llamada se escuchaba terrible”, esta es la capa donde esos tickets se resuelven.

Qué es realmente la pérdida de paquetes

La pérdida de paquetes es la falla de uno o más paquetes de datos en llegar a su destino a través de una red IP. Se mide como porcentaje de los paquetes enviados: si se envían 1,000 paquetes y llegan 980, eso es un 2% de pérdida de paquetes. En la práctica, “perdido” abarca tres casos. Un paquete puede no llegar nunca, puede llegar tan tarde que el receptor ya avanzó y lo descarta, o puede llegar corrupto y ser descartado. Desde la perspectiva del oyente, los tres suenan igual.

Es útil separar la pérdida de paquetes de sus dos parientes cercanos. La latencia es retardo, el tiempo que tarda un paquete en viajar de extremo a extremo. El jitter es la variación en ese retardo, paquetes que llegan con espaciado irregular. La pérdida de paquetes es ausencia, el paquete simplemente no está. Los tres interactúan; un jitter alto puede convertirse en pérdida cuando un paquete llega demasiado tarde para ser utilizado, pero son problemas distintos con soluciones distintas.

Los medios de voz viajan sobre el Real-time Transport Protocol (RTP), definido en RFC 3550. Cada paquete RTP lleva un número de secuencia y una marca de tiempo, que es lo que hace que la pérdida sea detectable en primer lugar: cuando el receptor ve que el paquete 41 llega justo después del paquete 39, sabe que el paquete 40 se perdió.

Por qué la pérdida de paquetes afecta más a la voz que a los datos

El tráfico de datos convencional, como la descarga de un archivo o una página web, funciona sobre TCP, que retransmite cualquier cosa que se pierda. Si se pierde un paquete, TCP simplemente lo envía de nuevo. El archivo llega intacto, solo un poco más lento, y usted nunca lo nota.

La voz no puede funcionar de esa manera. Una conversación en vivo funciona sobre UDP y RTP sin retransmisión, porque un paquete de audio que llega 300 milisegundos tarde es inútil. El momento que debía llenar ya pasó. Pedirlo de nuevo solo empeoraría el retardo. Así que cuando un paquete RTP se pierde, permanece perdido, y el audio que transportaba simplemente desaparece.

Cada paquete RTP normalmente contiene alrededor de 20 milisegundos de sonido. Un solo paquete perdido es un vacío de 20 milisegundos, que se escucha como un leve clic o una consonante cortada. Si se pierden paquetes de forma dispersa y constante, el cerebro compensa la mayoría de ellos. El daño real proviene de la pérdida en ráfaga, varios paquetes consecutivos perdidos a la vez, que deja un vacío lo suficientemente largo como para tragarse una palabra completa. Por eso dos llamadas con la misma cifra de 2% de pérdida pueden sonar completamente diferentes: la que pierde paquetes en ráfagas es mucho peor que la que los pierde al azar.

Cómo se mide la pérdida de paquetes y qué se considera aceptable

La pérdida se expresa como porcentaje de paquetes RTP, y el receptor la calcula a partir de los vacíos en esos números de secuencia. El protocolo complementario de RTP, RTCP, transporta estas estadísticas de vuelta para que ambos extremos, y cualquier dispositivo en la ruta de medios, puedan ver cómo se está comportando una llamada en tiempo real.

El otro número que importa es el Mean Opinion Score (MOS), la calificación estándar de 1 a 5 de la calidad de voz percibida. La pérdida de paquetes es una de las mayores variables en un cálculo de MOS, junto con el jitter y la latencia, por lo que la pérdida generalmente se manifiesta como un MOS en descenso antes de que alguien presente una queja. El MOS está en el centro de cualquier enfoque serio de monitoreo de VoIP.

Como guía aproximada, y es solo una guía porque el códec en uso cambia las cifras, una pérdida inferior a aproximadamente el 1% es generalmente aceptable en una llamada estándar con G.711. Entre el 1% y el 3% se vuelve perceptible, con palabras cortadas ocasionalmente. Por encima de aproximadamente el 5%, la mayoría de las llamadas son inutilizables. Estos umbrales están ampliamente publicados, pero el punto para un operador es más simple: usted no debería estar adivinando dónde se ubican sus llamadas en esa escala. Las cifras provienen de estadísticas RTP por llamada, y si no las está recopilando, está navegando a ciegas.

Qué causa la pérdida de paquetes en redes de voz

La congestión de red es la causa más común. Cuando un enlace se queda sin capacidad, las colas que lo alimentan se desbordan y el enrutador no tiene más opción que descartar paquetes. La voz, al ser pequeña y constante, queda atrapada en el mismo desbordamiento que todo lo demás, a menos que esté protegida.

Esa protección es el segundo problema. En un enlace sin política de calidad de servicio (QoS) y sin marcado DSCP, los paquetes de voz compiten en igualdad de condiciones con tráfico masivo como respaldos y transferencias de archivos, y una sola transferencia grande puede privar de recursos a una llamada. Más allá de la congestión, los sospechosos habituales son las transiciones inalámbricas y de última milla (interferencia Wi-Fi y circuitos de acceso sobrecargados), anomalías de enrutamiento que envían paquetes por el camino largo o hacia un agujero negro, y fallas de hardware como una NIC defectuosa o un puerto de switch intermitente. Finalmente, existe la pérdida autoinfligida: enviar más llamadas simultáneas a través de un dispositivo de medios de las que fue provisionado para manejar, causando que descarte paquetes por cuenta propia. Cuando la pérdida aparece, un proceso estructurado de resolución de problemas de VoIP es lo que separa una solución rápida de una interrupción prolongada.

Cómo un SBC detecta y contiene la pérdida de paquetes

Aquí es donde un controlador de borde de sesión demuestra su valor en una red de voz. Un SBC opera como un back-to-back user agent (B2BUA), lo que significa que termina la relación de señalización en un lado y origina una nueva en el otro, en lugar de simplemente reenviar paquetes. Cuando se encuentra en la ruta de medios, puede medir la pérdida RTP en cada tramo de forma independiente.

Esa independencia es lo más útil que un SBC aporta a la resolución de problemas de pérdida de paquetes. Una queja genérica como “la llamada se escuchaba mal” no indica dónde está el problema. Pero si el SBC muestra RTP limpio en el tramo de acceso hacia su cliente y pérdida elevada en el tramo del operador, el problema es del operador, y usted puede escalar con evidencia en lugar de iniciar un juego de adivinanzas. Si las lecturas son inversas, el problema está de su lado.

ProSBC expone esta visibilidad directamente. Produce puntuaciones MOS por llamada junto con cifras de jitter y pérdida de paquetes, y las pone a disposición mediante SNMP y salida de CDR (Call Detail Record), para que los datos fluyan hacia cualquier plataforma de monitoreo que usted ya utilice. Para inspección profunda también admite captura de paquetes en vivo y rastreo completo de llamadas SIP y RTP, lo que permite a un ingeniero extraer los paquetes reales de una llamada problemática en lugar de trabajar a partir de contadores resumidos. TelcoBridges cuenta con más de veinte años de experiencia en implementación de SIP y medios detrás de esta capacidad, y ProSBC maneja medios a escala de operador.

El SBC también le ofrece dos mecanismos para prevenir la pérdida en lugar de solo observarla. La negociación de códec permite al SBC seleccionar un códec adecuado para el enlace, ya que un códec de menor tasa de bits en una conexión restringida genera menos carga y deja más margen. El control de admisión de llamadas limita el número de sesiones simultáneas, lo que evita que la ruta de medios sea llevada a la pérdida inducida por congestión descrita anteriormente. Utilizados en conjunto, mantienen la pérdida autoinfligida fuera de la ecuación.

Una advertencia honesta: un SBC no puede crear ancho de banda, ni puede recuperar audio que una red de terceros ya descartó. Lo que sí hace es medir la pérdida con precisión, localizarla en un segmento específico y prevenir las condiciones de sobrecarga que causan pérdida dentro de su propia infraestructura. En las operaciones diarias, eso es la mayor parte de la batalla.

Reducción de la pérdida de paquetes en la práctica

Algunos hábitos mantienen la pérdida bajo control. Primero, aprovisione y priorice: marque el RTP con el valor DSCP correcto para que reciba prioridad QoS, y deje un margen de ancho de banda real en lugar de operar los enlaces al límite. Dimensione correctamente su capacidad de llamadas simultáneas y aplíquela con control de admisión, para que un pico de tráfico se rechace en la puerta en lugar de degradar cada llamada en curso. Adapte los códecs al enlace, eligiendo una opción de menor tasa de bits donde el ancho de banda sea limitado. Sobre todo, monitoree de forma continua en lugar de reactiva, porque las estadísticas por llamada exponen una tendencia antes de que lo hagan los clientes. Y cuando la pérdida aparezca, localícela con datos por segmento antes de escalar, para que la conversación con su operador comience desde los hechos.

Preguntas frecuentes

Conclusión

La pérdida de paquetes es audio faltante, sonido que la red debía entregar y no entregó. La voz lo sufre de manera aguda porque, a diferencia de la descarga de un archivo, no puede esperar un segundo intento. Una tasa de pérdida de apenas unos pocos puntos porcentuales es suficiente para arruinar una llamada, y la pérdida en ráfaga es peor de lo que el porcentaje solo sugiere. La salida es la medición y la localización: conozca sus cifras de pérdida por llamada y sepa qué segmento es responsable antes de actuar.