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

[[e-mail] (Dale R. Worley)]

> From: "Roni Even" <[e-mail]>
> 
> We started working in it see
> http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-usage-01 
> Please review

I wasn't on the mailing list when that came out!

It looks like it does what is needed.

I have the following comments on draft-wu-avtcore-dynamic-pt-usage-01:

1. As others have said, the WG can simply instruct IANA to update the
assignment table, but since we want to prescribe the order of
allocation of dynamic PTs, and that requires an RFC, we might as well
put the table update in the same RFC.

2. Given the complexity of the considerations surrounding PTs 64 and
65, there should be a section that explains all of the history and
considerations.

3. In section 3, the sequence in which payload types should be
allocated is given all in one dense paragraph.  It would probably be
clearer if the allocation order was broken out as an explicit list.
If I just separate the sentences that are now in the draft, there are
*five* groups to be used in order:

   Applications SHOULD first use values in the range for dynamic
   payload types [96-127].

   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 [35-63] followed
   by ...

   ... [20-24], 27, [29-30].

   If more payload type numbers are needed, the application may use
   the reserved values 1,2,19 (see [RFC3551]for reserved values) and
   64, 65 (see [RFC5761]for reserved value).

   If more Payload type numbers are needed, then applications may
   override the static types[0, 3-18,25,26,28] map encodings to these
   defined static payload type but this may cause problems for
   applications that may assume a specific payload format based on the
   Payload Type ignoring the mapping in the signaling.

Dale