draft-ietf-avt-rtp-g729-scal-wb-ext-01.txt   draft-ietf-avt-rtp-g729-scal-wb-ext-02.txt 
Network Working Group A. Sollaud Network Working Group A. Sollaud
Internet-Draft France Telecom Internet-Draft France Telecom
Expires: July 22, 2006 January 18, 2006 Expires: August 19, 2006 February 15, 2006
RTP payload format for the future scalable and wideband extension of RTP payload format for the G.729EV audio codec
G.729 audio codec draft-ietf-avt-rtp-g729-scal-wb-ext-02
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 33
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 July 22, 2006. This Internet-Draft will expire on August 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 International Telecommunication Union
the International Telecommunication Union (ITU-T) G.729 audio codec. (ITU-T) G.729EV audio codec. A media type registration is included
A media type registration is included for this payload format. for this payload format.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4 3. Embedded bit rates considerations . . . . . . . . . . . . . . 4
4. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 4 4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 5 5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5
4.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 6 5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 5
4.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 6
5. Payload format parameters . . . . . . . . . . . . . . . . . . 7 5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Media type registration . . . . . . . . . . . . . . . . . 7 6. Payload format parameters . . . . . . . . . . . . . . . . . . 8
5.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9 6.1. Media type registration . . . . . . . . . . . . . . . . . 8
5.3. Offer-answer model considerations . . . . . . . . . . . . 9 6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9
6. Security considerations . . . . . . . . . . . . . . . . . . . 10 6.3. Offer-answer model considerations . . . . . . . . . . . . 10
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Normative references . . . . . . . . . . . . . . . . . . . 11 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative references . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 10.2. Informative references . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) is working on a The International Telecommunication Union (ITU-T) recommendation
scalable and wideband extension of its recommendation G.729 [6]. G.729EV [1] is a scalable and wideband extension of the
This future audio codec will be called G.729EV in the following text. recommendation G.729 [7] audio codec. This document specifies the
This document specifies the payload format for packetization of payload format for packetization of G.729EV encoded audio signals
G.729EV encoded audio signals into the real-time transport protocol into the real-time transport protocol (RTP).
(RTP).
The payload format itself and the handling of variable bit rate are The payload format itself is described in Section 5. A media type
described in Section 4. A media type registration and the details registration and the details for the use of G.729EV with SDP are
for the use of G.729EV with SDP are given in Section 5. given in Section 6.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [2].
2. Background 2. Background
G.729EV is mainly designed to be used as a speech codec, but it can G.729EV is mainly designed to be used as a speech codec, but it can
be used for music at the highest bit rates. The sampling frequency be used for music at the highest bit rates. The sampling frequency
is 16000 Hz and the frame size is 20 ms. is 16000 Hz and the frame size is 20 ms.
This G.729-based codec produces an embedded bitstream providing an This G.729-based codec produces an embedded bitstream providing an
improved narrow band quality [300, 3400 Hz] at 12 kbps, and an improved narrow band quality [300, 3400 Hz] at 12 kbps, and an
enhanced and gracefully improving wideband quality [50, 7000 Hz] from enhanced and gracefully improving wideband quality [50, 7000 Hz] from
skipping to change at page 4, line 25 skipping to change at page 4, line 24
insertion descriptors (SID). The receiver's decoder will generate insertion descriptors (SID). The receiver's decoder will generate
comfort noise according to the SID information. This operation of comfort noise according to the SID information. This operation of
sending low bit rate comfort noise parameters during silence periods sending low bit rate comfort noise parameters during silence periods
is usually called discontinuous transmission (DTX). is usually called discontinuous transmission (DTX).
G.729EV will be first released without support for DTX. Anyway, this G.729EV will be first released without support for DTX. Anyway, this
functionality is planned and will be defined in a separate annex functionality is planned and will be defined in a separate annex
later. Thus this specification provides DTX signalling, even if the later. Thus this specification provides DTX signalling, even if the
size of a SID frame is not yet standardized. size of a SID frame is not yet standardized.
3. RTP header usage 3. Embedded bit rates considerations
The format of the RTP header is specified in RFC 3550 [2]. This The embedded property of G.729EV streams provides a mechanism to
adjust the bandwidth demand. At any time, a sender can change its
sending bit rate without an external signalling, and the receiver
will be able to properly decode the frames. It may help to control
congestion, since the bandwidth can be adjusted by selecting another
bit rate.
It may also help to share a fixed bandwidth dedicated to voice calls,
for example in a residential or trunking gateway. In that case, the
system can change the bit rates depending on the number of
simultaneous calls. Since it only impacts the sending bandwidth, we
introduce an in-band signalling to request the other party to change
its own sending bit rate, in order to adjust the receiving bandwidth
as well. This in-band request is called MBS, for Maximum Bit rate
Supported, and is described in the following payload format (see
Section 5.2). Note that it is only useful for two-way G.729EV
traffic, since the MBS request is piggy-backed over the speech frames
in the reverse direction.
4. RTP header usage
The format of the RTP header is specified in RFC 3550 [3]. This
payload format uses the fields of the header in a manner consistent payload format uses the fields of the header in a manner consistent
with that specification. with that specification.
The RTP timestamp clock frequency is the same as the sampling The RTP timestamp clock frequency is the same as the sampling
frequency, that is 16 kHz. So the timestamp unit is in samples. frequency, that is 16 kHz. So the timestamp unit is in samples.
The duration of one frame is 20 ms, corresponding to 320 samples per The duration of one frame is 20 ms, corresponding to 320 samples per
frame. Thus the timestamp is increased by 320 for each consecutive frame. Thus the timestamp is increased by 320 for each consecutive
frame. frame.
The M bit should be set as specified in the applicable RTP profile, If DTX is used, the first packet of a talkspurt, that is, the first
for example, RFC 3551 [3]. packet after a silence period during which packets have not been
transmitted contiguously, SHOULD be distinguished by setting the
marker bit (M) in the RTP data header to one. The marker bit in all
other packets is 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.
The assignment of an RTP payload type for this packet format is The assignment of an RTP payload type for this packet format is
outside the scope of the document, and will not be specified here. outside the scope of the document, and will not be specified here.
It is expected that the RTP profile under which this payload format It is expected that the RTP profile under which this payload format
is being used will assign a payload type for this codec or specify is being used will assign a payload type for this codec or specify
that the payload type is to be bound dynamically (see Section 5.2). that the payload type is to be bound dynamically (see Section 6.2).
4. Payload format 5. Payload format
4.1. Payload structure 5.1. Payload structure
The complete payload consists of a payload header of 1 octet, The complete payload consists of a payload header of 1 octet,
followed by audio data representing one or more consecutive frames at followed by audio data representing one or more consecutive frames at
the same bit rate. the same bit rate.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBS | FT | | | MBS | FT | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
: one ore more frames at the same bit rate : : one ore more frames at the same bit rate :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Payload Header: MBS field 5.2. Payload Header: MBS field
MBS (4 bits): maximum bit rate supported. Indicates a maximum bit MBS (4 bits): maximum bit rate supported. Indicates a maximum bit
rate to the encoder at the site of the receiver of this payload. The rate to the encoder at the site of the receiver of this payload. The
value of the MBS field is set according to the following table: value of the MBS field is set according to the following table:
+-------+--------------+ +-------+--------------+
| MBS | max bit rate | | MBS | max bit rate |
+-------+--------------+ +-------+--------------+
| 0 | 8 kbps | | 0 | 8 kbps |
| 1 | 12 kbps | | 1 | 12 kbps |
skipping to change at page 6, line 19 skipping to change at page 6, line 47
Note that the MBS is a codec bit rate, the actual network bit rate is Note that the MBS is a codec bit rate, the actual network bit rate is
higher and depends on the overhead of the underlying protocols. higher and depends on the overhead of the underlying protocols.
The MBS field MUST be set to 15 for packets sent to a multicast The MBS field MUST be set to 15 for packets sent to a multicast
group. group.
The MBS field MUST be set to 15 in all packets when the actual MBS The MBS field MUST be set to 15 in all packets when the actual MBS
value is sent through non-RTP means. This is out of the scope of value is sent through non-RTP means. This is out of the scope of
this specification. this specification.
4.3. Payload Header: FT field 5.3. Payload Header: FT field
FT (4 bits): Frame type of the frame(s) in this packet, as per the FT (4 bits): Frame type of the frame(s) in this packet, as per the
following table: following table:
+-------+---------------+------------+ +-------+---------------+------------+
| FT | encoding rate | frame size | | FT | encoding rate | frame size |
+-------+---------------+------------+ +-------+---------------+------------+
| 0 | 8 kbps | 20 octets | | 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets | | 1 | 12 kbps | 30 octets |
| 2 | 14 kbps | 35 octets | | 2 | 14 kbps | 35 octets |
skipping to change at page 7, line 5 skipping to change at page 7, line 32
+-------+---------------+------------+ +-------+---------------+------------+
The FT value 15 (NO_DATA) indicates that there is no audio data in The FT value 15 (NO_DATA) indicates that there is no audio data in
the payload. This MAY be used to update the MBS value when there is the payload. This MAY be used to update the MBS value when there is
no audio frame to transmit. The payload will then be reduced to the no audio frame to transmit. The payload will then be reduced to the
payload header. payload header.
If a payload with an invalid FT value is received, the whole payload If a payload with an invalid FT value is received, the whole payload
MUST be ignored. MUST be ignored.
4.4. Audio data 5.4. Audio data
Audio data of a payload contains one or more consecutive audio frames Audio data of a payload contains one or more consecutive audio frames
at the same bit rate. The audio frames are packed in order of time, at the same bit rate. The audio frames are packed in order of time,
that is the older first. that is the older first.
The actual number of frame is easy to infer from the size of the The actual number of frame is easy to infer from the size of the
audio data part: audio data part:
nb_frames = (size_of_audio_data) / (size_of_one_frame). nb_frames = (size_of_audio_data) / (size_of_one_frame).
This is compatible with DTX, with the restriction that the SID frame This is compatible with DTX, with the restriction that the SID frame
MUST be at the end of the payload (it is consistent with the payload MUST be at the end of the payload (it is consistent with the payload
format of G.729 described in section 4.5.6 of RFC 3551 [3]). Since format of G.729 described in section 4.5.6 of RFC 3551 [4]). Since
the SID frame is much smaller than any other frame, it will not the SID frame is much smaller than any other frame, it will not
hinder the calculation of the number of frames at the receiver side hinder the calculation of the number of frames at the receiver side
and can be easily detected. Actually the presence of a SID frame and can be easily detected. Actually the presence of a SID frame
will be inferred by the result of the above division not being an will be inferred by the result of the above division not being an
integer. integer.
Note that if FT=15, there will be no audio frame in the payload. Note that if FT=15, there will be no audio frame in the payload.
5. Payload format parameters 6. Payload format parameters
This section defines the parameters that may be used to configure This section defines the parameters that may be used to configure
optional features in the G.729EV RTP transmission. optional features in the G.729EV RTP transmission.
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) [5] 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 6.1. Media type registration
This registration is done using the template defined in RFC 4288 [7] This registration is done using the template defined in RFC 4288 [8]
and following RFC 3555 [8]. and following RFC 3555 [9].
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.
maxbitrate: the absolute maximum codec bit rate for the session. maxbitrate: the absolute maximum codec bit rate for the session.
Permissible values are between 0 and 11 (see table in Section 4.2 Permissible values are between 0 and 11 (see table in Section 5.2
of RFC XXXX). 11 is implied if this parameter is omitted. The of RFC XXXX). 11 is implied if this parameter is omitted. The
maxbitrate restricts the range of bit rates which can be used. maxbitrate restricts the range of bit rates which can be used.
Frames bit rate (FT) and MBS MUST NOT exceed this value. Frames bit rate (FT) and MBS MUST NOT exceed this value.
mbs: the initial value of MBS, that is the current maximum codec bit mbs: the initial value of MBS, that is the current maximum codec bit
rate supported as a receiver. Permissible values are between 0 rate supported as a receiver. Permissible values are between 0
and maxbitrate (see table in Section 4.2 of RFC XXXX). The and maxbitrate (see table in Section 5.2 of RFC XXXX). The
maximum MBS value is implied if this parameter is omitted. Note maximum MBS value is implied if this parameter is omitted. Note
that this parameter will be dynamically updated by the MBS field that this parameter will be dynamically updated by the MBS field
of the RTP packets sent, it is not an absolute value for the 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 Section 6 of RFC 2327 [5].
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. See Section 8 of RFC 3267 [10]
Encoding considerations: This media type is framed and contains Encoding considerations: This media type is framed and contains
binary data. binary data, see section 4.8 of RFC 4288 [8].
Security considerations: See Section 6 of RFC XXXX Security considerations: See Section 8 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: Audio and video conferencing Applications which use this media type: Audio and video conferencing
tools. tools.
Additional information: none Additional information: none
Person & email address to contact for further information: Aurelien Person & email address to contact for further information: Aurelien
Sollaud, aurelien.sollaud@francetelecom.com Sollaud, aurelien.sollaud@francetelecom.com
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [2]. hence is only defined for transfer via RTP [3].
Author/Change controller: IETF Audio/Video Transport working group Author: Aurelien Sollaud
delegated from the IESG
5.2. Mapping to SDP parameters Change controller: IETF Audio/Video Transport working group delegated
from the IESG
6.2. Mapping to SDP parameters
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[4], which is commonly used to describe RTP sessions. When SDP is [5], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the G.729EV codec, the mapping is used to specify sessions employing the G.729EV codec, the mapping is
as follows: as follows:
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("G729EV") goes in SDP "a=rtpmap" as the o The media subtype ("G729EV") goes in SDP "a=rtpmap" as the
encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for
G.729EV. G.729EV.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
skipping to change at page 9, line 46 skipping to change at page 10, line 28
a=rtpmap:98 G729EV/16000 a=rtpmap:98 G729EV/16000
Example 2: recommended packet duration of 40 ms (=2 frames), DTX off, Example 2: recommended packet duration of 40 ms (=2 frames), DTX off,
and initial MBS set to 26 kbps and initial MBS set to 26 kbps
m=audio 51258 RTP/AVP 99 m=audio 51258 RTP/AVP 99
a=rtpmap:99 G729EV/16000 a=rtpmap:99 G729EV/16000
a=fmtp:99 dtx=0; mbs=8 a=fmtp:99 dtx=0; mbs=8
a=ptime:40 a=ptime:40
5.3. Offer-answer model considerations 6.3. Offer-answer model considerations
The following considerations apply when using SDP offer-answer The following considerations apply when using SDP offer-answer
procedures to negotiate the use of G.729EV payload in RTP: procedures to negotiate the use of G.729EV payload in RTP:
o Since G.729EV is an extension of G.729, the offerer SHOULD o Since G.729EV is an extension of G.729, the offerer SHOULD
announce G.729 support in its "m=audio" line, with G.729EV announce G.729 support in its "m=audio" line, with G.729EV
preferred. This will allow interoperability with both G.729EV and preferred. This will allow interoperability with both G.729EV and
G.729-only capable parties. G.729-only capable parties.
Below is an example of such an offer: Below is an example of such an offer:
m=audio 55954 RTP/AVP 98 18 m=audio 55954 RTP/AVP 98 18
a=rtpmap:98 G729EV/16000 a=rtpmap:98 G729EV/16000
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
If the answerer supports G.729EV, it will keep the payload type 98 If the answerer supports G.729EV, it will keep the payload type 98
in its answer and the conversation will be done using G.729EV. in its answer and the conversation will be done using G.729EV.
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]). [4]).
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 o The "maxbitrate" parameter is bi-directional. If the offerer sets
a maxbitrate value, the answerer MUST reply with a smaller or a maxbitrate value, the answerer MUST reply with a smaller or
equal value. The actual maximum bit rate for the session will be equal value. The actual maximum bit rate for the session will be
the minimum. 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 [6]. The "maxptime"
parameter MUST be handled in the same way. parameter MUST be handled in the same way.
6. Security considerations Some special rules apply for mono-directional traffic:
o For sendonly streams, the "mbs" parameter is useless and SHOULD
NOT be used.
o For recvonly streams, the "mbs" parameter is the only way to
communicate the MBS to the sender, since there is no RTP stream
towards it. So to request a bit rate change, the receiver will
need to use an out-of-band mechanism, like a SIP RE-INIVTE.
Some special rules apply for multicast:
o The "mbs" parameter is useless and SHOULD NOT be used.
o The "maxbitrate" and "dtx" parameter become declarative and MUST
NOT be negotiated. These parameters are fixed, and a participant
MUST use the configuration that is provided for the session.
7. Congestion control
Congestion control for RTP SHALL be used in accordance with RFC 3550
[3] and any appropriate profile (for example, RFC 3551 [4]). The
embedded and variable bit rates capability of G.729EV provides a
mechanism that may help to control congestion, see Section 3.
The number of frames encapsulated in each RTP payload influences the
overall bandwidth of the RTP stream, due to the header overhead.
Packing more frames in each RTP payload can reduce the number of
packets sent and hence the header overhead, at the expense of
increased delay and reduced error robustness.
8. Security considerations
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 [3] and any appropriate profile (for example, RFC
3551 [3]). 3551 [4]).
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, integrity protection, and
itself. The payload format itself does not have any built-in authentication of the speech/audio itself. The payload format itself
security mechanisms. Confidentiality of the media streams is does not have any built-in security mechanisms. Any suitable
achieved by encryption, therefore external mechanisms, such as SRTP external mechanisms, such as SRTP [11], MAY be used.
[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 9. 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 6.1.
8. References 10. References
8.1. Normative references 10.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] International Telecommunications Union, "TBD", ITU-
T Recommendation TBD, 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [4] 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 [5] 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 [6] 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.
8.2. Informative references 10.2. Informative references
[6] International Telecommunications Union, "Coding of speech at 8 [7] 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.
[7] Freed, N. and J. Klensin, "Media Type Specifications and [8] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [9] 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. [10] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-
Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. 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
 End of changes. 52 change blocks. 
87 lines changed or deleted 154 lines changed or added

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