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

José Luis Millán <jmillan@aliax.net> Thu, 20 October 2011 06:30 UTC

Return-Path: <jmillan@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 CFA5211E8083 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 23:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level:
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.438, 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 430rvr6TixaM for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 23:30:22 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F299011E8080 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 23:30:21 -0700 (PDT)
Received: by iabn5 with SMTP id n5so3364399iab.31 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 23:30:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.5.73 with SMTP id 9mr3841521ibu.60.1319092221211; Wed, 19 Oct 2011 23:30:21 -0700 (PDT)
Received: by 10.231.16.75 with HTTP; Wed, 19 Oct 2011 23:30:21 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159AAA@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> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <CALiegfm_FN5hTyPupjOHLPwX--YPV-gewusvi9+JtV3i1ONpJw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159A00@sonusinmail02.sonusnet.com> <8EBB58C3-E135-4FB4-80F2-607E82C7BA7A@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159AAA@sonusinmail02.sonusnet.com>
Date: Thu, 20 Oct 2011 08:30:21 +0200
Message-ID: <CABw3bnMR1453mSVba02sZY4fiPoQK14qBBj2CXX83uZv00dwww@mail.gmail.com>
From: José Luis Millán <jmillan@aliax.net>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Thu, 20 Oct 2011 06:30:22 -0000

Partha,

Reading your earlier mail thread
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html):

" I'm asking for the single protocol based on my gateway implementation
experience in signaling protocol like SIP, H.323, and basic of MEGACO,
Q.931 (ISDN) etc., My understanding is that mapping of between tow
protocols leads to get the common set in both protocol and under
utilization of specific protocol functionality. The mapping is not
perfect lot of times and one of the example which I know in IETF product
is RFC 3398. It is not possible in RFC 3398 to proper reverse mapping of
cause code for ISUP in case conversion in first gateway converts ISUP to
SIP, second gateway converts is SIP to ISUP, ISUP cause code value in
second gateway is not same what is received in first gateway and this
leads to lot of interop issue which includes passing of reason SIP
header with Q.931 IE recently as per IETF-80 decision (workaround bug
fix). This is not the only mapping failure which I have seen during the
gateway implementation. So, I prefer to look for the strong reason for
putting multiple protocol (SIP, websocket) as a RTCWeb architecture. "

I would like to stract this last phrase:

"So, I prefer to look for the strong reason for
putting multiple protocol (SIP, websocket) as a RTCWeb architecture. "

Still confusing concepts. Many people have already said (I don't think
this is the list where this things have to be explained..) that
WebSocket is used here as a mere transport protocol, not Singalling.

With this misunderstanding of what is being speaking here, how is it
posible this list to have hundreds of emails from you trying to
convince people to do things the way you are benefited?


rtcweb;

I call upon the list moderator to control in some way this behaviour
in favour of the mission of this mailing list.









2011/10/20 Ravindran Parthasarathi <pravindran@sonusnet.com>:
> 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>