Dante vs AES67: planifica una red de audio interoperable

TL;DR — Dante es una plataforma comercial completa de audio en red; AES67 es un estándar de interoperabilidad para flujos de audio sobre IP compatibles. Los dispositivos Dante compatibles pueden intercambiar audio multicast RTP AES67 con endpoints AES67 no Dante, pero activar el modo es solo el comienzo. Los endpoints siguen necesitando formatos de audio compatibles, direccionamiento multicast, reloj PTPv2, política de red y suscripciones probadas. Mantén Dante nativo para las rutas Dante a Dante salvo que el diseño requiera específicamente un límite AES67.

Dante y AES67 resuelven problemas de distinto alcance

Dante y AES67 se comparan a menudo como si fueran dos productos intercambiables. No lo son.

Dante proporciona descubrimiento de dispositivos, enrutamiento, reloj, monitorización, configuración y transporte de medios en un ecosistema compatible. AES67 define una forma común para que los sistemas profesionales de audio sobre IP intercambien flujos de audio sin comprimir. No estandariza todas las funciones de control, descubrimiento, seguridad o gestión alrededor de esos flujos.

Por tanto, la pregunta práctica no es “¿cuál gana?” sino “¿dónde necesita el sistema un límite de audio basado en estándares y quién controla cada ajuste de ese límite?”.

Usa Dante nativo dentro de un sistema Dante

Cuando ambos endpoints son dispositivos Dante, normalmente se comunican mediante transporte Dante nativo aunque el modo AES67 esté activado. Activar AES67 no convierte todas las rutas en AES67 ni mejora una suscripción Dante a Dante ordinaria.

Usa la ruta nativa cuando ya satisfaga el requisito de producción. Conserva el comportamiento esperado de nombres, enrutamiento, monitorización y recuperación de Dante. Añade AES67 cuando un endpoint no Dante compatible deba enviar o recibir audio a través de una interfaz diseñada de forma intencionada, como un límite de broadcast, AV instalado, consola, DSP o grabación.

Esta distinción evita un error común: cambiar una red nativa estable solo porque todos los dispositivos ofrecen una opción de interoperabilidad.

Confirma que cada endpoint admite el modo requerido

La compatibilidad con AES67 es una capacidad del dispositivo, no una garantía asociada a cada puerto de red. Antes de avanzar el show, inventaría:

• producto e interfaz exactos;
• firmware instalado y versión de software Dante;
• modo RTP o AES67 compatible;
• sample rate, número de canales y formato de paquete compatibles;
• restricciones de dirección multicast;
• opciones de reloj PTPv2 y comportamiento del dominio;
• si cambiar de modo requiere reinicio;
• cómo el endpoint no Dante anuncia o acepta el flujo.

En las versiones actuales de Dante Controller, los dispositivos compatibles exponen controles de configuración RTP o AES67. Los productos antiguos pueden tener límites más estrechos de dirección, flujo o reloj. Usa la documentación del firmware desplegado en lugar de asumir que un único dispositivo que funciona representa a toda la flota.

Trata la ruta AES67 como un flujo multicast definido

La interoperabilidad AES67 usa flujos multicast RTP. Un transmisor crea un stream con un formato de audio, una dirección multicast de destino, un puerto UDP y un comportamiento de temporización. El receptor debe admitir esos valores y unirse al mismo stream.

Define el flujo antes de crear suscripciones:

Algunas implementaciones Dante solo reciben flujos AES67 dentro de determinados rangos multicast. Una suscripción también puede parecer aceptada aunque no pase audio si el prefijo RTP configurado en el receptor no coincide con el flujo transmitido. Registra los requisitos reales desplegados en lugar de copiar un ejemplo genérico de dirección.

Para la decisión más amplia sobre fanout, consulta Dante unicast versus multicast.

Diseña el reloj PTPv2 como un flujo de trabajo independiente

AES67 depende de la temporización PTPv2. Las redes Dante nativas tienen su propio comportamiento de elección de reloj, así que un diseño interoperable debe establecer de forma explícita cómo llegan los dispositivos relevantes a una referencia PTPv2 compatible.

Verifica:

1. qué dispositivo o reloj es apto para liderar el dominio de temporización AES67;
2. la versión PTP y el número de dominio usados por cada endpoint participante;
3. si los dispositivos Dante usan configuración de reloj AES67 automática o manual;
4. si algún dispositivo hace de puente para el comportamiento de temporización requerido entre la parte nativa y la parte AES67;
5. DSCP y tratamiento en switches para mensajes PTP event y general;
6. el efecto de perder el líder, un uplink o un endpoint.

No asumas que los dispositivos visibles comparten un reloj utilizable. Descubrimiento, control y temporización de medios son comprobaciones separadas. La guía de líder de reloj Dante explica la elección nativa de Dante; el límite AES67 sigue necesitando su propia verificación PTPv2.

Mantén el multicast dentro de un alcance de red intencional

Un flujo AES67 no es una razón para inundar todos los puertos. Mapea la VLAN y la ruta de switches y luego configura los controles multicast para ese diseño.

Una red gestionada puede usar IGMP snooping para enviar el stream solo a los puertos con receptores interesados, con un querier correctamente situado manteniendo la membresía. La política exacta corresponde al propietario de la red. Confirma que PTPv2, el descubrimiento cuando sea necesario y el multicast RTP llegan a los endpoints previstos sin filtrarse a redes de producción no relacionadas.

Comprueba también la capacidad de enlace en ambas direcciones. El multicast reduce el fanout del transmisor, pero cada flujo sigue consumiendo ancho de banda en cada enlace que lo transporta. La guía de requisitos de switches de red Dante cubre velocidad de enlace, QoS, EEE, contadores y pruebas de aceptación.

Prueba la interoperabilidad desde el silencio hasta la recuperación

1. Guarda la línea base nativa conocida

Exporta la configuración actual de Dante y registra reloj, rutas, sample rates, nombres, direcciones y estado del switch. Protege las salidas que ya funcionan antes de activar un nuevo modo RTP.

2. Configura un límite cada vez

Activa el modo requerido solo en endpoints compatibles. Aplica el formato acordado, el prefijo multicast, la latencia y los ajustes PTPv2. Deja terminar cualquier reinicio necesario antes de juzgar el resultado.

3. Crea un flujo de prueba identificable

Empieza con un pequeño conjunto de canales y una fuente de prueba inequívoca. Registra su orden de canales, dirección multicast, puerto y transmisor. Evita crear varios flujos anónimos a la vez.

4. Suscríbete e inspecciona cada capa

Confirma que el receptor se une al flujo previsto, bloquea el reloj correcto, no reporta errores y produce el audio correcto en la salida esperada. Una indicación de enrutamiento por sí sola no prueba que el medio sea audible e identificado correctamente.

5. Aplica carga realista

Ejecuta a la vez las rutas Dante nativas planificadas, los flujos AES67 y el tráfico compartido representativo. Vigila el estado del reloj, la latencia, los errores de paquete, la utilización de enlace, las colas y los destinos reales.

6. Somete a prueba el fallo y la reversión

Retira y restaura la fuente, el receptor, el líder de reloj y el enlace de red relevante, uno por uno. Mide el comportamiento de mute y recuperación. Finalmente, demuestra que la línea base documentada puede restaurarse sin inventar ajustes.

Documenta el límite de interoperabilidad

El Rider debe incluir:

• el motivo operativo para usar AES67;
• endpoints Dante nativos y AES67 por dispositivo, puerto y canal;
• firmware y responsable de compatibilidad;
• formato de audio y orden de canales;
• dirección multicast RTP, puerto y rango permitido;
• líder PTPv2, dominio, prioridades y fallback;
• VLAN, switches, owner de IGMP, QoS y capacidad de enlace;
• latencia del receptor y evidencia de aceptación;
• procedimientos de reinicio, fallo, repuestos y rollback;
• el técnico autorizado para cambiar cada lado.

No incluyas contraseñas ni credenciales de red sensibles en un rider público. Compártelas mediante el canal seguro aprobado del venue.

La guía de rider técnico para redes de audio digital muestra cómo situar este límite junto al resto de la entrega del show.

Lista de comprobación de Dante y AES67

• AES67 es necesario por un límite de interoperabilidad no Dante identificado.
• Cada endpoint y versión de firmware admite el modo seleccionado.
• Sample rate, codificación, orden de canales, dirección multicast y puerto coinciden.
• La fuente PTPv2, el dominio, la prioridad y el fallback están verificados.
• El alcance multicast, el querier, QoS, EEE y la capacidad de enlace están aprobados.
• La ruta pasa pruebas de audio correcto, carga completa, fallo y recuperación.
• Las rutas Dante nativas siguen documentadas y recuperables.
• El responsable y el procedimiento de rollback figuran en el Rider.

Errores comunes

Tratar AES67 como un sistema de control completo. Estandariza una ruta de medios interoperable, no todo el comportamiento de descubrimiento, enrutamiento, seguridad o monitorización.

Activar AES67 en todos los dispositivos Dante. Actívalo y configúralo solo donde un límite no Dante aprobado lo requiera.

Comprobar la ruta pero no el reloj. Un receptor puede descubrir un stream y aun así no producir audio estable sin una temporización PTPv2 compatible.

Copiar valores multicast sin criterio. Los rangos de dirección, prefijos, puertos y compatibilidad de dispositivos deben coincidir con los endpoints y el plan de red reales.

Probar un solo stream en un switch sin carga. La aceptación debe incluir las rutas nativas, la carga AES67 prevista, el tráfico compartido, los fallos y la recuperación.

FAQ

¿Cuál es la diferencia entre Dante y AES67?

Dante es una plataforma completa de medios en red con enrutamiento, descubrimiento, reloj, monitorización y configuración de dispositivos. AES67 es un estándar que permite que sistemas compatibles de audio sobre IP intercambien flujos de audio RTP.

¿Dante es compatible con AES67?

Los dispositivos Dante compatibles pueden enviar y recibir audio AES67 hacia y desde dispositivos AES67 no Dante compatibles. La compatibilidad depende del dispositivo, firmware, formato de audio, ajustes multicast y configuración PTPv2.

¿AES67 usa multicast?

La interoperabilidad AES67 suele usar flujos multicast RTP. El transmisor, el receptor, los switches, la VLAN, la dirección multicast, el puerto y la política IGMP deben encajar en el mismo plan.

¿AES67 requiere PTPv2?

Sí. AES67 usa PTPv2 para la sincronización del reloj de medios. Los endpoints participantes deben compartir una configuración PTPv2 compatible y una ruta de temporización compatible.

¿Cómo se prueba la interoperabilidad entre Dante y AES67?

Verifica capacidades y formatos, configura PTPv2, crea un flujo multicast RTP conocido, confirma el audio correcto en el destino y después prueba carga completa, pérdida de reloj y enlaces, retorno de endpoints y rollback.

Mantén recuperable el límite de estándares

Guarda el mapa aprobado de endpoints, el flujo RTP, el plan de reloj, el alcance de red, la evidencia de pruebas y el rollback junto con el resto de la documentación del show. En Techrider.live, guárdalo en el mismo Rider que el plano de escenario y la lista de canales, invita al ingeniero responsable a editarlo y luego guarda e inspecciona el historial antes de compartir la versión actual.