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

["Ravindran Parthasarathi" <[e-mail]>]

Matthew,

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Dzonatas Sol
>Sent: Thursday, August 25, 2011 11:39 PM
>To: [e-mail]
>Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as
SIPREC
>session recording client
>
>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.
>>
[Partha] Please provide good idea if you have any.

>>> 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.
[Partha] In case your concern is "security consideration", let us work
for it to solve the security issues. Please specific the list of
security concerns related to this.

>>
>> The bigger issue is that this essentially allows you to use a browser
>> as a media relay.
>
[Partha] why it is issue?
>
>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. 
[Partha] It is just a policy mechanism within the particular corporate
or education environment. Of course, any real-time application will
undergo the same policy constraints. For example, I know of couple of
corporate which does not permit Skype audio application to execute
within the corporate because it consumes lot of bandwidth. IMO, the
bandwidth consumption should not be stopping factor for adding the
requirement.

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).
>
[Partha] Same banner ad may send stream from your camera and microphone
when you are not ask for it as it is malicious script. I agree that you
concern is related to security in browser but your concern is not
related to recording requirement. Please clarify in case I'm missing
something.

>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
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb