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

Harald Alvestrand <harald@alvestrand.no> Thu, 08 September 2011 14:59 UTC

Return-Path: <harald@alvestrand.no>
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 ED1D621F87FA for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 07:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.058
X-Spam-Level:
X-Spam-Status: No, score=-108.058 tagged_above=-999 required=5 tests=[AWL=2.541, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 0gGP0Hn7GjNb for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 07:59:18 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 55DBF21F84DC for <rtcweb@ietf.org>; Thu, 8 Sep 2011 07:59:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DF4039E0F3; Thu, 8 Sep 2011 17:01:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFbLpVqDXrRB; Thu, 8 Sep 2011 17:01:09 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 71E4639E074; Thu, 8 Sep 2011 17:01:09 +0200 (CEST)
Message-ID: <4E68D8B5.7010602@alvestrand.no>
Date: Thu, 08 Sep 2011 17:01:09 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: igor.faynberg@alcatel-lucent.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> <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> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com>
In-Reply-To: <4E68D742.4010203@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
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, 08 Sep 2011 14:59:19 -0000

On 09/08/11 16:54, Igor Faynberg wrote:
> Well,  maybe we should take it off-line--I will be happy to explain a 
> few things in October. Just some in-line answers:
>
> On 9/8/2011 10:30 AM, Harald Alvestrand wrote:
>>> I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, 
>>> and REFER.
>> ...
>>
>> That's the commands. What are the parameters?
>
> My proposal is to populate the methods with parameters in the 
> JavaScript application.
It seems that writing up your proposal in enough detail that we can tell 
which parts you intend to have done in Javascript and which parts in 
browser code is an useful exercise, because I just don't seem to get the 
picture.
>>
>> As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY 
>> are for (I think they are just for presence), 
>
> No, no, no! Not just for presence, although it can be used for 
> presence.  These precious methods came from PINT, how could you forget 
> this!  They allow the client to subscribe for an event at the server 
> and then receive notifications asynchrously.  This specific feature 
> cannot be implemented using HTTP (just as INVITE cannot).  We used 
> them in PINT pretty much to enable the client to learn when PSTN call 
> is disconnected, but the SIP group had found many other uses later.
If the issue is getting a signal from a Web server to a client, there's 
approximately 100 ways to get notifications from the server to the 
client using HTTP (hanging GET being one of them). Now that WS is 
getting standardized, there will be 101.
>
> Again, my objective is to ensure that SIP (with all its bell and 
> whistles) can be supported by a JS application.  I am just starting to 
> study the code kindly sent my way a few minuts ago, but when I am 
> convinced that this can be done based on WebSocket alone, I will stop 
> harping on this.
>
> Igor
>