Who the F&#k Cares About Signaling?

Signaling is now a second class citizen. Sorry for going down this same path yet again, but I think it is an important notion. Signaling isn't important any longer.

By that I don't mean that we don't need it – I just mean that the struggle for a single bullet, an ubiquitous solution that can be used by all and for everything – that is what isn't important. You need to understand – I am coming with a very rich signaling background – from a business unit whose bread and butter was signaling – so for me to say that signaling isn't important is to throw away over a decade of my life down the virtual drain. Chris takes it farther still – when we had a chat the other day, he said that we need to tear down what we have developed and start fresh when it comes to WebRTC. That can be rather hard for many vendors, and for some it might not even make sense – but I do urge you to rethink your business model in light of WebRTC – that might need a serious polish. Why is signaling not important? Because it isn't interesting. It takes so little to build stuff up today with WebRTC, that just thinking of adding a full-fledged signaling protocol can increase cost and effort in ways not proportional to its contribution. It is nice to think about it though. I started "life" in VoIP in the good old days of H.323. It was all binary then – strict messages encoded to save on space. SIP won over H.323, doing so because it was written in "text" that allowed people to "debug" what they "saw" on going on the line. Honestly? SIP and H.323 are quite the same. The differences are like the ones between Gala and McIntosh (hint: they are both apples). Then came all the cool XMPP guys trying to displace SIP. It was fun. Whenever I wanted loads of comments on a post I only had to talk about SIP versus XMPP. And again – the differences were rather marginal. XMPP's "innovation" was mainly its ability to work over HTTP. So we moved from text to web. And now with WebRTC? it is any of the above, with this new option of "proprietary", which usually boils down to JavaScript code implementing *something* over either web sockets or just HTTP requests. We've been dumbing down (or simplifying?) the protocols we use for signaling, and we reached a point that it just doesn't matter what signaling protocol you use in your WebRTC implementation. What to choose then? Whatever works for you, based on experience, knowledge, ecosystem, cost or any other factor you need to deal with.