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

Chung Cheung Chu <chung.cheung.chu@ericsson.com> Fri, 15 April 2011 13:22 UTC

Return-Path: <chung.cheung.chu@ericsson.com>
X-Original-To: payload@ietfc.amsl.com
Delivered-To: payload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5666FE0719 for <payload@ietfc.amsl.com>; Fri, 15 Apr 2011 06:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxo3i4kJscNE for <payload@ietfc.amsl.com>; Fri, 15 Apr 2011 06:22:09 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id A6E4CE070A for <payload@ietf.org>; Fri, 15 Apr 2011 06:22:09 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FDLqBT013060; Fri, 15 Apr 2011 08:22:09 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 15 Apr 2011 09:21:48 -0400
From: Chung Cheung Chu <chung.cheung.chu@ericsson.com>
To: "payload@ietf.org" <payload@ietf.org>, "zfang@qualcomm.com" <zfang@qualcomm.com>
Date: Fri, 15 Apr 2011 09:21:48 -0400
Thread-Topic: Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02"
Thread-Index: Acv7cBLQOXCKYLYoShWDuO6AxsjItQ==
Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6@EUSAACMS0702.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6EUSAACMS0702e_"
MIME-Version: 1.0
Subject: [payload] Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02"
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: Fri, 15 Apr 2011 14:06:54 -0000

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