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

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

Hi Saul,

I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around. 

I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser or browser-to-other end-point to know whether parallel universe has to be build or not. In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways. Let us assume that the intention of RTCWeb is to create island of browser devices even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution.

Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using Javascript or plugins but interop and better performance is not guaranteed.

Thanks
Partha

>-----Original Message-----
>From: Saúl Ibarra Corretgé [mailto:[e-mail]]
>Sent: Thursday, September 15, 2011 1:23 PM
>To: Ravindran Parthasarathi
>Cc: Iñaki Baz Castillo; [e-mail]
>Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or
>not)
>
>Hi,
>
>[snip]
>
>> My point is that the default signaling protocol has to be supported in
>RTCWeb client which should not be downloaded in runtime to make the
>dialog between two RTCWeb client. I asked for SIP initially as SIP is
>the de-facto protocol and mostly deployment. I agree with Peter & others
>that websocket could be another alternative in the web deployment. In
>case required, I'll come up the write up to show the needs of default
>signaling protocol for making dialog between browser to browser.
>>
>
>Do you mean there should be a 'default signaling protocol' on every
>browser? I'm not sure I'd like that. I (personally) see RTCWeb as a
>framework on top of which we can build RTC applications. The fact that
>one would use SIP and someone else uses something else is not crucial,
>IMHO. Now if some new simplified protocol is chosen for browser-to-
>browser communication we'd have yet another island of devices (browsers
>in this case) to which we'd need to gateway somehow.
>
>[snip]
>
>>>
>>> WebRTC defines multimedia capabilities for web-browsers and mandates
>>> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
>>> aim of these protocols is to enable multimedia streams between a
>>> web-browser and other endpoint (which could also be a web-browser).
>>>
>> <partha> I hope that the aim of the protocols is to enable multimedia
>stream between browser to browser only. In case browser to other end-
>point is outside the scope of RTCWEb. </partha>
>>
>
>Well, why build a parallel universe just for the browsers? If RTCWeb
>would only define the media plane and developers themselves can choose
>the signaling protocol, the integration with existing communication
>systems (using SIP or XMPP for example since they are the most used
>ones) would be pretty straight-forward.
>
>My 2 cents.
>
>
>Regards,
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>