Subject: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"

From: Chung Cheung Chu <[email-masked]>
Date: Fri, 9 Sep 2011 16:01:37 -0400

Background

Per "draft-ietf-avt-rtp-evrc-nw-03", an EVRC-NW wideband-capable system using interleaved/bundled format would transmit MMM=0 to request the other end to encode and transmit EVRC-NW wideband encoded traffic.  If both the near end and the far end of a call are capable of EVRC-NW wideband support, this mechanism will lead to the exchange of wideband traffic in both directions.

If the far end of a call is not capable of wideband encoding, the far end will only encode and transmit traffic in narrowband mode despite the near end's repeated requests for wideband traffic.   Per "draft-ietf-avt-rtp-evrc-nw-03.txt", the near end system will not know for certain of the far end's wideband encoding capability/incapability.  Should the near end system be aware of the far end's incapability of wideband encoding, the near end can update the MMM bit-field to request the preferred narrowband traffic meeting the near end's local requirements.  For example, the near end could request Mode4 narrowband traffic if the near end system prefers bandwidth conservation over better narrowband quality.  The near end could alternatively request Mode1 narrowband traffic if the near end system prefers better narrowband quality over bandwidth conservation.

The issue can manifest itself in another way where end-to-end wideband communication is established first but the far end becomes wideband encoding incapable during the call, due to RF change or hand-over for example.

Another potential issue is that in the event the near end wideband capable system switches the mode request value in MMM from Mode0 to non-Mode0 for narrowband traffic in the scenarios above,  the near end will not know if and when the far end would become wideband encoding capable again.  End-to-end wideband communication, if desired, may never be realized again for the rest of the call.

Proposal

In the EVRCNW interleaved/bundled format, define a dedicated bit-field to signal the instantaneous local EVRC-NW wideband encoding capability.  This instantaneous wideband encoding capability identifier is sent together with the MMM field in the payload of each EVRC-NW packet to the other end.

For example, this bit-field can be allocated out of the existing 2-bit reserved bit-field.   A value of 0 (default) indicates the sending system is capable of EVRC-NW wideband encoding.  A value of 1 indicates it is incapable of wideband encoding.

The instantaneous wideband encoding capability identifier in each incoming packet is interpreted by the local control logic to determine the appropriate MMM mode request to the far end for wideband or narrowband encoded traffic.  While the far end is not capable of wideband encoding, the near end will request with an explicit mode request the preferrerd narrowband encoding mode.  Otherwise the near end can request wideband encoded traffic.   The preferred encoding mode equested can match the far end's capability dynamically.

The suggested change is for media subtype EVRCNW payload format only.  It is not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats where the MMM mode request field is not supported.

Regards,

CC

Chung-Cheung Chu
Media Gateway DSP Design
BCAM - 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.