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

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 22 August 2011 22:31
> To: [e-mail]
> Subject: Re: [rtcweb] Proposed text for remote recording use case
> 
> On 8/22/11 3:01 PM, Jim McEachern wrote:
> > 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?
> 
> 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.
[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

> 
> 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
> 
> > Jim
> >
> >
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:[e-mail]]
> > Sent: Monday, August 22, 2011 2:43 PM
> > To: Jim McEachern; Elwell, John; [e-mail]; 
> [e-mail]
> > 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
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Jim McEachern
> >> Sent: Monday, August 22, 2011 11:30 AM
> >> To: Elwell, John; [e-mail]; [e-mail]
> >> 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 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: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Elwell, John
> >> Sent: Monday, August 22, 2011 10:42 AM
> >> To: [e-mail]; [e-mail]
> >> Subject: [rtcweb] Proposed text for remote recording use case
> >>
> >> 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: [phone] (office and mobile)
> >> Email: [e-mail]
> >> 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.
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>