Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

Randell Jesup <randell-ietf@jesup.org> Wed, 24 August 2011 07:44 UTC

Return-Path: <randell-ietf@jesup.org>
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 7BB6921F8AF7 for <rtcweb@ietfa.amsl.com>; Wed, 24 Aug 2011 00:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level:
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 JG6tdqDYHdGn for <rtcweb@ietfa.amsl.com>; Wed, 24 Aug 2011 00:44:40 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id DA7D621F8AE9 for <rtcweb@ietf.org>; Wed, 24 Aug 2011 00:44:39 -0700 (PDT)
Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1Qw89i-0005mm-SM for rtcweb@ietf.org; Wed, 24 Aug 2011 02:45:48 -0500
Message-ID: <4E54AB9B.9090600@jesup.org>
Date: Wed, 24 Aug 2011 03:43:23 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net>
In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
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, 24 Aug 2011 07:44:40 -0000

On 8/23/2011 1:50 PM, Hutton, Andrew wrote:

> Hi,
>   
> Also agree that implementing a full SIP Session Recording Client (SRC) as defined ]
> by the SIPREC WG in to the browser would be a tall order and would open the flood
> gates for a lot of other requests for SIP functionality in the browser.

Agreed

> If however SIP is not in the browser then I think it is a useful and interesting test case
> to look at whether we could build a decomposed SRC with the browser handling the
> media and the web server handling the signalling. What I heard a number of times at
> IETF81 is that what people want is to build innovative new applications with a real time
> media enabled browser and to it seems clear to me we need a browser API which is
> flexible and enables applications to do clever things with media streams. So exploring
> some use cases which require the browser to duplicate and copy media streams is a good idea.
>   
> Therefore I think we should keep explore the remote recording use case further.

My personal (not Mozilla's) opinion is that SIPREC-style recording is 
out-of-scope,
and would be handled in this context by a webrtc-B2BUA (i.e. something 
that sits on the
signalling and media paths), or something that interacts directly with 
the app.

What I do want to consider for in-scope are local recording options.  
This can cover the "local
answering machine" case, but also "I want to record my call with Dad", 
"I want to record
my team's chatter in the game", "I want to interview someone for 
genealogy research", etc, etc.
Yes, these can be done (poorly) by using some external app to capture 
the screen and
speaker/mic audio - I don't consider that a replacement for local recording.

Local recording is far less problematical protocol-wise than SIPREC, and 
doesn't require
mandating SIP.

-- 
Randell Jesup
randell-ietf@jesup.org