draft-ietf-avt-rtp-g729-scal-wb-ext-00.txt   draft-ietf-avt-rtp-g729-scal-wb-ext-01.txt 
Network Working Group A. Sollaud Network Working Group A. Sollaud
Internet-Draft France Telecom Internet-Draft France Telecom
Expires: June 8, 2006 December 05, 2005 Expires: July 22, 2006 January 18, 2006
RTP payload format for the future scalable and wideband extension of RTP payload format for the future scalable and wideband extension of
G.729 audio codec G.729 audio codec
draft-ietf-avt-rtp-g729-scal-wb-ext-00 draft-ietf-avt-rtp-g729-scal-wb-ext-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 8, 2006. This Internet-Draft will expire on July 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a real-time transport protocol (RTP) payload This document specifies a real-time transport protocol (RTP) payload
format to be used for the future scalable and wideband extension of format to be used for the future scalable and wideband extension of
the International Telecommunication Union (ITU-T) G.729 audio codec. the International Telecommunication Union (ITU-T) G.729 audio codec.
A media type registration is included for this payload format. A media type registration is included for this payload format.
Table of Contents Table of Contents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
4.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Payload format parameters . . . . . . . . . . . . . . . . . . 7 5. Payload format parameters . . . . . . . . . . . . . . . . . . 7
5.1. Media type registration . . . . . . . . . . . . . . . . . 7 5.1. Media type registration . . . . . . . . . . . . . . . . . 7
5.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9 5.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9
5.3. Offer-answer model considerations . . . . . . . . . . . . 9 5.3. Offer-answer model considerations . . . . . . . . . . . . 9
6. Security considerations . . . . . . . . . . . . . . . . . . . 10 6. Security considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative references . . . . . . . . . . . . . . . . . . . 11 8.1. Normative references . . . . . . . . . . . . . . . . . . . 11
8.2. Informative references . . . . . . . . . . . . . . . . . . 11 8.2. Informative references . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) is working on a The International Telecommunication Union (ITU-T) is working on a
scalable and wideband extension of its recommendation G.729 [7]. scalable and wideband extension of its recommendation G.729 [6].
This future audio codec will be called G.729EV in the following text. This future audio codec will be called G.729EV in the following text.
This document specifies the payload format for packetization of This document specifies the payload format for packetization of
G.729EV encoded audio signals into the real-time transport protocol G.729EV encoded audio signals into the real-time transport protocol
(RTP). (RTP).
The payload format itself and the handling of variable bit rate are The payload format itself and the handling of variable bit rate are
described in Section 4. A media type registration and the details described in Section 4. A media type registration and the details
for the use of G.729EV with SDP are given in Section 5. for the use of G.729EV with SDP are given in Section 5.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 41 skipping to change at page 7, line 41
The parameters are defined here as part of the media subtype The parameters are defined here as part of the media subtype
registration for the G.729EV codec. A mapping of the parameters into registration for the G.729EV codec. A mapping of the parameters into
the Session Description Protocol (SDP) [4] is also provided for those the Session Description Protocol (SDP) [4] is also provided for those
applications that use SDP. In control protocols that do not use MIME applications that use SDP. In control protocols that do not use MIME
or SDP, the media type parameters must be mapped to the appropriate or SDP, the media type parameters must be mapped to the appropriate
format used with that control protocol. format used with that control protocol.
5.1. Media type registration 5.1. Media type registration
This registration is done using the template defined in [8] and This registration is done using the template defined in RFC 4288 [7]
following RFC 3555 [9] and following RFC 3555 [8].
Type name: audio Type name: audio
Subtype name: G729EV Subtype name: G729EV
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
dtx: indicates that discontinuous transmission (DTX) is used or dtx: indicates that discontinuous transmission (DTX) is used or
preferred. DTX means voice activity detection and non preferred. DTX means voice activity detection and non
transmission of silent frames. Permissible values are 0 and 1. 0 transmission of silent frames. Permissible values are 0 and 1. 0
means no DTX. 0 is implied if this parameter is omitted. The means no DTX. 0 is implied if this parameter is omitted. The
first version of G.729EV will not support DTX. first version of G.729EV will not support DTX.
mbs: indicates an initial value of MBS, that is the current maximum maxbitrate: the absolute maximum codec bit rate for the session.
codec bit rate supported as a receiver. Permissible values are Permissible values are between 0 and 11 (see table in Section 4.2
between 0 and 11 (see table in Section 4.2 of RFC XXXX). The of RFC XXXX). 11 is implied if this parameter is omitted. The
maximum MBS, that is 11, is implied if this parameter is omitted. maxbitrate restricts the range of bit rates which can be used.
Note that this parameter will be dynamically updated by the MBS Frames bit rate (FT) and MBS MUST NOT exceed this value.
field of the RTP packets sent, it is not an absolute value for the
mbs: the initial value of MBS, that is the current maximum codec bit
rate supported as a receiver. Permissible values are between 0
and maxbitrate (see table in Section 4.2 of RFC XXXX). The
maximum MBS value is implied if this parameter is omitted. Note
that this parameter will be dynamically updated by the MBS field
of the RTP packets sent, it is not an absolute value for the
session. The goal is to announce this value, prior to the sending session. The goal is to announce this value, prior to the sending
of any packet, to avoid the remote sender to exceed the MBS at the of any packet, to avoid the remote sender to exceed the MBS at the
beginning of the session. beginning of the session.
ptime: the recommended length of time in milliseconds represented by ptime: the recommended length of time in milliseconds represented by
the media in a packet. See RFC 2327 [4]. the media in a packet. See RFC 2327 [4].
maxptime: the maximum length of time in milliseconds which can be maxptime: the maximum length of time in milliseconds which can be
encapsulated in a packet. encapsulated in a packet.
skipping to change at page 10, line 21 skipping to change at page 10, line 28
Else, if the answerer supports only G.729, it will leave only the Else, if the answerer supports only G.729, it will leave only the
payload type 18 in its answer and the conversation will be done payload type 18 in its answer and the conversation will be done
using G.729 (the payload format for G.729 is defined in RFC 3551 using G.729 (the payload format for G.729 is defined in RFC 3551
[3]). [3]).
o The "dtx" parameter concerns both sending and receiving, so both o The "dtx" parameter concerns both sending and receiving, so both
sides of a bi-directional session MUST use the same "dtx" value. sides of a bi-directional session MUST use the same "dtx" value.
If one party indicates it does not support DTX, DTX must be If one party indicates it does not support DTX, DTX must be
deactivated both ways. deactivated both ways.
o The "maxbitrate" parameter is bi-directional. If the offerer sets
a maxbitrate value, the answerer MUST reply with a smaller or
equal value. The actual maximum bit rate for the session will be
the minimum.
o The "mbs" parameter is not symmetric. Values in the offer and the o The "mbs" parameter is not symmetric. Values in the offer and the
answer are independent and take into account local constraints. answer are independent and take into account local constraints.
Anyway, one party MUST NOT start sending frames at a bit rate Anyway, one party MUST NOT start sending frames at a bit rate
higher than the "mbs" of the other party. higher than the "mbs" of the other party.
o The parameters "ptime" and "maxptime" will in most cases not o The parameters "ptime" and "maxptime" will in most cases not
affect interoperability. The SDP offer-answer handling of the affect interoperability. The SDP offer-answer handling of the
"ptime" parameter is described in RFC 3264 [5]. The "maxptime" "ptime" parameter is described in RFC 3264 [5]. The "maxptime"
parameter MUST be handled in the same way. parameter MUST be handled in the same way.
skipping to change at page 10, line 43 skipping to change at page 11, line 7
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in the are subject to the general security considerations discussed in the
RTP specification [2] and any appropriate profile (for example, RFC RTP specification [2] and any appropriate profile (for example, RFC
3551 [3]). 3551 [3]).
As this format transports encoded speech/audio, the main security As this format transports encoded speech/audio, the main security
issues include confidentiality and authentication of the speech/audio issues include confidentiality and authentication of the speech/audio
itself. The payload format itself does not have any built-in itself. The payload format itself does not have any built-in
security mechanisms. Confidentiality of the media streams is security mechanisms. Confidentiality of the media streams is
achieved by encryption, therefore external mechanisms, such as SRTP achieved by encryption, therefore external mechanisms, such as SRTP
[6], MAY be used for that purpose. [9], MAY be used for that purpose.
This payload format and the G.729EV encoding do not exhibit any This payload format and the G.729EV encoding do not exhibit any
significant non-uniformity in the receiver-end computational load and significant non-uniformity in the receiver-end computational load and
thus in unlikely to pose a denial-of-service threat due to the thus in unlikely to pose a denial-of-service threat due to the
receipt of pathological datagrams. receipt of pathological datagrams.
7. IANA considerations 7. IANA considerations
It is requested that one new media subtype (audio/G729EV) is It is requested that one new media subtype (audio/G729EV) is
registered by IANA, see Section 5.1. registered by IANA, see Section 5.1.
skipping to change at page 11, line 30 skipping to change at page 11, line 39
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Handley, M. and V. Jacobson, "SDP: Session Description [4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
8.2. Informative references 8.2. Informative references
[7] International Telecommunications Union, "Coding of speech at 8 [6] International Telecommunications Union, "Coding of speech at 8
kbit/s using conjugate-structure algebraic-code-excited linear- kbit/s using conjugate-structure algebraic-code-excited linear-
prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[8] Freed, N. and J. Klensin, "Media Type Specifications and [7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", draft-freed-media-type-reg-05 (work in Registration Procedures", BCP 13, RFC 4288, December 2005.
progress), August 2005.
[9] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003. Payload Formats", RFC 3555, July 2003.
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Author's Address Author's Address
Aurelien Sollaud Aurelien Sollaud
France Telecom France Telecom
2 avenue Pierre Marzin 2 avenue Pierre Marzin
Lannion Cedex 22307 Lannion Cedex 22307
France France
Phone: +33 2 96 05 15 06 Phone: +33 2 96 05 15 06
Email: aurelien.sollaud@francetelecom.com Email: aurelien.sollaud@francetelecom.com
skipping to change at page 13, line 41 skipping to change at page 14, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 16 change blocks. 
26 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/