The whole is greater than the sum of its parts
We released a PR today about the AudioCodes WebRTC Connectivity Solution. In this post, I want to provide a technical insight into this solution, explaining why the whole is greater than the sum of its parts.
A typical approach to connecting WebRTC with an existing enterprise VoIP network would follow one of these two architectural concepts:
- Browser using Opus with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> Transcoding to G.7xx -> IP Phone on a SIP network
- Browser using G.711 with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> [Optional: Transcoding from G.711 to G.7xx]-> IP Phone on a SIP network
Both cases introduce some issues
The external WebRTC to SIP GW carries a price.
Transcoding from Opus to G.7xx is something you would want to avoid unless there is no other option. Opus requires hefty CPU resources (much more than most audio codecs) and introduces quality issues while increasing CAPEX.
The other alternative, using G.711 over the open internet, is not a good option as G.711 wasn’t built for sustaining quality over unmanaged networks.
Traffic traverses between networks and different network types (WiFi, Wireline Ethernet, public Internet and enterprise networks) while devices themselves can vary as well. Handling of network impairments should be done in the entity that connects between these networks as it is familiar with the requirements of each and has the per-session knowledge of source and destination of traffic. While the two links above use VoLTE as an example in the post, similar issues arise when traversing WebRTC to non-WebRTC networks and the algorithms described in these posts serve the need of this architecture as well.
Another missing piece in typical deployments is the ability to monitor the traffic, know what is happening on the network and impact SBC decisions for quality improvements.
Putting quality and scale at the front
The solution announced was designed with these two factors at the forefront and that is what makes it stick-out of the crowd.
In our solution, WebRTC is supported in the SBC itself. This includes WebSockets, DTLS and other WebRTC “special” behavior. This architecture simplifies deployment and management as well as reduces delay, (or in other words, increases quality).
Minimal transcoding scenarios
By supporting Opus in the AudioCodes IP Phone, we hold the rope at both ends. On the one hand, voice over the open Internet is using the Opus codec which is purposely built for this task. On the other hand, transcoding is not required as the IP Phone also supports Opus. This significantly increases the number of calls supported while reducing CAPEX.
For signaling we use SIP over WebSockets. We found this to be a good solution when the goal is to connect to existing networks.
Another advantage of the decision to use SIP for signaling is the connection to WebRTC API platforms. WebRTC API platforms typically use proprietary signaling. For connecting to existing networks they build an adaptor which is typically SIP. This basic SIP implementation can’t connect to any existing enterprise SIP network but going through the SBC allows it to do so. While this SIP adaptor varies and is not always pure WebRTC over WebSockets, eliminating the need for this adaptor to implement a full WebRTC to SIP GW, simplifies this interconnection making this task easier.
Voice quality enhancement
As mentioned, traffic traversing between networks typically suffer from call quality degradation. There are different implementations of media engines on the client side that are optimized for the network with which the client plans to work. When the client connects with another client on a network that it wasn’t built to connect with, voice call quality issues increase. Having the SBC as a demarcation point between the networks allows for the utilization of the AudioCodes voice enhancement algorithms for improving audio quality.
Detect & correct
The AudioCodes Session Experience Management (SEM) not only monitors and detects voice call quality issues, it also works in harmony with the SBC to allow for smart, quality based, routing and quality improvements.
Why is this important?
A WebRTC GW doesn’t stand by itself; it needs a multitude of capabilities and supporting elements to ensure effective and high quality service. This is why the whole is indeed greater than the sum of its parts when bringing all that is required for an end-to-end WebRTC Enterprise connectivity solution.