This is the first in a series of posts about new features we’re releasing to our voice stack in the very near future. What makes Simwood unique and very distinct from others who buy a magic VoIP box from a vendor is that our service is built on the best of open-source and the best of black boxes where necessary, all pulled together with our secret sauce. It is also deployed (inter)nationally on our own network. By the time “me too” gets a tick box they don’t understand on their magic black box, our customers will be several further innovations further on. Why? Because we exist to put new communications technology in the hands of your customers, and help you enrich their lives. Let’s leave “Me too” to compete with yesterday, while we make today the best it can be!
So, codecs. We’ll start with the assumption that we all know what they are and that there are many many options and each aims to solve a particular problem. The challenge in VoIP has been that a decision over which to support wasn’t always based on the best reasoning.
In the early years, codec issues were second only to NAT on the list of issues people had “getting VoIP going”. Usually, they centred on trying to use low bandwidth codecs where somewhere along the line things were being transcoded and a license hadn’t been bought.
Certainly, my recollection in the early 2000s was that codec innovation was about getting as many calls as possible into a low bandwidth connection, without quality being too bad. We introduced HD in 2010 because we believed that VoIP had at last transcended the PSTN in call quality, whilst bandwidth was more plentiful. Since then, we’ve seen a steady increase in the use of HD codecs, and the only use of low-bandwidth codecs being either inappropriate or extremely niche (or inappropriate, justified as a niche).
Our secret sauce has also ensured there was no un-necessary transcoding and we were as light touch within the network as we could be. We’ve been asked before (by industry luminaries as it happens) how our calls are so clear even when calling routine PSTN destinations that don’t support HD. This is why.
In the background, there’s been WebRTC gathering steam and that, whilst not directly responsible for all, has catalysed a number of important developments. One of them is Opus, and Opus is the default codec in WebRTC. But it really matters in RTC with or without the ‘web’ prefix. This is why in the interop changes we’ve announced relating to our new stack, Opus is fully supported1. We believe this is a first amongst wholesale providers.
So what is so good about Opus?
Firstly, Opus is one codec that can span applications from low-bandwidth calls, through to CD quality music. Furthermore, it is more efficient than almost every existing codec at each level as the graph below shows.
You’ll also note the high-end comparatives are music related: MP3, AAC etc. Opus is not an HD or wide-band codec like G.722, but is rather full-band or super-wideband. If G.722 was comparable with HD television, think of Opus at the high-end as 4k/UltraHD.
Furthermore, in terms of the latency introduced Opus is as good or better than any other codec, yet can be used across a wide variety of applications – from VoIP through streaming and wireless speakers through to remote music jamming. Of course, this also means it supports stereo too! The two exceptions are really niche:
- Lossless audio – use FLAC instead
- Ultra-low bitrate satellite/ham radio – use codec 2 instead
For our purposes in RTC and unified comms, our advice is clear: Use Opus.
Opus is an IETF standard so there are no licenses to buy either! The technical operation of it is beyond the scope of this but there are some great documents on the Opus Codec website. Suffice to say at this stage, Opus combines a number of the preceding codecs CELT and SILK, each of which has different characteristics and strengths.
Now, if that wasn’t good enough on its own, the really really cool thing about Opus is that is can dynamically shift between its modes (and thus bit-rate). In the case of VoIP applications, this means it can adapt to changes in the network, be it operating at a bit-rate that is appropriate for the bandwidth available (or the new bandwidth available if it changes!) or correcting for packet-loss through forward error correction. Isn’t that awesome?!
For Opus to know about network changes, RTCP needs to be enabled in both directions. We do not presently send RTCP; doing so is another feature of the new stack.
Opus in action
Consider these examples below which show Opus voice calls in varying conditions:
Uncompressed speech (i.e. G711 at 64kb/s)
Narrowband Opus at 8kb/s
Wideband Opus at 16kb/s
Fullband Opus at 32kb/s
Now those are all simply considering the bit-rate which is going to depend on available bandwidth. What about packet loss?
Super-wideband Opus at 24kbps with 30% packet loss
Super-wideband Opus at 24kbps with 30% packet loss but with forward error correction enabled
30% packet loss!!! That would render most VoIP calls completely impossible. Imagine the impact this can have on your end users’ experience (and your support costs!).
Bit-rate dynamically shifting from 8kb/s narrowband to 64kb/s
This is an extreme example as available bandwidth wouldn’t normally increase/decrease by a factor of 8 in a few seconds, but shows how Opus can adapt.
Of course, all of this comes at a price: Opus is more of an algorithm than a codec in that there is computation and adaptation to inputs, rather than simply converting one format to another in a consistent way.
We also have yet to find a hardware DSP that supports Opus (in variable bit rate and with forward error correction). Opus, therefore, needs to be handled in software and doing so is quite computationally expensive compared to simpler codecs. Thankfully we have plenty of hardware available to throw at the problem!
Getting it
So how might you use Opus? Well, firstly this is a feature of the new stack which is being introduced in a phased way alongside the old. If you try to use Opus on the old stack you’ll get the fixed bit-rate non-FEC variety we’ve supported for many years. You, therefore, need to be directing calls to the new stack when available but you probably have a bit of work to do before then anyway!
The full suite of options in mod_opus came to Freeswitch with 1.6.12 but 1.6.x is pretty comprehensive. Asterisk 14 released at Astricon last year didn’t have Opus, but they released 14.0.1 very shortly thereafter which does. That assumes, of course, you wish to handle it on your own equipment; If you’re bypassing media to us (recommended if you operate your own equipment) or creating trunks for your customers so they can send traffic directly (recommended), you’ll get Opus as soon as you give them a UA that supports it. Digium supports it in their DX8 range of phones but otherwise, there are not many about yet. If you’re playing with WebRTC though you’ll have Opus natively from the browser.
Wouldn’t it be great though if your favourite wholesale operator could give you a mobile app which used Opus only to get calls on-net. Your customers could enjoy CD quality audio that handled changing and problematic network conditions and you’d be a super-hero with far fewer support tickets to deal with. Hmm…
New stack part 2 – ZRTP: Encryption done right
New stack part 3 – Anycast SIP
1. The astute amongst you will note we have listed Opus on our interop documents for many years. This was the fixed bit-rate variety without forward error correction (see later in the post). ↩
