Re: [rtcweb] ROAP Example Application

Tim Panton <tim@phonefromhere.com> Fri, 21 October 2011 11:13 UTC

Return-Path: <tim@phonefromhere.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 957A621F8AFD for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 04:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level:
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 CN4hfpvKWb9E for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 04:13:27 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id EC05521F891D for <rtcweb@ietf.org>; Fri, 21 Oct 2011 04:13:26 -0700 (PDT)
Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 07E4337A902; Fri, 21 Oct 2011 12:26:12 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <4EA150BC.9040605@alvestrand.no>
Date: Fri, 21 Oct 2011 12:13:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <58EF1980-E869-4B0F-8C7D-99029EFB45C3@phonefromhere.com>
References: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com> <4EA11552.3010507@skype.net> <4EA150BC.9040605@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1251.1)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ROAP Example Application
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: Fri, 21 Oct 2011 11:13:27 -0000

On 21 Oct 2011, at 12:00, Harald Alvestrand wrote:

> 
> As I've noted before, they are more entangled than one might like them to be; if we don't support the extension to use a single RTP session, we don't know how many ICE sessions we need to set up until we know at least how many top level media types we want to support. If we want to support multiple RTP sessions for other reasons, we need similar control of the number of ICE sessions set up.

Who is 'we' ? Surely the decision of how many top level media types to support _must_ be taken at the 
application layer. The application has to make screen real-estate available for things like video, keypads etc.

> 
> It illustrates that while a lot of the concerns of codecs and ICE sessions are reasonably separate, the functions that manipulate RTP sessions need access to both.

And in my view the javascript needs access to _all_ 3 of them.

Tim.