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, 07 September 2011 16:52 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 6D5FF21F8C72 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 09:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 A85Heki8HlXE for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 09:52:02 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5421F8C3A for <rtcweb@ietf.org>; Wed, 7 Sep 2011 09:52:02 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p87Grp4n014090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 11:53:51 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87Grofp007614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2011 11:53:51 -0500
Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p87GrnmI009196; Wed, 7 Sep 2011 11:53:50 -0500 (CDT)
Message-ID: <4E67A19D.2070409@alcatel-lucent.com>
Date: Wed, 07 Sep 2011 12:53:49 -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: Matthew Kaufman <matthew.kaufman@skype.net>
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>
In-Reply-To: <4E668FB3.9020601@skype.net>
Content-Type: multipart/alternative; boundary="------------080906060506080300000004"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
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, 07 Sep 2011 16:52:03 -0000

Not that I disagree with any single thing that  Matthew said in his 
detailed respond, which I very much appreciate, but

1) I don't see why any other protocol will be easier to change a priori 
in order to meet the "innovation" requirements (I use quotes because I 
believe we need to see actual requirements before deciding that any 
protocol needs to change)

2) I believe we must address compatibility. For instance, with so much 
investment in by mobile operators in SIP-based IMS, the wireless 
handsets need to support it.

There are two approaches:  One, which Justin just mentioned is to rely 
on WebSocket (this is actually what I wrote about a while ago);  the 
second is to put a core SIP skeleton in the browser so that the actual 
headers can be completed by an application.

I think that we ought to investigate both (in my opinion, the second one 
will make life easier for developers).

I wonder if we can agree on a requirement that the browser must have 
sufficient set of capabilities to support development of SIP in the 
application.  Ultimately, this is what I want to ensure.

Igor



On 9/6/2011 5:25 PM, Matthew Kaufman wrote:
> On 9/6/11 6:13 AM, Igor Faynberg wrote:
>> I find this reasoning hard to understand.  First, the SIP standard 
>> has been around for a decade. What new standardization is needed?
>
> The issue is whenever you wish to innovate and add functionality.
>
> See the long, long list of RFCs that extend SIP. For some examples:
> RFC3515 - Refer method
> RFC3842 - Message waiting
> RFC3891 - Replaces header
> RFC3911 - Join header
> RFC3960 - Early media
> RFC4411 - Reason header for preemption
>
> Never mind all the things that aren't even finished...
>
> draft-ietf-bliss-shared-appearances
> draft-ietf-bliss-call-park-extension
>
> true bridged line appearances
>
> etc
>
> etc
>
> If all you want is a basic point-to-point phone, there's a short list 
> of RFCs you implement and you're done. But that isn't a platform for 
> innovation... it is just a phone.
>
> Matthew Kaufman
>