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

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

> From: "Mo Zanaty (mzanaty)" <[e-mail]>
> 
> 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.

The range 35 to 63 is already available as a secondary dynamic area,
given these sentences from RFC 5761

    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.

Strictly speaking, the secondary dynamic area is 35-63, along with
20-24, 27, and 29-30.  And the static assignments form a tertiary
dyanmic area.  (As Adam says, make sure your products work even if
statically-assigned PTs are assigned to different codecs.)

> I
> could only see that happening if products really need to support >32
> codecs. (True codecs, not demux IDs for different streams in
> bundles.)

People say that real products may use as many as 30 codec numbers now,
so I'd want to plan for at least 64 PTs being used.

Dale