Re: [rtcweb] Proposed text for local recording use case

"Elwell, John" <> Wed, 24 August 2011 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F50121F8B1F for <>; Wed, 24 Aug 2011 01:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.172
X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 54NtkQIbmWr4 for <>; Wed, 24 Aug 2011 01:50:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 89E9321F8B1C for <>; Wed, 24 Aug 2011 01:50:07 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id F00EC23F04CA; Wed, 24 Aug 2011 10:51:16 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 24 Aug 2011 10:51:17 +0200
From: "Elwell, John" <>
To: Cullen Jennings <>
Date: Wed, 24 Aug 2011 10:51:15 +0200
Thread-Topic: [rtcweb] Proposed text for local recording use case
Thread-Index: Acxh35Kt0gJDI7QwSkWAlTVOQ8fY+gAWeLEQ
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [rtcweb] Proposed text for local recording use case
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: Wed, 24 Aug 2011 08:50:08 -0000


In principle, copying real-time media to JS would certainly be a very flexible solution. However, depending exactly what the JS wants to use it for, I suspect there might possibly be performance issues.

Would there also be a requirement for passing media data from JS back down to the browser for transmission to the remote browser? I am thinking in particular of warning tone/announcements when recording is taking place, but of course it could be used for whatever you want.

The concept of passing media data up to JS / down to the browser would also be a solution for remote recording (if we decide we need it). The JS could then pass the collected data back down to another PeerConnection object for sending to the remote recording device. This in particular would need to be considered from a performance point of view - would passing it up to the JS and back down again be potentially slower than passing it between objects within the browser?


John Elwell
Tel: +44 1908 817801 (office and mobile)

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> -----Original Message-----
> From: Cullen Jennings [] 
> Sent: 23 August 2011 22:57
> To: Elwell, John
> Cc:;
> Subject: Re: [rtcweb] Proposed text for local recording use case
> On Aug 22, 2011, at 8:42 AM, Elwell, John wrote:
> > 4.2.xx Local Session Recording
> > In this use case, the web application user wishes to record 
> a real-time communication locally, such that transmitted and 
> received audio, video or other real-time media are stored in 
> one or more files. For a given medium, the two directions of 
> transmission can be stored in the same file (mixed) or in 
> separate files. The web application also stores metadata that 
> gives context to the stored media.
> > 
> > New requirements:
> > Fxx1: The browser MUST be able to store transmitted and 
> received media in local files.
> > 
> > Axx1: The web application MUST be able to ask the browser 
> to store transmitted and received media in local files, and 
> in the case of audio at least, ask for the two directions of 
> transmission to be stored mixed or separately.
> > 
> > John
> I think I want something just slightly different and that is 
> to send media that is data in the JS and to be able to hand 
> media as data to the JS. If the JS happens to read / write 
> that to a file that is fine with me but this allows the JS to 
> operate on the data or synthetically generate media and opens 
> the doors to the possibility of writing a codec in JS or NACL.