Network Working Group                                             Q. Xie
Internet-Draft                                                  Motorola
Expires: October 1, 2006                                       R. Kapoor
                                                                Qualcomm
                                                          March 30, 2006


       Enhancements to RTP Payload Formats for EVRC Family Codecs
               draft-ietf-avt-compact-bundled-evrc-02.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/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on October 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines several enhancements and extensions to the EVRC
   RTP payload formats defined in RFC 3558.  In particular, it defines
   support for the header-free and interleaved/bundled packet formats
   for the EVRC-B codec, a new compact bundled format for the EVRC and
   EVRC-B codecs, as well as discontinuous transmission (DTX) support
   for EVRC and EVRC-B encoded speech transported via RTP.  VoIP
   applications operating over low bandwidth dial-up and wireless



Xie & Kapoor             Expires October 1, 2006                [Page 1]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   networks require such enhancements for efficient use of the
   bandwidth.

Table of Contents

   1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1   Support of EVRC-B Codec  . . . . . . . . . . . . . . . . .  3
     2.2   Compact (Header-free) Bundled Format . . . . . . . . . . .  3
     2.3   Discontinuous Transmission (DTX) . . . . . . . . . . . . .  4
   3.  EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Other Frame-Based Vocoders . . . . . . . . . . . . . . . .  5
   4.  Compact Bundled Format . . . . . . . . . . . . . . . . . . . .  5
     4.1   Single Rate Operation  . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
     5.1   Registration of Media Type EVRC1 . . . . . . . . . . . . .  6
     5.2   Registration of Media Type EVRCB . . . . . . . . . . . . .  7
     5.3   Registration of Media Type EVRCB0  . . . . . . . . . . . .  8
     5.4   Registration of Media Type EVRCB1  . . . . . . . . . . . .  9
     5.5   DTX Parameters . . . . . . . . . . . . . . . . . . . . . . 10
     5.6   Mapping MIME Parameters into SDP . . . . . . . . . . . . . 12
     5.7   Usage in Offer/Answer  . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Storage Format . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2   Informative References . . . . . . . . . . . . . . . . . . 15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 17





















Xie & Kapoor             Expires October 1, 2006                [Page 2]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


1.  Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [2].

2.  Introduction

   This document defines support for the header-free and interleaved/
   bundled packet formats for the EVRC-B codec, a new compact bundled
   format for the EVRC and EVRC-B codecs, as well as discontinuous
   transmission (DTX) support for EVRC and EVRC-B encoded speech
   transported via RTP.  VoIP applications operating over low bandwidth
   dial-up and wireless networks require such EVRC RTP payload
   capabilities for efficient use of the bandwidth.

2.1  Support of EVRC-B Codec

   EVRC-B [4] is an extension to [3] developed in 3GPP2.  EVRC-B [4]
   compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech
   input into output frames of one of the four different sizes: Rate 1
   (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16
   bits).  In addition, there are two zero bit codec frame types: null
   frames and erasure frames, similar to EVRC [3].  One significant
   enhancement in EVRC-B is the use of 1/4 rate frames that were not
   used in EVRC.  This provides lower average data rates (ADRs) compared
   to EVRC, for a given voice quality.

   Since speech frames encoded by EVRC-B are different from those
   encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each
   other.  At the initiation of a RTP session, the RTP sender and
   receiver need to indicate (e.g., using MIME subtypes that are
   separate from those of EVRC) that EVRC-B is to be used for the
   ensuing session.

2.2  Compact (Header-free) Bundled Format

   The current interleaved/bundled packet format defined in RFC 3558
   allows bundling of multiple speech frames of different rate in a
   single RTP packet, sending mode change requests, and interleaving.
   To support these functions, a Table of Contents (ToC) is used in each
   RTP packet in addition to the standard RTP header.  The size of the
   ToC is variable, depending on the number of EVRC frames carried in
   the packet [5].

   The current header-free packet format defined in RFC 3558 is more
   compact and optimized for use over wireless links.  It eliminates the



Xie & Kapoor             Expires October 1, 2006                [Page 3]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   need for a ToC by requiring that each RTP packet contain only one
   speech frame (of any allowable rate), i.e., bundling is not allowed.
   Moreover, interleaving and mode change request are not supported in
   the header-free format [5].

   The compact bundled format described in this document presents the
   user an alternative to the header-free format defined in RFC 3558.
   This format allows bundling of multiple EVRC or EVRC-B frames without
   the addition of extra headers, as would be in case of the
   interleaved/bundled format.  However, in order to use this compact
   bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can
   be used in the session.  Similar to the header-free format defined in
   RFC 3558, interleaving and mode change request are not supported in
   the compact bundled format.

2.3  Discontinuous Transmission (DTX)

   The EVRC and EVRC-B codecs do not use Silence Descriptor frames;
   instead, in variable rate operation mode the encoder sends 1/8 rate
   frames during periods of silence, while in single rate operation mode
   (see Section 4), silence is encoded and sent in frames of the same
   rate as that of speech frames.  The DTX parameters defined in this
   document apply to 1/8th rate frames in the variable rate mode and to
   silence frames in the single rate operation mode.

   For simplicity, in the rest of this document the term "silence frame"
   refers either to an 1/8th rate frame in variable rate operation or a
   frame that contains only silence in the signal rate operation.

   Information carried in silence frames of EVRC and EVRC-B codecs
   varies little during periods of silence.  The transmission of these
   silence frames across the radio interface in a wireless system is
   expensive in terms of capacity, and therefore, suppression of these
   frames is desirable.

   Suppression of silence frames is accomplished by using DTX.  When DTX
   is applied, the first few silence frames may be transmitted to
   establish background noise during the period of silence.  Then a
   portion of the stream of subsequent silence frames is not transmitted
   and is discarded at the sender.  At the receiver, background or
   comfort noise may be generated by using the previously received
   silence frames.

3.  EVRC-B Codec

   Three RTP packet formats are supported for the EVRC-B codec - the
   interleaved/bundled packet format, the header-free packet format and
   the compact bundled packet format.  For the interleaved/bundled and



Xie & Kapoor             Expires October 1, 2006                [Page 4]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   header-free packet formats, the operational details and capabilities,
   such as ToC, interleaving, and bundling, of EVRC-B are exactly the
   same as those of EVRC, as defined in RFC3558 [5], except that the
   mode change request field in the ToC MUST be interpreted according to
   the definition of the RATE_REDUC parameter in EVRC-B [4].  The
   compact bundled packet format for EVRC-B is defined in Section 4 of
   this document.

3.1  Other Frame-Based Vocoders

   Other frame-based vocoders can be carried in the packet formats
   defined in this document, as long as they possess the following
   properties:

   o  the codec is frame-based;

   o  blank and erasure frames are supported;

   o  the total number of rates is less than 17;

   o  the maximum full rate frame can be transported in a single RTP
      packet using this specific format.

   Vocoders with the characteristics listed above can be transported
   using the packet format specified in this document with some
   additional specification work; the pieces that must be defined are
   listed in Section 15 of RFC 3558.

4.  Compact Bundled Format

   A packet in the compact bundled format consists of an RTP header
   followed by a sequence of one or more consecutive EVRC/EVRC-B codec
   data frames of the same rate, as shown below:

    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]                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   |       One or more EVRC/EVRC-B data frames of same rate        |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The codec data frames MUST be generated from the output of the codec
   following the procedure described in 5.2 in RFC 3558 [5] and all MUST
   be of the same rate and size.




Xie & Kapoor             Expires October 1, 2006                [Page 5]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


4.1  Single Rate Operation

   As mentioned earlier, in order to use the compact bundled format, all
   the EVRC/EVRC-B data frames in the session MUST be of the same rate.
   This packet format may carry only full or half-rate frames.

   For a session that uses the compact bundled format, the rate for the
   session can be determined during the session setup signaling, for
   example, via SDP exchanges.  See Section 5 below for more details.

5.  IANA Considerations

   Four (4) new MIME subtype registrations are required for EVRC-B
   support and compact bundled format payload types, and four (4)
   optional parameters - "silencesupp", "dtxmax", "dtxmin", and
   "hangover" - are defined and used in DTX, as described below.

5.1  Registration of Media Type EVRC1

   MIME media type name: audio

   MIME subtype names: EVRC1

   Required parameters: none

   Optional parameters: The following parameters apply to RTP transfer
      only.

   ptime: see RFC 2327 [8].

   maxptime: The maximum amount of media which can be encapsulated in
      each packet, expressed as time in milliseconds.  The time SHALL be
      calculated as the sum of the time the media present in the packet
      represents.  The time SHOULD be a multiple of the duration of a
      single codec data frame (20 msec).  If not signaled, the default
      maxptime value SHALL be 200 milliseconds.

   fixedrate: Indicates the EVRC rate of the session while in single
      rate operation.  Valid values include: 0.5 and 1, where a value of
      0.5 indicates the 1/2 rate while a value of 1 indicates the full
      rate.  If this parameter is not present, 1/2 rate is assumed.

   Encoding considerations: These types are defined for transfer of EVRC
      encoded data via RTP using the compact bundled format as described
      in RFC XXXX.






Xie & Kapoor             Expires October 1, 2006                [Page 6]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   Security considerations: See Section 6 of RFC XXXX.

   Published specification: The EVRC vocoder is specified in 3GPP2
      C.S0014 [3].  Transfer method with compact bundled RTP format is
      specified in RFC XXXX.

   Applications which use this media type: It is expected that many VoIP
      applications (as well as mobile applications) will use this type.

   Additional information: none

   Person & email address to contact for further
      information: Qiaobing.Xie@motorola.com

   Intended usage: COMMON

   Restrictions on usage: This type is only defined for transfer via RTP
      [6].

   Author: Qiaobing Xie

   Change controller: IETF Audio/Video Transport working group delegated
      from the IESG.


5.2  Registration of Media Type EVRCB

   MIME media type name: audio

   MIME subtype names: EVRCB

   Required parameters: none

   Optional parameters: The following parameters apply to RTP transfer
      only.

   ptime: see RFC 2327 [8].

   maxptime: The maximum amount of media which can be encapsulated in
      each packet, expressed as time in milliseconds.  The time SHALL be
      calculated as the sum of the time the media present in the packet
      represents.  The time SHOULD be a multiple of the duration of a
      single codec data frame (20 msec).  If not signaled, the default
      maxptime value SHALL be 200 milliseconds.







Xie & Kapoor             Expires October 1, 2006                [Page 7]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   maxinterleave: Maximum number for interleaving length (field LLL in
      the Interleaving Octet).  The interleaving lengths used in the
      entire session MUST NOT exceed this maximum value.  If not
      signaled, the maxinterleave length SHALL be 5.

   Encoding considerations: This media type is defined for transfer of
      EVRC-B encoded data via RTP using the Interleaved/Bundled packet
      format specified in RFC 3558 [5].

   Security considerations: See Section 6 of RFC XXXX.

   Interoperability considerations: none

   Published specification: The EVRC-B vocoder is specified in 3GPP2
      C.S0014-B [4].  Transfer method with Interleaved/Bundled packet
      format via RTP is specified in RFC 3558.

   Applications which use this media type: It is expected that many VoIP
      applications (as well as mobile applications) will use this type.

   Additional information: none

   Person & email address to contact for further
      information: Qiaobing.Xie@motorola.com

   Intended usage: COMMON

   Restrictions on usage: This type is only defined for transfer via RTP
      [6].

   Author: Qiaobing Xie

   Change controller: IETF Audio/Video Transport working group delegated
      from the IESG.


5.3  Registration of Media Type EVRCB0

   MIME media type name: audio

   MIME subtype names: EVRCB0

   Required parameters: none

   Optional parameters: see RFC 3558 [5].






Xie & Kapoor             Expires October 1, 2006                [Page 8]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   Encoding considerations: This media type is defined for transfer of
      EVRC-B encoded data via RTP using the Header-Free packet format
      specified in RFC 3558 [5].

   Security considerations: See Section 6 of RFC XXXX.

   Interoperability considerations: none

   Published specification: The EVRC-B vocoder is specified in 3GPP2
      C.S0014-B [4].  Transfer method with Header-Free packet format via
      RTP is specified in RFC 3558 and RFC XXXX.

   Applications which use this media type: It is expected that many VoIP
      applications (as well as mobile applications) will use this type.

   Additional information: none

   Person & email address to contact for further
      information: Qiaobing.Xie@motorola.com

   Intended usage: COMMON

   Restrictions on usage: This type is only defined for transfer via RTP
      [6].

   Author: Qiaobing Xie

   Change controller: IETF Audio/Video Transport working group delegated
      from the IESG.


5.4  Registration of Media Type EVRCB1

   MIME media type name: audio

   MIME subtype names: EVRCB1

   Required parameters: none

   Optional parameters: The following parameters apply to RTP transfer
      only.

   ptime: see RFC 2327 [8].

   maxptime: The maximum amount of media which can be encapsulated in
      each packet, expressed as time in milliseconds.  The time SHALL be
      calculated as the sum of the time the media present in the packet
      represents.  The time SHOULD be a multiple of the duration of a



Xie & Kapoor             Expires October 1, 2006                [Page 9]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


      single codec data frame (20 msec).  If not signaled, the default
      maxptime value SHALL be 200 milliseconds.

   fixedrate: Indicates the EVRC-B rate of the session while in single
      rate operation.  Valid values include: 0.5 and 1, where a value of
      0.5 indicates the 1/2 rate while a value of 1 indicates the full
      rate.  If this parameter is not present, 1/2 rate is assumed.

   Encoding considerations: These types are defined for transfer of
      EVRC-B encoded data via RTP using the compact bundled format as
      described in RFC XXXX.

   Security considerations: See Section 6 of RFC XXXX.

   Published specification: The EVRC-B vocoder is specified in 3GPP2
      C.S0014-B [4].  Transfer method with compact bundled RTP format is
      specified in RFC XXXX.

   Applications which use this media type: It is expected that many VoIP
      applications (as well as mobile applications) will use this type.

   Additional information: none

   Person & email address to contact for further
      information: Qiaobing.Xie@motorola.com

   Intended usage: COMMON

   Restrictions on usage: This type is only defined for transfer via RTP
      [6].

   Author: Qiaobing Xie

   Change controller: IETF Audio/Video Transport working group delegated
      from the IESG.


5.5  DTX Parameters

   For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558
   [5] and RFC XXXX, four additional optional parameters -
   "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and
   used in DTX, as described below.








Xie & Kapoor             Expires October 1, 2006               [Page 10]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   silencesupp: Permissible values are 0 and 1.  A value of 1 indicates
      that the sender of this parameter is capable of and desires to
      support silence suppression using DTX.  A value of 0 indicates
      that the sender of this parameter is either incapable of or
      unwilling to use silence suppression using DTX.  An RTP endpoint
      may use this parameter to declare its ability and desire to
      support silence suppression using DTX.  If this parameter is not
      present, the default value specified in [9] MUST be assumed.

      If the RTP receiver indicates through the use of SIP signaling or
      other means that it is incapable of or unwilling to use silence
      suppression using DTX, silence suppression using DTX as specified
      in this document MUST NOT be used for the session.

   dtxmax: indicates the maximum DTX update interval in number of
      frames.  During DTX, the RTP sender occasionally updates the RTP
      receiver about the change in background noise characteristics,
      etc., by sending a new silence frame to the RTP receiver.  The RTP
      receiver may use 'dtxmax' to indicate to the RTP sender the
      maximum interval (in number of frames) between any two DTX updates
      it expects to receive from the RTP sender.  If this parameter is
      not present in a session that uses DTX, the default value
      specified in [9] MUST be assumed.

      This parameter MUST be ignored if silence suppression using DTX is
      not used for the session.

   dtxmin: indicates the minimum DTX update interval in number of
      frames.  The RTP receiver may use 'dtxmin' to indicate to the RTP
      sender the minimal interval (in number of frames) between any two
      DTX updates it expects to receive from the RTP sender.  If this
      parameter is not present, the default value specified in [9] MUST
      be assumed.

      This parameter MUST be ignored if silence suppression using DTX is
      not used for the session.

   hangover: indicates the number of consecutive silence frames
      transmitted at the end of an active speech interval but before the
      DTX interval begins.  When setting up an RTP session that uses
      DTX, an RTP receiver can use this parameter to signal the number
      of silence frames it expects to receive before the beginning of
      DTX.  While hangover=0 is allowed, it is RECOMMENDED that hangover
      be set to 1 or greater since the presence of silence frames at the
      end of active speech can help the RTP receiver to identify the
      beginning of the DTX period.  If this parameter is not present for
      a session that uses DTX, the default value specified in [9] MUST
      be assumed.



Xie & Kapoor             Expires October 1, 2006               [Page 11]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


      This parameter MUST be ignored if silence suppression using DTX is
      not used for the session.


5.6  Mapping MIME Parameters into SDP

   The information carried in the MIME media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [8], which is commonly used to describe RTP sessions.  When SDP is
   used to specify sessions employing the compact bundled format for
   EVRC/EVRC-B encoded speech, the mapping is as follows:

   o  The MIME type ("audio") goes in SDP "m=" as the media name.

   o  The MIME subtype ("EVRC1", "EVRCB", EVRCB0", or "EVRCB1") goes in
      SDP "a=rtpmap" as the encoding name.

   o  The optional parameters "ptime" and "maxptime" go in the SDP
      "a=ptime" and "a=maxptime" attributes, respectively.

   o  The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1)
      goes in "a=fmtp" attribute by copying it directly from the MIME
      media type string as "fixedrate=value".

   o  The optional parameters "silencesupp", "dtxmax", "dtxmin", and
      "hangover" go in "a=fmtp" attribute by copying it directly from
      the MIME media type string as "silencesupp=value", "dtxmax=value",
      "dtxmin=value", and "hangover=value", respectively.

   Example of usage of EVRC1:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC1/8000
     a=fmtp:97 fixedrate=0.5
     a=maxptime:120

   Example of usage of EVRCB:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRCB/8000
     a=maxptime:120

   Example of usage of EVRCB0:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRCB0/8000

   Example of usage of EVRCB1:



Xie & Kapoor             Expires October 1, 2006               [Page 12]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRCB1/8000
     a=fmtp:97 fixedrate=0.5
     a=maxptime:100

   Example of usage of EVRC with DTX with silencesupp=1:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC/8000
     a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1

   Examples of usage of EVRC with DTX with silencesupp=0:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC/8000
     a=fmtp:97 silencesupp=0


5.7  Usage in Offer/Answer

   All SDP parameters in this payload format are declarative, and all
   reasonable values are expected to be supported.  Thus, the standard
   usage of Offer/Answer as described in RFC 3264 [7] SHOULD be
   followed.

   In addition, the following rules MUST be followed while negotiating
   DTX parameters:

   1.  If either offer and/or answer does not contain DTX parameters,
       the default values of the DTX parameters MUST be used.

   2.  If silencesupp is present and set to 1 in either offer or answer,
       all four DTX parameters MUST be present.  An example of this SDP
       usage is shown in Section 5.6.

   3.  If silencesupp is present and set to 0 in either offer or answer,
       the values of all received DTX parameters other than silencesupp
       SHOULD be ignored.

   4.  The value of dtxmax MUST be larger than or equal to the value of
       dtxmin.  Furthermore, if both offer and answer contain the dtxmax
       parameter, the value of dtxmax in the answer MUST be less than or
       equal to the value of dtxmax in the offer.

   5.  If both offer and answer contain the dtxmin parameter, the value
       of dtxmin in the answer MUST be greater than or equal to the
       value of dtxmin in the offer.




Xie & Kapoor             Expires October 1, 2006               [Page 13]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


   6.  If both offer and answer contain the hangover parameter, the
       value of hangover in the answer MUST be greater than or equal to
       the value of hangover in the offer.


6.  Security Considerations

   Implementations using the payload defined in this specification are
   subject to the security considerations discussed in RFC 3558 [5], RFC
   3550 [6], and any appropriate profile (for example RFC3551 [11]).
   This payload does not specify any different security services.

7.  Storage Format

   The storage format is used for storing speech frames, e.g., as a file
   or e-mail attachment.

   The file begins with a magic number to identify the vocoder that is
   used.  The magic number for EVRC-B corresponds to the ASCII character
   string "#!EVRC-B\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43 0x2D 0x42
   0x0A".

   Note, the "\n" is an important part of the magic number and MUST be
   included in the comparison, since, otherwise, the EVRC-B magic number
   will become indistinguishable from magic number used for EVRC.

   The codec data frames are stored in consecutive order, with a single
   TOC entry field, extended to one octet, prefixing each codec data
   frame.  The ToC field is extended to one octet by setting the four
   most significant bits of the octet to zero.  For example, a ToC value
   of 4 (a full-rate frame) is stored as 0x04.

   Speech frames lost in transmission and non-received frames MUST be
   stored as erasure frames (frame type 5, see definition in Section
   5.1, RFC3558) to maintain synchronization with the original media.

8.  Acknowledgements

   The following people have made significant contributions to this
   document (in alphabetic order): Parag Agashe, Jim Ashley, Harikishan
   Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth
   Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh
   Vij.

9.  References






Xie & Kapoor             Expires October 1, 2006               [Page 14]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


9.1  Normative References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  "Enhanced Variable Rate Codec, Speech Service Option 3 for
        Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014,
        January 1997.

   [4]  "Enhanced Variable Rate Codec, Speech Service Option XX for
        Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B, in
        progress.

   [5]  Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
        (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.

   [6]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications",
        RFC 3550, July 2003.

   [7]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        the Session Description Protocol (SDP)", RFC 3264, June 2002.

   [8]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [9]  "Discontinuous Transmission (DTX) of Speech in cdma2000
        Systems", 3GPP2 C.S0076-0, Version 1.0.

9.2  Informative References

   [10]  Bormann, C., "RObust Header Compression (ROHC): Framework and
         four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
         July 2001.

   [11]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
         Conferences with Minimal Control", RFC 3551, July 2003.











Xie & Kapoor             Expires October 1, 2006               [Page 15]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


Authors' Addresses

   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, 2-F9
   Arlington Heights, IL  60004
   US

   Phone: +1-847-632-3028
   Email: Qiaobing.Xie@Motorola.com


   Rohit Kapoor
   Qualcomm Inc.
   US

   Phone: +1-858-845-1161
   Email: rkapoor@qualcomm.com

































Xie & Kapoor             Expires October 1, 2006               [Page 16]


Internet-Draft        EVRC RTP Format Enhancements            March 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Xie & Kapoor             Expires October 1, 2006               [Page 17]