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

[Tim Panton <[e-mail]>]

On 4 Oct 2011, at 15:43, Randell Jesup wrote:

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

Here we disagree on 3 fronts :
1) whilst people will do access-the-PSTN apps they will be wasting their time (IMHO) The growth/interesting area in RTC is not PSTN interconnect.
I made the mistake of betting the farm on PSTN interconnect being the dominant use of an in browser audio component. I was wrong - people used 
the component for  collaboration, dating, games etc - but hardly at all for PSTN. Look at vivox, skype and the rest - PSTN access is a small and shrinking use case. We should not let it sway us unduly.

2) Phono's javascript exists and is open source - it  works and is based on xmpp. 
https://github.com/phono/PhonoSDK/tree/master/modules/phono-js/src/main
I'm not claiming that it solves _every_ problem, that it has the ideal abstraction,  
or that it is compatible with the yet unwritten RTCweb spec, but it does serve 
as a proof by example.

3) the moment RTCweb settles, the asterisk, freeswitch, YATE etc communities will write a native channel drivers for it. Those platforms
have built in http servers, channel independent RTP modules and protocol independent frameworks that can be leveraged to
ease the pain of supporting a new protocol.
I've investigated doing one for Asterisk SCF - it looks like a couple of weeks work. Minimal JS needed and certainly no sip.js 

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

But that thought and experience are (I'd argue) irrelevant, or at least need a deep review because it isn't the same problem as we
solved last time. Worse, we are only guessing what the problem is. Who says that the forking problem even exists if you let go of the 
device/call/line centric PSTN model - I'm not convinced.

> 
> 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")

(see phono)

> 2) The quality and testing of these libraries is unlikely to equal that of existing signalling stacks available freely for quite a while

True, but you may be underestimating the difficulty of taking an existing native SIP/IAX/XXX stack and adding it safely to a browser framework.
 Browsers have strict threading and memory requirements (especially when it comes to access to the DOM/JS) 
- and that's without event starting on the security issues. 
By minimizing the native code and maximizing the javascript  we put more of the code on the 'already sandboxed' side of the fence.
Also I doubt that the browser makers will all go for the same pre-existing-native stack, for license reasons if no other. Then you are faced
with the usual interop problems between 4 different  stacks implementing different subsets of a standard.

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

(following your example, which I don't wholly subscribe to for reasons mentioned above)

The users won't exactly 'download' jSIP.js - the web services they use will include it. 
The site's web developers will reference a version that works with the version of asterisk (say) that they have 
installed on their server. The last thing they want is the browser to go spontaneously fixing protocol implementation bugs when
they have carefully patched the asterisk to cover up the problem.

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

And I fear that it opens a different, more opaque, can of worms by encouraging these little-guys to adopt SIP/SER/asterisk just 
to get in-game push-to-talk.

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

I have no problem with an optional signalling library, I just rather it to be a javascript example not a baked in native default.

Tim.