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

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

4.2.yy Remote Session Recording
In this use case, the web application user wishes to record a real-time communication at a remote recording device, such that transmitted and received audio, video or other real-time media are transmitted in real-time to the remote device. The remote device can perform archiving, retrieval, playback, etc., but can also perform real-time analytics on the media. A typical deployment might be in a contact centre. For a given medium, the two directions of transmission can be transmitted together (mixed) or separately. The web application also sends metadata that gives context to the stored media.

New requirements:
Fyy1: The browser MUST be able to send in real-time to a remote recording device media that are being transmitted to and received from remote participants.

Ayy1: The web application MUST be able to ask the browser to transmit in real-time to a remote recording device media that are being transmitted to and received from remote participants and, in the case of audio at least, ask for the two directions of transmission to be transmitted to the remote recording device 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: Jim McEachern <[email-masked]>
Date: Mon, 22 Aug 2011 18:29:48 +0000

John,
It has previously been pointed out that in some jurisdictions there is a legal requirement to insert a tone (e.g. an intermittent beep) that indicates the conversation is being recorded.  It seems like this would be a good thing to mention here.  

If this makes sense, I'm thinking something like the following sentence added to the end of 4.2.yy:
"... If required, the web application will direct the browser to insert an appropriate indication (e.g. an intermediate beep) into the media stream to show that the communication is being recorded."

This also suggests an additional requirement.  
"Ayy2: The web application MUST be able to ask the browser to insert an appropriate indication into the media stream to indicate that the communication is being recorded."

I believe that F15 already covers the requirments for the browser in this case.
F15:         The browser MUST be able to process and mix
                   sound objects (media that is retrieved from another
                   source than the established media stream(s) with the
                   peer(s) with audio streams).

Thoughts?
Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Monday, August 22, 2011 10:42 AM
To: [email-masked]; [email-masked]
Subject: [rtcweb] Proposed text for remote recording use case

New requirements:

John

John Elwell

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 22 Aug 2011 11:43:08 -0700

Hi Jim,

SIPREC includes the notion of recording awareness, and in the case of a
recording aware device you can signal in SDP the fact that something is
being recorded rather than requiring an indication to be inserted into
the media stream. I think RTCWEB should be able to leverage this
mechanism. In that case, the indication of the media being recorded may
be communicated by the web application or the browser, but it need not
necessarily be inserted in the actual media.

Cheers,
Charles 

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim McEachern
> Sent: Monday, August 22, 2011 11:30 AM
> To: Elwell, John; [email-masked]; [email-masked]
> Subject: Re: [rtcweb] Proposed text for remote recording use case
> 
> John,
> It has previously been pointed out that in some jurisdictions there is
a legal requirement to insert a
> tone (e.g. an intermittent beep) that indicates the conversation is
being recorded.  It seems like
> this would be a good thing to mention here.
> 
> "... If required, the web application will direct the browser to
insert an appropriate indication
> (e.g. an intermediate beep) into the media stream to show that the
communication is being recorded."
> "Ayy2: The web application MUST be able to ask the browser to insert
an appropriate indication into
> the media stream to indicate that the communication is being
recorded."
> In this use case, the web application user wishes to record a
real-time communication at a remote
> recording device, such that transmitted and received audio, video or
other real-time media are
> transmitted in real-time to the remote device. The remote device can
perform archiving, retrieval,
> playback, etc., but can also perform real-time analytics on the media.
A typical deployment might be
> in a contact centre. For a given medium, the two directions of
transmission can be transmitted
> together (mixed) or separately. The web application also sends
metadata that gives context to the
> stored media.
> 
> New requirements:
> Fyy1: The browser MUST be able to send in real-time to a remote
recording device media that are being
> transmitted to and received from remote participants.
> 
> Ayy1: The web application MUST be able to ask the browser to transmit
in real-time to a remote
> recording device media that are being transmitted to and received from
remote participants and, in the
> case of audio at least, ask for the two directions of transmission to
be transmitted to the remote
> recording device mixed or separately.
> 
> John
> 
> 
> John Elwell

---

From: Jim McEachern <[email-masked]>
Date: Mon, 22 Aug 2011 19:01:43 +0000

Charles, 
Does this mean that there isn't a need to say anything, or that we should state there is a requirement to  indicate the communication is being recorded, but not assume you will have to insert something into the media path?

Jim

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: Monday, August 22, 2011 2:43 PM
To: Jim McEachern; Elwell, John; [email-masked]; [email-masked]
Subject: RE: [rtcweb] Proposed text for remote recording use case

Hi Jim,

SIPREC includes the notion of recording awareness, and in the case of a recording aware device you can signal in SDP the fact that something is being recorded rather than requiring an indication to be inserted into the media stream. I think RTCWEB should be able to leverage this mechanism. In that case, the indication of the media being recorded may be communicated by the web application or the browser, but it need not necessarily be inserted in the actual media.

Cheers,
Charles 

Behalf Of Jim McEachern
recorded."
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
in real-time to a remote

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2011 17:31:06 -0400

> Does this mean that there isn't a need to say anything, or that we should state there is a requirement to  indicate the communication is being recorded, but not assume you will have to insert somet…

We've discussed this in siprec.
Its our understanding that in some cases the entity doing the recording 
has an obligation to ensure that the participants in the recorded 
session are aware of the recording. Playing out special tones, like 
beeps, is one way of achieving that, but not necessarily the only way. 
Rules vary, so we need to be flexible about this.

For siprec we are providing a way for participants in the session being 
recorded to signal that they are capable of recognizing an indication of 
recording in the signaling path. For UAs that don't so signal, the SRC 
will then have to provide indication in the media.

This seems to provide sufficient flexibility for the cases siprec is 
covering. It covers things like pstn gateways.

For RTCWEB the same concepts probably apply, but the assumptions and 
details may differ.

Also note that this isn't just about audio. If we are recording video, 
and not audio, then playing out beeps in the audio stream may not make 
much sense. (Consider a video + real time text call involving a deaf 
person.) Providing an indication in the signaling allows the UA to 
tailor an indication most suited to its user.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 22 Aug 2011 15:56:25 -0700

Hi Jim,

I met to recommend the latter.

Cheers,
Charles

> From: Jim McEachern [mailto:[email-masked]]
> Sent: Monday, August 22, 2011 12:02 PM
> To: Charles Eckel (eckelcu); Elwell, John; [email-masked];
[email-masked]
> Does this mean that there isn't a need to say anything, or that we
should state there is a requirement
> to  indicate the communication is being recorded, but not assume you
will have to insert something
> into the media path?
> SIPREC includes the notion of recording awareness, and in the case of
a recording aware device you can
> signal in SDP the fact that something is being recorded rather than
requiring an indication to be
> inserted into the media stream. I think RTCWEB should be able to
leverage this mechanism. In that
> case, the indication of the media being recorded may be communicated
by the web application or the
> browser, but it need not necessarily be inserted in the actual media.
> 
> Cheers,
> Charles
> 
> > Registered office: Brickhill Street, Willen Lake, Milton Keynes,
MK15
> 0DJ.

---

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

Jim,

Good point. Unfortunately the nature of  tones/announcements will vary considerably between jurisdictions, so the JS would either need to provide an explicit description of what is to be inserted, or would need to provide a source. In many cases nothing at all would be needed. Often it is the case that all callers into a contact centre are played an initial announcement that calls may be recorded, before being forwarded to the agent. So if an RTC-Web-based agent is acting as the recording client for remote recording, it perhaps won't need to provide any tone/announcement. 

John

> Sent: 22 August 2011 19:30
> Subject: RE: Proposed text for remote recording use case
> 
> John,
> It has previously been pointed out that in some jurisdictions 
> there is a legal requirement to insert a tone (e.g. an 
> intermittent beep) that indicates the conversation is being 
> recorded.  It seems like this would be a good thing to mention here.  
> 
> If this makes sense, I'm thinking something like the 
> following sentence added to the end of 4.2.yy:
> "... If required, the web application will direct the browser 
> to insert an appropriate indication (e.g. an intermediate 
> beep) into the media stream to show that the communication is 
> being recorded."
> 
> "Ayy2: The web application MUST be able to ask the browser to 
> insert an appropriate indication into the media stream to 
> indicate that the communication is being recorded."
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> real-time communication at a remote recording device, such 
> that transmitted and received audio, video or other real-time 
> media are transmitted in real-time to the remote device. The 
> remote device can perform archiving, retrieval, playback, 
> etc., but can also perform real-time analytics on the media. 
> A typical deployment might be in a contact centre. For a 
> given medium, the two directions of transmission can be 
> transmitted together (mixed) or separately. The web 
> application also sends metadata that gives context to the 
> stored media.
> 
> New requirements:
> Fyy1: The browser MUST be able to send in real-time to a 
> remote recording device media that are being transmitted to 
> and received from remote participants.
> 
> Ayy1: The web application MUST be able to ask the browser to 
> transmit in real-time to a remote recording device media that 
> are being transmitted to and received from remote 
> participants and, in the case of audio at least, ask for the 
> two directions of transmission to be transmitted to the 
> remote recording device mixed or separately.
> 
> John
> 
> 
> John Elwell

---

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

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 22 August 2011 22:31
> To: [email-masked]
> > Does this mean that there isn't a need to say anything, or 
> that we should state there is a requirement to  indicate the 
> communication is being recorded, but not assume you will have 
> to insert something into the media path?
> 
[JRE] A caveat here. The fact that a participant's UA can signal that it can recognize an indication of recording and pass on some sort of indication to the participant should not necessarily be seen as removing the need for the SRC to insert a tone/announcement (or equivalent in other media). The simple indication to the UA that recording is in progress for a given medium might not convey the full meaning that can be conveyed by a country-specific or enterprise-specific announcement. So in many deployments I anticipate the SRC providing in-band indications anyway, but allowing a recording-aware UA to augment these with additional indications specific to its user interface, e.g., light a lamp, flash text, etc..

John

> > SIPREC includes the notion of recording awareness, and in 
> the case of a recording aware device you can signal in SDP 
> the fact that something is being recorded rather than 
> requiring an indication to be inserted into the media stream. 
> I think RTCWEB should be able to leverage this mechanism. In 
> that case, the indication of the media being recorded may be 
> communicated by the web application or the browser, but it 
> need not necessarily be inserted in the actual media.
> >
> > Cheers,
> > Charles
> >
> >> I believe that F15 already covers the requirments for the 
> browser in
> > this case.
> >>                     source than the established media 
> stream(s) with
> > the
> >> Registered office: Brickhill Street, Willen Lake, Milton 
> Keynes, MK15
> > 0DJ.
> >> Siemens Enterprise Communications Limited is a Trademark 
> Licensee of
> > Siemens AG.

---

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

Just to try and help clarify requirements ... I suspect the current requirements you wrote could be meant mostly by just taking a copy of the data to and from the speaker/mic/camera/screen and just sending them via a HTTP post to some web service that recorded them. I suspect you want something different than that so we might need to poke at these requirements a bit to see what it is. Alternatively, if data can be copied from one stream to anther stream using the JS, does that provide everything you need or is it something more. 

(BTW... I am probably not in favor of supporting these requirements in the client as it is typically not a great place to do recording but that's a separate issues. Just trying to clarify what we talking about)

---

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

Cullen,

Since I posted the proposed text, I have attempted to clarify things in a different thread:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg00707.html
This may help to clarify things. My proposed text might require refinement, depending on the outcome of that other thread.

HTTP post is not what is really needed here - in common with the SIPREC work, the idea is to send real-time media in real-time (over RTP), for similar reasons that RTC-Web uses peer-to-peer RTP. Some recording devices use real-time analytics, and need to receive the information without significant delay.

John

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 23 August 2011 22:49
> To: Elwell, John
> Cc: [email-masked]; [email-masked]
> Just to try and help clarify requirements ... I suspect the 
> current requirements you wrote could be meant mostly by just 
> taking a copy of the data to and from the 
> speaker/mic/camera/screen and just sending them via a HTTP 
> post to some web service that recorded them. I suspect you 
> want something different than that so we might need to poke 
> at these requirements a bit to see what it is. Alternatively, 
> if data can be copied from one stream to anther stream using 
> the JS, does that provide everything you need or is it 
> something more. 
> 
> (BTW... I am probably not in favor of supporting these 
> requirements in the client as it is typically not a great 
> place to do recording but that's a separate issues. Just 
> trying to clarify what we talking about)
> 
> > In this use case, the web application user wishes to record 
> a real-time communication at a remote recording device, such 
> > Ayy1: The web application MUST be able to ask the browser 
> to transmit in real-time to a remote recording device media 
> that are being transmitted to and received from remote 
> Keynes, MK15 0DJ.
> Licensee of Siemens AG.