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

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: Matthew Kaufman [mailto:[e-mail]] 
> Sent: 25 August 2011 18:14
> To: Elwell, John
> Cc: Harald Alvestrand; [e-mail]
> 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: [phone] (office and mobile)
Email: [e-mail]
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
>