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

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:ron.even.tlv@gmail.com] 
Sent: Wednesday, September 11, 2013 4:41 PM
To: Mo Zanaty (mzanaty); 'DRAGE, Keith (Keith)'; 'Colin Perkins'; 'Magnus Westerlund'; 'Dale R. Worley'
Cc: avt@ietf.org
Subject: RE: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?

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

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: 11 September, 2013 9:31 PM
> To: DRAGE, Keith (Keith); Colin Perkins; Magnus Westerlund; Roni Even
> (ron.even.tlv@gmail.com); Dale R. Worley (worley@ariadne.com)
> Cc: avt@ietf.org
> Subject: RE: [AVTCORE] Should we update the IANA registry to reflect RFC
> 5761?
> 
> 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
> 72-76 Reserved for RTCP conflict avoidance [RFC3551]
> 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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Wednesday, September 11, 2013 8:18 AM
> To: Colin Perkins; Magnus Westerlund
> Cc: avt@ietf.org
> Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC
> 5761?
> 
> 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
> 
> > -----Original Message-----
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> > Colin Perkins
> > Sent: 11 September 2013 12:01
> > To: Magnus Westerlund
> > Cc: avt@ietf.org
> > Subject: Re: [AVTCORE] Should we update the IANA registry to reflect
> > RFC 5761?
> >
> > On 11 Sep 2013, at 07:08, Magnus Westerlund
> > <magnus.westerlund@ericsson.com> wrote:
> > > On 2013-09-10 22:15, Roni Even wrote:
> > >> Hi Dale,
> > >> We started working in it see
> > >> http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-usage-01
> > >> Please review
> > >> Roni Even
> > >
> > > 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.
> >
> >
> > 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/
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt