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

Paul Kyzivat <> Mon, 27 May 2013 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 123F021F8D94 for <>; Mon, 27 May 2013 11:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.496
X-Spam-Status: No, score=0.496 tagged_above=-999 required=5 tests=[AWL=-0.267, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZEi1hY9DAr1U for <>; Mon, 27 May 2013 11:55:54 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:96]) by (Postfix) with ESMTP id 1CC0E21F8D00 for <>; Mon, 27 May 2013 11:55:53 -0700 (PDT)
Received: from ([]) by with comcast id h6Nl1l0011HzFnQ596vt5R; Mon, 27 May 2013 18:55:53 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id h6vt1l0073ZTu2S3a6vt0b; Mon, 27 May 2013 18:55:53 +0000
Message-ID: <>
Date: Mon, 27 May 2013 14:55:52 -0400
From: Paul Kyzivat <>
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
References: <> <> <> <> <>, <> <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1369680953; bh=1lF5MesolGYYAjOwiggQSdU4wT4V7MqeCnR0dbLxMN4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B2Kt5lv6vMOiiEwNEsWBGg9Hxdobn06Vlkgmb/Y6lMrl386fv79sdq7UJB9sAR3lW Um5ZfoNMhuBaz0ac50E05A22rwcsgdskrS5XpFpIYS1pKM1PVEVj3iiCFk/gWwKtWs A1M7EkAKntm4KNYAcCfaZq/nzUtUa/tlLalp5pEpl8HNjnTP/HARy83rCwb+XnHIC5 1yyaQlU7zz1eijGv+YGoGMQxEguE6W33k0hSZ5ZD1HgO8qIdYm9gPk+lsmE/37mgbl UKGwTj6oEf/rzfKc24nV9wG8WTPjrSD6SuknhsedHbgKaMhzDkqNFjv6onPEmjEjoJ M9PDQfFEz0Xsg==
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 May 2013 18:55:59 -0000

On 5/27/13 2:43 PM, Christer Holmberg wrote:
> Hi,
>>>>>>> v=0
>>>>>>> o=alice 2890844526 2890844526 IN IP4 s= c=IN IP4
>>>>>>> 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.
>>> 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?

The PT can be viewed as method of last resort for associating a packet 
with an m-line, because the PT is the one thing that could be used for 
that association that you *must* specify in RTP. Everything else that 
*could* be used (e.g., SSRC) is optional.

So if nothing else is present in the SDP that could be used then the PTs 
need to be unique per-m-line. But if something else is present, then it 
is no longer necessary that the PTs be unique.