Re: [rtcweb] Proposed text - remote recording use case
"Elwell, John" <john.elwell@siemens-enterprise.com> Wed, 14 September 2011 05:51 UTC
Return-Path: <john.elwell@siemens-enterprise.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 A1DEF21F8B3A for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 22:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.04
X-Spam-Level:
X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, 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 7Cl8FR3ivcq7 for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 22:51:26 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CAAB221F8A91 for <rtcweb@ietf.org>; Tue, 13 Sep 2011 22:51:25 -0700 (PDT)
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 16B451EB8461; Wed, 14 Sep 2011 07:53:31 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 14 Sep 2011 07:53:31 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 14 Sep 2011 07:53:29 +0200
Thread-Topic: [rtcweb] Proposed text - remote recording use case
Thread-Index: AQHMcjBe44ynxue6Dkeiz3Tz6NhmfZVMYF4g
Message-ID: <A444A0F8084434499206E78C106220CA0BC0F38C36@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net> <4E6F6624.3070809@alvestrand.no> <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com>
In-Reply-To: <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 14 Sep 2011 05:51:28 -0000
> -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 13 September 2011 17:16 > To: Harald Alvestrand; Elwell, John > Cc: Elwell, John; rtcweb@ietf.org > Subject: Re: [rtcweb] Proposed text - remote recording use case > > Actually, I think remote recording may already be possible > without anything new. > > Draft-ietf-rtcweb-use-cases-and-requirements-04 has a > use-case 4.2.7 for "Multiparty video communication", and > associated requirements. All you need for remote recording > is the ability for the javascript to create a separate media > stream to the recorder (SRS), as if the SRS were a third > participant, and fork the user's audio/video into both > streams. The 4.2.7 requirement implies that will be possible. > > What's not handled by that is replicating the received > audio/video from the peer into the recording stream to the > SRS - i.e., the browser will be able to fork the locally > generated media, but not the media received from the peer. > For sessions between two rtcweb browsers controlled by the > same provider this could still work, since both rtcweb > browsers could be told to create streams to the SRS for both > halves of media to be recorded. For calls to/from another > domain, if one uses SIP between the servers then one could do > real SIPREC in a logical SIP B2BUA there. [JRE] I don't think that is good enough - it should not be necessary to rely on a remote peer to send its media to the recorder, particularly in federation cases. Both directions of media should come from the one peer. John > > -hadriel > p.s. the ability for rtcweb browsers to create conf calls by > doing half-mixing and using a full mesh of media streams is > not normal for SIP, and may be rather tricky to get to work > right if the participants are not in the same domain and SIP > has to be used between. Was the intention that such > inter-domain cases would require a centralized conf server > instead of direct media meshing? > > > On Sep 13, 2011, at 10:18 AM, Harald Alvestrand wrote: > > > 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 > >> > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > >
- [rtcweb] Proposed text - remote recording use case Elwell, John
- Re: [rtcweb] Proposed text - remote recording use… Dzonatas Sol
- Re: [rtcweb] Proposed text - remote recording use… Ravindran Parthasarathi
- Re: [rtcweb] Proposed text - remote recording use… Matthew Kaufman
- Re: [rtcweb] Proposed text - remote recording use… Olle E. Johansson
- Re: [rtcweb] Proposed text - remote recording use… Harald Alvestrand
- Re: [rtcweb] Proposed text - remote recording use… Hadriel Kaplan
- Re: [rtcweb] Proposed text - remote recording use… Hadriel Kaplan
- Re: [rtcweb] Proposed text - remote recording use… Matthew Kaufman
- Re: [rtcweb] Proposed text - remote recording use… Elwell, John
- Re: [rtcweb] Proposed text - remote recording use… Elwell, John
- Re: [rtcweb] Proposed text - remote recording use… Ravindran Parthasarathi
- Re: [rtcweb] Proposed text - remote recording use… Elwell, John
- Re: [rtcweb] Proposed text - remote recording use… Elwell, John
- Re: [rtcweb] Proposed text - remote recording use… Harald Alvestrand
- Re: [rtcweb] Proposed text - remote recording use… Ravindran Parthasarathi
- Re: [rtcweb] Proposed text - remote recording use… Ravindran Parthasarathi
- Re: [rtcweb] Proposed text - remote recording use… Elwell, John
- Re: [rtcweb] Proposed text - remote recording use… Iñaki Baz Castillo