Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Tim Panton <[e-mail]>]

On 3 Oct 2011, at 19:24, Ravindran Parthasarathi wrote:

> Hadriel,
> 
> Sorry for the delay response. I have mentioned the reason for "standard signaling protocol" as a separate draft and the related thread is http://www.ietf.org/mail-archive/web/rtcweb/current/msg01733.html. 
> 
> I agree to the fact that SCCP protocol is decided by Cisco folks but it does not mean that every company in the world has to create their own version of SCCP protocol and IETF should not force every company to re-invent the wheel.
> 
> The intention of standard signaling protocol is not against those who have the interest in creating their own proprietary signaling protocol. The main purpose is for the welfare of those whose focus is not signaling but interested in Real-time communication. JavaScript library by third party is worst case in case there is no native standard signaling protocol exists for RTCWeb.
> 
> Let us discuss how much services has to be provided by standard signaling protocol.
> 
> Thanks
> Partha

Partha - here's a quick review of http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00

I'm not going to go through it line by line as I disagree with almost all of it, so I
focus on 2 key assumptions:

Firstly -> 

Fig 1 is wrong  - in the _huge_ majority of instances there will be
only one web server in such a diagram. Federated services will only be the minority case.

Where services do interconnect, they will (As in the SIP and PSTN world today) go through 
policy gateways which will manage tariffs and dataflow into and out of the service.

So there should be either 1 web server or 2 webservers and 2 policy gateways.

If you correct this diagram  the rest of the document is invalidated.

Secondly ->

You assume that being compatible with a legacy protocol would be a good thing, 
but don't examine why. 
I contend that there is no suitable legacy protocol and no advantage would be conveyed by 
implementing one directly in a browser. I'll use SIP to illustrate my point:

The illusion is that there are lots of SIP devices that users are itching to call from their
browsers. There aren't. Almost all the SIP devices in the world are behind policy firewalls
and are not directly accessible from a browser based SIP implementation.

Even if they were reachable, our experience of browser based realtime audio
(at phonefromhere.com) shows that people don't use the browser to call PSTN-like
endpoints. If they want a PSTN experience, they pick up one of the 3+ phones available to
them. 
(What they do use browser based realtime audio for is dating, conference calls, collaboration etc)

Even if all the SIP devices were reachable and people wanted to reach them, 
we still should not be using that as the core case to base the webRTC spec upon.
There are (I guess) already more users of the facebook site than there are SIP devices.


Conclusion -> 

So we should focus upon the most common use-case and not get distracted into discussing 
what is at best an edge case.

The risk of such a discussion (of a standard signalling protocol) is that we will still be discussing it in 3 
years time and each of the browser makers will have implemented their own subtly different
webRTC solutions.

Tim, speaking for himself, but based on bitter experience at phonefromhere.com