If you are reading this blog there is a good chances you heard about WebRTC and are well aware of the various products and services around it. Centering on enterprise communication and how WebRTC is being realized in this segment, the market is pretty much focused on one solution – a GW.
Now don’t get me wrong, WebRTC GWs are very important, you can’t really do without them if you want to overcome the slow deployment cycles and stay current with technology advancements. The point is that a GW is not enough. Let’s delve more into that.
The Typically Proposed “WebRTC for Enterprise” Architecture
If you look at some of the architectures used today for bringing WebRTC into enterprise networks they typically comprise a WebRTC GW and a media server that transcodes Opus to some other common codec, say G.729. Some options will also include RESTful APIs for configuration and creation of services on top. On the Audio side, there are cases where G.711 is used end-to-end but this option is not a preferred one from quality perspective when going over the open internet even though there are ways to add resiliency and improve quality even if G.711 is used.
A typical architecture of WebRTC GW Deployment
The architecture described above is great, it will do the job. Question is, at what price.
Basically this architecture is kind of an “easy” way to bridge WebRTC into an enterprise network. You put a big box that will brute-force everything to what you have running on your network today. If that big box doesn’t provide the required capacity, just add another one.
There is another option
The most “expensive” component in GWing WebRTC into an enterprise network is the transcoding part. The way to work around this is by adding native support for Opus to the end devices. Doing so will yield quality improvement, cost reduction and preserve privacy. You can find a detailed technical overview why going native with WebRTC media on the end devices is important in an earlier blog post I published.
Reality is that Opus transcoding is extremely computing intensive so architecting this task on the server side will take a significant capacity toll on your system.
The flip side of this is that putting Opus on the IP Phone is complex. Assuming you are going for a SW upgrade and not a HW change, it requires flexibility in the phone architecture and hard work to get Opus running on it.
The subject of why adding Opus to existing IP Phones is complex interested me for a long time so I had a chat with our experts. Eli Shoval who is running our DSP Group and Oren Klimker, a team leader in this group.
The challenges in running Opus on an IP Phone can be summarized to be:
- Processing power – Since not all IP Phones were born equal there needs to be optimization work and actual rewriting of some codec parts to make it run best on the IP Phone processor
- Memory – This includes both footprint and run-time memory requirements. Opus is a feature rich codes that serves a wide variety of implementation scenarios; additionally, since sampling rate of Opus is higher than traditional VoIP codes memory required for an audio channel is increased
This in turn yields 2 main tasks required to overcome the MIPS and memory challenges:
- Optimization – This work includes optimized implementation of some components of the Opus codec for both performance on the specific phone’s SoC (System on Chip) and memory consumption
- Selective implementation – Part of the rewrite work needs to include removal of certain functions not required on an IP Phone
But there is Opus 1.1, doesn’t that solve the issue?
The short answer to this is NO.
In details, there are 2 reasons why Opus 1.1 doesn’t remove the need for native support for Opus on the end devices but rather make it even more essential.
The first reason is simple. Since transcoding will always add delay, reduce quality and impose cost on the server implementation; whenever possible, better to avoid getting into transcoding.
The second reason lies in the details of Opus 1.1 improvements. There is a pretty long list of changes, some such as surround encoding improvements don’t really touch the IP Phone requirements that much. What I want to take a closer look at is the speed improvements. As it looks, the team that built Opus 1.1 focused on improving the codec speed when running on ARM processors with NEON (do I hear mobile?), they reached up to 40% improvement. On the other hand, for x86 architectures there is no real improvement and in some cases things even got a bit worse. This can be seen in the diagrams below.
Opus 1.1 performance on ARM Cortex-A9 and i7-3520M
This means that Opus 1.1 doesn’t bring good news to transcoding servers but it does improve the performance on some of the end devices.
As explained in this post and on earlier ones the preferred architecture for deploying WebRTC on any network and specifically on enterprise networks is one with end-to-end media without transcoding. The target should be to minimize the cases of transcoding to those where it is a must. Such cases as where traffic is going through a GW to PSTN or over SIP Trunks. In other cases, going native with WebRTC on the end devices is a preferred architecture.