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

["Ravindran Parthasarathi" <[e-mail]>]

Hi Randell/Tim,

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Randell Jesup
>Sent: Tuesday, October 04, 2011 8:13 PM
>To: [e-mail]
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
>defining a signaling protocol for WebRTC (or not)]
>
>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.
<partha> Agreed for the federated services. I will add another diagram
with single server in the next revision </partha>

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

<partha> It is not my argument. In case some of the draft sounds so,
Please point it out and I will change </partha>

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

<partha> Agreed </partha>

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

<partha> Under Sec 4, first bullet convey the same above point. In case
the bullet text is not clear, Please let me know. </partha>

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

<partha> It is the important point. </partha>

 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.

<partha> My argument is also not for SIP. </partha>

  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.

<partha> I agree with you. I listed some of the existing signaling
protocol for the same reason which shall be integrated quickly. Most of
the existing signaling protocol is stable by now because of the usage in
other applications. </partha>

>
>
>--
>Randell Jesup
>[e-mail]
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb