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

"Roni Even" <ron.even.tlv@gmail.com> Wed, 11 September 2013 20:43 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37B521E80C6 for <avt@ietfa.amsl.com>; Wed, 11 Sep 2013 13:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qognWLhppBCB for <avt@ietfa.amsl.com>; Wed, 11 Sep 2013 13:43:35 -0700 (PDT)
Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7415121E80BF for <avt@ietf.org>; Wed, 11 Sep 2013 13:43:34 -0700 (PDT)
Received: by mail-ee0-f47.google.com with SMTP id d49so4850965eek.6 for <avt@ietf.org>; Wed, 11 Sep 2013 13:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=xDFMRKE9d/W/Pols5u3GiW5pNEM5vMzwkNbtXpbO3xE=; b=W89gDj2B4J272+U72wng5MHzfQ/ADR7+m0kuGPPkkMxK6HOeMsNLjwKDfNM7oqZv1H ETKbRCZIDk0GdMcTHCp79odBZIDE4wMsldNx7GTtHIhxSLAERIw8SHG+4q6N3eDKYBT6 XyXJMs/zpodAazNfa6CXHzaGMkvcwNt9lBOJw9UInpGx04F/PExV3sufC73CseSgWEIH A7VdiuKMXsc+4qQF8Qciz8KP8koboIC+DV5qmBUK50HEfIIrvXls4k+vhOBzkjc5E9Rb M4I26wF6r7B0cuqv841xX9Lv2TJ6UOSk3pQDYxSrB8+SfkufZBx4SX55TfMwxZxM6aPa 2SNA==
X-Received: by 10.15.102.71 with SMTP id bq47mr5114752eeb.66.1378932213531; Wed, 11 Sep 2013 13:43:33 -0700 (PDT)
Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id m54sm43518421eex.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Sep 2013 13:43:32 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Mo Zanaty \(mzanaty\)'" <mzanaty@cisco.com>, "'DRAGE, Keith \(Keith\)'" <keith.drage@alcatel-lucent.com>, "'Colin Perkins'" <csp@csperkins.org>, "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>, "'Dale R. Worley'" <worley@ariadne.com>
References: <201309101932.r8AJWOBj916357@shell01.TheWorld.com> <026301ceae62$8ff6d770$afe48650$@gmail.com> <523008E0.7050209@ericsson.com> <8357B75E-44D2-4C34-82BA-350447AEB48E@csperkins.org> <949EF20990823C4C85C18D59AA11AD8B0A2BFA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <3879D71E758A7E4AA99A35DD8D41D3D91D528CDD@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D528CDD@xmb-rcd-x14.cisco.com>
Date: Wed, 11 Sep 2013 23:40:46 +0300
Message-ID: <00a501ceaf2f$332e0220$998a0660$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIvIRJJEjptctUNL7cAbcvxymJj+wFftrf/AORDpBoCQHrF+QIP4lL6AbrzoreYvZ/V8A==
Content-Language: en-us
Cc: avt@ietf.org
Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2013 20:43:36 -0000

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