Re: [rtcweb] Gateway need and usecase [was RE: Review request for RTCWeb standard signaling protocol]

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 19 October 2011 05:11 UTC

Return-Path: <HKaplan@acmepacket.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 52BD811E8080 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 22:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level:
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599]
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 R5WAcuEbGuKI for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 22:11:31 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55011E8073 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 22:11:30 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 19 Oct 2011 01:11:26 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 19 Oct 2011 01:11:26 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Thread-Topic: [rtcweb] Gateway need and usecase [was RE: Review request for RTCWeb standard signaling protocol]
Thread-Index: AQHMjh2MKAHKdWoRPEeKqc2wy+gDJw==
Date: Wed, 19 Oct 2011 05:11:25 +0000
Message-ID: <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.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><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-proj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <CALiegfm_FN5hTyPupjOHLPwX--YPV-gewusvi9+JtV3i1ONpJw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <728CEA80883FF741A745AF020FB92E67@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Gateway need and usecase [was RE: 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: Wed, 19 Oct 2011 05:11:32 -0000

Hi Partha,
comments inline

On Oct 18, 2011, at 11:32 PM, Ravindran Parthasarathi wrote:

> It is not that I'm interested in RTCWeb gateway but it is the best known solution currently. Please look into my earlier mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html) for asking not to have gateways and the issues involved in developing gateways. But in case two protocols like SIP, websocket are started using for the signaling within the same session, the interop is possible only with gateways or tunneling wherein I prefer gateway.  

I am confused by your statements.  In the email thread you cited above, and in your draft, you imply that websocket is a signaling protocol or browser-to-browser protocol.  It isn't.  For all intents and purposes of this WG, it's a transport.  That's all.  It's like TCP, UDP or SCTP.  And it goes between the browser and a web server, not between browsers.  What's put onto that transport socket is up to the JavaScript and web server code.

I also don't understand what you mean by "interop is only possible with gateways or tunneling".  I don't see how tunneling anything solves interop of anything.  But for gateways, yes if everything spoke a standard protocol, making gateways would be easier - but it doesn't require the RTCWeb<->browser path to speak that signaling protocol; it only requires the web-server to speak it.  In fact it might not even require that - it might be possible to have a gateway be a JavaScript client too.


> I agree that the primary focus of this WG is to browser-to-browser without federation in mind. But the power of collaboration using RTCWeb will be realized in case federation protocol are used. For example, search for the keyword in Google from the Android browser, go to the website, click in the website leads to the call in the call center of the website company without involving any PSTN network. Here, website of the company acts as a service provider for the company and reduce the PSTN/SIP trunk cost drastically.

So?  How does this require a standard signaling protocol on the browser?

-hadriel