IETF Logo Mail Archive

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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Wed, 24 August 2011 04:38 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 EBAF921F8B02 for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 21:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.607
X-Spam-Level:
X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Gdh2xrkvsWl4 for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 21:38:38 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0850821F8AFC for <rtcweb@ietf.org>; Tue, 23 Aug 2011 21:38:37 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7O4dkVZ004565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 23:39:46 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7O4djXk008321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2011 23:39:46 -0500
Received: from [135.244.192.104] (faynberg.lra.lucent.com [135.244.192.104]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7O4dhks024288; Tue, 23 Aug 2011 23:39:44 -0500 (CDT)
Message-ID: <4E54808F.4000805@alcatel-lucent.com>
Date: Wed, 24 Aug 2011 00:39:43 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
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>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com>
Content-Type: multipart/alternative; boundary="------------060201090000090906030102"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: 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]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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, 24 Aug 2011 04:38:40 -0000

Actually, I don't think that the "must not" decision has ever been made 
by the WG. In fact, two implementation reports from the last meeting 
cited SIP implementation...

I actually thought that the need for supporting SIP in the browser was 
well articulated in Quebec...

Igor



On 8/23/2011 8:57 PM, Ravindran Parthasarathi wrote:
>
> I agree with Igor.  It will be good in case the discussion in the line 
> why SIP MUST NOT be used for browser. I guess that the following are 
> not the reason for not selecting SIP:
>
> 1) Memory usage in browser is not the limiting factor for SIP. I know 
> of the SIP application which works well in embedded device with 16MB RAM.
>
> 2)In case the idea is to use the simple alternative protocol for the 
> basic dialog between browser to browser. It is possible for the same 
> protocol to become as complex as SIP in 5-10 years while adding more 
> feature or services.  We end-up with two protocol for real-time 
> communication from IETF and interact through gateways.
>
> 3)As per IETF recommendation,  standalone application in endpoint has 
> to use SIP for real-time communication whereas the same application 
> running in browser has to use RTCWeb recommended protocol. It is tough 
> for each application to support both protocols or its related 
> infrastructure to make it work. Or the intention is not to use SIP 
> anywhere in endpoint?
>
> I'm interested in hearing the reasons for why SIP MUST NOT be used in 
> browser.
>
> Thanks
>
> Partha
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *Igor Faynberg
> *Sent:* Wednesday, August 24, 2011 2:09 AM
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Remote recording - RTC-Web client acting as 
> SIPREC session recording client
>
>
>
> On 8/23/2011 1:50 PM, Hutton, Andrew wrote:
>
>
>
> ...
>
>
>
> What I heard a number of times at IETF81 is that what people want is 
> to build innovative new applications with a real time media enabled 
> browser and to it seems clear to me we need a browser API which is 
> flexible and enables applications to do clever things with media 
> streams. So exploring some use cases which require the browser to 
> duplicate and copy media streams is a good idea.
>
> Indeed the browser API must be flexible and it must enable 
> applications.  Strong ++ on that.
>
> Inasmuch as we, in the IETF, are not really in control of API, to 
> ensure its flexibility we can only make the right protocol 
> selection.   To this end, the worst thing would be trying to reinvent 
> the wheel.  People have been working on SIPREC for more than a year 
> now--would it be not wise on our part to take the output of that work?
>
> Overall, even if the browser does not support the full-blown SIP, I 
> think it must support some parts of it (REFER and SUBSCRIBE/NOTIFY, 
> for one thing) in order to enable flexibility.
>
> A few thousand messages ago, I asked how (asynchronous) notifications 
> could be implemented without having SIP in the browser, and I don't 
> think we had a sufficient discussion.
>
> Igor
>

v2.23.0 | Report a Bug | By Email