Why Was AES67 Developed?

The AoIP silo problem

Audio over IP solved a physical cabling problem and created a commercial one. Instead of running hundreds of analog or AES3 circuits, an installation could route channels over Ethernet with low latency, flexible capacity, and software-defined connections. The benefit was obvious, but the first generation of protocols was largely proprietary.

Native ecosystems controlled the whole user experience. A controller discovered devices from the same brand, arranged their channels, managed clocking, and presented one coherent workflow. That integration was powerful inside the ecosystem and restrictive outside it. Direct interoperability often required a bridge or a dedicated conversion device.

The result was vendor lock-in by architecture rather than by contract. Once a facility standardized on a console, stage box, amplifier, or processing platform from one ecosystem, replacing one layer could force changes across the rest of the signal chain. Users wanted the benefits of IP without accepting a permanent single-vendor boundary.

AES X192 and the design brief

The AES X192 project was the standards effort that became AES67. Its brief was not to create another competing native ecosystem. The goal was to define a common interoperability mode that existing and future AoIP systems could expose without abandoning their own architecture.

That restraint shaped the standard. AES67 focused on transport, synchronization, media clock behavior, encoding, and stream description. It reused established IT and media protocols instead of inventing a new stack. RTP already offered a proven way to carry real-time media. PTPv2 offered precision timing. SDP provided a structured way to describe sessions.

The X192 work also recognized that interoperability would be incomplete if it ignored timing or format negotiation. Audio can move as packets and still be unusable if receivers reconstruct it at the wrong instant or interpret channels incorrectly. AES67 therefore defined a narrow but technically meaningful meeting point.

AES67-2013: a shared contract

AES67-2013 gave manufacturers a public target. A product could remain native to Dante, RAVENNA, Livewire, or another system while also supporting selected AES67 streams. The native protocol could continue to handle discovery, routing, control, and premium features. AES67 provided the audio path between otherwise separate domains.

For integrators, the first release changed procurement conversations. Instead of asking only whether two systems were identical, a project could ask whether both supported a compatible AES67 mode for the required sample rate, packet time, channel count, and timing configuration. That did not eliminate integration work, but it gave the work a common vocabulary.

For manufacturers, AES67 offered a way to reduce customer friction without opening every proprietary advantage. Supporting the standard could make a product easier to place in mixed estates while preserving the native ecosystem's management, redundancy, and value-added features.

AES67-2018 and the maturing ecosystem

Real deployments reveal details that a first edition cannot fully anticipate. AES67-2018 revised the standard after manufacturers, integrators, and testing organizations gained experience with multi-vendor systems. The revision became an important reference for products and specifications that needed clearer expectations around the common interoperability profile.

A revision does not make every implementation identical. It gives product teams and system designers a more stable basis for conformance statements and test plans. Teams still need to verify which optional capabilities a product exposes and how it handles connection setup, stream descriptions, PTP configuration, and failure recovery.

The move from AES67-2013 to AES67-2018 also reflects the broader maturity of AoIP. Standards discussions shifted from proving that IP audio could work to making multi-vendor systems manageable, diagnosable, and predictable at scale.

Always confirm the exact edition and amendments cited by a procurement or product document.

What the design intentionally left open

AES67 is powerful partly because it does not attempt to standardize every part of an audio network. It leaves discovery, connection management, security policy, device naming, and redundancy to existing ecosystems or higher-level systems. That choice allows native platforms to keep their strengths and lets vendors implement AES67 without rebuilding their entire product architecture.

The tradeoff is that two AES67 devices may carry audio successfully while offering completely different user experiences. One may advertise streams automatically, one may depend on a controller, and a third may require manual session descriptions. This is why integration projects need a control-plane inventory as well as a stream inventory.

The standard also does not guarantee audio quality by itself. It defines how PCM audio is transported and synchronized, not how a microphone is placed, how a converter performs, or how a network is tuned. Interoperability and sound quality are related but separate engineering responsibilities.

How AES67 changed the ecosystem

The strongest evidence of AES67's value is that interoperability became an expected product attribute. Major AoIP ecosystems now describe their relationship to AES67, and many products expose an interoperability mode rather than treating competing protocols as a complete barrier.

This changed competition from simple protocol exclusion to implementation quality. Vendors can compete on latency, channel density, control, redundancy, conversion quality, form factor, support, and integration depth while still offering a common audio path. Customers gain leverage because a single device no longer has to be replaced simply to connect one new subsystem.

AES67 also helped prepare the industry for ST 2110. Broadcasters wanted audio transport that could participate in an all-IP production architecture, and the AES67 body of work provided an important technical foundation for ST 2110-30. The standards remain distinct, but their shared assumptions made the transition easier.

Value for integrators and system owners

Integrators gain a defensible way to connect mixed equipment. They can preserve a working native network, introduce a new vendor for a specific function, or create a migration path without replacing every endpoint at once. The audio transport can be standardized while the control and operational layers evolve on a separate schedule.

System owners gain bargaining power and lifecycle flexibility. A standards-based boundary makes it easier to compare products, retain useful legacy equipment, and replace one subsystem without rewriting the complete signal chain. It also creates a clearer test surface for acceptance and troubleshooting.

Those benefits depend on disciplined design. AES67 interoperability does not eliminate the need to document SDP sessions, multicast addresses, PTP domains, QoS policy, naming conventions, and support ownership. The standard provides the contract. The project team still has to make the contract operational.

Value for OEMs and product teams

For an OEM, AES67 can reduce the cost and time required to connect a product to a broader professional audio market. Instead of building a complete native ecosystem, a manufacturer can implement a defined interoperability path and concentrate investment on its own differentiation: DSP, acoustics, conversion, industrial design, reliability, or workflow.

The standard also gives product teams a shared test vocabulary. An OEM can specify supported sample rates, packet sizes, channels, PTP behavior, and stream-description handling, then test against representative third-party devices. A clear compatibility matrix is more useful than a general claim of AES67 support.

The commercial opportunity is strongest when the product fits a specific role in a hybrid system. A network bridge, stage interface, amplifier, processor, or recorder can add value by behaving predictably at the AES67 boundary while offering a differentiated native feature set above it.

What AES67 does not solve

AES67 does not make discovery and control universal, and it does not guarantee that every native feature can cross a vendor boundary. Meters, presets, gain sharing, redundancy state, device identity, and firmware workflows may still be proprietary. A successful integration plan must state which functions are audio streams and which remain outside the standard.

It also does not protect a poorly designed network. Incorrect QoS, uncontrolled multicast, unstable PTP, insufficient switch buffers, and weak monitoring can defeat an otherwise compliant implementation. Engineers should treat interoperability testing and network commissioning as one process.

Finally, AES67 is not a guarantee of future investment protection by itself. It is a durable standard foundation, but longevity also depends on product support, documentation, spare parts, security updates, and the willingness of vendors to maintain their interoperability modes. Standards reduce risk when the surrounding engineering and commercial commitments are sound.