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

["Roni Even" <[e-mail]>]

Hi Colin,
The major motivation is to update the closed IANA registry
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-para
meters-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.

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 

Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: 02 September, 2013 1:07 PM
> To: Roni Even
> Cc: [e-mail] WG
> Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-
> dynamic-pt-usage-00.txt
> 
> Roni,
> 
> Can you explain what's new in this draft? As far as I can tell, it just
repeats the
> guidance in RFCs 3551 and 5761.
> 
> Colin
> 
> 
> 
> On 30 Aug 2013, at 17:33, Roni Even <[e-mail]> wrote:
> > Hi,
> > Apologize for the cross posting. Please comment only in avtcore
> > mailing list
> >
> > We have submitted a draft that clarifies the usage of dynamic payload
type
> numbers.
> > This is based on email discussion in MMUSIC Thanks Roni Even
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: 30 August, 2013 7:29 PM
> > To: Qin Wu; Wenson Wu; Rachel Huang; Roni Even; Rachel Huang
> > Subject: New Version Notification for
> > draft-wu-avtcore-dynamic-pt-usage-00.txt
> >
> >
> > A new version of I-D, draft-wu-avtcore-dynamic-pt-usage-00.txt
> > has been successfully submitted by Qin Wu and posted to the IETF
> repository.
> >
> > Filename:	 draft-wu-avtcore-dynamic-pt-usage
> > Revision:	 00
> > Title:		 Guideline for dynamic payload type number usage
policy
> > Creation date:	 2013-08-30
> > Group:		 Individual Submission
> > Number of pages: 5
> > URL:             http://www.ietf.org/internet-drafts/draft-wu-avtcore-
> dynamic-pt-usage-00.txt
> > Status:
http://datatracker.ietf.org/doc/draft-wu-avtcore-dynamic-pt-
> usage
> > Htmlized:        http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-
> usage-00
> >
> >
> > Abstract:
> >   The RTP Profile for Audio and Video Conferences with Minimal Control
> >   (RTP/AVP) is the basis for many other profiles, such as the Secure
> >   Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for
> >   Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
> >   AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback
> >   (RTP/SAVPF).  This document updates RFC 3551 and provide guidelines
> >   for payload type number usage policy.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 

--- Begin Message ---

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-param
eters-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
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic

--- End Message ---