iStockphoto/da-kuk The last three years — following the ratification of the AES67 standard — have brought about an amazing transformation in the broadcast industry. Audio over IP is on everyone’s lips. With no exaggeration, AoIP is a juggernaut racing through our industry at a pace approaching that of wildfire.
As the first company to develop AoIP for broadcast, the Telos Alliance is gratified to see our idea so widely adopted. And now, we have front-row seats to a whole new phase of this as the television industry firmly jumps into AoIP with its adoption of AES67. This is very cool, and we’ve only just begun to see the impact that AoIP will have in TV with its more complex workflows.
As you can imagine, we have many conversations each day with clients across the world seeking to understand more about AoIP and specifically how they can use AES67 in their facilities. There are two topics that we’re frequently being asked about right now:
AES67 COMPLIANCE VS. COMPATIBILITY
We hear the terms AES67 compliance and AES67 compatibility raised during countless discussions. Sound like the same thing, right? Not so. Here’s the difference and why it matters to you:
Just as the Telos Alliance created Livewire and Livewire+ (our Livewire AoIP plus AES67), other companies have created their own versions — or protocols — of AoIP with AES67, e.g. Ravenna. Each protocol that has implemented AES67 has not done so in the same way. This is because AES67, like all standards, can be minimally implemented and still “sort of” do the job. In other words, it is possible to achieve some level of audio interoperability under AES67 and yet still not fully comply with the standard.
This is what is meant by compliant vs. compatible. Simply put, compliance means that all aspects of the AES67 standard are met; compatible means some of the standard is complied with. There is a big difference.
For example, one aspect of the standard calls for Unicast mode using SIP. Such a usage could be the exchange of audio between city pairs using AES67. City-to-city connections are normally created using a wide-area network where the multicast streams (normally found in AoIP) are not likely to be supported. If your audio network’s native AES67 protocol or your specific gear does not support Unicast, you might not be able to move the audio back and forth without purchasing additional gear. To be clear, 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.
Why don’t all AES67 protocols and/or manufacturers provide Unicast mode using SIP, you ask? It is because this part of implementing the standard is pretty challenging. We know it’s hard work, but we also know from our experience with IP codecs that many of our customers will want this capability. Still, some manufacturers and protocols will “short-cut” and leave it out. Now, officially speaking, those protocols and manufacturers are no longer AES67-compliant. Because there are no AES67 police, you’d be wise to confirm compliance and receive assurances that your protocol and/or vendor is fully compliant to assure best performance now, and in the future.
Unicast is just one example where something specified in the AES67 standard is not complied with. There are others. For example: One AoIP protocol 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 with other devices intending to share audio on the network using AES67.
A FACILITY OVER IP
Naturally, once people catch on to the vision and capabilities of audio over IP, they want their entire facility from that point forward to take full advantage of the technology. In our 10+ years helping people first begin to consider AoIP and then ultimately adopt it, we’ve had many discussions to encourage these folks to consider the entire process of converting or creating their AoIP facility.
Our customers have helped us to understand that it’s important to think through certain aspects of AoIP usage (or workflow) prior to choosing a baseline protocol and beginning the conversion. Choices made at this earliest stage in the adoption will affect the future capabilities in a way we’ve never seen before in broadcast technology. This is due to the beauty and functionality of fully interconnected gear. Perhaps the biggest decision to make in the beginning is the determination of a baseline protocol one — that is at the foundation of the network.
Here’s why: A baseline standard (be it Livewire+ or another) will define a master set of capabilities over and above the most basic audio interoperability made possible by AES67. Aspects like Advertising/Discovery, GPIO (General Purpose I/O, also called “tally” or contact closures) and Program-Associated Data (PAD) are all defined by the baseline protocols, but these are not in AES67. For example, if you chose a baseline AoIP protocol that does not support GPIO, you may not be able to easily start and stop external gear. In other words, for the announcer to be able to start the next song or commercial using the buttons on the console, GPIO must be supported. Needless to say, this is a major consideration.
So, in total, the design of a facility over IP will need to take into account the anticipated need for not only audio interoperability, but also advertising/discovery, GPIO and PAD amongst all the devices that will make up the core of the network. Sure, AES67 will assure some level of audio interoperability, but don’t assume that your workflow will automatically be supported.
Like all equipment-buying decisions, careful consideration of how you will use your gear will help you make choices you’ll be happy living with for a long time.
The author is vice president of sales, support and marketing for the Telos Alliance.
