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

[Adam Roach <[e-mail]>]

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