Most Popular Articles
IP Audio Begins Interoperability Journey
Connection management is the means by which media streams are established between a sender and one or more receivers.
Connection management for all unicast streams shall be done via Session Initiation Protocol (SIP). All receivers must support unicast streams, and all receivers must support SIP. All devices are SIP user agents with an associated SIP URI (Uniform Resource Identifier). URIs are learned through discovery or by other means such as static configuration.
Typically, SIP is used with the assistance and participation of SIP servers, and different types of servers perform different tasks on an SIP network. They can be located anywhere on the network that is reachable by other participants. However, there is also a server-less mode that can be used to perform connection management between user-agents in a direct peer-to-peer fashion. This mode is used in smaller systems where the SIP servers would provide minimal benefits. In order for this to work, there must be a means by which the caller can learn of the network information (i.e., IP address) of the callee. This can be done through discovery, manual configuration, or higher-layer protocols. In the server-less mode all SIP messages must be sent directly to the targeted agent as opposed to a SIP server, and an agent operating in this mode must respond to such requests.
Multicast connections may be established without the use of a connection management protocol. A receiver is not required to make a direction connection with the sender. Instead, a receiver obtains a session description of the desired connection using discovery, and then uses IGMP to inform the network of its desire to receive the stream in question.
After reaching this point in the article, you may have one of two questions: either you want to know if AES67 will affect your current system in some fashion; or alternatively, if it will affect future purchase decisions.
According to its website, Axia and the other companies in the Telos Alliance have been involved with AES-X192 since its inception. I communicated directly to get their thoughts on AES67. "We finally have a standard for AoIP audio transport in AES67 - and that's great!" said Marty Sacks, VP of Axia Audio. "Ultimately, the goal is for every studio audio device to click together with CAT-5 and share audio. But along with that shared audio, there's a whole world of other functionality that broadcasters expect, like device start/stop functions, monitor mutes, on-air tallies, the ability to control peripherals from the console, the ability to know when an audio source is live and ready for air, the ability for playout systems to control fader on/off functions and more. Those are functions that AES67 alone doesn't provide for. AES67 is a great start toward a unified standard, but when the first AES67 devices hit the marketplace, they will also need to support this additional functionality, no matter whose system they use, in order to provide an integrated control experience for the user - otherwise they're going to be no better than AES3 streams, with serial GPI cables running alongside."
I also communicated directly with Wheatstone for its thoughts regarding AES67. "Wheatstone was very involved in the AES-X192 group that developed the new AES67 standard, which gives us that very important first step of transport interoperability," said Andrew Calvanese, Wheatstone VP of engineering. "We are evaluating our WheatNet-IP system so that our customers can take advantage of AES67 but with an eye on a much wider goal of total interoperability that includes discovery and control. AES67 is the first step in what we hope will lead to a totally interoperable environment that includes not only transport, but the means to control and discover all devices and functions within the network. We are working with other engineering teams to standardize on the control and discovery protocols that can make that happen at an overall, interoperable level."
Logitek intends to be compliant with the AES67 standard by spring of 2014; It will make the necessary development work this winter and plan to have that project completed by April.
To reiterate, AES67 is simply a means to give (formerly) disparate AoIP systems a way to talk to one another, using existing protocols; no new protocols have been developed in this process. It's too early to tell what impact AES67 will have in broadcasting, but the adoption of standards in technology usually provides benefits down the road.
Irwin is RF engineer/project manager for Clear Channel Los Angeles. Contact him at email@example.com.
Acceptable Use Policy blog comments powered by Disqus
[an error occurred while processing this directive]
Today in Radio History
The history of radio broadcasting extends beyond the work of a few famous inventors.
Read each issue online in our Digital Edition Format in your Web browser.
EAS Information More on EAS
The feed provides feeds for all US states and territories.
Need a calendar for your computer desktop? Use one of ours.
Information from manufacturers and associations about industry news, products, technology and business announcements.
Browse Back Issues[an error occurred while processing this directive]
Also in the December Issue
- Local Radio Spotlight: Koser Radio Group
- Trends in Technology: Streaming Audio Update
- Contest Rules Rewrite and EAS Issues
- Embedded Computing, With a Side of Pi
- Field Report: TASCAM US-366