Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Wed, 24 August 2011 09:31 UTC

Return-Path: <andrew.hutton@siemens-enterprise.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 3C70D21F88A0 for <rtcweb@ietfa.amsl.com>; Wed, 24 Aug 2011 02:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.195
X-Spam-Level:
X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599]
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 J2dBu+LvWa-O for <rtcweb@ietfa.amsl.com>; Wed, 24 Aug 2011 02:31:00 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1004E21F86B3 for <rtcweb@ietf.org>; Wed, 24 Aug 2011 02:31:00 -0700 (PDT)
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 6ABC423F0579; Wed, 24 Aug 2011 11:32:09 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 24 Aug 2011 11:32:09 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>, Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Wed, 24 Aug 2011 11:32:08 +0200
Thread-Topic: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
Thread-Index: AcxiMdnrLZ5odl+OTrqPMKk8lyAmOgABJSXAAAIvXZA=
Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31018BF6DF6@MCHP058A.global-ad.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> <4E54AB9B.9090600@jesup.org> <A444A0F8084434499206E78C106220CA0B00FDB534@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA0B00FDB534@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] 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: Wed, 24 Aug 2011 09:31:01 -0000

Randell,

I would like to make it clear that I am not saying that SIPREC is a reason for putting SIP in the browser but if SIP is not in the browser then we need to be able to build applications like a SIPREC SRC using a combination of the browser and the web application. 

Therefore I do think that the remote recording case is a useful use case to explore and should not be out of scope as it helps us understand the type of media handling requirements that the browser needs to support innovative applications.  

Of course as John stated if a decision is made to put SIP in the browser then there would be additional browser and API requirements to support SIPREC.

Regards
Andy



> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Elwell, John
> Sent: 24 August 2011 09:24
> To: Randell Jesup; rtcweb@ietf.org
> Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as
> SIPREC session recording client
> 
> Randell,
> 
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org
> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup
> > Sent: 24 August 2011 08:43
> > 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:
> >
> > > Hi,
> > >
> > > Also agree that implementing a full SIP Session Recording
> > Client (SRC) as defined ]
> > > by the SIPREC WG in to the browser would be a tall order
> > and would open the flood
> > > gates for a lot of other requests for SIP functionality in
> > the browser.
> >
> > Agreed
> >
> > > If however SIP is not in the browser then I think it is a
> > useful and interesting test case
> > > to look at whether we could build a decomposed SRC with the
> > browser handling the
> > > media and the web server handling the signalling. 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.
> > >
> > > Therefore I think we should keep explore the remote
> > recording use case further.
> >
> > My personal (not Mozilla's) opinion is that SIPREC-style recording is
> > out-of-scope,
> > and would be handled in this context by a webrtc-B2BUA (i.e.
> > something
> > that sits on the
> > signalling and media paths), or something that interacts
> > directly with
> > the app.
> >
> > What I do want to consider for in-scope are local recording options.
> > This can cover the "local
> > answering machine" case, but also "I want to record my call
> > with Dad",
> > "I want to record
> > my team's chatter in the game", "I want to interview someone for
> > genealogy research", etc, etc.
> > Yes, these can be done (poorly) by using some external app to capture
> > the screen and
> > speaker/mic audio - I don't consider that a replacement for
> > local recording.
> >
> > Local recording is far less problematical protocol-wise than
> > SIPREC, and
> > doesn't require
> > mandating SIP.
> [JRE] I am not advocating supporting SIP in the browser just for the
> purpose of supporting SIPREC SRC functionality. What I am saying is
> that if the browser is concerned only with media aspects, then only the
> media aspects of SRC functionality need to be considered in the browser
> (e.g., copying the media streams). On the other hand, if, for other
> reasons, SIP is implemented in the browser, it would require additional
> enhancements to support SIP aspects of SIPREC SRC functionality.
> 
> John
> 
> John Elwell
> Tel: +44 1908 817801 (office and mobile)
> Email: john.elwell@siemens-enterprise.com
> http://www.siemens-enterprise.com/uk/
> 
> Siemens Enterprise Communications Limited.
> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15
> 0DJ.
> Registered No: 5903714, England.
> 
> Siemens Enterprise Communications Limited is a Trademark Licensee of
> Siemens AG.
> 
> 
> >
> > --
> > Randell Jesup
> > randell-ietf@jesup.org
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb