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

Dzonatas Sol <dzonatas@gmail.com> Fri, 09 September 2011 17:19 UTC

Return-Path: <dzonatas@gmail.com>
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 71C6521F86AA for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 10:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.971
X-Spam-Level:
X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 xMJ7QZnYEnka for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 10:19:13 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B76A121F86A1 for <rtcweb@ietf.org>; Fri, 9 Sep 2011 10:19:13 -0700 (PDT)
Received: by yxt33 with SMTP id 33so379515yxt.31 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 10:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jcjB+cxwSLGVRrVopYRdKUcGoyO/GJDxRi64SCFNdiE=; b=pv0wlwJwcrypouzDJzpVkmSEUwHtp06cYCxw49rLh3f3eSVeOyPra3TJwtC1/4pN5H KQcz14ZE2xJNI03w16Z2Vi6af7ZB1CuccHFQ1S2+ug5zScCW/DE9dwgrwQsdqNwv+Res Q7tjSV96B4aTdi7AFH69MlsbywxnrAkdA4PeM=
Received: by 10.68.199.67 with SMTP id ji3mr577726pbc.38.1315588868684; Fri, 09 Sep 2011 10:21:08 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id u2sm21284921pbq.9.2011.09.09.10.21.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 10:21:07 -0700 (PDT)
Message-ID: <4E6A4B78.2010802@gmail.com>
Date: Fri, 09 Sep 2011 10:23:04 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 09 Sep 2011 17:19:14 -0000

On 09/09/2011 09:41 AM, 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?
>    

Is there some specific need for the use of the words "third party"? I 
think that should be "modem", yet I know that word doesn't work in 
replace as-is. Maybe extend RFC 2198 to indicate the presence of an 
"audio-out" capable of modulation of SSRC media that MAY record. Does 
that hint on something more fair and reusable?



> 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
>
>    


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant