[AVTCORE] IANAs payload type number registry and RFC 5761

[Magnus Westerlund <[e-mail]>]

WG,
(As Chair)

I started writing on a email to IANA regarding our discussion and the
need to update the registry:
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1

After having reviewed RFC 3551, RFC 5761, the registry and the email
discuss and do question the recommendation the discussion and
https://datatracker.ietf.org/doc/draft-wu-avtcore-dynamic-pt-usage/ have
on this topic.

My understanding of Dale's original message to this list and the reason
for raising this issue is that people look at this table to determine
how to handle dynamic PT assignments. This is a closed registry and has
therefore not been updated. Also the relevant information around how to
chose dynamic payload type ranges are present now in two documents.
Namely RFC 3551, Section 3:

   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.  Redefining payload types below 96 may cause
   incorrect operation if an attempt is made to join a session without
   obtaining session description information that defines the dynamic
   payload types.

This is further expanded on given that one is using RTP/RTCP
multiplexing by RFC 5761 that adds the additional rules and
clarification 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.

Thus, if this is the main reason why people want to update the registry
I would recommend that we propose to IANA to update the registries note,
that is not particular helpful at this point.

I believe a good note for this registry would contain three things.

1. That the registry is closed, see RFC 3551, no additional
registrations will be done. The payload types that have a static mapping
are the below ones (0-34).

2. The "Reserved for RTCP conflict avoidance" in this table is not up to
date. Instead
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-4
provides the list of the RTCP types that has actually been registered.
Subtract 128 from the RTCP Packet Type value to find the corresponding
PT value with collision risk. For further information see RFC 3551 and
RFC 5761.

3. If you seek guidance on which PT values to use for assigning dynamic
payload types, then that is present in RFC 3551 (Section 3) and RFC 5761
(Section 4).

I think such a note update will continue to be more relevant that a
current patch to the reserved range. It also avoids the complexities
that the dynamic payload type assignment rules are different between
users of RFC 5761 and those who don't.

Comments

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------