What is AES67?

AES67 is officially titled AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability. The Audio Engineering Society published the first edition in 2013 and issued the AES67-2018 revision after industry experience exposed ambiguities and integration details that needed clearer treatment.

The standard does not create a single closed ecosystem. It defines a technical meeting point where products from different vendors can exchange real-time audio when each product implements the required profile and the system integrator configures the shared network correctly. Compliance is therefore a starting point, not a promise that every optional feature or management function will work automatically.

For procurement and design work, cite the edition being used and verify the manufacturer's conformance statement. AES67-2018 is the revision most current procurement documents reference, but teams should still check the AES standards catalog for amendments, corrigenda, or later editions before freezing a specification.

The standard defines interoperability at selected layers. It does not standardize every operational behavior a user sees.

Before AES67, each Audio over IP platform solved similar problems in its own way. A Dante network, RAVENNA network, Livewire system, or Q-LAN installation could deliver excellent real-time audio inside its own product family, but direct cross-vendor routing often required bridges, conversion hardware, or manual workarounds.

That fragmentation created commercial and operational risk. A facility could become dependent on one ecosystem for routing, clocking, control, and support. Expanding the system meant checking protocol compatibility before evaluating acoustics, workflow, or price. Legacy equipment became harder to retain when a new platform arrived.

AES67 addresses that problem by specifying a common interoperability path for audio transport. It lets a native ecosystem expose selected streams in a form that another AES67-capable ecosystem can receive. This is why AES67 is often described as a bridge: it does not erase the differences between platforms, but it makes controlled movement between them possible.

An AoIP system converts sampled audio into time-stamped packets, sends those packets over Ethernet and IP infrastructure, and reconstructs a continuous audio signal at the receiver. The difficult part is not moving bytes. It is preserving sample timing, channel relationship, and playback continuity while sharing a packet network with other traffic.

AES67 assumes a managed network that can separate real-time media from ordinary data. Switches need sufficient buffering, multicast control, and traffic prioritization. Routers can carry streams between subnets when the design supports multicast routing or unicast flows, but every boundary adds configuration and monitoring requirements.

The media clock is separate from the packet clock. PTP aligns device time, while the audio sample rate defines the media clock. A receiver must recover both the correct sampling phase and a stable stream of samples. Packet loss, excessive jitter, or an unstable clock can produce dropouts even when the average network bandwidth is more than sufficient.

• Sampling converts analog audio into discrete numeric values at a defined rate.
• Packetization adds sequence, timestamp, and payload information so receivers can reconstruct the stream.
• Buffering absorbs normal network variation but increases end-to-end latency.
• Synchronization keeps independent devices aligned to one shared time reference.

AES67 uses IEEE 1588-2008 Precision Time Protocol, commonly called PTPv2, to distribute a common time reference. PTP messages allow devices to compare timestamps and correct for network delay. In audio systems, the resulting time base lets senders and receivers place samples on a shared timeline rather than relying only on local oscillator frequency.

Real-time Transport Protocol, defined in RFC 3550, carries the audio payload. RTP supplies sequence numbers and timestamps that allow receivers to detect missing or out-of-order packets and reconstruct the intended playback time. RTP Control Protocol can provide reception statistics, although control and monitoring choices vary by product.

Session Description Protocol describes the stream before it is received. An SDP document identifies media type, address, port, payload format, packet time, channel mapping, and other parameters. In some systems SDP is exchanged directly; in others it is carried by a discovery or management layer. Because AES67 does not define one universal device-control protocol, SDP handling can differ between implementations.

PTP, RTP, and SDP are standards used by AES67. They are not optional marketing labels.

AES67 uses linear PCM audio so receivers do not need a proprietary codec to interoperate. The common payload forms are 16-bit and 24-bit PCM, often described by RTP payload types such as L16 and L24. A sender and receiver must agree on sample rate, packet time, payload type, channel count, and channel ordering.

Quality of Service matters because audio packets are delay-sensitive but not necessarily high in bandwidth. DSCP markings and queue treatment give PTP and RTP traffic priority over file transfers, backups, and general office data. A VLAN can help separate media traffic, but VLAN separation alone is not a substitute for proper queue design and monitoring.

Multicast lets one sender distribute a stream to several receivers without duplicating traffic for every endpoint. It also introduces risks: misconfigured IGMP snooping, absent queriers, or accidental flooding can disrupt the whole network. Large deployments should plan multicast address ranges, querier placement, group limits, and PTP domains before commissioning.

• Reserve capacity and queue budgets for media traffic.
• Use a documented multicast address plan.
• Verify PTP domain and priority settings across all switches.
• Monitor packet loss, jitter, clock offsets, and IGMP state after deployment.

AES67 does not prescribe one automatic device discovery system. Some products use SAP announcements, some use mDNS or Bonjour, and some rely on a native controller or a third-party orchestration tool. A device can be AES67-capable and still require manual SDP exchange or vendor software to establish a connection.

It also does not define a universal connection-management model, a mandatory user interface, or a complete security architecture. Routing permissions, naming conventions, firmware updates, access control, and monitoring APIs remain product-specific. This is one reason AES67 interoperability often works best when a controller or management layer above the audio transport can coordinate endpoints.

Redundancy is another important boundary. AES67 defines the streaming and synchronization layers, not seamless packet duplication or switchover. Systems that require hitless redundancy commonly add a network redundancy scheme from the surrounding architecture, such as dual links with a media-specific protection method, and the exact behavior depends on the products and network design.

Finally, AES67 does not guarantee interoperability merely because a badge appears on a datasheet. The implementation still has to negotiate compatible parameters, support the required payload format, and behave correctly under the expected PTP and network conditions.

Dante is Audinate's proprietary audio networking technology. Dante AES67 interoperability typically appears as a mode or configuration that lets selected Dante flows exchange audio with other AES67 devices. Native Dante discovery, routing, control, and management remain part of the Dante ecosystem, so an AES67 connection may coexist with a control plane that still requires Dante Controller or another Audinate tool.

RAVENNA is an open technology platform built around standard IP protocols and is strongly aligned with AES67 and SMPTE ST 2110-30. It can carry additional profiles, formats, channel counts, synchronization options, and redundancy models beyond the minimum AES67 interoperability contract. AES67 is therefore a common layer inside a broader RAVENNA deployment, not a complete description of every RAVENNA capability.

Hybrid designs are common. A facility may keep a native Dante estate for stage boxes, amplifiers, and consoles while using AES67 to connect a broadcast core, a RAVENNA production system, or a specific third-party processor. The integration plan should identify which endpoints are native, which are in interoperability mode, where SDP is exchanged, and who owns clock and multicast policy.

Interoperability mode is a system design choice. It does not erase native feature differences.

Start with a written signal and clock plan. List every stream, its direction, sample rate, packet time, channel count, multicast group, source address, receiver, and fallback path. Decide whether the network will use unicast or multicast for each class of traffic, and define how SDP will be conveyed and stored.

Build a PTP domain plan before adding endpoints. Confirm which devices can be grandmasters, how boundary or transparent clocks are handled, what happens if the preferred grandmaster disappears, and whether the network has a stable holdover strategy. Test PTP performance with the same switch configuration and traffic load expected in operation.

Then test interoperability as a system, not as a product demonstration. Confirm channel mapping, nominal gain, sample alignment, stream recovery after a link event, multicast join and leave behavior, and management visibility. Include edge cases such as firmware mismatch, a rebooted grandmaster, an unplugged receiver, and a congested uplink.

Commissioning should leave durable evidence: switch configurations, PTP logs, stream records, test results, and ownership for future changes. AES67 simplifies the transport contract, but it does not remove the need for professional network discipline.

AES67 is used in broadcast facilities, houses of worship, conference centers, stadiums, performance venues, recording studios, and large campus installations. It is especially useful where equipment from several vendors must share audio, where an existing AoIP estate should connect to a new production core, or where a standards-based transport is required for long-term maintainability.

One misconception is that AES67 means every AES67 device can be controlled in the same way. In practice, audio may flow while discovery, routing, labels, and monitoring remain separate. Another misconception is that AES67 is a quality level or a codec. It is an interoperability framework; audio quality depends on the source, sample format, clocking, and network behavior.

A third misconception is that AES67 and ST 2110-30 are interchangeable names for the same standard. They are closely related, but AES67 is an AES audio interoperability standard while ST 2110-30 is a constrained audio component of SMPTE's broader professional media over IP suite. Some technical documents write ST2110 without the space when naming the family. The distinction matters when specifying broadcast workflows, NMOS control, PTP profiles, and conformance levels.