SIP Audio Codecs – Are They the Future?

In the past, if you wanted broadcast quality audio on an OB, you had to book and ISDN months in advance at a fairly non-negligible cost. Even more costly was broadcasts really remote locations with ISDN satellite links running at around £10+ per minute.

 

Go further back in time and 400/800MHz FM radio links were the order of the day. Almost every station had some form of “radio car” (or even van in some cases), complete with collapsible mast on the roof.

 

Those could be interesting to drive in busy city centres, with the extra height and lack of visibility out back (the mast tends to go through the centre of the vehicle). It was a fun experience that one time I’ve ever driven in the centre of London.

 

Nowadays, IP based codecs are seeing a lot more use. And I must say, I’m not particularly surprised. IP connections are available pretty much anywhere you go. Admittedly they vary a fair bit in quality, but, with the right audio codecs in use, you can do better than ISDN quality on a mobile phone using public 3G networks.

 

The catch is that it all falls apart when there’s any sort of real crowd gathered (e.g. a football stadium, music arena or even political march). Everyone’s trying to post that funny Tweet or brag on Facebook. You’ve not got any more right to the bandwidth than anyone else.

 

Nailed down wired connections tend to be the way to go if you can. However, the cost of satellite links has dropped enough now that it can be economic under the right circumstances. Systems like the Vipranet that aggregate multiple mobile network connections can help as well.

 

But assuming you’ve a good connection of some form, what are the codecs like to work with? The answer might surprise you, especially if you’ve encountered ISDN codecs and the multiple incompatible algorithms they use.

 

Generally, IP based codecs play well with each other. Especially, if you’re doing as per my current experiments and connecting them to each other through SIP.

 

Most IP codecs you see on the market tend to be varying levels of N/ACIP compatible. N/ACIP is an EBU (not just Eurovision!) standard that basically says IP codecs should support SIP and a recommended set of algorithms. The idea is that you can buy any pair of codecs from different manufacturers and have them operate together.

 

This is something I’ve been putting to the test recently. On the server side, we’re using a copy of OpenSIPs, configured to also straddle between the internal and external networks. While the configuration was painful to get right, it was one of the few SIP servers that just got out of the way and lets you use any audio algorithm you want.

 

It’s also bundled with RTPProxy, a tool that will route RTP traffic (the actual audio connections) between the internal and external networks. That again took a bit effort to get working correctly. For that reason, I’ll be doing an article on how to configure these systems in the near future.

 

But for now I may as well tell you how the different IP codecs interoperated with each other. The experiments I’ve been running have involved the Tieline Commander G3, Comrex Access Rack and Luci Live.

Tieline Commander G3

 

The Tieline Commander G3 took a bit more work to get operating with the SIP server. It also has a couple of limitations that might catch you out. Firstly, it doesn’t support DNS. This meant changing the server IP address as I moved the codec between the internal and external networks, somewhat rendering the split DNS that was configured as bit pointless.

 

Secondly, it can only dial extensions with numbers. That means you need to ensure any other user it wishes to dial has a numeric alias of some form.

When I got it going though, it worked solidly and reliably. No real operational problems were encountered.

With regards to audio algorithms, the Tieline Commander is limited to G.711, G.722 (64kbps – ISDN quality), MP2 and linear WAVE when using SIP.

 

This isn’t necessarily problematic but will limit what codecs the Tieline Commander will operate with. It’s also showing its age a bit, lacking modern algorithms such as AAC and Opus.

Comrex Access

 

The Comrex Access is a bit of a more recent unit and seemed to be much easier to configure. The web interface is incredibly useful when it comes to both configuration and handling calls.

 

Algorithm wise you get G.711, G.722, AAC-HE (v1 and v2) and Opus to choose from when operating with SIP. The modern codecs are a welcome feature, especially when it comes to the quality for bandwidth trade off.

 

However, there is currently a bit of an issue with regards to AAC-HE (both versions). When operating with SIP, it will only support up to 56kbps on AAC-HE. That’s a bit of a catch when it comes to operating with other codecs.

 

If you’ve been paying attention, you’ll have realised that having the Comrex Access and Tieline Commander talk to each other is very limited in algorithm choice. You get G.711, G.722 and linear WAVE to choose from.

Luci Live

 

The offering out of the three that surprised me most was the softphone – Luci Live. It works on a number of different platforms, both desktop and mobile.

 

On top of that, the selection of audio algorithms seems to cover all the major offerings. Specifically, G.711, G.722, MP2, AAC-HE (v1 and v2), ULCC, Opus and Linear WAVE are supported.

 

Configuring a destination required a few steps and how to answer an inbound call wasn’t the most obvious thing to do in the mobile phone interfaces. However, the range of algorithms offered and the way it generally “just works” was pleasantly surprising.

 

When it came to testing between the three different codecs, it was interesting to hear the difference in quality you could get from the different algorithms.

 

While linear WAVE was the ultimate benchmark (and least practical running at over 1MBps each way), Opus seemed to come out on top for the bitrate in question. AAC-HE wasn’t too far off but MP2 is really starting to show its age now.

 

With speech, you can get Opus (and AAC) right down into the 30-40kbps range and still get reasonable audio quality. Music, and especially tracks with a wide stereo image, tended to require around 64kbps to sound somewhere approaching broadcast quality.

 

96kbps Opus seemed to be a reasonable trade off between quality and bandwidth. Just as well because that’s about the best I could get out of free WiFi offerings when trialling this.

 

There are very few situations I could really recommend the use of G.711 or G.722, other than compatibility with older codecs and softphones. The higher quality you can get for the same bitrate from modern codecs means you’re better served with the modern codecs.

 

The result of all this is that you can use IP codecs for broadcast radio. With modern algorithms such as AAC and Opus available, you can sound better than you ever could on ISDN.

 

The catch is that it can be a little complicated to configure all of this. Especially when it comes to the SIP server. Thankfully there will be a few more articles in the future covering some of this.

You may also like...

2 Responses

  1. Hi Marc

    Great review, you are correct the Commander G3 has it’s limitations. The new generation of codecs from Tieline including the BridgeIT’s, Merlins and Genies provide DNS support; OPUS (Tieline was the first codec manufacturer to deploy OPUS); AAC and EaptX. We also have the worlds most popular Smartphone Codec ReportIT. If you wish drop me a line and we can arrange for you to have a play with a gear.

    • marc says:

      Hello,

      It did feel a little unfair comparing the G3 against the more modern codecs. The only reason these codecs are compared are because that’s what we had going spare at the company I work for.

      On the Tieline side of things, they do use the ReportIt app extensively for journalist contributions. I’ve also personally used your POTS codecs for OBs over the years.

      I’d be happy to test a more modern codec (assuming my employer doesn’t already have one) and will be in touch with you shortly.

      Regards,

      Marc.

Leave a Reply

Your email address will not be published. Required fields are marked *