Re: [rtcweb] Review request for RTCWeb standard signaling protocol

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

Inaki,

<snip>
" The draft just talks about supposed advantages of using a "default/standard" signaling protocol for WebRTC"
</snip>
I'm happy to hear from you that RTCWeb standard signaling protocol has some advantages. 

I thought that at least you will understand my point after looking at the draft but does not seems to be. Please note that RTCWeb standard signaling protocol is not against having proprietary protocol and I have explained in Sec 4 of the draft as 

"  The defining signaling protocol is not a hindrance for any innovative
   RTCWeb signaling protocol development as it is complementary
   solution."

I could not understand some of your argument, Please read inline for details.

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:[e-mail]]
>Sent: Monday, October 03, 2011 9:07 PM
>To: Ravindran Parthasarathi
>Cc: [e-mail]
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>protocol
>
>2011/10/3 Ravindran Parthasarathi <[e-mail]>:
>> Hi all,
>>
>> RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-
>partha-rtcweb-signaling-00) draft list the need for standard signaling
>protocol between RTCWeb client (browser) and RTCWeb server and the
>possible signaling protocol for the same. This draft is written based on
>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail
>thread discussion. Could you please provide your valuable comments.
>
>Hi Ravindran,
>
>The draft just talks about supposed advantages of using a
>"default/standard" signaling protocol for WebRTC, and clearly ignores
>all the disadvantages that people in this list has explained in
>several threads. So I must repeat them:
>
>
>1) If the browsers speak *native* SIP (or any other protocol) 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). It would be possible just in case the
>signaling protocol is HTTP or WebSocket.

<partha> I guess that you propose to have websocket or HTTP based signaling protocol and not preferring SIP. I'm ok to have any one of the standard signaling protocol and not. So, we have no disagreement at this level for the draft. </partha>

>
>2) By forcing a specific signaling protocol between rtcweb client and
>server, you force the existence of ugly signaling gateways (rtcweb to
>SIP/XMPP). 

<partha> In case you have any solution (other than SIP) in RTCWeb with any signaling gateway, let us discuss. Please don’t mentioned your websocket tunneling SIP as a solution. Even in your proposed mechanism, gateway (B2BUA) has to remove the websocket transport and forward SIP messages with appropriate changes. ISTM, you are simply arguing </partha>

Your draft shows it as an advantage:
>
>   o  Gateway for RTCWeb server and legacy signaling protocol is easy in
>      case standard RTCweb signaling protocol is used.
>
>Easy??? that should be a joke. Doing protocol conversion/gateway
>always means loss of features. If not, take any current
>JSON-AJAX-based "web softphone" in which there is a conversion from
>the custom (always custom!!!) JSON protocol to SIP protocol in a
>"special" gateway, and let me know which one allows "exotic" features
>like parallel forking or call transfer.
>

<partha> I meant for "easy" in the comparative sense. Protocol conversion/gateway does not means loss of features and this is based on my experience on gateways which supports multiple protocol namely ISDN, ISUP, SIP, H.323, MGCP, SCCP simultaneously. Websocket or HTTP will be one another addition signaling protocol in those gateway for interop with existing signaling protocol. In case you think that it is cakewalk job then you are wrong. Each protocol mapping will involve some circus during conversion like extra RE-INVITE. 

My comparison is between "your proposal custom made RTCWeb signaling to federated signaling protocol" to "RTCWeb standard signaling protocol to federated signaling protocol". </partha>


>Please, don't mandate a gateway for signalling protocol, please. I
>*do* know that SIP and XMPP can be ***fully*** implemented in
>JavaScript by using websocket as transport protocol and a SIP/XMPP
>proxy/server that also implements SIP/XMPP over WebSocket (this is not
>protocol gateway!! this is ***pure*** SIP/XMPP).

<partha> Please note that RTCWeb server in your implementation has to acts as gateway to remove websocket tunnel. Gateway includes B2BUA with different transport. And also, your argument is not related to my draft </partha>

>
>
>
>In the other side, I think you don't fully understand how WWW world
>works for years. Your draft talks about some "issues" (which IMHO are
>not issues at all), comments in line:
>
>
>> 3.  Issues without RTCWeb standard signaling protocol
>>
>>   The issues in creating non standard RTCWeb sigaling protocol are
>>
>>   o  Without RTCWeb standard signaling protocol, each website
>developer
>>      has to understand the complication of signaling protocol for
>>     making the real-time communication.
>
>For sure there will appear signalling libraries, some of them GPL some
>others not. 

<partha> GPL or not is one of the issue with 3rd party signaling libraries </partha>

WWW is a jungle, trying to mandate something never works.

<partha> I believe that RTCweb mandating (media, security) works for WWW jungle. </partha>

>And I don't want to be limited by the basic features that your "RTCWeb
>standard signaling protocol" would provide.
>

<partha> Of course, the limited feature "RTCWeb standard signaling protocol" is not for power user like you and also it does not hinder any of your activity. But I'm fail to understand your argument for not having standard signaling protocol </partha>

>
>>   o  Downloading the complete RTCWeb signaling protocol Javascript is
>>      inefficient as it impact performance and setup delay of real-time
>>      communication.  The caching of Javascript shall avoid downloading
>>      the signaling protocol in each time RTCWeb server is accessed.
>>      But the Javascript cache is possible to be removed often which
>>      leads to the impact.
>
>Ok, let me say something similar:
>
>      Downloading the complete Gmail Javascript is
>      inefficient as it impact performance and setup delay of real-time
>      communication. So we need to create a "standard webmail protocol"
>      so Gmail, Hotmail, Yahoo and all the webmail providers would use
>      them and all the browsers would natively implement it.
>
>
>>   o  Also, browser has to download each website signaling protocol
>>      indepentely
>
>Same as above. When you visit Gmail you download the complete JS code
>from Gmail. If later you visit Hotmail you download the complete JS
>code from Hotmail. That's how WWW works. Welcome.


<partha> There is no comparison between non-real time protocol and real-time protocol. I agree that non-real time WWW works in this fashion which is not appropriate for real-time application. Also, please note that number of e-mail provider to real-time application will be very different. Say I'll provide RTCWeb application in my personal website for communicating with me in my mobile.  </partha>
>
>
>
>--
>Iñaki Baz Castillo
><[e-mail]>