WebRTC is changing the way enterprises communicate within their organization and with their customers.
As a result of the large and diverse range of different use cases of WebRTC in the Enterprise world, there are inevitably a number of challenges that need to be addressed. We’ve compiled a list of some of the key challenges and solutions for consideration with regards to implementing WebRTC for Enterprise solutions: Signaling, Multi-party, Interoperability, Quality and Scalability.
SIP? XMPP? JSON? Rumor? The right answer to the signaling question probably depends a lot on your starting point and on what you’re trying to accomplish.
While many people think signaling should be standardized; others think we already have the answer in SIP or REST. Some maintain that the lack of a signaling specification (beyond the need to support SDP offer/answer) is a huge gap in the WebRTC standard.
A major vulnerability was uncovered yesterday which affects a majority of web service providers. The exploit is related to OpenSSL’s heartbeat extension which could enable a malicious attacker to access private keys. The bug has been present in OpenSSL since December 2011, and was brought to light yesterday. You can find more information about the exploit termed “Heartbleed” (CVE-2014-0160) here.
Our operations team reacted immediately to this and has taken the necessary steps to secure our infrastructure, ensuring the appropriate secure versions of OpenSSL are in place.
Connectivity, we at TokBox believe, is one of the cornerstones of real-time communication applications. So we are happy to announce that we now support TURN over TCP.
There are several technologies which are used to help establish connectivity in WebRTC. The first mechanism is using a protocol called STUN. STUN uses a ping-pong mechanism to find the public IP of a client end-point so that a peer-to-peer session can be established and one can traverse a firewall. While this is useful in a number of scenarios, there are cases where one could be behind symmetric NATs, where STUN does not suffice. TURN helps in these cases. TURN is a mechanism by which real-time media can be relayed through a TURN server to punch through firewalls. OpenTok seamlessly supports STUN and TURN so a developer doesn’t have to worry about how to setup up these servers, scale them, establish connectivity etc.
At TokBox, we aim to push boundaries and deliver the best possible WebRTC-enabled experience for application developers building face-to-face video applications. One of our guiding architectural philosophies has been to provide the right primitives for developers to build rich and powerful applications. In addition, we want to make sure we abstract the underlying nuts and bolts and enable the cloud service to dynamically react to changing environmental conditions (bandwidth, packet-loss, etc.) in order to deliver the best possible experience.
The multiparty stream routing component of the OpenTok platform is also capable of shaping traffic in real time. Let’s take a look at how this this capability delivers a significantly improved quality of experience for users.
Today, we are happy to announce yet another significant milestone in the technical evolution of the OpenTok platform – dynamic traffic shaping for audio and video through our Mantis infrastructure. We are now optimizing the experience for every participant in a multi-party call.
WebRTC is essentially defined as a peer-to-peer protocol for real-time browser-based communication. The problem is that countless real-world applications require multi-party support. So eight weeks ago we unveiled Mantis to solve this. Mantis is our next-generation cloud-scaling infrastructure that enables developers to deliver bandwidth-efficient multi-party WebRTC support.