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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 05 June 2013 16:48 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 696DB21F9BD8 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.171, 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 C5wrMxjSGoVi for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:47:55 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9695721F9BD2 for <mmusic@ietf.org>; Wed, 5 Jun 2013 09:47:55 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id kgMQ1l0051HzFnQ51gnvUD; Wed, 05 Jun 2013 16:47:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id kgnu1l00U3ZTu2S3agnvge; Wed, 05 Jun 2013 16:47:55 +0000
Message-ID: <51AF6BB9.3010807@alum.mit.edu>
Date: Wed, 05 Jun 2013 12:47:53 -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: Christer Holmberg <christer.holmberg@ericsson.com>
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> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370450875; bh=rVmXuABfraRWi1mJKFVLupJ4KOMNgS8He9EnuemYHQI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Yx4/2LXP09OdnThHoeiM9AjJxVcu7wvHEfqO3ZgEzKkoURBQtrCjTGerxSEhe9T1R 6kfYbvuVlkedlWQZT1eWO7rYDXXHNDdO0TKPxiOQMnaCsT311Rirj8OE2Ni4R4w1jU MzIu8r6hLFYj8f3msnc9ZE02vHaiPVzhrMgzY7Anq7EQ1NKsfTLkO3wCEASFLAwL/v MPhTnl/bg0447gUEuSk+tHiCu6qaeyajUKwdid9OvFJdUErmoeh5bqUsAsQbnCVUEL czHtxKiQKZ7gIyqpOv1toTSrKZQ688v7HCJdh3JpxPGYPZ1Je35PMNN+0KGddWODiV FsRrDArd7vJ/g==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>
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 16:48:00 -0000

On 6/5/13 12:23 PM, Christer Holmberg wrote:
> Hi,
>
> I think there are many reasons why one would want to use different m- lines. Eventhough the transport characteristics are the same (if you use BUNDLE, that is), there other things that may be different. Just to give a simple example: the direction attribute value, content attribute value, and anything related to the "scope"/"context" of the m- line.

Christer - I suspect we are on the same page.

I agree there are many reasons one might want to bundle m-lines.
But I assert that every one of those reasons will also require that you 
be able to associate incoming packets with a particular one of those 
m-lines.

I don't understand why this is in question. I originally stated it as a 
truism because I thought it was self evident.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>
>
> -----Alkuperäinen viesti-----
> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Paul Kyzivat
> Lähetetty: 5. kesäkuuta 2013 18:53
> Vastaanottaja: Cullen Jennings
> Kopio: mmusic@ietf.org
> Aihe: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
>
> 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
>>
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>