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

[Magnus Westerlund <[e-mail]>]

Payload,

I should have included you from start. Please provide any input on this 
Errata as its relate to an RTP Payload format.

Cheers

Magnus Westerlund
(AVTCORE WG chair)

Den 2016-04-04 kl. 14:36, skrev Magnus Westerlund:
> 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 <[e-mail]>
>>
>> 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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------