Re: [MMUSIC] Proposal for what bundle should say about demux

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 21:23 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9225121F8EC2 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 14:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.18
X-Spam-Level:
X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 Hfa9gkEJMB3Y for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 14:23:24 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89421F8EBE for <mmusic@ietf.org>; Mon, 27 May 2013 14:23:24 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id h8u41l0061GhbT85E9PPZv; Mon, 27 May 2013 21:23:23 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id h9PP1l00g3ZTu2S3T9PPh6; Mon, 27 May 2013 21:23:23 +0000
Message-ID: <51A3CECA.1080705@alum.mit.edu>
Date: Mon, 27 May 2013 17:23:22 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com> <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <C5E08FE080ACFD4DAE31E4BDBF944EB1135183E7@xmb-aln-x02.cisco.com> <A7E47BAA-5289-4C34-A9B9-6E8A1147D20F@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> <51A3AF2A.6030302@alum.mit.edu> <ACC62A7F-0CDC-4E55-8082-E8D5C3E6A7E4@csperkins.org> <51A3B5E3.6010404@alum.mit.edu> <79E64A40-452B-47C3-85B1-F037FD231E0F@csperkins.org>
In-Reply-To: <79E64A40-452B-47C3-85B1-F037FD231E0F@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369689803; bh=uLXca/WNrGxEzWfOu60bI3druwqdNaxmzwzWgNp/7Ok=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=flIxYEuQZGqFjWZMgT+6aSQg/Bq6HNfwQUlkgEQiM4gcGoIPUI6wtY0Tq7j9jo1h2 mYSE0IO6qyrBS37BgM1PvmNMFbduBu+sIotzMqMr0cmS0RvJjzqTD+zH0rrbAj4HNj np5FgEBmHWy/eqPRuzl3rPyeJnihyuMVsttHu9DD4Igbm0vMQ+QvjxqXnCLJ5gpuz0 auSV7tDUDE4IKrd6C+EeVfIXyUSSyXK8msm0O4QKzblAnHOnum7wV/eO2/7lcpJ7hx 6l/sP0umN7/ql1UGU94ML6pRgA6z1VI/ht7JzHYHt5Ogxy4BD4xRj8quYhoVBpRt0I HnfFsNb9ezMcg==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 May 2013 21:23:30 -0000

On 5/27/13 4:12 PM, Colin Perkins wrote:
> On 27 May 2013, at 20:37, Paul Kyzivat wrote:
> ...
>> I agree there is no *need* to relax the PT uniqueness requirement in order to map the packets (or sources if you prefer) to m-lines.
>>
>> But (at least with plan A) there is a concern that there will be insufficient PTs to keep them unique per-m-line.
>>
>> What I am saying is that if you do the mapping to m-line *before* the mapping from PT to payload format, then you *can* relax the PT uniqueness requirement.
>
> That would mean using signalled SSRC values to map from an RTP source to an m= line. Once you've done that, though, it's not clear that you need that many unique payload types (since if you're using the same payload format in two m= lines you can use the same payload type in both, when using a signalled SSRC to distinguish the m= lines).

Yes, that may be true. If that is sufficient for people its ok with me.
But it does still mean, in response to Christer, that the same PT might 
be in multiple m-lines in the bundle.

>> This isn't violating precedent, because there is no precedent. Neither the problem nor the solution are present without bundling.
>
> There's precedent in that the RTP specifications assume the mapping is fixed in a single RTP session.

There is also precedent that you don't have audio and video in the same 
RTP session. We are going to be breaking *some* precedents. Its just a 
matter of which ones are sacred.

	Thanks,
	Paul