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

[Magnus Westerlund <[e-mail]>]

Hi,

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?

Cheers

Magnus

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------