If you are building a system and want to understand the pluses and minuses of signaling, look no further than Tsahi Levent-Levi’s well-thought out piece on signaling protocols and which strategy to use with WebRTC.
Reproduced with permission from Levent-Levi’s blog, BlogGeek.Me.
Once you have read Levent-Levi’s entire piece you will have a great understanding of how to manage signaling, and you will also realize why Google did not bring the requirement along for the ride. In theory, all signals are good, and like Cisco, WebRTC has never met a [signaling] protocol it did not like.
I only had one question upon reading, “How to Select a Signaling Protocol for Your Next WebRTC Project?” Is signaling choice a help or a hindrance if you are looking to reach out to new people?
Levent-Levi answers my question, stating that Google and URL is discovery. From a website perspective, I agree, but what if you want to offer WebRTC as a standalone service? In that case, I would modify Levent-Levi’s table in the following manner.
|
Technique
|
Discovery?
|
Why?
|
|
SIP over WebSockets
|
Yes
|
Supports IM, URI, ENUM etc.
|
|
XMPP/Jingle
|
Yes
|
Supports IM, URI, ENUM etc.
|
|
Websockets
|
No
|
Needs to know the elements
|
|
XHR/Comet
|
No
|
Needs to know the elements
|
|
Data Channel
|
Maybe
|
As an open channel it supports anything
|
More than once I have been told that my bellhead has a VoIP brain, which is blocking my grokking the value of Websockets, but I think Levent-Levi was right in saying that SIP with Websockets is different from Websockets alone, though in the Websockets presentations I have noticed that the signal is to known elements.
So what point am I trying to make? (Always a good question.) These days, even my favorite websites punt on discovery and allow Facebook to serve as a login system. Such sites recognize that in our always-on world, the website is not a separate destination, that people move around the Web with great ease, and it isn’t likely that a session will be open with your site at all times.
Of course, this is bad news for all of those who imagined they were going to kill Skype. Such folks can dare to think that they will be first movers, but as I pointed out last week, technology does not make a service, and it is far easier to attach to a site that people are going to use via that website’s APIs. To me, this all suggests that the data channel is the way to go. For example, if you build a WebRTC client that supports LinkedIn, you are likely to eventually find yourself competing with LinkedIn. However, if your WebRTC client connects to LinkedIn via its APIs, you can enable discovery on its systems. Likewise, you can interconnect to Facebook, Twitter and Google+.
Levent-Levi points out, “Social networks enable you to use their credentials not via protocols but via an API (OAuth or similar). Once there, you don't really connect to their network and therefore the data channel is irrelevant.”
To that I add that you can use the data channel to place the social networks in the context of your own offering. Doing this enables more users and allows for the leveraging of Metcalfe’s law: The value of a telecommunications network is proportional to the square of the number of connected users of the system (n2).
WebRTC as a Web interface only seems to be a Metcalfe anomaly. If you think you can live without interoperability, ask yourself a simple question: Can you compete with Google? If the answer is “No,” I would suggest you start with the question, “How can my implementation grow?” You will be surprised what you discover.
Edited by
Rachel Ramsey
