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.

Standards

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.

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.

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