AES67 compatibility and compliance are not one in the same. This short guide explains the difference, and why you should care.
One of our goals at the Telos Alliance is to further the adoption of AES67, the standard for audio-over-IP designed to allow interoperability between various IP-based audio networking systems, like our own Livewire+ AES67, Ravenna, Q-Lan, and Dante. So we hear the terms AES67 compliance and AES67 compatibility thrown about a bit, often with reckless abandon. And while they may sound the same, the difference between compliance and compatibility is huge. Here, we’ll spell out those differences and explain why it matters.
AES67, like all standards, can be minimally implemented. But when standards are minimally implemented, well, they minimally get the job done. It’s possible to achieve a level of audio interoperability using AES67, yet still not fully comply with the standard. Simply put, compliance means that every single aspect of the AES67 standard is met. ‘Compatible’ means some of the standard is complied with. There is a big difference.
One aspect of AES67, for example, calls for Unicast mode using SIP. This could be the exchange of audio between city pairs using AES67. Normally, city-to-city connections are created using a wide area network where multicast streams normally found in AoIP aren’t likely to be supported. If your audio network’s native AES67 protocol or your specific gear doesn’t support Unicast, you might not be able to move audio back and forth without purchasing additional gear.
A full implementation of AES67 is required at the protocol level and by the manufacturer of the gear you are purchasing to be assured of Unicast mode using SIP.
"AES67, like all standards, can be minimally implemented. But when standards are minimally implemented, well, they minimally get the job done."
—Marty Sacks, Vice President of Sales, Support, and Marketing, Telos Alliance
So why don’t all AES67 protocols and manufacturers support Unicast mode using SIP? Because implementing it into the standard is fairly challenging. But it’s important. Despite the fact that it is hard work, we know from our experience with IP codecs that it’s a capability that our customers want. Unfortunately, in an effort to stamp their products with AES67 with the least amount of effort, some manufacturers and protocols take the shortcut and leave it out altogether. Those protocols and manufacturers are no longer AES67 compliant because they did not comply with this part of the standard.
Unicast is just one instance of an AES67 standard that isn’t complied with by all manufacturers and protocols. There are others. One AoIP protocol, for example, dynamically assigns IP addresses to its network-connected devices in AES67 mode. This is analogous to your mobile number changing every time you power it up. As you can imagine, this can wreak havoc on other network devices intending to share audio using AES67.
There is no AES67 task force out there policing whether or not protocols and gear are fully compliant or merely compatible. It’s a good idea to confirm AES67 compliance before you choose your protocol and equipment. This will give you the best performance both now and in the future.
Did you know that Telos Alliance’s Livewire+ AES67 protocol is inherently fully AES67 compliant? That means you get all the functionality that the standard specifies. Plus, Livewire+ AES67 goes beyond AES67’s audio interoperability to add GPIO, program associated data (PAD), and advertising/discovery.
For more content about getting up to speed with AoIP and AES67, read these blog posts:
Still want to know more? Download our AoIP eBook!