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

Colin Perkins <csp@csperkins.org> Mon, 27 May 2013 20:12 UTC

Return-Path: <csp@csperkins.org>
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 8EEBD21F9684 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 13:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 e1RO+A8OvMaP for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 13:12:54 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6398A21F8FA5 for <mmusic@ietf.org>; Mon, 27 May 2013 13:12:54 -0700 (PDT)
Received: from [81.187.2.149] (port=46150 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Uh3mh-0007gG-Kq; Mon, 27 May 2013 21:12:53 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <51A3B5E3.6010404@alum.mit.edu>
Date: Mon, 27 May 2013 21:12:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <79E64A40-452B-47C3-85B1-F037FD231E0F@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>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
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 20:12:59 -0000

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). 

> 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. 



-- 
Colin Perkins
http://csperkins.org/