¿Qué es AES67 – y por qué importa?

Audio-over-IP (AoIP) ha transformado flujos de trabajo de audio profesionales, pero durante años el ecosistema fue fragmentado. Cada fabricante —Dante, RAVENNA, Livewire, Q-LAN— utiliza protocolos patentados que no podían hablar entre sí. En 2013 la Audio Engineering Society publicó AES67, un estándar de interoperabilidad abierta que define un conjunto común de protocolos de red para que dispositivos de diferentes proveedores coexistan

AES67 es ahora ampliamente adoptado en la radiodifusión, sonido en vivo, estudios de grabación, AV corporativo e incluso algunas aplicaciones de sonido instaladas. Es la base para otros estándares AoIP como SMPTE ST 2110-30 y contribuye al impulso más amplio hacia la producción de todo I. Comprender la arquitectura y protocolos de AES67 no es sólo un ejercicio académico, afecta directamente su capacidad de diseñar, solucionar problemas y escalar una red de audio moderna.

Componentes básicos de la arquitectura AES67

Una red AES67 se basa en cuatro pilares esenciales: infraestructura de red, sincronización, transporte de medios y descubrimiento. Cada componente se basa en estándares de la fuerza de trabajo de ingeniería de Internet bien establecidos (IETF), que mantiene el sistema tanto confiable como vendor-agnóstico.

1. Infraestructura de red

AES67 se ejecuta en Ethernet estándar, pero debido a que lleva audio isocrono en tiempo real, la red debe cumplir ciertos requisitos mínimos. IGMP snooping para gestionar los grupos multicast de manera eficiente, DiffServ QoS (Diferenciado Código de Servicios Punto) para priorizar paquetes de audio, y Aislamiento VLAN para el control separado y el tráfico de medios. Mientras que 1 Gbps es típica, las plantas de transmisión a gran escala pueden utilizar 10 Gbps o más. Los marcos de Jumbo (hasta 9000 bytes) son opcionales pero se recomienda reducir la sobrecarga de paquetes.

Para una operación fiable, los ingenieros de red deben permitir estrictas colas prioritarias (generalmente CoS 4 o 5 para PTP, CoS 3 para audio RTP) y asegurar un reenvío de baja latencia. Los interruptores no deben introducir más de unos pocos microsegundos de jitter, porque la sincronización PTP de AES67 tolera sólo pequeñas variaciones de tiempo.

2. Sincronización – Protocolo sobre el tiempo de precisión (PTP)

Todos los dispositivos AES67 deben sincronizarse con un reloj común. Los mandatos estándar IEEE 1588-2008 Precision Time Protocol (a menudo llamado PTPv2) utilizando el Perfil AES67. A diferencia del PTP genérico, el perfil AES67 especifica un número de dominio predeterminado (dominio 0) y utiliza mensajería de reloj de dos pasos con multicast. El reloj de gran maestro es normalmente un servidor PTP dedicado, pero cualquier dispositivo en la red, un micrófono, una consola de mezcla o un puente, puede convertirse en el gran maestro si tiene una fuente de reloj estable.

El Mejor algoritmo del reloj maestro (BMCA) automáticamente selecciona el reloj más preciso, minimizando la configuración humana. En la práctica, las emisoras a menudo bloquean todos los dominios PTP a una referencia GPS o GNSS, logrando sincronización de submicrosecond en grandes instalaciones. Sin esta precisión, los buffers de audio se deslizarían o se desplomarían.

3. Transporte de medios – Protocolo de transporte en tiempo real (RTP)

Las muestras de audio se encapsulan en paquetes RTP y se transmiten sobre UDP. AES67 soporta las tasas comunes de muestreo: 44.1, 48 y 96 kHz, con profundidades de bits de 16 o 24 bits (y 32 bits punto flotante para uso intraestudio). Los canales por flujo pueden oscilar entre 1 y 8 (pero 4 es típico para la interoperabilidad con otros estándares como SMPTE ST 2110-30).

El formato de carga de pago RTP es L16 o L24 para PCM lineal sin compresión. AES67 también permite la codificación de μ-law para la compatibilidad con sistemas de telecomunicaciones antiguos, aunque raramente se utiliza en audio profesional. Los paquetes se envían como flujos UDP multicast a una dirección de grupo; los receptores se suscriben a través de IGMP. Protocolo de control de RTP (RTCP) se utiliza para estadísticas fuera de banda, pero no para la recuperación del reloj, que es manejado por completo por PTP.

Latency in AES67 es configurable. El defecto recomendado es de 1 ms (que permite aproximadamente 48 muestras por paquete a 48 kHz), pero algunos equipos soportan 0,125 ms para monitorización de latencia ultra-bajo o 4 ms para conexiones menos críticas sobre las redes congestionadas.

4. Descubrimiento y registro

Los dispositivos necesitan saber qué flujos están disponibles en la red. AES67 originalmente se basó en la Protocolo de anuncio de sesión (SAP), que periódicamente transmite descripciones de secuencias (formato SDP) a una conocida dirección multicast (224.2.127.254). SAP es simple y ligero, pero puede ser chateado en grandes redes.

Otros métodos de descubrimiento coexisten con AES67: RTSP (Protocolo de Streaming de Tiempo Real) se pueden utilizar para el control de sesión, y extensiones más recientes como mDNS/DNS-SD están ganando tracción en entornos híbridos Dante/AES67. El punto clave es que AES67 no define un protocolo de descubrimiento, sino que sólo mandatos que los flujos pueden describirse usando un archivo de descripción de sesión (SDP). Los fabricantes son libres de implementar cualquier mecanismo de descubrimiento que transmita información SDP, siempre y cuando un dispositivo de terceros pueda parizarlo.

Protocolos clave en detalle

Mientras que los cuatro componentes básicos constituyen la arquitectura, varios protocolos subyacentes merecen una mirada más cercana. Entendiendo cómo se interbloquean es lo que separa un despliegue funcional AES67 de un problematico.

PTP (Protocolo de Tiempo de Precisión) – el latido cardíaco

PTP trabaja intercambiando mensajes de tiempos entre el gran maestro y todos los relojes de esclavos. El perfil AES67 utiliza dos pasos: el gran maestro envía un mensaje sincronizado, luego un mensaje de seguimiento que contiene el tiempo de salida exacto. Los esclavos usan eso para computar offset y ajustar sus propios relojes a través de un algoritmo servo.

En los interruptores más gestionados, los mensajes PTP deben recibir la máxima prioridad y nunca ser retrasados por el procesamiento de la tienda y de futuro. Los relojes de sonido o relojes transparentes (TC) en los interruptores pueden compensar la demora del puente, pero en las redes pequeñas un enfoque de dos pasos ordinario sin TC es suficiente. La norma requiere que los dispositivos finales se bloquean dentro de 2 segundos de inicio y mantengan la deriva por debajo de 1 micro segundo intervalo con un diseño bien.

RTP (Protocolo de Transporte en tiempo real) – el Portador de carga

Los paquetes RTP llevan un encabezado que contiene número de secuencia, timetamp y SSRC (identificador de fuente de sincronización). El perfil AES67 especifica un tiempo máximo de paquete de 4 ms, con 1 ms preferido. Desde que RTP se ejecuta sobre UDP, no hay retransmisión; la pérdida de paquetes debe ser manejada hasta arriba (por ejemplo, a través de flujos redundantes o FEC, aunque AES67 no ordena FEC).

Un problema común: tiempos de empaquetado descompuestos entre el remitente y el receptor pueden causar desplegamientos de audio. Configurar siempre ambos extremos al mismo parámetro "ptime" en el archivo SDP. Verificar también que la ruta de red no excede el tiempo de RTP a vida (TTL); AES67 recomienda un TTL de al menos 10 para redes pequeñas.

SIP (Protocolo de Iniciación de la Sesión) – un superposición útil

AES67 menciona SIP como un método posible para la gestión de sesión y el descubrimiento de secuencias, pero raramente es el enfoque primario. En la práctica, la mayoría de los dispositivos AES67 dependen de interfaces web de SAP o propietarios. SIP es más común en AoIP orientados por telecom como VoIP o intercomunicadores basados en SIP que se integran con puentes AES67.

Beneficios de AES67 en el Mundo Real

El beneficio primario es interoperabilidad sin bloqueo. Una instalación de radiodifusión que utiliza RAVENNA para enlaces de estudio a transmisor puede aceptar micrófonos equipados con Dante; una consola de sonido en vivo puede extraer un flujo de un Q-SYS DSP. AES67 actúa como un “translator” universal que elimina la necesidad de hardware de puerta de entrada dedicado en muchos casos.

Otras ventajas son:

  • Escalabilidad: Debido a que AES67 utiliza multicast IP estándar, puede agregar cientos de secuencias siempre y cuando sus conmutadores puedan manejar el conteo de grupos multicast y ancho de banda. No hay cuota de licencia por canal.
  • Eficacia de los costos: No se requiere hardware de red patentado – los interruptores de la plataforma de buena calidad funcionan cuando se configuran correctamente.
  • Futuro-prueba: Como SMPTE ST 2110 se convierte en la norma en la radiodifusión, AES67 (que es idéntica a la parte de audio de ST 2110-30) ya está allí. Un estudio que construye una red AES67 hoy puede migrar a la totalidad ST 2110 video-over-IP más adelante con cambios mínimos.
  • Confiabilidad: El reloj basado en PTP elimina los problemas de deriva y jitter que plagan las redes isocronas más antiguas. La tolerancia de AES67 para la pérdida de paquetes (hasta 1% sin fallo crítico en sistemas bien dotados) añade resiliencia.

Guía de implementación – Construyendo su primera red AES67

Implementar AES67 requiere más que solo enchufar dispositivos. Siga este enfoque estructurado para evitar dolores de cabeza comunes.

Paso 1: Verificar la compatibilidad del dispositivo

No todos los dispositivos que reclaman “AES67” son totalmente compatibles. Revise la lista de interoperabilidad AES67 (mantenida por la Media Networking Alliance). Si mezcla Dante y RAVENNA, por ejemplo, asegúrese de que el módulo Dante admite el modo AES67 opcional (disponible en muchos modelos más nuevos).

Paso 2: Diseño de la red Topología

Usar un estrella topología con interruptores de núcleo y borde, o una hoja de columna para grandes plantas. Habilitar la snooping IGMP y Querier en cada VLAN que lleva audio. Control separado y tráfico de audio: VLANs dedicados para PTP y transmisión de flujo multicast reduce el riesgo de la configuración errónea.

Asignar direcciones IP estáticas a dispositivos críticos (gran reloj, unidades de I/O fijas). DHCP es aceptable para puntos finales si el contrato de arrendamiento es largo, pero evitar direcciones dinámicas para los grandes maestros de PTP.

Paso 3: Configurar PTP

  • Designar un gran maestro primario (por ejemplo, un servidor PTP bloqueado por GPS).
  • Asegúrese de que todos los dispositivos usen el perfil AES67 (IEEE 1588-2008, 2 pasos, por defecto de dominio 0, multicast).
  • Establecer todos los interruptores en modo de reloj transparente (si es compatible) o modo de reloj de límite. Al mínimo, no deben filtrar los mensajes PTP; asegúrese de que se permite el multicast PTP Ethernet (dirección de MAC 01-1B-19-00-00-00-00).
  • Monitor PTP offset en cada dispositivo – debe ser < 1 μs. Si supera 10 μs, hay un problema de tiempo de red (tras demora de red, sobrecarga de CPU o jitter de cableado pobre).

Paso 4: Configurar las corrientes

Utilice la interfaz de usuario web del dispositivo o software de control para crear un flujo de transmisor. Capturar el archivo SDP (a menudo descargable como un archivo .sdp). En el receptor, importar el SDP o utilizar el descubrimiento automático (SAP/mDNS). Verificar que el flujo aparece en la red: puede utilizar Wireshark con el filtro de visualización para ver paquetes.

Paso 5: Prueba y validación

  • Medir latencia entre transmisor y receptor mediante un tono y osciloscopio, o una herramienta de análisis RTP. Por defecto AES67 1 ms debe ser alcanzado con un simple interruptor.
  • Prueba la resistencia del paquete desconectando un cable brevemente; el audio no debe desconcertar para paquetes perdidos de 1–2 ms de duración. Si lo hace, aumentar el tamaño del búfer ligeramente (hasta 4 ms).
  • Verifique que se mantiene la cerradura PTP cuando se agregan múltiples secuencias. Un error común está sobrecargando el interruptor CPU con mensajes PTP en un puerto mal configurado; use el conmutador QoS para priorizar PTP.

Paso 6: Documenta tu configuración

Grabar la configuración de cada dispositivo IP, PTP role, stream SDP y switch port. Esto es invaluable cuando un componente falla y necesita reemplazo. Sin documentación, reconstruir una gran red AES67 desde cero es casi imposible.

Pitfalls comunes – y cómo evitarlos

  • PTP reloj de conflictos: Ejecutar múltiples dominios PTP en la misma red (por ejemplo, sistema de películas usando el dominio 0 mientras una consola de sonido en vivo utiliza el dominio 1) puede causar confusión.
  • IGMP snooping no habilitado: Sin ella, multicast audio inunda cada puerto de conmutación, causando pérdida de paquetes y carga innecesaria. Siempre permite IGMP en cada VLAN.
  • Misconfigurado QoS: Si PTP se retrasa tras un estallido de tráfico FTP, derivas de sincronización. Use colas de prioridad estrictas (DSCP 46 para PTP, DSCP 34 o 36 para audio RTP).
  • Desigualdad de marco de Jumbo: Si el interruptor admite marcos jumbo pero el remitente no, puede obtener fragmentación. Mantenga todos los dispositivos en el mismo MTU (1500 o 9000).
  • Ignorando el sistema de red: Incluso con PTP perfecto, los búferes de la máquina de arranque RTP deben ser establecidos para absorber el rompecabezas de la red. Use “ptime” consistente con el peor de los casos de su red.

Comparación con otras normas AoIP

AES67 no es un producto; es un estándar de cobertura. Dante domina el mercado AV instalado y soporta AES67 como modo secundario. RAVENNA es popular en la radiodifusión y ya utiliza AES67 como su transporte de audio nativo. Livewire+ (de Wheatstone) está construido en AES67. Q-LAN (QSC) también soporta AES67. La diferencia clave: en un entorno multi-vendor, AES67 asegura que todos hablan el mismo idioma. Cuando usted necesita la latencia más baja (sub-0,25 ms), los sistemas propietarios todavía tienen un borde, pero para el 99% de uso profesional, AES67 1 ms es más que adecuado.

El futuro de AES67

La Sociedad de Ingeniería de Audio continúa evolucionando el estándar. AES67-2022 agregó soporte para flotador de 32 bits, clarificó el manejo de flujo redundante, y actualizó el perfil PTP para alinearse con IEEE 1588-2019. Media Networking Alliance ejecuta programas de certificación para garantizar la interoperabilidad. A medida que SMPTE ST 2110 se expande más allá de la transmisión en eventos en vivo y casas de culto, AES67 seguirá siendo la columna vertebral de audio. Para cualquier ingeniero que diseñe un sistema de audio en red hoy, AES67 no es sólo una buena a la acción, es la apuesta más segura para la compatibilidad a largo plazo.

Para profundizar, consulte al funcionario AES67 standard (AES67-2018/R2023), el RTP RFC (RFC 3550), y el estándar IEEE 1588-2008. Guías prácticas de Audinate y RAVENNA Ofrece estudios de casos de despliegue en el mundo real. Con una sólida comprensión de la arquitectura y protocolos de AES67, puede diseñar una red de audio que sea de alto rendimiento y realmente abierta.