Thursday, Dec 3rd at 11:00 AM CST
Tuesday, Dec 8th at 10:00 AM CST
The excitement surrounding WebRTC continues to grow unabated. Innovation abounds and every day I am bombarded on the Twittersphere (in addition to multiple LinkedIn groups, RSS blog feeds and frequent webinars) with another product announcement or a new and interesting demonstration of the technology. I am encouraged that so many share our opinion that WebRTC is a truly disruptive force.
In the midst of all this activity and dialog, however, I am surprised by the lack of discussion around a critical element of the solution: signaling. While attention tends to be fixed on the media path between two WebRTC endpoints – and the pleasure of seeing a smiling face at the other end of a web page, there has been relative silence as to the best approach to connect the user to the service in a way that simplifies the development of the applications being considered.
There are certainly camps forming in this area. Myriad new OTT players are pushing closed and proprietary signaling methods to gain a subscriber base and chase the Wall Street equivalent of Metcalf’s Law – where the valuation of a company is exponentially proportional to the number of named subscribers.
Some legacy telecommunications vendors, on the other hand, are looking to the past for a signaling solution. Many advocate making a browser into a VoIP-like client and prescribe SIP as the protocol of choice. This is not surprising, as most of the players in their ecosystem understand SIP and are comfortable with it. While there is no question that this will be a use case – with browser clients used for VoIP services – the exclusive use of SIP signaling in WebRTC may hold back its innovation potential.
SIP was developed predominantly as a telephony protocol (well, perhaps more accurately it has been implemented for telephony; its initial goals were much more grandiose), and it has by-and-large been successful in that endeavor. But in a Web-based context, it is critical to include technologies that are embraced by the Web community.
The promise of WebRTC is about creating new applications and being able to embed communications directly within them. Accordingly, the focus needs to be on the application developer – NOT THE NETWORK. The complexity of what needs to happen inside the network should be masked and abstracted out as much as possible.
For these reasons and others, REST has emerged as an alternate signaling protocol with the highest potential to allow WebRTC to realize its full potential. By offering Web designers a familiar and simple-to-use programmatic interface, service providers have an opportunity to extend outside of their current realm and participate in the new services that are created -- instead of becoming merely the pipe that transports them.
The benefits of REST are numerous and significant in comparison to SIP:
While WebRTC is still in its infancy and there are many ways to deploy it successfully, it is important to reflect on how the new edge of the service provider network will interact with the Web domain and think beyond the basic SIP technology. SIP is tremendously valuable inside the network, but it is certainly not the only – and may not represent the best – choice for connecting with new services unlocked via the Web.