Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

Colin Perkins <csp@csperkins.org> Mon, 27 May 2013 19:24 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 7746521F96C1 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 12:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.228
X-Spam-Level:
X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 zdvaiwxKNSYj for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 12:24:28 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA65921F96AD for <mmusic@ietf.org>; Mon, 27 May 2013 12:24:27 -0700 (PDT)
Received: from [81.187.2.149] (port=41046 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 1Uh31u-0000er-7f; Mon, 27 May 2013 20:24:27 +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: <51A3B070.1090006@alum.mit.edu>
Date: Mon, 27 May 2013 20:24:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC6422F6-8049-4E28-937F-54282EF5CD06@csperkins.org>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@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] Scope of RTP payload types in BUNDLE?
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 19:24:39 -0000

On 27 May 2013, at 20:13, Paul Kyzivat wrote:
> On 5/27/13 2:52 PM, Colin Perkins wrote:
>>>>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I?
>>> 
>>>> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines.
>>> 
>>> But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines?
>> 
>> You don't. If you care about that, you need to either use distinct PT values for each m= line, or signal SSRCs.
> 
> I assert that if you don't care about associating a packet to a particular m-line in a bundle that you don't need to use bundle.

Sure.

> So if you used bundle, you must care, and so there must be a way to achieve that association.

Sure.

> The reason you care is because doing so allows you to discover all the other things in that media section of the SDP that may be pertinent to this packet.


Sure. 

But, again, let's keep the discussion of mapping RTP/RTCP packets onto RTP sources separate from the discussion of how to map the RTP sources onto m= lines. The former is well-defined by RTP, the latter is not yet defined. Proposals for solving the latter shouldn't start with "when a packet arrives, first do this", because that's the domain of the RTP source de-multiplexing process; rather they should consider "how do we map this RTP-level source (i.e., a sequence of RTP and RTCP packets identified by SSRC, whether signalled or not) onto an m= line". 

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