HomeDivulgaciónAoIP II: aplicaciones prácticas

AoIP II: aplicaciones prácticas

Audio over IP

En la primera entrega de AoIP hablamos de las ventajas del uso de esta tecnología en nuestros entornos de producción y de sus principales diferencias frente al audio tradicional, ya fuera analógico o digital. Sin embargo, poner en práctica un sistema completo de AoIP presenta nuevos retos que hay que afrontar y que los diferentes fabricantes han ido solucionando. En esta ocasión, veremos las aplicaciones prácticas necesarias para poner en marcha este tipo de sistemas: la detección automática, la administración, el control y la seguridad.

 

El concepto de plug-and-play es algo ya asumido por todos, ya sean tanto profesionales como consumidores en cualquier entorno IT. El wifi simplemente funciona, el USB sencillamente se conecta y mis auriculares directamente se oyen al conectarlos a mi teléfono. Pero llegar a este nivel de madurez no ocurre de la noche a la mañana. Aún recuerdo cuando para conectar cualquier nuevo dispositivo al ordenador había que preparar los drivers, instalarlos, en su versión correcta claro dependiendo del sistema operativo, el modelo del dispositivo, etc.…, conectar el dispositivo en la secuencia correcta, seguir un protocolo y configurarlo todo manualmente y más… Y de esto no hace tanto, tan solo 10-15 años.

Y ¿qué ha hecho posible que en el mundo IT esto cambiase? Pues los estándares abiertos. Todos los sistemas operativos, dispositivos y protocolos hablan el mismo idioma, al menos parcialmente, lo que permite que se comporten de esta manera automática tan deseable y que nos facilita tanto la vida. Bueno, pues en el AoIP ha ocurrido algo parecido.

Tres décadas de historia

Sí, hace 30 años que el AoIP se comenzó a utilizar en los entornos de producción multimedia en general. Y al principio todo era tan tedioso como en el mundo IT. Todo había que configurarlo a mano, nada se entendía con nada y los fabricantes parecía que estaban peleados como hermanos por la herencia del progenitor y no había manera de que se entendieran.

Por ejemplo, un micrófono IP conectado a una red necesitaba disponer de una dirección IP y hacer uso de direcciones IP de broadcast conocidas por el resto de los dispositivos que “escucharan” dicho stream que enviaba el micrófono y fueran capaces de “leerlo”, entender su formato, la profundidad de bits, la tasa de muestreo y todo. Pues todo esto había que configurarlo manualmente.
Es fácil imaginar los problemas y la cantidad de errores de configuración que se producían y el tiempo necesario para configurar hasta el más mínimo entorno de producción AoIP. Esto frenó mucho su despliegue, pero era el futuro y los fabricantes y estándares siguieron evolucionando hasta hacer posible lo que tenemos hoy día: AES67.

Logrando el Plug-n-Play

Para lograr que al conectar un nuevo dispositivo a nuestra red de producción de audio sobre IP éste sea descubierto y funcione correctamente hacen falta dos cosas: descubrir el dispositivo y controlarlo.

Cuando hablamos de descubrir el nuevo dispositivo no solo se trata de que el resto de los equipos sepan que está ahí, sino que también sepan en qué formato está configurado y qué tipo de stream de audio está generando, en caso de que sea una fuente. Para ello, antes que nada hay que asignarle una IP. Esto es fácil de solucionar gracias al protocolo DHCP (Dynamic Host Control Protocol), mediante el cual el router es capaz de otorgar una dirección IP dentro del rango de la red a un dispositivo nuevo. Ya lo tenemos en la red.

Yendo un paso más allá, necesitamos decirle al resto de dispositivos la configuración de audio en la que está establecido. Para esto existe AES67. Este protocolo establece un formato específico de RTP (Real-Time Transport Protocol) payload mediante el cual se intercambian las especificaciones de audio. Este payload es entendido por el resto de los dispositivos y se adaptan a ello. Ya tenemos el dispositivo correctamente descubierto y con su formato adecuado.

Pasando a la parte del control, además de la IP del dispositivo debemos conocer la(s) dirección(es) broadcast que utiliza para transmitir el stream. Estas direcciones se usan para que el resto de los dispositivos puedan “escuchar” el stream y solicitar al switch de la red una copia de estos paquetes broadcast. De esta manera se reduce la carga de la red y todos los dispositivos escuchan el mismo stream al mismo tiempo sin duplicarlo. EL problema es la gran cantidad de direcciones broadcast existentes hasta en la red más pequeña, lo que complica enseguida el control de éstas, pero si se hace bien se gestionan automáticamente.

No todo son buenas noticias con Plug-n-Play ya que este complica mucho la interoperabilidad entre dispositivos. Si todos conocen a todos, se asume que todos se tienen que hablar con todos. Se asume también que otros formatos como AES3 o MADI puedan entenderse con dispositivos AES67. Además de sistema automáticos, los softwares de control siempre tienen funcionalidades manuales para poder entenderse entre protocolos.

Aumentando la flexibilidad

Aumentar la flexibilidad y la facilidad para interconectar cualquier tipo de dispositivo tiene un precio: la complejidad. Que todo se entienda con todo hace que tengamos que realizar configuraciones complejas como, por ejemplo, conocer todas las direcciones broadcast de la red. Hasta en la red más pequeña hay centenares de direcciones broadcast y su número crece exponencialmente.

Es por ello por lo que estándares como AES67 no incluyen una especificación concreta para dicha interoperabilidad y subsecuente flexibilidad, dejando a la red y los softwares de gestión dicha función. Hoy en día estos sistemas están suficientemente maduros y funcionan bastante bien para gestionar una red AoIP.

Interoperabilidad aumentada

Al igual que la realidad aumentada, un punto crítico es que todos los dispositivos, sean del fabricante que sean, no solo se entiendan entre sí, sino que los softwares de gestión sean del fabricante que sean, puedan descubrir y controlar todos los dispositivos. El problema es que cada fabricante desarrolla su sistema de control basado en sus productos, evidentemente, y dedican grandes esfuerzos de desarrollo y dinero, pero no pueden realizar grandes desarrollos de interoperabilidad.

Además, supondría problemas de compartir ciertos secretos o código fuente entre fabricantes a lo cual todo el mundo es muy receloso. Al final, en el código fuente es donde está el valor de la propiedad intelectual de los diferentes desarrollos y suponen mucho dinero, como comentábamos.

Es por ello por lo que, si queremos disponer de la flexibilidad del AoIP, como AES67, debemos admitir ciertos compromisos. Por ejemplo, tener una red AoIP basada en AES67 con el sistema de control de un único fabricante nos dará todas las ventajas y flexibilidad, pero dentro de este fabricante.

Bien es cierto que los fabricantes, o reguladores, podrían trabajar en estándares abiertos para que los equipos y sistemas de control fueran compatibles entre sí, pero esto no caerá del cielo mañana. Hay ciertos avances e iniciativas en este aspecto, pero aún queda tiempo para que maduren.

Conclusiones

Al final debemos quedarnos con lo mejor de ambos mundos. Por ejemplo, combinar las especificaciones del estándar ST2110 con AES67 es un buen compromiso. La parte de operaciones está más que resuelta en AoIP, pero quedan retos como la interoperabilidad de los sistemas de control entre equipamientos de distintos fabricantes o simplificar la configuración necesaria de una red IT a la hora de conectar el equipamiento entre sí.

Más que luchar contra las limitaciones actuales es mejor adaptarse a ellas y conocerlas para poder trabajar mucho mejor y aprovecharse de las ventajas que el AoIP, especialmente la flexibilidad que este nos ofrece. Sin duda el comprometer algo en términos de variedad de equipamiento nos va a otorgar unas ventajas que, mediante audio tradicional, ya sea analógico o digital, no podríamos imaginar.

Por Yeray Alfageme

ETIQUETAS:
Abierta la convocato
RTVE apoya la inicia