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

[Iñaki Baz Castillo <[e-mail]>]

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.

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

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).



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. WWW is a jungle, trying to mandate something never works.
And I don't want to be limited by the basic features that your "RTCWeb
standard signaling protocol" would provide.


>   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.



-- 
Iñaki Baz Castillo
<[e-mail]>