Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client]

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 12 September 2011 18:55 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 7AF2C21F8CB7 for <rtcweb@ietfa.amsl.com>; Mon, 12 Sep 2011 11:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level:
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 KFfeXJV2venc for <rtcweb@ietfa.amsl.com>; Mon, 12 Sep 2011 11:55:44 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6260D21F8CB2 for <rtcweb@ietf.org>; Mon, 12 Sep 2011 11:55:37 -0700 (PDT)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8CIw77W011250; Mon, 12 Sep 2011 14:58:07 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 14:57:37 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC717D.D4DCEB1E"
Date: Tue, 13 Sep 2011 00:27:34 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0AA2@sonusinmail02.sonusnet.com>
In-Reply-To: <1D062974A4845E4D8A343C6538049202065582FF@XMB-BGL-414.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client]
Thread-Index: Acxt9AbN3JhWXoAGQEWrQ9SN744t+wARGUtgAMkSJbAAB9H90A==
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> <1D062974A4845E4D8A343C6538049202065582FF@XMB-BGL-414.cisco.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>, "Harald Alvestrand" <harald@alvestrand.no>
X-OriginalArrivalTime: 12 Sep 2011 18:57:37.0073 (UTC) FILETIME=[D6840A10:01CC717D]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client]
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, 12 Sep 2011 18:55:49 -0000

Hi Muthu,

 

Browser is yet another application in the system which has the
programming environment using Javascript.  I explained my point of view
in another mail thread:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. My
proposal is similar to SIP stack with C or C++ API but RTCWeb API is
designed based on Javascript. Like normal SIP stack, the new headers
shall be added by the use of Javascript API. SIP stack in browser shall
composes of transaction layer, encoding & decoding of the SIP message,
and UAC & UAS functionality mentioned in RFC 3261. I agree that agreed
upon NAT traversal mechanism of signaling protocol has to be supported
for RTCWeb.  Jquery library shall be built for the high level API's.

 

These sort of SIP framework will scale for any sort innovative real-time
application with better performance compare to any other protocol known
in IETF. As the core SIP stack is build within browser, javascript
programmer will focus on application and not on the protocol
intricacies.

 

Thanks

Partha

 

From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] 
Sent: Monday, September 12, 2011 8:52 PM
To: Ravindran Parthasarathi; Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote
recording - RTC-Web client acting as SIPREC sessionrecording client]

 

Asking for the browser to support SIP is like asking for the OS kernel
to support 100s of SIP specs to cater to various kinds of applications,
instead of implementing what portion of SIP you care about in the
application itself -- it just doesn't look scalable. Even if you want to
experiment with a new SIP header you would have to wait for the browser
vendor to release the new version of the browser or make changes to the
browser code yourself, severely hampering application development.

 

Muthu

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
Of Ravindran Parthasarathi
Sent: Thursday, September 08, 2011 8:44 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote
recording - RTC-Web client acting as SIPREC sessionrecording client]

 

Harald,

 

I'm proposing for "SIP UA framework for RTCWeb browser", the framework
provides Javascript API. In case you mean the same as "SIP lite". I'm
fine with it. SIP UA framework helps to support two-party communication
from RTCWeb browser and uses HTTP as presence or configuration
interface. 

 

As I mentioned in the another mail, I'm talking about INVITE subset of
RFC 3261 in browser.  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Thursday, September 08, 2011 12:23 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

 

On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: 

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant
with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also
agree with you that browser-to-browser communication, I could not see
the strong reason for supporting S/MIME. As part of the RTCWeb
architecture & solution, we will able to explore the SIP UA requirement
for making browser SIP compliant.

So you're advocating for creating a "SIP lite" subset that RTCWEB
browsers implement.
I think we have been down this road before, and it's not a happy one.
But sure - if you want us to implement some part of SIP, *please start
stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP
UA application, forked response will be rejected with CANCEL in browser
without Javascript intervention. The main requirement is to build the
right SIP UA framework in browser by which Javascript developer will be
able to use to the maximum extent without impacting the basic 2 two
party communication in the internet.  

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel
a modern exchange in web world (Plain Old Telephony System phone with
exchange architecture). I think so because POTS phones are dumb which
does not know its identity and every event like offhook, onhook has to
passed to exchange (webserver) whereas RTCWeb client (browser) has to
pass every event to webserver and webserver has whole intelligence to
make it work.

Don't forget that the RTCWEB client (the browser) contains an open,
fully programmable application platform - the Javascript engine. That's
a HUGE difference to the POTS phone.

I got this feel more when someone is talking about MEGACO or MGCP
between RTCWEB client & webserver. My understanding is that SIP does not
fit well to legacy telephone-based paradigm by any means but MEGACO or
MGCP are the better choice which maps to SS7 architecture well. I'm
interested in seeing RTCWeb client perform the basic routing rather than
webserver does the routing on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype
or Google hangout) communication, there will be no need of signaling but
I'm interested in communication with one of the Google real-time user in
internet without having any Google id.  I believe that SIP will make it
work.

If by saying "the Google real time user in Internet", you mean a Google
Talk user, you have that already. It's called Google Voice. It uses SIP,
but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we
don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote: 

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative dependencies including S/MIME.
It's not a small dependency.





The basic reason for asking SIP is to make the basic call works between
browser to browser across web servers. Without SIP in browser, it is not
going happen. Innovative application is going to be proprietary whether
it is HTTP or SIP or any other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more intelligence compare to dump signaling mechanism
like MEGACO and browser acts as MG. 

Why does that "intelligence" need to be in the browser, rather than in
the Javascript?



The importance of basic call interop is that there is no need of many
individual id like skype id, Google id  and yahoo id by everyone in the
world to communicate others. I wish to have single id like e-mail id to
be maintained by browser-to-browser users to communicate with others. 

This only makes sense for applications that fit the "call an identified
party" paradigm.



SIP helps to interop for basic call with other existing realtime
application in Enterprise & Telecom provider.

There is no need to build two different signaling logic in VoIP servers
for each service. Your own example of Bridge line appearance will need
two implementation by the single vendor because desktop application or
hardphone implementation based on SIP and browser based implementation
is depend on HTTP metadata. It is possible to avoided by having one
signaling protocol.

One protocol can be achieved by multiple applications choosing to
implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the
browser.



 

In RTCWEB does not standardize the signaling protocol interface between
browsers, the interop across webservers is next to impossible and it
will be restricted to single webserver (company) only. Please let  me
know in case I'm missing something here.


I think the main thing you are missing is that there are many
applications that people want to build on top of RTCWEB that are not
telephones, and will not fit with telephone-based paradigms.