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

[Randell Jesup <[e-mail]>]

On 10/4/2011 5:16 AM, Tim Panton wrote:
> 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.

Agreed.

> 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.

I agree, that is not a reason for any standard on signalling (though as 
you say Partha didn't actually give a reason).  If someone is building 
an access-the-PSTN app (and they will), they can use or build a lib to 
do so - though I'll also mention these fully-functional JS SIP/etc 
libraries we presume don't exist yet and are a lot of work to write and 
debug.  A Skype can do so easily; a small PBX add-on company using 
Asterisk not so much.

I have a different argument: I want it to be *easy* for a website 
author/app developer to add audio or video for their users.   The 
developers aren't experts on glare, forking, the intricacies of getting 
offer-answer (or whatever) right, ad nauseum.  If you ask them to 
*design* their own protocol, they'll make a ton of 'rookie' mistakes.  
And for added fun, they'll likely never correct them and in many cases 
never understand why the bug is occasionally reported by their users.

A random example is forking - forking will happen (forward call to all 
the devices the person logged in under) , and handling forking well 
requires some thought and experience.

The obvious answer is "those people shouldn't design a protocol (leave 
that to the big guys), they should use a standard library."  Ok, great, but:

1) These don't exist yet (minor issue; one presumes they'll exist "soon")
2) The quality and testing of these libraries is unlikely to equal that 
of existing signalling stacks available freely for quite a while
3) Inaki's (sorry about the cedilla) point about "website-based 
libraries can be updated more often than ones baked into a browser" is 
valid, but it has a flip-side - the swarm of smaller users of webrtc are 
likely to download a version of jSIP.js (or whatever) and are not likely 
to actively track updates.  My understanding is that this is rife in the 
use of things like jquery - upgrading is time-consuming and risks 
breakage, and requires QA.  People grab one version and never change it 
- while Firefox for example updates every 6 weeks.  (He may have a 
better argument with IE users, especially in business, but my point 
still holds.)  The larger, sophisticated users are more likely to 
update, or debug problems when they occur, so I'm not worried about them 
- and they can use jSIP.js regardless if there's a signalling protocol 
in the browser.

Point 3 is in ways the strongest point here, since I assume these 
libraries will exist at some point.

You'll note I'm not arguing for SIP here - I'm arguing that there are 
valid reasons for easy default signalling *as and option*, especially 
for the health of the "little guy" app/service developer who wants to 
add RT media.  If we had a functional, debugged, standard JS protocol 
that was free and we could figure a way for app developers to ease the 
update process, it would undercut my argument - but we don't have that, 
and we can't count on that, at least not for a while.  It does not 
*have* to be any existing signalling standard - though using one of 
those is probably easiest, quickest (if the wars over whether/what 
subside) and least error-prone.


> 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.

Yes, this is critical.  We need to finish it.  I'd rather have it 
finished and a strong project to build a "standard" external JS library 
under way than to have the whole thing wait.  But if I had my druthers 
(what the bleep are those, anyways?) I'd have an optional signalling 
protocol available.


-- 
Randell Jesup
[e-mail]