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

[Dzonatas Sol <[e-mail]>]

On 08/25/2011 10:14 AM, Matthew Kaufman wrote:
> 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.


Or, ... picture in picture capability.



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

The internet does not end at hyper-commercials over your regularly 
broadcasted network series.

Maybe browsers should be aware of the ads in prime schedules; pinpoint 
that junction.



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


My tone-deafness still desires "crystal-clear auido" (above 192Kbps per 
speaker), yet the browser narrowed that down to 192Kbps per stream and 
then that divides furthers into only some fraction per speaker. This has 
been hell with dysfunctional lectures due to sound quality, especially 
when ad-streams appear after links of interest activate.

Each speaker needs it's own IPv6 address, so we should imagine the 
browser provided by the speaker device, and paravirtualize for multiple 
speakers.

Oh the days of elementary schools that use any speaker as two way 
communication seems almost over.



>
> Matthew Kaufman
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant