Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?

Magnus Westerlund <> Fri, 26 April 2013 06:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CD6E21F9743; Thu, 25 Apr 2013 23:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QK2M1woNImUR; Thu, 25 Apr 2013 23:50:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DEFA321F856D; Thu, 25 Apr 2013 23:50:35 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-3c-517a23bab713
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 46.CC.19728.AB32A715; Fri, 26 Apr 2013 08:50:34 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 26 Apr 2013 08:50:34 +0200
Message-ID: <>
Date: Fri, 26 Apr 2013 08:50:28 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Adam Roach <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvre4u5apAg5Vr1S32/F3EbjF1+WMW ixcP5jBZXLp4lsmBxWPK742sHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXRv/hJpaCbumK j49msjYw3hDtYuTkkBAwkbj+9zEbhC0mceHeeiCbi0NI4BSjxIWtJ5ghnOWMEheXTwGr4hXQ lri+9RQjiM0ioCqx/PlDZhCbTcBC4uaPRqAaDg5RgWCJra0xEOWCEidnPmEBsUUEFCXaDt8E K2cWqJO4cGM6O0i5sICvxOavchCr5jNK7Fx5DWw8J9Cq5zsfQB0nKbHlRTs7RK+exJSrLYwQ trxE89bZYDOFgOobmjpYJzAKzUKyehaSlllIWhYwMq9iZM9NzMxJLzfaxAgM5INbfqvuYLxz TuQQozQHi5I47wypykAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNsO1lyuli1MzzC/sXL2 0oi4X7dWFOdc4ep7FLHvePOfBcUcrxQ6wv5pTn1s+K7ubs1klu3RfNn/26sFd92q4hPh0M78 WxwxU+BI9wSd7t8d1kvrp+RO5jK6Ovfzxqm2HH9z7rQKTP6yp4Jvw261K5zVvj2FRYeuLpJd ev7i5oy+uWmcGx6FnlFiKc5INNRiLipOBAAk/f62MgIAAA==
Cc: "" <>, "" <>
Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?
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: Fri, 26 Apr 2013 06:50:38 -0000


And to add to that. These limitations are only present given that you
actually are using RTP and RTCP multiplexing. You can regain the whole
128 numbers by having RTP and RTCP separated.

This quote from RFC 5761:

   Given these constraints, it is RECOMMENDED to follow the guidelines
   in the RTP/AVP profile [7] for the choice of RTP payload type values,
   with the additional restriction that payload type values in the range
   64-95 MUST NOT be used.  Specifically, dynamic RTP payload types
   SHOULD be chosen in the range 96-127 where possible.  Values below 64
   MAY be used if that is insufficient, in which case it is RECOMMENDED
   that payload type numbers that are not statically assigned by [7] be
   used first.

I think is clear that you have 96 values for use. The MUST NOT is really
to ensure that you will not have issues. Assuming tighter signalling
control could have allowed dynamic blocking of the space, but that was
deemed to complex and error prone.

Regarding the IANA, Mo you have correctly identified the registry as
closed and Adam pointed to the relevant text. Is this level of
indirection so problematic that this registry needs a Note to the effect?



On 2013-04-25 21:29, Adam Roach wrote:
> On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote:
>> I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic.
> I think RFC 3551, section 3 is still the governing text on how RTP/AVP
> (and its related profiles) allocates payload types:
>>  "This profile reserves payload type numbers in the range 96-127
>>   exclusively for dynamic assignment.  Applications SHOULD first use
>>   values in this range for dynamic payload types.  Those applications
>>   which need to define more than 32 dynamic payload types MAY bind
>>   codes below 96, in which case it is RECOMMENDED that unassigned
>>   payload type numbers be used first.  However, the statically assigned
>>   payload types are default bindings and MAY be dynamically bound to
>>   new encodings if needed."
> (With particular emphasis on the final quoted sentence)
> So, _practically_ speaking, the proposed registry update does make a big
> difference: it clarifies that 64-71 and 77-95 are off limits. Also,
> _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct
> codecs, since even the statically assigned payload types can be rebound.
> If you work with teams that are under the mistaken impression that you
> cannot dynamically re-bind the first 64 RTP payload types, I would beg
> you to disabuse them of that notion.
> /a
> _______________________________________________
> mmusic mailing list


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: