6
TECH TIPS
RADIOWORLD ENGINEERING EXTRA
April 17, 2019
Professional IP Audio Codec Compatibility Codecs of different brands can often work together if you take the proper steps BY TOM HARTNETT
It’s late Tuesday afternoon, and you get a call from one of your show’s producers. There’s an expert guest on the other coast, and he’s planned a long-form interview with her tonight. The studio she’s in has an IP audio codec. So do you. “Let’s do this!” says the producer. What could go wrong? It seems like this should be simple. Give the far-end studio your IP codec’s address, and enjoy the sweet wideband audio flowing with low delay back and forth, right? Nobody needs to know she hasn’t flown in to talk to you. But when her studio tries to connect, nothing happens. The interview is conducted by phone. The producer is livid. You call the far-end studio in the morning for the post-mortem. It turns out that you have brand X codec and they have brand Y. Why can’t different brands interconnect? The answer is: They can. But it’s not simple. And both the codec and your network need to be specially configured to do this, and things need to be tested ahead of time. And there are a couple of layers of “gotchas” based on the brands that can throw a wrench in things. Sometimes this is enough for a busy engineer to say “to heck with it.” But if you’re willing to spend a little time configuring things, here are some tips on how to make it happen. WHY IS IT SO? Interoperability requires standards that developers can use to create common protocols that connect together. In the case of IP codecs, one standard does exist: EBU Tech 3326. It’s imperfect, but it does define a way professional-grade codecs should interoperate. One main issue with the standard is that it was defined after many of the codecs on the market were developed or were already heavily in development. Several manufacturers had substantial sales of codecs before 3326 was published, and had done a lot of development work on perfecting their own protocols. So 3326 was added as an alternate mode of operation
FIRST (continued from page 4)
I’ve heard it said that if you have time to do something twice, you have time to do it right. I would agree with that sentiment. Quite often, the reality is that it takes a lot less time to do a task right the first time than it does to apply a quick fix now and make it right later. So look at it this way: By doing it right the first time, you’ll actually save time, and those who come after you will benefit as well. While he’s not an engineer, singer/songwriter Billy Joel captured the sentiment well:
on most devices, with the proprietary modes still being the default. Also, the EBU chose to make the 3326 standard use the same VoIP (Voice-over-IP) protocol gaining use in the telephone industry. Known as SIP, for Session Initialization Protocol, it was used by virtually no audio hardware codecs at the time. By default, most IP codecs use a single network socket to send and receive their “handshaking” or call setup information and their audio media. SIP does things differently, and as we’ll see, complicates the IT configuration required to use it. Finally, the IP audio codec market is competitive. This competition drives innovation. Manufacturers have added things like error correction layers, presence/traversal services and call security features that aren’t well-defined in the standard. ABOUT SIP In the world of VoIP, SIP is virtually always set up as a client-server protocol. A SIP endpoint (which can be a phone, a software client or a PBX) registers with a server upstream, and creates a “keep-alive” signaling channel between the client and server. The server can
Fig. 1: SIP connection.
Fig. 2: Separate signaling and media paths are required for a SIP connection.
also be a PBX (serving SIP endpoints) or it can also be a cloud-based server providing VoIP services directly to PBXs or endpoints. Fig. 1 shows this. In this figure, the PBX is both a client (registering with the cloud provider) and a server (providing registration services to the phones). This has a big advantage if routers with NAT and firewalls exist between the client and the server. Because the initial registration request is made outgoing from the client, a socket is created and can be I’ve gotta get it right the first time That’s the main thing, I can’t afford to let it pass You get it right the next time that’s not the same thing, Gonna have to make the first time last Enough said. Cris Alexander, CPBE AMD DRB, is director of engineering of Crawford Broadcasting Co. and technical editor of RW Engineering Extra. Email him your thoughts and suggestions for articles to rweetech@gmail.com.
kept active with keep-alive messages. If an unsolicited message must be sent from the server to the client (e.g., incoming call alert), the open socket can be reused, and the unsolicited information is allowed to pass back to the client through the NAT router. The channel that is kept open is strictly for signaling, and no audio media is ever passed on it. SIP dictates that a separate RTP socket gets opened between client and server in order to pass media. This is the fact that makes SIP complicated in IT environments. Somehow, this independent media stream must also bridge the same NAT routers and firewalls as the signaling channel. In the client/server model (where it’s assumed no NAT or firewall exists on the server side) this can be done simply by assuring the client creates a stream first. The server can respond on the same socket and be reasonably sure things will flow unimpeded both ways. This is shown in Fig 2. PEER-TO-PEER SIP Having cloud servers to route calls is convenient in the VoIP application of SIP, but often doesn’t fit well into the workflow of connecting hardware codecs together. It is possible, however, and SIP registration servers are available for free from several providers. (continued on page 8)