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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 18:38 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 8DA8821F94DC for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 11:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.42
X-Spam-Level:
X-Spam-Status: No, score=0.42 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, 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 DrBO6Xm1U2-0 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 11:38:34 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 87E1D21F9418 for <mmusic@ietf.org>; Mon, 27 May 2013 11:38:34 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id h6221l0061swQuc566eawx; Mon, 27 May 2013 18:38:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id h6eZ1l00o3ZTu2S3b6eZRj; Mon, 27 May 2013 18:38:33 +0000
Message-ID: <51A3A829.7050201@alum.mit.edu>
Date: Mon, 27 May 2013 14:38:33 -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: mmusic@ietf.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>
In-Reply-To: <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org>
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=1369679914; bh=k7WSWFaDBTzeO3XqA9dK0uo7CGGo5/v1VZE2R0JDMcI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Yrpup20E0SVUOaj70NKwVwHScTDSlN7IcameyVVuNdVYL1bv95D20c2EZhKstXCkQ HIYIay60guTA0zD14SyYH9VHqQHf+KXcKWF8inF6MULbvD9hFC48jOH0X4VwrRwAHy 0cH2/1nItnzh4X4fZ3dmnEFuOftWTD3rVMdfGQ971uVb5Klws8Z4RO4ij2HEubCFAl 2q348fsO4hKux76cycVRcznnJlJsAIvOqGGNwMsqSFTvz6k6xHCJzD+7Q1PpUPgX6Q mFeZEgM23Z/gFAM8mM1SPG0BcOppz7ZmztcSXClwOooKDZdAE8V0sBbl6ZK9El3s3A 6x99KqBRQYJsQ==
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 18:38:39 -0000

On 5/27/13 2:10 PM, Colin Perkins wrote:
> On 27 May 2013, at 18:55, Christer Holmberg wrote:
>>>>>> v=0
>>>>>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4
>>>>>> host.anywhere.com
>>>>>> t=0 0
>>>>>> m=audio 49170 RTP/AVP 96
>>>>>> a=rtpmap:96 AMR-WB/16000
>>>>>> m=audio 49170 RTP/AVP ???
>>>>>> a=rtpmap:??? AMR-WB/16000
>>>>>
>>>>> Not sure I get your point. You can have two different payload types that map to the same payload format in a single RTP session, since
>>>>> you can always distinguish what payload format is intended. You can't have the same payload type mapping to two different payload
>>>>> formats in a single RTP session, since you can't then infer what payload format was meant.
>>>>
>>>> Please not that both PTs map to the SAME payload format :)
>>>
>>> I thought I addressed that in my reply.
>>
>> I am not sure you did - at least I didn't get it :)
>>
>> Again, my understanding of what you said is that, for any payload format within an RTP session, the PT value has to be unique.
>
> Correct.

Now you're both confused. What you are trying to say is that for any PT 
value withing an RTP session the payload format must be unique.

E.g., two different PTs may map to the same format, but one PT may not 
map to two different formats.

But I continue to argue that we could relax that, as long as there is 
something else that selects which PT mapping to use.

>> 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. Mapping the same payload type to two different payload formats is the problem.

It depends. *If* you are trying to use the PT to associate packets to an 
m-line, then indeed you might need to use different PT values for the 
same payload format in order to accomplish that.

	Thanks,
	Paul