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

"Ravindran Parthasarathi" <> Mon, 17 October 2011 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11DF81F0C45 for <>; Mon, 17 Oct 2011 14:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 210v59uXuKlJ for <>; Mon, 17 Oct 2011 14:44:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 045D41F0C36 for <>; Mon, 17 Oct 2011 14:44:11 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9HLihu5002134; Mon, 17 Oct 2011 17:44:43 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 17:44:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Oct 2011 03:13:57 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQAAJDGiUACYxAkA==
References: <><><><><><><><><><><><><><><>, <2E239D6FCD033C4BAF15F38 6A979BF5 1159950@sonu> <>
From: Ravindran Parthasarathi <>
To: "Avasarala, Ranjit" <>, Iñaki Baz Castillo <>
X-OriginalArrivalTime: 17 Oct 2011 21:44:08.0875 (UTC) FILETIME=[E68D47B0:01CC8D15]
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 21:44:13 -0000

Hi Ranjit,

I agree with you for using signaling protocol to be used over websocket.


>-----Original Message-----
>From: Avasarala, Ranjit []
>Sent: Monday, October 17, 2011 10:39 PM
>To: Ravindran Parthasarathi; Iñaki Baz Castillo
>Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
>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
>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
>>-----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
>>Unfortunatelly for you, your mails will always receive the deserved
>>> <partha> I'm not favor Inaki solution of SIP over websocket because
>>> 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
>>> be sufficient and there is no need of complicated SIP based
>>> 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