Problemas de calidad de llamadas VoIP: cómo diagnosticar las cinco áreas de falla y corregirlas

Cuando un cliente reporta una mala llamada, lo primero útil que se necesita saber es qué tipo de problema es. Una llamada que nunca se conectó es un problema de señalización (SIP). Una llamada que se conectó pero no tuvo audio es un problema de ruta de medios. Una llamada que se conectó, tuvo audio en ambas direcciones y aun así sonó mal es lo que cubre este artículo: un problema de calidad de audio, donde cada área por debajo del audio parece estar funcionando y el resultado audible sigue siendo deficiente.

Las quejas de calidad de audio casi siempre se resuelven en una sola causa subyacente: una de cinco áreas de calidad está fallando a lo largo de la ruta de la llamada. Cada área deja una huella diferente en las estadísticas de medios por llamada, cada una suena diferente para el oyente y cada una tiene su propia solución. La disciplina de diagnóstico consiste en asociar el síntoma con el área y luego aplicar la corrección que aborda esa causa específica.

Este artículo continúa donde la guía de resolución de problemas VoIP más amplia deja el tema y profundiza en cada área. Para el lado operativo de detectar estos problemas antes que los suscriptores, la guía de mejores prácticas de monitoreo VoIP es la referencia complementaria.

Qué significa realmente “audio deficiente”: las cinco áreas

Una queja de “la llamada sonó mal” casi siempre se resuelve en uno de cinco problemas de calidad distintos. Tratarlos como áreas separadas es la diferencia entre un diagnóstico que funciona y uno que cambia configuraciones al azar hasta que llega el siguiente ticket.

Las cinco áreas son pérdida de paquetes, jitter, retardo unidireccional, artefactos de códec y transcodificación, y eco. Cada una tiene una firma audible diferente, un rastro de evidencia diferente en RTCP y CDR, y una ruta de remediación diferente. Más de un área puede fallar en la misma llamada, pero en la práctica operativa un área es casi siempre la contribuyente dominante y corregirla lleva la llamada de vuelta a una calidad aceptable por sí sola.

El resto de este artículo recorre cada área en orden: qué produce la falla, cómo suena, cómo confirmarla con la evidencia disponible y qué cambiar realmente.

Área 1: pérdida de paquetes

La voz es en tiempo real. No hay retransmisión. Un paquete que no llega a tiempo se pierde, y el receptor tiene que sintetizar un reemplazo o reproducir silencio durante ese intervalo. Cualquier pérdida sostenida por encima de aproximadamente el 1 por ciento se vuelve audible, y por encima del 3 por ciento la llamada es difícil de seguir.

La firma audible son palabras cortadas, breves intervalos de silencio, estallidos ocasionales o artefactos de inicio, y una sensación “robótica” mientras el PLC intenta llenar los huecos. Los suscriptores lo describen como “la llamada se cortaba constantemente” o “cada pocos segundos perdía una palabra”.

La primera evidencia a leer es el informe del receptor RTCP de cada lado, o el porcentaje equivalente de pérdida en el CDR por llamada del SBC. Si la pérdida está por encima del 1 por ciento en una dirección y cercana a cero en la otra, la ruta en la dirección afectada es la sospechosa. Si la pérdida es bilateral, ambas direcciones comparten un salto congestionado, generalmente en algún punto intermedio de la ruta del operador.

Las causas se agrupan en un conjunto pequeño en operaciones reales. La congestión WAN en una ruta específica del operador es la más común, y generalmente se manifiesta como picos de pérdida durante horas laborales en llamadas enrutadas por esa troncal mientras otras troncales permanecen limpias. Las microráfagas en un enlace sobrevendido producen el mismo resultado audible pero con ráfagas de pérdida demasiado breves para ver en promedios, solo visibles en PCAP. Los desajustes de MTU y la fragmentación IP tienden a destruir paquetes de tamaños específicos de forma sistemática. La inestabilidad de ruta en la trayectoria BGP upstream produce ventanas de pérdida breves pero severas que se repiten. El Wi-Fi en el lado LAN es su propia fuente de pérdida y casi nunca es visible desde el SBC.

Las rutas de corrección son aproximadamente en este orden. Verifique que el marcado DSCP se esté aplicando en la interfaz del SBC y que el marcado sea realmente respetado por cada salto intermedio. Muchos operadores descubren durante una investigación de calidad que DSCP se configuró hace años y una actualización de enrutador en algún punto de la ruta dejó de respetarlo. Re-enrute las llamadas afectadas a través de una troncal alternativa para confirmar que la pérdida es específica de la ruta, no de la plataforma. Si el SBC lo admite, habilite la corrección de errores hacia adelante (FEC) en el tramo que enfrenta la red con pérdida. Revise la carga en el enlace upstream y descargue tráfico que no sea de voz si la voz y las transferencias masivas comparten una cola. Para la pérdida por Wi-Fi, la única solución real es Ethernet cableado en los teléfonos afectados, lo cual es una conversación con el equipo de LAN más que un cambio en el SBC.

Una nota específica sobre el comportamiento de los códecs bajo pérdida. G.711 (PCM) envía muestras de audio sin comprimir y no tiene PLC nativo integrado en el flujo de bits estándar, por lo que cuando se pierde un paquete, se pierde un fragmento de audio sin procesar con él. G.729 y códecs predictivos similares incluyen mecanismos PLC que intentan mantener la continuidad de la señal de voz cuando se pierden tramas.

Área 2: jitter

Si la pérdida de paquetes se refiere a paquetes que nunca llegan, el jitter se refiere a paquetes que llegan en el momento equivocado. Los códecs de voz envían un paquete cada 20 milisegundos (con un ptime típico de 20 ms), y el receptor los espera en esa cadencia. Cuando el tiempo entre llegadas varía, el búfer de jitter del lado receptor absorbe la variación hasta su tamaño configurado y luego descarta los paquetes tardíos o estira el audio para esperarlos.

La firma audible es audio inestable y fluctuante con cortes ocasionales, a veces descrito como “robótico” o “bajo el agua”. A menudo coexiste con pérdida de paquetes de bajo nivel porque un búfer de jitter que ha excedido su capacidad descarta los paquetes que llegan tarde, los cuales aparecen como pérdida en el informe RTCP.

La evidencia a leer es el campo de jitter en el informe del receptor RTCP y en el CDR. Cualquier valor por debajo de 20 ms es cómodo para casi cualquier búfer. Entre 20 y 50 ms, la calidad percibida depende en gran medida de la configuración del búfer. Por encima de 50 ms, el MOS caerá por debajo de 3.5 para la mayoría de los códecs independientemente del ajuste del búfer.

Las causas son diferentes de las causas de pérdida de paquetes, lo cual es parte de por qué las dos áreas se separan claramente. La profundidad variable de la cola en un salto intermedio es la fuente más grande: un enrutador que prioriza la voz cuando su cola es corta pero ignora la prioridad cuando la cola se llena. La programación inconsistente de QoS en un salto virtualizado produce el mismo efecto dentro de un hipervisor. La privación de CPU en un PBX, SBC o pasarela de medios virtualizado introduce jitter incluso cuando la red subyacente está limpia, porque los paquetes permanecen en la pila de red del host esperando tiempo de vCPU. El enrutamiento asimétrico donde las dos mitades de la llamada toman rutas diferentes puede producir jitter unidireccional que el informe bidireccional RTCP dificulta atribuir.

El búfer de jitter es en sí mismo un contribuyente frecuente a la calidad percibida, en ambas direcciones. Si está subdimensionado, descarta paquetes tardíos y produce cortes audibles. Si está sobredimensionado, agrega latencia que el oyente experimenta como Área 3 (retardo unidireccional) y reporta como un problema separado en un ticket posterior. La mayoría de los receptores modernos utilizan búferes de jitter adaptativos que se redimensionan dentro de límites configurados. Un búfer adaptativo no se queda simplemente en su techo de 200 ms; se ajusta al jitter observado real y tiende a mantenerse alrededor de 60 a 80 ms, la profundidad inicial más un margen. El techo de 200 ms es un límite, no un objetivo, y la latencia innecesaria solo aparece cuando el búfer está mal ajustado o el algoritmo sobredimensiona agresivamente.

Las rutas de corrección comienzan con el propio búfer de jitter si el receptor está bajo control del operador. Establezca límites adaptativos que coincidan con el perfil real de la ruta medido sobre una muestra representativa. Si el salto variable es identificable desde traceroute o telemetría por salto, aplique o corrija QoS en ese salto. Si el SBC o PBX está virtualizado y se sospecha privación de CPU, fije los vCPU y reserve memoria, o mueva la carga de trabajo a hardware dedicado. Si la ruta cruza una región de enrutamiento asimétrico conocida (los clientes empresariales multihomed son los infractores habituales), anclar los medios en el SBC divide la llamada en dos tramos de red distintos y manejables, lo cual aísla el jitter a un segmento específico y evita que se acumule de extremo a extremo.

Área 3: latencia (retardo unidireccional)

El retardo de extremo a extremo es la más silenciosa de las cinco áreas porque no necesariamente hace que el audio suene mal. Lo que hace es volver la conversación inviable. Por encima de 150 ms unidireccional, los interlocutores comienzan a hablar encima del otro; por encima de 250 ms unidireccional, la conversación se siente como una llamada satelital; por encima de 400 ms, el habla normal es imposible. La norma ITU-T G.114 define estos umbrales, y se aplican a toda la ruta de boca a oído, no solo al segmento del operador.

La firma audible no es distorsión. El llamante y el receptor reportan pausas incómodas, interrupciones, repetidos “¿sigue ahí?”, y una sensación general de que la conversación está desfasada. Rara vez describirán el audio en sí como malo.

La evidencia a buscar es el campo de retardo unidireccional en las estadísticas de calidad del SBC. El operador solo ve y controla el segmento de la ruta que cruza el SBC. Los segmentos restantes (procesamiento del códec del lado LAN, reproducción del búfer de jitter, ruta del operador del extremo lejano) deben estimarse o medirse por separado.

Las causas son en gran parte aditivas. La distancia geográfica contribuye retardo de propagación física (aproximadamente 1 ms por cada 100 km en fibra, más si la ruta hace desvíos de enrutamiento). Los ciclos de codificación y decodificación agregan de 10 a 30 ms por paso dependiendo del códec, y cada salto de transcodificación agrega otro ciclo completo. El propio búfer de jitter es un elemento de retardo, típicamente de 40 a 100 ms en una ruta bien ajustada y sustancialmente más si está sobredimensionado. Los tramos satelitales agregan de 240 a 280 ms en cada dirección. El acceso móvil (3G especialmente, pero también LTE y 5G) agrega de 50 a 150 ms en el lado radio que el operador de red fija no puede reducir.

Las rutas de corrección consisten en acortar los contribuyentes que el operador controla. Reduzca los saltos de transcodificación ajustando la política de códec por NAP para que el SBC negocie un códec común cuando sea posible en lugar de hacer puente entre dos diferentes. Implemente un SBC regional más cerca de la base de clientes para que el segmento de la ruta del operador sea corto. Reajuste el búfer de jitter si se ha medido como el contribuyente dominante. Para un centro de contacto alojado que atiende llamantes en distintos continentes, dividir el tráfico en múltiples SBC regionales es a menudo la única vía hacia un retardo conversacional aceptable.

Área 4: artefactos de códec y transcodificación

A veces la llamada tiene condiciones de red limpias, jitter normal, baja pérdida, retardo unidireccional razonable, y el audio aún suena mal. El sospechoso restante es el códec en sí, o la cadena de códecs por la que ha pasado el audio.

Las firmas audibles varían. La codificación en tándem a través de un códec de baja tasa de bits produce una calidad hueca y procesada que los suscriptores describen como “metálica” o “como teléfono viejo”. El colapso de banda ancha a banda estrecha produce una caída repentina en la fidelidad que es obvia para cualquiera que haya estado escuchando al mismo llamante en una ruta de banda ancha previamente. Los códecs CS-ACELP (familia G.729) manejan bien la voz limpia y se degradan bruscamente con ruido de fondo, música en espera, sibilantes y cualquier señalización dentro de banda como tonos de fax o DTMF dentro de banda.

La evidencia está en el SDP y el CDR. El rastreo de llamada del SBC muestra el códec negociado en cada tramo de la llamada. Si el tramo entrante es G.711, el tramo saliente es G.729, y un tercer salto aguas abajo recodifica de vuelta a G.711, esos son dos pasos en tándem a través de un códec con pérdida en una sola llamada. El campo MOS en el CDR reflejará la pérdida acumulada aunque todas las demás métricas de calidad se lean como limpias. La comparación G.711 vs G.729 profundiza en la aritmética de MOS por códec.

Las causas se derivan de cómo funciona la negociación SDP. Cuando cada lado ofrece un códec que se superpone, la llamada procede sin transcodificación. Cuando las ofertas no se superponen, el SBC tiene que transcodificar, lo que significa un ciclo completo de decodificación y recodificación por cada 20 ms de audio durante toda la duración de la llamada. La codificación en tándem ocurre cuando la misma llamada se transcodifica nuevamente en un salto aguas abajo, generalmente porque la política de otro operador obliga un códec diferente en el siguiente tramo. El colapso de banda ancha ocurre cuando cualquier tramo de banda estrecha está en algún lugar de la ruta; Opus o AMR-WB en los terminales no sobrevive un segmento de tránsito G.711 en el medio.

Las rutas de corrección se centran en la política de códec. Configure las preferencias de códec por NAP para que el SBC negocie un códec común siempre que ambos lados lo admitan, eliminando el salto de transcodificación por completo. Para rutas premium donde el ancho de banda no es la restricción, fuerce G.711 de extremo a extremo para evitar la pérdida perceptual de los códecs comprimidos. Donde la transcodificación sea inevitable, empújela a un solo punto en la ruta y evite que los tramos posteriores recodifiquen. Para rutas móvil-a-IP, la guía de transcodificación SBC AMR a G.711 cubre las consideraciones específicas de calidad y DSP.

Área 5: eco

El eco es el área con mayor probabilidad de ser diagnosticada erróneamente como otra cosa. Los suscriptores se quejan de que se escuchan a sí mismos, o de que la otra parte reporta escucharse a sí misma, y el primer instinto suele ser revisar las métricas de códec o red. Ninguna mostrará nada anormal, porque el eco es un artefacto de la ruta de medios que reside en un área diferente a las cuatro ya cubiertas.

La firma audible es que el llamante escucha una copia retardada de su propia voz. Solo afecta una dirección de la llamada a la vez: la parte cuyo audio se está reflejando de vuelta experimenta el problema, y la otra parte no. El eco que siempre estuvo presente a niveles bajos se vuelve audible cuando la latencia en la ruta aumenta, porque el oído humano deja de percibir el eco cuando el retardo cae por debajo de aproximadamente 25 ms (el audio se fusiona con el habla original) y comienza a percibirlo con claridad por encima de 50 ms.

La evidencia es más difícil de leer en RTCP y CDR. El MOS puede o no reflejar el eco, dependiendo de si la estimación de calidad por llamada incluye medición de eco. La evidencia más clara es la naturaleza unilateral de la queja: la parte A escucha su propia voz, la parte B no escucha nada anormal, y las métricas de ambas mitades de la llamada se ven normales.

Las causas están casi siempre en el límite analógico. Una conversión de 2 hilos a 4 hilos en un híbrido analógico produce eco eléctrico que debería ser cancelado por un cancelador de eco en la pasarela del lado troncal. Cuando el cancelador falta, está mal ajustado o tiene una longitud de cola insuficiente para la ruta, el eco residual se filtra. La otra fuente es el eco acústico en el terminal: un altavoz abierto, un auricular mal ajustado, o un teléfono sostenido lejos del oído, con el audio del extremo lejano filtrándose de vuelta al micrófono local.

Las rutas de corrección comienzan identificando el tramo que introduce el híbrido. Las pasarelas PSTN y los límites TDM-a-IP son los infractores habituales. Verifique que el cancelador de eco esté habilitado en ese tramo, que su longitud de cola esté configurada para el retardo de la ruta, y que las mediciones de ERL (echo return loss) y ERLE (echo return loss enhancement) estén dentro de rangos aceptables. Si el eco solo apareció en llamadas que antes estaban limpias, busque un cambio reciente que haya agregado latencia a la ruta; el eco siempre estuvo ahí a niveles bajos y la nueva latencia lo desenmascaró. Para el eco acústico, la única solución real es cambiar cómo se usa el terminal o reemplazar el auricular.

El flujo de trabajo diagnóstico

Leer las cinco áreas en orden proporciona un árbol de decisión confiable para cualquier queja activa.

Comience con la evidencia de RTCP y CDR para la llamada afectada. Lea cuatro números: porcentaje de pérdida, jitter, retardo unidireccional (o RTT dividido entre dos) y MOS. Si la pérdida está por encima del 1 por ciento en cualquier dirección, el problema es el Área 1 y el siguiente paso es encontrar la ruta que toma la dirección con pérdida. Si el jitter está por encima de 20 ms y tiende hacia 50 ms, el problema es el Área 2 y el siguiente paso es identificar el salto variable o el búfer de jitter subajustado. Si el retardo unidireccional está por encima de 150 ms, el problema es el Área 3 y el siguiente paso es descomponer el retardo en sus contribuyentes aditivos. Si los cuatro números son normales pero el MOS está por debajo de 3.5, el problema es el Área 4, y el rastreo de llamada mostrará la negociación de códec en cada tramo. Si la queja especifica que una parte se escucha a sí misma mientras la otra no, y las demás métricas están limpias, el problema es el Área 5, y el límite analógico en la dirección afectada es el sospechoso.

Cuando más de un área está por encima del umbral, corrija el contribuyente dominante primero y vuelva a medir. Una llamada con 2 por ciento de pérdida y 30 ms de jitter se leerá mejor después de corregir la pérdida incluso si el jitter no ha cambiado; perseguir ambos simultáneamente confunde la evidencia.

Cuando la evidencia disponible no puede identificar un área de forma concluyente, la siguiente escalación es un PCAP por llamada en la interfaz del SBC durante la queja, abierto en Wireshark con las herramientas de análisis RTP. PCAP es la verdad de base cuando CDR y RTCP no coinciden.

Lo que NO reside en el SBC

El SBC tiene visibilidad del segmento de la llamada que cruza sus interfaces y muy poca visibilidad de todo lo demás. Ese límite importa por dos razones prácticas.

Los problemas de terminales del lado LAN están fuera de la ventana de medición del SBC. Un teléfono en un enlace Wi-Fi congestionado, un softphone ejecutándose en una laptop con privación de CPU, un auricular con cancelación de eco acústico degradada, o un AGC mal configurado en el terminal producirán quejas de calidad que parecen no atribuibles desde el SBC. El SBC puede demostrar que la llamada estaba limpia en su interfaz; el siguiente paso es del equipo de LAN o del proveedor del terminal.

Las rutas del operador del lado lejano también están fuera de la ventana de medición. Si un operador aguas abajo está descartando paquetes en su red central, el SBC verá la pérdida en el informe RTCP entrante pero no tendrá detalle más allá de eso. El mejor paquete para entregar a un operador aguas abajo al escalar un problema de pérdida en la red central es un PCAP de doble extremo, o una captura tomada justo en el límite de ingreso/egreso del SBC. Los tickets vagos permanecen en la cola; los tickets con evidencia concreta avanzan más rápido. Para la visión más amplia de cuándo y cómo empaquetar una escalación, la guía de resolución de problemas VoIP cubre la escalación con operadores en detalle.

Cómo ProSBC ayuda a resolver problemas de calidad de llamadas VoIP más rápido

ProSBC está diseñado en torno a la realidad operativa de que las quejas de calidad llegan y tienen que diagnosticarse rápidamente. El MOS por llamada se calcula de forma nativa en el SBC, con los campos subyacentes de jitter, pérdida y retardo unidireccional expuestos en cada registro CDR tanto para exportación de texto como RADIUS. El desglose en áreas es lo que hace que el flujo de trabajo diagnóstico anterior sea utilizable sin sondas externas ni herramientas de síntesis.

La captura de paquetes en vivo compatible con Wireshark se puede habilitar por llamada o por NAP sin reiniciar nada, lo que significa que la evidencia PCAP está disponible en el momento en que llega un ticket. El rastreo de llamadas SIP muestra el códec negociado en cada tramo, exponiendo la codificación en tándem y los desajustes de códec que producen quejas del Área 4. El motor de enrutamiento programable por API admite política de códec por NAP, que es el punto de control práctico para gestionar saltos de transcodificación en una red multi-operador. La transcodificación por hardware mediante Tmedia está disponible para entornos donde se requiere calidad de grado DSP en transcodificaciones AMR, Opus o G.729 a escala.

Para proveedores que desean el área de panel de control sin construirlo ellos mismos, Monitoring as a Service integra las métricas de calidad por llamada en un panel administrado con alertas en tiempo real. Para operadores que desean delegar completamente el trabajo de diagnóstico, el nivel de Managed Service incluye ProSBC+ con alta disponibilidad 1+1, soporte Level 3 24×7, cambios de configuración continuos y monitoreo continuo.