WebRTC Application Development: Architecture & Gateways
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(WebRTC Gateway).
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.
RTCWeb.in is a custom webrtc app development company delivering high-performance real-time solutions including-voice/video chat apps, instant messaging solutions, screen sharing, etc. for varied industries.
The Typically Proposed “WebRTC Development 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.
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.
If you are wondering to develop a webrtc application by experts, read this blog here- https://blog.rtcweb.in/webrtc-solutions-an-enhancement-to-your-unified-communication-suite/
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.
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.
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.
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.