Re: [payload] Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02"

["Fang, Zheng" <[e-mail]>]

Hi Chung Cheung,

Thanks for the comments.  I agree with the clarification you proposed.  I will adopt these changes into the next revision.

Best Regards,
Zheng

From: Chung Cheung Chu [mailto:[e-mail]]
Sent: Thursday, March 31, 2011 7:20 AM
To: [e-mail]; Fang, Zheng
Subject: Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02"


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 in 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.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      RTP Header [4]                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |R|R| LLL | NNN | MMM |  Count  |  TOC  |  ...  |  TOC  |padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        one or more codec data frames, one per TOC entry       |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Per draft "draft-ietf-avt-rtp-evrc-nw-02", EVRCNW operates in narrowband mode-4 by default.  EVRCNW encoder operates in wideband mode only when an EVRCNW encoder receives indication of the EVRCNW wideband decoding capability and preference from the other side.   The draft adopts an optional SDP attribute "mode-set-recv" to indicate EVRCNW wideband decoding capability and preference.  The indication of EVRCNW wideband decoding capability and preference can also be communicated to the other side via the mode request field "MMM" during an active session.

Proposal

RFC3558 recommends that mode change request is applicable to two-party calls only and not to multi-party calls.

(Section 10)
The Mode Request signal requests a particular encoding mode for the speech encoding in the reverse direction.  All implementations are RECOMMENDED to honor the Mode Request signal.  The Mode Request signal SHOULD only be used in one-to-one sessions.  In multi-party sessions, any received Mode Request signals SHOULD be ignored.


It is believed that mode request should be applicable to EVRCNW operation in both two-party and conference calls.  In particular, mode request is necessary to activate EVRCNW narrowband-to-wideband and wideband-to-narrowband switching during an active two-party or conference call session.

It is proposed that the following texts for mode request usage be considered for media subtype EVRCNW payload format.



Original text: Section 6

   Three RTP packet formats are supported for the EVRC-NW codec - the interleaved/bundled packet format, the header-free packet format and the compact bundled packet format.  For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and [3], except that the mode change request field in the ToC MUST be interpreted according to the definition of the RATE_REDUC parameter as defined in EVRC-NW [4]. The media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format and audio/EVRCNW1 maps to the compact bundled packet format.

Suggested text: Section 6

   Three RTP packet formats are supported for the EVRC-NW codec - the interleaved/bundled packet format, the header-free packet format and the compact bundled packet format.  For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and [3], except that (1) the mode change request field in the ToC interleaved/bundled packet format MUST be interpreted according to the definition of the RATE_REDUC parameter as defined in EVRC-NW [4] and (2) the mode change request field in interleaved/bundled packet format SHOULD be honored by an EVRCNW encoding end point in an one-to-one session with a dedicated EVRCNW decoding end point such as in a two-party call or in a conference leg. The media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format and audio/EVRCNW1 maps to the compact bundled packet format.





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.