With no signaling in WebRTC, who take care of the client when you are selling a gateway?
WebRTC poses an interesting challenge for gateway vendors, which is what to choose as signaling for their gateway. This challenge means they need to think differently than the way they have packaged and delivered their gateways to customers in the past.
A slide from a talk I gave 2 years ago…
Let’s start by looking at the signaling selection part first. There are essentially 3 different options for gateway vendors here:
- Rely on SIP over WebSocket. This will probably work, but will require a selection of a specific SIP JS library along with a reference implementation on top. The reason? SIP and WebRTC interact a bit differently in SDP, and WebSocket implementations of SIP are still brand new. Add to that the stupid complexity of different SIP implementations (that don’t really interoperate) and you’ve got yourself a nice headache.
- Proprietary *something* over WebSocket or XHR. In this case, the gateway vendor envisions some simple protocol to go along with the WebRTC side of his implementation and “standardize” that as the interface to his gateway. While workable, he will be required to provide some reference client written in… JS.
- RESTful interface. The idea here is that the gateway lets some other party interact with it using REST APIs, which works, but is less efficient and flexible than XHR or WebSocket. And at the end of the day, there is no escaping the need to write some reference implementation to explain how to use this proprietary REST API.
The result? From offering standardized signaling interface in a gateway, a gateway vendor now needs to offer his own interface. That interface requires integration, which is best handled by the gateway vendor himself – how can he develop, test and support his gateway without such an implementation?
Next step? The customer of the gateway starts asking how to make this work in Internet Explorer. What can a gateway vendor do in such a case? Tell the customer to find a solution on his own? Tell the customer to develop or purchase a plugin? Or should he just close this gap and offer his own plugin – providing a bit more value for his customer and reducing the risks.
And while we’re at it, how about offering a mobile SDK to connect to the gateway using WebRTC?
Why is it important?
No signaling in WebRTC changes how we should think about our “boxes” in the network – the job they have hired to do.
If the gateway vendor is now in charge of signaling, he has a larger job to do – he is essentially defining the client and should be the one implementing it.
On the other hand, how does that affect vendors who focus on VoIP clients? Can they even grow to provide anything meaningful around WebRTC, or will they just become useless when service providers can just rely on their gateway (or SBC) vendors for the client as well?
Make no mistake. WebRTC changes everything.