[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-avt-compact-bundled-evrc

Network Working Group                                             Q. Xie
Internet-Draft                                                  Motorola
Expires: March 27, 2006                                        R. Kapoor
                                                                Qualcomm
                                                      September 23, 2005


           Enhancements to RTP Format for EVRC Family Codecs
               draft-xie-avt-compact-bundle-evrc-01.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 March 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines several enhancements and extensions to RFC3558
   EVRC RTP payload format.  In particular, it defines the support for a
   compact bundled format and EVRC-B codec, as well as discontinuous
   transmission (DTX) support for EVRC and EVRC-B encoded speech
   transported via RTP sessions.  Some VoIP applications, such as Push-
   to-Talk and VoIP over low bandwidth dial-up and wireless networks,
   require such enhancements for efficient use of the bandwidth.



Xie & Kapoor             Expires March 27, 2006                 [Page 1]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


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 . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Compact Bundled Format . . . . . . . . . . . . . . . . . . . .  5
     4.1   Single Rate Operation  . . . . . . . . . . . . . . . . . .  5
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
     5.1   Registration of Media Type EVRCB . . . . . . . . . . . . .  6
     5.2   Registration of Media Type EVRC1 and EVRCB1  . . . . . . .  6
     5.3   Payload Format Parameters for DTX  . . . . . . . . . . . .  8
     5.4   Mapping MIME Parameters into SDP . . . . . . . . . . . . .  9
     5.5   Usage in Offer/Answer  . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2   Informative References . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 12





























Xie & Kapoor             Expires March 27, 2006                 [Page 2]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


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 several enhancements and extensions to RFC3558
   EVRC RTP payload format [5].  In particular, it defines the support
   for a compact bundled format and EVRC-B codec, as well as
   discontinuous transmission (DTX) support for EVRC and EVRC-B encoded
   speech transported via RTP sessions.  Some VoIP applications, such as
   Push-to-Talk and VoIP over low bandwidth dial-up and wireless
   networks, require such enhancements 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 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 that there are Rate 1/4 frames that were not used in EVRC.
   This provides lower average data rates (ADRs) compared to EVRC, for a
   given voice quality.

   Since EVRC-B encoded speech frames are different from those of 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 rate change request, and interleaving.  To
   support these functions, a Table of Content (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 March 27, 2006                 [Page 3]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


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

   Since the biggest EVRC/EVRC-B speech frame is 171 bits (full rate),
   it is therefore very inefficient in terms of bandwidth utilization to
   send EVRC/EVRC-B speech frames one at a time over RTP/UDP/IP, as
   being required by the header-free format.  It is assumed that this
   shortcoming of the header-free format will be overcome or at least
   greatly alleviated in practice by the use of RTP/UDP/IP header
   compression or removal techniques such as ROHC [9].

   However, in many wireless systems such as 3GPP and 3GPP2, header
   compression/removal is only applied between the mobile station and
   the radio access network.  ROHC is not an end-to-end compression
   scheme, there will be many hops between the EVRC/EVRC-B sender and
   the EVRC/EVRC-B receiver where such overheads may be an issue.  As
   speech will be carried one speech frame per RTP packet with full RTP/
   UDP/IP headers, it would result in very poor bandwidth utilization in
   that part of the network.

   The compact bundled format described in this document presents the
   user an alternative to the header-free format defined in RFC 3558.
   The compact bundled format is wireless-friendly since it does not use
   a ToC.  It also allows bundling of multiple EVRC or EVRC-B frames and
   will not create bandwidth inefficiency problems in the network.
   However, to use this compact bundled format the compromise one has to
   make is that 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 rate change request are not supported in
   the compact bundled format.

2.3  Discontinuous Transmission (DTX)

   Originally, EVRC codec did not provide DTX support; in variable rate
   operation mode the encoder sends 1/8 rate frames during periods of
   silence, while in single rate operation mode (see 4.1 ???), silence
   is encoded and sent in silence frames of the same rate as that of
   speech frames.

   Silence or 1/8 rate frames of EVRC and EVRC-B codecs vary little
   during periods of silence.  The transmission of these 1/8 rate frames
   (or silence frames in the single rate operation mode) 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 using DTX.  When DTX is



Xie & Kapoor             Expires March 27, 2006                 [Page 4]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


   applied, the first few 1/8 rate frames (or silence frames in the
   single rate operation mode) are transmitted to establish background
   noise during the period of silence.  Then a portion of the stream of
   subsequent 1/8 rate frames (or silence frames in the single rate
   operation mode) are not transmitted and discarded at the encoder.  At
   the receiver, background or comfort noise should be created by using
   the previously received 1/8th rate frames (or silence frames in the
   single rate operation mode).

3.  EVRC-B Codec

   Two RTP modes are supported for EVRC-B codec - the interleaved/
   bundled packet format and compact bundled packet format.  For the
   interleaved/bundled packet format, 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].  The
   compact bundled packet format for EVRC-B is defined in Section 4 of
   this document.

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 vocoder date frames MUST be generated from the output of the
   vocoder following the procedure described in 5.2 in RFC 3558 [5] and
   they all MUST be of the same rate and size.

4.1  Single Rate Operation

   As mentioned earlier, to use the compact bundled format, all the
   EVRC/EVRC-B data frames in the session MUST be of the same rate
   (either 1 or 1/2 rate).  To some VoIP applications, such as Push-to-
   Talk over cellular, this is not viewed as much of a limitation due to
   their unique communication style where rate changes in a session are
   often difficult and sometimes even undesirable.




Xie & Kapoor             Expires March 27, 2006                 [Page 5]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


   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

   Three (3) new MIME subtype registration are required for the 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 EVRCB

   Media Type name: audio

   Media subtype names: EVRCB

   Required parameters: none

   Optional parameters: see RFC 3558 [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] and RFC XXXX.

   Security considerations: See Section 7 of RFC XXXX.

   Public 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 and RFC XXXX.

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

   Intended usage: COMMON.  It is expected that many VoIP applications
      (as well as mobile applications) will use this type.

   Author/Change controller:

      *  Qiaobing.Xie@motorola.com

      *  IETF Audio/Video transport working group


5.2  Registration of Media Type EVRC1 and EVRCB1






Xie & Kapoor             Expires March 27, 2006                 [Page 6]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


   Media Type name: audio

   Media subtype names: EVRC1, EVRCB1

   Required parameters: none

   Optional parameters:

   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.

   evrcfixedrate: Indicates the EVRC/EVRC-B rate of the session while in
      single rate operation.  Valid values for EVRC1 and EVRCB1 subtype
      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
      or EVRC-B encoded data via RTP using the compact bundled format as
      described in RFC XXXX.

   Security considerations: See Section 7 of RFC XXXX.

   Public specification: The EVRC and EVRC-B vocoders are specified in
      3GPP2 C.S0014 and 3GPP-2 C.S0014-B, respectively.  Transfer method
      with compact bundled RTP format is specified in RFC XXXX.

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

   Intended usage: COMMON.  It is expected that many VoIP applications
      (as well as mobile applications) will use this type.

   Author/Change controller:

      *  Qiaobing.Xie@motorola.com

      *  IETF Audio/Video transport working group







Xie & Kapoor             Expires March 27, 2006                 [Page 7]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


5.3  Payload Format Parameters for DTX

   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.

   silencesupp: Permissible values are 0 and 1.  A value of 1 indicates
      the sender's ability and desire to support silence suppression
      using DTX.  A value of 0 or when not present, it indicates that
      the sender is either incapable or unwilling to use silence
      suppression using DTX.  Unless indicated by both the RTP sender
      and receiver, silence suppression using DTX MUST NOT be used for
      the session.

   dtxmax: indicates the maximum number of 1/8 rate frames (or silence
      frames in the single rate operation mode) that may be continuously
      suppressed and thus provides a "keep alive" function to the
      bearer.  When setting up an RTP session that uses DTX, an RTP
      receiver can use this parameter to signal the maximum number of
      1/8 rate frames (or silence frames in the single rate operation
      mode) that may be continuously suppressed by the RTP sender.  If
      this parameter is not present for a session that uses DTX, the
      default value MUST be assumed.  This parameter MUST be ignored if
      silence suppression using DTX is not used for the session.
      [Editor's note: Default value is 50 and will be specified in a
      3GPP2 TSG-C 1.1 document].

   dtxmin: indicates the minimum number of contiguous 1/8 rate frames
      (or silence frames in the single rate operation mode) that MUST be
      suppressed when they occur in the output of the codec.  When
      setting up an RTP session that uses DTX, an RTP receiver can use
      this parameter to signal the minimum number of contiguous 1/8 rate
      frames (or silence frames in the single rate operation mode) that
      SHOULD be suppressed by the RTP sender.  If this parameter is not
      present for a session that uses DTX, the default value MUST be
      assumed.  This parameter MUST be ignored if silence suppression
      using DTX is not used for the session.  [Editor's note: Default
      value is 8 and will be specified in a 3GPP2 TSG-C 1.1 document.]

   hangover: indicates the number of 1/8 rate frames (or silence frames
      in the single rate operation mode) transmitted at the end of
      active speech but before DTX actions begin.  When setting up an
      RTP session that uses DTX, an RTP receiver can use this parameter
      to signal the number of 1/8 rate frames (or silence frames in the
      single rate operation mode) that SHOULD be transmitted by the RTP
      sender prior to beginning DTX actions.  If this parameter is not
      present for a session that uses DTX, the default value SHOULD be



Xie & Kapoor             Expires March 27, 2006                 [Page 8]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


      assumed.  This parameter MUST be ignored if silence suppression
      using DTX is not used for the session.  [Editor's note: Default
      value is 2 and will be specified in a 3GPP2 TSG-C 1.1 document.]

   Additionally, the RTP marker (M) bit MUST be used by the RTP senders
   to indicate that a DTX interval may begin.  The marker bit may be
   used by RTP receivers in order to assist in managing the play-out
   buffers.  In particular, the M bit MUST be set to '1' to indicate
   that discontinuous transmission may begin with the next packet and
   MUST be set to '0' otherwise.  [Editor's note: This is still very
   confusing.  There is no specific behavior of the receiver being
   requested here.  Either this will be clarified in the following
   revisions or this para will be removed.]

5.4  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 ("EVRCB", "EVRC1", 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 "evrcfixedrate" (for subtypes EVRC1 and
      EVRCB1) goes in "a=fmtp" attribute by copying it directly from the
      MIME media type string as "evrcfixedrate=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 EVRCB:

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

   Example of usage of EVRC1:





Xie & Kapoor             Expires March 27, 2006                 [Page 9]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


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

   Example of usage of EVRCB1:

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

   Example of usage of EVRC1 with DTX:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC1/8000
     a=fmtp:97 evrcfixedrate=0.5
     a=fmtp:97 silencesupp=1 dtxmax=50 dtxmin=8 hangover=2
     a=maxptime:120


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

6.  Security Considerations

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

7.  References

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



Xie & Kapoor             Expires March 27, 2006                [Page 10]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


        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.

7.2  Informative References

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

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


Authors' Addresses

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

   Phone: +1-847-632-3028
   Email: qxie1@email.mot.com


   Rohit Kapoor
   Qualcomm Inc.
   US

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




Xie & Kapoor             Expires March 27, 2006                [Page 11]

Internet-Draft        EVRC RTP Format Enhancements        September 2005


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


Acknowledgment

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




Xie & Kapoor             Expires March 27, 2006                [Page 12]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/