author is vice president, Telos Products, for the Telos Alliance.
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.”
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.
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
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.
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
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
SIP server is used, the “called” IP codec is registered with its SIP server,
while the “calling” IP codec “dials” an address like this: firstname.lastname@example.org. 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.”
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”)
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.
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.
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.
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.
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.
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.
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.
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.
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
on this or any article. Write to email@example.com
with “Letter to the Editor” in the