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

"Elwell, John" <john.elwell@siemens-enterprise.com> Fri, 26 August 2011 07:19 UTC

Return-Path: <john.elwell@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 2CAB221F8B23 for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 00:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.149
X-Spam-Level:
X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, 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 2J29wu-6JKiA for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 00:19:34 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E286221F8B06 for <rtcweb@ietf.org>; Fri, 26 Aug 2011 00:19:33 -0700 (PDT)
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0E3821EB8448; Fri, 26 Aug 2011 09:20:46 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 26 Aug 2011 09:20:46 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Date: Fri, 26 Aug 2011 09:20:44 +0200
Thread-Topic: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
Thread-Index: AcxjSnUdKEziW3P2QE6bEV50Fy14XQAckhCQ
Message-ID: <A444A0F8084434499206E78C106220CA0B011C8FC6@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> <101C6067BEC68246B0C3F6843BCCC1E31018BF6DF6@MCHP058A.global-ad.net> <4E554BCE.2040403@alum.mit.edu> <4E56399E.2020902@alvestrand.no> <A444A0F8084434499206E78C106220CA0B011C8D3B@MCHP058A.global-ad.net> <4E5682DD.5020204@skype.net>
In-Reply-To: <4E5682DD.5020204@skype.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
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Fri, 26 Aug 2011 07:19:35 -0000

 

> -----Original Message-----
> From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] 
> Sent: 25 August 2011 18:14
> To: Elwell, John
> Cc: Harald Alvestrand; rtcweb@ietf.org
> Subject: Re: [rtcweb] Remote recording - RTC-Web client 
> acting as SIPREC session recording client
> 
> On 8/25/2011 5:51 AM, Elwell, John wrote:
> >
> > New requirements:
> > Fyy1: The browser MUST be able to send in real-time to a 
> third party media that are being transmitted to and received 
> from remote participants.
> 
> This is a bad idea.
> 
> > Ayy1: The web application MUST be able to ask the browser 
> to transmit in real-time to a third party media that are 
> being transmitted to
> 
> Yes. It should be possible for the browser to send two copies of the 
> same media to two different places, possibly even with 
> different encoders.
> 
> >   and received from remote participants
> 
> But this is a bad idea. Providing APIs that let a browser send audio 
> that is being received from the other end to a third party 
> open several 
> different cans of worms simultaneously. 
[JRE] I would assume it would be possible for an application to take previously received media from a remote endpoint and use that as the source for sending to a third party. Will there be anything to stop the application doing that? For example, would there be constraints in place to ensure that the source of media sent is an original source (microphone, camera), as opposed to a file, say? I hope not, because this would prevent me sending a pre-recorded announcement to callers, e.g., when I am not present in person.

I don't have a particular preference whether it is the browser or the application doing the relaying, provided it can be more or less in real-time.

> One is that there's 
> now another 
> path by which a user's media may be sent, possibly without the same 
> security constraints, without their knowledge. Sure, a B2BUA 
> can do this 
> as well, but it makes doing the wrong thing easier.
[JRE] There are regulations in most places that require a user to be notified if a conversation is being recorded. I don't believe it is possible to enforce such regulations technically or prevent recording in the absence of such notifications.

> 
> The bigger issue is that this essentially allows you to use a 
> browser as 
> a media relay. This will be objected to in corporate (and some 
> education) environments where there are sound reasons for disallowing 
> user applications to take advantage of a high-bandwidth connection to 
> relay media for third parties. 
[JRE] In such corporate environments, where they want recording, they could do it centrally, thereby forcing all media through a middlebox. Doing it at the endpoint removes the need for that middlebox.

> It also may result in 
> unexpected resource 
> consumption on mobile platforms, where the user is paying in 
> bandwidth 
> charges and battery life to relay media for a third party. 
[JRE] Indeed, so in this sort of environment you wouldn't want to use this capability, and if recording is required it would need to be done from a middlebox.

> And unless 
> implemented carefully, it can lead to relaying that is very 
> unexpected 
> (a banner ad that doesn't ask for permission to use your camera and 
> microphone but does relay media for a third party while running).
[JRE] Perhaps permission is needed to relay media from a third party, and likewise to relay information from a local file, etc..

> 
> Not to mention all the protocol-level implications of being an RTP 
> mixer, if we're trying to stay true to that particular choice 
> of protocols.
[JRE] Even if you do mixing (which helps save uplink bandwidth), you are not forced to use the RTP mixer model, you could use the endpoint model. So each PeerConnection would use RTP/RTCP in the normal manner, without interacting with the other one.

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.


> 
> Matthew Kaufman
>