ANLISIS DE CALIDAD DE SERVICIO SKYPE

Introduccin

Es bien sabido que las redes basadas en el protocolo IP ofrecen un nico nivel de servicio:
Best Effort. Es decir, no se lleva a cabo ningn tipo de reserva de recursos, no se conoce el
retraso mximo sufrido por los paquetes, ni garantiza que los paquetes lleguen correctamente a
su destino. De tal forma que se ofrece el mejor servicio posible para un instante determinado.

As, se hace imperativo definir y establecer la calidad de servicio (QoS) en las redes de este tipo
para el funcionamiento correcto de las aplicaciones multimedia y servicios sncronos, como la
voz y vdeo en tiempo real. De modo que la QoS hace referencia a la capacidad de garantizar
que se cumplen los requisitos de trfico para un determinado flujo de informacin. Esto se
traduce para el usuario final en la adquisicin de una conexin y un servicio descrito en
trminos de rapidez, fiabilidad, rendimiento y disponibilidad.

Si atendemos al funcionamiento de VoIP, el hecho de usar una red de conmutacin de

paquetes, implica que la informacin vocal es codificada y fragmentada originando un flujo de
paquetes que siguen rutas distintas entre el origen y el destino. Esto conlleva a que los paquetes
lleguen al destino, generalmente, desordenados y con distinto retardo acumulado, e incluso
puede ocurrir que no lleguen al destino debido a las prdidas. Debido a este fenmeno, es
necesario establecer ciertos requisitos en el trfico de VoIP generado:

Ancho de banda ocupado.

Retardo de los paquetes.
Prdidas de paquetes.
Calidad de la comunicacin.

Ancho de Banda

El ancho de banda (BW) establece la tasa mxima de transferencia de datos entre los extremos
de la comunicacin. Debido a que las comunicaciones en tiempo real son muy sensibles al
retraso y a la congestin que pueda sufrir la red, se tiene que garantizar un ancho de banda
mnimo para este tipo de paquetes.

Centrndonos en la voz sobre IP, los requerimientos de acho de banda para la transmisin de
la seal vocal vienen determinados por el cdec de voz usado en cuestin. En la siguiente tabla
puede observarse la relacin existente entre los cdecs de voz analizados en este estudio y el
BW consumido.

Para realizar el clculo del ancho de banda necesario por cada algoritmo de codificacin de voz
hay que tener en cuenta que se han aadido las cabeceras pertinentes al empaquetamiento de
los datos de voz.
El desglose de dichas cabeceras queda como sigue: 12 octetos para RTP, 8 para UDP, 20 para
IP y 18 bytes de cabecera de nivel de enlace, suponiendo que se trata de Ethernet con 4 octetos
de cdigo de redundancia cclica (CRC).

Silc o opus

Por ltimo, comentar que el cdec no slo determina la manera de muestrear y digitalizar la
informacin sino que tambin se encarga de comprimir la secuencia de datos. Esta compresin
de la forma de onda posee bastante relevancia en cuanto al ahorro del ancho de banda. Esto es
especialmente importante en los enlaces de baja capacidad y permite realizar un mayor nmero
de conexiones simultneamente. Otra manera de preservar el ancho de banda consiste en el
uso de las tramas SID, supresin de silencios. Proceso por el cual se genera una trama de ruido
de confort, en lugar de una rfaga de tramas activas, que sustituye a los silencios en la
conversacin.

Retardo

Como se ha comentado anteriormente, el hecho de que las comunicaciones a travs de VoIP

sean en tiempo real hace que el trfico intercambiado sea muy sensible al retardo. Los efectos
producidos en la conversacin que se derivan del retardo son:

Eco. Es consecuencia de las reflexiones de la seal transmitida. De manera que cuando el

retardo supera el umbral de los 25 ms, el transmisor percibe una seal molesta y retrasada de
sus propias palabras. Si el retraso alcanzara niveles muy elevados, mantener la conversacin
sera imposible.

Talker overlap. Este fenmeno ocurre cuando uno de los abonados se superpone a la voz del
otro debido a un gran retardo de los paquetes no permitiendo la interactividad entre los
locutores. Esto comienza a ser apreciable a partir de los 150 ms aproximadamente.

Por regla general, la voz comienza a degradarse a partir de los 150 ms, aunque, en condiciones
extraordinarias, se puede aceptar hasta 400 ms. No obstante, el retardo es un factor crtico en
este tipo de comunicaciones.

Para solventarlo es relevante conocer las fuentes que lo provocan. stas pueden agruparse en
dos grupos:

Retardo en la pasarela.

Retardo algortmico. Es introducido por el cdec usado y es inherente al algoritmo de

codificacin.

Retardo de empaquetamiento. Hace referencia al tiempo que se requiere para rellenar un

paquete de informacin, es decir la carga til del paquete sin cabeceras, con los datos ya
codificados y comprimidos. Depende directamente del tamao de trama definido por cada
cdec y el nmero de tramas por paquetes.

Retardo de serializacin. Est relacionado con la tasa del reloj de transmisin. Se define como
el tiempo requerido para inyectar una unidad de informacin en la interfaz de red.

Retardo de supresin de jitter. Este retardo se debe al almacenamiento temporal del flujo de
paquetes en un buffer del extremo receptor. Esto se hace as para eliminar la variabilidad del
retardo transformando los retrasos variables a retrasos fijos.

Retardo en la red.

Retardo de propagacin. Es el tiempo requerido por el paquete para llegar desde su origen al
destino. Depende tanto del medio de propagacin como del estado de la red. 35

Retardo de encolado. Tiempo que esperan los paquetes almacenados en una cola de salida
antes de ser transmitidos por la red.

Todos estos tipos de retardos son considerablemente importantes para un correcto

funcionamiento de una conversacin a travs de la red de paquetes. Sin embargo, en el caso de
estudio slo podemos considerar los retardos originados en el extremo transmisor. Aun ms,
dentro de este grupo es posible considerar ciertos retrasos como despreciables frente al
componente fundamental. As, nos referimos al retardo de encolado que existe en el
multiplexor como el predominante respecto al retardo algortmico, de empaquetado y de
serializacin.

Perdidas de paquetes

La prdida de paquetes es un fenmeno que ocurre con mucha frecuencia en las redes de
paquetes como consecuencia de una congestin de red. Los paquetes al atravesarla pueden
encontrarse la cola de salida de algn elemento de red llena de tal manera que no se aceptan
paquetes nuevos y, consecuentemente, se desechan. Otro factor que puede provocar esta
impertinencia es que los paquetes lleguen con demasiado retraso al extremo receptor y tengan
que ser descartados.

En aplicaciones que no funcionan en tiempo real es posible solventar en cierta medida el

problema de la prdida de paquetes haciendo uso del protocolo de transporte TCP el cual
permite retransmitir los paquetes que no lleguen al destino correctamente. Sin embargo, esto
no es procedente para el tipo de trfico que nos concierne puesto que cualquier retransmisin
produce un retardo adicional no tolerable generalmente. Ah reside la razn por la cual se hace
uso del protocolo de transporte UDP.

La consecuencia primordial de los paquetes perdidos es un deterioro de la seal de voz. Esto

se debe a que cada trama contiene, de forma aproximada pues depende del tipo de cdec, un
fonema de voz. En consecuencia, cuando se pierde un paquete se pierde el fonema
correspondiente o, en su defecto, varios de ellos pues depende del nmero de tramas
contenidas en cada uno de los paquetes. Cuando la tasa de prdidas es pequea, an
provocando una disminucin en la calidad de servicio, no presenta un gran problema pues los
decodificadores incluyen mecanismos de interpolacin y el cerebro humano es capaz de
reconstruir el intervalo de conversacin no recibida. Sin embargo, probabilsticamente, la
prdida de un paquete suele traducirse en la prdida de varios de ellos, lo que s degrada
severamente la calidad de la comunicacin.

De nuevo, en el escenario de simulacin propuesto, el fenmeno de la prdida de paquetes

ser estudiado en el conmutador del extremo transmisor.

Calidad de la comunicacin

La calidad de servicio en VoIP est ntimamente ligada con la percepcin que tienen los
usuarios finales de la conversacin mantenida. Existen medidas subjetivas que implican a
personas fsicas y mtodos de medicin que emulan la percepcin del odo humano y permiten
obtener una puntuacin equivalente.

Mtodos Subjetivos

En los mtodos subjetivos se distinguen dos mtodos de evaluacin de la calidad del audio:
por evaluacin directa (ACR) o por comparacin contra un audio de referencia (DCR). Con
evaluaciones directas se califica la calidad en funcin de una escala del uno al cinco, siendo
cinco excelente y uno malo, tal como muestra la tabla 8. El MOS (Mean Opinion Score)
es la escala ms utilizada basada en someter a conversacin a un gran nmero de usuarios y
promediar la nota otorgada por cada uno de ellos. Esta metodologa de evaluacin se halla
estandarizada en la recomendacin ITU-T P.800.

En cambio, si la evaluacin es comparativa, el rango de calificacin tambin oscila entre uno y

cinco, pero con la salvedad de que en este caso se califica en funcin del esfuerzo empleado
por los usuarios para entender la conversacin debido a las diferencias entre el audio de
referencia y el medido. As, se define una escala equivalente conocida como DMOS
(Degradation MOS).

En general, los mtodos subjetivos son caros, lentos y dependientes de factores como el pas,
el idioma, la actitud de los participantes, etc.
Mtodos Objetivos

En cuanto a los mtodos objetivos predominan tres recomendaciones de la ITU-T: el modelo

E, la recomendacin P.863 y la g.107. Todos ellos tienen en comn que se basan en
mediciones de propiedades fsicas de una red para estimar la evaluacin de los usuarios. A su
vez, se diferencian entre mtodos intrusivos, basados en medir la degradacin a la salida 38
sufrida por una seal conocida previamente inyectada en la red; y no intrusiva, consistente en
monitorizar ciertos parmetros para determinar la calidad en tiempo real.

Modelo E

El modelo E es el modelo de opinin ms ampliamente difundido. Se basa en una

cuantificacin escalar de la calidad del sonido que se estima que percibir un usuario. Este
modelo suele usarse como una herramienta informtica para la planificacin de la transmisin.
Una caracterstica fundamental es que incluye factores de degradacin de la seal transmitida
que reflejen los efectos de los dispositivos de red que intervienen en la generacin, transmisin
y conmutacin de la seal de audio. De manera que dicho modelo proporciona, en base a
diversos parmetros medibles en la red, el factor R, el cual es posible traducirlo a una escala
MOS tal como se refleja en la siguiente tabla.

El factor R viene dado por la siguiente expresin:

Cada uno de los componentes de la ecuacin anterior se calcula a partir de los parmetros de
transmisin que se muestran en la figura contenida en la recomendacin de la ITU-T g.107 y
que se presenta en este documento,

El componente representa la relacin seal a ruido, es decir, describe el efecto del ruido en
la comunicacin incluyendo fuentes de ruido tales como el ruido de circuito y el ruido
ambiente. El factor es la suma de todos los impedimentos que ocurren simultneamente
con la transmisin de la voz y se divide en factores ms especficos que contemplan el
volumen de la conexin y la distorsin de la cuantificacin.

modela las degradaciones producidas por los retardos y el eco, el cual a su vez se divide en
factores ms especficos que distinguen entre el eco del transmisor y del receptor. El sumando
representa el factor de ventaja que significa que se admite una degradacin de la calidad de la
comunicacin por parte del usuario a cambio de otras facilidades en el acceso al servicio.

El factor , es el factor de degradacin por equipo efectivo y se corresponde a las

degradaciones producidas por los cdec y por las prdidas de paquetes. Para cuantificar esta
degradacin se definen cuatro parmetros: factor de degradacin por equipo ( ), su valor se
halla tabulado para distintos cdecs; robustez ante prdida de paquetes (), tabulado
igualmente; probabilidad de prdida de paquetes ( ) y ratio de rfagas (). Cuando la
conversacin se realiza a travs de VoIP, este ltimo parmetro juega un rol muy importante ya
que las prdidas, por lo general, se producen a rfagas haciendo que tome un valor superior a
uno.

Algunas crticas realizadas a este modelo es que no tiene en cuenta degradaciones debidas a
adaptaciones dinmicas, como por ejemplo cambio de cdecs o variacin del tamao del
buffer de reproduccin.

QoS.-
Calidad de servicio QoS refiere a la medida del rendimiento de la red desde el punto de vista
tcnico, y a la posibilidad de gestionarla para cumplir con las prestaciones necesarias para las
aplicaciones.

Los mtodos subjetivos de medida de la calidad de servicio, se basan en conocer directamente

la opinin de los usuarios.Tpicamente resultan en un promedio de opiniones (por ejemplo, en
un valor de MOS Mean Opinin Store).

La calidad de la voz se establece a travs de la opinin del usuario. La calidad de audio puede
ser evaluada directamente

ACR = Absolute Category Rating.

DCR = Degradation Category Rating.

Tomando en cuenta un total de 69 personas encuestadas donde se les pregunto si usaba el

servicio de Skype tanto en sus computadoras como en sus diferentes dispositivos porttiles se
lleg a los siguientes datos.

calificacin Nro. de personas

excelente 1 20
buena 2 15
regular 3 14
mediocre 4 12
mala 5 8

MOS Mean Opinin Store

25

20
NMERO DE VOTOS

15

10

0
1 2 3 4 5
PUNTAJE DE OPINN

Gracias a ACR podemos ver que la opinion de un numero de personas y su opinion subjetiva
acerca del servicio de voz ip ademas agregar la conformidad del servicio y en su mayoria la
gente utiliza este servicio en sus dispositivos moviles.
De la misma manera gracias a DCR podemos determinar comparando cpon una media de 2,5
las puntuaciones de las 69 personas preguntadas

inaudible 1 5
audible 2 40
poco molesta 3 15
molesta 4 9
muy molesta 5 5

Con un total de 191 de calificacin, de 69 personas con una media de 2,76 de promedio sobre la
media del proyecto de 2,5.

QUIC

Google no slo se encarga de desarrollar software sino que quiere acelerar Internet. Primero
cre SPDY, un protocolo para aumentar la velocidad y disminuir la latencia de las pginas web
con respecto al protocolo HTTP, tenis todos los detalles de SPDY en este artculo. Ahora
Google ha creado QUIC, un protocolo de red experimental basado en el protocolo UDP.
Las siglas de QUIC significan Quick UDP Internet Connections, y lo que pretende este
protocolo es que las lneas de Internet de baja velocidad y alta latencia, tenga mejores
resultados que usando el protocolo TCP que se utiliza actualmente en todas las conexiones.
Debemos recordar que TCP es un protocolo fiable y orientado a conexin, QUIC quiere ser
orientado a conexin pero bajo UDP.
Google ha anunciado que un pequeo grupo de usuarios de su navegador, Google Chrome, va
a empezar a navegar con QUIC de forma experimental. En principio, los usuarios no notarn
ninguna diferencia, excepto que la navegacin web ir bastante ms rpido.
El protocolo QUIC soporta varias conexiones multiplexadas entre dos puntos finales mediante
UDP, y proporciona una seguridad equivalente a SSL/TLS por lo que nuestros datos irn
perfectamente cifrados.
Las principales caractersticas que QUIC nos proporcionar son las siguientes:

Mejorar la latencia de la conexin.

Mecanismos de control de congestin.
Correccin de los errores de paquetes para evitar la retransmisin.

El principal motivo para desarrollar QUIC, segn Google, es por el retraso que introduce TCP
al flujo de datos cuando hay retraso en un paquete.
QUIC es cdigo libre y el objetivo de Google es convertirlo en un nuevo estndar, equivalente
a las conexiones TCP pero con una latencia muy reducida y una mejor compatibilidad con
SPDY. Si los resultados de QUIC son satisfactorios, se podra integrar en posteriores versiones
de TCP y TLS.

STUN

Se utiliza un servidor STUN (Simple Traversal of User Datagram Protocol [UDP] through
Network Address Translators [NATs]), para conseguir que los clientes NAT (tal como
computadores detrs de un firewall) puedan efectuar llamadas telefnicas a un proveedor
VOIP alojado fuera de su red local.

En una llamada de VoIP con SIP los usuarios suelen encontrar problemas, como audio
unidireccional o fallos al intentar registrarse con un proveedor de VoIP o con una centralita IP
que no est en la misma red. Esto suele deberse a cmo funcionan los protocolos SIP cuando
las entidades estn detrs de un router o firewall (escenarios bastante usuales). STUN ayuda a
resover esoso problemas.
STUN es un protocolo de red del tipo cliente/servidor que tiene como principal objetivo
conseguir que clientes NAT encuentren su direccin IP pblica, el tipo de NAT en el que se
encuentra y el puerto de Internet asociado con el puerto local por medio de NAT. Consigue
que el dispositivo que est detras de una pasarela conozca qu traduccin de puertos hizo la
pasarela (NAT); es decir qu puerto han de emplear otros dispositivos para conectarse con l.
Hay que tener en cuenta que no siempre los routers y pasarelas traducen los puertos; dependen
del tipo de NAT que tengam y cmo se haya configurado.[2] Esta informacin se utiliza para
configurar una comunicacin UDP entre dos hosts que se encuentren tras enrutadores NAT.
Se usa esta informacin para configurar la comunicacin UDP entre el cliente y el proveedor
VOIP y as poder establecer la llamada. En la actualidad este protocolo est definido en
[RFC5389].

SSDP

El Protocolo Simple de Descubrimiento de Servicios (Simple Service Discovery Protocol) es

un protocolo que sirve para la bsqueda de dispositivos UPnP en una red. Utiliza UDP en
unicast o multicast en el puerto 1900 para anunciar los servicios de un dispositivo. Slo la
informacin ms importante acerca el dispositivo y el servicio ofrecido est contenido en los
mensajes intercambiados.
El protocolo se utiliza tambin para buscar ciertos servicios en la red. Un Punto de Control
UPnP (UPnP Control Point) manda un mensaje a todos los dispositivos en la red por el mismo
canal, igual que los anuncios. Si alguno de ellos ofrece el servicio deseado le contesta con un
mensaje normal HTTP con el cdigo '200 OK'. Este mensaje se manda en UDP unicast.
QoS objetivo.-
Se realizo una diferentes videollamadas para poder analizar datos recolectados por medio del
sniffer wireshark