AES67: Two More Ships Set A Course For Interoperability

Two weeks ago in this space, I posted “AES67: Are Two Ships Passing In The Night?,” an interview with Aidan Williams, CTO of Audinate, regarding AES67 and the ramifications of having four separate system discovery options as part of the audio-over-IP standard.

The underlying issue, according to Williams, is that having different system discovery options can lead to problems for end users of AES67-enabled equipment because they expect it to be essentially plug-and-play.

As I wrote at the time:

Understand, Williams and Audinate have settled on one of the four discovery options specified in AES67 and would like to see the whole industry do the same. Other vendors selecting other discovery options undoubtedly would like to see the industry support their selections.

Not surprisingly, I have begun to receive other points of view on the topic. Today, I present the thoughts of Andreas Hildebrand, senior product manager at digital media technology at ALC NetworXand Kevin Gross, founder of AVA Networks, on system discovery and AES67.

Both Gross and Hildebrand were highly instrumental in the development of the AES67 standard. Gross chaired the task group whose work was eventually published as the AES67 standard in September 2013, and Hildebrand was a key member of the working group.

Why wasn’t there agreement on a single system discovery solution?

Gross: The lack of agreement on a discovery solution is simply because there was no discovery system that met all the requirements of the AES67 project. Bonjour, which is natively used by Dante, does not work well on the larger IP-routed networks. SAP, the AES67 option chosen by Audinate for their AES67 implementation, is designated “experimental” and has known performance limitations.

It is important to appreciate that connections can be made without discovery. There is no discovery system for email or the telephone system, and people don’t call those systems broken or incomplete. Third parties, such as Google, have created discovery systems (search engines) for the world-wide web after the fact.

What is your perspective, Andreas?

Hildebrand: The definitions within AES67 are sufficient to achieve fully synchronized data exchange. Discovery is not an absolutely necessary function to establish a connection (and sometimes it is not even desirable to be able to unconditionally discover all available devices and streams). Connections can be established based on the “magic numbers” which are defined by standardized SDP [Session Description Protocol (RFC 4566)] attributes.

AES67 defines no mandatory transport protocol for SDP data — although it offers non-mandatory suggestions in the informative annex. Indeed, it is assumed that the SDP information for an available AES67-formatted stream is being provided, i.e., displayed, by a sending device or the respective system controller, and that this required information can be manually entered into a receiver desiring connection to that stream.

While all known devices implementing AES67 to date offer this possibility, Dante-based implementations have no means for manually reading/entering the SDP data. They solely support SDP exchange through SAP protocol, one of the mentioned protocol options.

Furthermore, discovery is often used in a wider system or application context with different requirements, where one or the other discovery mechanism may have a better fit or, in contrast, may or cannot be used at all. Consequently, we felt it was a wise decision not to make a single discovery protocol mandatory.

OK, so what does AES67 interoperability really mean?

Gross: AES67 is an interoperability mode and should not be compared to a system like Dante. It’s true that AES67 doesn’t “work” like Dante, but that doesn’t make it “broken.”

You add AES67 to Dante, RAVENNA, Livewire, Q-LAN or even AVB to achieve interoperability.

AES67 was not designed to be “plug-and-play” because it is an interoperability mode, not a stand-alone solution.

What it does is to provide the means for synchronized, high performance, low latency exchange of audio data between existing solutions. It was not intended to replace any of these solutions, just to enable them to operate together as part of a larger system.

Leave a Reply

Your email address will not be published. Required fields are marked *