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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 23 August 2011 15:21 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 39B0B21F8ACA for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 08:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level:
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_47=0.6]
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 8eFQ6yjMQxZ3 for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 08:21:57 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEE321F89BA for <rtcweb@ietf.org>; Tue, 23 Aug 2011 08:21:57 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id PrGe1h0011vXlb85FrP5Zk; Tue, 23 Aug 2011 15:23:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id PrNp1h01Q0tdiYw3drNvpM; Tue, 23 Aug 2011 15:23:01 +0000
Message-ID: <4E53C5C7.7090904@alum.mit.edu>
Date: Tue, 23 Aug 2011 11:22:47 -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: Dan York <dyork@voxeo.com>
References: <A444A0F8084434499206E78C106220CA0B00FDAE6A@MCHP058A.global-ad.net> <4E526EEF.8080605@alum.mit.edu> <A444A0F8084434499206E78C106220CA0B00FDB07F@MCHP058A.global-ad.net> <4E53B33E.20508@alum.mit.edu> <0373F256-76A8-4498-8699-34FC6813B2CB@voxeo.com>
In-Reply-To: <0373F256-76A8-4498-8699-34FC6813B2CB@voxeo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed text for local 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: Tue, 23 Aug 2011 15:21:58 -0000

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:
> Comments inline...
>
> On Aug 23, 2011, at 10:03 AM, Paul Kyzivat wrote:
>
>> On 8/23/11 3:50 AM, Elwell, John wrote:
>>>> 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.
>>> [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.
>>
>> 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 dyork@voxeo.com
> <mailto:dyork@voxeo.com>
> Phone: +1-321-710-9193 skype: danyork sip:dyork@voxeo.com
>
> *Join the Voxeo conversation:*
> *Blogs: http://blogs.voxeo.com*
> *Twitter: http://twitter.com/voxeo http://twitter.com/danyork*
> *Facebook: http://www.facebook.com/voxeo*
>