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

Iñaki Baz Castillo <> Mon, 03 October 2011 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1110221F8E2C for <>; Mon, 3 Oct 2011 13:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FJoEh2wLG+hM for <>; Mon, 3 Oct 2011 13:25:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 36F8221F8DD1 for <>; Mon, 3 Oct 2011 13:24:51 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so4839673vcb.31 for <>; Mon, 03 Oct 2011 13:27:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id cj3mr121183vcb.76.1317673673731; Mon, 03 Oct 2011 13:27:53 -0700 (PDT)
Received: by with HTTP; Mon, 3 Oct 2011 13:27:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 03 Oct 2011 22:27:53 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Ravindran Parthasarathi <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Oct 2011 20:25:27 -0000

2011/10/3 Ravindran Parthasarathi <>:
> <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.

Hi Ravindran. I've never said that. I just said that your draft "talks
about *supposed* advantages. More inline.

> 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 will comment about this at the end of this mail.

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

Not exactly. I propose nothing. I don't propose a "default signaling
protocol" at all (reasons in the rest of the mail).

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

First of all, WebSocket is a *transport* protocol, rather than an
application protocol as you suggest in different comments. The
separation between a transport protocol and an application protocol is
just logical: A transport protocol carries messages of an application

WebSocket by itself is just nothing. The developer must use or create
a WebSocket subprotocol by defining messages to be send via the
WebSocket connection, and such protocol is coded in JavaScript!. So
WebSocket is a transport protocol as UDP or TCP. Or would you consider
UDP over TCP as an application protocol?

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

Again: WebSocket is not a signaling protocol. IMHO you should take a
look to

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

I just think that the best way to interoperate with protocol A is by
using protocol A, rather than using protocol B and a gateway A/B.

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

I've already explained that WebSocket must be considered a transport
protocol, so a SIP proxy implementing SIP over WebSocket *transport*
is not a B2BUA. It's the same concept as a common SIP proxy
implementing UDP and TCP, and allowing a request to come via UDP and
leave the proxy via TCP. I've just added a new transport: WebSocket.
That changes nothing from the point of view of what a SIP proxy is
supposed to do. It's not a B2BUA.

> And also, your argument is not related to my draft </partha>

IMHO it's related as your draft assumes the need for a gateway
performing application gateway.

> WWW is a jungle, trying to mandate something never works.
> <partha> I believe that RTCweb mandating (media, security) works for WWW jungle. </partha>

Yes, but you are trying to mandate something that is unnecessary,
since what you propose can already be done by custom JavaScript. About
your text:

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

It does not convince me since in other mails you have suggested that
WebRTC should just allow communication between browsers.

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

Having a standard signaling protocol meanst that browsers must
natively implement it, and I think that's unnecessary. In the same way
you could expect that something like jQuery should be part of the
JavaScript stack in browsers, but it is not, and *lot* of people uses
jQuery, and they can use a newer version of jQuery when it's available
without having to wait for a new version of *every* webbrowsers. The
web developer just needs to include the desired jQuery version in its
web application and it's done. If jQuery would be part of the JS
stack, then a web developer would never know wheter their clients use
a browser that implements jQuery version X or Y. That stops
innovation, and the very same for a "default rtcweb signaling

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

Open Gmail, open, open Facebook, open any web page in which
there is a *realtime* chat, and voilá, you get a realtime protocol.
Fortunately all these apps could use WebSocket soon rather than
dealing with ugly HTTP long polling or HTTP Comet. In all those cases,
the realtime protocol is implemented using a custom JavaScript code
that the browser MUST download. The same when WebSocket arrives since
WebSocket is just a transport protocol and it requires custom
JavaScript code implementing a real protocol on top of it.

Now a suggestion: instead of trying to propose a default rtcweb
signaling protocol built-in the web browser, why don't you create a
signaling protocol on top of WebSocket (for example using JSON
messages exchange) and publish it? If for example such protocol or
implementation has a bug, you can fix it by publishing a new version,
and the web developers will just need to provide the new JavaScript
file, rather than having to wait for *all* the web browsers in the
world to fix the bug and *all* the humans in the world to upgrade
their web browsers. Wouldn't that stop innovation??


Iñaki Baz Castillo