IP-Audio Connections Using N/ACIP

Radio engineers are turning to IP-based infrastructure and connectivity for streaming audio between studios and other sites. Indeed, as ISDN and, more recently, even "real" POTS connections are disappearing, we're turning to the same technology we use for e-mail, web, and file transfer - Internet Protocol - "IP."

Just as we've enjoyed interconnection standards for POTS equipment, and, later, ISDN equipment, we want a basic connection standard for IP-based audio transmission, as well. N/ACIP, which is the acronym for "Network / Audio Contribution over IP", is the standard we have today. While the N/ACIP specifications make up a 17 page document (EBU - TECH 3326), the outcome is that IP-Audio codecs complying with the requirements of N/ACIP will connect with each other and pass two-way audio between themselves.

At its foundation, N/ACIP employs SIP (Session Initiation Protocol) to negotiate which codec to use. SIP is the framework for setting up and supporting the connection and negotiating its parameters - negotiating what you want to exchange. And while most SIP connections for voice calls are handled by a SIP server (on-site or off-site), N/ACIP IP-audio connections are possible with or without a SIP server.

If a SIP server is used, the "called" IP codec is registered with its SIP server, while the "calling" IP codec "dials" an address like this: examplestudio3@sip.exampleradionetwork.com. In this example, is the registered name of the IP codec that's connected to a SIP server called.

It's also possible for SIP to negotiate call setup parameters when making a direct connection, without the benefit of a SIP server. Indeed, the N/ACIP standard specifies that SIP, as implemented in a compliant audio codec, will work in the absence of a SIP server. To connect with another codec via a direct SIP call, the "calling" IP codec "dials" an address like this: If a direct-dialing a SIP codec on a different IP network, then the appropriate port must be forwarded through the NAT router on the remote, "dialed" end.

The standard SIP port of 5060 is assumed, and usually does not need to be specified. If a different port had been designated, then the "dialed" address might look like.

Port forwarding is an important technique to understand; it's the sure way to traverse NAT routers and connect directly to the end device of interest. Port translation is another handy technique to access different but similar devices across a NAT router. The one risk to using port forwarding from the Public Internet into your LAN is possibly allowing malicious activity to affect your desired service. "Script kiddies" - or worse - are often trying port 5060 to gain access to otherwise unprotected SIP servers and SIP devices.

While the N/ACIP standard assists disparate IP-audio codecs to connect with each other, there are several aspects of an IP-audio connection that are not addressed, yet may be important to the user. For example, an N/ACIP call assumes that the IP link has enough bandwidth and low jitter. There is nothing within N/ACIP that addresses negotiation of codec bit rates or receive buffer size. N/ACIP codecs will compare their list of codecs during the connection setup and agree on the "best" codec that both units have. This may not be the codec that you really want to use. Moreover, there is no factoring of the IP path's bandwidth, jitter, or packet loss into the codec negotiation.

N/ACIP compliance is an important feature for any IP codec to have - and most models available now do. However, there's a good chance you'll never actually use the specific inter-brand compatibility that N/ACIP offers. This is because several IP codec makers have developed connection protocols that are more sophisticated, more reliable, and more flexible than the basic N/ACIP features. And even for less sophisticated IP-audio codecs, fixed applications, such as STL or other full-time program links, are often manually configured with like equipment at each end, and don't need the connection convenience that N/ACIP offers. Still, understanding what N/ACIP can do for your codecs will give you insight into how they connect over IP. Moreover, you might find better ways to keep your IP-audio devices working together smoothly.

Going beyond N/ACIP's connection functionality, several IP audio codec makers offer their own, proprietary connection and negotiation schemes. At Telos we designed a SIP-like rendezvous server called the "ZIP Server". It's free to use with the Telos Z/IP ONE IP-audio codec. A Z/IP ONE will easily and automatically register with the ZIP Server, providing presence and NAT traversal services, as well as custom naming, group identity and password protection. A Z/IP ONE user can save other Z/IP ONEs' directory entries locally and see the online status of those "buddies". Connecting to any "buddy" is as easy as "highlight and click". The ZIP Server will relay audio data for the call if the NAT router at either end of an IP connection will not allow a peer-to-peer handoff during the connection setup.

Other IP-audio codec makers offer their own schemes to assist with presence and connection setup for their codec models. These schemes are not generally interoperable with other brands. However, each scheme tends to offer more functionality and some account for more path factors than does the N/ACIP approach.

Earlier I stated that N/ACIP compliance is important for any IP codec to have. It's important, also, to understand the objectives offered by N/ACIP's assistance to IP-audio codec use. For basic and effective cross-brand connectivity, N/ACIP is a functioning standard with wide acceptance. For comprehensive and, perhaps, automatic control of IP-audio codecs and their communication over a variety of IP paths, investigate various manufacturers' approaches to optimized and reliable point-to-point audio streaming.

Telos Alliance has led the audio industry’s innovation in Broadcast Audio, Digital Mixing & Mastering, Audio Processors & Compression, Broadcast Mixing Consoles, Audio Interfaces, AoIP & VoIP for over three decades. The Telos Alliance family of products include Telos® Systems, Omnia® Audio, Axia® Audio, Linear Acoustic®, 25-Seven® Systems, Minnetonka™ Audio and Jünger Audio. Covering all ranges of Audio Applications for Radio & Television from Telos Infinity IP Intercom Systems, Jünger Audio AIXpressor Audio Processor, Omnia 11 Radio Processors, Axia Networked Quasar Broadcast Mixing Consoles and Linear Acoustic AMS Audio Quality Loudness Monitoring and 25-Seven TVC-15 Watermark Analyzer & Monitor. Telos Alliance offers audio solutions for any and every Radio, Television, Live Events, Podcast & Live Streaming Studio With Telos Alliance “Broadcast Without Limits.”