Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4347)

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 04 April 2016 17:41 UTC

Return-Path: <magnus.westerlund@ericsson.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 405B912D14E for <avt@ietfa.amsl.com>; Mon, 4 Apr 2016 10:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 aFhIN3jb4yIg for <avt@ietfa.amsl.com>; Mon, 4 Apr 2016 10:41:43 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEE212D60F for <avt@ietf.org>; Mon, 4 Apr 2016 10:36:28 -0700 (PDT)
X-AuditID: c1b4fb3a-f79d86d000005b69-cb-5702a61ba63b
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.71.23401.B16A2075; Mon, 4 Apr 2016 19:36:27 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 19:36:26 +0200
To: <ben@nostrum.com>, <alissa@cooperw.in>, <keith.drage@alcatel-lucent.com>, <roni.even@mail01.huawei.com>
References: <20150427154444.78210180092@rfc-editor.org>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <5702A612.4090802@ericsson.com>
Date: Mon, 4 Apr 2016 14:36:18 -0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20150427154444.78210180092@rfc-editor.org>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7hK70MqZwg77tchbTz/xltHjZs5Ld Yn7naXaLp41nGS2etPxgtjj5ZQeLA5tH67O9rB5fnrxk8liy5CeTx47ND1g97t66xOQxa+cT lgC2KC6blNSczLLUIn27BK6Mq89XMxfsMak4Nf05UwPjXo0uRk4OCQETia6fDxkhbDGJC/fW s3UxcnEICRxhlDi/+j8jhLOMUWLK/wcsIFXCAuYS0xdtYQOxRQRyJXqPfwOzhYDil1+/Z+1i 5OBgFtCT6P5WChJmE7CQuPmjEayEV0BbYv+RV2BjWARUJFacW8QKYosKxEgcf3eOEaJGUOLk zCdgNZxAvT+ufGWHGGkv8WBrGUiYWUBeonnrbGaIrdoSDU0drBMYBWch6Z6F0DELSccCRuZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGhf3DLb6sdjAefOx5iFOBgVOLhXXCKMVyINbGs uDL3EKMEB7OSCO/5JUzhQrwpiZVVqUX58UWlOanFhxilOViUxHlzIv+FCQmkJ5akZqemFqQW wWSZODilGhiLFOPq8nt/sCvzqUz+lCL0Sb8y8vUj2xuyWw8zl/ILfL40v++3+YETV/qWt7DZ +b5lEDaSqIierB67c2mCwa2Z6m3HXD8LP5nk+C2OZW/a4gpBtYO324/lz/tst6LDyH71ln17 17euT1Dc6/7W55L0Y6vDBV6na9gTD7o86/ZiKA0TuCLw5IISS3FGoqEWc1FxIgD+7ReLeQIA AA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/9zO8w35yQgoXszvm6sEaHB8EeSg>
Cc: Thomas.Belling@nokia.com, avt@ietf.org
Subject: Re: [AVTCORE] [Technical Errata Reported] 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: Mon, 04 Apr 2016 17:41:45 -0000

WG,

I am co-author of this document. If there are any controversy around the 
consensus here I will let my co-chair or the AD judge that.

However, the WG should progress this Errata. It has been created due to 
actual interoperability issues that has been discussed in 3GPP SA4. From 
my perspective the errata also represents the intention of the document. 
Thus I propose that this errata is verified. Please provide any feedback 
by the 18th of April.

Cheers

Magnus Westerlund




Den 2015-04-27 kl. 12:44, skrev RFC Errata System:
> 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=4347
>
> --------------------------------------
> Type: Technical
> Reported by: Thomas Belling <Thomas.Belling@nokia.com>
>
> 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.
>
> 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
>
>


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------