[AVTCORE] [Errata Verified] RFC4867 (4349)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 25 May 2016 22:09 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 4FC4E12DDF4; Wed, 25 May 2016 15:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.328
X-Spam-Level:
X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph3pv5cWdCbU; Wed, 25 May 2016 15:09:11 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A424512DDF8; Wed, 25 May 2016 15:08:39 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 110B7180006; Wed, 25 May 2016 15:08:04 -0700 (PDT)
To: Thomas.Belling@nokia.com, Johan.Sjoberg@ericsson.com, Magnus.Westerlund@ericsson.com, ari.lakaniemi@nokia.com, Qiaobing.Xie@motorola.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160525220804.110B7180006@rfc-editor.org>
Date: Wed, 25 May 2016 15:08:04 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/FpI__4kphlhjAYItdsx0y8UZjKE>
Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, avt@ietf.org
Subject: [AVTCORE] [Errata Verified] RFC4867 (4349)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 25 May 2016 22:09:12 -0000

The following errata report has been verified for RFC4867,
"RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4349

--------------------------------------
Status: Verified
Type: Technical

Reported by: Thomas Belling <Thomas.Belling@nokia.com>
Date Reported: 2015-04-27
Verified by: Ben Campbell (IESG)

Section: 8.1

Original Text
-------------
      mode-set: Restricts the active codec mode set to a subset of all
               modes, for example, to be able to support transport
               channels such as GSM networks in gateway use cases.
               Possible values are a comma separated list of modes from
               the set: 0,...,7 (see Table 1a [2]).  The SID frame type
               8 and NO_DATA (frame type 15) are never included in the
               mode set, but can always be used.  If mode-set is
               specified, it MUST be abided, and frames encoded with
               modes outside of the subset MUST NOT be sent in any RTP
               payload or used in codec mode requests.  If not present,
               all codec modes are allowed for the payload type.


Corrected Text
--------------
      mode-set: Restricts the active codec mode set to a subset of all
               modes, for example, to be able to support transport
               channels such as GSM networks in gateway use cases.
               Possible values are a comma separated list of modes from
               the set: 0,...,7 (see Table 1a [2]).  The SID frame type
               8 and NO_DATA (frame type 15) are never included in the
               mode set, but can always be used.  If mode-set is
               specified, it MUST be abided, i.e. frames encoded with
               modes outside of the subset MUST NOT be sent in any RTP
               payload and codec mode requests MUST only use modes
               within the mode-set or CMR=15. If the mode-set parameter
               is not present, then all codec modes are allowed for the
               payload type.


Notes
-----
The existing text rules out that CMR=15 is used when a mode-set has been negotiated. However, this contradicts a statement in .clause 4.3.1 that if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads.

This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF.

--------------------------------------
RFC4867 (draft-ietf-avt-rtp-amr-bis-06)
--------------------------------------
Title               : RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
Publication Date    : April 2007
Author(s)           : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG