Prodys Audio Over IP Tools Castellano

White paper Julio 09 Rev 06
NDICE
1.2.2.1.2.2.2.3.3.AUDIO SOBRE IP .................................................................................... 4 TIPOS DE CONEXIONES IP ....................................................................... 8 UNICAST ......................................................................................... 8 MULTICAST ..................................................................................... 8 MULTI-UNICAST .................................................................................. 9 PROTOCOLOS ..................................................................................... 11
3.1.EL ESTNDAR EBU TECH 3326 PARA CONTRIBUCIN DE AUDIO SOBRE IP ...................11 3.2.ALGORITMOS PROPIETARIOS DE PRODYS ......................................................12 3.2.1.Network Address Translation (NAT) ......................................................14 4.5.6.7.7.1.7.2.8.9.10.11.12.13.MECANISMO DE AJUSTE PLL DE PRODYS ................................................ 16 JITTER............................................................................................... 17 TAMAO DE LOS PAQUETES DE AUDIO ................................................... 18 PAQUETES PERDIDOS........................................................................... 19 FEC (FORWARD ERROR CORRECTION) ..........................................................19 ERROR CONCEALMENT ...........................................................................21 PAQUETES DESORDENADOS .................................................................. 22 ACTIVE RECOVERY ............................................................................. 23 HERRAMIENTAS DE MEDIDA DE PRODYS ............................................. 25 HERRAMIENTAS DE MONITORIZACIN: SNMP Y SISTEMA DE ALARMAS ... 28 DOBLE INTERFAZ LAN ...................................................................... 29 VLAN .............................................................................................. 30
Prodys S.L. Tel: +34 91 6896880 Fax: +34 91 6943777 Email: sales@prodys.net Web: www.prodys.com
Page 2
INTRODUCCIN
Prodys fue pionero en fabricar codificadores profesionales de audio sobre IP para el mercado del broadcast, lanzando nuestro primer codificador IP, el ProntoNet, en 2004. Nuestra experiencia en este sentido ha aumentado junto con las diferentes soluciones de hardware y software que hemos desarrollado como resultado de la cooperacin con nuestros clientes y otras personas del broadcast profesional, ayudndoles a encontrar soluciones viables para facilitar su migracin a esta nueva tecnologa IP. Esta gua prctica est encaminada a proporcionar los conocimientos fundamentales de todos los conceptos relevantes al streaming de audio sobre redes IP, as como el uso de las diferentes herramientas proporcionadas por PRODYS para tratar con ellas. El conocimiento de estas cuestiones y la manera de hacerles frente es esencial para el usuario para lograr una conexin de audio fiable sobre IP.
Page 3
1.- AUDIO SOBRE IP La mayora de las comunicaciones de audio digital en los ltimos aos se han logrado en redes sncronas donde se proporcionaba un reloj comn a ambos extremos de la conexin, as era posible sincronizar equipos con un simple mecanismo de bsqueda de reloj. Por tanto, los datos llegan al extremo remoto exactamente al mismo ritmo y en el mismo orden en que se enviaron desde el extremo transmisor. Adems, el flujo de datos era continuo y por lo tanto lo era el retardo. El tipo de llamada tenda a ser punto a punto y bidireccional. Esto es completamente diferente en las redes IP, donde la flexibilidad para el tipo de conexin es mucho ms amplia. Adems, hay una falta de reloj, por lo que el audiocodec IP debe conseguir un algoritmo con sincronizacin de reloj para compensar esto.
El flujo de datos est dividido en paquetes, donde cada paquete en un flujo puede ser tratado de una manera diferente del resto, de modo que el camino desde el transmisor al receptor podra variar dependiendo de varios factores diferentes. Esto puede introducir diferentes retardos en el tiempo de llegada de cada uno de los paquetes de audio, en otras palabras jitter en las comunicaciones IP.
Figura 1: Jitter
Page 4
#3
#3
El efecto del jitter en la comunicacin de audio es un buffer potencialmente vaco en el extremo decodificador. Esta falta de datos causar una interrupcin en el audio. Este comportamiento de la red podra introducir otras cuestiones importantes, que deben tenerse en cuenta, tales como la prdida y desorden de paquetes.
Figura 2: Diferentes caminos y paquetes desordenados
Figura 3: Prdida de paquetes Normalmente, un paquete se considera que se ha perdido cuando no llega a su destino debido a la congestin de la red o a cualquier otro problema relacionado con el procesado del flujo de datos en el camino desde la fuente al destino.
Page 5
Pa ck et A
A et ck Pa
Sin embargo, cuando hablamos de streaming de audio, algunos paquetes podran no llegar o llegar demasiado tarde para ser procesados. En streaming de audio, el resultado en ambos casos es el mismo: el paquete es considerado como un paquete perdido y como resultado hay una prdida de audio. Esta prdida de audio podra dar lugar a un corte de audio apreciable o no dependiendo de si las tcnicas de error concealment se pueden aplicar o no. Para continuar la comparacin con otros enlaces de audio digital, los enlaces IP necesitan alguna informacin extra que se enva a travs de la comunicacin junto con los datos de audio, en forma de cabeceras (overhead), lo que aumenta el ancho de banda necesario para conseguir el streaming de audio. El tamao de los paquetes de audio (frames o muestras) afectar al porcentaje de overhead, de manera que cuanto ms pequeo es el frame, ms grande ser el overhead en relacin a los datos de audio, pero menor ser el retardo. Por lo tanto, la configuracin de este parmetro es un compromiso entre retardo y ancho de banda.
Figura 4: Overhead Es por eso que el audiocodec IP debe permitir tamaos de paquete flexibles, de modo que el usuario pueda ajustar el equipo dependiendo de las necesidades de la aplicacin en relacin al retardo y ancho de banda. Los codecs IP de Prodys permiten al usuario configurar el tamao del paquete para todos los algoritmos de compresin de bajo retardo, proporcionando al usuario una ventana de informacin muy til que le informa sobre el retardo y overhead final dependiendo de los diferentes tamaos de paquete para el modo de compresin seleccionado.
Page 6
Figura 5: Informacin pgina Web
Para finalizar, tambin se proporciona una herramienta muy potente y de fcil uso que permite en tiempo real y durante la conexin de audio mostrar los parmetros crticos que SON ESENCIALES para el ajuste fino de la configuracin IP. Esta herramienta proporcionar al usuario toda la informacin en tiempo real sobre todos los parmetros crticos antes mencionados: jitter, paquetes perdidos, paquetes desordenados y ocupacin del buffer. El ltimo captulo explica cmo funciona con algunas capturas de pantalla.
Page 7
2.- TIPOS DE CONEXIONES IP Existen dos tecnologas diferentes para establecer conexiones de audio sobre IP: conexiones Unicast y Multicast. Para algunas redes que no soportan la tecnologa Multicast, como Internet, Prodys ha desarrollado un protocolo especial: Multi-Unicast que es una combinacin de los dos tipos de conexin y est disponible en todos los audiocodecs IP de Prodys.
2.1.UNICAST
Las conexiones Unicast son conexiones punto a punto, muy similares a los enlaces sobre RDSI, por ejemplo. Las conexiones Unicast pueden ser unidireccionales o bidireccionales. Adems, las conexiones unidireccionales pueden ser conexiones de salida o de entrada de datos: conexiones Unicast Tx or Unicast Rx respectivamente.
Figura 6: conexin Unicast

2.2.MULTICAST
Las conexiones Multicast son conexiones unidireccionales punto a multipunto. Con MULTICAST las llamadas deben ser hechas desde ambos extremos. Tanto el transmisor de los datos como todos los receptores deben llamar para establecer una conexin a un grupo multicast. La operacin multicast puede verse en el siguiente diagrama:
Page 8
Figura 7: conexin Multicast La gran ventaja del multicast es que el ancho de banda requerido sigue siendo el mismo independientemente del nmero de destinatarios, ya sea 1 o N, siendo el modo ms apropiado para distribucin de audio desde una fuente a varios destinos al mismo tiempo y con el mismo audio. El nico inconveniente es que no todas las redes IP soportan Multicast. De hecho, las redes de rea global, como Internet, no son compatibles con este modo.
2.3.MULTI-UNICAST
Con la inclusin del Multi-Unicast, el usuario puede simular una conexin Multicast punto a multi-punto sobre IP estableciendo tantas conexiones unicast como nmero de receptores. Esto permite al usuario enviar el mismo audio hasta a 10 destinos diferentes sobre estas redes IP que no soportan Multicast.
Page 9
Figura 8. Multi-Unicast El nico inconveniente de este modo es que el ancho de banda requerido en el extremo transmisor se multiplicar por el nmero de receptores.
Page 10
...
3.- PROTOCOLOS Los tipos de conexiones sobre IP mencionados anteriormente, solo definen un medio para transportar datos desde un emisor a uno o varios receptores, pero no definen la forma de establecer, controlar y echar abajo la conexin, as como el mecanismo para negociar el modo de compresin para las conexiones de audio y la manera de integrar otros datos auxiliares de informacin junto con el audio en el flujo de audio. Prodys ha desarrollado tanto protocolos propietarios como estndar, basados en el estndar EBU TECH 3326 para contribucin de audio sobre IP.
3.1.EL ESTNDAR EBU TECH 3326 PARA CONTRIBUCIN DE AUDIO SOBRE IP
La European Broadcast Union (EBU) est fomentando la operatividad entre audiocodificadores de distintos fabricantes. Con este fin, se ha propuesto el uso y la aplicacin de un subconjunto de Protocolos de Internet. SIP/SAP/RTP y SDP son los protocolos principales, aunque SIP es el comnmente utilizado para referirse a la norma completa. Esta cooperacin permitir a los usuarios configurar comunicaciones de streaming de audio entre equipos de diferentes fabricantes. Prodys se ha comprometido a trabajar junto con el grupo EBU NACIP en la definicin e implementacin de este nuevo estndar para audio sobre IP. Desde el principio, Prodys se ha mantenido a la vanguardia en el desarrollo de esta norma, garantizando que todos los protocolos declarados como obligatorios en el estndar sean implementados. La primera versin de este estndar se public en 2007 como EBU Tech 3326 standard.
Page 11
3.2.-
ALGORITMOS PROPIETARIOS DE PRODYS
Prodys empez a desarrollar sus propios protocolos propietarios para llevar a cabo conexiones de streaming IP, debido a la falta de un estndar: Prodys Real Time Control Protocol (P-RTCP): Este es un protocolo basado en TCP que permite el establecimiento y finalizacin de una conexin as como la negociacin del modo del codec (sincronizacin de audio automtica en todos los modos). Prodys Real Time Protocol (P-RTP): Este es un protocolo basado en UDP utilizado para la transmisin de audio. A pesar de que existe un estndar definido por el grupo EBU a este respecto, en el momento de escribir este documento todava hay algunas caractersticas que no han sido abordadas, pero que estn cubiertas por nuestros algoritmos propietarios, tales como: Compresin de audio asimtrica: Con los Protocolos Propietarios de Prodys, es posible codificar y decodificar en diferentes modos de compresin. Datos auxiliares: SIP no define una forma comn de embeber datos auxiliares junto con los datos de audio, mientras que los Protocolos Propietarios de Prodys soportan datos auxiliares para todos los modos de compresin. Procedimientos de BackUp: el Protocolo de Redundancia de Prodys N+1 permite a un codec IP backup proporcionar redundancia para hasta N codecs IP activos. Con este protocolo si uno de los equipos que llama falla, el equipo BackUp se hace cargo y establece la conexin, copiando la configuracin del equipo averiado.
Page 12
Figura 9. Protocolo de Redundancia N+1 El protocolo de redundancia N+1 funciona sobre IP, y cualquier codec IP de Prodys puede actuar como equipo de BackUp para cualquier otro codec de Prodys. Esto hace posible el control de una unidad con otra diferente (hardware independiente), las cuales no tienen que estar en el mismo lugar necesariamente, siempre que las correspondientes seales de audio estn disponibles en ambos lugares. Adems de esto, la conexin por RDSI puede ser utilizada como BackUp de los interfaces IP y X21 en caso de fallo. Ninguno de estos procedimientos, ni el BackUp por RDSI, ni la redundancia N+1, estn cubiertos por la norma NACIP. Overhead: nuestros protocolos propietarios aaden menos overhead a la conexin de audio. Protocolo de Control: con los Protocolos Propietarios de Prodys, es posible habilitar/deshabilitar el Protocolo de Control de la conexin. Esta parte es responsable del establecimiento, negociacin, monitorizacin y finalizacin de la conexin de audio. Este Protocolo de Control es similar al protocolo SIP en este sentido. Con este tipo de control, es posible establecer la conexin desde cualquier extremo sin ninguna intervencin del extremo remoto. Adems, es posible saber si la conexin est activa y lista en cada momento sin tener que monitorizar el codec en el sitio remoto, dado
Page 13
que este protocolo chequea continuamente si el equipo remoto est bien. Por otro lado, hay algunas aplicaciones en las que, por defecto, la conexin IP es unidireccional y, en este caso, un protocolo de control de este tipo sera un fracaso, dado que se necesita un enlace bidireccional para funcionar. Para estos casos, es posible deshabilitar el Protocolo de Control para las conexiones de audio. El inconveniente de esto es que no habr ningn control del estado del extremo remoto, y la llamada tendr que ser establecida desde ambos extremos. Mecanismos de NAT Traversal: el Protocolo Propietario v3 de Prodys, introduce tcnicas de NAT Traversal para permitir la conexin automtica a travs de los routers independientemente de su configuracin. Para ayudar el usuario a entender esta caracterstica, explicaremos este concepto en el siguiente apartado. 3.2.1.- Network Address Translation (NAT) Cualquier dispositivo IP conectado a Internet necesita una nica direccin IP. El rango disponible de direcciones IP para el estndar IPv4 es limitado y no es lo bastante grande para cubrir todos los dispositivos IP en todo el mundo. Para hacer frente a esta limitacin, NAT habilita mltiples hosts en una red privada para acceder a Internet usando una nica direccin IP pblica. Por tanto, se definen dos rangos diferentes de direcciones IP: interna o privada y externa o pblica. Una vez que un host interno ha iniciado una conexin a un dispositivo IP externo a travs del NAT habilitado (router), se habilita el camino inverso en el router, pero cualquier otro trfico entrante no solicitado es rechazado (firewall). Dependiendo del tipo de NAT, este camino inverso ser habilitado para cualquier aplicacin o host externo, o slo al host y aplicacin a la que se accede desde el host interno. Este ltimo tipo se llama NAT Simtrico, uno de los ms comunes en los routers de marcas conocidas.
Page 14
10.10.10.10 :5060
80.80.80.80 :7000
empfangen
Figura 10. Trfico de entrada no solicitado bloqueado (firewall) por el NAT Algunas herramientas para tratar con NAT se basan en la suposicin de que este router NAT no ser del tipo NAT Simtrico, ofreciendo un Server externo que ayuda al codec interno a conectar con el codec externo abriendo un camino entre los routers a ambos extremos de la conexin. STUN es un protocolo para alcanzar esta solucin de una forma ms estndar.
10.10.10.10 :5060 80.80.80.80 :7005
80.80.80.80 :7000
Figura 11. Trfico entrante no solicitado es permitido por el router NAT (NAT no simtrico) por el camino inverso abierto con la ayuda del STUN server Sin embargo, ninguna de estas herramientas funciona bien cuando el NAT en cada extremo es del tipo NAT simtrico. Para solventar este problema, Prodys desarroll sus Protocolos IP Propietarios v3 y v4, que permiten el flujo de datos bidireccional a
Page 15
travs de cualquier tipo de router NAT en el extremo que llama1, sea ste de tipo simtrico o no, sin necesidad de configurar el router. 4.- MECANISMO DE AJUSTE PLL DE PRODYS Debido a la falta de un reloj para proporcionar un mecanismo de sincronizacin comn en las redes IP, se debe implementar en el codec IP un mecanismo de compensacin. De lo contrario, el jitter (frecuencias de reloj ligeramente diferentes) inherente a los relojes de los conversores de audio AD/DA de ambos extremos de la conexin, dara lugar a incrementos de retardo e interrupciones de audio. El algoritmo de control de PLL de Prodys controla la velocidad de reloj del conversor Digital/Analgico mediante un ajuste del PLL (reloj) del receptor, de modo que cuando el buffer de recepcin tiene baja ocupacin, este algoritmo ralentiza el PLL, as se reduce el ritmo de consumo del buffer y ste puede recobrar su estado original. Al contrario, acelerar la velocidad del reloj (PLL) del conversor DA en caso de desbordamiento del buffer. Este mecanismo asegura la fiabilidad y continuidad del flujo de audio incluso cuando el medio de transmisin carece de un reloj de sincronizacin comn, como es el caso de todas las redes IP. La barra de Streaming de la pgina web de control de nuestros audiocodecs IP informa al usuario en tiempo real sobre la operacin del algoritmo de ajuste PLL. Por lo tanto, cuando esta barra va hacia la izquierda, significa que ha disminuido la ocupacin del buffer y el mecanismo PLL ha reducido la velocidad del reloj de DA, y viceversa.
Figura 12. Barra de Streaming

Es necesario configurar el NAT o direccionar los puertos en el router del extremo al que se llama, pero este extremo es usualmente el estudio o emisora, donde el router debera ser accesible.
1
Page 16
5.- JITTER El jitter es la diferencia entre el tiempo de llegada ms rpido para un paquete y el ms lento. El efecto del jitter en la comunicacin de audio es un buffer vaco en el extremo decodificador. Esta falta de datos causar una interrupcin en el audio. Con el fin de compensar esto, el equipo debe proporcionar al usuario la posibilidad de ajustar un buffer de jitter (Rx buffer). Este buffer de jitter suaviza las diferencias en los tiempos de llegada de los paquetes de audio, dando como resultado un flujo de salida constante para alimentar al decodificador de audio. Cuanto ms grande sea el buffer, ms probable es que el decodificador reciba correctamente los datos. Sin embargo, cuanto ms grande sea el buffer, ms grande ser el retardo. Los codecs IP de Prodys ofrecen al usuario la posibilidad de ajustar el buffer de jitter hasta 10 segundos.
Figura 13. Ventana de configuracin del Jitter (buffer RX)

Page 17
6.- TAMAO DE LOS PAQUETES DE AUDIO Como se ha mencionado anteriormente, los enlaces IP necesitan una informacin extra (overhead) que se aade a los datos de audio reales, requiriendo ms ancho de banda. Por lo tanto, como la informacin de cabecera es de tamao constante, cuanto menor sea el tamao del paquete de audio mayor ser el porcentaje de overhead aadido, pero ms pequeo ser el retardo, y viceversa. Por lo tanto, para que el usuario pueda ajustarse mejor al ancho de banda de su red y al delay requerido, los codecs IP de Prodys permiten al usuario configurar, para todos los modos de compresin de bajo retardo, desde un tamao de paquete muy pequeo de 2msg hasta un tamao de paquete grande de 20msg. Adems, una informacin actualizada dinmicamente muestra al usuario el delay y overhead real si el usuario cambia el tamao del paquete en la web de control.
Figura 14. Configuracin del tiempo entre paquetes (Time Between Packets o TBP)
Page 18
7.- PAQUETES PERDIDOS La probabilidad de que se pierdan los paquetes depender de varios factores, siendo los principales la calidad de la red, el ancho de banda disponible y el tamao de paquete utilizado para el streaming de audio. Dependiendo de las circunstancias, las tcnicas FEC no pueden compensar totalmente la prdida de datos y el resultado ser un corte de audio. Esta interrupcin de audio ser ms fuerte o ms suave dependiendo del tipo de audio, el tamao de muestra y el tipo de algoritmo de codificacin. Para hacer esta interrupcin de audio menos audible, se deben aplicar tcnicas de correccin de errores.
7.1.FEC (FORWARD ERROR CORRECTION)
En caso de prdida de paquetes, habr una falta de audio que ser ms fuerte o ms suave dependiendo del tipo de audio, el tamao de muestra y el tipo de algoritmo de codificacin. Los mecanismos Forward Error Correction deben ser capaces de compensar una pequea cantidad de paquetes perdidos. Los mecanismos FEC envan paquetes especiales de paridad que permiten reconstruir la informacin en base a informacin redundante en caso de prdida de paquetes. Sin embargo estas tcnicas aadirn ms retardo y ms ancho de banda a la conexin de audio. Los audiocodecs IP de Prodys permiten al usuario ajustar diferentes esquemas para el FEC. 1. Un paquete FEC por cada paquete de audio (100% overhead). 2. Un paquete FEC por cada 2 paquetes de audio (50% overhead). 3. Un paquete FEC por cada 3 paquetes de audio (33.3% overhead). . 24. Un paquete FEC por cada 24 paquetes de audio (4.16 % overhead). El segundo incrementar el overhead en un 50%, pero ser capaz de reconstruir paquetes perdidos aislados, mientras que un 100% de FEC
Page 19
doblar los requerimientos de ancho de banda, pero ser capaz de reconstruir hasta dos paquetes de audio perdidos consecutivos. Tambin es posible seleccionar esquemas de overhead ms bajos, reduciendo el overhead a 1 paquete FEC por cada 24 paquetes de audio. Esto significa que el buffer interno necesita retener al menos 24 paquetes de audio, por tanto incrementar el retardo. Por lo tanto: cuanto ms grande sea la ventana de paquetes de audio por cada paquete FEC, ms grande ser el retardo, pero ms pequeo el overhead. Del mismo modo, cuanto ms grande sea la ventana de paquetes de audio, menos robusto es el algoritmo, ya que puede reconstruir menos paquetes perdidos (en el esquema ms simple, 1 paquete FEC por cada 24 paquetes de audio, un mximo de un paquete perdido de un grupo de 24 paquetes de audio podr ser reconstruido).
Page 20
El flujo FEC se enva por un puerto diferente al audio, de forma que se mantenga la compatibilidad con los codecs que no soportan esta tecnologa. El mecanismo FEC de Prodys se ha desarrollado segn el estndar RFC 2733, manteniendo nuestro compromiso de interoperatividad.
7.2.ERROR CONCEALMENT
Hay algunas aplicaciones donde los mecanismos FEC no pueden ser utilizados debido a las restricciones de ancho de banda y retardo. Para estos casos, el decodificador de audio puede utilizar un mtodo para minimizar el efecto de la prdida de paquetes.
Figura 17. Error Concealment. Esta figura muestra la relacin entre calidad y complejidad para diferentes tcnicas de error concealment. No hay una nica forma de implementar estas herramientas, ni estndar nico a seguir. Despus de analizar las diferentes tcnicas, Prodys decidi implementar el mejor en trminos de relacin calidad/complejidad: Repeticin con fundido. Estas tcnicas son parte de los estndares de audio MPEG, y la mejor manera eficaz para corregir errores en la reproduccin de audio provocados por prdidas de informacin.
Page 21
8.- PAQUETES DESORDENADOS Dado que el flujo de datos se divide en paquetes, y cada paquete puede ser enrutado por un camino diferente del resto, el camino desde el transmisor al receptor puede variar dependiendo de varios factores diferentes. Esto podra dar lugar a que lleguen paquetes fuera de secuencia. Para tratar esto, los codecs IP de Prodys soportan un reordenamiento de paquetes si se configura un buffer de recepcin (Rx jitter) para la conexin de audio. Esta funcin es compatible en los protocolos Propietario v4 y en SIP/RTP.
Figura 18. Reordenamiento de paquetes.

Page 22
9.- ACTIVE RECOVERY La herramienta de Active Recovery est basada en tcnicas de Retransmisin. A diferencia del FEC (recuperacin pasiva), no se aade informacin redundante en el flujo original para ayudar al receptor a reconstruir el flujo de datos en caso de prdida de paquetes.
Figura 19. Diagrama de Active Recovery para una red con jitter cero
Page 23
La herramienta de Active Recovery slo enva informacin adicional cuando es realmente necesario, por lo tanto mantiene el overhead adicional al mnimo. Como puede verse en la figura 19, el paquete de audio C es el nico paquete perdido, por lo que sta es la nica informacin redundante que se enva desde el transmisor. El inconveniente de esta tcnica es una mayor latencia extremo a extremo, debida al retardo de ida y vuelta del enlace IP. Como puede verse en la figura 19, el decodificador debe esperar un periodo de tiempo inicial (buffering) antes de empezar a leer datos, para hacer frente al retardo adicional causado por el retraso de ida y vuelta de un paquete retransmitido en caso de prdida. De lo contrario, cuando se pierde el paquete de audio C en la figura 19 habra una interrupcin de audio. Si este retardo adicional causado por la retransmisin fuese interpretado como jitter en la conexin, la herramienta active recovery sera el buffer de jitter. Tener en cuenta que el jitter es un concepto diferente, sin nada que ver con las tcnicas de active recovery y retransmisin, y que el buffer de jitter tendra que ser aadido al buffer de active recovery en caso de jitter en el enlace. Este mtodo puede ser muy adecuado para comunicaciones de audio unidireccionales donde la latencia no es un problema.
Page 24
10.- HERRAMIENTAS DE MEDIDA DE PRODYS Una de las caractersticas ms innovadoras en la familia de codecs IP de Prodys comparada con otros fabricantes son las herramientas de monitorizacin para la red y el streaming de audio. La ltima de estas herramientas se llama Real time Network Analyzer la cual funciona simultneamente con la conexin de audio. Esta herramienta ofrece informacin sobre el rendimiento del streaming de audio en tiempo real, y almacena informacin durante 24 horas, o hasta 7 das si la web de control permanece abierta durante ese tiempo. Toda la informacin disponible puede ser exportada a un archivo, y es organizada por llamada, de modo que es posible recuperar los datos de una llamada especfica en un momento dado. Esta herramienta proporciona al usuario la siguiente informacin: 1. Ocupacin del Rx Buffer (buffer de recepcin) 2. Jitter 3. Paquetes perdidos y paquetes desordenados Esta informacin muestra la calidad del streaming de audio sobre la red IP, as como ayuda al usuario a ajustar la configuracin del streaming de audio para adaptarse a las propiedades de la red. El fondo de la grfica se iluminar en rojo en los periodos de tiempo en los que el decodificador no sea capaz de reconstruir la salida de audio debido a problemas de funcionamiento en la red, correspondindose con los mensajes de alarma Frame lost y Decoder not framed.
Figura 20. Ocupacin del buffer de recepcin con notificaciones de alarma del decodificador
Page 25
Adems, funciona como parte de la pgina web de control, por lo que no es necesario instalar ningn software adicional.
Figura 21. Analizador en Tiempo Real de Prodys En caso de que el usuario desee comprobar el ancho de banda disponible, el retardo y/o el jitter antes de establecer la conexin, Prodys ofrece a sus clientes otra herramienta, la cual trabaja off-line, y que permite al usuario medir el ancho de banda de subida y bajada en el enlace IP entre dos equipos Prodys, as como el retardo de ida y vuelta. Tambin es posible simular una conexin de audio real en trminos de ancho de banda y tasa de paquetes para comprobar si el enlace IP soporta los requerimientos necesarios de ancho de banda de audio. Si esta opcin NO est seleccionada, esta herramienta intentar utilizar la mayor cantidad de ancho de banda posible, midiendo el ancho de banda total disponible para ese enlace.
Page 26
Advertencia: esta herramienta coger TODO el ancho de banda disponible, as que debera ser utilizada con cuidado en una red en servicio.
Figura 22. Herramienta de Test Streaming
Page 27
11.- HERRAMIENTAS DE SISTEMA DE ALARMAS
MONITORIZACIN:
SNMP
Los equipos IP de Prodys soportan protocolo SNMP para control/notificacin de variables de configuracin y alarmas. Adems, el sistema de alarmas permite al usuario seleccionar que tipo de eventos el equipo chequear y notificar. Estas notificaciones sobre determinados tipos de eventos y/o alarmas se podrn realizar va traps de SNMP y/o emails.
Figura 23. Ventana de alarmas. Las alarmas son salvadas en la memoria no voltil del codec, as es posible acceder a la informacin de la alarma incluso si la unidad ha sido reiniciada.
Figura 24. Ventana del histrico de alarmas.

Page 28
12.- DOBLE INTERFAZ LAN En algunas instalaciones de red IP es deseable separar la red de audio de la red de gestin o control. Esto puede ser para prevenir que otros equipos IP, tales como ordenadores, pongan trfico extra en la red de audio, o para prevenir el acceso de ordenadores y equipos externos a la LAN corporativa. En caso de que esta separacin no se pueda conseguir mediante un dispositivo IP externo (router) por ejemplo, Prodys ya ofrece la opcin de incluir un segundo interfaz Ethernet/IP en sus equipos. Este segundo interfaz Ethernet/IP tiene su propia direccin IP, actuando como un interfaz totalmente independiente para propsitos de control/gestin. El interfaz Ethernet principal acta slo como un interfaz de audio en caso de que el segundo interfaz est habilitado en el equipo y no aceptar ninguna conexin entrante de gestin para aislar la red de audio de la de control.
Page 29
13.- VLAN Los estndares 802.1Q/p para el marcado VLAN estn soportados a partir de la versin de firmware 6.0.9 en adelante. El estndar 802.1Q o VLAN (Virtual LAN) se refiere a un grupo de dispositivos de red en una o ms redes LAN que estn configurados de forma que se pueden comunicar entre ellos como si estuvieran conectados a una misma red fsica, cuando en realidad estn conectados a diferentes redes. Dado que las redes VLAN estn basadas en conexiones lgicas y no fsicas, son muy flexibles y permiten cambiar la topologa de red, controlar la asignacin y optimizacin de recursos de una manera muy eficiente. El estndar IEEE 802.1p es una extensin del estdar 802.1Q (marcado VLAN) y ambos funcionan en conjunto. El estndar 802.1Q especifica como marcar los paquetes de la trama Ethernet y los campos a aadir a esta para el marcado VLAN. Este marcado se basa fundamentalmente en dos campos: VLAN ID (12 bits) y Prioritization (3 bits). El campo Prioritization no est definido en el estndar 802.1Q, por lo que es el estndar 802.1p el que define los posibles valores a utilizar para estos bits. A partir de la version 6.0.9 de firmware, el usuario puede marcar los paquetes de control y de datos como tramas pertenecientes a VLANs diferentes, de forma que cualquier dispositivo de red compatible con la norma 802.1Q (VLAN) puede llevar a cabo topologas de red VLAN y aplicar QoS (calidad de serivicio). La confiracin VLAN es muy sencilla. El usurio slo tiene que introducir dos valores (ID y Priority) para configurar dos VLANs preestablecidas por defecto, una para datos de control y otra para datos de audio. Estos campos sern utilizados para marcar los paquetes de las tramas Ethernet tanto de control como de audio. Adems, el usuario ha de introducir las direcciones IP de las VLAN de audio y de control respectivamente. VLAN es una opcin que est disponible como licencia bajo perdido. Si est interesado en conseguir una licencia, por favor pngase en contacto con el departamento de ventas en sales@prodys.net.
Page 30

Prodys Audio Over IP Tools Castellano

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Prodys Audio Over IP Tools Castellano

Hochgeladen von

Copyright:

Verfügbare Formate

White paper Julio 09 Rev 06

Figura 2: Diferentes caminos y paquetes desordenados

Figura 5: Informacin pgina Web

Figura 6: conexin Unicast

ALGORITMOS PROPIETARIOS DE PRODYS

Figura 12. Barra de Streaming

Figura 13. Ventana de configuracin del Jitter (buffer RX)

Figura 18. Reordenamiento de paquetes.

Figura 22. Herramienta de Test Streaming

11.- HERRAMIENTAS DE SISTEMA DE ALARMAS

Figura 24. Ventana del histrico de alarmas.

Das könnte Ihnen auch gefallen