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

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 25 Apr 2013 18:57:46 +0000

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 could only see that happening if products really need to support >32 codecs. (True codecs, not demux IDs for different streams in bundles.)

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Thursday, April 25, 2013 1:26 PM
To: [email-masked]
Subject: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Apr 2013 14:29:29 -0500

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Apr 2013 08:50:28 +0200

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:

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

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
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: Fri, 26 Apr 2013 14:20:52 -0400 (EDT)

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

(cleaning up my proposal)

I use the IANA registries as the reference for how the various number
spaces are managed.  The current final rows of the Payload Types table
read:

    35-71   Unassigned

I find these to be problematic in several ways:

1) RFC 5761 is not mentioned at all, despite that it provides
important modifications of the governing text in RFC 3551.  This is a
practical problem:  Note that Adam quoted the text in RFC 3551, not
the text in RFC 5761, and the 3551 text is now incorrect.

2) The range that is reserved for RTCP avoidance is not specified
correctly.  It's true that the rest of the RTCP avoidance range is
marked "Unassigned", but in the context of RFC 3551, that suggests
that they can be used as a secondary dynamic assignment area.

3) The range 35-71 should be marked more clearly as the secondary
dynamic assignment area.

Because of this, I suggest the following changes to this registry:

1) The "Reference" section should be changed from "[RFC3551]" to
"[RFC5761][RFC3551]".

2) The final rows should be changed to

    35-63   Unassigned/secondary dynamic area       [RFC5761]
    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]

Dale