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

From: [email-masked] (Dale R. Worley)
Date: Tue, 10 Sep 2013 15:32:24 -0400 (EDT)

Back in April, there was a discussion on the Mmusic mailing list
regarding updating the IANA registry for RTP payload types.
Primarily, this involves recording RFC 5761 as the primary defining
document, and updating the table of payload type ranges to match the
usages assigned by RFC 5761.  The proposal (as revised during the
discussion) is:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg10809.html

    1) The "Reference" section should be changed from "[RFC3551]" to
    "[RFC5761][RFC3551]".

    2) The final rows should be changed to

	35-63   Unassigned/secondary dynamic area       [RFC5761]
	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]

The discussion is (currently) indexed at
http://www.ietf.org/mail-archive/web/mmusic/current/thrd3.html,
starting at "Should we update the IANA registry to reflect RFC 5761?".
Eight people participated in the discussion (not counting myself).  It
appeared to me that there was agreement from all parties that it would
be beneficial to update the registry as proposed.  (Disagreement
concerned whether further information should be added to the registry
describing further payload types that could be used in situations
where confusion with RTCP was not a concern.)

At the Berlin IETF, the Avtcore chairs presented this slide:

    http://www.ietf.org/proceedings/87/slides/slides-87-mmusic-7.pdf
    page 13

    RTP Payload Types Registry

    Result of discussion on MMUSIC list:

    * The "Reference" section should be changed from "[RFC3551]" to
      "[RFC5761][RFC3551]".
      - RFC5761: Multiplexing RTP Data and Control Packets on a Single
      Port
      - RFC3551: RTP Profile for Audio and Video Conferences

    * The final rows should be changed to
        35-63 Unassigned/secondary dynamic area [RFC5761]
        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]

    * To be reviewed by AVTCORE

Consequently, I'd like to start the discussion of whether the registry
should be updated to mention RFC 5761.

Dale

---

From: "Roni Even" <[email-masked]>
Date: Tue, 10 Sep 2013 23:15:55 +0300

Hi Dale,
We started working in it see
http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-usage-01 
Please review
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dale R. Worley
> Sent: 10 September, 2013 10:32 PM
> To: [email-masked]
> Subject: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?
> 
> Back in April, there was a discussion on the Mmusic mailing list regarding
> updating the IANA registry for RTP payload types.
document,
> and updating the table of payload type ranges to match the usages assigned
> by RFC 5761.  The proposal (as revised during the
> discussion) is:
> 
> The discussion is (currently) indexed at http://www.ietf.org/mail-
> archive/web/mmusic/current/thrd3.html,
appeared
> to me that there was agreement from all parties that it would be
beneficial to
> update the registry as proposed.  (Disagreement concerned whether further
> information should be added to the registry describing further payload
types
> that could be used in situations where confusion with RTCP was not a
> concern.)
> 
should
> be updated to mention RFC 5761.
> 
> Dale
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Sep 2013 08:08:32 +0200

> http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-usage-01 

Roni, as WG chair I think you need to be a bit more clear in your
statement. You and your co-author has an individual proposal that the WG
should write and publish an RFC make the situation clearer.

I think the WG has choices in three main directions:

1) Do nothing
2) Update the registry
3) Write some type of RFC to provide further clarifications, possibly
updating any of the existing RFCs that defines current behavior.

As a chair I do like to get the WG participants view on which of these
directions you think is appropriate. Please do motivate why you think so.

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: "Roni Even" <[email-masked]>
Date: Wed, 11 Sep 2013 10:11:57 +0300

Hi,
Just to clarify, my response was as an individual which I should have stated
(not as WG chair)

I agree with Magnus list of choices and think that based on the MMUSIC
discussion option 1 is not relevant.

As for the other options I prefer the third option. Even though it repeats
text from RFC3551 and RFC5761 it also request to update the IANA registry.
It also makes recommendation about which pt numbers can be used for dynamic
mapping.

The update for the IANA registry was triggered by Dale's email thread.

I think it will be good to have also the pt number usage guidelines, this is
triggered by the open issue in section 3.2.1.2 of
http://tools.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt . 

The authors of draft-wu-avtcore-dynamic-pt-usage-01 are looking for feedback
from the WG at which direction to take and if there is support for having
such guidelines

Roni Even
As individual

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: 11 September, 2013 9:09 AM
> To: Roni Even
> Cc: 'Dale R. Worley'; [email-masked]
> Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC
> 5761?
> 
> 
statement.
> You and your co-author has an individual proposal that the WG should write
> and publish an RFC make the situation clearer.
> 
updating
> any of the existing RFCs that defines current behavior.
> 
> >> and updating the table of payload type ranges to match the usages
> >> assigned by RFC 5761.  The proposal (as revised during the
> >> discussion) is:
> >>
> >> update the registry as proposed.  (Disagreement concerned whether
> >> further information should be added to the registry describing
> >> further payload
> > types
> >> Audio/Video Transport Core Maintenance [email-masked]
> > Audio/Video Transport Core Maintenance [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 11 Sep 2013 12:01:08 +0100

On 11 Sep 2013, at 07:08, Magnus Westerlund <[email-masked]> wrote:
> statement. You and your co-author has an individual proposal that the WG should write and publish an RFC make the situation clearer.
> 

I think the working group chairs should ask IANA to fix the registry. It is clearly an oversight that the IANA considerations of RFC 5761 didn't ask IANA to make the changes at the time, and that RFC is very clear what payload types need to be reserved, so I'd expect IANA to be willing to do this without needing an additional RFC.

If not, I'm happy to file an errata statement on the IANA considerations of RFC 5761.

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Sep 2013 12:18:07 +0000

At the time this was first discussed, there was a need to record things in the IANA registry that were not there. So yes, an update to the IANA registry is required, and that is not necessarily depending on progressing an RFC.

However, part of the proposal originally made were to express things in the IANA registry that were clearly not just a registration action for a codepoint. It is those aspects, if they are still required, that need an RFC.

I'd have to go back to the original mails to work out what those were, but put simply, if the action involves anything more than documenting a codepoint based on information in an existing RFC, then it needs a new RFC to cover it.

Regards

Keith

> Sent: 11 September 2013 12:01
> To: Magnus Westerlund
> Cc: [email-masked]
> I think the working group chairs should ask IANA to fix the registry. It
> is clearly an oversight that the IANA considerations of RFC 5761 didn't
> ask IANA to make the changes at the time, and that RFC is very clear what
> payload types need to be reserved, so I'd expect IANA to be willing to do
> this without needing an additional RFC.
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 11 Sep 2013 18:30:47 +0000

RFC 5761 already has all bases covered in very clear text.
So I think the only thing needed is to update the registry.
The "Reference" should be "[RFC5761][RFC3551]", as Dale suggested.
The final rows should be updated as follows, almost as Dale suggested.

OLD:
35-71 Unassigned
77-95 Unassigned
96-127 dynamic [RFC3551]

NEW:
35-63 Unassigned
64-95 Reserved for RTCP conflict avoidance [RFC5761][RFC3551]
96-127 dynamic [RFC5761][RFC3551]

This differs from the draft below, and slightly from what Dale suggested.
The draft allows 64-65 as dynamic, contrary to RFC5761, which is bad.
While 64-65 are historic, they are actually in use, even in the webrtc code!

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Wednesday, September 11, 2013 8:18 AM
To: Colin Perkins; Magnus Westerlund
Cc: [email-masked]
Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?

Regards

Keith

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 Sep 2013 23:40:46 +0300

Hi Mo,
Are you saying the webrtc code support old historical H.261 messages (in a
compliant interoperable way!!!) which are not relevant to any of the new
video codec (H.264 or VP8) . It is better to force it to change to using CCM
RFC 5104 and for H.261 use RFC4587

This is the text from RFC 4587 explaining why they can be deprecated.

Optional H.261-Specific Control Packets

   RFC 2032 defined two H.261-specific RTCP control packets, "Full
   INTRA-frame Request" and "Negative Acknowledgement".  Support of
   these control packets was optional.  The H.261-specific control
   packets differ from normal RTCP packets in that they are not
   transmitted to the normal RTCP destination transport address for the
   RTP session (which is often a multicast address).  Instead, these
   control packets are sent directly via unicast from the decoder to the
   encoder.  The destination port for these control packets is the same
   port that the encoder uses as a source port for transmitting RTP
   (data) packets.  Therefore, these packets may be considered "reverse"
   control packets.  This memo suggests generic methods to address the
   same requirement.  The authors of the documents are not aware of
   products that support these control packets.  Since these are
   optional features, new implementations SHALL ignore them, and they
   SHALL NOT be used by new implementations.
Roni

> From: Mo Zanaty (mzanaty) [mailto:[email-masked]]
> Sent: 11 September, 2013 9:31 PM
> To: DRAGE, Keith (Keith); Colin Perkins; Magnus Westerlund; Roni Even
> ([email-masked]); Dale R. Worley ([email-masked])
> Cc: [email-masked]
> Subject: RE: [AVTCORE] Should we update the IANA registry to reflect RFC
> 5761?
> 
> DRAGE, Keith (Keith)
> At the time this was first discussed, there was a need to record things in
the
> IANA registry that were not there. So yes, an update to the IANA registry
is
> required, and that is not necessarily depending on progressing an RFC.
> 
> However, part of the proposal originally made were to express things in
the
> IANA registry that were clearly not just a registration action for a
codepoint.
> It is those aspects, if they are still required, that need an RFC.
> 
> I'd have to go back to the original mails to work out what those were, but
put
> simply, if the action involves anything more than documenting a codepoint
> based on information in an existing RFC, then it needs a new RFC to cover
it.
> > > 3) Write some type of RFC to provide further clarifications,
> > > possibly updating any of the existing RFCs that defines current
behavior.
> > >
> > > As a chair I do like to get the WG participants view on which of
> > > these directions you think is appropriate. Please do motivate why you
> think so.
> >
> >
> > I think the working group chairs should ask IANA to fix the registry.
> > It is clearly an oversight that the IANA considerations of RFC 5761
> > didn't ask IANA to make the changes at the time, and that RFC is very
> > clear what payload types need to be reserved, so I'd expect IANA to be
> > willing to do this without needing an additional RFC.
> >

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Sep 2013 06:05:07 +0000

Hi Roni,

The webrtc RTP code is based on GIPS, which historically implemented FIR via RFC 2032 even for new codecs like H.264. Even if webrtc fixes this, products which used GIPS may still be using this. So I think it is safer to avoid 64-65 per RFC 5761 (which notes that they are obsoleted by RFC 4587, but still says to avoid them).

I like Colin's offer to file an errata statement on the IANA considerations in RFC 5761 to handle this. I think we should take him up on it and avoid some milestones. :)

Cheers,
Mo

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2013 4:41 PM
To: Mo Zanaty (mzanaty); 'DRAGE, Keith (Keith)'; 'Colin Perkins'; 'Magnus Westerlund'; 'Dale R. Worley'
Cc: [email-masked]
Subject: RE: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?

Hi Mo,

the
is
the
codepoint.
put
it.
behavior.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Sep 2013 13:30:04 +0300

Mo,
This usage of FIR based on RFC2032 for H.264 is not standard and should not
be a problem of the IETF!!!!!
Roni

> Sent: 12 September, 2013 9:05 AM
> To: Roni Even; 'DRAGE, Keith (Keith)'; 'Colin Perkins'; 'Magnus
Westerlund';
> 'Dale R. Worley'
> The webrtc RTP code is based on GIPS, which historically implemented FIR
via
> RFC 2032 even for new codecs like H.264. Even if webrtc fixes this,
products
> which used GIPS may still be using this. So I think it is safer to avoid
64-65 per
> RFC 5761 (which notes that they are obsoleted by RFC 4587, but still says
to
> avoid them).
> 
> I like Colin's offer to file an errata statement on the IANA
considerations in
> RFC 5761 to handle this. I think we should take him up on it and avoid
some
> milestones. :)
> video codec (H.264 or VP8) . It is better to force it to change to using
CCM RFC
> 5104 and for H.261 use RFC4587
> 
> > simply, if the action involves anything more than documenting a
> > codepoint based on information in an existing RFC, then it needs a new
> > RFC to cover
> it.
> >
> > Regards
> >
> > Keith
> >
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> > > Of Colin Perkins
> > > didn't ask IANA to make the changes at the time, and that RFC is
> > > very clear what payload types need to be reserved, so I'd expect
> > > IANA to be willing to do this without needing an additional RFC.
> > >

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Sep 2013 16:17:08 +0000

Hi Roni,

I completely agree it is not standard and should be fixed.
But I also agree with RFC 5761 that 64-95 should be avoided.

Mo

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 6:30 AM
To: Mo Zanaty (mzanaty); 'DRAGE, Keith (Keith)'; 'Colin Perkins'; 'Magnus Westerlund'; 'Dale R. Worley'
Cc: [email-masked]
Subject: RE: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?

Mo,

Westerlund';
via
products
64-65 per
to
considerations in
some
CCM RFC

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Sep 2013 20:54:09 +0300

Hi,
The question is what to do if you run out of pt numbers. I think that we
need to specify some order. First of all this range can be usd if not
multiplexing RTP and RTCP. If you does then some can be used if we define
some priority.
I would think that the ones not used may be used, and 64-65 also. I think
this should be done before mapping to pt numbers used for static mapping
that are not used in the applications mostly because some will used at the
static payload type number and not at the RTPMAP
Roni

> Sent: 12 September, 2013 7:17 PM
Westerlund';
> > Are you saying the webrtc code support old historical H.261 messages
> > (in a compliant interoperable way!!!) which are not relevant to any of
> > the new video codec (H.264 or VP8) . It is better to force it to
> > change to using
> CCM RFC
> > > To: DRAGE, Keith (Keith); Colin Perkins; Magnus Westerlund; Roni
> > > Even ([email-masked]); Dale R. Worley ([email-masked])
> > > Cc: [email-masked]
> > > While 64-65 are historic, they are actually in use, even in the
> > > webrtc
> > code!
> > >
> > > Mo
> > >
> > >
> > > Of DRAGE, Keith (Keith)
> > > codepoint based on information in an existing RFC, then it needs a
> > > new RFC to cover
> > it.
> > >
> > > Regards
> > >
> > > Keith
> > >
> > > > > Roni, as WG chair I think you need to be a bit more clear in
> > > > > your statement. You and your co-author has an individual
> > > > > proposal that the WG
> > > > It is clearly an oversight that the IANA considerations of RFC
> > > > 5761 didn't ask IANA to make the changes at the time, and that RFC
> > > > is very clear what payload types need to be reserved, so I'd
> > > > expect IANA to be willing to do this without needing an additional
RFC.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 12 Sep 2013 14:04:35 -0400 (EDT)

> From: "Roni Even" <[email-masked]>
> 

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

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Sep 2013 18:22:34 +0000

Hi Dale,
I think RFC 5761 already addresses your points below, clearly and concisely.
http://tools.ietf.org/html/rfc5761#section-4

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Thursday, September 12, 2013 2:05 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?

Dale