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

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Aug 2011 16:42:11 +0200

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

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2011 10:59:59 -0400

This is a good start. But I'd like to dig a little deeper into the 
intent here.

The below says the *user* wishes to record, and the *browser* must be 
able to do it. But is that the only case of interest?

ISTM that in a number of cases it will be the web application that wants 
the recording, even if there is an obligation to inform the user that it 
is happening. And the behavior of the application may be changed 
substantially if the recording cannot be made.

(Consider a web app provided by a brokerage to its clients.)

OTOH, maybe some of these cases are out of scope because the 
user+browser can't be sufficiently trusted, so that its necessary to do 
the recording from some secure server.

	Thanks,
	Paul

On 8/22/11 10:42 AM, Elwell, John wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 09:50:22 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 22 August 2011 16:00
> To: [email-masked]
> Subject: Re: [rtcweb] Proposed text for local recording use case
> 
[JRE] I think there is a significant difference between local recording and remote recording. If there is a policy, say in a call centre, to record calls, the recording device is most likely going to be central, not local to the user's device. So I think for local recording it is largely up to the user whether to record or not. But yes, it could be that the application at least suggests recording.

John

John Elwell

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Aug 2011 10:03:42 -0400

> [JRE] I think there is a significant difference between local recording and remote recording. If there is a policy, say in a call centre, to record calls, the recording device is most likely going…

I agree there is a significant difference between local and remote 
recording.

But in the RTCWEB context there are a number of alternatives for local 
recording. Specifically, how is the decision made to record locally?

- the user could have configured the browser to unconditionally
   record every media stream, without regard to what the JavaScript
   has to say about it. This might be an important policy choice if
   you don't trust what the web sites do

- the JS downloaded from a web server may come with instructions
   to make a local recording.

- the JS downloaded from a web server may contain code that checks
   local policy in the browser and/or queries the user, to decide
   whether to make a local recording

In the latter two of the above the decision to record or not rests with 
the web server. In the first case it does not. The first case also 
requires a different sort of implementation in the browser - it must be 
hooked into the stream processing machinery at a lower level.

I think its necessary to decide whether the first case needs to be 
supported. Its tricky, because recording everything is probably 
excessive, yet I'm not sure I'm ready to trust that all the web servers 
I want to use will do the right thing.

Is there a middle ground?

	Thanks,
	Paul

---

From: Dan York <[email-masked]>
Date: Tue, 23 Aug 2011 10:37:46 -0400

Comments inline...

On Aug 23, 2011, at 10:03 AM, Paul Kyzivat wrote:

> I agree there is a significant difference between local and remote recording.
> 
> But in the RTCWEB context there are a number of alternatives for local recording.

DY>  I would also argue that there are any number of alternatives for local recording completely *outside* of what we are talking about for RTCWEB.   

DY> For instance, one the of the use cases *I* have personally for the RTCWEB work is to do audio (and potentially video) interviews with people and record them for various podcasts to which I contribute.  Typically I use Skype today for that, but I'd love an alternative where I could simply give someone a URL where they could go and click a button to connect to me and start the interview.  I can do this today, of course, using things like http://phono.com/ , but it does require the person calling me to use Flash, Java, etc. to do the connection from their browser to their audio devices.   I want to be free of all of that and just have it work in the browser.

DY> As I've been reading this whole thread on local/remote recording, I was thinking how I would use this in my use case... and the reality is that I probably *wouldn't* use it.  I already have additional software on my system that records my local computer audio and indeed can record my entire screen in a video format (which allows me to record video sessions).  I can then do all the relevant post-production I need to create the audio or video files I need.

DY> In fact, I have multiple solutions for local recording on my computer... some are commercial products I have purchased, some are open source.  Now true, they are not synced to an incoming call, so I would need to trigger them to initiate the recording, but they are available.

DY> All of this made me wonder if perhaps we are diving in a bit too deep here...  while it might be ideal for recording to be triggered in an RTCWEB connection, is that truly the vast majority of cases?  Or are we debating something that is more of an edge case?   In a call center environment, for instance, might the agents not already have other software installed on their computer that could be doing the local recording if required?

DY> I'm concerned in reading these threads that we are adding more and more layers of complexity which could get in the way of spurring widespread adoption.  (And yes, I do fully understand the counter-argument that if we don't think about this in advance we may not be able to add the functionality later.)

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-321-710-9193  skype: danyork  sip:[email-masked]

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Aug 2011 11:22:47 -0400

IMO the key here is that we are thinking it through.
It may turn out that there are no new requirements on RTCWEB.
But then that decision will have been made consciously, rather than by 
default.

I'm all for allowing independent things to be dealt with independently, 
rather than including everything in one big mash up. But finding where 
to draw the lines between things isn't always easy.

	Thanks,
	Paul

On 8/23/11 10:37 AM, Dan York wrote:
>>> [JRE] I think there is a significant difference between local
>>> recording and remote recording. If there is a policy, say in a call
>>> centre, to record calls, the recording device is most likely going to
>>> be central, not local to the user's device. So I think for local
>>> recording it is largely up to the user whether to record or not. But
>>> yes, it could be that the application at least suggests recording.
>>
> DY> I would also argue that there are any number of alternatives for
> local recording completely *outside* of what we are talking about for
> RTCWEB.
>
> DY> For instance, one the of the use cases *I* have personally for the
> RTCWEB work is to do audio (and potentially video) interviews with
> people and record them for various podcasts to which I contribute.
> Typically I use Skype today for that, but I'd love an alternative where
> I could simply give someone a URL where they could go and click a button
> to connect to me and start the interview. I can do this today, of
> course, using things like http://phono.com/ , but it does require the
> person calling me to use Flash, Java, etc. to do the connection from
> their browser to their audio devices. I want to be free of all of that
> and just have it work in the browser.
>
> DY> As I've been reading this whole thread on local/remote recording, I
> was thinking how I would use this in my use case... and the reality is
> that I probably *wouldn't* use it. I already have additional software on
> my system that records my local computer audio and indeed can record my
> entire screen in a video format (which allows me to record video
> sessions). I can then do all the relevant post-production I need to
> create the audio or video files I need.
>
> DY> In fact, I have multiple solutions for local recording on my
> computer... some are commercial products I have purchased, some are open
> source. Now true, they are not synced to an incoming call, so I would
> need to trigger them to initiate the recording, but they are available.
>
> DY> All of this made me wonder if perhaps we are diving in a bit too
> deep here... while it might be ideal for recording to be triggered in an
> RTCWEB connection, is that truly the vast majority of cases? Or are we
> debating something that is more of an edge case? In a call center
> environment, for instance, might the agents not already have other
> software installed on their computer that could be doing the local
> recording if required?
>
> DY> I'm concerned in reading these threads that we are adding more and
> more layers of complexity which could get in the way of spurring
> widespread adoption. (And yes, I do fully understand the
> counter-argument that if we don't think about this in advance we may not
> be able to add the functionality later.)
>
> My 2 cents,
> Dan
>
> --
> <mailto:[email-masked]>
> *Join the Voxeo conversation:*
> *Blogs: http://blogs.voxeo.com*
> *Twitter: http://twitter.com/voxeo http://twitter.com/danyork*
> *Facebook: http://www.facebook.com/voxeo*
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 23 Aug 2011 15:56:46 -0600

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

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.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 23 Aug 2011 18:00:49 -0700

Native Client mode needs Native Server mode as different accounts local 
and remote; like, six hours worth of samples from physical grid 
simulation; scene data driven graphs store optional.

Geolocation schema for C.A.V.E.s was one of many common questions never 
made FAQ.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Aug 2011 10:51:15 +0200

Cullen,

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

John Elwell

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 23 August 2011 22:57
> To: Elwell, John
> Cc: [email-masked]; [email-masked]
> > 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:
> > 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.