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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 05 June 2013 15:53 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 7873A21F9B2B for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 08:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.261
X-Spam-Level:
X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.176, 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 d4HrT1XBGBDh for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 08:53:21 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A921F9AED for <mmusic@ietf.org>; Wed, 5 Jun 2013 08:53:20 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id kb2R1l00327AodY58ftL6e; Wed, 05 Jun 2013 15:53:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id kftK1l01D3ZTu2S3fftK4k; Wed, 05 Jun 2013 15:53:20 +0000
Message-ID: <51AF5EEE.8080904@alum.mit.edu>
Date: Wed, 05 Jun 2013 11:53:18 -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: Cullen Jennings <fluffy@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> <FF8A3ABB-992C-48D9-856F-A6A21A35A0C1@iii.ca>
In-Reply-To: <FF8A3ABB-992C-48D9-856F-A6A21A35A0C1@iii.ca>
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=1370447600; bh=+9sS19E8Ugx7/PGMeIP4HrAVr7xbbhp/U9N0smJeWI8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HtghmHXgpJIW/qCHwbEiDd4XiIERjIBi0RKZ8yf8ASi8delsPmZVTMnpWtNTbK3UW c/XFMTlawK5zrUlzi4qd/2K5RxEwAnFUPgHXLhlp+2Ec3X5b9gVqmcrc+l0txf2INt OpovXZOI1fSWIERUwMyYjksSQ4BfGQ3YoXfenwViuFrtJ3hJ9OImUSjZBpt20tV0XU dPZWiWV1mOzm/+2xfyo8KkiAhBLLpxTZNE6za13PFWLdb14RR7iCWnFKPTOjOVJuXH BwgITG0f8KQkpsX2qO6sTbQeoMpRJalE/au2yKe8Oc0+0HBnxdNd7cBKNgJVhNBrzv WLWJs1N8gaKtQ==
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 15:53:29 -0000

On 6/3/13 6:49 PM, Cullen Jennings wrote:
>
> 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.

I don't understand. Why do you want to use multiple m-lines on one port? 
If you don't need to associate the packets with a particular one of 
those m-lines, then why didn't you use a single m-line?

E.g., if your reason is because one is audio and another is video then 
you certainly want to associate the packets with one or the other.

ISTM that the whole point of Plan A is that each m-line is associated 
with a specific use/rendering, and so it is essential to associate 
incoming packets with a particular one of the m-lines.

	Thanks,
	Paul

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