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

Harald Alvestrand <harald@alvestrand.no> Tue, 13 September 2011 14:16 UTC

Return-Path: <harald@alvestrand.no>
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 ED82E21F8B1D for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 07:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.159
X-Spam-Level:
X-Spam-Status: No, score=-108.159 tagged_above=-999 required=5 tests=[AWL=2.440, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 rsoQ8wfClhID for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 07:16:12 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDBF21F8B1E for <rtcweb@ietf.org>; Tue, 13 Sep 2011 07:16:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4995739E0AF; Tue, 13 Sep 2011 16:18:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkgIE8YAJLaJ; Tue, 13 Sep 2011 16:18:13 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 11F9C39E088; Tue, 13 Sep 2011 16:18:13 +0200 (CEST)
Message-ID: <4E6F6624.3070809@alvestrand.no>
Date: Tue, 13 Sep 2011 16:18:12 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
References: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net>
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 - 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: Tue, 13 Sep 2011 14:16:17 -0000

I like this text for capturing the use case.

I agree with Matthew that it seems to come with some special caveats 
that we should consider whether we can solve before agreeing that this 
is an use case we MUST solve - but some of those issues may be issues we 
will face as a natural consequence of the API proposal anyway.

I suggest that Stefan add it to the use case draft under "use cases 
considered", so that we have the text in the draft, with a note that the 
WG has not accepted this as a "must do" use case.

On 09/09/11 18:41, Elwell, John wrote:
> On yesterday's call it was agreed to work on text to cover the remote recording use case. Below is text, based on an earlier proposal and subsequent input. I have focused on the main requirement derived from this use case, relating to copying to a different peer connection, and skipped any more detailed requirements concerning possible mixing of the two directions of audio or injecting any tones / announcements.
>
> 4.2.yy Remote Session Recording
> In this use case, the web application user wishes to record a real-time communication at a remote third party (e.g., a recording device), such that transmitted and received audio, video or other real-time media are transmitted in real-time to the third party. The third party can perform recording, archiving, retrieval, playback, etc., but can also perform real-time analytics on the media. A typical deployment might be in a contact centre. The web application also sends metadata that gives context to the stored media. The web application will ensure that appropriate indications are given to participants so that they are aware of recording.
>
> New requirements:
> Fyy1: The browser MUST be able to send in real-time to a third party 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 third party media that are being transmitted to and received from remote participants.
>
> Comments?
>
> 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
>