Historically, communications has been a balancing act, with interoperability on one side and innovation on the other. The PSTN is the ultimate standards-based and interoperable network but that comes at the price of utter inflexibility. On the other hand, you have walled-garden services like Skype and Viber. They support all kinds of innovative features, but even Skype is far from universal. The best thing about WebRTC is that it manages to be interoperable while at the same time enabling innovation.

Why doesn’t signaling matter in the WebRTC world? Because WebRTC endpoints are dynamic – they are created out of JavaScript, HTML and CSS when you visit a website. Your browser is essentially building a phone based on instructions from the web developer, and these instructions include some means of signaling. SIP over WebSocket? Jingle over BOSH? Some kind of home-grown JSON messaging over Comet? It doesn’t matter. The mechanism of interoperability isn’t the signaling protocol, it’s the Web. All you need is a standards-compliant browser and you can communicate with anyone.

In a WebRTC world, every site is a “fenced garden” — it has its own internal (and potentially proprietary) mode of operation, but anyone with a browser can come in and play. Each site may have a completely different user experience and underlying technology but you, as the end user, won’t care.

Speek.com looks like a silo to me.

Twelephone uses the phono , which is a js library for the phono service and that provides a SIP backend.

UberConference use a gateway the call to other protocols. They offer a rich media experiance to their users then interwork with other protocols in their cloud.

The use of a protocol gateway is something that I expect will be fairly common in the future. Products like Digium’s Asterisk and Acme Packet can already do SIP/WebRTC translation. I have even seen some gateways do the SAVPF/AVP conversion for the media too.

You actually can…

Twelephone, Speek, UberConference and a lot of other WebRTC services provide a URL that is either personal to the user or in the context of the specific interaction that you can use or share with others.
Same as email, only in a URL form.

A browser downloading it’s client for a particular service is how I expect it to happen.
The Google hangouts client will be part of and know the Google procedures and conventions. The Cisco WebEx client will know and use the Cisco procedures and conventions.

That is “simple”. That model works right now, even without WebRTC. Albeit with lots of restrictions on which platform/browser/network combinations.

With standard signaling, I could extend my phonebook to include federated services (the email convention of @domain.com works well here).

At the moment, there is no “WebRTC” URI. I can’t click on a webrtc:me@mydomain.com (c.f. mailto) and trust that my browser knows what to do with it. That would requires conventions, protocols… or dare I even say… Standard Signaling.

When you access a WebRTC URL, the browser will download a javascript from it that tells it what to do. It’s really simple.

An example from the past: usenet vs the web
Usenet used standardised protocols to exchange forum discussions between servers. It had ‘interconnection agreements’, it had a universally accepted feature set. Then came the web. Many web site have forum discussions. Some require authentication of senders, some don’t (like this one). Some use 3rd party authentication — eg stackoverflow.com. Some require a ‘silo’ account, like facebook. Sure I can’t use my highly customized NNTP usenet reader to access all those forums. But the forum developers had much more freedom to innovate than in the usenet world where everything had to be standardized. And the average user preferred the web forums, too.

A URL might be as universal an an E.164, but what payload do I send to it?

With an E.164, I can start doing ENUM and SRV lookups and let my network determine what to do with it. Part of the lookup process gives me back a protocol and connection information.

With standard signaling, I know what to do next to complete the call.

With a URL, what do you do with it?
Do you send GET? POST? What payload do you send? query args or multipart MIME?
Do I encode it with xml? json? what parameters do I need to use.
Is it authenticated using OAuth2 or OpenID? Do I have an OAuth token that the server accepts or shall I try HTTP basic instead.

Without standardized signaling only the vendor who wrote the implementation can use that system. It’s a real problem that exists before we even start discussing the effects of WebRTC.

—
My hope, and the way it appears to be heading, is that vendors will start to implement web sites and clients using WebRTC to handle all of the hard stuff for the client, get a js library (my current favourite is sipML5.org) which talks SIP to a proxy for further routing.

This way, we’re not throwing away what we have learned over the past decade. The last thing I want to see is web designers reimplementing wheels and resolving problems.

Signaling is very important to me. Part of my job involves watching wireshark traces of SIP and watching the behaviors of products from different vendors interacting with each other.

XMPP and SIP (and SMTP) are everywhere.

PSTN maybe the most common “standard” that audio phones use to interoperate, but it is usual to see that operators use SIP for routing calls inside their networks.

For homes, some operators are even offering so called “HD Audio” these days. I bet that if you check, they’re really using SIP to upgrade from G.711 without you knowing about it.

If you work in an office, it is probable that there’s a deskphone nearby. Does it have an RJ11 or an RJ45 cable in it?
If it is an RJ45, then admit it, you’re using SIP too. If RJ11, then it is probably interworked to SIP at the first server, then routed over IP.

True.

Ben,

Signaling will stay with us forever. Question is – how fundamental is it going to be moving forward. I think it is getting commoditized to the point of irrelevancy.