[AVTCORE] [Errata Verified] RFC4867 (4347)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 25 May 2016 22:04 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 15C5612DD0E; Wed, 25 May 2016 15:04:56 -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 jg49Yc1VqYkE; Wed, 25 May 2016 15:04:54 -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 A2F6512DDCD; Wed, 25 May 2016 15:04:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1A340180006; Wed, 25 May 2016 15:04:18 -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: <20160525220418.1A340180006@rfc-editor.org>
Date: Wed, 25 May 2016 15:04:18 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/9ZiBvmZL4SrnusRiNIpJK_r4BRw>
Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, avt@ietf.org
Subject: [AVTCORE] [Errata Verified] RFC4867 (4347)
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:04:56 -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=4347

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

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

Section: 4.3.1

Original Text
-------------
   CMR (4 bits): Indicates a codec mode request sent to the speech
      encoder at the site of the receiver of this payload.  The value of
      the CMR field is set to the frame type index of the corresponding
      speech mode being requested.  The frame type index may be 0-7 for
      AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined
      in Table 1a in [4].  CMR value 15 indicates that no mode request
      is present, and other values are for future use.

   The codec mode request received in the CMR field is valid until the
   next codec mode request is received, i.e., a newly received CMR value
   corresponding to a speech mode, or NO_DATA overrides the previously
   received CMR value corresponding to a speech mode or NO_DATA.
   Therefore, if a terminal continuously wishes to receive frames in the
   same mode X, it needs to set CMR=X for all its outbound payloads, and
   if a terminal has no preference in which mode to receive, it SHOULD
   set CMR=15 in all its outbound payloads.

   If receiving a payload with a CMR value that is not a speech mode or
   NO_DATA, the CMR MUST be ignored by the receiver.


Corrected Text
--------------
   CMR (4 bits): Indicates a codec mode request sent to the speech
      encoder at the site of the receiver of this payload.  The value of
      the CMR field is set to the frame type index of the corresponding
      speech mode being requested.  The frame type index may be 0-7 for
      AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined
      in Table 1a in [4].  CMR value 15 indicates that the receiver has
      no preference in which mode within the negotiated mode set to
      receive, and other values are for future use.

   The codec mode request received in the CMR field is valid until the
   next codec mode request is received, i.e., a newly received CMR value
   corresponding to a speech mode, or CMR=15 overrides the previously
   received CMR value corresponding to a speech mode or CMR=15.
   Therefore, if a terminal continuously wishes to receive frames not 
   higher than mode X, it needs to set CMR=X for all its outbound
   payloads, and if a terminal has no preference in which mode within 
   the negotiated mode set to receive, it SHOULD set CMR=15 in all its
   outbound payloads.

   If receiving a payload with a CMR value that is not a speech mode or
   CMR=15, the CMR MUST be ignored by the receiver.


Notes
-----
The definition of CMR 15 as "no mode request is present", could be understood to suggest that other previously received CMR values remain applicable. However, this contradicts text in the subsequent paragraphs suggesting CMR=15 should be used when the "terminal has no preference in which mode to receive", and stating that any previously received CMR value is overridden by CMR=15.

It is thus unclear for a receiving entity that has previously received a CMR value requesting a lower AMR mode and then receives a CMR value 15 if it should continue to send using the lower AMR mode or if it can select a higher mode within the negotiated mode set based on own preferences.

CMR 15 is referred to as "NO_DATA" in subsequent text, but "NO_DATA" is not well defined. This value appears in the quoted references, but these references are only quoted for CMR values 0 to 7/8.

It is also not perfectly clear if CMR=15 allows for any mode, or only modes within the negotiated mode set. However, the definition of the mode-set parameter in Clause 8.1 suggests that only modes within the negotiated mode-set can be sent when a mode-set has been negotiated.

The text "if a terminal continuously wishes to receive frames in the same mode X, it needs to set CMR=X for all its outbound payloads" seems to suggest that the receiver will always follow the request, although it may also choose to send lower modes, as explained in text further below.

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