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

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:ron.even.tlv@gmail.com] 
Sent: Thursday, September 12, 2013 6:30 AM
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?

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

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: 12 September, 2013 9:05 AM
> To: Roni Even; '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 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