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

Cullen Jennings <fluffy@iii.ca> Wed, 05 June 2013 00:01 UTC

Return-Path: <fluffy@iii.ca>
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 7533521F9A2B for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level:
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219]
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 UcYO5orgFSRk for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:01:52 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A58721F9A20 for <mmusic@ietf.org>; Tue, 4 Jun 2013 17:01:48 -0700 (PDT)
Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CFBF22E257; Tue, 4 Jun 2013 20:01:41 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51A3B070.1090006@alum.mit.edu>
Date: Mon, 03 Jun 2013 16:49:44 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF8A3ABB-992C-48D9-856F-A6A21A35A0C1@iii.ca>
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.1503)
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: Wed, 05 Jun 2013 00:01:58 -0000

On May 27, 2013, at 1:13 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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.

I'm not sure this makes a huge difference to your argument but I don't think I agree with the above. 

It seems that even if you don't care which m-line the media get associated with, if you want to use a single port for all the m-line, you still need bundle. 


> 
> So if you used bundle, you must care, and so there must be a way to achieve that association.
> 
> 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.
> 
> 	Thanks,
> 	Paul