Audio over IP (AoIP) has transformed professional audio workflows by enabling high-quality, low-latency audio transport over standard Ethernet networks. As broadcast, live sound, and studio environments increasingly adopt IP-based infrastructure, interoperability between different AoIP systems becomes critical. The AES67 standard, developed by the Audio Engineering Society, addresses this need by defining a common set of protocols for synchronization, transport, and discovery. Understanding AES67 compatibility is essential for engineers, system integrators, and educators who require seamless integration across diverse audio networks.

What Is AES67?

AES67, formally known as AES67-2018, is an interoperability standard for high-performance audio over IP networks. It was initially published in 2013 and revised in 2018 to improve clocking and discovery mechanisms. Unlike proprietary AoIP protocols such as Dante, Ravenna, or Q-LAN, AES67 does not define a full closed ecosystem. Instead, it specifies a minimal set of requirements that any device must meet to communicate with other AES67-compliant devices. This makes it a "lowest common denominator" layer that bridges islands of different AoIP systems.

The standard is built on widely adopted open technologies: Precision Time Protocol (PTPv2) for synchronization, Real-time Transport Protocol (RTP) for audio streaming, Session Description Protocol (SDP) for stream metadata, and Session Announcement Protocol (SAP) for automatic discovery. By standardizing these elements, AES67 ensures that equipment from different manufacturers can exchange audio streams without custom gateways or software patches.

AES67 in the AoIP Ecosystem

AES67 sits at the core of the Audio over IP interoperability landscape. Many major manufacturers now embed AES67 support alongside their native protocols. For example, Audinate’s Dante devices can operate in AES67 mode, and the Ravenna suite is natively AES67-compliant. AES67 is also the audio component of the SMPTE ST 2110 suite for broadcast media transport, making it essential for television and radio production.

Key Features of AES67 Compatibility

AES67 compatibility is defined by several technical features that together enable reliable, low-latency audio networking. Understanding these features helps in selecting devices and designing networks.

  • Interoperability: The primary goal. Any two AES67-compliant devices, regardless of brand, can exchange audio with configuration via SDP. This eliminates vendor lock-in and simplifies multi-vendor installations.
  • Synchronization via Precision Time Protocol (PTPv2): AES67 mandates IEEE 1588-2008 (PTPv2) with a specific default profile. This provides sample-accurate timing across the network, essential for multi-channel, multi-device systems. For redundancy, AES67 supports either a grandmaster clock elected from the network or an external reference.
  • Stream Management with RTP and SDP: Audio is carried in RTP packets using a negotiated payload format (typically L24 or L16 linear PCM, but also compressed codecs if agreed). SDP files describe the stream format, IP addresses, ports, and timing information. This allows devices to "advertise" streams and receivers to "join" them.
  • Discovery via SAP or mDNS: AES67 originally used SAP (Session Announcement Protocol) to announce streams. Many modern implementations also support mDNS (Multicast DNS) for service discovery, making it easier to find devices on a network segment. Some systems use the NMOS IS-04 registration for larger deployments.
  • Multicast and Unicast Support: AES67 works with both multicast (one-to-many) and unicast (one-to-one) streaming. Multicast is efficient for many receivers, while unicast fits point-to-point or smaller setups. The standard defines mechanisms for devices to join and leave multicast groups via IGMP.

Audio Parameters and Latency

AES67 defines several mandatory audio parameters to guarantee interchange. It supports sample rates of 44.1 kHz, 48 kHz (and multiples up to 192 kHz), and bit depths of 16, 24, or 32 bits per sample. Latency is configurable, typically ranging from 1 ms to 10 ms. The standard allows devices to negotiate packet time (e.g., 1 ms, 125 µs) to balance latency versus network overhead. Lower packet time reduces delay but increases network load.

Implementing AES67 Compatibility in Your Network

Implementing AES67 requires careful attention to network infrastructure, device configuration, and ongoing management. Following these guidelines will help achieve reliable operation.

Network Infrastructure and Quality of Service (QoS)

Because AES67 streams are real-time and sensitive to jitter, the network must prioritize audio traffic. Use managed switches that support IGMP snooping to contain multicast traffic to only ports that need it. Configure QoS (DiffServ) to mark audio packets with expedited forwarding (EF) or assured forwarding (AF41). Ensure sufficient bandwidth: a 48-channel, 48 kHz, 24-bit stream consumes about 72 Mbps. Separate audio traffic from best-effort data using VLANs to prevent congestion. For large-scale deployments, consider using PTP boundary clocks (BC) or transparent clocks (TC) to maintain precise synchronization across multiple switches.

Clocking and Synchronization Setup

All AES67 devices must share a common PTP domain. Choose one grandmaster clock (e.g., a dedicated PTP server or a device with built-in grandmaster capability) and assign all devices to the same domain number (default 0). Ensure switches pass PTP messages correctly (enable at least transparent clocking). Verify that the ordinary clocks in endpoints can lock to the grandmaster within microseconds. If PTP fails, streams may drift or produce clicks. External references like GPS or NTP can feed the grandmaster for long-term stability.

Device Configuration and Discovery

Configure each device with its AES67 mode enabled. In practice, many devices have a web interface or control panel to choose between native mode and AES67 mode. After enabling, the device will start advertising its clock availability and stream offers (SDP). On the receiving side, initiate subscription: the receiver takes the SDP URI (often from a multicast announcement or mDNS) and sets up an RTP receiver. Some systems use central management software (e.g., Audinate’s Dante Controller or Lawo’s VSM) to orchestrate subscriptions; others rely on manual SDP file exchanges.

Common Configuration Pitfalls

  • PTP domain mismatch: Devices in different PTP domains cannot synchronize. Always set all devices to the same domain.
  • Jitter buffer underrun: If network delay varies too much, audio glitches occur. Increase the jitter buffer in the receiver (within the allowed 1-10 ms range) to compensate.
  • Unicast vs. multicast routing: Ensure routers and firewalls allow multicast traffic and that IGMP querier is active. For unicast, verify that the RTP ports are open.
  • Sample rate and format mismatch: Both sender and receiver must agree on the SDP parameters. Use tools like the AES67 Analyzer to verify.

Benefits of AES67 Compatibility

Adopting AES67 delivers tangible advantages for any audio-over-IP deployment.

  • Flexibility: Mix and match equipment from different vendors without custom bridges. A studio can use a Dante-equipped mixing console alongside a Ravenna-based microphone preamplifier, as long as both support AES67.
  • Scalability: Add new devices to an existing network without replacing infrastructure. As long as they are AES67-compliant, they will integrate.
  • Cost-Effectiveness: Avoid investing in proprietary converters or separate network fabrics for each protocol. AES67 runs on standard Gigabit Ethernet hardware.
  • Future-Proofing: AES67 is a foundational component of SMPTE ST 2110, which is rapidly becoming the standard for broadcast media transport. Investing in AES67-ready equipment today positions your facility for tomorrow’s IP-based workflows.
  • Simplified Training: Once staff understand one AES67 device, they can work with any others. The shared vocabulary (PTP, RTP, SDP) reduces learning curves.

Challenges and Considerations

Despite its strengths, AES67 presents challenges that need careful planning.

  • Network Configuration Complexity: Setting up PTP, QoS, and multicasting requires IT knowledge. In house environments without dedicated network staff, this can be a hurdle. Training or hiring specialist integrators is often necessary.
  • Latency Variability: AES67 allows latency buffers up to 10 ms, but some applications require sub-millisecond delays (e.g., live monitoring). In such cases, proprietary protocols like Ravenna or Dante may offer lower latency profiles, though they also support AES67 at higher latency.
  • Interoperability at Scale: While the standard ensures basic compatibility, advanced features (redundancy, routing flexibility, remote control) are not defined. For large systems with hundreds of streams, a management layer like NMOS (AMWA NMOS) is recommended to handle dynamic subscription control.
  • Verification and Testing: Not all devices claiming AES67 compliance implement every aspect equally. Use test tools such as the AES67 Analyzer to validate conformance, and check SDP files for correct syntax.

Testing and Verifying AES67 Interoperability

Before deploying AES67 in critical paths, validate the setup. Connect a single sender and receiver, then monitor for errors. Use Wireshark to inspect PTP timing messages and RTP streams. Commercial tools like the Dante AES67 Converter or the Ravenna AES67 tools offer graphical interfaces. Key metrics: PTP offset (should be below 1 µs), jitter (under 0.5 µs), and packet loss (0%). Many manufacturers provide detailed guides for their devices; always follow those first.

The Future of AES67 and AoIP

AES67 continues to evolve. The AES recently released a 2023 revision that clarifies redundancy with seamless switching (e.g., SMPTE 2022-7) and improves support for higher sample rates. The standard is increasingly used in combination with NMOS for dynamic discovery and connection management, enabling fully automated IP infrastructures. As 2110-30 gains traction in broadcasting, AES67’s role as the audio transport will only grow. Additionally, the rise of AV-over-IP for live events and installations reinforces the need for universal interoperability. Embracing AES67 now positions your facility to adapt to these trends smoothly.

Conclusion

Understanding AES67 compatibility is vital for achieving seamless AoIP interoperability. By adhering to a common core of PTP, RTP, SDP, and discovery protocols, AES67 allows diverse audio systems to communicate effectively. For engineers and system integrators, the path to reliable operation lies in proper network design, careful device configuration, and thorough testing. The benefits—flexibility, scalability, cost savings, and future-proofing—far outweigh the initial learning curve. As audio networking continues to evolve, embracing the AES67 standard ensures your setup remains compatible, robust, and ready for the next generation of IP-based audio workflows.