{"id":7929,"date":"2016-09-02T15:28:32","date_gmt":"2016-09-02T20:28:32","guid":{"rendered":"http:\/\/www.servervoip.com\/blog\/?p=7929"},"modified":"2019-06-07T11:44:02","modified_gmt":"2019-06-07T16:44:02","slug":"qos-calidad-de-servicio-para-voip","status":"publish","type":"post","link":"http:\/\/www.servervoip.com\/blog\/qos-calidad-de-servicio-para-voip\/","title":{"rendered":"QoS-Calidad de Servicio para VoIP"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n<\/div>\n
\n <\/span>\n <\/div>\n<\/div>\n

QoS o Calidad de Servicio (Quality of Service, en ingl\u00e9s): <\/strong> Son las tecnolog\u00edas que garantizan la transmisi\u00f3n de cierta cantidad de informaci\u00f3n en un tiempo dado (throughput). Calidad de servicio es la capacidad de dar un buen servicio. Es especialmente importante para ciertas aplicaciones tales como la transmisi\u00f3n de v\u00eddeo o voz.<\/p>\n

El auge de la telefon\u00eda IP es algo evidente y la principal raz\u00f3n es el reaprovechamiento de los recursos y la disminuci\u00f3n en el coste de llamadas a trav\u00e9s de Internet. Sin embargo, si de algo adolece todav\u00eda la VoIP es de la calidad de los sistemas telef\u00f3nicos tradicionales. Los problemas de esta calidad son muchos veces inherentes a la utilizaci\u00f3n de la red (Internet y su velocidad y ancho de banda) y podr\u00e1n irse solventando en el futuro. Mientras tanto, cuanto mejor conozcamos los problemas que se producen y sus posibles soluciones mayor calidad disfrutaremos.
\nLos principales problemas en cuanto a la calidad del servicio (QoS) de una una red de VoIP, son la Latencia, el Jitter la p\u00e9rdida de paquetes y el Eco. En VoIP estos problemas pueden ser resueltos mediante diversas t\u00e9cnicas que se explican en los siguientes apartados.<\/p>\n

Los problemas de la calidad del servicio en VoIP vienen derivados de dos factores principalmente:<\/p>\n

a) Internet es un sistema basado en conmutaci\u00f3n de paquetes y por tanto la informaci\u00f3n no viaja siempre por el mismo camino. Esto produce efectos como la p\u00e9rdida de paquetes o el jitter.
\nb) Las comunicaciones VoIP son en tiempo real lo que produce que efectos como el eco, la p\u00e9rdida de paquetes y el retardo o latencia sean muy molestos y perjudiciales y deban ser evitados.
\nMuchas cosas le ocurren a los paquetes desde su origen al destino, resultando los siguientes problemas vistos desde el punto de vista del transmisor y receptor:<\/p>\n

Paquetes sueltos<\/strong>
\nLos ruteadores pueden fallar en liberar algunos paquetes si ellos llegan cuando los buffers ya est\u00e1n llenos. Algunos, ninguno o todos los paquetes pueden quedar sueltos dependiendo del estado de la red, y es imposible determinar que pasar\u00e1 de antemano. La aplicaci\u00f3n del receptor puede preguntar por la informaci\u00f3n que ser\u00e1 retransmitida posiblemente causando largos retardos a lo largo de la transmisi\u00f3n.<\/p>\n

Retardos<\/strong>
\nPuede ocurrir que los paquetes tomen un largo per\u00edodo en alcanzar su destino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa para prevenir la congesti\u00f3n de la red. En algunos casos, los retardos excesivos pueden inutilizar aplicaciones tales como VoIP.<\/p>\n

Jitter<\/strong>
\nLos paquetes del transmisor pueden llegar a su destino con diferentes retardos. Un retardo de un paquete var\u00eda impredeciblemente con su posici\u00f3n en las colas de los ruteadores a lo largo del camino entre el transmisor y el destino. Esta variaci\u00f3n en retardo se conoce como jitter y puede afectar seriamente la calidad del flujo de audio y\/o v\u00eddeo.
\nEntrega de paquetes fuera de orden<\/p>\n

Cuando un conjunto de paquetes relacionados entre s\u00ed son encaminados a Internet, los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos. Esto ocasiona que los paquetes lleguen en diferente orden de como fueron enviados. Este problema requiere un protocolo que pueda arreglar los paquetes fuera de orden a un estado is\u00f3crono una vez que ellos lleguen a su destino. Esto es especialmente importante para flujos de datos de v\u00eddeo y VoIP donde la calidad es dram\u00e1ticamente afectada tanto por latencia y p\u00e9rdida de sincron\u00eda.<\/p>\n

Errores<\/strong>
\nA veces, los paquetes son mal dirigidos, combinados entre s\u00ed o corrompidos cuando se encaminan. El receptor tiene que detectarlos y justo cuando el paquete es liberado, pregunta al transmisor para repetirlo as\u00ed mismo.
\nVeamos con mas detalle los fenomenos que afectan en la calidad de la transmision de la voz y el video:<\/p>\n

Jitter
\nCAUSAS:<\/strong>
\nEl jitter es un efecto de las redes de datos no orientadas a conexi\u00f3n y basadas en conmutaci\u00f3n de paquetes. Como la informaci\u00f3n se discretiza en paquetes cada uno de los paquetes puede seguir una ruta distinta para llegar al destino.
\nEl jitter se define t\u00e9cnicamente como la variaci\u00f3n en el tiempo en la llegada de los paquetes, causada por congesti\u00f3n de red, perdida de sincronizaci\u00f3n o por las diferentes rutas seguidas por los paquetes para llegar al destino.
\nLas comunicaciones en tiempo real (como VoIP) son especialmente sensibles a este efecto. En general, es un problema frecuente en enlaces lentos o congestionados. Se espera que el aumento de mecanismos de QoS (calidad del servicio) como prioridad en las colas, reserva de ancho de banda o enlaces de mayor velocidad (100Mb Ethernet, E3\/T3, SDH) puedan reducir los problemas del jitter en el futuro aumque seguir\u00e1 siendo un problema por bastante tiempo.<\/p>\n

VALORES RECOMENDADOS:<\/strong><\/p>\n

El jitter entre el punto inicial y final de la comunicaci\u00f3n debiera ser ser inferior a 100 ms. Si el valor es menor a 100 ms el jitter puede ser compensado de manera apropiada. En caso contrario debiera ser minimizado.<\/p>\n

POSIBLES SOLUCIONES:<\/strong>
\n\u2013 La soluci\u00f3n m\u00e1s ampliamente adoptada es la utilizaci\u00f3n del jitter buffer. El jitter buffer consiste b\u00e1sicamente en asignar una peque\u00f1a cola o almacen para ir recibiendo los paquetes y sirviendolos con un peque\u00f1o retraso. Si alguno paquete no est\u00e1 en el buffer (se perdi\u00f3 o no ha llegado todav\u00eda) cuando sea necesario se descarta. Normalmente en los telefonos IP (hardware y software) se pueden modificar los buffers. Un aumento del buffer implica menos perdida de paquetes pero m\u00e1s retraso. Una disminuci\u00f3n implica menos retardo pero m\u00e1s perdida de paquetes.<\/p>\n


\nLatencia
\nCAUSAS:<\/strong>
\nA la latencia tambi\u00e9n se la llama retardo. No es un problema espec\u00edfico de las redes no orientadas a conexi\u00f3n y por tanto de la VoIP. Es un problema general de las redes de telecomunicaci\u00f3n. Por ejemplo, la latencia en los enlaces via satelite es muy elevada por las distancias que debe recorrer la informaci\u00f3n.
\nLa latencia se define t\u00e9cnicamente en VoIP como el tiempo que tarda un paquete en llegar desde la fuente al destino.
\nLas comunicaciones en tiempo real (como VoIP) y full-duplex son sensibles a este efecto. Es el problema de \u201cpisarnos\u201d. Al igual que el jitter, es un problema frecuente en enlaces lentos o congestionados.<\/p>\n

VALORES RECOMENDADOS:<\/strong><\/p>\n

La latencia o retardo entre el punto inicial y final de la comunicaci\u00f3n debiera ser ser inferior a 150 ms. El o\u00eddo humano es capaz de detectar latencias de unos 250 ms, 200 ms en el caso de personas bastante sensibles. Si se supera ese umbral la comunicaci\u00f3n se vuelve molesta.<\/p>\n

POSIBLES SOLUCIONES:<\/strong><\/p>\n

No hay una soluci\u00f3n que se pueda implementar de manera sencilla. Muchas veces depende de los equipos por los que pasan los paquetes, es decir, de la red misma. Se puede intentar reservar un ancho de banda de origen a destino o se\u00f1alizar los paquetes con valores de TOS para intentar que los equipos sepan que se trata de tr\u00e1fico en tiempo real y lo traten con mayor prioridad pero actualmente no suelen ser medidas muy eficaces ya que no disponemos del control de la red.
\nSi el problema de la latencia est\u00e1 en nuestra propia red interna podemos aumentar el ancho de banda o velocidad del enlace o priorizar esos paquetes dentro de nuestra red.<\/p>\n

Eco
\nCAUSAS:<\/strong><\/p>\n

El eco se produce por un fenomeno t\u00e9cnico que es la conversi\u00f3n de 2 a 4 hilos de los sistemas telef\u00f3nicos o por un retorno de la se\u00f1al que se escucha por los altavoces y se cuela de nuevo por el microfono. El eco tambi\u00e9n se suele conocer como reverberaci\u00f3n.
\nEl eco se define como una reflexi\u00f3n retardada de la se\u00f1al acustica original.
\nEl eco es especialmente molesto cuanto mayor es el retardo y cuanto mayor es su intensidad con lo cual se convierte en un problema en VoIP puesto que los retardos suelen ser mayores que en la red de telefon\u00eda tradicional.<\/p>\n

VALORES RECOMENDADOS:<\/strong><\/p>\n

El o\u00eddo humano es capaz de detectar el eco cuando su retardo con la se\u00f1al original es igual o superior a 10 ms. Pero otro factor importante es la intensidad del eco ya que normalmente la se\u00f1al de vuelta tiene menor potencia que la original. Es tolerable que llegue a 65 ms y una atenuaci\u00f3n de 25 a 30 dB.<\/p>\n

POSIBLES SOLUCIONES:<\/strong><\/p>\n

En este caso hay dos posibles soluciones para evitar este efecto tan molesto.
\n\u2013 Supresores de eco \u2013 Consiste en evitar que la se\u00f1al emitida sea devuelta convirtiendo por momentos la linea full-duplex en una linea half-duplex de tal manera que si se detecta comunicaci\u00f3n en un sentido se impide la comunicaci\u00f3n en sentido contrario. El tiempo de conmutaci\u00f3n de los supresores de eco es muy peque\u00f1o. Impide una comunicaci\u00f3n full-duplex plena.
\n\u2013 Canceladores de eco \u2013 Es el sistema por el cual el dispostivo emisor guarda la informaci\u00f3n que env\u00eda en memoria y es capaz de detectar en la se\u00f1al de vuelta la misma informaci\u00f3n (tal vez atenuada y con ruido). El dispostivo filtra esa informaci\u00f3n y cancela esas componentes de la voz. Requiere mayor tiempo de procesamiento.<\/p>\n

[rev_slider captions]
\n[rev_slider ServerVoip]
\n <\/p>\n

\n

P\u00e9rdida de paquetes \u2013 packet loss
\nCAUSAS:<\/strong>
\nLas comunicaciones en tiempo real est\u00e1n basadas en el protocolo UDP. Este protocolo no est\u00e1 orientado a conexi\u00f3n y si se produce una p\u00e9rdida de paquetes no se reenvian. Adem\u00e1s la perdida de paquetes tambi\u00e9n se produce por descartes de paquetes que no llegan a tiempo al receptor.
\nSin embargo la voz es bastante predictiva y si se pierden paquetes aislados se puede recomponer la voz de una manera bastante \u00f3ptima. El problema es mayor cuando se producen p\u00e9rdidas de paquetes en r\u00e1fagas.<\/p>\n

VALORES RECOMENDADOS:<\/strong><\/p>\n

La perdida de paquetes m\u00e1xima admitida para que no se degrade la comunicaci\u00f3n deber ser inferior al 1%. Pero es bastante dependiente del c\u00f3dec que se utiliza. Cuanto mayor sea la compresi\u00f3n del codec m\u00e1s pernicioso es el efecto de la p\u00e9rdida de paquetes. Una p\u00e9rdida del 1% degrada m\u00e1s la comunicaci\u00f3n si se usa el c\u00f3dec G.729 en vez del G.711.<\/p>\n

POSIBLES SOLUCIONES:<\/strong><\/p>\n

Para evitar la p\u00e9rdida de paquetes una t\u00e9cnica muy eficaz en redes con congesti\u00f3n o de baja velocidad es no transmitir los silencios. Gran parte de las conversaciones est\u00e1n llenas de momentos de silencio. Si solo transmitimos cuando haya informaci\u00f3n audible liberamos bastante los enlaces y evitamos fenomenos de congesti\u00f3n.
\nDe todos modos este fenomeno puede estar tambi\u00e9n bastante relacionado con el jitter y el jitter buffer.<\/p>\n


\nAncho de banda insuficiente
\nCAUSAS:<\/strong><\/p>\n

El ancho de banda de las comunicaciones es limitado y suele estar compartido por numerosas aplicaciones (web, correo electr\u00f3nico, tr\u00e1fico FTP, descarga de archivos,\u2026).
\nEn conexiones a Internet el ancho de banda se define t\u00e9cnicamente como la cantidad de informaci\u00f3n o de datos que se puede enviar a trav\u00e9s de una conexi\u00f3n de red en un per\u00edodo de tiempo dado. El ancho de banda se indica generalmente en bites por segundo (BPS), kilobites por segundo (kbps), o megabites por segundo (mps).
\nSi nuestras comunicaciones de VoIP comparten ancho de banda con otras aplicaciones puede que no tengamos suficiente capacidad para mantener correctamente una comunicaci\u00f3n de Voz IP.<\/p>\n

VALORES RECOMENDADOS:<\/strong><\/p>\n

El ancho de banda est\u00e1 fuertemente relacionado con el codec o codificaci\u00f3n que estemos usando. Por ejemplo para una comunicaci\u00f3n usando el codec G.711 codificamos la voz a 64 Kbps. Como tenemos que a\u00f1adirle cabeceras para empaquetar los paquetes de voz podemos necesitar aproximadamente 80 Kbps de ancho de banda para una sola conversaci\u00f3n (depende de los protocolos sobre los que encapsulemos)
\nSi utilizamos por ejemplo un codec como G.729 m\u00e1s comprimido y que codifica la voz a 8 Kbps necesitaremos,al a\u00f1adirle las cabeceras unos 24 Kbps de ancho de banda para mantener una conversaci\u00f3n.<\/p>\n

POSIBLES SOLUCIONES:<\/strong><\/p>\n

Si tenemos problemas de ancho de banda podemos abordar el problema desde varios frentes:
\n\u2013 Aumentar el ancho de banda de las redes por las que circulen nuestras comunicaciones (normalmente pagando m\u00e1s)
\n\u2013 Reducir el consumo que hagan otras aplicaciones del ancho de banda (especialmente las descargas de archivos mediante redes de intercambio)
\n\u2013 Usar un codec con mayor compresi\u00f3n que usen menos ancho de banda. (Ej: G729)<\/p>\n

Pruebas de QoS en VoIP<\/strong><\/p>\n

Para poder comprobar como es la calidad de nuestro enlace para el funcionamiento de la VoIP existen algunas herramientas web muy interesantes que podemos consultar y que nos daran resultados muy interesantes.<\/p>\n

\u2013 Para comprobar el nivel de jitter y los paquetes perdidos podemos visitar la siguiente p\u00e1gina:
\nhttp:\/\/myspeed.visualware.com\/indexvoip.php<\/p>\n

Realiza un test en funci\u00f3n del servidor escogido y el codec que deseamos utilizar.
\nEsta otra p\u00e1gina hace un test parecido pero no nos deja escoger el codec.
\nhttp:\/\/www.voiptest.org\/speedtest.swf
\nLos resultados nos ser\u00e1n los mismos puesto que se usan servidores diferentes pero nos daran una idea de la calidad de nuestras conexiones y nos servira para detectar problemas.<\/p>\n

Este es un modelo que es bastante \u00fatil para comprender de qu\u00e9 formas podemos intentar garantizar la QoS y con cu\u00e1les conseguirlo. En esta figura est\u00e1n representadas las dos acciones fundamentales asociadas a garantizar la QoS:<\/p>\n

\u2022\tClasificaci\u00f3n: El tr\u00e1fico que entra al equipo y que se ha de transmitir se tiene que clasificar. Pueden usarse muchos criterios de clasificaci\u00f3n: Por equipo destino, por marcas en los paquetes, por aplicaci\u00f3n\u2026 Es algo que siempre hay que hacer ya que si no el propio concepto de QoS no existe. B\u00e1sicamente, la clasificaci\u00f3n es buscar a qu\u00e9 par\u00e1metros de QoS negociados o contratados pertenece un paquete (o tr\u00e1fico) en particular: Tr\u00e1fico m\u00e1ximo en r\u00e1faga, tr\u00e1fico m\u00ednimo sostenido, latencia m\u00e1xima, variaci\u00f3n en la latencia\u2026
\n\u2022\tAsignaci\u00f3n de recursos: Una vez que se tiene el tr\u00e1fico clasificado, y por tanto se saben qu\u00e9 par\u00e1metros de QoS se deben cumplir, hay que asignar los recursos en la interfaz. Hay que permitir que los paquetes se transmitan al medio (el aire o un cable).<\/p>\n

La fase de clasificaci\u00f3n es com\u00fan a todos los tipos de interfaz que necesitan garantizar la QoS, pero la principal diferencia viene en la fase de asignaci\u00f3n de recursos. Existen dos mecanismo que son lo bastante generales como para merecer que les demos un nombre \u201cQoS a nivel 3 (L3QoS o IPQoS)\u201d y \u201cQoS a nivel 2 (L2QoS o MACQoS)\u201d.<\/p>\n

L3QoS: QoS a nivel IP<\/strong><\/p>\n

Las t\u00e9cnicas que se usan en este tipo de mecanismos de QoS son los t\u00edpicos de los conformadores de tr\u00e1fico o traffic shapers (TS). El TS clasifica el tr\u00e1fico que entra en funci\u00f3n de los criterios que se establezcan para cada una de los contratos de QoS. Es tambi\u00e9n conocida como QoS a nivel IP.<\/p>\n

Una vez que el tr\u00e1fico est\u00e1 clasficado, el TS asigna de una forma estad\u00edstica los recursos de transmisi\u00f3n al medio. Por ejemplo si la cola de un servicio de baja latencia est\u00e1 muy llena, intentar\u00e1 vaciarla lo m\u00e1s r\u00e1pido posible o por ejemplo si la cola de un servicio con tasa m\u00ednima garantizada tiene paquetes, intentar\u00e1 mantener en promedio a la salida esa tasa.<\/p>\n

Estas t\u00e9cnicas de QoS a nivel 3, a veces llamados a nivel IP, son las cl\u00e1sicas basadas en colas de prioridades asociadas al DSCP o al TOS de las cabeceras IP, por ejemplo.<\/p>\n

El problema que presentan las t\u00e9cnica L3QoS es que no se conoce con exactitud la capacidad y la disponibilidad del medio sobre el que se transmiten. Imaginemos que tenemos un medio sin cables. El tr\u00e1fico bruto puede depender del usuario al que se transmita, ya que podr\u00edan estar mas lejos u obstruidos. Usar t\u00e9cnicas de L3QoS en estos casos, al desconocer la capacidad real por usuario destino, por ejemplo, lleva a una ineficiencia insalvable: \u201cNo se puede garantizar una QoS en t\u00e9rminos absolutos, solo relativos\u201d.<\/p>\n

Esto quiere decir que si tenemos un servicio de 1Mbps y otro de 2Mbps, la \u00fanica garant\u00eda que puede hacer un sistema de L3QoS es que el tr\u00e1fico del primero va a ser la mitad que el del segundo, pero no puede garantizar cu\u00e1l va a ser en realidad ese m\u00ednimo, ya que desconoce el estado y disponibilidad del medio.<\/p>\n

Este problema a\u00fan se agrava mucho m\u00e1s en el caso en el que el medio est\u00e1 gestionado en contienda (WiFi, ethernet\u2026) En estos casos el propio uso del medio es estad\u00edstico, ni siquiera el nivel 2 puede saber si podr\u00e1 transmitir en un momento dado. Es m\u00e1s, en el caso de que la red empiece a cursar mucho tr\u00e1fico, es posible que un paquete jam\u00e1s sea transmitido debido a las cont\u00ednuas colisiones.<\/p>\n

L2QoS: QoS a nivel MAC
\nCuando la asignaci\u00f3n de recursos se hace a nivel 2, el sistema que va asignando los slots de transmisi\u00f3n conoce en todo momento tanto la disponibilidad del medio como la calidad o tr\u00e1fico neto que es capaz de transmitir para cada usuario. Es tambi\u00e9n conocida como QoS a nivel MAC.<\/p>\n

Tomado de: http:\/\/elastixtech.com\/qos-calidad-de-servicio-para-voip\/<\/p>\n

DataCenter VoIP<\/h2>\n

Los edificios que alojan a los servidores en Europa y Estados Unidos son los centros de datos m\u00e1s ecol\u00f3gicos y fueron construidos como idea de almac\u00e9n de datos. La ubicaci\u00f3n estrat\u00e9gica en Europa central y en Estados Unidos son las ventajas principales.<\/p>\n

Los Data Centers est\u00e1n perfectamente situados para garantizar conexiones r\u00e1pidas a todos los territorios de Europa y Am\u00e9rica para que todos los clientes se beneficien de la mejor calidad en el servicio brindado. Por otra parte, el edificio que est\u00e1 situado en Europa se encuentra en una de las zonas m\u00e1s ricas de agua subterr\u00e1nea, lo que abre la posibilidad a ServerVoIP de realizar un innovador, ecol\u00f3gico y \u00fanico sistema de refrigeraci\u00f3n de forma natural.<\/p>\n

\"datacenter<\/a>
\n