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

"Avasarala, Ranjit" <> Mon, 17 October 2011 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B10D21F8C80 for <>; Mon, 17 Oct 2011 10:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yyCxFkbKTTzQ for <>; Mon, 17 Oct 2011 10:13:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D6FD921F8C7D for <>; Mon, 17 Oct 2011 10:13:15 -0700 (PDT)
Received: from ([fe80::c4c3:4566:8b3b:ec85]) by ([fe80::5efe:]) with mapi; Tue, 18 Oct 2011 01:13:13 +0800
From: "Avasarala, Ranjit" <>
To: Ravindran Parthasarathi <>, Iñaki Baz Castillo <>
Date: Tue, 18 Oct 2011 01:09:26 +0800
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQAAJDGiU=
Message-ID: <>
References: <><><><><><><><><><><><><><> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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, 17 Oct 2011 17:13:21 -0000

Hi Partha

Though I agree with you that SIP over Websockets is an overkill on web browsers, there is a need for some kind of signaling protocol for communicating offer / answer model between 2 web browser clients.  This was one of my comments on Inaki's SIP over Websockets transport.  

My point is there is a need for some kind of signaling protocol to be used over Websockets - be it SIP or XMPP -  but these should be used as Websocket sub protocol.

From: [] On Behalf Of Ravindran Parthasarathi []
Sent: Monday, October 17, 2011 10:30 PM
To: Iñaki Baz Castillo
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

The point to be noted is folks put forth the same argument again & again..each time, it is not possible to come up new answer ;-) I noticed often you complain as if your important is missed out. We are arguing only about "nothing" vs "something" as a RTCWeb signaling protocol.

I clearly explained why SIP over websocket is an overkill in the below mail thread. Please read it and don't argue that it is working. All the working stuff is not good. Infact for any protocol, the first idea pop-up is to tunnel the complete inside (For Ex: ISUP over SIP) but always better ways to solve it.

I think that you confusing the argument with script & protocol. I agree that WWW world works with PHP for server side and Javascript, CSS for client side but I'm talking about HTTP protocol in case of legacy web. Of course, HTTP is not designed for real-time communication. So, we need some signaling protocol like Jingle, Websocket with offer/answer (ROAP) to make it work. Let us talk about the protocol and not about the programming environment.

The base idea of defining the protocol is to provide the basic building blocks and new service shall be developed using these building block. In case basic building block is well defined, building the new service will not be impossible. Normally, standard protocol will undergo through review which the basic new service needs.

I'm talking about the performance because I know that success story SIP written in C over SIP written in Java. In case you argue for SIP plugin vs native SIP, the performance may not be much difference. Also, the download of the entire protocol is worse than in-build protocol by any means.


>-----Original Message-----
>From: Iñaki Baz Castillo []
>Sent: Monday, October 17, 2011 9:21 PM
>To: Ravindran Parthasarathi
>Cc: Tim Panton;
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>2011/10/17 Ravindran Parthasarathi <>:
>Again the same...
>Ravindran, you are repeating the *same* arguments in different
>mails/threads. You always *ignore* and don't reply to responses given
>to your arguments. You are also manipulating some given responses by
>making them to look as if their content agree with your insistent
>You are trying to manipulate this WG and that is dishonest. STOP please.
>Unfortunatelly for you, your mails will always receive the deserved
>> <partha> I’m not favor Inaki solution of SIP over websocket because it
>> overkill for signaling protocol.
>Demonstrate it !!!
>I know that SIP over websocket is NOT an overkill (because I *use*
>it). You DONT KNOW the opposite. You CANNOT assert the opposite.
>Stop lying please!
>> Websocket solves routing issues between
>> browser-webserver- browser, so the lightweight protocol over websocket
>> be sufficient and there is no need of complicated SIP based Javascript
>> stack.
>Use whatever you want but don't force me to use what you want. Neither
>insist on creating a "default signaling protocol" for the reaons given
>1000 times in this maillist (those reasons you ignore again and again
>and you will NEVER reply to).
>> Also, I’m not believer of the downloading complete signaling protocol
>> because it will delay the setup time which is crucial in lot of real-
>> application. Of course, it may not be critical for free application
>but not
>> for professional services.
>So you don't understand how the WWW works. The user visits a web page,
>the browser downloads all the HTML, CSS, images and JavaScript stuff
>and, *after that*, the web application is ready to be used. It does
>not depend just on having a signaling protocol built-in the browser.
>Now the problem is downloading a ~150KB JavaScript file??? There are
>images taking more space in lot of webs!
>> AFAIK, signaling protocol codebase expands very quickly with the
>addition of
>> new services and leads to more delay in the setup of the session.
> </partha>
>And how is supposed your proposed "default signaling protocol" to
>handle those "new services"? If you try NOW to make a "default
>signaling protocol" for RTCweb that means that you MUST know *NOW* all
>the possible requirements of any RTCweb future communication. You
>don't know them, I don't know them, nobody knows them!
>Iñaki Baz Castillo
rtcweb mailing list