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

"Roni Even" <ron.even.tlv@gmail.com> Thu, 12 September 2013 17:57 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 0871A11E81E2 for <avt@ietfa.amsl.com>; Thu, 12 Sep 2013 10:57:05 -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 FnFnRk8v5y6d for <avt@ietfa.amsl.com>; Thu, 12 Sep 2013 10:57:04 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B4EE121E8117 for <avt@ietf.org>; Thu, 12 Sep 2013 10:56:58 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id b13so144113wgh.11 for <avt@ietf.org>; Thu, 12 Sep 2013 10:56:57 -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=ZzCNHH7UX2bW1uny4G/rymiHQLJ5itYykPBtaqVeQbY=; b=L5x3z999UCBpqv1vbnLsgnll8odYc+f1QfHy1Uz9nC+8dutH14wzPnS6cRkMBanrXX MGzAVl1YV6lEz2GtqXLj0ff3xyAzgRssV6DtKrUv8c2wZcktsyQFienwzZDi4/dr5P/X nUz336ZMrtzJYhLldEczJnzg9ZFV9YOpga8/k8k+xXldtHjhUFZqFuR19KQAJ/qBv2tz ypLVZ9epjvSIFbfhxNMpxxd/gWaOeSk+Z5GNCZiI3xDpvAeH3enBB+B7GXO0MoB50ZNY FCbpHr+b8nLx02UsRug1/CM1uKPmmsIQUGZOUYfOkE/Eu1yPyyk1ohBeCgRw5mb/HXbq 831A==
X-Received: by 10.180.109.132 with SMTP id hs4mr19072693wib.46.1379008617798; Thu, 12 Sep 2013 10:56:57 -0700 (PDT)
Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id fz8sm19415835wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Sep 2013 10:56:57 -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> <00a501ceaf2f$332e0220$998a0660$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D91D53507F@xmb-rcd-x14.cisco.com> <010b01ceafa3$0d3e2670$27ba7350$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D91D53634F@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D53634F@xmb-rcd-x14.cisco.com>
Date: Thu, 12 Sep 2013 20:54:09 +0300
Message-ID: <015501ceafe1$174e4170$45eac450$@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+QIP4lL6AbrzorcCDGyGyAKN3EiFAe0YubABKSRSopiBgIZg
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: Thu, 12 Sep 2013 17:57:08 -0000

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

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: 12 September, 2013 7:17 PM
> 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,
> 
> 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