N/ACIP: Simplifying Codec Connections

Publish date:

N/ACIP: Simplifying Codec Connections

Mar 1, 2010 12:00 PM, By Doug Irwin, CPBE AMD

Can your box play nice with dozens of other codecs?

Image placeholder title

As IP codecs become more and more familiar around the broadcast plant, and their use becomes more commonplace, it's only natural to expect that one day you might want to make an audio-over-IP connection with some entity that has a different brand of codec than you do. This was certainly a selling point with some ISDN codec manufacturers, and now is becoming one with IP codec manufacturers as well.

In 2006, some German vendors and broadcasters put forth the idea that interoperability between IP codecs was desirable, and soon thereafter the EBU formed a group (N/ACIP) to establish audio compatibility over IP standards with two main objectives. The first was interoperability of devices from different manufacturers, and the second was to provide guidelines to broadcasters for the introduction of audio contribution over IP. I'll investigate what N/ACIP means and how it can benefit us.


The interoperability standards in N/ACIP are based on two different aspects of codec operation. First, for a codec to meet the standards, it has to include at minimum the following codec algorithms: G.711, G.722 and MPEG-1/2 layer II. In addition, the unit in question must also support plain old PCM (not the AES/EBU data stream we are accustomed to). For the MPEG Layer II codec, many bit-rate/sampling-rate combinations are mandatory, as seen in Figure 1.

Bit Rate (kb/s)Sampling Rate 16kHz*24kHz*32kHz48kHz 32M 40M 48M 56M 64M 80MM 96MM 112MM, JS, SM, JS, S 128MM, JS, SM, JS, S 160M, JS, SM, JS, S 192�M, JS, SM, JS, S 224SS 256�SS 320Frame Too LargeS 384�Frame Too LargeS * MPEG-2 � � � � �� Optional for portable equipment M = mono, JS = joint stereo, S = stereo Figure 1. N/ACIP bit-rate/sampling-rate combinations for Layer II. Mandatory rates are shown in bold.

In addition to the required codecs and PCM, there are recommended codecs: MPEG-4 AAC, MPEG-4 AAC LD, and MPEG-1/2 Layer III with various bit-rate/sampling-rate combinations, as seen in Figure 2.

Bit Rate (kb/s)Sampling Rate 16kHz*24kHz*32kHz48kHz 32MM 40MM 48MMMM 56MMMM 64MMMM 80MMM 96MMM 112MM, JS, SM, JS, S 128MM, JS, SM, JS, S 160M, JS, SM, JS, S 192�M, JS, SM, JS, S 224SS 256�SS 320Large FrameS * MPEG-2 � � � � � Optional for portable equipment M = mono, JS = joint stereo, S = stereo Figure 2. N/ACIP bit-rate/sampling-rate combinations for Layer III, AAC and AAC-LD. Mandatory rates are shown in bold.

Another one of the interoperability standards describes the means by which the packets are built up by the encoder. The N/ACIP compliant device must use RTP (real-time transport protocol), which uses UDP for its transport method. User Datagram Protocol (UDP) is the connectionless transport method used in IP, as opposed to TCP, which is the connection-oriented transport method in IP. Whereas TCP allows for the retransmission of lost packets, UDP does not; any error correction methodologies (such as forward error correction) must be implemented by the application running on top of UDP. A UDP data stream has less overhead than TCP, so in that sense at least, it provides a more efficient use of available bandwidth.

-- continued on page 2

1 2 3 Next

N/ACIP: Simplifying Codec Connections

Mar 1, 2010 12:00 PM, By Doug Irwin, CPBE AMD

Can your box play nice with dozens of other codecs?

Another aspect of the operation of a N/ACIP-compliant codec is the use of SIP to establish a session between two endpoint devices (i.e., two audio-over-IP codecs).


What is SIP? Let's take a look at SIP and see why its use makes sense, along with some particulars about how it works.

SIP stands for Session Initiation Protocol. It's an application layer protocol that is agnostic about what transport layer it runs on top of � for example it will work with either UDP or TCP. The job of SIP is the creation, modification (if needed) and termination of sessions between two endpoints � which would be two IP codecs. By the way, in the parlance of SIP, these endpoints are also known as UAs (user agents).

Consider this common scenario, which should clarify the advantage to using SIP.

Say you are a news reporter, and your typical means of communicating with your HQ is by way of an IP codec that can work over wired networks or Wi-fi networks. As you move around and connect to various networks, your IP codec will necessarily have to get a new IP address every time (likely by way of DHCP). For HQ to initiate a connection with you, it would have to have an updated IP address each and every time you moved.

This would be like using a cell phone that had its number change every time you got into a different cell. Not very practical � you'd be tough, if not impossible, to reach.

With SIP, your codec gets a URI (Uniform Resource Identifier). This looks and sounds very much like a Web address, probably because SIP is modeled on HTTP. The format of the URI is SIP:username@domain.com. For our example then, say our news reporter has a URI of SIP:newsguy@bignewsnetwork.com. Every time newsguy gets on a different network, his codec registers its new IP with a registrar server that functions very much like a DNS server. (HQ could very well be hosting its own SIP server, which, among other things, performs the registrar server duties. This server would live on the public side of a firewall on the network.) When HQ wishes to contact newsguy, it does so by dialing his URI on the codec at HQ. SIP uses the updated information in the registrar server to come up with the actual IP.

Aside from putting the two endpoints in contact with one another, SIP also sees to it that they agree on the codec to be used, thus assuring that they actually do pass audio from one end to the other. After the session is established, SIP goes idle; the two endpoints connect directly with one another for the actual passage of the payload data. Once the session is over, SIP is also used to tear down the link and effectively end the communications.

-- continued on page 3

Previous 1 2 3 Next

N/ACIP: Simplifying Codec Connections

Mar 1, 2010 12:00 PM, By Doug Irwin, CPBE AMD

Can your box play nice with dozens of other codecs?


So, to review, the standards for N/ACIP interoperability are just these: each device must use RTP over UDP in building the packets; audio must be sent using one of three codecs or PCM; and the initiation and termination of sessions between endpoints is done via SIP.

Most of the major codec manufacturers offer N/ACIP compliance in their product lines.

The ubiquitous nature of the Internet opens up many new possibilities for unique programming elements at a radio station. For news/talk stations: Need to send talent off to the war zone? For CHR stations: What about an impromptu interview with talent that is touring overseas? For sports stations: Dead audio pairs in the locker room? With the ever-increasing number of IP codecs in existence around this country and overseas, N/ACIP compliance is an important feature to consider when outfitting your own station with an IP codec or two. Sure, when you buy a pair of them, you're going to buy both from the same manufacturer; but when connecting on the spur of the moment to a location you never heard of that morning, knowing your box can talk with many of the dozens of codecs out there already is going to increase your chances of success.

N/ACIP Rundown

Which IP codecs support N/ACIP? Here's a list of several.

  • AEQ
    As an early participant in creating N/ACIP, all AEQ codecs are N/ACIP compliant.
  • AETA
    AETA was an early participant in N/ACIP compatibility.
  • Comrex
    A 2009 firmware release for its Access IP codecs makes them N/ACIP compatible.
  • Digigram
    The Iqoya link is N/ACIP compatible.
  • Mayah Communications
    The C11 series codecs, Sporty and Flashman are N/ACIP compatible.
  • MDO UK
    The Audio-TX STL-IP is compatible with N/ACIP.
  • Musicam USA
    The Suprima LC, Road Warrior and Suprimax are N/ACIP compatible.
  • Orban
    The Opticodec 7600 is N/ACIP compatible.
  • Telos Systems
    The Zephyr/IP is N/ACIP compliant.
  • Tieline Technology
    All IP codecs are N/ACIP compatible.
  • Worldcast Systems APT
    APT was an early adopter and participant of the N/ACIP standard and supply the Worldnet Oslo, Worldcast Equinox, Eclipse and Meridian as fully compliant codecs.
    Irwin is transmission systems supervisor for Clear Channel NYC and chief engineer of WKTU, New York. Contact him atdoug@dougirwin.net.

Previous 1 2 3