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

[Chung Cheung Chu <[e-mail]>]

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: [phone]   or   [phone] 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.