Signaling is made of 2 things, the transport on which it is carried and the signaling itself. In VoIP networks, signaling is basically the religion you decided to follow – SIP, XMPP, H.323, MGCP…
These protocols make use of some or all of the common standard transport protocols – TCP, UDP, SCTP.
In the traditional VoIP world, the signaling protocol was and still is considered as an important identifier of your solution. This is regardless of the fact that many of the current SIP deployments are not really pure standard and require some mediation between them, an SBC.
In WebRTC things are different. WebRTC doesn’t define any signaling protocol or transport for signaling; this is left for the application. This gives more flexibility but also more things to decide on and therefore debate about.
Tsahi from BlogGeek.me talks about why WebSockets is probably the right way to go, or more correctly, secured WebSockets. No point in me repeating that.
Here I want to focus on the signaling protocol question.
Andrew Prokop addressed this on No Jitter describing the matrix “solution to the problem”.
Question is, is there a problem and thus, a need for a solution.
Case study A – I’m building my new awesome service
A company that is planning the new Facebook, WhatsApp, tinder… or maybe adding WebRTC related capabilities to an existing service, say game, real-estate or bank.
A few characteristics of these services:
- The service includes much more than just A talking to B, even if C, D and E are conferenced in
- Idea is that users experience the service the way the provider wants them to experience it, meaning in the web app or mobile app provided by this service. This has to do with UX and might also relate to monetization
- The WebRTC related communication that is part of the service has no value out of context of the service…I have no desire to speak with that banker or real-estate agent out of scope of the service he is giving me
And the conclusion:
If I’m a company building this new awesome service, I have no need for federation or interoperability. I’m going to makeup my own “thing” for the service to work. Where relevant, I will use existing stuff and change them as I see fit.
Case study B – I’m connecting my telephony network with WebRTC
In this case we have a UC or Contact Center vendor or a service provider that wants to offer access to his solution from browsers or mobile devices.
The desire is to do as less mediation as possible and simplify the solution. In this case, using the same or closest signaling protocol that is used in the existing solution would make a lot of sense.
If the need is to provide Web developers a way to connect their app with this UC or Contact Center solution then decision might be to wrap that telephony related interface with a simpler custom purpose interface or use a proprietary protocol instead of SIP. The decision will be case by case and based on the focus of the solution, desired functionality and developers it is targeted at.
Conclusion – One size doesn’t fit all
In each of these 2 case studies, outcome of what to use for signaling may vary, each application has its own current needs and future plans impacting the decision. A good point to start with is what does your application revolve around. Is it more telephony centered that wants a “Web leg” or is it a Web service that might need to connect to telephony networks or other Web services in the future. The latter might lead to proprietary signaling while in some cases, the former may lead to use of a standard protocol such as SIP.