Re: [rtcweb] Use cases - recording and voicemail

[Paul Kyzivat <[e-mail]>]

Randell,

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.

	Thanks,
	Paul

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.
>
>