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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 17 October 2011 21:44 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DF81F0C45 for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 14:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 210v59uXuKlJ for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 14:44:12 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 045D41F0C36 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 14:44:11 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9HLihu5002134; Mon, 17 Oct 2011 17:44:43 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com 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: <2E239D6FCD033C4BAF15F386A979BF51159954@sonusinmail02.sonusnet.com>
In-Reply-To: <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyM5Jfz3IeIkoa8S7WSCIWq+duQ2QAAeHWQAAJDGiUACYxAkA==
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><CALiegf=ejF2kUC1m=74o9eprF1M8wYtgE-Crwa1x14rzDOf+gQ@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><CAOg=WDcC9t2KhQUg0gDJ60gO_2mNyMv9HKt=otCdPDfj4TnoTg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><CABRok6mM7TfbLgGhoQvdRh1Kwoi5BhRweLcqWg7VZOFnaa8VOw@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><CALiegfmrncjsLVSiWk0tEgzwB00YaBGiqj0SDf9JTm9p1ZNoVA@mail.gmail.com>, <2E239D6FCD033C4BAF15F38 6A979BF5 1159950@sonu sinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC0980416C9DD@HKGMBOXPRD22.polycom.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Avasarala, Ranjit" <Ranjit.Avasarala@Polycom.com>, =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
X-OriginalArrivalTime: 17 Oct 2011 21:44:08.0875 (UTC) FILETIME=[E68D47B0:01CC8D15]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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.

Thanks
Partha

>-----Original Message-----
>From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com]
>Sent: Monday, October 17, 2011 10:39 PM
>To: Ravindran Parthasarathi; Iñaki Baz Castillo
>Cc: rtcweb@ietf.org
>Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
>protocol
>
>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.
>
>Regards
>Ranjit
>________________________________________
>From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of
>Ravindran Parthasarathi [pravindran@sonusnet.com]
>Sent: Monday, October 17, 2011 10:30 PM
>To: Iñaki Baz Castillo
>Cc: rtcweb@ietf.org
>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.
>
>-Partha
>
>>-----Original Message-----
>>From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
>>Sent: Monday, October 17, 2011 9:21 PM
>>To: Ravindran Parthasarathi
>>Cc: Tim Panton; rtcweb@ietf.org
>>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>>protocol
>>
>>2011/10/17 Ravindran Parthasarathi <pravindran@sonusnet.com>;:
>>
>>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
>>proposal.
>>
>>You are trying to manipulate this WG and that is dishonest. STOP
>please.
>>
>>Unfortunatelly for you, your mails will always receive the deserved
>>response:
>>
>>
>>
>>> <partha> I'm not favor Inaki solution of SIP over websocket because
>it
>>is
>>> 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
>>will
>>> 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
>>script
>>> because it will delay the setup time which is crucial in lot of real-
>>time
>>> 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
>><ibc@aliax.net>;
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb