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

I think this would be useful, if only to make clear that # of PTs is
extremely limited.

On Thu, Apr 25, 2013 at 10:25 AM, Dale R. Worley <worley@ariadne.com> wrote:

> I was looking at the IANA registry "RTP Payload types (PT) for
> standard audio and video encodings"
> (
> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-1
> )
> to see what the allowed dynamic payload types are, and what PTs are
> reserved to avoid confusion with RTCP.  The unassigned range is:
>
> 35-71   Unassigned
> 72-76   Reserved for RTCP conflict avoidance    [RFC3551]
> 77-95   Unassigned
> 96-127  dynamic                                 [RFC3551]
>
> Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Data
> and Control Packets on a Single Port"), which gives these
> instructions in section 4:
>
>    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.
>
> Since the entire range 64 to 95 is now reserved, the table should
> read:
>
> 35-63   Unassigned
> 64-71   Reserved for RTCP conflict avoidance    [RFC5761]
> 72-76   Reserved for RTCP conflict avoidance    [RFC3551]
> 77-95   Reserved for RTCP conflict avoidance    [RFC5761]
> 96-127  dynamic                                 [RFC3551]
>
> IMHO, it would be helpful to get this table up to date with regard to
> the RFCs, even though it is marked "Closed".
>
> Do people agree with me on this?  (And how do we go about it?  I
> assume that the AD can route it to IANA.)
>
> (This also limits us to 61 PTs, which is another matter.)
>
> Dale
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>