[payload] Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02"

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

Background

Draft "draft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and corresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.S0014-D].  EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2.  This codec supports a total of 8 modes of operation for narrowband and wideband voice band traffic compression.  Mode-0 is for wideband compression.  Mode-1 to mode-7 are for narrowband compression where mode-4 is defined as the default mode.  The average encoding rate for narrowband operation is decreased with increasing operating mode from mode-1 to mode-7.

Three media subtype payload formats are defined in this draft.  They are EVRCNW, EVRCNW0 and EVRCNW1.  This email concerns with operations associated with the media subtype EVRCNW payload format definition.

Media subtype EVRCNW payload format is defined with a payload header which consists of a 3-bit mode request field "MMM" and other payload related parameters [Ref. RFC3558].  Per MMM definition by RFC3558, EVRCNW traffic receiver uses this field to request an EVRCNW encoding mode to be used by the EVRCNW traffic generator for new traffic in the reverse path.

Draft "draft-ietf-avt-rtp-evrc-nw-02" adopts two optional SDP attributes "mode-set-recv" and "sendmode" from RFC5188.  Attribute "mode-set-recv" is used to indicate the preferred mode of bearer traffic supported by an EVRCNW receiver.  This attribute can assume a set of values 0, 1, ..., 7 denoting mode-0, mode-1, ..., mode-7 support, respectively.  Attribute "sendmode" is used to announce the current EVRCNW encoding mode by an EVRCNW encoder.

The draft states that in absence of mode-0 specification in "mode-set-recv" or in absence of the attribute, an EVRCNW encoder at the other side can only operate in narrowband mode.  In absence of attribute "sendmode", the encoding mode is mode-4.


Proposal

It is understood that an EVRCNW encoder cannot autonomously generate and send EVRC-NW mode-0 (wideband) traffic to the partner in absence of the partner's mode-0 (wideband) decoding capability.  However, a user capable of decoding mode-0 (wideband) traffic should be allowed to request for mode-0 (wideband) traffic from the partner using the MMM field in the RTP RFC header.  Such an in-band request is an implicit indication of mode-0 (wideband) decoding capability of the originator.  Upon receiving the mode-0 (wideband) request, a mode-0 (wideband) capable partner should be allowed to generate and send EVRC-NW wideband encoded traffic to the request originator, regardless of the SDP attribute "mode-set-recv".  A partner not capable of wideband encoding can ignore the request and should use a narrowband mode.

An example where the MMM mode change request field facilitates narrowband-to-wideband and wideband-to-narrowband operation switching is as follows:

An EVRCNW transcoding free (TrFO) call is established in a session between mobile-A in a circuit switched network and mobile-B in a 4G network via a communication node in the core network, such as a media gateway.   In this example, mobile-A supports EVRCNW without wideband compression capability, and mobile-B supports EVRCNW with wideband compression capability.  The media gateway sends at call setup time SDP mode-set-recv attribute to mobile-B specifying only narrowband mode support in light of mobile-A EVRCNW wideband incapability.  During the call, a call transfer (or call waiting) takes place replacing mobile-A with an EVRCNW wideband capable device, mobile-C.  In this example, the media gateway does not update the optional SDP mode-set-recv attribute on the stationary side to mobile-B.

In this scenario, EVRCNW wideband operation is allowed between mobile-C and the media gateway but not feasible between the media gateway and mobile-B according to the mode-set-recv definition in the current draft.  This could result in end-to-end EVRCNW operation in narrowband mode only.  If MMM mode change requests for mode-0 traffic relayed from mobile-C is allowed and supported by mobile-B, end-to-end EVRCNW transcoding free operation would be re-established in wideband mode.

Conversely, when the wideband support capability is terminated during an active call session, for example due to a call transfer (or call waiting) back from mobile-C to mobile-A, mode change requests relayed from mobile-A for narrowband operation should be considered as a preference indication that narrowband traffic is desired by the originator.  Mobile-B should honor the request and return narrowband compressed traffic.  This is required even if the mode-set-recv SDP attribute from the media gateway to mobile-B includes mode-0 support.



It is proposed that the following texts for media subtype EVRCNW SDP attributes "mode-set-recv" and "sendmode" be clarified:


Original text: Section 9.1.1
mode-set-recv: A subset of EVRC-NW modes.  Possible values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes.  Absence of this parameter signals the mode set {1,2,3,4,5,6,7}.

Suggested text: Section 9.1.1
mode-set-recv: A subset of EVRC-NW modes.  Possible values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes.  Absence of this parameter signals the mode set {1,2,3,4,5,6,7}.

During an active call session, 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.  An EVRCNW wideband capable node receiving the request can operate in wideband mode.  A mode request with MMM=1, 2, ..., or 7 from a communication partner is an implicit indication of the partner's EVRCNW narrowband decoding capability and preference.  An EVRCNW node receiving the request should honor the request and operate in narrowband mode.



Original text: Section 10
   1.  To inform the capability of wideband mode support: A decoder can always decode all the narrowband modes (modes 1 to 7).  Unless the decoder indicates the support of mode 0 (i.e., preference) in this parameter, an encoder at the other side shall not operate in mode 0.

Suggested text: Section 10
   1.  To inform the capability of wideband mode support: A decoder can always decode all the narrowband modes (modes 1 to 7).  Unless the decoder indicates the support of mode 0 (i.e., preference) in this parameter and in the MMM mode request field in media subtype EVRCNW payload format, an encoder at the other side shall not operate in mode 0.



Original text: Section 9.1.1
   sendmode: A mode of the EVRC-NW codec.  An encoder can use this to signal its current mode of operation.  Possible values are 0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  Absence of this parameter signals mode 4.

Suggested text: Section 9.1.1
   sendmode: A mode of the EVRC-NW codec.  An encoder can use this to signal its current mode of operation.  Possible values are 0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  Absence of this parameter signals mode 4.
   It is not necessary to send this optional SDP attribute when an EVRCNW encoder updates its encoding mode during an active call session such as in response to requests in the MMM mode request field from the other side. Conversely, absence of this SDP attribute should not be interpreted as an indication the encoder operates only in default mode-4.


The suggested changes are for media subtype EVRCNW payload format only.  They are 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
[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.