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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6301E21F8C1D for <>; Mon, 17 Oct 2011 10:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oiShRLnwvm-O for <>; Mon, 17 Oct 2011 10:00:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 825EC21F8678 for <>; Mon, 17 Oct 2011 10:00:11 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9HH0gv6011023; Mon, 17 Oct 2011 13:00:42 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 13:00: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="utf-8"
Content-Transfer-Encoding: base64
Date: Mon, 17 Oct 2011 22:30:06 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQ
References: <><><><><><><><><><><><><><> <>
From: Ravindran Parthasarathi <>
To: Iñaki Baz Castillo <>
X-OriginalArrivalTime: 17 Oct 2011 17:00:08.0675 (UTC) FILETIME=[39CD1B30:01CC8CEE]
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:00:12 -0000

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