Re: [payload] Comments to "draft-ietf-avt-rtp-evrc-nw-05"

"Fang, Zheng" <zfang@qualcomm.com> Wed, 22 February 2012 17:59 UTC

Return-Path: <zfang@qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3783821F883E for <payload@ietfa.amsl.com>; Wed, 22 Feb 2012 09:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.398
X-Spam-Level:
X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OEM_S_DOL=1.2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNxBixMU5y3c for <payload@ietfa.amsl.com>; Wed, 22 Feb 2012 09:58:54 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id B479B21F8833 for <payload@ietf.org>; Wed, 22 Feb 2012 09:58:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=zfang@qualcomm.com; q=dns/txt; s=qcdkim; t=1329933534; x=1361469534; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Fang,=20Zheng"=20<zfang@qualcomm.com>|To:=20Chu ng=20Cheung=20Chu=20<chung.cheung.chu@ericsson.com>,=20"p ayload@ietf.org"=0D=0A=09<payload@ietf.org>|Subject:=20RE :=20Comments=20to=20"draft-ietf-avt-rtp-evrc-nw-05" |Thread-Topic:=20Comments=20to=20"draft-ietf-avt-rtp-evrc -nw-05"|Thread-Index:=20Aczr8P6xhrNUyUn1ThSZWyOLVQQldQFmm j7Q|Date:=20Wed,=2022=20Feb=202012=2017:58:53=20+0000 |Message-ID:=20<E23CE350F3C94C4A834B4E7069CA56790D4D3EE4@ nasanexd01a.na.qualcomm.com>|References:=20<26490BBDEEACA 14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson .se>|In-Reply-To:=20<26490BBDEEACA14EA1A0070367B3ADBDBDDE 752422@EUSAACMS0702.eamcs.ericsson.se>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanex d01anaqu_"|MIME-Version:=201.0; bh=g3xcqZ2olBA5FSFBMFZTMOFynSlWo8fS03V4/5bYm8E=; b=w2bRE0Cw9riHjdc5P8hSc8ameIat1MoWLuW6zZvdnnVa9vVsdSwDuNBL okx8W5ETzd/L5WZI38xg5/XpPa1hYa53FMNcaAloetHuVCDjL/v86WVYc XWceqbHwepTQgxLhQfUXqybg7fwiyP6v5P73AYKCJmWJ3NTTz1h6LntrF M=;
X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="163072501"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 22 Feb 2012 09:58:53 -0800
X-IronPort-AV: E=Sophos; i="4.73,464,1325491200"; d="scan'208,217"; a="119400076"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Feb 2012 09:58:53 -0800
Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.165]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 09:58:53 -0800
From: "Fang, Zheng" <zfang@qualcomm.com>
To: Chung Cheung Chu <chung.cheung.chu@ericsson.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Comments to "draft-ietf-avt-rtp-evrc-nw-05"
Thread-Index: Aczr8P6xhrNUyUn1ThSZWyOLVQQldQFmmj7Q
Date: Wed, 22 Feb 2012 17:58:53 +0000
Message-ID: <E23CE350F3C94C4A834B4E7069CA56790D4D3EE4@nasanexd01a.na.qualcomm.com>
References: <26490BBDEEACA14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson.se>
In-Reply-To: <26490BBDEEACA14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.30.39.5]
Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanexd01anaqu_"
MIME-Version: 1.0
Subject: Re: [payload] Comments to "draft-ietf-avt-rtp-evrc-nw-05"
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 17:59:00 -0000

Hi Chung-Cheung,

Thank you for the proposal. These changes look good to me. I will incorporate these changes in the next version of this draft.

Thanks,
Zheng


From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com]
Sent: Wednesday, February 15, 2012 6:49 AM
To: payload@ietf.org; Fang, Zheng
Subject: Comments to "draft-ietf-avt-rtp-evrc-nw-05"


Background

"draft-ietf-avt-rtp-evrc-nw-05" for EVRC-NW codec payload format specification defines the SDP attribute "mode-set-recv" and the "MMM" mode change request field in the interleaved/bundled payload format for media type EVRCNW.  The attribute "mode-set-recv" presents a list of modes which could include mode-0 for wideband support and/or mode-1 through mode-7 for narrowband support.  A communication entity can send the SDP attribute "mode-set-recv" to inform its communication partner at the far end of the entity's preference of incoming traffic for the call session.  Absence of this parameter signals the preference of mode set {1,2,3,4,5,6,7} for narrowband incoming traffic only.  The "MMM" mode change request field in the interleaved/bundled payload format is a dynamic mechanism reflecting a specific incoming mode type preferred by a communication entity during a call session.

This contribution presents three change proposals to clarify the interpretations and usage of these two mode preference specification mechanisms.

Proposal 1

When a communication entity receives from the far end partner a mode change request indicating a preference for narrowband traffic, "draft-ietf-avt-rtp-evrc-nw-05" recommends the communication entity to operate its EVRC-NW encoder in narrowband mode and transmit narrowband traffic to the far end partner.  It is proposed that the draft mandates a communication entity to operate its EVRC-NW encoder in narrowband mode and transmit narrowband traffic to the far end partner in the event of receiving a MMM mode change request for narrowband traffic.

This change is necessary because the SDP attribute "mode-set-recv" may not be updated during a call session.  In an exemplary configuration, a mobile-mobile EVRC-NW wideband communication is established between System A and System B where the two systems sent mode-set-recv={0,1,2,3,4,5,6,7} to each other at call setup and MMM = 0 during the call.  System A is hard handovered to System C which supports EVRC-NW narrowband modes only.  System C does not send "mode-set-recv" to System B during the handover.  After handover, System C sends MMM with its value set to one of the narrowband modes to System B.  Upon receiving the MMM mode change request with narrowband decoding preference, System B must switch to operate in narrowband mode to transmit narrowband encoded traffic to System C.  Otherwise, System C's failure to decode wideband traffic will lead to communication failure.

Original text (section 10)

"A mode request with MMM=1, 2, ..., or 7 from a communication partner is an implicit indication of the partner's EVRCNW narrowband decoding preference.  The encoder of an EVRCNW node receiving the request should honor the request and operate in narrowband mode."

Modified text (section 10)

"A mode request with MMM=1, 2, ..., or 7 from a communication partner is an implicit indication of the partner's EVRC-NW narrowband decoding preference.  The encoder of an EVRC-NW node receiving the request shall honor the request and operate in narrowband mode."


Proposal 2

This proposal suggests editorial changes to further clarify the roles of the SDP attribute "mode-set-recv" and the "MMM" mode change request field to avoid potential mis-interpretation and mis-use of the two mechanisms and to ensure proper EVRC-NW decoding preference communication.

Original text (section 10)

Conversely, if mode 0 is not preferred, then there is no indication that mode 0 is supported.

Modified text (section 10)

Conversely, If mode 0 is not preferred for media type EVRCNW0 or EVRCNW1, then there is no indication that mode 0 is supported.  However absence of this parameter or absence of mode 0 in this parameter for media type EVRCNW shall not preclude mode 0 support during a call where mode 0 may be requested via the MMM field.



Original text (section 10)

Note, during an active call session using the interleaved/bundled packet format, the MMM mode request received from a communication partner complements the mode set information in mode-set-recv.  A mode request with MMM=0 from a communication partner is an implicit indication of the partner's EVRCNW wideband decoding capability and preference.

Modified text (section 10)

Note, during an active call session using the interleaved/bundled packet format, the MMM mode request received from a communication partner can contain a mode request different than the values in the last mode-set-recv attribute.  The partner's EVRC-NW wideband decoding capability is determined by the latest mode-set-recv attribute or MMM mode request field. For example, a complements the mode set information in mode-set-recv.  A mode request with MMM=0 from a communication partner is an implicit indication of the partner's EVRC-NW wideband decoding capability and preference.


Proposal 3


The MMM mode change request field in the interleaved/bundled payload format provides a means for an EVRC-NW receiver to specify the preferred wideband/narrowband operating mode types.  This facilitates the support of the EVRC-NW codec design principle to allow a trade-off between subjective quality performance and system capacity consideration.  This proposal suggests an addition of a section to the draft with a guideline for mode change request handling in consideration of the EVRC-NW codec design principle.  This guideline is recommended to ensure end-to-end call performance, for example when there is a mismatch between the local mode support capability/preference and the MMM mode change requests received from the far end.

Suggested new text

Mode Change Request/Response Considerations
The Interleaved/Bundled packet format for the EVRC family of vocoders supports a 3-bit field (MMM) that a communication node can use to indicate its preferred compression mode to an opposite node. The concept of the compression mode (also known as Capacity Operating Point) was introduced to allow a controlled trade-off between voice quality and channel capacity. The notion makes it possible to exercise vocoders at the highest possible (average) bit-rate (hence, highest voice quality) when the network is lightly loaded. Conversely, once the network load increases the vocoders can be requested to operate at lower average bit-rates so as to absorb the additional network load without causing an undue increase in the frame-erasure rates; the underlying premise is that while a higher bit-rate improves the vocoder performance, it also increases the network loading, risking a sharp decline in voice quality should the frame-erasure rate be too high. By contrast, a lower bit-rate mode of operation can result in accommodation of the additional network load without causing unduly high frame-erasure rates, resulting in better overall quality despite the inherently lower voice quality of the lower bit-rate mode of the vocoder.
Accordingly, the MMM field should be used to request the far-end to transmit compressed-speech using a mode that provides the best balance between voice quality and capacity. However, in the case of mobile-mobile calls, for example, there are two wireless sides involved, each with a potentially different network load level and hence a different preferred mode. In such cases, achieving optimal end-to-end performance depends on coherent management of the operative mode by the two sides. This requires that even if the local node prefers a higher bit-rate vocoder mode, it should adjust to a lower bit-rate mode if requested by the far end, in order to avoid potentially-high frame erasure rates due to heavy load at the far end network. For similar reasons, in cases where a mode requested by the far end should not be supported, it might still be beneficial to consider switching to a supported vocoder mode corresponding to a lower average bit-rate than requested. It is recommended that the next lower average bit-rate supported vocoder mode is used for encoding when a mode requested by the far end is not supported.
A wideband-capable endpoint can use the information conveyed by the C-bit of the RTP payload header to determine the optimal mode to request of the far end. If the far end cannot provide Mode0 packets (C-bit=1), then the choice of MMM can be based strictly on the local network load. If the C-bit indicates remote end's Mode0 encoding capability (C-bit=0), then even if the local network load is not light, Mode0 can be requested knowing definitively that it will be supported. This will permit operators to treat wideband-capable mobiles preferentially, should they wish to adopt such policy.


The three proposed changes above are for media type EVRCNW using interleaved/bundled payload format only.  They are not applicable to media type EVRCNW0 and EVRCNW1 payload formats where the MMM mode change request field is not supported.



Thanks,

CC

Chung-Cheung Chu
Ericsson
ECN:       810-16713
External: +514-461-6713   or   +514 345-7900 x46489

This Communication is Confidential.  We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer.