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

[Matthew Kaufman <[e-mail]>]

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. 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.

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. 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. 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).

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.

Matthew Kaufman