What is AES67 – and Why Does It Matter?

Audio-over-IP (AoIP) has transformed professional audio workflows, but for years the ecosystem was fragmented. Each manufacturer—Dante, RAVENNA, Livewire, Q-LAN—used proprietary protocols that could not talk to one another. In 2013 the Audio Engineering Society published AES67, an open interoperability standard that defines a common set of network protocols so devices from different vendors can exchange high-quality audio over standard IP networks. AES67 does not replace these proprietary systems; it acts as a "bridging layer" that allows them to coexist and interoperate without requiring every device to support a single closed platform.

AES67 is now widely adopted in broadcast, live sound, recording studios, corporate AV, and even some installed sound applications. It is the foundation for other AoIP standards like SMPTE ST 2110-30 and contributes to the broader push toward all-IP production. Understanding AES67’s architecture and protocols is not just an academic exercise—it directly affects your ability to design, troubleshoot, and scale a modern audio network.

Core Components of the AES67 Architecture

An AES67 network is built on four essential pillars: network infrastructure, synchronization, media transport, and discovery. Each component relies on well-established Internet Engineering Task Force (IETF) standards, which keeps the system both reliable and vendor-agnostic.

1. Network Infrastructure

AES67 runs on standard Ethernet, but because it carries isochronous real-time audio, the network must meet certain minimum requirements. Switches must support IGMP snooping to manage multicast groups efficiently, DiffServ QoS (Differentiated Services Code Point) to prioritize audio packets, and VLAN isolation to separate control and media traffic. While 1 Gbps is typical, large-scale broadcast plants may use 10 Gbps or higher. Jumbo frames (up to 9000 bytes) are optional but recommended to reduce packet overhead.

For reliable operation, network engineers should enable strict priority queues (usually CoS 4 or 5 for PTP, CoS 3 for audio RTP) and ensure low latency forwarding. Switches should not introduce more than a few microseconds of jitter, because AES67’s PTP synchronization tolerates only tiny timing variances.

2. Synchronization – Precision Time Protocol (PTP)

All AES67 devices must be synchronized to a common clock. The standard mandates IEEE 1588-2008 Precision Time Protocol (often called PTPv2) using the AES67 profile. Unlike generic PTP, the AES67 profile specifies a default domain number (domain 0) and uses two-step clock messaging with multicast. The grandmaster clock is typically a dedicated PTP server, but any device on the network—a microphone, a mixing console, or a bridge—can become the grandmaster if it has a stable clock source.

The Best Master Clock Algorithm (BMCA) automatically selects the most accurate clock, minimizing human configuration. In practice, broadcasters often lock all PTP domains to a GPS or GNSS reference, achieving sub-microsecond sync across large installations. Without this precision, audio buffers would glitch or drop out.

3. Media Transport – Real-time Transport Protocol (RTP)

Audio samples are encapsulated into RTP packets and transmitted over UDP. AES67 supports common sampling rates: 44.1, 48, and 96 kHz, with bit depths of 16 or 24 bits (and 32-bit floating point for intra-studio use). Channels per stream can range from 1 to 8 (but 4 is typical for interoperability with other standards like SMPTE ST 2110-30).

RTP payload format is L16 or L24 for uncompressed linear PCM. AES67 also allows μ-law encoding for compatibility with older telecom systems, though that is rarely used in professional audio. Packets are sent as multicast UDP streams to a group address; receivers subscribe via IGMP. The RTP Control Protocol (RTCP) is used for out-of-band statistics, but not for clock recovery—that is handled entirely by PTP.

Latency in AES67 is configurable. The recommended default is 1 ms (allowing about 48 samples per packet at 48 kHz), but some equipment supports 0.125 ms for ultra-low latency monitoring or 4 ms for less critical connections over congested networks.

4. Discovery and Registration

Devices need to know which streams are available on the network. AES67 originally relied on the Session Announcement Protocol (SAP), which periodically broadcasts stream descriptions (SDP format) to a well-known multicast address (224.2.127.254). SAP is simple and lightweight, but it can be chatty on large networks.

Other discovery methods co-exist with AES67: RTSP (Real Time Streaming Protocol) can be used for session control, and more recent extensions like mDNS/DNS-SD are gaining traction in hybrid Dante/AES67 environments. The key point is that AES67 itself does not define a discovery protocol—it only mandates that streams can be described using a Session Description Protocol (SDP) file. Manufacturers are free to implement any discovery mechanism that conveys SDP information, as long as a third-party device can parse it.

Key Protocols in Detail

While the four core components constitute the architecture, several underlying protocols deserve a closer look. Understanding how they interlock is what separates a functional AES67 deployment from a problematic one.

PTP (Precision Time Protocol) – the Heartbeat

PTP works by exchanging timestamped messages between the grandmaster and all slave clocks. The AES67 profile uses two-step operation: the grandmaster sends a Sync message, then a Follow_Up message containing the exact departure time. Slaves use that to compute offset and adjust their own clocks via a servo algorithm.

On most managed switches, PTP messages must be given the highest priority and never be delayed by store-and-forward processing. Boundary clocks or transparent clocks (TC) on switches can compensate for bridge delay, but in small networks an ordinary two-step approach without TC is sufficient. The standard requires that end devices lock within 2 seconds of startup and maintain drift below 1 microsecond over a 1-second interval—tight, but achievable with good design.

RTP (Real-time Transport Protocol) – the Payload Carrier

RTP packets carry a header containing sequence number, timestamp, and SSRC (synchronization source identifier). The AES67 profile specifies a maximum packet time of 4 ms, with 1 ms preferred. Since RTP runs over UDP, there is no retransmission; packet loss must be handled upstream (e.g., via redundant streams or FEC, though AES67 does not mandate FEC).

A common pitfall: mismatched packet times between sender and receiver can cause audio dropouts. Always configure both ends to the same “ptime” parameter in the SDP file. Also verify that the network path does not exceed the RTP time-to-live (TTL); AES67 recommends a TTL of at least 10 for small networks.

SIP (Session Initiation Protocol) – a Helpful Overlay

AES67 mentions SIP as one possible method for session management and stream discovery, but it is seldom the primary approach. In practice, most AES67 devices rely on SAP or proprietary web interfaces. SIP is more common in telecom-oriented AoIP like VoIP or SIP-based intercoms that integrate with AES67 bridges.

Benefits of AES67 in the Real World

The primary benefit is interoperability without lock-in. A broadcast facility using RAVENNA for studio-to-transmitter links can accept Dante-equipped microphones; a live sound console can pull a stream from a Q-SYS DSP. AES67 acts as a universal “translator” that eliminates the need for dedicated gateway hardware in many cases.

Other advantages include:

  • Scalability: Because AES67 uses standard IP multicast, you can add hundreds of streams as long as your switches can handle the multicast group count and bandwidth. There is no licensing fee per channel.
  • Cost-effectiveness: No proprietary network hardware required – good-quality off-the-shelf switches work when configured properly.
  • Future-proofing: As SMPTE ST 2110 becomes the norm in broadcast, AES67 (which is identical to the audio part of ST 2110-30) is already there. A studio that builds an AES67 network today can migrate to full ST 2110 video-over-IP later with minimal changes.
  • Reliability: PTP-based clocking eliminates the drift and jitter issues that plague older isochronous networks. AES67’s tolerance for packet loss (up to 1% without critical failure in well-buffered systems) adds resilience.

Implementation Guide – Building Your First AES67 Network

Deploying AES67 requires more than just plugging in devices. Follow this structured approach to avoid common headaches.

Step 1: Verify Device Compatibility

Not all devices claiming “AES67” are fully compliant. Check the AES67 interoperability list (maintained by the Media Networking Alliance). If you mix Dante and RAVENNA, for example, ensure the Dante module supports the optional AES67 mode (available on many newer models). Some older gear requires a firmware update.

Step 2: Design the Network Topology

Use a star topology with a core switch and edge switches, or a spine-leaf for large plants. Enable IGMP snooping and Querier on each VLAN that carries audio. Separate control and audio traffic: dedicated VLANs for PTP and stream multicast reduce the risk of misconfiguration.

Assign static IP addresses to critical devices (grandmaster clock, fixed I/O units). DHCP is acceptable for endpoints if the lease is long, but avoid dynamic addresses for PTP grandmasters.

Step 3: Configure PTP

  • Designate a primary grandmaster (e.g., a GPS-locked PTP server).
  • Ensure all devices use the AES67 profile (IEEE 1588-2008, 2-step, default domain 0, multicast).
  • Set all switches to transparent clock mode (if supported) or boundary clock mode. At minimum, they should not filter PTP messages; make sure PTP Ethernet multicast is allowed (MAC address 01-1B-19-00-00-00).
  • Monitor PTP offset on each device – it should be < 1 µs. If it exceeds 10 µs, there is a network timing issue (switch delay, CPU overload, or jitter from poor cabling).

Step 4: Set Up Streams

Use the device’s web UI or control software to create a transmitter stream. Capture the SDP file (often downloadable as a .sdp file). On the receiver, import the SDP or use automatic discovery (SAP/mDNS). Verify that the stream appears on the network: you can use Wireshark with the rtp display filter to see packets. Check the SSRC – duplicate SSRCs between streams can cause confusion on receivers that do not handle it gracefully.

Step 5: Test and Validate

  • Measure latency between transmitter and receiver using a tone and oscilloscope, or a RTP analyzer tool. AES67’s 1 ms default should be achieved over a simple switch.
  • Test packet loss resilience by disconnecting a cable briefly; the audio should not glitch for lost packets of 1–2 ms duration. If it does, increase buffer size slightly (up to 4 ms).
  • Verify that PTP lock is maintained when you add multiple streams. A common mistake is overloading the switch CPU with PTP messages on a poorly configured port; use switch QoS to prioritize PTP.

Step 6: Document Your Configuration

Record each device’s IP, PTP role, stream SDP, and switch port configuration. This is invaluable when a component fails and needs replacement. Without documentation, rebuilding a large AES67 network from scratch is nearly impossible.

Common Pitfalls – and How to Avoid Them

  • PTP clocking conflicts: Running multiple PTP domains on the same network (e.g., movie system using domain 0 while a live sound console uses domain 1) can cause confusion. Stick to a single domain or isolate with VLANs.
  • IGMP snooping not enabled: Without it, multicast audio floods every switch port, causing packet loss and unnecessary load. Always enable IGMP on each VLAN.
  • Misconfigured QoS: If PTP gets delayed behind a burst of FTP traffic, synchronization drifts. Use strict priority queues (DSCP 46 for PTP, DSCP 34 or 36 for RTP audio).
  • Jumbo frame mismatch: If the switch supports jumbo frames but the sender does not, you may get fragmentation. Keep all devices on the same MTU (1500 or 9000).
  • Ignoring network jitter: Even with perfect PTP, RTP jitter buffers must be set to absorb network jitter. Use “ptime” consistent with your network’s worst-case jitter.

Comparison with Other AoIP Standards

AES67 is not a product; it is a bridging standard. Dante dominates the installed AV market and supports AES67 as a secondary mode. RAVENNA is popular in broadcast and already uses AES67 as its native audio transport. Livewire+ (from Wheatstone) is built on AES67. Q-LAN (QSC) supports AES67 as well. The key difference: in a multi-vendor environment, AES67 ensures they all speak the same language. When you need the lowest latency (sub-0.25 ms), proprietary systems still have an edge, but for 99% of professional use, AES67’s 1 ms is more than adequate.

The Future of AES67

The Audio Engineering Society continues to evolve the standard. AES67-2022 added support for 32-bit float, clarified redundant stream handling, and updated the PTP profile to align with IEEE 1588-2019. Meanwhile, the Media Networking Alliance runs certification programs to guarantee interoperability. As SMPTE ST 2110 expands beyond broadcast into live events and houses of worship, AES67 will remain the audio backbone. For any engineer designing a networked audio system today, AES67 is not just a nice-to-have—it is the safest bet for long-term compatibility.

To dive deeper, consult the official AES67 standard (AES67-2018/R2023), the RTP RFC (RFC 3550), and the IEEE 1588-2008 standard. Practical guides from Audinate and RAVENNA offer real-world deployment case studies. With a solid grasp of AES67’s architecture and protocols, you can design an audio network that is both high-performance and truly open.