Cómo medir la calidad de una llamada

Cuando trabajamos con VoIP, somos conscientes de que estamos trabajando con una tecnología digital, formada por un flujo de datos dedicado a señalización, y otro flujo de datos dedicado a media esto es: audio, vídeo, archivos, etc. Todo es digital por lo que el ruido electromagnético que suele afectar a la información transmitida por líneas analógicas no nos afecta en este caso, y además es IP, de manera que en cada dispositivo inteligente routers, switches, etc, existen herramientas de verificación de datos que comprueban que lo que entra por un puerto, sale por otro exactamente igual y en el menor tiempo posible. No obstante, hay motivos por los que, durante una conversación, nos interesa conocer la calidad de audio a fin de descubrir fallos, problemas y ponerles solución.

El 80% de las veces, los errores de audio suelen ser debido a problemas de calidad de servicio o ancho de banda insuficiente. Generalmente esto se soluciona configurando QoS en el router, separando las redes de VoIP y la de datos a fin de que «las actualizaciones de windows no se coman el ancho de banda de una llamada». un 5% de las veces suele ser por problemas con auriculares de mala calidad (micrófonos demasiado cerca de la boca, lo que provoca un volumen excesivo y ruidos propios del movimiento de la boca que son capturados por el micrófono).

Imagina que estás trabajando, haces una llamada y esta se escucha entrecortado… ¿por qué ocurre? ¿cómo se puede solucionar? seguramente diremos que es por falta de ancho de banda, o algún cuello de botella pero, ¿ y si no es eso?.

Necesitamos medir la calidad de una llamada a fin de garantizar que las conversaciones tienen la calidad mínima exigible. Esa medición debe ser objetiva y comprobable, de ahí que tengamos que adentrarnos en un tema nuevo.

Para medir la calidad de una llamada tenemos que conocer algunos conceptos clave en el mundo de las comunicaciones VoIP:

• Latencia : Es el retraso que hay desde el microsegundo en el que llega el sonido al micrófono de nuestro teléfono, hasta que sale por el altavoz del microteléfono del receptor. Esta latencia suele ser inferior a 100ms y cuando es más (<200ms.) se nota que hay cierta espera entre un turno de palabra y el siguiente, pero sigue permitiendo una conversación más o menos fluida. Cuando esa cantidad de tiempo aumenta (al utilizar redes de alta latencia como enlaces vía satélite) es mucho más complicado establecer una conversación normal y hay que hablar por turnos declarados para evitar pisarse con respuestas a frases antiguas.
• Jitter : Si la latencia es siempre la misma, se puede mantener una conversación simplemente esperando un segundo entre el fin de la frase y el comienzo de la siguiente. Pero si la latencia varía cada segundo, mantener una conversación es sumamente difícil. Más aún cuando esto provoca pérdida de paquetes debido a que hay paquetes nuevos que llegan antes que otros más antiguos. Es como decir: -«Voy a comprar pan» y que «pan» llege antes que «comprar», de manera que el sistema receptor, elimina «comprar» y escucharías «Voy a … pan»
• Paquetes perdidos : Por muchos motivos, un paquete puede desaparecer: demasiado tiempo en ser transmitido (cada paquete tiene un TTL -tiempo de vida- que si es superado, el paquete es eliminado por estar obsoleto y ser inútil), ruido en la señal digital que provoca cambios y que fomentan que dicho paquete sea desechado por haber sufrido cambios durante el viaje, etc. Esto provocan problemas en el audio similares a lo comentado antes: microcortes de audio de unos 20~30 milisegundos, tiempo suficiente para que se aprecie un corte de audio si estamos escuchando música, pero apenas perceptible si estamos en una conversación con paradas, pausas entre palabra y palabra, o si somos conscientes que nuestro interlocutor no tiene una buena conexión. Hay códecs que permite «autocompletar» el audio que falta, con lo que obtendremos esa sensación de audio «metálico» o «robótico» que seguro que hemos experimentado todos.
• Ancho de banda: Si el ancho de banda es insuficiente, los paquetes tardarán en llegar al destinatario, lo que implica que haya latencia, o bien que los paquetes sean perdidos, por lo que tendremos una conversación con retraso y microcortes. En función del códec utilizado necesitaremos más o menos ancho de banda, de ahí que para conexiones limitadas, se recomiende utilizar codecs especiales como GSM, G729, iLBC, Speex, etc. en lugar de los G711, G722, G726, etc.

Una vez aclarados estos conceptos y problemas, tenemos que ver cómo medir la calidad de una conversación VoIP y para ello haremos uso del «Protocolo RTCP»

Protocolo RTCP

El protocolo RTCP (RealTime Control Protocol) lleva, como su nombre indica, un control sobre el tráfico Realtime, de manera que analizando el tráfico RTCP podemos ver muchos factores que afectan a la calidad de audio. En Asterisk podemos obtener esta información de cada llamada habilitando el debug del RTCP:

rtcp set debug on

Tras este comando, empezaremos a ver paquetes de este tipo:

SSRC of sender: 698304002
NTP timestamp: 2085979081.0338186240
RTP timestamp: 2072023812
SPC: 29242 SOC: 4678720
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 25818
Sequence number cycles: 1
Interarrival jitter: 0.0032
Last SR(our NTP): 0.0000000000
DLSR: 0.0000 (sec)
RTT: 0.3180(sec)

Para entender algunos datos, hay que saber qué significan algunos campos:

Packets lost: Son los paquetes perdidos. Si está a cero significa que no hay paquetes perdidos por lo tanto, el audio es correcto: Todos los paquetes enviados han sido recibidos.

RTT (Round Trip Time): Viene a ser la latencia. Esto suele tener un valor constante (entre el timestamp del emisor y el timestamp del receptor). Si esta latencia varía, se transforma en el Jitter que hemos comentado antes.

Interarrival Jitter: La variación de la latencia utilizando para ellos los últimos paquetes enviados y recibidos. El jitter se mide en tiempo. Para entenderlo: si todos los paquetes enviados en el segundo 1, son recibidos en el segundo 4, la latencia es (4-1) 3, y el jitter es 0. Ahora bien, si la latencia es 3, la siguiente es 4, la siguiente es 5, la siguiente es 6,… el jitter es 1. Por suerte, el jitter suele ocurrir porque hay variación entre la latencia de un paquete y del siguiente, pero no siempre va a aumentar la latencia: si la latencia es 3, la siguiente es 4, la siguiente es 2, la siguiente es 3, etc… el Interarrival jitter es una media entre los valores jitter, por lo que suele estar entre 0 y 1 y puede solucionarse utilizando «jitter buffer» en el teléfono o en el Asterisk. ¿Qué valores debemos configurar el jitter buffer para que sea óptimo? Este es un tema que ya lo trataremos otro día.

Si queréis conocer el significado del resto de información del RTCP, podéis verlo aquí.

Valores de medición

Ya han sido explicados los conceptos básicos de la calidad de audio, pero claro, no es interesante tratar valores puntuales para analizar todo el audio de una conversación, ya que pueden ocurrir problemas en 1 segundo de la conversación pero ser perfecta el resto del tiempo. Por lo que analizando los valores puntuales durante toda la conversación, podemos obtener medidas más prácticas e interesantes:

Class of Service (CoS): Mide el % de los paquetes que llegan a ambos extremos durante toda la conversación. Lo ideal es que llegue el 100% de los paquetes (CoS = 100%) pero si tenemos valores similares tampoco es un drama (>95%).

Mean Opinion Score (MOS): Es una de las medidas más utilizadas para conocer la calidad de una conversación. Mide los valores de paquetes perdidos, jitter y latencia y genera un valor promedio que oscila entre 1 y 5. Un valor por debajo de 3.5 se considera problemático mientras que un valor superior a 4.5 se considera una llamada normal con buena calidad.

R-Factor: Es una medida similar al MOS, utilizada como recomendación de la ITU y basada en los mismos factores que puntúan la calidad entre 0 y 100 tal y como se puede ver en la tabla siguiente:

Herramientas de análisis y medición

Existen herramientas que analizan el tráfico y muestran, no solo la «traza SIP» de la conversación, si no también los valores de medida de la calidad de esta, datos detallados de la llamada (paquetes perdidos, tiempos de respuesta, latencia, jitter, etc…)

Existía uno bastante bueno aunque comercial, llamado VQManager. Por desgracia, como ocurre con el software comercial, el software se descontinúa, abandona y desaparece en lugar de ser liberado.

Por suerte, existe más herramientas que analizan esta información y ofrecen resultados muy interesantes:

• Homer SIP Capture: http://sipcapture.org/ (Opensource)
• VoIPMonitor: http://www.voipmonitor.org/ (Opensource)
• Recqual: https://sourceforge.net/projects/recqual/ (Opensource)
• AQua: http://sevana.biz/products/aqua/
• VoIPSpear: https://www.voipspear.com/
• CommView: http://www.tamos.com/products/commview/