Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt

[Colin Perkins <[e-mail]>]

Qin,

Comments inline.

Colin

On 4 Sep 2013, at 02:48, Qin Wu <[e-mail]> wrote:
> Hi,Colin:
>  
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Colin Perkins
> Sent: Wednesday, September 04, 2013 12:20 AM
> To: Roni Even
> Cc: [e-mail]
> Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt
>  
> Hi Roni,
>  
> On 2 Sep 2013, at 12:55, Roni Even <[e-mail]> wrote:
> Hi Colin,
> The major motivation is to update the closed IANA registry
> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1 that points to RFC 3551 and does not have the right allocations by referring to this document , I have the wrong pointer in the draft. This is based on the email thread started with the attached email.
>  
> I would have thought that could be resolved with an email to IANA, rather than a new draft, since all you're doing is updating the registry to match the published RFCs.
>  
> [Qin]: One of motivation to write this draft, I think , is to avoid running out of possible payload type space in case of multiple RTP
>    streams in a single session, we need some guideline on how to use dynamic payload type number space.

RFC 3551 and 5761 provide that guidance already. Your draft just seems to repeat that guidance. 

> One example, is RFC2032 is obsoleted by RFC4587, RTCP Control Packet types 192,193 should be called back and recycled for
> dynamic payload number allocation when payload number space is a issue, since one principle defined in RFC5761 is
> “for each RTP payload type (PT), PT+128 is distinct from the RTCP packet types used.”

This seems to be the only change compared to RFC 5761: to allow RTP payload types 64 and 65 to be used as a last resort. I'm unconvinced this is worth the trouble, but maybe.

> Another open issue we want to solve is as pointed by section 4, editor note, can we recommend re-use of payload type in
> bundled m-lines if they map to the same payload format here, if yes, that is something different from RFC3551.

That's an issue for the BUNDLE specifications, and not something that should go into a draft updating RFC 3551.

> The other reason is to clarify which payload types from the range 0-95 can be used for dynamic mapping and in what order. This is based on the MMUSIC session in Berlin and the open issue in section 3.2.1.2 of
> http://tools.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt
>  
> But, the draft just seems to repeat the guidelines in RFC 5761 and 3551. The only difference seems to be to give an explicit order in which the unassigned payload type numbers are to be used, which seems unnecessary.
>  
> [Qin] Yes, explicit order is not necessary, however that is not what we proposed in this draft( i.e., to give the order).
> One thing I am not sure is do you believe Support for multiple RTP
>  streams in a single session which is recommended in order
> to reduce the number of open transport connections can
>  exhaust the payload type space.

I'm not convinced that exhausting the RTP payload type space is a real problem in practice. However, even if it is a real problem, I don't think the additional two payload types made available by draft will solve it. 

-- 
Colin Perkins
http://csperkins.org/