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

Matthew Kaufman <matthew.kaufman@skype.net> Thu, 25 August 2011 17:13 UTC

Return-Path: <matthew.kaufman@skype.net>
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 3A87121F8AD8 for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 10:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 y-Iz8Zf5ipYB for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 10:13:19 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3029B21F8A51 for <rtcweb@ietf.org>; Thu, 25 Aug 2011 10:13:19 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 9AC2B1708; Thu, 25 Aug 2011 19:14:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=c6/DISVhbReXKh cyTEA1DuFHx7E=; b=km0z4b1l4eDIvzQYrgg/kbb/tgZ7Px/NAzWJ36DTHsSf4V iFYeag6rVk4Y9KvJdOwUSisS+4OzDkcTkZCc6tMbRSnolGAnJIkL1hK+vU+ijhQD Vff61QG7WKtri1rMYJo1906uevTjH7Li+ZvE9LS311y7SUxeqHQlNv61DO6a8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=YqEvV9uEv+hUJJS0Dp43Qi 1WTsue47UqjeQEmjkHSYT9/MaHLVRKRAUaVcub3MRM2kwHiSV7hmjV7KjO4XYEEZ nkngQ+UZvtAq/zo6BArEzp1EsDcrIfAqy1EZ8ZeUmM5mCKnZ8GW5leqNU4m8SeWd OUi5vTCHMSLwrWDcL7BJo=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 992F97F6; Thu, 25 Aug 2011 19:14:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 79AEE3507D45; Thu, 25 Aug 2011 19:14:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HMONFRQRWVh; Thu, 25 Aug 2011 19:14:31 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 133AA3507EAC; Thu, 25 Aug 2011 19:14:30 +0200 (CEST)
Message-ID: <4E5682DD.5020204@skype.net>
Date: Thu, 25 Aug 2011 10:14:05 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
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> <4E54AB9B.9090600@jesup.org> <A444A0F8084434499206E78C106220CA0B00FDB534@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31018BF6DF6@MCHP058A.global-ad.net> <4E554BCE.2040403@alum.mit.edu> <4E56399E.2020902@alvestrand.no> <A444A0F8084434499206E78C106220CA0B011C8D3B@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA0B011C8D3B@MCHP058A.global-ad.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Thu, 25 Aug 2011 17:13:20 -0000

On 8/25/2011 5:51 AM, Elwell, John wrote:
>
> 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.

This is a bad idea.

> 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

Yes. It should be possible for the browser to send two copies of the 
same media to two different places, possibly even with different encoders.

>   and received from remote participants

But this is a bad idea. Providing APIs that let a browser send audio 
that is being received from the other end to a third party open several 
different cans of worms simultaneously. One is that there's now another 
path by which a user's media may be sent, possibly without the same 
security constraints, without their knowledge. Sure, a B2BUA can do this 
as well, but it makes doing the wrong thing easier.

The bigger issue is that this essentially allows you to use a browser as 
a media relay. This will be objected to in corporate (and some 
education) environments where there are sound reasons for disallowing 
user applications to take advantage of a high-bandwidth connection to 
relay media for third parties. It also may result in unexpected resource 
consumption on mobile platforms, where the user is paying in bandwidth 
charges and battery life to relay media for a third party. And unless 
implemented carefully, it can lead to relaying that is very unexpected 
(a banner ad that doesn't ask for permission to use your camera and 
microphone but does relay media for a third party while running).

Not to mention all the protocol-level implications of being an RTP 
mixer, if we're trying to stay true to that particular choice of protocols.

Matthew Kaufman