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,

<snip> 
Ok, but such protocol should be carried within HTTP or WebSocket, rather than being a native SIP/XMPP/whatever-custom-protocol built-in the web browsers. Do we agree on this? I think the answer is "not", so please continue reading. </snip>

Your assumption is wrong here. When I ask for standard signaling protocol, websocket will be one of the alternative to considered for further discussion in case there is an agreement for having standard signaling protocol.

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:[e-mail]]
>Sent: Tuesday, September 27, 2011 1:03 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)])
>
>Hi Ravindran, comments inline:
>
>
>2011/9/26 Ravindran Parthasarathi <[e-mail]>:
>> The aim of having standard RTCWeb signaling protocol is to make basic
>dialog between two different browsers (For ex: Mozilla & chrome) user.
>
>And me and others already said that the aim of WebRTC is not
>converting web browsers into generic SIP phones capable of
>establishing a call between them without visiting the same page
>(replace "SIP" with whichever protocol).
>
>WebRTC adds value to the WWW world, so it's assumed that first of all,
>browsers visit some website, so they can get something (JavaScript
>code).
>
>
>
>> 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.
>
>Ok, but such protocol should be carried within HTTP or WebSocket,
>rather than being a native SIP/XMPP/whatever-custom-protocol built-in
>the web browsers. Do we agree on this? I think the answer is "not", so
>please continue reading.
>
>
>
>>>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>
>
>AFAIK one of the aims of WebRTC is allowing multimedia sessions within
>browsers *without* the need of external plugins (like Flash or Java
>applets).
>
>
>
>
>>>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>
>
>I'm sure that fans of XMPP would not like that (even less taking into
>account that XMPP is much more deployed in pure Internet than SIP).
>
>
>
>>>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>
>
>So you want a "built-in protocol" not to bore web developers with
>custom and complex signaling protocols, but at the same time you want
>to force them to build a hyper-complex gateway in server side. ¿?¿?
>
>
>
>>>> 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>
>
>Again: browsers MUST not *directly* interop with other browsers in the
>*signaling* plane. If two browsers visit the same page and download
>the *same* JavaScript, such JS already can say the browsers how to
>signal the media.
>
>Please, don't insist on the same again and again. There is NO need at
>all for web browsers to natively and directly speak
>SIP/XMPP/other-protocol between them. In fact, that is undesirable.
>
>
>
>>  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>
>
>Ok. But in other mails you propose that WebRTC should be an island for
>web browsers. Wouldn't that stop innovation?
>
>
>
>>>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>
>
>No. What I meant is very clear: if the signaling (or the "default
>signaling" as you propose) is not carried via HTTP or WebSocket, then
>it would require another kind of centralized server (as a SIP proxy in
>the provider side). So all those websites hosted in shared hosting
>datacenters (i.e. using a shared Apache with different virtual
>domains) would have no chance to use WebRTC. Just it.
>
>
>
>Regards.
>
>
>--
>Iñaki Baz Castillo
><[e-mail]>