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

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 13 September 2011 16:13 UTC

Return-Path: <HKaplan@acmepacket.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 9391621F8CA0 for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 09:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599]
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 zfXYn44DwBfu for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 09:13:37 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14B21F8C91 for <rtcweb@ietf.org>; Tue, 13 Sep 2011 09:13:37 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 13 Sep 2011 12:15:36 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 12:15:36 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Harald Alvestrand <harald@alvestrand.no>, John Elwell <john.elwell@siemens-enterprise.com>
Thread-Topic: [rtcweb] Proposed text - remote recording use case
Thread-Index: AQHMcjBe44ynxue6Dkeiz3Tz6NhmfQ==
Date: Tue, 13 Sep 2011 16:15:35 +0000
Message-ID: <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com>
References: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net> <4E6F6624.3070809@alvestrand.no>
In-Reply-To: <4E6F6624.3070809@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A1C75EC8B9043C4EA17F8A076EEB5A37@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 16:13:38 -0000

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.

-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