Re: [rtcweb] Use cases - recording and voicemail

Randell Jesup <> Fri, 19 August 2011 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52E2121F8B13 for <>; Fri, 19 Aug 2011 14:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvhMfE3dIV1k for <>; Fri, 19 Aug 2011 14:52:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B982721F8AF8 for <>; Fri, 19 Aug 2011 14:52:53 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1QuX0g-0005wq-FK; Fri, 19 Aug 2011 16:53:50 -0500
Message-ID: <>
Date: Fri, 19 Aug 2011 17:51:38 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: "" <>, "" <>
References: <> <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Use cases - recording and voicemail
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: Fri, 19 Aug 2011 21:52:54 -0000

On 8/19/2011 5:49 AM, Stefan Håkansson LK wrote:

> John,
> this was a good way sort things up.
> I my view we should definitely support local recording of streams (regardless of if they are generated by local devices or received via RTP), and this could be done in parallel to rendering them or not (up to the app).

Agreed.   Note that there are legal requirements in various locations around recording
conversations; that's up to the application IMHO -- however we'll want to make sure it's
reasonably easy for the application to do.  While I'm not an expert, recording someone
in many jurisdictions requires periodic beeps, etc.  They'd have to mix it into the outgoing
stream, but it would have to remain there even if the user "muted".  I want to make sure
we're providing something that won't be a hassle for the application developers.

> The recorded media should also be possible to render locally (be the source for a video element).

> I'm less sure about that the recorded media should also be an RTP source - couldn't you just as well send the file over and then play it at the remote end?

That might not work for cases where the two users are talking through different
providers/apps, and it also would imply a much longer delay in many cases, plus
local storage requirements, etc.   Think a recorded greeting played to callers if
no one answers, for example.

Assuming that recording and playback are of encoded media:

There are issues with recording and playback having to do with error recovery.
For recording an incoming stream, it's less of an issue - you do normal error
recovery, and on playback it would look the same as it would have if the call had
been live.

For sending a pre-recorded stream (greeting, etc): I'd assume it was recorded
without loss.  However, the other side may experience loss in receiving it.
To deal with this, we can a) decode and re-encode the media, allowing us to react
to incoming loss reports, or b) include periodic IDRs or equivalent.  I would
lean to a) (decode&  re-encode), that also handles issues with codec parameters,
codec choice, etc.  So an input would be from a decoded stream.  This may use more
resources than b; the application could (at its discretion) not render incoming media
while playing back.

Randell Jesup