Sponsored By

All We Want for Christmas Is More WebRTCAll We Want for Christmas Is More WebRTC

WebRTC is being applied in many different ways, for many different audiences, but that doesn't stop us from wanting more for the technology.

Leo Papadopoulos

December 15, 2016

2 Min Read
No Jitter logo in a gray background | No Jitter

WebRTC is being applied in many different ways, for many different audiences, but that doesn't stop us from wanting more for the technology.

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 more than $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 Wish List

  • An Enterprise-Grade, Managed STUN/TURN Server - With traditional SIP, session border controllers (SBCs) 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, for 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 enterprises need doesn't exist today.

  • Support for RETURN - Since enterprises will continue to use symmetric firewalls, communication cloud providers still need STUN/TURN servers 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 Wish List

  • 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 and there are many servers from which to choose.

    What's on your WebRTC wish list this holiday season?

About the Author

Leo Papadopoulos

Leo Papadopoulos is co-founder of and currently serves as CTO at Cloud9 Technologies, where he brings more than 25 years of technology leadership with proven success at both start-ups and established businesses. Leo has extensive experience with enterprise voice and collaboration, cloud services, and WebRTC. He has built and managed large-scale R&D programs and deployed those technologies in a variety of high-performance communications and collaboration products and services, worldwide.

As CTO and chief architect at IPC Systems, Leo invented and brought to market three generations of market-leading communications and collaboration products used globally by financial traders. As CTO at Lexar and Westcom, Leo served as inventor of the first cloud-based trader voice service that made it practical to connect and trade in emerging markets. As director of technology at Bridge Electronics, Leo led the development of an open line communications platform widely adopted by the foreign exchange markets.