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

Adam Roach <> Thu, 25 April 2013 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6EDD21F850E; Thu, 25 Apr 2013 12:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BxN63Fn1bmap; Thu, 25 Apr 2013 12:29:40 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 3052F21F84F5; Thu, 25 Apr 2013 12:29:40 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r3PJTT13005817 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 14:29:30 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Thu, 25 Apr 2013 14:29:29 -0500
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060404010905000303020204"
Received-SPF: pass ( is authenticated by a trusted mechanism)
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: Thu, 25 Apr 2013 19:29:41 -0000

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.