AES67 Audio over IP Standard

AES67 (2013, revised 2018) is an open IEEE/AES standard for streaming uncompressed audio over IP networks with sub-millisecond latency. Developed jointly by the Audio Engineering Society and adopted as part of SMPTE ST 2110-30, it defines how audio packets are formatted, synchronized, and routed across standard Ethernet, allowing hardware from different manufacturers to exchange audio on the same network.

See also: glossary/aes for a quick-reference summary of AES standards.

Why AES67 Matters

Proprietary audio networking protocols — Dante, Ravenna, Livewire, WheatNet, Q-LAN — each handle discovery, routing, and management differently. Without a common standard, a Dante-only console cannot send audio to a Ravenna processor or a Livewire broadcast codec. AES67 solves this by defining only the transport layer (how audio packets are structured and timed), leaving discovery and management to proprietary systems. When two devices both enter AES67 mode, they can exchange audio regardless of their native protocol.

For broadcasters with mixed-vendor infrastructure, this interoperability is essential. For corporate AV with a single-vendor Dante installation, AES67 is less critical day-to-day but becomes important when a non-Dante device must integrate.

Technical Specification

AES67 is built on established networking standards:

• Transport: RTP (Real-time Transport Protocol) over UDP/IP — the same transport used for VoIP and video streaming
• Multicast addressing: 239.x.x.x range (administratively scoped multicast)
• Sample rates: 48 kHz (required), 44.1 kHz and 96 kHz (optional)
• Bit depths: 24-bit linear PCM (L24, required), 16-bit and 32-bit (optional)
• Packet time (ptime): 1 ms (required), 0.125 ms, 0.25 ms, 0.5 ms, 4 ms (optional)
• Maximum channels per stream: 8 at 1 ms ptime on 1 GbE
• Clock synchronization: IEEE 1588-2008 PTP, profile per AES67 Annex B (multicast, domain 0 default)
• Latency: 1 ms typical (configurable 0.33 ms–1000 ms)

Bandwidth per channel: approximately 4.5 Mbps at 48 kHz/24-bit/1 ms ptime. A 64-channel stream consumes ~288 Mbps on a 1 GbE link — well within capacity, but significant in multi-stream deployments.

Session Description and Discovery

AES67 defines audio transport but not device discovery. Finding AES67 sources on the network requires a separate mechanism:

SDP (Session Description Protocol) — RFC 4566 format text blocks describing a stream's multicast address, RTP payload type, sample rate, channel count, and ptime. AES67 streams are described using SDP.

SAP (Session Announcement Protocol) — RFC 2974. Devices multicast SDP announcements to the 239.255.255.255 SAP address at regular intervals. Receivers listen to this address to discover available streams. SAP/SDP is used by Ravenna and by AES67 in broadcast environments.

Dante Discovery: Dante devices in AES67 mode do not use SAP/SDP — they still use Dante's proprietary discovery. A Dante device receives AES67 streams via manually configured subscriptions or through Dante Domain Manager. See dante for Dante-native AES67 integration.

NMOS (Networked Media Open Specifications) — IS-04/IS-05 (AMWA Networked Media Open Specifications) provide a REST API-based discovery and connection management framework increasingly used in broadcast alongside AES67. NMOS replaces SAP in large SMPTE 2110 installations.

PTP Configuration for AES67

All AES67 devices synchronize to an IEEE 1588 PTP grandmaster. Misconfigured PTP is the leading cause of AES67 interoperability failures.

Key PTP parameters:

• Domain number: AES67 Annex B specifies domain 0 by default. Dante uses domain 0. Ravenna and some broadcast gear use domain 127. Devices on different PTP domains cannot synchronize — they will click, drop, or fail completely.
• Profile: AES67 Annex B defines a default PTP profile (End-to-End delay mechanism, multicast transport). Some devices support the SMPTE ST 2059-2 PTP profile required by broadcast 2110 systems — verify compatibility.
• Grandmaster selection: IEEE 1588 uses BMCA (Best Master Clock Algorithm). The grandmaster is elected based on clock class, accuracy, and variance. In mixed-vendor systems, explicitly designate a dedicated grandmaster (a PTP-capable switch or a dedicated PTP appliance like the Meinberg LANTIME) rather than relying on BMCA to elect a stable device.
• Switch support: Managed switches should support PTP boundary clock or transparent clock operation. Without switch PTP support, PTP delays and asymmetry are higher, increasing clock jitter.

Verifying PTP sync: Use the vendor's monitoring tool (Dante Controller for Dante, Ravenna Discovery for Ravenna, or a standalone IEEE 1588 analyzer) to confirm all devices are locked to the same grandmaster and showing offset values under 1 µs.

AES67 in Dante Systems

Dante devices support AES67 in two ways:

AES67 receive mode: A Dante device can subscribe to an AES67 multicast stream from a non-Dante source. Configured in Dante Controller (Device View → AES67). The Dante device appears as the AES67 receiver; the remote device must send SAP/SDP announcements or be manually configured.

Dante AES67 transmit mode: The device transmits a Dante flow formatted as AES67 RTP. Other AES67-capable devices can receive it. This must be enabled in Dante Controller and requires that the AES67 receiver can parse the SDP session information.

Important limitation: Dante in AES67 mode sacrifices automatic discovery and Dante routing convenience. AES67 subscriptions must be configured manually on both ends, and troubleshooting requires understanding both Dante and AES67 diagnostic tools.

AES67 and SMPTE ST 2110

SMPTE ST 2110 is the broadcast industry's reference standard for professional media over IP. It uses three sub-standards:

• ST 2110-20: Uncompressed video (based on SMPTE 2022-6)
• ST 2110-30: Uncompressed audio — this is AES67 (adopts AES67 transport)
• ST 2110-40: Ancillary data (closed captions, timecode)

Facilities implementing 2110 for broadcast use AES67 as their audio transport layer, typically with NMOS IS-04/IS-05 for device registry and connection management instead of SAP. Understanding AES67 is prerequisite to working in 2110 broadcast environments.

Network Requirements

• Managed Gigabit Ethernet with IGMP snooping (controls multicast delivery)
• IGMP v2 or v3 on switches — prevents multicast flooding of non-AES67 ports
• QoS (DSCP 46 / EF) — AES67 traffic should be prioritized like Dante. See qos-for-audio
• Dedicated AV VLAN — isolates AES67 multicast from general IT traffic. See vlan-configuration-for-av
• PTP-capable switches — boundary clock or transparent clock support reduces PTP timing jitter
• 1 GbE minimum — 100 Mbps switches cannot handle even modest channel counts

Common Pitfalls

• PTP domain mismatch — The single most common failure. Dante uses domain 0; Ravenna often uses domain 127; some broadcast devices use other domains. Devices on different domains cannot synchronize. Check every device's PTP domain setting explicitly — never assume it defaults to the same value.
• Missing SAP/SDP announcements — Some AES67 devices don't transmit SAP by default. If the receiving device can't find the stream via discovery, you must manually input the source stream's SDP session description. Keep SDP files documented for every AES67 source in the system.
• Multicast address conflicts — Two AES67 systems on the same physical network using the same multicast addresses will interfere. Plan multicast address ranges across VLANs and document them.
• Incomplete interoperability testing — Certification to AES67 spec doesn't guarantee interoperability with every other certified device. Always test specific hardware pairs in a lab before production deployment, especially across manufacturers.
• Forgetting IGMP snooping — Without IGMP snooping, AES67 multicast streams flood all switch ports, consuming bandwidth on every device connected to the switch. A 64-channel AES67 stream flooding a 24-port switch wastes bandwidth proportional to port count.
• AES67 over Wi-Fi — AES67 requires consistent low-latency delivery that Wi-Fi cannot reliably provide. Always use wired Ethernet for AES67 transport.