3. EVALUACIÓN DINAMICA DE QOS EN EL CLIENTE...
34
Página 20 3. EVALUACIÓN DINAMICA DE QOS EN EL CLIENTE PJSIP 3.1. Introducción a QoS en VoIP Como UDP no proporciona un mecanismo para asegurar que los paquetes de datos son enviados en orden secuencial ni garantiza una calidad de servicio, las implementaciones de VoIP tienen problemas con la latencia y el jitter. Para evitar este problema el nodo receptor debería reestructurar los paquetes IP que lleguen desordenados, retrasados o perdidos, mientras que asegura que la trama de audio mantiene una temporización adecuada. Esta funcionalidad es realizada por un elemento denominado buffer de jitter. Los principales retos de VoIP a los que tiene que hacer frente para garantizar una cierta calidad QoS del servicio a continuación son: - Retraso/latencia - Paquetes perdidos - Jitter La latencia es un parámetro que afecta a las transmisiones realizadas mediante VoIP. Existen dos tipos de retardo: - Los retrasos fijos no pueden ser controlados debido a que las características de la red varían. Se producen en los procesos de transmisión del paquete por los distintos dispositivos de la red, como pueden ser: la codificación, la creación de paquetes, la red y buffer de jitter. - Los retrasos variables son los producidos debido a las colas de salida y a los retrasos de la red. El tráfico de voz es un tráfico en tiempo real, un gran retraso en la entrega de los paquetes de voz provoca que la conversación no sea entendible. Se puede determinar que un retraso aceptable tiene que ser inferior a 250 milisegundos. Este retardo máximo total se distingue en tres tipos de retraso que son inherentes en las redes de telefonía: - Retraso de propagación: es causado por la velocidad de la luz viajando por un medio de fibra óptica o por un medio de cobre. - Retraso del buffer de jitter: transforma los retrasos variables a retrasos fijos ya que deja colgada la primera muestra que recibe durante un periodo de tiempo antes de enviarla. La contribución del buffer del jitter al retraso es que a parte del retraso propio de jitter que la trama posee se le está añadiendo otro retraso debido a este buffer. - Retraso de transmisión: es causado por los aparatos que manejan la información de voz, es la cantidad de tiempo que tarda en ponerse un bit o byte en un interfaz de red. Este retraso es directamente influido por la velocidad del reloj del interfaz y por el tamaño del paquete.
Transcript of 3. EVALUACIÓN DINAMICA DE QOS EN EL CLIENTE...
Página 20
3. EVALUACIÓN DINAMICA DE QOS EN EL CLIENTE PJSIP
3.1. Introducción a QoS en VoIP
Como UDP no proporciona un mecanismo para asegurar que los paquetes de datos
son enviados en orden secuencial ni garantiza una calidad de servicio, las
implementaciones de VoIP tienen problemas con la latencia y el jitter. Para evitar este
problema el nodo receptor debería reestructurar los paquetes IP que lleguen
desordenados, retrasados o perdidos, mientras que asegura que la trama de audio
mantiene una temporización adecuada. Esta funcionalidad es realizada por un elemento
denominado buffer de jitter.
Los principales retos de VoIP a los que tiene que hacer frente para garantizar una
cierta calidad QoS del servicio a continuación son:
- Retraso/latencia
- Paquetes perdidos
- Jitter
La latencia es un parámetro que afecta a las transmisiones realizadas mediante VoIP.
Existen dos tipos de retardo:
- Los retrasos fijos no pueden ser controlados debido a que las características de la
red varían. Se producen en los procesos de transmisión del paquete por los
distintos dispositivos de la red, como pueden ser: la codificación, la creación de
paquetes, la red y buffer de jitter.
- Los retrasos variables son los producidos debido a las colas de salida y a los
retrasos de la red.
El tráfico de voz es un tráfico en tiempo real, un gran retraso en la entrega de los
paquetes de voz provoca que la conversación no sea entendible. Se puede determinar que
un retraso aceptable tiene que ser inferior a 250 milisegundos. Este retardo máximo total
se distingue en tres tipos de retraso que son inherentes en las redes de telefonía:
- Retraso de propagación: es causado por la velocidad de la luz viajando por un
medio de fibra óptica o por un medio de cobre.
- Retraso del buffer de jitter: transforma los retrasos variables a retrasos fijos ya que
deja colgada la primera muestra que recibe durante un periodo de tiempo antes de
enviarla. La contribución del buffer del jitter al retraso es que a parte del retraso
propio de jitter que la trama posee se le está añadiendo otro retraso debido a este
buffer.
- Retraso de transmisión: es causado por los aparatos que manejan la información
de voz, es la cantidad de tiempo que tarda en ponerse un bit o byte en un interfaz
de red. Este retraso es directamente influido por la velocidad del reloj del interfaz
y por el tamaño del paquete.
Página 21
- Retraso de procesamiento incluye muchas diferentes causas de retraso, (paquetización, codificación y conmutación de paquetes) y es causado por aparatos que transmiten las tramas a través de la red.
La pérdida de paquetes es otro de los factores determinantes, ya que puede ocurrir
por muchas razones, y en algunos casos es inevitable, pero la principal causa es debido a la
congestión de la red. Durante la congestión los routers y switches pueden sobrepasar sus
colas y descartar paquetes. Otra causa que provoca la pérdida de paquetes es un exceso de
latencia, un grupo de paquetes llega tarde y deben ser descartados en favor de los nuevos.
Los paquetes perdidos de las aplicaciones que no son de tiempo real no son críticos. Estas
aplicaciones suelen usar TCP (Transmisión Control Protocol) [RFC793] que permite
retransmisión, no supondría un gran problema. Sin embargo, las aplicaciones basadas en
tiempo real como UDP son menos tolerantes a la pérdida de paquetes porque no tienen
posibilidad de retransmisión.
La consecuencia que provoca la pérdida de paquetes es que se producen vacios en la
conversación. La ventaja que tienen los paquetes de VoIP es que su longitud es corta, la
pérdida de esta pequeña cantidad de diálogo no empeora la conversación de los
interlocutores. Pero probabilísticamente la pérdida de un paquete significa la pérdida de
varios paquetes, este hecho sí degrada severamente la calidad del servicio de una red
VoIP. Este fenómeno es conocido como pérdidas en ráfagas (burst).
Se determina que un porcentaje tolerable de pérdida de paquetes se centra entre 1%
y 3% y la calidad empieza a ser intolerable cuando más del 3% de los paquetes de voz se
han perdido.
El último de los factores determinantes en la evaluación de la calidad en VoIP es el
retardo producido por el jitter. Este se define como la variación del tiempo de llegada
entre paquetes. Mientras el que envía está esperando transmitir fiablemente los paquetes
de voz a un intervalo regular, debido a los problemas que se pueden producir en la red,
como son la congestión, la longitud de las colas demasiado largas o los errores, estos
paquetes de voz pueden retrasarse a través de la red y no llegar con el mismo intervalo a
la estación receptora. Este hecho provoca una discontinuidad en la trama de la voz de
tiempo real. El efecto del jitter afecta al retraso y a la pérdida de paquetes, como se
comentó anteriormente, puede ser mitigado si se van guardando los paquetes de voz en un
buffer.
Las aplicaciones de voz son muy susceptibles a estas variaciones ya que es un
parámetro que degrada cuantiosamente la calidad de la voz y modifica el diálogo. Lo que
influye directamente en la QoS de la VoIP. El jitter se produce normalmente en redes que
tienen un ancho de banda de baja capacidad. Puede causar que los paquetes a su llegada al
receptor sean procesados fuera de secuencia.
El jitter puede incluso afectar en mayor medida a la QoS que el propio retraso de los
paquetes. Si el jitter es alto, los paquetes llegan a su destino a ráfagas. Cuando los routers
reciben una trama de VoIP, compensan el jitter que encuentran. Tienen que ser capaces de
almacenar en un buffer estos paquetes y reenviarlos con el mismo espaciado entre cada
uno de ellos, para reducir el jitter. Si la magnitud de jitter es tan grande que los paquetes
Página 22
son recibidos fuera del rango del buffer, entonces son descartados provocando la pérdida
de paquetes.
Vistos los principales parámetros que nos condicionan la calidad en una llamada de
VoIP, necesitamos de algún modo evaluar dicha calidad mediante el cómputo de los
parámetros anteriormente descritos. De este modo, para evaluar la calidad del audio, la
ITU-T provee un modelo para su cálculo mediante la recomendación G.107 [ITUG.107],
comúnmente conocida como modelo-E. La implementación de este modelo se realiza
mediante la recolección de parámetros de retardo total (jitter y retardos de red) y
pérdidas contenidos en los informes RTCP. Así, gracias a este modelo es viable conseguir
los valores de medición de calidad perseguidos a partir, únicamente, de los mencionados
estadísticos de pérdidas y retardos. Para tal efecto se dispone de las ecuaciones que
conforman el modelo y que se detallan a continuación.
La ecuación principal determina el factor R, que es la puntuación de calidad
resultante de la aplicación del modelo a los datos de entrada. Posteriormente, dicha
puntuación puede ser traducible a una escala MOS. El factor R está constituido por R0, que
representa la señal a ruido básica que incluye fuentes de ruido tales como ruido de circuito
y ruido de ambiente; Id representa las degradaciones producidas por el retardo, y el factor
de degradación efectiva del equipo Ie-eff incluye la degradación debida a pérdidas de
paquetes.
𝑅 = 𝑅0 − 𝐼𝑑 − 𝐼𝑒−𝑒𝑓𝑓
El término R0 se considera constante, su valor se ha fijado a 93,2. Esto implica que,
aunque las degradaciones fuesen nulas, el máximo valor alcanzable por el factor es igual a
dicha constante. En cambio, los valores de Id e Ie-eff se subdividen en parámetros más
específicos.
El factor de degradación por retardo posee una ecuación simplificada que se basa en
evaluar el retardo de red que sufren los paquetes transmitidos, expresado en
milisegundos. Este factor Id se calcula entonces como
𝐼𝑑 = 0,024 · 𝑑 + 0,11 · 𝑑 − 177,3 · 𝐻 𝑑 − 177,3
donde d es el retardo total observado por los paquetes de VoIP, mientras que H es la
función de Heavyside tal que H(x) = 0 para x < 0 y 1 para x ≥ 0.
Una vez calculado el factor de degradación por retardo pasamos a hacer lo propio
con el factor de degradación efectiva. Este depende de unos valores tabulados mediante
pruebas para intentar aproximarse al valor real de la forma más precisa posible. Entre los
valores tabulados se hallan el factor de degradación del equipo para pérdida de paquetes
Página 23
nula Ie y el factor de robustez contra pérdida de paquetes Bpl. Así, eligiendo los valores
predefinidos para cada códec, y recogidos en la tabla 1, se obtiene Ie-eff como sigue
𝐼𝑒−𝑒𝑓𝑓 = 𝐼𝑒 + 95 − 𝐼𝑒 ·𝑃𝑝𝑙
𝑃𝑝𝑙
𝐵𝑢𝑟𝑠𝑡𝑅+ 𝐵𝑝𝑙
donde Ppl es un parámetro variable adimensional que mide la probabilidad de pérdidas de
paquetes (expresada en tanto por cien) que se produce en una conversación de VoIP. La
variable BurstR es un parámetro adimensional también que mide las pérdidas de paquetes
producidas a ráfagas en una conversación.
TABLA 1: VALORES DE IE Y BPL PARA LOS DISTINTOS CÓDECS
BurstR es el burst ratio y es la última modificación añadida por la ITU-T para
optimizar los resultados en base al comportamiento presentado por las pérdidas de
paquetes. Relaciona la longitud de las ráfagas de pérdida de paquetes con la longitud de las
ráfagas ante pérdidas aleatorias. Es por ello que siempre su valor es superior a la unidad,
salvo cuando las pérdidas presentan una distribución aleatoria que entonces el resultado
es uno.
Para medirlo de forma eficaz se define el tamaño medio de las ráfagas de paquetes
perdidos B, medido en términos de tramas perdidas. Así, finalmente el parámetro BurstR
queda expresado de la siguiente forma:
𝐵𝑢𝑟𝑠𝑡𝑅 = 𝑚𝑎𝑥{ 1, 𝐵 · 1 −𝑃𝑝𝑙
100 }
Página 24
El segundo término se corresponde con la propia expresión proporcionada por la
recomendación para distribuciones de pérdidas de paquetes en cadenas de Markov de dos
estados.
3.2. Evaluación de QoS en PJSIP
En este apartado veremos los diferentes procedimientos para evaluar los
parámetros de pérdidas y retardos que intervienen en la evaluación de QoS. Para ello, se
han utilizado diversos archivos originales de PJSIP que han sido modificados para lograr
implementar diversas funciones en ellos que nos permitan lograr los objetivos de
evaluación de calidad perseguidos. Estos archivos se encuentran alojados en el directorio
archivos/modificaciones del CD adjunto y pueden ser utilizados sobre el código original
atendiendo a las instrucciones contenidas en el Anexo B. Instrucciones sobre las
modificaciones a PJSIP.
Para poder determinar la calidad de la conversación ofrecida por PJSIP se van a
tener en cuenta los siguientes parámetros:
- Paquetes perdidos
- Duración de las ráfagas de pérdidas
- Retardo de red
- Retardo en el buffer de jitter en recepción
- Retardo de empaquetado
Estos parámetros se encuentran implementados por PJSIP en una serie de
estructuras de datos propias donde almacena unos estadísticos a los cuales accederemos
desde distintas funciones implementadas en los archivos de código fuente. De este modo,
podremos lograr estimar parámetros de retardo y pérdidas de paquetes durante una
conversación. Estas estructuras de datos que utilizaremos se encuentran implementadas
en el código en base a las estructuras que define el protocolo RTP/RTCP desarrollado en la
RFC 3550.
El protocolo RTCP se vale de informes (SR/RR y XR) donde evalúa parámetros
relativos a la calidad del audio y que envía cada cierto tiempo al extremo emisor para
llevar un control de dicha calidad.
En la RFC 3550 se describe como se computa el intervalo entre informes RTCP, que
llamaremos T. Esta computación sigue un algoritmo que tiene en cuenta diversos factores
tales como el número de emisores en cada sesión, el ancho de banda dedicado al control
de la llamada, el tiempo desde el último informe, el tamaño del informe, etc. Este algoritmo
estima el intervalo T en función de estos parámetros para optimizar el ancho de banda que
se utiliza para señalización respecto al utilizado para la comunicación vocal. Para ello la
RFC 3550 recomienda un intervalo mínimo Tmin entre informes RTCP de 5 segundos. De
este modo, se limita la frecuencia máxima de envío de informes RTCP. En la
implementación de PJSIP se define este valor a 5 segundos en el fichero “config.h”
contenido en el directorio archivos/pjproject1.14/pjmedia/include/pjmedia del CD adjunto.
Página 25
# define PJMEDIA_RTCP_INTERVAL 5000 /* msec*/
Solo es posible enviar un informe RTCP SR/RR con un tiempo inferior a Tmin, cuando
se trate del primer informe RTCP al inicio de una conversación o después de un re-Invite,
ya que no hay referencia de un informe RTCP anterior. En la RFC 3550 se define el valor
para este primer intervalo como la mitad de Tmin.
Por tanto, para nuestro caso con un Tmin de 5 segundos deducimos que el primer
informe RTCP se enviará a los 2,5 segundos, mientras que el resto de informes se enviarán
con un periodo mayor o igual a 5 segundos. En la figura 11 podemos comprobar cómo
estos valores se corresponden con lo esperado para cada uno de los dos tipos de informes
RTCP durante una llamada de 130 segundos.
FIGURA 11: INTERVALO ENTRE INFORMES RTCP
Se observa como el primer informe RTCP SR/RR se produce a los 2,5 segundos,
mientras que el resto se produce con intervalos superiores a los 5 segundos. Se observa
también como el intervalo de los informes extendidos RTCP XR es mayor, ya que aportan
una información más ampliada y consumen más recursos de ancho de banda.
Para tener una idea de la duración media del intervalo entre informes RTCP, Tmedio,
se han analizado 40 llamadas de 60 segundos de duración cada una. En estas medidas
realizadas no se produce ningún re-Invite durante la conversación. Los resultados son los
siguientes:
Página 26
Tmedio (s)
Informe RTCP SR/RR 5,25
Informe RTCP XR 7,64
TABLA 2: DURACIÓN MEDIA DEL INTERVALO ENTRE INFORMES RTCP
En estos cálculos no se ha tenido en cuenta el primer informe emitido, que como ya
sabemos, se envía a los 2,5 segundos del comienzo de la llamada. Los resultados obtenidos
indican que en media los informes RTCP SR/RR se envían con mayor frecuencia que los
informes RTCP XR.
Una vez estimada la frecuencia con la que obtendremos los informes RTCP,
utilizaremos los estadísticos que se estiman en dichos informes para evaluar parámetros
de retardos y pérdidas de paquetes. Concretamente evaluaremos el retardo total sufrido
por los paquetes (tanto en la red como en los buffers de los equipos), la probabilidad de
pérdida de un paquete y la duración de las ráfagas de pérdidas durante el intervalo entre
informes RTCP.
A partir de ahora hablaremos del extremo local como el host cliente encargado de
recopilar los estadísticos de los paquetes que recibe del extremo remoto. El extremo
remoto será entonces el otro host cliente que transmite los paquetes en cuestión.
3.2.1. Evaluación del retardo de red
Para la medida del retardo de red se suele emplear el RTT (Round Trip Time), sobre
todo para evaluar el efecto sobre la interactividad, que tiene lugar sobre los 350-400
milisegundos, por lo que medidas de RTT resultan más fiable que medidas de retardo
unidireccional.
La evaluación del RTT es realizada utilizando los paquetes RTCP, donde mediante el
protocolo NTP (Network Time Protocol), se envía marca de tiempo con el instante en el que
fue enviado. Como se utiliza NTP, es de suponer que ambos equipos comparte el mismo
reloj. Tras analizar en qué instante llegó la trama y cuando fue generada, un equipo
concluye el RTT que está experimentando de la siguiente forma:
𝑅𝑇𝑇 = 𝐴 − 𝐷𝐿𝑆𝑅 − 𝐿𝑆𝑅
Donde A es el instante de llegada al receptor del informe RTCP, mientras que LSR es
el instante en el que fue generado ese informe RTCP en el emisor y DLSR es el retraso que
mide el emisor entre el último informe RTCP recibido y el que informe que genera. En la
figura 12 se puede observar un ejemplo de este cómputo.
Página 27
FIGURA 12: EVALUACIÓN DE RTT
La evaluación de este estadístico se realiza en el archivo fuente “rtcp.c”, en la función
“pjmedia_rtcp_rx_rtcp()”, que se llama cada vez que se recibe un informe RTCP mediante la
fórmula descrita anteriormente. De esta forma cada vez que nos disponemos a enviar un
informe RTCP consultamos el valor de dicho estadístico para obtener el último valor
almacenado de RTT.
Un inconveniente que se deriva de este método es que si la aplicación tiene retardos
como por ejemplo el buffer al enviar los paquetes a la red, se miden como retardos de red,
ya que las marcas de tiempo se generan al construirse el paquete. La solución adoptada es
medir el retardo de forma independiente con un ping al destino y de esta forma analizar y
comparar las estadísticas que devuelve.
3.2.2. Evaluación del retardo de empaquetado y retardo en el buffer
de jitter
Para la evaluación del retardo de empaquetado, la forma más fiable es utilizar la
estimación de RemoteNfpp y multiplicarla por el tiempo de trama. Así, cada cierto tiempo
dado por el valor anterior se envía un paquete RTP a la red, ignorando el retardo de
transmisión que será mucho menor. Este retardo de empaquetado es el tiempo que tiene
que esperar un paquete en el transmisor antes de ser enviado, ya que tiene que esperar al
resto de tramas para completar el paquete RTP. De esta manera se estima el retardo de
empaquetado delayemp(T) durante un intervalo T como
𝑑𝑒𝑙𝑎𝑦𝑒𝑚𝑝 (𝑇) = 𝑟𝑒𝑚𝑜𝑡𝑒𝑁𝑓𝑝𝑝 (𝑇) · 𝑇𝑡𝑟𝑎𝑚𝑎
La evaluación del retardo de buffer de jitter no resulta sencilla. En la actual
implementación, este valor se tiene en cuenta al realizar el informe RTCP XR, para lo cual
Página 28
se consulta el estado del buffer, y su estadístico que nos ofrece el valor medio. Dicho
estadístico es reseteado tras cada envío de paquetes RTCP XR.
Para conocer el retardo medio que sufren las tramas en el buffer, PJSUA se vale del
estadístico que almacena el tamaño de buffer, framelist_size. Este estadístico proporciona
el número de tramas contenidas en el buffer de jitter y se modifica cada vez que inserta
una trama en el buffer o cada vez que la retira para reproducirla.
PJSUA recalcula el valor de framelist_size mediante un número de secuencia que se
asigna a cada trama cuando se pone en el buffer. Este cómputo se realiza de la siguiente
manera
𝑓𝑟𝑎𝑚𝑒𝑙𝑖𝑠𝑡_𝑠𝑖𝑧𝑒 = 𝑖𝑛𝑑𝑒𝑥 − 𝑜𝑟𝑖𝑔𝑖𝑛 + 1
Donde index se corresponde con el número de secuencia que se asocia a la trama
que se acaba de insertar en el buffer y origin se corresponde con el número de secuencia
asociado a la primera trama del buffer, la cual espera a ser enviada al códec para ser
reproducida. El cálculo puede apreciarse de manera más nítida en la siguiente ilustración
FIGURA 13: FUNCIONAMIENTO BUFFER DE JITTER
La anterior evaluación del tamaño del buffer se realiza en el archivo fuente “jbuf.c”
dentro de “jb_framelist_put_at( )”, una subfunción que se llama cada vez que se recibe una
trama y se inserta en el buffer.
Por otra parte, PJSUA también modifica el valor de framelist_size decrementandolo
cuando se retira una trama de buffer. Además, incrementa el valor de origin para así saber
cuál es la siguiente trama que espera a ser reproducida.
𝑓𝑟𝑎𝑚𝑒𝑙𝑖𝑠𝑡_𝑠𝑖𝑧𝑒 − −
𝑜𝑟𝑖𝑔𝑖𝑛 + +
Página 29
Este computo anterior se realiza en el archivo fuente “jbuf.c” dentro de
“jb_framelist_get( )”, una subfunción que se llama cada vez que se retira una trama del
buffer.
PJSUA mide el retardo medio en el buffer de jitter solo cuando retira una trama de
este y siempre que la última operación realizada haya sido poner una trama en el buffer.
Para ello utiliza una variable auxiliar, curr_delay, que nos proporciona el retardo que se
observa cada vez que se extrae una trama. Este retardo se computa de la siguiente forma
𝑐𝑢𝑟𝑟_𝑑𝑒𝑙𝑎𝑦 = 𝑓𝑟𝑎𝑚𝑒𝑙𝑖𝑠𝑡_𝑠𝑖𝑧𝑒 · 𝑇𝑡𝑟𝑎𝑚𝑎
Solo se computa curr_delay justo después de que se inserte un paquete en el buffer y
se retire una trama de este, ya que anteriormente se ha puesto un paquete completo en el
buffer. Así, si se retiran varias tramas consecutivamente después de la llegada de un
paquete, el estadístico curr_delay solo se evalúa la primera vez, y no vuelve a ser evaluado
hasta que no se ponga un nuevo paquete en el buffer. Por tanto, curr_delay se evalúa cada
vez que llega un paquete al buffer y el intervalo de actualización de este estadístico
dependerá del número de tramas del paquete que se reciba y de la duración de estas. Por
ejemplo, si se reciben paquetes con remoteNfpp igual a 8 y la duración de las tramas es de
10 milisegundos, se obtendrá un valor de curr_delay cada 80 milisegundos.
Una vez evaluado curr_delay, se pasa a la función “pj_math_stat_update()” que va
calculando la media acumulativa de esta variable. Para computar el retardo medio durante
un intervalo se resetean las estadísticas cada vez que se envía un informe RTCP. De este
modo, obtenemos el retardo medio en el buffer de jitter para un intervalo de medida T,
que llamaremos delaybuff(T).
El valor de delaybuff(T) se evalúa en el archivo fuente “jbuf.c” en la función
“pjmedia_jbuf_get_frame()”, que se llama cuando se quiere retirar una trama del buffer.
Cuando se inicia un flujo de paquetes RTP, el buffer de jitter espera a que le llegue
un determinado número de tramas antes de retirar ninguna, con el fin de asegurarse de
que siempre va a tener tramas disponibles para reproducir. De este modo el buffer
introduce un retardo inicial al inicio de la conversación que viene dado por el número de
tramas que acumula antes de reproducir ninguna. Este mismo efecto se produce después
de largos periodos de silencio que terminan por vaciar el buffer, ya que no se reciben
tramas durante ellos.
El número de tramas que espera el buffer antes de retirar ninguna viene
determinado por el modo de operación con el este funcione. El buffer de jitter puede
operar en dos modos de funcionamiento: fijo o adaptativo. En el modo fijo, el buffer espera
a que le llegue siempre un determinado número de tramas fijo, mientras que en el modo
adaptativo este valor puede variar en cada caso dependiendo de la duración de las tramas
que se reciben. Por defecto, PJSUA establece un buffer adaptativo.
De este modo se intenta compensar el efecto de la variación del retardo de red y las
pérdidas de paquetes, que producirán una variación en la tasa de llegadas de paquetes a lo
largo del tiempo de llamada.
Página 30
La variable curr_delay nos está midiendo el retardo que existe en el buffer justo
después de que llegue un paquete. Por tanto, este estadístico nos mide siempre realmente
la duración del paquete (remoteNfpp · Ttrama) que acaba de llegar más la duración de las
tramas que había antes de que llegara el paquete, que llamaremos BufferPO. Esta última
variable es realmente el tiempo que tiene que esperar el paquete al llegar al buffer para
ser reproducido.
𝑐𝑢𝑟𝑟_𝑑𝑒𝑙𝑎𝑦 = 𝑟𝑒𝑚𝑜𝑡𝑒𝑁𝑓𝑝𝑝 · 𝑇𝑡𝑟𝑎𝑚𝑎 + 𝐵𝑢𝑓𝑓𝑒𝑟𝑃𝑂
De esta forma se llega a la conclusión de que curr_delay, que nos proporciona el
retardo en el buffer de jitter ya está contabilizando siempre el retardo de empaquetado en
su medida, ya que cada vez que llega un paquete añade su duración total al buffer
(RemoteNfpp · Ttrama). De esta forma, en el caso de que el buffer estuviera siempre vacio y
llegara un paquete, este no esperaría nada (BufferP0=0), su retraso solo sería el de
empaquetado. Así, el retraso por empaquetado y el retraso en el buffer de jitter pueden
obtenerse a través de curr_delay y de su media para cada intervalo, delaybuff(T),
proporcionado cada vez que enviamos un informe RTCP.
𝑑𝑒𝑙𝑎𝑦𝑏𝑢𝑓𝑓 𝑇 = 𝑑𝑒𝑙𝑎𝑦𝑒𝑚𝑝 𝑇 + 𝐵𝑢𝑓𝑓𝑒𝑟𝑃𝑂(𝑇)
3.2.3. Evaluación del retardo total
Una vez definidos los retardos de red, retardo de empaquetado y retardo en el
buffer de jitter, solo queda calcular el retardo total que sufren los paquetes. Este retardo
total se refiere al retardo que observa un paquete desde que es emitido por el códec de voz
en el extremo transmisor hasta que llega al extremo receptor y es reproducido.
El retardo total entonces puede ser descompuesto como la suma del retardo de
empaquetado, el retardo en la red al atravesarla y el retardo en el buffer de jitter mientras
espera a ser reproducida. Como se ha comentado en su respectivo apartado, el retardo en
el buffer de jitter ya incluye en su medida el efecto del retardo de empaquetado, por lo que
la expresión más acertada para definir el retardo total es la siguiente
𝑑 𝑇 =𝑅𝑇𝑇
2 + 𝑑𝑒𝑙𝑎𝑦𝑏𝑢𝑓𝑓 𝑇
Donde RTT es el último retardo de ida y vuelta medido cada vez que se envía un
informe RTCP, mientras d(T) será el retardo total que sufren los paquetes en un intervalo
de medida T entre informes RTCP.
De esta forma hemos obtenido una medida fiable del retraso d(T) para cada
intervalo. Este retraso total se evalúa en el archivo fuente “rtcp_xr.c” dentro de la función
“pjmedia_rtcp_build_rtcp_xr()” cada vez que vamos a construir un paquete RTCP XR para
enviarlo al extremo remoto.
Página 31
3.2.4. Evaluación de las pérdidas de paquetes
Para evaluar las pérdidas de paquetes en un periodo concreto, existen dos
alternativas que se explican más abajo. Estos dos métodos se valen de los dos tipos de
informes RTCP emitidos por un equipo para calcular mediante los estadísticos que
contienen, la probabilidad de pérdida de paquetes.
3.2.4.1. FractionLoss
La métrica FractionLoss considera la relación entre los paquetes recibidos en un
intervalo y los que deberíamos haber recibido, es decir, los paquetes esperados. Mediante
estos valores estima las pérdidas producidas en ese intervalo. El cómputo de estos
estadísticos se realiza cada vez que vamos a construir un paquete RTCP SR/RR para
enviarlo al extremo remoto tal como se define en el protocolo RTCP. Esta métrica,
implementada dentro del código, se evalúa en el archivo fuente “rtcp.c” dentro de la
función “pjmedia_rtcp_build_rtcp()” .
Para hallar el número de paquetes esperados por el extremo local en cada intervalo se compara el número de paquetes totales esperados respecto al número de paquetes totales esperados en el anterior intervalo de la siguiente forma
𝑒𝑥𝑝𝑖𝑛𝑡 (𝑇) = 𝑒𝑥𝑝 𝑇 − 𝑒𝑥𝑝(𝑇 − 1)
donde expint (T) es el número de paquetes esperados en un intervalo entre informes
RTCP, exp (T) es el número actual de paquetes esperados totales hasta el actual intervalo
de medida T y exp (T-1) es el número de paquetes esperados totales hasta el anterior
intervalo de medida.
El número de paquetes esperados totales exp (T), se calcula mediante la secuencia
de control base y la última secuencia recibida en un paquete RTP. Este número de
secuencia de control base es creado de forma aleatoria por parte del extremo remoto (el
emisor de paquetes) al inicio de la sesión RTP, de forma que el extremo local conoce este
valor desde el momento en que recibe el primer paquete RTP y obtiene el primer número
de secuencia recibido. El número de secuencia de cada paquete RTP aumenta de forma
unitaria desde el inicio hasta el final de cada llamada conforme estos paquetes se van
generando. De este modo, el número de paquetes esperados totales hasta el actual
intervalo se calcula como
𝑒𝑥𝑝 𝑇 = 𝑙𝑎𝑠𝑡𝑠𝑒𝑞 (𝑇) − 𝑐𝑡𝑟𝑙𝑠𝑒𝑞
donde lastseq es el número de secuencia recibido en el último paquete RTP del
intervalo de medida y ctrlseq es la secuencia de control base que se recibió en el primer
paquete RTP. Estos dos estadísticos quedan registrados en el equipo local cada vez que se
recibe un paquete RTP. Concretamente son modificados en el archivo fuente “rtcp.c” en la
función “pjmedia_rtcp_rx_rtp()”, que se llama cada vez que llega un paquete RTP de forma
correcta.
Página 32
El número de paquetes esperados en el anterior intervalo exp (T-1), es actualizado
con el valor del estadístico de paquetes esperados exp (T) justo después de que se estime
expint (T), para poder así calcular los paquetes esperados en el próximo intervalo.
𝑒𝑥𝑝 𝑇 − 1 = 𝑒𝑥𝑝 𝑇
Ahora de la misma forma que para los paquetes esperados, se calcula el número de
paquetes recibidos por el extremo local en cada intervalo comparándose el número de
paquetes totales recibidos respecto al número de paquetes totales recibidos en el anterior
intervalo de la siguiente forma
𝑟𝑥𝑖𝑛𝑡 (𝑇) = 𝑟𝑥 𝑇 − 𝑟𝑥(𝑇 − 1)
donde rxint (T) es el número de paquetes recibidos en un intervalo entre informes
RTCP, rx (T) es el número de paquetes recibidos totales hasta el actual intervalo de medida
T y rx (T-1) es el número de paquetes recibidos totales hasta el anterior intervalo de
medida.
Para el cálculo de rx (T), el extremo local lleva un contador que se consulta cada vez
que se requiere el envío de un informe RTCP SR/RR. Este contador se incrementa cada vez
que llega un paquete con un nuevo número de secuencia. Se modifica este estadístico en el
archivo fuente “rtcp.c” en la función “pjmedia_rtcp_rx_rtp()”, que se llama cada vez que
llega un paquete de forma correcta.
El número de paquetes recibidos en el anterior intervalo rx (T-1), es actualizado con
el valor del estadístico de paquetes recibidos rx (T) cuando se estima rxint (T) para calcular
los paquetes recibidos en el próximo intervalo.
𝑟𝑥 𝑇 − 1 = 𝑟𝑥 𝑇
Conocidos los paquetes los paquetes recibidos y los que se deberían haber recibido
en cada intervalo, podemos estimar los paquetes perdidos en cada intervalo de la
siguiente forma
𝑙𝑜𝑠𝑡𝑖𝑛𝑡 𝑇 = 𝑒𝑥𝑝𝑖𝑛𝑡 (𝑇) − 𝑟𝑥𝑖𝑛𝑡 (𝑇)
donde lostint(T) es el número de paquetes perdidos en un intervalo T.
De esta forma si en un intervalo estimamos que deberíamos haber recibido 100
paquetes pero solo tenemos 90 recibidos, estimamos que se han perdido 10 paquetes.
Las pérdidas de paquetes en un intervalo cualquiera, viene determinada de la
siguiente manera
𝐹𝑟𝑎𝑐𝑡𝑖𝑜𝑛𝐿𝑜𝑠𝑠 (𝑇) =𝑙𝑜𝑠𝑡𝑖𝑛𝑡 𝑇
𝑒𝑥𝑝𝑖𝑛𝑡 (𝑇)
Página 33
donde FractionLoss es la probabilidad de pérdida de paquetes hallada durante un
intervalo T entre informes RTCP SR/RR.
Siguiendo con el ejemplo anteriormente mencionado, la probabilidad de perdida se
calcularía como el cociente de 10 paquetes perdidos entre los 100 los paquetes que
deberíamos haber recibido, lo que se corresponde a un 10 % de pérdidas.
Una vez analizado el método de cálculo de paquetes perdidos nos centraremos en
definir diferentes imperfecciones o detalles que pueden influir en las estimaciones
pertinentes.
Uno de estos detalles se observa cuando se envía un re-Invite, cosa que ocurre cada
vez que cambia el número de tramas por paquete. El problema es que se resetea cualquier
estadístico de paquetes recibidos y esperados .Así, cuando se genera el siguiente informe
RTCP SR/RR sólo se contabilizan los paquetes recibidos totales desde el re-Invite. El re-
Invite provoca también que se tome como nuevo número de secuencia base, ctrlseq, el
indicado por el último número se secuencia recibido antes del re-Invite. De la misma
forma, sólo se contabilizan los paquetes esperados porque como se ha mencionado
anteriormente estos se calculan mediante la diferencia entre el último número de
secuencia recibido y el nuevo número de secuencia base, que ha sido modificado a partir
del re-Invite.
El que el resultado de la estimación este sesgado en mayor o menor medida depende
de cómo de distintas fueran las pérdidas en cada uno de los conjuntos de paquetes. Así, si
durante ese intervalo que no se ha contabilizado en los estadísticos se produce por
ejemplo una ráfaga de pérdidas elevada y en el intervalo que si se contabiliza no se
produce perdida alguna, el informe dará como resultado que no ha habido pérdidas,
cuando si se han producido y han afectado a la calidad de la llamada. En el caso opuesto,
pueden no producirse pérdidas durante el primer intervalo en el que no se contabilizan y
producirse pérdidas elevadas en el segundo que si se contabilizan, obteniéndose un valor
de pérdidas más elevado del que realmente se produce. Este efecto puede ser desacoplado
de cara al algoritmo de optimización del número de tramas por paquete mediante la
desestimación del primer informe RTCP SR/RR después de un re-Invite, ya que como
hemos mencionado, puede contener resultados no fiables.
Además, los informes RTCP SR/RR que se envían cuando se inicia un flujo de
paquetes RTP (comienza una llamada) y cuando se produce un re-Invite contabilizan un
número más reducido de paquetes debido a que el intervalo de medida es la mitad en
estos casos. El efecto de obtener un estadístico de un número de muestras tan bajo es otro
motivo para desconfiar de la fiabilidad de este primer informe RTCP SR/RR.
Otro detalle que afecta a la estimación de los paquetes perdidos es que tampoco se
contabilizan los paquetes recibidos ni esperados entre el último informe SR/RR y el
mensaje SIP BYE que provoca la finalización de la sesión RTP (finalización de la llamada).
La omisión de estos paquetes en la contabilizad de los paquetes perdidos no afectan
debido a que la llamada ha terminado y no se hace necesario corregir el numero de tramas
por paquete en el algoritmo de optimización.
Página 34
3.2.4.2. RatioLoss
La métrica RatioLoss relaciona los paquetes recibidos y perdidos en el intervalo
entre cada dos informes RTCP XR. De esta forma, obtenemos el estadístico de pérdidas de
paquetes. La métrica es implementada dentro del código y se evalúa en el archivo
“rtcp_xr.c” dentro de la función “pjmedia_rtcp_build_rtcp_xr()” cada vez que vamos a
construir un paquete RTCP XR para enviarlo al extremo remoto, tal como se define en el
protocolo RTCP.
Mediante la comparación de los paquetes recibidos en el actual intervalo y los
recibidos en el anterior, obtenemos la estimación de paquetes recibidos en un intervalo
como
𝑟𝑥𝑝𝑘𝑡𝑖𝑛𝑡 (𝑇) = 𝑟𝑥𝑝𝑘𝑡 𝑇 − 𝑟𝑥𝑝𝑘𝑡 (𝑇 − 1)
donde rxpkt (T) es el número de paquetes recibidos totales hasta el actual intervalo
T, rxpkt (T-1) es el número de paquetes recibidos totales hasta el anterior intervalo y
rxpktint (T) es el número de paquetes totales recibidos en el intervalo T.
Para el cálculo de rxpkt(T), el extremo local lleva un contador que se consulta cada
vez que se requiere el envío de un informe RTCP SR/RR. Este contador se incrementa cada
vez que llega un paquete RTP con un nuevo número de secuencia. Se modifica este
estadístico en el archivo fuente “rtcp.c” en la función “pjmedia_rtcp_rx_rtp()”, que se llama
cada vez que llega un paquete RTP de forma correcta.
Ahora mediante la comparación de los paquetes perdidos en el actual intervalo y los
perdidos en el anterior, obtenemos la estimación de paquetes perdidos en un intervalo
como
𝑙𝑜𝑠𝑠𝑖𝑛𝑡 (𝑇) = 𝑙𝑜𝑠𝑠 𝑇 − 𝑙𝑜𝑠𝑠 (𝑇 − 1)
donde loss (T) es el número de paquetes perdidos totales hasta el actual intervalo T,
loss (T-1) es el número de paquetes perdidos totales hasta el anterior intervalo y lossint (T)
es el número de paquetes totales perdidos en el intervalo T.
Para el cálculo de loss (T), el extremo local lleva un contador que se consulta cada
vez que se requiere el envío de un informe RTCP SR/RR. Este contador se incrementa cada
vez que llega un paquete RTP con un número de secuencia distinto al que se esperaba. El
incremento del contador de pérdidas se define como
𝑑𝑖𝑓𝑓 = 𝑛𝑒𝑤𝑠𝑒𝑞 − 𝑙𝑎𝑠𝑡𝑠𝑒𝑞 − 1
donde newseq es el número se secuencia del nuevo paquete recibido, lastseq es el
número de secuencia del último paquete recibido y diff es el incremento que se le suma al
contador de perdidas.
Para llevar una cuenta del número total de paquetes recibidos y perdidos totales
hasta el anterior intervalo, rxpkt (T-1) y loss (T-1), se utiliza un fichero auxiliar llamado
Página 35
“lRXTXPKT.txt” donde se guardan los valores actuales rxpkt (T) y loss (T) para
posteriormente en la construcción del siguiente informe RTCP XR del intervalo T+1
compararlos con los valores actualizados de rxpkt (T+1) y loss (T+1).
Conocidos ya todos los datos necesarios, podemos calcular las pérdidas de paquetes
en un intervalo cualquiera, de la siguiente forma
𝑅𝑎𝑡𝑖𝑜𝐿𝑜𝑠𝑠 (𝑇) =𝑙𝑜𝑠𝑠𝑖𝑛𝑡 (𝑇)
𝑟𝑥𝑝𝑘𝑡𝑖𝑛𝑡 𝑇 + 𝑙𝑜𝑠𝑠𝑖𝑛𝑡 (𝑇)
donde RatioLoss(T) es la probabilidad de pérdida de paquetes en un intervalo T
entre informes RTCP XR.
Como en la métrica de pérdidas anterior, cada vez que se produce un re-Invite, los
estadísticos de paquetes perdidos y recibidos totales, rxpkt (T) y loss (T) se inicializan a
cero. El problema que surge es que cuando queramos hallar por ejemplo los paquetes
recibidos en un intervalo, rxpktint (T), el resultado será negativo.
𝑠𝑖 𝑟𝑥𝑝𝑘𝑡 𝑇 < 𝑟𝑥𝑝𝑘𝑡 𝑇 − 1 𝑒𝑛𝑡𝑜𝑛𝑐𝑒𝑠 𝑟𝑥𝑝𝑘𝑡𝑖𝑛𝑡 𝑇 < 0
Esto ocurre de forma análoga para lossint (T).
El problema es solucionado introduciendo la siguiente condición antes de evaluar
rxpktint (T) y lossint (T).
FIGURA 14: CONDICION PARA RE-INVITE
Con esta simple condición, siempre tomaremos un valor positivo y fiable de estos
parámetros en cada intervalo.
La métrica RatioLoss no presenta el inconveniente de la anterior métrica respecto al
problema de la pérdida de paquetes debido a los re-Invite, ya que cuando se produce un
Página 36
mensaje de re-Invite seguidamente se envía un informe extraordinario RTCP XR para
finalizar el cómputo de paquetes en el intervalo anterior y comenzar otro nuevo cómputo
en el actual. Tampoco le afecta el problema de la fiabilidad de que el primer informe RTCP
SR/RR realice un computo sobre un número de paquetes escaso, porque el intervalo de
envío del primer informe RTCP XR es mayor que el del informe RTCP SR/RR, y por tanto
contiene muchas más muestras. Esto es así para cualquier informe RTCP XR, ya que
siempre abarcan un intervalo más amplio. Del mismo modo que se envía un informe RTCP
XR después de un re-Invite, se envía también un informe después del mensaje de SIP BYE
con que se cierra la llamada. De este modo, se computan todos los paquetes RTP hasta el
final de la sesión.
Existen unas pérdidas adicionales que no estaban contempladas en ninguna de las
dos métricas que acabamos de estudiar. Estas pérdidas se producen debido a las tramas de
voz que se pierden en el buffer de jitter cuando esperan para ser reproducidas. Aunque
una trama llegue correctamente al receptor, el efecto de la variación del retado de red
(jitter) puede ocasionar que no llegue a tiempo al buffer de jitter para ser reproducida en
el altavoz. De esta forma, la trama necesaria ha sido recibida correctamente, pero el buffer
la ha desechado. La máxima desviación del retardo de red que puede ser compensada por
el buffer de jitter es igual al retraso que introduce el buffer antes de empezar a reproducir
el flujo de voz, es decir, el buffer espera un tiempo determinado antes de reproducir la
primera trama del flujo de voz para así tener siempre tramas que reproducir en el buffer.
Entonces, si el jitter es excesivo, la tasa de llegada de paquetes al buffer decrecerá o
aumentará significativamente. Si la tasa de llegada decrece provocará que el buffer se
vacíe paulatinamente. En cambio, si la tasa aumenta provocará que el buffer se llene de
tramas. Esto último puede introducir un retardo tal que algunas tramas se pierdan. En la
figura 15 podemos observar como varia el número de tramas totales perdidas durante una
llamada de 60 segundos sobre la que se aplican diferentes valores de jitter.
FIGURA 15: TRAMAS TOTALES PERDIDAS
Página 37
Se observa cómo mientras más elevado es el jitter, mayores son las pérdidas totales
producidas en el buffer a lo largo de una llamada, ya que hace que cambie la tasa de
llegada de paquetes repentinamente y se llene el buffer, con el consiguiente efecto de
retardo introducido.
El estadístico, que proporciona el número de tramas totales perdidas en el buffer de
jitter se modifica dentro del archivo que implementa el citado buffer, “jbuf.c”, en la función
“pjmedia_jbuf_get_frame()”, que se llama cada vez que se manda una trama al altavoz.
El número de tramas perdidas se almacena en un fichero auxiliar llamado
“jb_loss.txt” cuando se actualizan en la anterior función. Este fichero es leído cada vez que
se manda un informe RTCP para hallar el número de paquetes perdidos en el buffer,
obtenido de la siguiente manera
𝑗𝑏𝑙𝑜𝑠𝑠 (𝑇) =𝑓𝑟𝑎𝑚𝑒𝑙𝑜𝑠𝑠(𝑇)
𝑟𝑒𝑚𝑜𝑡𝑒𝑁𝑓𝑝𝑝
donde frameloss(T) es el número de tramas pérdidas en el buffer de jitter durante un
intervalo T leído del fichero “jb_loss.txt”, remoteNfpp es el número de tramas por paquete
con el que el extremo remoto transmite y jbloss(T) es el número de paquetes perdidos en
el buffer durante un intervalo T.
Para conseguir que frameloss(T) compute solo las tramas perdidas en un intervalo,
reiniciamos su valor cada vez que se envía un informe RTCP.
3.2.5. Evaluación de la duración de las ráfagas de pérdidas
Las pérdidas totales de tramas del extremo remoto no resultan fáciles, pues no
sabemos con certeza el número de tramas que contenían los paquetes perdidos. Este
aspecto afecta a la evaluación de las pérdidas por ráfagas.
El valor de la duración media de las ráfagas de pérdidas se evalúa cada vez que
vamos a enviar un informe RTCP XR al extremo remoto. PJSUA considera que los paquetes
recibidos en un intervalo RTCP (es lo único que se puede medir desde el extremo local)
contienen el mismo número de tramas que se aplica de forma local por lo que el valor de la
duración de las ráfagas debe ser corregido aplicando el número de tramas de voz que
contienen los paquetes del extremo remoto. El cálculo del número de tramas por paquete
con el que transmite el extremo remoto durante un intervalo, remoteNfpp(T) se estima
mediante la siguiente fórmula.
𝑟𝑒𝑚𝑜𝑡𝑒𝑁𝑓𝑝𝑝 𝑇 =𝑡𝑥𝑝𝑘𝑡𝑖𝑛𝑡 (𝑇)
𝑟𝑥𝑝𝑘𝑡𝑖𝑛𝑡 (𝑇) + 𝑙𝑜𝑠𝑠𝑖𝑛𝑡 (𝑇)· 𝑁𝑓𝑝𝑝(𝑇)
Donde txpktint(T) es el número de paquetes transmitidos por el extremo local en un
intervalo T , mientras que Nfpp(T) es el número de tramas por paquete con el que
transmite el extremo local durante un intervalo T.
Página 38
El número de paquetes transmitidos en un intervalo, txpktint(T), se calcula de la
siguiente forma.
𝑡𝑥𝑝𝑘𝑡𝑖𝑛𝑡 (𝑇) = 𝑡𝑥𝑝𝑘𝑡 𝑇 − 𝑡𝑥𝑝𝑘𝑡 (𝑇 − 1)
Donde txpkt (T) es el número de paquetes transmitidos totales hasta el actual
intervalo T, mientras que txpkt (T-1) es el número de paquetes transmitidos totales hasta
el anterior intervalo.
Para llevar la cuenta del número total de paquetes transmitidos totales hasta el
anterior intervalo, txpkt (T-1), se utiliza un fichero auxiliar llamado “lRXTXPKT.txt” donde
se guarda el valor actual de txpkt (T) para posteriormente en la construcción del siguiente
informe RTCP XR del intervalo T+1 compararlo con el valor actualizado de txpkt (T+1). Si
se produjera un re-Invite el estadístico txpkt(T) se resetearía y txpktint(T) anterior sería
negativo. Este problema se soluciona igualando a cero txpkt (T-1) cuando se detecta un re-
Invite, como se hace también para rxpkt (T-1) y loss (T-1) en apartados anteriores.
De esta forma, si durante un intervalo entre paquetes RTCP XR sabemos que hemos
transmitido 300 paquetes cada uno con 6 de tramas por paquete y que esperábamos
recibir 150 paquetes del extremo remoto, entonces sabemos que el extremo remoto está
emitiendo la mitad de paquetes que el extremo local y que por lo tanto tiene que estar
transmitiendo paquetes con el doble de tramas, en este caso 12.
Una vez calculado remoteNfpp(T), solo necesitamos conocer la duración de las
ráfagas de pérdidas cada vez que se produzcan. Este parámetro lo calcula internamente
PJSUA de la siguiente forma
𝑝𝑒𝑟𝑖𝑜𝑑 =𝑑𝑖𝑓𝑓 · 𝑝𝑘𝑡_𝑠𝑖𝑧𝑒
𝑐𝑙𝑜𝑐𝑘_𝑟𝑎𝑡𝑒
Donde diff es el número de paquetes perdidos que se computan en cada recepción
de un nuevo paquete RTP, pkt_size es el tamaño de los paquetes, dado en número de
muestras, con el que transmite el extremo local, clock_rate es la frecuencia de reloj del
sistema, dado en muestras por segundo y period es la duración de las pérdidas producidas.
La duración de las pérdidas se evalúa en el archivo fuente “rtcp.c” en la función
“pjmedia_rtcp_rx_rtp()”, que se llama cuando llega un paquete RTP de forma correcta. Cada
vez que se evalúa el estadístico period, se pasa a la función “pj_math_stat_update()” que va
calculando la media acumulativa de los datos recibidos. Para computar las pérdidas
medias durante un intervalo se resetean las estadísticas cada vez que se envía un informe
RTCP. De este modo, obtenemos la duración media de las pérdidas a ráfagas en un
intervalo de medida T, que llamaremos loss_period(T).
Una vez hallada la duración media de las pérdidas, nos proponemos traducir este
valor a términos de tramas pérdidas. Este paso se realiza de la siguiente manera
𝑏𝑢𝑟𝑠𝑡 (𝑇) =𝑙𝑜𝑠𝑠_𝑝𝑒𝑟𝑖𝑜𝑑 (𝑇)
𝑇𝑡𝑟𝑎𝑚𝑎
Página 39
Donde Ttrama es la duración de las tramas proporcionadas por el códec y burst (T) es
el número medio de tramas pérdidas a ráfagas, para cada intervalo, que queríamos
obtener.
Como se ha comentado anteriormente, la duración de las ráfagas de pérdidas se
computa respecto al tamaño de los paquetes con que transmite el equipo local, es decir,
respecto al número de tramas por paquete local Nfpp. Por ejemplo, operamos con 6 y 12
tramas por paquete en el extremo local y remoto respectivamente y utilizamos el códec
G.711, cuya duración de trama es de 10 milisegundos. Si el extremo remoto envía 1
paquete y este se pierde, el extremo local va a estimar que la duración de las ráfagas es de
un paquete, que son 6 tramas, cuando en realidad se han perdido 12 tramas. Para
solucionar la adulteración de este valor necesitamos introducir un factor de corrección
que tenga en cuenta la diferencia entre Nfpp y remoteNfpp. Este factor vendrá dado por el
cociente de ambos. Así, corregimos el valor de burst (T) de la siguiente forma
𝑏𝑢𝑟𝑠𝑡 𝑇 =𝑙𝑜𝑠𝑠_𝑝𝑒𝑟𝑖𝑜𝑑 𝑇
𝑇𝑡𝑟𝑎𝑚𝑎·𝑟𝑒𝑚𝑜𝑡𝑒𝑁𝑓𝑝𝑝 (𝑇)
𝑁𝑓𝑝𝑝 (𝑇)
Siguiendo con el ejemplo anterior, aplicaríamos un factor de corrección de 12/6 al
valor calculado anterior, que nos daría como resultado que se han perdido 12 tramas.
De este modo, hemos obtenido la duración media para cada intervalo de las pérdidas
producidas a ráfagas en términos de tramas, burst (T), para posteriormente utilizarla en la
estimación de la calidad de la conversación.
3.3. Validación de los parámetros de QoS
En este apartado realizaremos una serie de medidas sobre los estadísticos
estudiados anteriormente y comprobaremos la fiabilidad que nos ofrecen dichas medidas.
Se realizaran una serie de llamadas entre dos equipos y se recopilarán los estadísticos
proporcionados por PJSUA.
Para analizar la fiabilidad de las medidas de retardos, pérdida de paquetes y ráfaga
de pérdidas se utilizará el escenario que se muestra en la figura 16. Los host clientes se
conectarán mediante un cable cruzado a otro host donde se ejecutará el software Network
Emulator for Windows Toolkit (NEWT). Este software será el encargado de introducir los
efectos de pérdidas y retraso deseados en el canal, de forma que al medir en uno de los
host clientes esas pérdidas se puedan correlar con los parámetros introducidos al
emulador NEWT. El escenario definido es, por tanto, un entorno controlado en el que no
habrá factores externos que puedan alterar significativamente el resultado de las medidas
realizadas.
Página 40
FIGURA 16: ESCENARIO CONTROLADO DE MEDIDA
3.3.1. Medidas de retardo de red
Para comparar la fiabilidad de los estadísticos de retardo recopilados mediante el
protocolo NTP (en los informes RTCP) y un ping independiente de PJSUA, se utiliza el
escenario típico anteriormente definido sin pérdidas y mediante el software NEWT se
introduce un RTT de 3 milisegundos entre ambos equipos. En la figura 17 podemos
observa cómo evoluciona el retardo de red para cada uno de los dos métodos a lo largo de
una llamada de 160 segundos de duración.
FIGURA 17: RETARDO DE RED MEDIDO
Se observa como la comparativa entre los resultados de la medida del RTT mediante
el protocolo NTP en los informes RTCP y del RTT por parte de ping ofrece resultados muy
similares para entornos no saturados. Se han realizado también pruebas para un retraso
de 100 ms y la diferencia entre ambos métodos permanece invariante.
Página 41
3.3.2. Medidas de pérdidas de paquetes
Una vez definidas las métricas de cálculo de la pérdida de paquetes, FractionLoss y
RatioLoss, se plantea realizar un análisis para comparar la fiabilidad de ambas mediante la
emulación de diversas características de pérdidas en la red en el escenario definido en
anteriores apartados mediante el software NEWT. Para ello se realizarán 20 llamadas
distintas de 60 segundos de duración. El códec utilizado es el G.711 y no se utiliza VAD.
Para el total de llamadas obtendremos la probabilidad media de pérdida de paquetes
estimada por cada método mediante sus respectivos informes RTCP (SR/RR para
FractionLoss y XR para RatioLoss). Además calcularemos la varianza de esta medida, que
nos dará una estimación de la dispersión de las muestras tomadas; y el número de
informes RTCP mediante los cuales se han obtenido estos resultados.
Prueba nº 1: Probabilidad de pérdida igual al 1% y 10%
El objetivo de esta primera prueba es comprobar la fiabilidad de ambos métodos de
medida de pérdidas, FractionLoss y RatioLoss, para una probabilidad aleatoria de pérdida
baja y alta.
Con tal fin, emularemos sobre el escenario típico definido en anteriores apartados
una probabilidad de pérdida de paquetes RTP, Ppl, del 1 y del 10 por ciento, mediante el
software NEWT. El extremo local recopilará estadísticas de los paquetes que recibe del
extremo remoto con remoteNfpp igual a 6 tramas por paquete. En la siguiente tabla se
encuentra calculada la media, para cada métrica, de cada uno de los estadísticos
mencionados.
Prueba nº 2: Probabilidad de pérdida igual al 1% y 10% con re-Invite cada 6
segundos
El objetivo de esta segunda prueba es comprobar la fiabilidad de ambos métodos de
medida de pérdidas, FractionLoss y RatioLoss, para una probabilidad aleatoria de pérdida
de paquetes baja y alta en un entorno en el que el extremo remoto envía un re-Invite cada
6 segundos. Este valor de 6 segundos se ha escogido teniendo en cuenta la duración media
de los intervalos entre informes RTCP SR/RR y el tiempo de actualización del algoritmo
del número de tramas por paquete local y remoto.
Ppl (%) Ppl medida (%) Varianza Nº informes
FractionLoss RatioLoss FractionLoss RatioLoss FractionLoss RatioLoss
1 0,997 1,028 1,509 0,824 12,35 7,50
10 9,660 10,312 18,283 12,596 12,60 8,20
TABLA 3: RESULTADOS DE PÉRDIDAS PRUEBA 1
Página 42
Para ello, emularemos sobre el escenario típico definido en anteriores apartados
una probabilidad de pérdida de paquetes RTP, Ppl, del 1% y 10% mediante el software
NEWT. El extremo local recopilará estadísticas de los paquetes que recibe del extremo
remoto, el cual cada 6 segundos cambiará el valor de remoteNfpp y enviará el
correspondiente re-Invite. El valor de remoteNfpp variará de forma unitaria entre un valor
mínimo de 2 y un máximo de 16 tramas por paquete. En la siguiente tabla se encuentra
calculada la media, para cada métrica, de cada uno de los estadísticos mencionados.
Prueba nº 3: Probabilidad de pérdida igual al 1% y 10% con re-Invite cada 10
segundos
El objetivo de esta tercera prueba es comprobar la fiabilidad de ambos métodos de
medida de pérdidas, FractionLoss y RatioLoss, para una probabilidad aleatoria de pérdida
de paquetes baja y alta en un entorno en el que el extremo remoto envía un re-Invite cada
10 segundos. Este valor de 10 segundos se ha escogido teniendo en cuenta la duración
media de los intervalos entre informes RTCP XR y el tiempo de actualización del algoritmo
del número de tramas por paquete local y remoto.
Para ello, emularemos sobre el escenario típico definido en anteriores apartados
una probabilidad de pérdida de paquetes RTP, Ppl, del 1% y 10% mediante el software
NEWT. El extremo local recopilará estadísticas de los paquetes que recibe del extremo
remoto, el cual cada 6 segundos cambiará el valor de remoteNfpp y enviará el
correspondiente re-Invite. El valor de remoteNfpp variará de forma unitaria entre un valor
mínimo de 2 y un máximo de 16 tramas por paquete. En la siguiente tabla se encuentra
calculada la media, para cada métrica, de cada uno de los estadísticos mencionados.
TABLA 4: RESULTADOS DE PÉRDIDAS PRUEBA 2
Ppl (%) Ppl medida (%) Varianza Nº informes
FractionLoss RatioLoss FractionLoss RatioLoss FractionLoss RatioLoss
1 0,608 1,103 2,270 2,395 19,90 11,95
10 7,123 9,733 47,859 53,227 19,85 11,55
Ppl (%) Ppl medida (%) Varianza Nº informes
FractionLoss RatioLoss FractionLoss RatioLoss FractionLoss RatioLoss
1 0,468 0,991 1,570 2,738 14,95 9,85
10 7,772 9,753 52,386 36,233 15,10 9,90
TABLA 5: RESULTADOS DE PÉRDIDAS PRUEBA 3
Página 43
3.3.3. Medidas de duración de las ráfagas de pérdidas
Para comprobar la fiabilidad de la medida de pérdidas a ráfagas, se cotejaran los
resultados medidos por PJSUA y los emulados por el software NEWT en el entorno
controlado definido anteriormente. Con tal fin, emularemos sobre el escenario típico
definido en anteriores apartados una determinada probabilidad aleatoria de que se
produzca una ráfaga de pérdidas, Pburst, mediante el software NEWT. Además, también
definiremos en el software NEWT que el tamaño mínimo y máximo de estas ráfagas sea de
3 y 4 paquetes respectivamente. El número de paquetes perdidos anterior tendrá una
distribución aleatoria entre dichos valores mínimo y máximo. De esta forma, el software
NEWT producirá ráfagas aleatorias de pérdidas con una determinada probabilidad, Pburst,
sobre las que se perderán también de forma aleatoria un determinado número de
paquetes RTP comprendido entre el mínimo y el máximo establecidos, en este caso 3 y 4
paquetes.
Para ello se realizarán 20 llamadas distintas de 60 segundos. El códec utilizado es el
G.711 y no se utiliza VAD. Para el total de esas llamadas obtendremos la duración media de
las ráfagas de paquetes estimada mediante los informes RTCP XR. Además calcularemos la
varianza de esta medida, que nos dará una estimación de la dispersión de las muestras
tomadas.
Prueba nº 1: Probabilidad de burst igual al 1% y 10%
El objetivo de esta primera prueba es comprobar la fiabilidad de la medida de la
duración media de las ráfagas de pérdidas, burst (T), para una probabilidad de pérdida a
ráfagas baja y otra alta en un entorno controlado. Este estadístico se mide en términos de
tramas.
Emularemos sobre el escenario típico definido en anteriores apartados una
probabilidad de burst, Pburst, del 1% y 10%. El extremo local recopilará estadísticas de los
paquetes que recibe del extremo remoto con un valor de remoteNfpp igual a 6 tramas por
paquete. El valor del número de tramas por paquete local, Nfpp, es siempre fijado a un
valor 6. En la siguiente tabla se encuentra calculada la media de cada uno de los
estadísticos medidos.
Pburst(%) Duración burst
(tramas) Varianza
1 21,20 6,80
10 23,55 5,94
TABLA 6: RESULTADOS DE BURST PRUEBA 1
Página 44
Prueba nº 2: Probabilidad de burst igual al 1% y 10% con re-Invite cada 6 segundos
El objetivo de esta segunda prueba es comprobar la fiabilidad de la medida de la
duración media de las ráfagas de pérdidas, burst (T), para una probabilidad de pérdida a
ráfagas baja y alta en un entorno controlado en el que el extremo remoto envía un re-
Invite cada 6 segundos. Este valor de 6 segundos se ha escogido teniendo en cuenta la
duración media de los intervalos entre informes RTCP SR/RR y el tiempo de actualización
del algoritmo del número de tramas por paquete local y remoto. El estadístico burst (T) se
mide en términos de tramas.
Con tal fin, emularemos sobre el escenario típico definido en anteriores apartados
una probabilidad aleatoria de que se produzca una ráfaga de pérdidas, Pburst, del 1% y 10
%. El extremo local recopilará estadísticas de los paquetes que recibe del extremo remoto,
el cual cada 6 segundos cambiará el valor de remoteNfpp y enviará el correspondiente re-
Invite. El valor de remoteNfpp oscilará siempre entre 5 y 6 tramas por paquete. El valor del
número de tramas por paquete local, Nfpp, es siempre fijado a un valor 6. En la siguiente
tabla se encuentra calculada la media de cada uno de los estadísticos medidos.
Pburst(%) Duración burst
(tramas) Varianza
1 21,61 10,89
10 23,05 11,97
TABLA 7: RESULTADOS DE BURST PRUEBA 2
Prueba nº 3: Probabilidad de burst igual al 1% y 10 con re-Invite cada 10 segundos
El objetivo de esta tercera prueba es comprobar la fiabilidad de la medida de la
duración media de las ráfagas de pérdidas, burst (T), para una probabilidad de pérdida a
ráfagas baja y alta en un entorno controlado en el que el extremo remoto envía un re-
Invite cada 6 segundos. Este valor de 10 segundos se ha escogido teniendo en cuenta la
duración media de los intervalos entre informes RTCP SR/RR y el tiempo de actualización
del algoritmo del número de tramas por paquete local y remoto. El estadístico burst (T) se
mide en términos de tramas.
Con tal fin, emularemos sobre el escenario típico definido en anteriores apartados
una probabilidad aleatoria de que se produzca una ráfaga de pérdidas, Pburst, del 1% y 10
%. El extremo local recopilará estadísticas de los paquetes que recibe del extremo remoto,
el cual cada 6 segundos cambiará el valor de remoteNfpp y enviará el correspondiente re-
Invite. El valor de remoteNfpp oscilará siempre entre 5 y 6 tramas por paquete. El valor del
número de tramas por paquete local, Nfpp, es siempre fijado a un valor 6. En la siguiente
tabla se encuentra calculada la media de cada uno de los estadísticos medidos.
Página 45
Pburst(%) Duración burst
(tramas) Varianza
1 19,46 14,29
10 24,70 53,49
TABLA 8: RESULTADOS DE BURST PRUEBA 3
3.3.4. Medidas de retardo en el buffer de jitter
Para comprobar el funcionamiento del buffer de jitter estableceremos una serie de
pruebas tanto con un buffer fijo como adaptativo y con diferentes valores de remoteNfpp
en el escenario definido en anteriores apartados.
Prueba nº 1: Buffer fijo
El objetivo de esta primera prueba consiste en comprobar el retardo inicial que se
introduce en el buffer de jitter al comienzo de una conversación o después de largos
periodos de silencio que vacíen el buffer. Además, comprobaremos como afecta el retardo
en el buffer a las tramas perdidas en este.
Con tal fin, realizaremos tres pruebas con una llamada de 60 segundos de duración
para diferentes valores de remoteNfpp. El códec utilizado será el G.711, cuya duración de
trama es de 10 milisegundos. El extremo remoto no tendrá activado el detector de
actividad vocal (VAD). De esta manera, el extremo remoto estará continuamente
mandando tramas de voz, concretamente cada 10 milisegundos. El retardo de red
existente en el escenario de las pruebas se puede considerar prácticamente cero, por lo
tanto, el extremo receptor estará recibiendo un flujo de paquetes constante desde el
extremo remoto. Implementaremos un buffer fijo de 10 tramas y veremos cómo
evoluciona la variable curr_delay, que mide el retardo en el buffer de forma instantánea
cada vez que llega un paquete al buffer. Además, computaremos el número total de tramas
que se van perdiendo en el buffer a lo largo de la llamada. En este estudio no existen
ningún tipo de pérdidas o retrasos impuestos.
En la figura 18 se puede observar el retardo medido por la variable curr_delay,
medido en milisegundos, durante la llamada para valores de remoteNfpp de 2, 4 y 8 tramas
por paquete. En la figura 19 se observan las pérdidas totales registradas en el buffer
durante la llamada para los mismos valores de remoteNfpp estudiados en la primera
gráfica.
Página 46
FIGURA 18: RETARDO BUFFER DE JITTER
FIGURA 19: TRAMAS PERDIDAS TOTALES
Se observa de la figura 18 como el primer valor de curr_delay tomado equivale al
retardo inicial indicado en la implementación del buffer fijo, que se corresponde con 10
tramas. Para remoteNfpp igual a 2 tramas por paquete, hasta que no llegan 5 paquetes, no
se empieza a reproducir ninguna trama. Por tanto, su retraso es de 100 milisegundos. Para
el caso en el que remoteNfpp vale 4, cuando llega el tercer paquete se pasa de tener 8
Página 47
tramas almacenadas a tener 12, y entonces comienzan a reproducirse las tramas. De forma
análoga, cuando remoteNfpp es 8, no empiezan a reproducirse las tramas hasta que llega el
2 paquete y se pasa de tener 8 tramas almacenadas a tener 16, lo que da lugar a su
correspondiente retraso.
La figura 19 nos muestra el acumulativo de pérdidas producidas a lo largo de la
llamada. Se observa como las pérdidas crecen después de que el retardo en el buffer
aumente. Estas tramas perdidas son las tramas que han sufrido un retardo tal que no ha
llegado a tiempo para reproducirse. En cambio, cuando el retardo en el buffer se mantiene
constante, el valor de tramas perdidas no crece, manteniéndose constante también.
Prueba nº 2: Retardo medio e instantáneo medido y buffer fijo
El objetivo de esta segunda prueba consiste en comprobar que el retardo medio
medido en cada intervalo entre informes RTCP XR concuerda con el retardo instantáneo
medido por la variable curr_delay cada vez que llega un paquete RTP.
Con tal fin, realizaremos una llamada de 60 segundos de duración para un valor,
remoteNfpp, de 2 y 4 tramas por paquete. El códec utilizado será el G.711, cuya duración
de trama es de 10 milisegundos. El extremo remoto no tendrá activado el detector de
actividad vocal (VAD). De esta manera, el extremo remoto estará continuamente
mandando tramas de voz, concretamente cada 10 milisegundos. El retardo de red
existente en el escenario de las pruebas se puede considerar prácticamente cero, por lo
tanto, el extremo receptor estará recibiendo un flujo de paquetes constante desde el
extremo remoto. Implementaremos un buffer fijo de 10 tramas y veremos cómo
evoluciona la variable curr_delay, que mide el retardo en el buffer de forma instantánea
cada vez que llega un paquete al buffer. También analizaremos el retardo medio medido
por la variable, delaybuff (T), en cada intervalo T entre informes RTCP XR. En este estudio
no existen ningún tipo de pérdidas o retrasos impuestos.
En la figura 20 se puede observar el retardo instantáneo estimado por la variable
curr_delay, medido en milisegundos, durante la llamada para un valor de remoteNfpp de 2
tramas por paquete. Superpuesto a este retardo instantáneo se encuentra el retardo medio
medido por la variable delaybuff(T) durante cada intervalo. En la figura 21 se realiza un
análisis análogo para remoteNfpp igual a 4 tramas por paquete.
Página 48
FIGURA 20: RETARDO MEDIO BUFFER DE JITTER
FIGURA 21: RETARDO MEDIO BUFFER DE JITTER
Se observa de las anteriores gráficas como el retardo medio proporcionado por los
informes RTCP computa fielmente el retardo instantáneo producido. Retardo instantáneo
Página 49
y media coinciden cuando el primero es constante. Para la primera gráfica, el retardo
medio medido durante toda llamada mediante los informes RTCP es de 32,83
milisegundos, mientras que la media realizada al retardo instantáneo nos da un valor de
33,15 milisegundos. Para la segunda gráfica, el retardo medio medido durante toda
llamada mediante los informes RTCP es de 71,57 milisegundos, mientras que la media
realizada al retardo instantáneo nos da un valor de 71,59 milisegundos. Vemos la
independencia de las medidas de retardo respecto al número tramas por paquete.
Prueba nº 3: Retardo medio e instantáneo medio con buffer adaptativo
El objetivo de esta tercera prueba consiste en comprobar de nuevo que el retardo
medio medido en cada intervalo entre informes RTCP XR concuerda con el retardo
instantáneo medido por la variable curr_delay cada vez que llega un paquete RTP, pero en
este caso se observará a través de un buffer adaptativo y en unas condiciones en la que se
producirá un jitter de 300 milisegundos a través del software NEWT. Este jitter es
implementado variando el retardo de red de 0 a 300 milisegundos en periodos de 10
segundos.
Con tal fin, realizaremos una llamada de 60 segundos de duración para un valor,
remoteNfpp, de 2 tramas por paquete. El códec utilizado será el G.711, cuya duración de
trama es de 10 milisegundos. El extremo remoto no tendrá activado el detector de
actividad vocal (VAD). De esta manera, el extremo remoto estará continuamente
mandando tramas de voz, concretamente cada 10 milisegundos. El retardo de red
existente en el escenario de las pruebas se puede considerar prácticamente cero, por lo
tanto, el extremo receptor estará recibiendo un flujo de paquetes constante desde el
extremo remoto. Implementaremos un buffer adaptativo y veremos cómo evoluciona la
variable curr_delay, que mide el retardo en el buffer de forma instantánea cada vez que
llega un paquete al buffer. También analizaremos el retardo medio medido por la variable,
delaybuff (T), en cada intervalo T entre informes RTCP XR.
En la figura 22 se puede observar el retardo instantáneo estimado por la variable
curr_delay, medido en milisegundos, durante la llamada para un valor de remoteNfpp de 2
tramas por paquete. Superpuesto a este retardo instantáneo se encuentra el retardo medio
medido por la variable delaybuff(T) durante cada intervalo.
Página 50
FIGURA 22: RETARDO BUFFER ADAPTATIVO
Se observa de la anterior gráfica como el retardo medio proporcionado por los
informes RTCP sigue fielmente el retardo instantáneo producido. Retardo instantáneo y
media coinciden cuando el primero es constante. El retardo medio medido durante toda la
llamada mediante los informes RTCP es de 64 milisegundos, mientras que la media
realizada al retardo instantáneo nos da un valor de 65,96 milisegundos. En este caso al
producirse efectos de jitter, el retardo medio medido es prácticamente igual de exacto que
en otras pruebas.
Prueba nº 4: Retardo medio e instantáneo medio con buffer adaptativo
El objetivo de esta cuarta y última prueba consiste en comprobar cómo evoluciona el
retardo instantáneo medido por la variable curr_delay cada vez que llega un paquete RTP
cuando se da el efecto del jitter en la red. En estas condiciones, se producirá un jitter de
300 milisegundos a través del software NEWT. Este jitter es implementado variando el
retardo de red de 0 a 300 milisegundos en periodos de 10 segundos.
Con tal fin, realizaremos una llamada de 60 segundos de duración para un valor,
remoteNfpp, de 2 y 8 tramas por paquete. El códec utilizado será el G.711, cuya duración
de trama es de 10 milisegundos. El extremo remoto no tendrá activado el detector de
actividad vocal (VAD). De esta manera, el extremo remoto estará continuamente
mandando tramas de voz, concretamente cada 10 milisegundos. El retardo de red
existente en el escenario de las pruebas se puede considerar prácticamente cero, por lo
tanto, el extremo receptor estará recibiendo un flujo de paquetes constante desde el
extremo remoto. Implementaremos un buffer fijo de 10 tramas y veremos cómo
evoluciona la variable curr_delay, que mide el retardo en el buffer de forma instantánea
cada vez que llega un paquete. Además, computaremos el número total de tramas que se
van perdiendo en el buffer a lo largo de la llamada
Página 51
En la figura 23 se puede observar el retardo instantáneo estimado por la variable
curr_delay, medido en milisegundos, durante la llamada para un valor de remoteNfpp de 2
y 8 tramas por paquete. En la figura 24 se observan las pérdidas totales registradas en el
buffer durante la llamada para los mismos valores de remoteNfpp estudiados en la primera
gráfica.
FIGURA 23: RETARDO BUFFER ADAPTATIVO
FIGURA 24: TRAMAS PERDIDAS TOTALES
Se observa de la figura 23 como cada 10 segundos el retardo en el buffer oscila de
manera más o menos abrupta dependiendo de cómo se encuentre el buffer en ese instante.
Concretamente, a partir de segundo 20 el retardo aumenta hasta magnitudes excesivas
Página 52
debido a que empiezan a llegar paquetes con mayor frecuencia. Después de esto, el buffer
comienza a perder tramas de forma consecutiva, como puede observarse en la segunda
gráfica, hasta que vuelve a coger una trama en tiempo y se estabiliza. Normalmente,
cuando se pierde una trama de un paquete porque no llega a tiempo debido al retraso, el
resto de tramas del paquete que la siguen también se perderá. Estas pérdidas se
propagarán hasta que se encuentre una trama que sea válida para reproducirla. Se puede
comprobar en la figura 23 que este efecto es más acusado cuanto mayor es el número de
tramas por paquete, ya que son más los paquetes que viajan juntos y por tanto se
producen paquetes con menor frecuencia en el extremo remoto.
Una vez comprobado el funcionamiento del buffer de jitter y los efectos adversos
que pueden afectarle, podemos asegurar la fiabilidad de la variable curr_delay.
3.4. Discusión de resultados
Con el fin de evaluar la calidad de una conversación se han descrito en apartados
anteriores una serie de métodos para evaluar tres parámetros que nos afectan en el
cómputo de la calidad de una llamada. Estos tres parámetros son el retardo total que
sufren los paquetes, la probabilidad de pérdida de paquetes y la duración media de las
ráfagas de pérdidas. Para cada uno de ellos, se ha definido el proceso de obtención de tal
estadístico y se han realizado una serie de pruebas para comprobar como de fiables son
los resultados obtenidos.
Para la evaluación del retardo total que sufren los paquetes, primero comenzamos
con la evaluación del retardo de red proporcionado por dos métodos diferentes. Uno de
ellos se basa en calcular el RTT (Round Trip Time) mediante una marca de tiempo enviada
en los informes RTCP que es generada mediante el protocolo NTP. La otra variante era
medir RTT directamente a través de un ping independiente del código y evaluar las
estadísticas devueltas por este. Como se vio en su correspondiente apartado ambos
métodos presentan una diferencia entre ellos de 1 a 2 milisegundos. En el retardo global,
el RTT suele ser una parte muy pequeña para redes no saturadas, que es lo habitual si
estamos utilizando aplicaciones de VoIP, comparado con otros retardos como el de
empaquetado o el del buffer de jitter. Por ejemplo, para 6 tramas por paquete, el retardo
medio oscilará entre 70 ms – 120 ms (dependiendo del buffer de jitter), por lo que 1 o 2
milisegundos de diferencia entre ambos métodos no tendrán un impacto significativo en la
medida de la calidad. Es por ello por lo que se decide continuar con la medida
proporcionada por PJSUA mediante el protocolo NTP, que
El otro factor que influye en la evaluación del retardo total es el retardo de
empaquetado y el retardo en el buffer de jitter. Como se vio en su momento, el estadístico
que mide el retardo medio en el buffer también contemplaba en dicha medida el retardo
de empaquetado que sufren los paquetes, ya que añadía la propia duración del paquete a
retardo medido en el buffer. Esta medida se muestra totalmente fiable como se puede
comprobar de los resultados obtenidos para cada una de las pruebas realizadas. Tanto
para un buffer adaptativo como fijo el estadístico requerido mide las variaciones de
Página 53
retardo en cada intervalo de forma natural y obtiene un valor de retardo medio en el
buffer acorde con lo esperado al realizar las pruebas.
El segundo parámetro necesario para evaluar la calidad de una llamada es la
probabilidad de pérdida de paquetes RTP en una conversación. Este estadístico se ha
obtenido a través de dos métodos diferentes. La probabilidad de pérdida calculada
mediante el método FractionLoss se vale de los informes RTCP SR/RR, mientras que el
método RatioLoss se vale de los informes RTCP XR.
Se han realizado pruebas emulando diferentes probabilidades de pérdidas, una alta
y otra baja, y continuos mensajes de re-Invite con un cierto periodo que actualizan el
número de tramas por paquete. De estas pruebas se desprenden resultados que indican
que cuando no existen re-Invites durante una llamada, ambas métricas miden de forma
fiable la probabilidad de pérdida de paquetes emulada, tanto para una probabilidad alta
como para una baja. Aunque la medida proporcionada por la métrica RatioLoss en ambos
casos se encuentra siempre por encima de la medida obtenida mediante FractionLoss.
Además de que las medidas de RatioLoss presentan una menor dispersión. Para las
pruebas realizadas en las que se producen re-Invites cada cierto tiempo durante la
conversación, la métrica RatioLoss siempre mide una probabilidad de pérdida cercana a la
probabilidad emulada y que es muy superior (cuando hay pocas pérdidas llega a ser el
doble) a la probabilidad hallada por la métrica FractionLoss. La dispersión de las medidas
en este caso se mantiene en el mismo orden para ambas métricas. En este caso se
demuestra que la métrica FractionLoss ya no es fiable, pues como se ha dicho, estima
probabilidades siempre lejanas e inferiores a la probabilidad emulada. La métrica
RatioLoss da buenos resultados en el caso de re-Invite, ya que los resultados obtenidos
están siempre en torno a los valores de pérdidas emulados.
Analizados los resultados ofrecidos por ambas métricas y teniendo en cuenta que se
producirán re-Invites durante una conversación cada vez que se cambie el número de
tramas por paquete con que se transmite, el método elegido para estimar la probabilidad
de pérdida ocurrida durante una llamada será la métrica RatioLoss, ya que presenta un
mejor comportamiento sobre todo cuando se producen re-Invites. Por tanto, la medida de
la calidad se realizará en base a las pérdidas estimadas por este método.
Para finalizar, analizaremos la fiabilidad de las medidas obtenidas sobre la duración
de las ráfagas de pérdidas. Este estadístico se computa en términos de tramas pérdidas.
De esta forma mide en media, el número tramas pérdidas cada vez que se produce una
ráfaga de pérdida de paquetes. Se han realizado comprobaciones para diferentes
probabilidades de suceso de una ráfaga de pérdidas y para el envío de mensajes de re-
Invite al cambiar el número de tramas por paquete con el que transmite el extremo
remoto. Los resultados obtenidos para cada una de estas pruebas descritas anteriormente
reflejan en mayor o menor medida que el estadístico de pérdidas estimado se adecua al
valor emulado al realizar cada una de las diferentes pruebas.
De esta forma podemos concluir este apartado diciendo que los estadísticos
obtenidos necesarios para estimar la calidad de una llamada, presentan un alto índice de
fiabilidad, a razón de los resultados obtenidos al realizar pruebas con diferentes
casuísticas.
