Subject: [AVTCORE] IANAs payload type number registry and RFC 5761

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Jan 2014 16:19:01 +0100

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 Jan 2014 11:49:22 -0500 (EST)

> From: Magnus Westerlund <[email-masked]>

> [etc.]

A note containing all of this information would satisfy my concerns.

Dale

---

From: Adam Roach <[email-masked]>
Date: Thu, 23 Jan 2014 14:22:04 -0600

> A note containing all of this information would satisfy my concerns.

It's not my preferred solution, but I can live with this as well.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Jan 2014 13:07:05 +0100

> It's not my preferred solution, but I can live with this as well.

What would your preferred solution be? To update the registry?

I am personally hesitant to do that for the following reasons:

1. It is a closed registry

2. The registries purpose was to capture which static assignments that
had been made.

3. The dynamic payload type recommendations are done in RFC 3551.

4. If one is using the RTP/RTCP multiplexing of RFC 5761 that applies
also, but we do have different set of rules depending on if one is using
RFC5761 or not. That is difficult to capture in a static table.

5. The RTCP reservations are done in a different table, including an
indication of what the primary and secondary ranges for assignment are.

6. The PT's, i.e. lower 7 bits of the packets types that would collides
with is a ever changing. So updating it today doesn't help, if we are
going to use it in this way would need to continue to ensure that all
new RTCP packet types that goes into the RTCP Packet type registry also
get a line in the Payload type registry.

These are the reasons why I think a note being a better solution.

Cheers

Magnus Westerlund