Does the AES67 standard guarantee interoperability for realtime Audio over IP?Mikael Vest, sales director, NTP Technology, explores the question
The purpose of any new technology is to provide advanced capabilities to users. Standardisation has proved in many cases the best way to develop new technical systems in a coherent manner. As a general rule, it ensures technical functionality and specifications are in place for equipment to work in the real world where equipment comes from a multiplicity of manufacturers. Standardisation is in most cases driven by organisations supported on an industry-wide basis by manufacturers, service-providers, research facilities and their various customers.
But there is another important factor influencing technical progress. Many manufacturers conduct research and develop new technology on their own initiative. In some cases this technology is made available to other manufacturers under license and in that way becomes a de facto standard.
So where does this leave us with regards to realtime audio over IP? The enabling technology has been available in various forms for Ethernet Layer 2 since Park Audio’s CobraNet was introduced in 1996, followed by other proprietary formats such as Livewire from the Axia Audio division of Telos, Q-Lan from QSC and WheatNet-IP from Wheatstone. Audinate’s Dante appeared in 2006 and ALC’s Ravenna in 2010, both based on IP Layer 3.
The only actual standard until recently has been the Audio Video Bridging (AVB) set of recommendations promoted by the Institute of Electrical & Electronics Engineers in cooperation with the AVnu alliance. The IEEE’s AVB is based in IP Layer 2.
More recently, the AES67 standard has been developed by a task group within the Audio Engineering Society. This is based on Layer 3 standards like IEEE1588 for peer-to-peer distribution and clocking via the network interface, and a number of other well defined standards for audio packet formatting and so on.
However the very important service definition information contained in service definition packages (SDPs) specifies the setting of AES67 devices in the network in order to be able to have these connected in a service. This information is allowed to be a number of different formats which are not mutually compatible.
The current situation is that manufacturers which initially offered AoIP designs based on Ravenna have chosen one variant of the SDP which is coherent with the Ravenna specification. Now, with Dante also supporting AES67, the SDP format chosen is in accordance with one of the other options in AES67. That option is more in line with the Dante implementation but in practice these two systems are not compatible in a real-life AoIP network. Similar issues exist for other proprietary formats that have moved towards AES67 compliance.
So is interoperability for realtime AoIP systems compliant to the AES67 standard guaranteed? The answer is no!
The only way to proceed towards the goal of true standardisation in this context is to continue the preliminary work so that users can benefit from the full potential of an effectively universal AoIP networking system.
8.B51
