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

"Ravindran Parthasarathi" <> Thu, 25 August 2011 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC49021F8BEC for <>; Thu, 25 Aug 2011 11:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h3zMaugIVj6l for <>; Thu, 25 Aug 2011 11:36:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E0FA021F8BEB for <>; Thu, 25 Aug 2011 11:36:28 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p7PIc9t3022826; Thu, 25 Aug 2011 14:38:09 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 14:29:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Aug 2011 23:59:30 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
Thread-Index: AcxjUdXyxz18SiILSee/YnVQ5vVDQAAAP3CQ
References: <> <> <> <> <> <> <> <> <> <> <><> <>
From: "Ravindran Parthasarathi" <>
To: "Dzonatas Sol" <>, <>, <>
X-OriginalArrivalTime: 25 Aug 2011 18:29:35.0261 (UTC) FILETIME=[F0A464D0:01CC6354]
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Aug 2011 18:36:29 -0000


Please read inline.


>-----Original Message-----
>From: [] On
>Of Dzonatas Sol
>Sent: Thursday, August 25, 2011 11:39 PM
>Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as
>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
>>> 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
>> 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
>> 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

It also may result in unexpected resource
>> consumption on mobile platforms, where the user is paying in
>> charges and battery life to relay media for a third party. And unless
>> implemented carefully, it can lead to relaying that is very
>> (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

>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
>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
>Oh the days of elementary schools that use any speaker as two way
>communication seems almost over.
>> Matthew Kaufman
>> _______________________________________________
>> rtcweb mailing list
>--- ---
>Web Development, Software Engineering
>Ag-Biotech, Virtual Reality, Consultant
>rtcweb mailing list