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

Colin Perkins <csp@csperkins.org> Mon, 27 May 2013 13:05 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 43D4C21F9626 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 06:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.639
X-Spam-Level:
X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, 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 oMEW9QVUK8bF for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 06:05:07 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48E21F9625 for <mmusic@ietf.org>; Mon, 27 May 2013 06:05:07 -0700 (PDT)
Received: from [81.187.2.149] (port=42240 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 1Ugx6l-0004TQ-RG; Mon, 27 May 2013 14:05:06 +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: <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>
Date: Mon, 27 May 2013 14:05:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <599C780A-F483-470E-91F2-68DBA605C79C@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>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "mmusic@ietf.org WG" <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 13:05:12 -0000

On 27 May 2013, at 14:02, Christer Holmberg wrote:
>>>>> There were a number of comments in the call last week, and on the list, about unique payload types in BUNDLE. I'd like to explore this further.
>>>>> 
>>>>> Case A: Within a single RTP session, I think we'd all agree that an offer that uses the same RTP payload type for two payload formats on a single m= line is problematic: 
>>>>> 
>>>>> 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
>>>>> a=rtpmap:96 G7291/16000
>>>>> 
>>>>> If this were done the receiver would have no way of distinguishing what payload format is meant by payload type 96. Accordingly, unique payload formats need to be used for each payload format.
>>>> 
>>>> That should be "...unique payload types need to be used for each payload format" of course.
>>> 
>>> What if you have two m- lines, with identical encoding in both? Both 
>>> represent the same payload format, don't they? :)
>>> 
>>> 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.

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