Network Working Group                                         A. Sollaud
Internet-Draft                                            France Telecom
Updates: 4749 (if approved)                             December 8, 2008
Intended status: Standards Track
Expires: June 11, 2009


             G.729.1 RTP Payload Format update: DTX support
                  draft-ietf-avt-rfc4749-dtx-update-03

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 June 11, 2009.

Abstract

   This document updates the Real-time Transport Protocol (RTP) payload
   format to be used for the International Telecommunication Union
   (ITU-T) Recommendation G.729.1 audio codec.  It adds Discontinuous
   Transmission (DTX) support to the RFC 4749 specification, in a
   backward-compatible way.  An updated media type registration is
   included for this payload format.








Sollaud                   Expires June 11, 2009                 [Page 1]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  RTP Header Usage  . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Payload Format  . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Payload Format Parameters . . . . . . . . . . . . . . . . . . . 5
     5.1.  Media Type Registration Update  . . . . . . . . . . . . . . 5
     5.2.  Mapping to SDP Parameters . . . . . . . . . . . . . . . . . 5
       5.2.1.  DTX Offer-Answer Model Considerations . . . . . . . . . 6
       5.2.2.  DTX Declarative SDP Considerations  . . . . . . . . . . 7
   6.  Congestion Control  . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
































Sollaud                   Expires June 11, 2009                 [Page 2]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


.  Introduction

   The International Telecommunication Union (ITU-T) Recommendation
   G.729.1 [ITU-G.729.1] is a scalable and wideband extension of the
   Recommendation G.729 [ITU-G.729] audio codec.  [RFC4749] specifies
   the payload format for packetization of G.729.1 encoded audio signals
   into the Real-time Transport Protocol (RTP) [RFC3550].

   The Annex C of G.729.1 [ITU-G.729.1-C] adds Discontinuous
   Transmission (DTX) support to G.729.1.  This document updates the RTP
   payload format to allow usage of this Annex.

   Only changes or additions to [RFC4749] will be described in the
   following sections.

   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 described in [RFC2119].


.  Background

   G.729.1 supports Discontinuous Transmission (DTX), a.k.a. "silence
   suppression".  It means that the coder includes a Voice Activity
   Detection (VAD) algorithm, to determine if an audio frame contains
   silence or actual audio.  During silence periods, the coder may
   significantly decrease the transmitted bit rate by sending a small
   frame called Silence Insertion Descriptor (SID), and then stop
   transmission.  The receiver's decoder will generate comfort noise
   (CNG) according to the parameters contained in the SID.  This DTX/CNG
   scheme is specified in [ITU-G.729.1-C].

   G.729.1 SID has an embedded structure.  The core SID is the same as
   the legacy G.729 SID [ITU-G.729-B].  A first enhancement layer adds
   some parameters for narrowband comfort noise, while a second
   enhancement layer adds wideband information.  G.729.1 SID can be 2,
   3, or 6 octets long.


.  RTP Header Usage

   The fields of the RTP header must be used as described in [RFC4749],
   except for the Marker (M) bit.

   If DTX is used, the first packet of a talkspurt, that is, the first
   packet after a silence period during which packets have not been
   transmitted contiguously, MUST be distinguished by setting the M bit
   in the RTP data header to one.  The M bit in all other packets MUST



Sollaud                   Expires June 11, 2009                 [Page 3]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


   be set to zero.  The beginning of a talkspurt MAY be used to adjust
   the playout delay to reflect changing network delays.

   If DTX is not used, the M bit MUST be set to zero in all packets.


.  Payload Format

   The payload format is the same as in [RFC4749], with the option to
   add a SID at the end.

   So the complete payload consists of a payload header of 1 octet (MBS
   and FT fields), followed by zero or more consecutive audio frames at
   the same bit rate, followed by zero or one SID.

      Note that it is consistent with the payload format of G.729
      described in section 4.5.6 of [RFC3551].

   To be able to transport a SID alone, that is, without actual audio
   frames, we assign the FT value 14 to SID.  When using FT=14, only a
   single SID frame SHALL be included in the payload.  The actual SID
   size (2, 3, or 6 octets) is inferred from the payload size: it is the
   size of what is left after the payload header.

   When a SID is appended to actual audio frames, the FT value remains
   the one describing the encoding rate of the audio frames.  Since the
   SID is much smaller than any other frame, it can be easily detected
   at the receiver side, and it will not hinder the calculation of the
   number of frames.  The actual SID size is inferred from the payload
   size: it is the size of what is left after the audio frames.

   Section 5.4 of [RFC4749] mandates to ignore the remainging bytes
   after complete frames.  This document overrides this statement: the
   receiver of the payload must consider these remainging bytes as a SID
   frame.  If the size of this remainder is not a valid SID frame size
   (2, 3, or 6 octets), the receiver MUST ignore these bytes.

   The full FT table is given for convenience:













Sollaud                   Expires June 11, 2009                 [Page 4]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


               +-------+---------------+-------------------+
               |   FT  | encoding rate |     frame size    |
               +-------+---------------+-------------------+
               |   0   |     8 kbps    |     20 octets     |
               |   1   |    12 kbps    |     30 octets     |
               |   2   |    14 kbps    |     35 octets     |
               |   3   |    16 kbps    |     40 octets     |
               |   4   |    18 kbps    |     45 octets     |
               |   5   |    20 kbps    |     50 octets     |
               |   6   |    22 kbps    |     55 octets     |
               |   7   |    24 kbps    |     60 octets     |
               |   8   |    26 kbps    |     65 octets     |
               |   9   |    28 kbps    |     70 octets     |
               |   10  |    30 kbps    |     75 octets     |
               |   11  |    32 kbps    |     80 octets     |
               | 12-13 |   (reserved)  |         -         |
               |   14  |      SID      | 2, 3, or 6 octets |
               |   15  |    NO_DATA    |         0         |
               +-------+---------------+-------------------+

   DTX has no impact on the MBS definition and use.


.  Payload Format Parameters

   Parameters defined in [RFC4749] are not modified.  We add a new
   optional parameter to configure DTX.

5.1.  Media Type Registration Update

   We add a new optional parameter to the audio/G7291 media subtype:

   dtx:  indicates that discontinuous transmission (DTX) is used or
      preferred.  Permissible values are 0 and 1. 0 means no DTX. 1
      means DTX support, as described in Annex C of ITU-T Recommendation
      G.729.1. 0 is implied if this parameter is omitted.

   When DTX is turned off, the RTP payload MUST NOT contain SID, and the
   FT value 14 MUST NOT be used.

5.2.  Mapping to SDP Parameters

   The information carried in the media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [RFC4566], which is commonly used to describe RTP sessions.

   The mapping described in [RFC4749] remains unchanged.




Sollaud                   Expires June 11, 2009                 [Page 5]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


   The "dtx" parameter goes in the SDP "a=fmtp" attribute.

   Some example partial SDP session descriptions utilizing G.729.1
   encodings follow.

   Example 1: default parameters (DTX off)

      m=audio 57586 RTP/AVP 96
      a=rtpmap:96 G7291/16000

   Example 2: recommended packet duration of 40 ms (=2 frames), maximum
   bit rate is 20 kbps, DTX supported and preferred.

      m=audio 49987 RTP/AVP 97
      a=rtpmap:97 G7291/16000
      a=fmtp:97 maxbitrate=20000; dtx=1
      a=ptime:40

5.2.1.  DTX Offer-Answer Model Considerations

   The offer-answer model considerations of [RFC4749] fully apply.  In
   this section we only define the management of the "dtx" parameter.

   The "dtx" parameter concerns both sending and receiving, so both
   sides of a bi-directional session MUST have the same DTX setting.  If
   one party indicates it does not support DTX, DTX must be deactivated
   both ways.  In other words, DTX is actually activated if, and only
   if, "dtx=1" in the offer and in the answer.

   A special rule applies for multicast: the "dtx" parameter becomes
   declarative and MUST NOT be negotiated.  This parameter is fixed, and
   a participant MUST use the configuration that is provided for the
   session.

   A RTP receiver compliant with only RFC 4749 and not this
   specification will ignore the "dtx" parameter and will not include it
   in its answer, so DTX will not be activated in this case.  As a
   remark, if that happened, this kind of receiver would not be confused
   by a RTP stream with DTX because RFC 4749 requires to ignore the
   bytes that are now used for SID frames.  But during silence period,
   the receiver would then react using packet loss concealment instead
   of comfort noise generation, leading to bad audio quality.  This
   justifies the use of the "dtx" parameter, even if the payload format
   is backward compatible at the binary level.







Sollaud                   Expires June 11, 2009                 [Page 6]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


5.2.2.  DTX Declarative SDP Considerations

   The "dtx" parameter is declarative and provides the parameter that
   SHALL be used when receiving and/or sending the configured stream.


.  Congestion Control

   The congestion control considerations of [RFC4749] apply.

   The use of DTX can help congestion control by reducing the number of
   transmitted RTP packets and the average bandwidth of audio streams.


.  Security Considerations

   The security considerations of [RFC4749] apply.

   By observing the RTP flow with DTX, an attacker could see when and
   how long people are speaking.  This is a general fact for DTX, and
   G.729.1 DTX introduces no new specific issue.


.  IANA Considerations

   It is requested that one new optional parameter for media subtype
   (audio/G7291) is registered by IANA, see Section 5.1.


.  References

9.1.  Normative References

   [ITU-G.729.1]
              International Telecommunications Union, "G.729 based
              Embedded Variable bit-rate coder: An 8-32 kbit/s scalable
              wideband coder bitstream interoperable with G.729", ITU-
              T Recommendation G.729.1, May 2006.

   [ITU-G.729.1-C]
              International Telecommunications Union, "G.729.1 DTX/CNG
              scheme", ITU-T Recommendation G.729.1 Annex C, May 2008.

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time



Sollaud                   Expires June 11, 2009                 [Page 7]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


              Applications", STD 64, RFC 3550, July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4749]  Sollaud, A., "RTP Payload Format for the G.729.1 Audio
              Codec", RFC 4749, October 2006.

9.2.  Informative References

   [ITU-G.729]
              International Telecommunications Union, "Coding of speech
              at 8 kbit/s using conjugate-structure algebraic-code-
              excited linear-prediction (CS-ACELP)", ITU-
              T Recommendation G.729, March 1996.

   [ITU-G.729-B]
              International Telecommunications Union, "A silence
              compression scheme for G.729 optimized for terminals
              conforming to Recommendation V.70", ITU-T Recommendation
              G.729 Annex B, October 1996.

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


Author's Address

   Aurelien Sollaud
   France Telecom
   2 avenue Pierre Marzin
   Lannion Cedex  22307
   France

   Phone: +33 2 96 05 15 06
   Email: aurelien.sollaud@orange-ftgroup.com














Sollaud                   Expires June 11, 2009                 [Page 8]

 
Internet-Draft         G.729.1 DTX support in RTP          December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.


Intellectual Property

   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.











Sollaud                   Expires June 11, 2009                 [Page 9]