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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 19 October 2011 23:31 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 4736B21F8AB8 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 16:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.783
X-Spam-Level:
X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 xs068Fwd4QYL for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 16:31:49 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9C21F8AAC for <rtcweb@ietf.org>; Wed, 19 Oct 2011 16:31:49 -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 p9JNWKYc004325; Wed, 19 Oct 2011 19:32:20 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 19:31:46 -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: Thu, 20 Oct 2011 05:01:39 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159AAA@sonusinmail02.sonusnet.com>
In-Reply-To: <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Gateway need and usecase [was RE: Review request forRTCWeb standard signaling protocol]
Thread-Index: AQHMjh2MKAHKdWoRPEeKqc2wy+gDJ5WEQmcg
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- 654AFE7 9 F64B@ag-pr oj ects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <CALiegfm_FN5hTyPupjOHLPwX--YPV-gewusvi9+JtV3i1ONpJw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com> <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.com>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-OriginalArrivalTime: 19 Oct 2011 23:31:46.0332 (UTC) FILETIME=[445285C0:01CC8EB7]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Gateway need and usecase [was RE: Review request forRTCWeb 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 23:31:51 -0000

Hadriel,

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
>Sent: Wednesday, October 19, 2011 10:41 AM
>To: Ravindran Parthasarathi
>Cc: Iñaki Baz Castillo; <rtcweb@ietf.org>
>Subject: Re: [rtcweb] Gateway need and usecase [was RE: Review request
>forRTCWeb standard signaling protocol]
>
>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.

<partha> I'm not saying websocket as browser-to-browser protocol. In browser-web server-browser topology, websocket helps to create two-way communication between browsers through web server. So, SDP shall be carried between two browsers using two websocket (browser1 to web server, browser2 to web server) using ROAP sort of protocol. 

In analogy, SIP protocol acts as a transport mechanism for passing SDP between two user agents (UAC & UAS) through proxy/B2BUA. Please note that browser has to no need of maintaining its own identity of the user. You may debate than the point of discussion is media control protocol and not signaling protocol. If so, we will discuss in detail to correct the terminology for common understanding. </partha>

>And it goes between the browser and a web server, not between browsers.
<partha> Yes </partha>

>What's put onto that transport socket is up to the JavaScript and web
>server code.
>
<partha> It is the open item discussion between "low level API" vs. "ROAP API" vs. any other high level API </partha>

>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.  
<partha> Here, the topology is browser--web server & SIP-proxy GW----UA. Browser shall tunnel SIP messages over websocket by which web server & SIP-proxy GW entity shall transport the same SIP message to the UA without any gateway functionality. </partha>

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

<partha> Let us take the topology of browser---web server & SIP UA GW----UA, browser & web server communication is using some signaling protocol whereas  UA to SIP-UA GW communicates using SIP. Here, I'm interested in ROAP sort of protocol to be standardized by which gateway building is easier. For this requirement, browser has to incorporate ROAP sort of protocol and not custom build signaling. </partha>

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