Dante y AES67

Estándar abierto frente a ecosistema comercial

AES67 se mantiene como un estándar público. Su propósito es definir una superficie común de interoperabilidad que muchos fabricantes puedan implementar sin adoptar el controlador, el modelo de descubrimiento o la familia de productos de una sola empresa. Dante es un ecosistema tecnológico comercial propiedad de Audinate y desarrollado por ella. Ofrece una experiencia de usuario completa que abarca el descubrimiento, el enrutamiento, el reloj, la gestión de dispositivos, las tarjetas de sonido virtuales, el software y el hardware certificado.

Esa diferencia no es un defecto de ninguno de los dos modelos. Un organismo de estándares puede definir una capa común duradera, pero no puede garantizar la experiencia de usuario de cada implementación. Un ecosistema comercial puede entregar herramientas estrechamente integradas y un comportamiento predecible, pero permanece bajo el control de su propietario.

La interoperabilidad Dante AES67 debe verse, por tanto, como un punto de encuentro entre esos modelos. Los dispositivos Dante pueden exponer flujos seleccionados en una forma compatible con AES67, y los dispositivos AES67 pueden recibir o enviar esos flujos. El resto del flujo de trabajo Dante sigue siendo específico de Dante.

Propiedad y contexto de marca

AES67 se desarrolla mediante la actividad de normalización de la AES. Dante y los nombres, logotipos y especificaciones técnicas asociados están controlados por Audinate. Un producto que admite la interoperabilidad Dante AES67 no se convierte por ello en código abierto, ni una implementación AES67 se convierte por definición en un producto Dante.

La precisión con las marcas importa en la escritura técnica. Use Dante solo para describir la tecnología de Audinate y use los nombres oficiales del fabricante al referirse a un dispositivo o modo concreto. Evite dar a entender que AES67 es propietaria de Dante o que Dante es un sinónimo genérico de AoIP.

Dante es una marca registrada de Audinate Pty Ltd. Esta página es una comparación técnica independiente.

La atribución de marca es contexto editorial, no un sustituto de la revisión de los términos vigentes del proveedor.

Descubrimiento, enrutamiento y control

Los dispositivos Dante nativos suelen descubrirse a través del ecosistema de control de Dante y gestionarse con herramientas como Dante Controller o Dante Director, según el producto y el despliegue. El usuario ve nombres de dispositivos, etiquetas de canales, suscripciones, estado del reloj y diagnóstico en una interfaz unificada.

AES67 no define un protocolo universal de descubrimiento o enrutamiento. Cuando Dante opera en un modo de interoperabilidad AES67, el flujo de audio puede ser visible para un sistema externo mediante una descripción de sesión o un mecanismo de descubrimiento compatible, pero eso no significa que todas las funciones de Dante queden disponibles en el controlador externo.

Los integradores deben documentar dos capas: los flujos de audio que cruzan la frontera AES67 y las acciones de gestión que permanecen nativas. Un diagrama híbrido útil muestra Dante Controller a un lado, el dispositivo o controlador AES67 al otro, y los puntos exactos donde se intercambian SDP, direcciones de multidifusión, configuración PTP y mapeo de canales.

Reloj, latencia y redundancia

Dante usa su propio modelo de reloj y ofrece ajustes de latencia configurables para los flujos nativos. El modo AES67 puede imponer un tiempo de paquete o un ajuste de latencia diferente, porque el contrato de interoperabilidad debe coincidir con el dispositivo externo. Un diseño exitoso debe usar la misma tasa de muestreo, el mismo tiempo de paquete y la misma relación de reloj en ambos lados de la conexión.

La latencia no es un número único. Incluye la paquetización, el almacenamiento en búfer del receptor, el procesamiento del dispositivo, el tránsito de red y cualquier conversión entre los modos nativo y de interoperabilidad. La comparación más segura es la latencia de extremo a extremo medida en la topología real, no el ajuste más bajo impreso en una ficha técnica.

Dante proporciona opciones de redundancia dentro de su ecosistema, mientras que AES67 en sí no define un mecanismo universal de protección sin interrupciones. Un despliegue híbrido puede conservar la redundancia nativa dentro del dominio Dante exponiendo un modelo de protección diferente en la frontera AES67. El comportamiento de esa frontera ante fallos debe probarse y documentarse.

La alineación PTP es igualmente importante. Los dispositivos Dante y los dispositivos AES67 pueden necesitar compartir una referencia de reloj o tender un puente entre dominios de temporización de forma controlada. Una planificación PTP deficiente puede producir audio intermitente aunque el enrutamiento y el ancho de banda parezcan correctos.

Gestión y soporte

La gestión nativa de Dante cubre más que la suscripción de audio. Incluye los nombres de dispositivos, las etiquetas de canales, la supervisión del reloj, los flujos de trabajo de firmware, los registros de eventos y el acceso a servicios o software de Audinate. El modo de interoperabilidad AES67 no expone automáticamente esas funciones de gestión a un sistema de terceros.

Un proyecto híbrido debe definir quién es responsable de cada capa. ¿Quién asigna los nombres de dispositivo Dante? ¿Quién gestiona las direcciones de multidifusión AES67? ¿Quién supervisa el PTP? ¿Quién recibe las alarmas si desaparece un flujo? ¿Quién actualiza el firmware en cada lado de la frontera? Una propiedad ambigua es una causa habitual de resolución lenta de incidencias.

Las fronteras de soporte también deben ser explícitas. Un fabricante puede dar soporte al dispositivo Dante, al modo AES67 y a la configuración de red por separado, y rechazar la responsabilidad por un controlador de terceros o un diseño de conmutador no estándar. Una matriz de integración por escrito reduce los reproches mutuos durante la puesta en marcha y la operación.

Certificación y afirmaciones de cumplimiento

Los productos Dante participan en el programa de productos y certificación de Audinate, y el conjunto de funciones disponible puede variar según la clase de dispositivo, el hardware, el firmware y la licencia. El soporte AES67 debe verificarse contra el modelo exacto y la versión de firmware, no inferirse de la marca Dante.

Una revisión de cumplimiento útil plantea cuatro preguntas. ¿Admite el dispositivo la dirección de flujo AES67 requerida? ¿Admite la tasa de muestreo y el tiempo de paquete? ¿Expone el número de canales necesario? ¿Encaja su comportamiento de reloj y redundancia en el diseño del sistema? Una quinta pregunta es si el fabricante documenta las limitaciones del modo de interoperabilidad.

La certificación es evidencia sobre una configuración probada específica, no prueba de que todas las combinaciones se comporten igual. Conserve la versión de firmware, la exportación de configuración, los guiones de prueba y los resultados medidos junto con el expediente del proyecto.

Lo que cambia el modo Dante AES67

En un despliegue Dante AES67 típico, se configuran flujos de transmisión o de recepción seleccionados para usar un transporte y una relación de temporización compatibles con AES67. Esto puede permitir que una red Dante alimente a un procesador que no es Dante, a un dispositivo de radiodifusión, a un sistema de grabación o a otra plataforma AoIP que admita el mismo perfil de interoperabilidad.

La frontera suele ser más estrecha que el flujo de trabajo nativo. Un receptor AES67 no necesariamente conoce el nombre del dispositivo Dante, las etiquetas de canales ni el modelo de suscripción. Puede que solo vea un flujo IP descrito por SDP. A la inversa, el controlador de Dante puede no ser capaz de gestionar todas las propiedades del receptor externo.

Algunas funciones también pueden cambiar cuando un dispositivo sale del modo Dante nativo. Los números de canales pueden ser menores, los ajustes de latencia pueden quedar limitados, las tasas de muestreo pueden estar restringidas y el comportamiento de redundancia puede diferir. Esas limitaciones son específicas de la implementación y deben confirmarse en la documentación vigente del producto.

Limitaciones que conviene planificar

La mayor limitación no siempre es el ancho de banda, sino la visibilidad operativa. Un operador de Dante puede ver una red nativa sana mientras una interconexión AES67 ha fallado, o un controlador AES67 puede mostrar un flujo sin saber que su fuente Dante ha entrado en un estado nativo degradado. La supervisión entre dominios es esencial.

El diseño de multidifusión es otro riesgo común. Dante, AES67 y la red circundante pueden tener convenciones distintas de asignación de direcciones, comportamiento IGMP y densidad de flujos. Un plan limpio de multidifusión debe reservar rangos, limitar la pertenencia a grupos y verificar el comportamiento del querier en cada VLAN.

Por último, una conexión Dante AES67 no es un conversor universal para todo formato o función de control. No convierte en audio las señales que no lo son, no sustituye a un conversor de tasa de muestreo ni garantiza que un dispositivo de terceros pueda controlar un producto Dante. Esas funciones requieren productos separados o integración de gestión.

Despliegues Dante puros e híbridos

Un despliegue Dante puro suele ser la opción más sencilla cuando todos los puntos finales críticos provienen del ecosistema Dante y el proyecto valora un solo controlador, un solo modelo de soporte y funciones nativas predecibles. Añadir AES67 a un sistema Dante limpio puede introducir una sobrecarga de reloj, multidifusión y pruebas que el proyecto no necesita.

Un despliegue híbrido tiene sentido cuando una instalación debe conectar un parque Dante con un sistema RAVENNA, un núcleo de producción ST 2110-30, un procesador de terceros o una plataforma de grabación o supervisión basada en estándares. También tiene sentido durante una migración, cuando un sitio quiere introducir un nuevo subsistema sin sustituir la red Dante existente.

La pregunta práctica de diseño no es puro frente a híbrido en abstracto, sino qué flujos necesitan cruzar la frontera y qué garantía requiere cada flujo. Un número reducido de flujos de monitorización de bajo riesgo puede tolerar un puente simple. Una ruta de emisión en vivo puede exigir redes redundantes, temporización determinista, supervisión y un procedimiento de fallo probado.

Lista de verificación y errores comunes

Comience la lista de verificación con los requisitos del flujo: dirección, tasa de muestreo, tiempo de paquete, número de canales, multidifusión o unidifusión y comportamiento de recuperación esperado. Después verifique el modelo Dante, el firmware, la licencia, el modo de interoperabilidad, la configuración PTP, el soporte de redundancia y la visibilidad de gestión. Pruebe la pareja exacta de dispositivos, no solo la categoría de marketing.

Un error común es pensar que el soporte AES67 vuelve genérico a un dispositivo Dante. En la práctica, el comportamiento nativo de Dante sigue siendo el centro de la experiencia del producto. Otro error es suponer que el modo AES67 siempre es gratuito o siempre idéntico entre modelos. Las licencias, el hardware, el firmware y la clase de producto pueden afectar a la disponibilidad.

Un tercer error es considerar la interoperabilidad un mero detalle de ingeniería. Cambia la adquisición, la operación, el soporte y la formación. El mejor diseño híbrido da a cada ecosistema un papel claro y crea una frontera estrecha y documentada con criterios de aceptación medibles.

• Confirme el modelo Dante exacto y la versión de firmware.
• Verifique la dirección AES67, el número de canales y el formato de paquete.
• Documente la frontera PTP y de reloj.
• Decida cómo funcionarán la multidifusión, la redundancia y la supervisión.
• Pruebe la recuperación antes de poner el sistema en marcha.