The author is vice president, Telos Products, for the Telos Alliance.
An image from the European Broadcasting Union technical document on N/ACIP called EBU-Tech 3326. It sets out requirements necessary to ensure interoperability between equipment used for transport of contribution-quality audio over IP networks. 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, or “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. N/ACIP, the acronym for Network/Audio Contribution Over IP, is the standard we have today.
Interconnection
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 Session Initiation Protocol, or SIP, 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: [email protected]. In this hypothetical, “examplestudio3” is the registered name of the IP codec that’s connected to a SIP server, which is called “sip.examplaradionetwork.com.”
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: “ip.ad.dr.ess.”
When direct-dialing an SIP codec on a different IP network, 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, the “dialed” address might look like “ip.ad.dr.ess:SIPport.”
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 receives 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.
Compliance
N/ACIP compliance is an important feature for any IP codec; most available models now have it. 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.
Even for less sophisticated IP audio codecs, fixed applications like 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 proprietary connection and negotiation schemes.
At Telos, we designed a SIP-like rendezvous server called the “ZIP Server,” which goes with the Telos Z/IP One IP audio codec. A Z/IP One will automatically register with the ZIP Server, providing presence and NAT traversal services, as well as custom naming, group identity and password protection. The codec user can save other Z/IP Ones’ directory entries locally and see the online status of those “buddies.”
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.
Comment on this or any article. Write to [email protected] with “Letter to the Editor” in the subject field.
