As users of WebRTC, we’re in great company, with tech-giants such as Facebook, Slack, Snapchat, and WhatsApp utilizing it in their services. In fact, Blacc Spot Media recently reported that over $2.7 Billion in funding went to WebRTC companies in 2016.
Use of WebRTC, a versatile technology, is growing rapidly. WebRTC is being applied in many different ways, for many different audiences. As technologists, we always want more, so recently I sat down with my chief architect, Andy Pappas, and we came up with our WebRTC wish lists for the holidays.
Leo’s Wishlist:
An Enterprise-Grade Managed STUN/TURN Server
With traditional SIP, there are Session Border Controllers (SBC’s) that exert control over signaling. However, in the WebRTC world, since we don’t have standard signaling, we need to get as close as we can to establishing an SBC. The solution would be an enterprise STUN/TURN server. STUN, formally Session Traversal Utilities for NAT (network address translation), basically echoes a public IP address back to the endpoint. TURN, Traversal Using Relays around NAT, acts like a lightweight media relay when a peer-to-peer connection cannot be established.
Some solutions have a STUN/TURN server for the enterprise but come with too many built-in features and require you to lock onto specific app’s servers. A simple STUN/TURN server with the management features needed by enterprises doesn’t exist today.
Support For RETURN
Since enterprises will continue to use symmetric firewalls, a STUN/TURN server will still be needed in the cloud. For the above process to work, the WebRTC stack must support RETURN to help avoid call failure. Recursively Encapsulated TURN or RETURN allows the browser to encapsulate two TURN servers in one.
Andy’s Wishlist:
More Efficient Peer Connection
In peer to peer networking, it would be great to have a more efficient Interactive Connectivity Establishment (ICE) when multiple STUN/TURN servers are available. In this scenario, WebRTC can take a relatively long time and consume high CPU and memory when a user needs to connect to many peers in a mesh configuration.
A more efficient solution would be to cache or test a connection to a TURN server or list of TURN servers, have the call connect to those, and then later switch to a STUN server or continue with TURN. Right now we’ve customized how we connect to alleviate this delay and load, but there is a lot of room for improvement in this area.
Microphone and Audio Level Alerts and Limits
The detection of and alerts letting users know that they are too close to or have applied too much gain to their microphones would be helpful. If speech/noise statistics were collected over time, this could translate to an API that would signal users if they are operating the microphone incorrectly or were in an environment requiring a different gain level or microphone. Being able to add configurable microphone loss and boost within audio processing would be nice, as well.
An auto level or hard limit on incoming speech at the channel level would also help cases where multiple users are speaking at the same time, which is frequent in the financial services industry.
De-Reverberation Algorithm
Reverberation is a very common problem for a typical home or office user and can be a huge degradation to speech intelligibility on a communication platform. This is solvable with selection of appropriate microphone hardware, however a better, or complimentary, solution is to add a de-reverberation algorithm on the microphone. It might even be possible to characterize the environment by using the speaker-to-microphone acoustic path or model from the acoustic echo canceler.
What’s on your WebRTC wish list this holiday season?
