Re: [clue] comment on draft-lennox-clue-rtp-usage-0

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 13 February 2012 15:57 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA321F8526 for <clue@ietfa.amsl.com>; Mon, 13 Feb 2012 07:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level:
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 E7TomBDgO-So for <clue@ietfa.amsl.com>; Mon, 13 Feb 2012 07:57:52 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEA121F8492 for <clue@ietf.org>; Mon, 13 Feb 2012 07:57:51 -0800 (PST)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZTmu1i0070SCNGk5DTxs8G; Mon, 13 Feb 2012 15:57:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id ZTxs1i00R07duvL3VTxsFx; Mon, 13 Feb 2012 15:57:52 +0000
Message-ID: <4F3932FE.7050803@alum.mit.edu>
Date: Mon, 13 Feb 2012 10:57:50 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: clue@ietf.org
References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com>
In-Reply-To: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 15:57:53 -0000

On 2/13/12 6:21 AM, Roni Even wrote:
> Hi,
>
> My view is that there are two separate problems that the draft discusses:
>
> 1.The co-relation between the media capture and the codec information in
> the offer answer
>
> 2.Multiplexing multiple media streams.
>
> I think that the second problem is addressed in
> http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00

> As for the mapping I have a proposal to use a capture set group in the
> SDP for the ampping

Using that solution means that there will be one or more lines in the 
SDP for each capture that *might* be carried. In the case of a large 
conference and switched streams this could potentially be hundreds of 
captures. I expect that having an SDP with hundreds of m-lines will 
likely be considered unacceptable.

I presume you are assuming somehow the number of m-lines need not be so 
great. I guess that means that either its limited to conferences with 
fewer total captures, or else that the number of captures described in 
SDP can be very limited compared to the total number that exist.

Can you elaborate your thinking?

	Thanks,
	Paul