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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 22 August 2011 21:30 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798F321F8C4D for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 14:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEUTuJD0ruX2 for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 14:30:04 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6045A21F8BBE for <rtcweb@ietf.org>; Mon, 22 Aug 2011 14:30:04 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id PZWz1h0051GhbT85EZXAl7; Mon, 22 Aug 2011 21:31:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta07.westchester.pa.mail.comcast.net with comcast id PZX71h00W0tdiYw3TZX8DZ; Mon, 22 Aug 2011 21:31:08 +0000
Message-ID: <4E52CA9A.9020901@alum.mit.edu>
Date: Mon, 22 Aug 2011 17:31:06 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B00FDAE6B@MCHP058A.global-ad.net> <8584590C8D7DD141AA96D01920FC6C698C880779@gbplmail03.genband.com> <E1CBF4C7095A3D4CAAAEAD09FBB8E08C051BF791@xmb-sjc-234.amer.cisco.com> <8584590C8D7DD141AA96D01920FC6C698C8807DC@gbplmail03.genband.com>
In-Reply-To: <8584590C8D7DD141AA96D01920FC6C698C8807DC@gbplmail03.genband.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed text for remote recording use case
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2011 21:30:05 -0000

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.

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:eckelcu@cisco.com]
> Sent: Monday, August 22, 2011 2:43 PM
> To: Jim McEachern; Elwell, John; rtcweb@ietf.org; public-webrtc@w3.org
> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Jim McEachern
>> Sent: Monday, August 22, 2011 11:30 AM
>> To: Elwell, John; rtcweb@ietf.org; public-webrtc@w3.org
>> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Elwell, John
>> Sent: Monday, August 22, 2011 10:42 AM
>> To: rtcweb@ietf.org; public-webrtc@w3.org
>> 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: +44 1908 817801 (office and mobile)
>> Email: john.elwell@siemens-enterprise.com
>> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb