Simplifying a standard is something I have never seen happen in real life. Would be nice if it were possible, but I do think it rather is impossible.

I agree there should be a modern (without the pre 2010 accumulated baggage) and easy way to signal, but what would be the cost of reinventing something.

Perhaps a compromise would be to simplify what we have and unload some of that excess baggage accumulated along the way.

There is nobody who dislikes the backward telecom industry more than myself. However, SIP does not have to be coupled with telecom or even voip in any way. SIP was a protocol that was designed to help legacy telecom out of the dark ages but many don’t realize it can work for any type of session setup and management. Any custom WebRTC signalling protocol that is around fully featured, in a large scale system, and around long enough will begin to look a lot like SIP or XMPP (if they’re smart they’ll scrap it first).

SIP can work completely independently from any service provider. Two SIP clients, if configured correctly, can communicate P2P. However, for a slightly more scalable system but without using a voip vendor I’d use http://oversip.net (websocket backend) and http://sipjs.com (javascript client). Using those you’d instantly gain all of the features, reliabilty, interoperability, and scalabilty that it would take an individual a lifetime to achieve.

Keith, thanks for taking the time to write this comment. I love a good argument 🙂

I should be the first to defend signaling protocols. Been developing and marketing them for most of my adult life. I do believe that they are becoming less important to developers, especially when I have my own protocol that is used across the service already. Think of a dating site for example. It has its own way of “messaging” between people. A way to handle discovery, schedule blind dates, status updates, etc. It would be far easier to just hook up that last bit of making a real time on line session (I won’t call it a call) into the existing protocol than it would be to try and (brutally) force SIP into that scenario.

I see WebRTC as a way for services out there to add communications without the reliance on the old guard of telecom players – be it large carriers or VoIP vendors. Once they do, often times going for the “tried and true” of telecom that is SIP (or XMPP) makes little sense.

I strongly disagree when you say standardized signaling protocols (I’m assuming SIP or XMPP) many times hold no value. Even if the purpose of a given WebRTC application is not to communicate with other devices that speak SIP or XMPP, I’d highly recommend using a standardized protocol unless it’s one of most trivial of applications.

Here are some reasons why:
1. There is no need to reinvent the wheel. There are lots of edge cases for starting, stopping, bridging, and ending sessions as well as media negotiation. Make use of the knowledge of the MANY who have encountered these problems before in many diverse systems.
2. The protocols are very worn and well tested. There have been RFCs in existance for years.
3. Interoperability and network federation. The world doesn’t need another wall-off communications network, be a bridge not a wall.
4. Most importantly, the existing open source and proprietary ecosystems are huge. There are higly scalabe client-side and server-side implementations in every language imaginable, tons of books and documention, and lots of experienced engineers for hire.