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

Dzonatas Sol <> Thu, 25 August 2011 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C47221F8B2F for <>; Thu, 25 Aug 2011 11:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yxr07zIqDurd for <>; Thu, 25 Aug 2011 11:06:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A38921F8B2B for <>; Thu, 25 Aug 2011 11:06:00 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2320603gxk.31 for <>; Thu, 25 Aug 2011 11:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xN+zYCIXFaaFY/u+XztAVFRNWvfC+8EMwrOynkUh0xA=; b=V/AUbiwF9pRQWLlSmw+4nR33oH+8jjH4vlSNgtb9+Xoa5QKlykucR/T0+76DpyN0x3 CwWnpcph6XDQiftDJW6SkjjFxDQF9gZ7vK3piFB1Q/7pgt/LLGIPxcij/Y+urZLNBDZy zEeHSl1BkMhMWMFyk/+n6TguLwU+XvQv+pqnY=
Received: by with SMTP id x6mr36349ict.388.1314295633912; Thu, 25 Aug 2011 11:07:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id a11sm395416ibg.55.2011. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Aug 2011 11:07:13 -0700 (PDT)
Message-ID: <>
Date: Thu, 25 Aug 2011 11:08:39 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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:06:01 -0000

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 

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