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

From: Colin Perkins <[email-masked]>
Date: Mon, 2 Sep 2013 11:07:06 +0100

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

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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Sep 2013 14:55:53 +0300

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

> From: Colin Perkins [mailto:[email-masked]]
> Sent: 02 September, 2013 1:07 PM
> To: Roni Even
> Cc: [email-masked] 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
> 
> 
> 
> > 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
> >
> > Status:
http://datatracker.ietf.org/doc/draft-wu-avtcore-dynamic-pt-
> usage
> > 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.
> > Audio/Video Transport Core Maintenance [email-masked]

Subject: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?
From: "Dale R. Worley" <[email-masked]>
To: <[email-masked]>
Date: Thu, 25 Apr 2013 20:25:52 +0300

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 3 Sep 2013 14:49:27 +0200

Hi,

I have also looked at this. I think the introduction needs to be much
clearer on what this document's purpose is. To my understanding it is
two fold:
1. Clarify to implementors that yes you can use the payload types in the
lower range for dynamic, including the overriding the static ones.
2. Update the closed IANA registry to actually combine the different set
of changes and make the current state clear.

Based on that I don't see a need to update RFC 3551 in the way section 3
does it.

Maybe I have misunderstood the drivers behind it, but the above is what
I have gotten from the public list discussions I have read.

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: Colin Perkins <[email-masked]>
Date: Tue, 3 Sep 2013 17:19:59 +0100

Hi Roni,

On 2 Sep 2013, at 12:55, Roni Even <[email-masked]> wrote:
> 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.

> 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

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.

Colin

> <Mail Attachment.eml>

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

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Sep 2013 01:48:10 +0000

Hi,Colin:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: Wednesday, September 04, 2013 12:20 AM
To: Roni Even
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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.

[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.

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."

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.

[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.

That's something brought up in the open issue part of draft-roach-mmusic-unified-plan-00.

Colin

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]<http://csperkins.org>]
Sent: 02 September, 2013 1:07 PM
To: Roni Even
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-
dynamic-pt-usage-00.txt

Roni,

Colin

On 30 Aug 2013, at 17:33, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
Apologize for the cross posting. Please comment only in avtcore
mailing list

numbers.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
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:

usage

Htmlized:        http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-
usage-00

Abstract:

The IETF Secretariat

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

<Mail Attachment.eml>

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

---

From: "Roni Even" <[email-masked]>
Date: Wed, 4 Sep 2013 08:30:28 +0300

Hi Colin,

We will update the document provide the updated table.

The document adds two things to RFC 5761, it clarifies and  recommend the
order by which to use the pt numbers. it allows as an  option to use pt
umber 64 and 65 .

This will make it easier for implementers mostly because of the need for pt
numbers when using bundle.

Roni

From: Colin Perkins [mailto:[email-masked]] 
Sent: 03 September, 2013 7:20 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [AVTCORE] New Version Notification for
draft-wu-avtcore-dynamic-pt-usage-00.txt

Hi Roni,

Hi Colin,

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.

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.

Colin

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: 02 September, 2013 1:07 PM
To: Roni Even
Cc: [email-masked] WG
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-
dynamic-pt-usage-00.txt

Roni,

repeats the

Colin

Hi,

type

numbers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 30 August, 2013 7:29 PM
To: Qin Wu; Wenson Wu; Rachel Huang; Roni Even; Rachel Huang
Subject: New Version Notification for

repository.

policy

dynamic-pt-usage-00.txt

Status:

usage

usage-00

Abstract:

tools.ietf.org.

The IETF Secretariat

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

<Mail Attachment.eml>

-- 

Colin Perkins

http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 4 Sep 2013 23:13:36 +0100

Hi Roni,

I really don't think you need a new draft to update this table. There is an existing RFC that reserves those payload types; just ask IANA to make the correction to the registry.

I'm also struggling to see the benefit in listing the order is which the payload types are to be assigned, beyond that which is in RFC5761/3551.

Colin

On 4 Sep 2013, at 06:30, Roni Even <[email-masked]> wrote:
> The document adds two things to RFC 5761, it clarifies and  recommend the  order by which to use the pt numbers. it allows as an  option to use pt umber 64 and 65 .
> This will make it easier for implementers mostly because of the need for pt numbers when using bundle.
> Roni
>  

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 4 Sep 2013 23:26:41 +0100

Qin,

Comments inline.

Colin

>    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. 

> “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.

> 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.

>  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/

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Sep 2013 02:42:19 +0000

Hi,Colin:
For motivation, May I point you to look at the following discussion on MMUSIC mailing list:
http://www.ietf.org/mail-archive/web/payload/current/msg00542.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg11062.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg11107.html

I don't know it is sufficient to just send some proposed IANA changes to IANA.
Usually based on my understanding, a document is needed to let IANA to take action.

For your comments, I do think we give a new policy for new payload format coming up,
please see my reply below.

Regards!
-Qin
From: Colin Perkins [mailto:[email-masked]]
Sent: Thursday, September 05, 2013 6:27 AM
To: Qin Wu
Cc: Roni Even; [email-masked]
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt

Qin,

Comments inline.

Colin

On 4 Sep 2013, at 02:48, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi,Colin:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Colin Perkins
Sent: Wednesday, September 04, 2013 12:20 AM
To: Roni Even
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt

Hi Roni,

[Qin]: I disagree. just like two policies given in section 4 of RFC5761, one new policy we want

 to give in this draft is since the registry for RTP Payload types (PT) for standard audio and video

encodings  is closed, new payload format *MUST*   use dynamic payload type number assignment

and Each new payload format is named by a registered media subtype.

However RFC3551 section 3.1 only said,to register additional encoding, you may either assign each encoding
a short name, in some context, you refer to these encodings in the form of a MIME content-type, or assigns static
RTP payload type numbers, or assign with dynamic payload type number.

[Qin]: I see. However one thing I don't understand, RFC5761only proposes Multiplexing RTP Data and Control Packets on a Single Port,

Why two policies defined in RFC5761 can affect RFC3551 and proposed payload type usage can be used to update RFC3551.

[Qin]: Agree. I think section 3 of this draft for "update to RFC3551" can go away now.

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Sep 2013 03:04:08 +0000

Hi, Magnus:
I agree with your comments below and will remove section 3.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Tuesday, September 03, 2013 8:49 PM
To: Roni Even
Cc: 'Colin Perkins'; [email-masked]
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt

Hi,

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Thu, 5 Sep 2013 13:28:14 +0100

Qin,

On 5 Sep 2013, at 03:42, Qin Wu <[email-masked]> wrote:
> I don’t know it is sufficient to just send some proposed IANA changes to IANA.

If your goal is simply to correct the registry to match RFC 5761, then I don't believe you need a new document. Just email the IANA, and ask them to make the correction to match RFC 5761.

> For your comments, I do think we give a new policy for new payload format coming up, please see my reply below.
...
> [Qin]: I disagree. just like two policies given in section 4 of RFC5761, one new policy we want to give in this draft is since the registry for RTP Payload types (PT) for standard audio and video 
> encodings  is closed, new payload format *MUST*   use dynamic payload type number assignment and Each new payload format is named by a registered media subtype. 
>  
> However RFC3551 section 3.1 only said,to register additional encoding, you may either assign each encoding a short name, in some context, you refer to these encodings in the form of a MIME content-type, or assigns static RTP payload type numbers, or assign with dynamic payload type number.

I don't understand your message, but I do not believe there is a conflict between RFC 3551 and 5761.

> [Qin]: I see. However one thing I don’t understand, RFC5761only proposes Multiplexing RTP Data and Control Packets on a Single Port,

Because the payload type in RTP and RTCP packet occupies the same byte, but is 7 bits in RTP and 8 bits in RTCP. When multiplexing RTP and RTCP packets on the same port it is necessary to specify how to distinguish. That is the reason why RFC 5761 updates RFC 3551.

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

---

From: "Roni Even" <[email-masked]>
Date: Thu, 5 Sep 2013 16:11:34 +0300

Colin,
One other reason and it would be added is to say that when selecting which
pt numbers to use always assume that multiplexing of RTP/RTCP  is used.
Roni

> Sent: 05 September, 2013 3:28 PM
> To: Qin Wu
> If your goal is simply to correct the registry to match RFC 5761, then I
don't
> believe you need a new document. Just email the IANA, and ask them to
> make the correction to match RFC 5761.
> 
> > For your comments, I do think we give a new policy for new payload
format
> coming up, please see my reply below.
> ...
> > [Qin]: I disagree. just like two policies given in section 4 of RFC5761,
one
> new policy we want to give in this draft is since the registry for RTP
Payload
> types (PT) for standard audio and video
> > encodings  is closed, new payload format *MUST*   use dynamic payload
> type number assignment and Each new payload format is named by a
> registered media subtype.
> >
> > However RFC3551 section 3.1 only said,to register additional encoding,
you
> may either assign each encoding a short name, in some context, you refer
to
> these encodings in the form of a MIME content-type, or assigns static RTP
> payload type numbers, or assign with dynamic payload type number.
> 
> > [Qin]: I see. However one thing I don't understand, RFC5761only
> > proposes Multiplexing RTP Data and Control Packets on a Single Port, Why
> two policies defined in RFC5761 can affect RFC3551 and proposed payload
> type usage can be used to update RFC3551.
> 
> Because the payload type in RTP and RTCP packet occupies the same byte,
> but is 7 bits in RTP and 8 bits in RTCP. When multiplexing RTP and RTCP
> packets on the same port it is necessary to specify how to distinguish.
That is
> the reason why RFC 5761 updates RFC 3551.
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 5 Sep 2013 14:17:37 +0100

Why? You know whether RTP and RTCP are multiplexed or not.

Colin

On 5 Sep 2013, at 14:11, "Roni Even" <[email-masked]> wrote:
> Colin,
> One other reason and it would be added is to say that when selecting which pt numbers to use always assume that multiplexing of RTP/RTCP  is used.
> Roni
> 

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