Re: [rtcweb] Use cases - recording and voicemail

Paul Kyzivat <> Fri, 19 August 2011 23:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC03411E80CA for <>; Fri, 19 Aug 2011 16:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BfWnf7MeHGUX for <>; Fri, 19 Aug 2011 16:51:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C99D111E80BF for <>; Fri, 19 Aug 2011 16:51:09 -0700 (PDT)
Received: from ([]) by with comcast id NPiC1h0031uE5Es5FPs8fn; Fri, 19 Aug 2011 23:52:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id NPs51h0160tdiYw3cPs6cb; Fri, 19 Aug 2011 23:52:06 +0000
Message-ID: <>
Date: Fri, 19 Aug 2011 19:52:03 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
References: <> <>, <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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 23:51:12 -0000


Many of the issues you are bringing up are things we have been 
addressing in the siprec WG. RTCWEB can either reinvent all that, or we 
can find some way to reuse that work. At the moment, siprec assumes that 
the agent that is initiating the recording is in the signaling path of a 
sip call, and that it is capable of establishing another sip session to 
the recorder. Those assumptions would seem to be wrong for RTCWEB.


On 8/19/11 5:51 PM, Randell Jesup wrote:
> 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).
> Yes.
>> 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.