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

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

Hi Inaki,

Your vision of Javascript signaling protocol is exactly opposite to Jozsef proposal of having XML mechanism. Please try to understand that everybody is not excited to develop their own signaling protocol even though you consider it as a freedom world. I have insisted multiple time that I'm asking for one RTCWeb signaling protocol across browser vendor but it is not required to be SIP. The aim of having standard RTCWeb signaling protocol is to make basic dialog between two different browsers (For ex: Mozilla & chrome) user. 

Having seeing the list discussion on signaling intricacies in this alias, it is no point in asking each web developer to create their own signaling protocol. It is better for IETF to recommend one protocol which best suit RTCWeb signaling requirement and best simple API for signaling protocol will be defined by W3C.

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:[e-mail]]
>Sent: Tuesday, September 27, 2011 12:15 AM
>To: Ravindran Parthasarathi
>Cc: Jozsef Vass; Saúl Ibarra Corretgé; [e-mail]
>Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol
>[was RE: About defining a signaling protocol for WebRTC (or not)])
>
>2011/9/26 Ravindran Parthasarathi <[e-mail]>:
>> What level of interop is required for the online registered players?
>All RTCWEb browser (Mozilla, chrome, IE) player should be able interop
>without need of browser specific JS or plugin.
>
>Ravindran, you insist of that even when multiple comments tell you the
>opposite. If Mozilla, Chrome or IE browsers are visiting the *same*
>website then they *already* share the *same* JavaScript (loaded from
>the website) so they can signal the media thought the web server (by
>using HTTP or WebSocket) as defined in the retrieved JavaScript code.
>This is easy to understand IMHO and this is how WWW works for years =>
>interoperability between clients visiting the same website. Period.
>
<partha> WWW works with plugin. If you think otherwise, there is no much
Work for IETF in this WG </partha>

>If the browsers speak *native* SIP (as you suggest in many threads)
<partha> I asked initially because it is defacto recommended IETF 
real-time protocol </partha>

>then the web server is unaware of what is happening at media level
>between the visitors (because the web server, where the application
>logic is, does not see the signaling traffic).
<partha> IMO, it is your bad assumption. There are "n" number of way to
Design server even if they speak different protocol which is a common 
Practice in gateway implementation </partha>

>
>
>> Here, there is a need of defining the common underlying protocol
>(which is not RTCWeb developer concern).
>
>No, it's not.
<partha> There is a strong need to define signaling protocol which helps
Browsers to interop and also reduce the complexity for web developers </partha>

 You can repeat 1000 times by ignoring any rationale
>already replied to you in multiple threads. But that changes nothing.
>WebRTC does not need native SIP or native XMPP/Jingle spoken by web
>browsers. In fact, that would stop innovation, would mandate website

<partha> I have clarified multiple time that your innovation is not going 
to stop by defining standard signaling protocol. Let say X protocol become
standard signaling protocol which does not mean that you should not 
implement your SIP over websocket using Javascript. So, this is false 
propaganda by few folks that it would stop innovation. </partha>

>admins to provide a SIP/XMPP server within their infrastructure (how!)
>and would make WebRTC unfeasible in shared web hostings.
<partha> In case you talking about manageability of the servers, lot of more
Stuff involved than simple protocol decision </partha>


>
>
>The only point of discussion here is the requirements for the custom
>JavaScript code retrieved from the web server in order to interoperate
>with the WebRTC stack in the browser, and the JS API defining the
>methods to read and generate media descriptions (like-SDP) that would
>be sent to the other peer via the signaling path (HTTP/WebSocket).
>
>
>Regards.
>
>
>
>--
>Iñaki Baz Castillo
><[e-mail]>