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