Audio Video Transport WG                                  Sassan Ahmadi
INTERNET-DRAFT                                               Nokia Inc.
Expires: November 26, 2005                                 May 26, 2005


      Real-Time Transport Protocol (RTP) Payload Format for the
   Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec
           <draft-ahmadi-avt-rtp-vmr-wb-extension-00.txt>


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is a submission of the IETF AVT WG. Comments should
   be directed to the AVT WG mailing list, avt@ietf.org.


Abstract

   This document is an addendum to RFC xxxx, which specifies the
   real-time transport protocol for the Variable-Rate Multimode
   Wideband (VMR-WB) speech codec. This document contains the
   information related to the new operating mode of VMR-WB. All
   provisions, restrictions, use cases, features, etc. that are
   specified in RFC xxxx are applicable to the new operating mode
   without any exception.

   No new media type registration is included in this document as the
   new VMR-WB mode, defined in this document, will use the same media
   type specified in RFC xxxx (i.e., audio/VMR-WB). Note that the
   RFC xxxx was developed with sufficient flexibility for future
   extensions and thereby it allows the addition of new operating
   modes without any impacts on the interoperability of terminals
   supporting different versions of the VMR-WB standard.

Sassan Ahmadi                                                  [page 1]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

Table of Contents

1.Introduction.................................................2
2.Conventions and Acronyms.....................................2
3.The Variable-Rate Multimode Wideband (VMR-WB) Extension......3
4.The Necessary Updates in RFC xxxx............................3
   4.1. Implementation Considerations..........................5
5. Congestion Control..........................................5
6. Security Considerations.....................................5
   6.1. Confidentiality........................................5
   6.2. Authentication.........................................5
   6.3. Decoding Validation and Provision for Lost or Late
        Packets................................................5
7. Payload Format Parameters...................................6
   7.1. VMR-WB RTP Payload MIME Registration...................6
   7.2. Mapping MIME Parameters into SDP.......................7
   7.3. Offer-Answer Model Considerations......................7
8. IANA Considerations.........................................7
References.....................................................7
   Normative References........................................7
   Informative References......................................7
Author's Address...............................................7
IPR Notice.....................................................8
Copyright Notice...............................................8


1. Introduction

   This document is an addendum to RFC xxxx [2] and contains the
   necessary updates for the support of the new operating mode of 3GPP2
   VMR-WB standard [1]. The new mode of VMR-WB standard (i.e., VMR-WB
   mode 4) has similar characteristics (e.g., narrowband/wideband
   input/output media processing capability, continuous and
   discontinuous transmission, etc.)  as the other modes of VMR-WB
   already included in RFC xxxx. Therefore, all provisions and
   restrictions specified in RFC xxxx are applicable to all modes of
   the VMR-WB standard including the new mode, which is described in
   this document.

   As a result, no media type registration is required. The VMR-WB file
   format; i.e., for transport of VMR-WB speech data in storage mode
   applications, is specified in [1,4] and supports the new mode.

   The following sections provide the necessary updates to RFC xxxx to
   enable support of VMR-WB mode 4.


2. Conventions and Acronyms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as


Sassan Ahmadi                                                  [page 2]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

   described in RFC2119 [3].

   The following acronyms are used in this document:

    3GPP2  - The Third Generation Partnership Project 2
    CDMA   - Code Division Multiple Access
    VMR-WB - Variable-Rate Multimode Wideband Codec
    CMR    - Codec Mode Request
    DTX    - Discontinuous Transmission
    RTP    - Real-Time Transport Protocol
    MIME   - Multipurpose Internet Mail Extension
    SDP    - Session Description Protocol

   The term "frame-block" is used in this document to describe
   the time-synchronized set of speech frames in a multi-channel


3. The Variable-Rate Multimode Wideband (VMR-WB) Extension

   VMR-WB is the wideband speech-coding standard developed by
   Third Generation Partnership Project 2 (3GPP2) for
   encoding/decoding wideband/narrowband speech content in
   multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a
   source-controlled variable-rate multimode wideband speech
   codec. It has a number of operating modes, where each mode is
   a tradeoff between voice quality and average data rate. The
   operating mode in VMR-WB (as shown in Table 2) is chosen based on
   the traffic condition of the network and the desired quality of
   service. The desired average data rate (ADR) in each mode
   is obtained by encoding speech frames at permissible rates (as shown
   in Tables 1 and 3) compliant with CDMA2000 system depending on the
   instantaneous characteristics of input speech and the maximum and
   minimum rate constraints imposed by the network operator.

   The capabilities of the VMR-WB codec were extended through the
   addition of a new mode operating at lower average data rates,
   resulting in improved system capacity in IP and non-IP networks [1].

   As a result of this extension, certain tables and parameters in RFC
   xxxx must be updated to support of the new operating mode. VMR-WB
   mode 4 is compliant with all applicable provisions and restrictions
   specified in RFC xxxx [2].

   The existing flexibility in RFC xxxx for future extensions allows
   the addition of the new mode without any impact on the
   interoperability with earlier implementations of RFC xxxx.

   The following sections provide the necessary updates that are
   required to be made in RFC xxxx.


4. The Necessary Updates in RFC xxxx


Sassan Ahmadi                                                  [page 3]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

Table 1 of RFC xxxx is updated as follows:

   +---------------------------+-----------------+---------------+
   |        Frame Type         | Bits per Packet | Encoding Rate |
   |                           |   (Frame Size)  |     (kbps)    |
   +---------------------------+-----------------+---------------+
   | Full-Rate                 |      266        |     13.3      |
   | Full-Rate                 |      171        |     8.55      |
   | Half-Rate                 |      124        |      7.2      |
   | Half-Rate                 |       80        |      4.0      |
   | Quarter-Rate              |       54        |      2.7      |
   | Quarter-Rate              |       40        |      2.0      |
   | Eighth-Rate               |       20        |      1.0      |
   | Eighth-Rate               |       16        |      0.8      |
   | Blank                     |        0        |       -       |
   | Erasure                   |        0        |       -       |
   | Full-Rate with Bit Errors |      171        |     8.55      |
   +---------------------------+-----------------+---------------+
   Table 1: CDMA2000 system permissible frame types and their associated
   encoding rates

   Note that the new permissible rates correspond to CDMA2000 rate-set
   I.

   Table 2 of RFC xxxx is updated as follows to include VMR-WB mode 4
   and VMR-WB mode 4 with maximum half-rate similar to that described in
   Section 2.4 of the revised VMR-WB specification [1].

   +-------+----------------------------------------------------------+
   | CMR   |                 VMR-WB Operating Modes                   |
   +-------+----------------------------------------------------------+
   |   0   | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps)   |
   |   1   | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps)   |
   |   2   | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps)  |
   |   3   | VMR-WB mode 2                                            |
   |   4   | VMR-WB mode 1                                            |
   |   5   | VMR-WB mode 0                                            |
   |   6   | VMR-WB mode 2 with maximum half-rate encoding            |
   |   7   | VMR-WB mode 4                                            |
   |   8   | VMR-WB mode 4 with maximum half-rate encoding            |
   | 9-14  | (reserved)                                               |
   |  15   | No Preference (no mode request is present)               |
   +-------+----------------------------------------------------------+
   Table 2: List of valid CMR values and their associated VMR-WB
   operating modes.

   Table 3 of RFC xxxx is updated as follows to include new frame types
   (FT) associated with VMR-WB mode 4.

   Note that the size of the frames are unique and different, allowing
   for the use of header-free payload format for all modes of operations
   [2].


Sassan Ahmadi                                                  [page 4]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

+----+--------------------------------------------+-------------------+
| FT |                Encoding Rate               | Frame Size (Bits) |
+----+--------------------------------------------+-------------------+
| 0  | Interoperable Full-Rate (AMR-WB 6.60 kbps) |       132         |
| 1  | Interoperable Full-Rate (AMR-WB 8.85 kbps) |       177         |
| 2  | Interoperable Full-Rate (AMR-WB 12.65 kbps)|       253         |
| 3  | Full-Rate 13.3 kbps                        |       266         |
| 4  | Half-Rate 6.2 kbps                         |       124         |
| 5  | Quarter-Rate 2.7 kbps                      |        54         |
| 6  | Eighth-Rate 1.0 kbps                       |        20         |
| 7  | Full-Rate 8.55 kbps                        |       171         |
| 8  | Half-Rate 4.0 kbps                         |        80         |
| 9  | CNG (AMR-WB SID)                           |        35         |
| 10 | Eighth-Rate 0.8 kbps                       |        16         |
| 11 | (reserved)                                 |         -         |
| 12 | (reserved)                                 |         -         |
| 13 | (reserved)                                 |         -         |
| 14 | Erasure (AMR-WB SPEECH_LOST)               |         0         |
| 15 | Blank (AMR-WB NO_DATA)                     |         0         |
+----+--------------------------------------------+-------------------+
Table 3:VMR-WB payload frame types for real-time transport

   Note that the new entires replace the "reserved" entries in RFC xxxx
   Tables 1 to 3 and there are no changes in the existing table entries
   of RFC xxxx.


4.1 Implementation Considerations

   Same as RFC xxxx


5. Congestion Control

   Same as RFC xxxx


6. Security Considerations

   Same as RFC xxxx


6.1. Confidentiality

   Same as RFC xxxx


6.2. Authentication

   Same as RFC xxxx


6.3. Decoding Validation and Provision for Lost or Late Packets

Sassan Ahmadi                                                  [page 5]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

   Same as RFC xxxx


7. Payload Format Parameters

   Same as RFC xxxx.


7.1. VMR-WB RTP Payload MIME Registration

   No MIME registration is required for the new mode of VMR-WB. The
   only necessary update is in the definition of the optional MIME
   parameter "mode-set" by adding the new operating mode. Note that
   the addition of the new mode does not create any interoperability
   issues since the modes of operation are negotiated and agreed
   by the IP terminals through the offer-answer model provided in
   Section 9.3 of RFC xxxx [2].

     mode-set:       Requested VMR-WB operating mode set. Restricts
                     the active operating modes to a subset of all
                     modes. Possible values are a comma separated
                     list of integer values. Currently, this list
                     includes modes 0,1,2, 3, and 4 [1,2] but MAY be
                     extended in the future. If such mode-set is
                     specified during session initiation, the encoder
                     MUST NOT use modes outside of the subset. If not
                     present, all operating modes in the set 0 to 4 are
                     allowed for the session.

   Encoding considerations:

          Same as RFC xxxx

   Security considerations:

          Same as RFC xxxx

   Public specification:

          The VMR-WB speech codec is specified in following
          3GPP2 specifications C.S0052-A version 1.0.
          Transfer methods are specified in RFC xxxx.

   Additional information:

   Person & email address to contact for further information:

                 Sassan Ahmadi, Ph.D.   Nokia Inc. USA
                 sassan.ahmadi@nokia.com

   Intended usage: COMMON.

     Same as RFC xxxx

Sassan Ahmadi                                                  [page 6]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

   Author/Change controller:

     IETF Audio/Video Transport working group delegated from the IESG


7.2. Mapping MIME Parameters into SDP

     Same as RFC xxxx


7.3. Offer-Answer Model Considerations

     Same as RFC xxxx


8. IANA Considerations

     None


References

Normative References

   [1]  3GPP2 C.S0052-A v1.0 "Source-Controlled Variable-Rate
        Multimode Wideband Speech Codec (VMR-WB) Service Options
        62 and 63 for Spread Spectrum Systems", 3GPP2 Technical
        Specification, April 2005.

   [2]  S. Ahmadi, "Real-Time Transport Protocol (RTP) Payload Formats
        for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec",
        RFC xxxx, Internet Engineering Task Force, May 2005.

   [3]  S. Bradner, "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, Internet Engineering
        Task Force, March 1997.

Informative References

   [4]  3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia
        Services", 3GPP2 Technical Specification, May 2005.

   Any 3GPP2 document can be downloaded from the 3GPP2 web
   server, "http://www.3gpp2.org/", see specifications.


Author's Address

   The editor will serve as the point of contact for all
   technical matters related to this document.

    Dr. Sassan Ahmadi             Phone: 1 (858) 831-5916
                                  Fax:   1 (858) 831-5111

Sassan Ahmadi                                                  [page 7]


INTERNET-DRAFT      VMR-WB Extension RTP Payload Format        May 2005

    Nokia Inc.                    Email: sassan.ahmadi@nokia.com
    12278 Scripps Summit Dr.
    San Diego, CA 92131 USA

    This Internet-Draft expires in six months from May 27, 2005.


RFC Editor Considerations

    The RFC editor is requested to replace all occurrences of xxxx with
    the RFC number that reference [2] will receive.


IPR Notice

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed
    to pertain to the implementation or use of the technology described
    in this document or the extent to which any license under such
    rights might or might not be available; nor does it represent that
    it has made any independent effort to identify any such rights.
    Information on the procedures with respect to rights in RFC
    documents can be found in BCP 78 and BCP 79.
    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use
    of such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository
    at http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Copyright Notice

    Copyright (C) The Internet Society (2005).  This document is
    subject to the rights, licenses and restrictions contained in BCP
    78, and except as set forth therein, the authors retain all their
    rights.

    This document and the information contained herein are provided on
    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE.

Sassan Ahmadi                                                  [page 8]