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

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

Hi Jim,

For the given RTCWeb basic communication, if some other better signaling
protocol exists, we will adopt for it. 

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Jim McEachern
>Sent: Tuesday, October 04, 2011 9:29 PM
>To: Randell Jesup; [e-mail]
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:About
>defining a signaling protocol for WebRTC (or not)]
>
>On Tue, Oct 4, 2011 at 10:43 AM, Randell Jesup <[e-mail]>
>wrote:
>
>> 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 problem with this argument is that it involves complex
functionality
>that would not be covered by basic SIP in the browser.
>Are you proposing that the full SIP stack, with support for forking,
>early media, etc. be built into all browsers?  If yes, then we are
>already at the bottom of the "slippery slope" that people fear.
> If no, then the app developer will still need to deal with this
>complexity.
>
>Am I missing something?
>
>Jim