Difference between AES67 & ST 2110-30

AES67 and ST 2110-30 are related because ST 2110-30 references the same audio transport family. The practical difference is scope. AES67 answers a narrow interoperability question: can this sender and receiver exchange real-time audio using a common set of IP media rules? ST 2110-30 answers a broader production question: how should audio be carried as one essence among video, ancillary data, and control in a managed broadcast system?

That difference is why an AES67 stream can be acceptable in a conference system without using NMOS or conforming to a specific broadcast level. The same stream may fail an ST 2110-30 conformance requirement if the sample rate, packet time, channel count, or timing profile does not match the required operating level.

In simple terms, AES67 is a compatibility layer across AoIP ecosystems. ST 2110-30 is a profile within a broadcast architecture. The distinction is not about which standard is better. It is about choosing the contract that matches the job.

AES67 is an AES standard. Its primary purpose is audio interoperability, with use cases that include live sound, installed audio, conferencing, recording, and broadcast. It is deliberately broad enough to work with multiple native AoIP systems and multiple control or discovery approaches.

ST 2110 is a SMPTE standards suite for professional media over managed IP networks. The audio part, ST 2110-30, is designed around the needs of television production, playout, outside broadcast, and other facilities where independent audio, video, and data essences must be synchronized and routed at scale.

That design center changes the questions a system architect asks. AES67 projects often start with whether two products can talk. ST 2110 projects start with the facility-wide clock, network, discovery, control, redundancy, and timing model, then place audio into that model.

Both standards depend on PTPv2 for precision timing, but the profile and operating assumptions matter. AES67 can be used with PTP default-profile behavior or with the AES67 PTP Media Profile, depending on the devices and deployment. The goal is a stable common time base that lets receivers reconstruct samples at the correct instant.

Broadcast ST 2110 systems commonly use the SMPTE ST 2059-2 timing profile, which was written for professional media facilities and is intended to coordinate the wider ST 2110 environment. ST 2059-2 is not simply a label on a PTP clock. It affects domain planning, message rates, grandmaster behavior, and validation procedures.

A product that works in a small AES67 network will not necessarily join a large ST 2110 PTP domain without configuration. Integrators should verify profile support, grandmaster capability, boundary-clock behavior, and fallback rules before mixing ecosystems. A technically valid conversion can still create a fragile clock plan if ownership and monitoring are unclear.

AES67 defines a useful baseline and leaves optional operating modes to the implementation. A common interoperability baseline is 48 kHz audio with 1 ms packet time and up to eight channels per stream. Other sample rates, packet times, and larger channel counts can appear in AES67 products when the sender and receiver agree.

ST 2110-30 narrows the operational combinations through conformance levels. Level A works at 48 kHz with 1 ms packet time and up to eight channels. Level B keeps 48 kHz and up to eight channels but uses 125 us packet time for lower latency. Level C also uses 125 us packets and raises the channel count substantially.

The X designations extend the level families to 96 kHz operation. Exact limits should be confirmed against the current standard and product documentation. The important system lesson is that packet time is not just a latency preference. It changes packet rate, switch load, buffer requirements, jitter sensitivity, and the number of simultaneous flows a device can support.

• 48 kHz is the common broadcast and AES67 baseline.
• 1 ms packets are easier on the network but add buffering latency.
• 125 us packets reduce latency and increase packet rates.
• Higher channel counts and sample rates multiply bandwidth and device load.

Do not assume that two devices support every level merely because both say AES67 or ST2110.

AES67 does not fully define how devices discover one another, register available streams, or establish connections. Implementations may use session announcements, mDNS, vendor controllers, manual configuration, or another management layer. Because the audio transport is standardized, interoperability can succeed even when the control experience differs from device to device.

ST 2110 systems commonly use the AMWA NMOS family to provide a common registration and control model. IS-04 supports discovery and registration, while IS-05 supports connection management. Other NMOS specifications can expose capabilities, status, events, or security. NMOS is not the audio transport itself; it is the surrounding fabric that makes large multi-vendor systems easier to operate.

This is one of the clearest differences between a basic AES67 integration and a broadcast-grade ST 2110 deployment. AES67 can connect streams while leaving labels, routing, and monitoring fragmented. ST 2110 architecture expects those functions to be designed deliberately, often with NMOS, orchestration, and facility-wide identity and access policies.

ST 2110-30 conformance is a promise about a defined operating point, not merely a promise that audio can pass over IP. A conforming sender, receiver, or device must satisfy the applicable level and profile requirements. That makes commissioning more predictable in large systems where many vendors and many streams must coexist.

The broadcast suite also considers timing relationships beyond audio alone. Separate video, audio, and ancillary streams can be routed independently while remaining synchronized to the same facility time base. This separation is valuable for multilingual audio, captions, metadata, and flexible production workflows.

AES67 interoperability and ST 2110-30 conformance can overlap in a product, but one does not automatically prove the other. Procurement should ask for the exact AES67 profile, ST 2110-30 level, PTP profile, NMOS support, redundancy behavior, and tested interoperability matrix rather than relying on broad claims.

AES67 does not define one universal seamless redundancy mechanism. Some native platforms provide their own protection scheme, and AES67 interoperability may not expose every redundancy feature to the other ecosystem. The surrounding network and product design determine whether a failure produces a brief interruption, a stream reconnection, or hitless recovery.

ST 2110 facilities often combine the media suite with network protection standards and a carefully designed dual-path topology. The exact architecture still depends on the equipment. Redundancy has to be tested as an end-to-end service, including failure detection, switchover time, stream continuity, clock stability, and operator visibility.

For both standards, redundancy must be designed before the first live event. A second cable or a second switch is not enough if PTP has one vulnerable grandmaster, if multicast joins are not clean, or if management tools cannot identify which path failed.

Choose AES67 when the main requirement is interoperability between audio ecosystems, when a hybrid estate must connect selected streams, or when a product needs a standards-based audio transport without committing to a full broadcast control architecture. Also choose it when the surrounding products already define discovery, management, and redundancy in a way the project accepts.

Choose ST 2110-30 when audio must become part of a managed broadcast fabric with video, NMOS control, ST 2059 timing, defined conformance levels, and facility-scale orchestration. The decision should be driven by the operational model, not only by a datasheet. A live sound system and a national broadcast facility can both use IP audio while needing very different guarantees.

Many projects use both. AES67 can connect non-broadcast equipment or preserve an existing AoIP domain, while ST 2110-30 carries the production core. Document the boundary between them, including sample-rate conversion, PTP profile conversion, control translation, and failure behavior. The boundary is where most integration risk lives.