Return-Path: 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 ; 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 ; 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 ; 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 ) 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 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: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <51A39870.7040708@alum.mit.edu> <6E11F505-6808-4E09-9359-8494B795BEDD@csperkins.org> <51A3AF2A.6030302@alum.mit.edu> <51A3B5E3.6010404@alum.mit.edu> To: Paul Kyzivat 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >=20 > But (at least with plan A) there is a concern that there will be = insufficient PTs to keep them unique per-m-line. >=20 > 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=3D 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=3D lines you can use the same payload type in = both, when using a signalled SSRC to distinguish the m=3D lines).=20 > 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.=20 --=20 Colin Perkins http://csperkins.org/