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

Iñaki Baz Castillo <ibc@aliax.net> Mon, 17 October 2011 17:19 UTC

Return-Path: <ibc@aliax.net>
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 5223F21F8CB6 for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 10:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 y3vVzV-7-qlx for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 10:19:19 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A95D621F8CB5 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 10:19:19 -0700 (PDT)
Received: by vws5 with SMTP id 5so3351284vws.31 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 10:19:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.35.34 with SMTP id e2mr20941767vdj.52.1318871959042; Mon, 17 Oct 2011 10:19:19 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 10:19:18 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com>
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> <2E239D6FCD033C4BAF15F386A979BF51159950@sonusinmail02.sonusnet.com>
Date: Mon, 17 Oct 2011 19:19:18 +0200
Message-ID: <CALiegfmmSN51bp_-NFVfOwPa3DfYGxkqGYZxuDdyJ-mq+vu-nw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 17:19:20 -0000

2011/10/17 Ravindran Parthasarathi <pravindran@sonusnet.com>;:

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

I argue that it *works* and it is *not* an overkill.


> All the working stuff is not good.

Are you asserting that my software is not good??? who are you to say that???
Have I said that most probably all the software you have coded sucks?


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

So, why do you tunnel SIP over UDP or TCP? Instead create a new
transport level protocol on top of the IP layer and call it
SIP-Ravindran.



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

ROAP is just about negotiating media! You still need a signaling
protocol (for example to tell the server "who you want to call"). Such
signaling protocol can be a custom JSON over WebSocket, or can be SIP
over WebSocket or whatever over WebSocket (or over HTTP with Comet).

And you still don't understand that WebSocket is not an application
protocol, but a transport protocol. You insist in saying "Websocket
with offer/answer (ROAP)", so how to signal the destination of the
audio/video call? You need a WebSocket subprotocol on top of the
WebSocket transport for that, for example *SIP* (or whatever you
choose).


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

Ok ok, say what you want (the same again and again). Good luck and bye.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>;