[AVTCORE] [Technical Errata Reported] RFC4867 (4349)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 27 April 2015 15:58 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED31A88D3 for <avt@ietfa.amsl.com>; Mon, 27 Apr 2015 08:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level:
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
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 T6Yzn1Lqsd5s for <avt@ietfa.amsl.com>; Mon, 27 Apr 2015 08:58:05 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61D1A88CF for <avt@ietf.org>; Mon, 27 Apr 2015 08:58:05 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 23479180092; Mon, 27 Apr 2015 08:57:09 -0700 (PDT)
To: Johan.Sjoberg@ericsson.com, Magnus.Westerlund@ericsson.com, ari.lakaniemi@nokia.com, Qiaobing.Xie@motorola.com, ben@nostrum.com, alissa@cooperw.in, keith.drage@alcatel-lucent.com, roni.even@mail01.huawei.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20150427155709.23479180092@rfc-editor.org>
Date: Mon, 27 Apr 2015 08:57:09 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/5pf1HvjAlEguo48fOXNFoeml7LM>
X-Mailman-Approved-At: Tue, 28 Apr 2015 10:50:02 -0700
Cc: Thomas.Belling@nokia.com, avt@ietf.org, rfc-editor@rfc-editor.org
Subject: [AVTCORE] [Technical Errata Reported] RFC4867 (4349)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 27 Apr 2015 15:58:07 -0000

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Thomas Belling <Thomas.Belling@nokia.com>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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