draft-ietf-avt-rtp-g729-scal-wb-ext-04.txt   draft-ietf-avt-rtp-g729-scal-wb-ext-05.txt 
Network Working Group A. Sollaud Network Working Group A. Sollaud
Internet-Draft France Telecom Internet-Draft France Telecom
Expires: October 26, 2006 April 24, 2006 Expires: November 18, 2006 May 17, 2006
RTP payload format for the G.729EV audio codec RTP payload format for the G.729.1 audio codec
draft-ietf-avt-rtp-g729-scal-wb-ext-04 draft-ietf-avt-rtp-g729-scal-wb-ext-05
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 33 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 October 26, 2006. This Internet-Draft will expire on November 18, 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 International Telecommunication Union format to be used for the International Telecommunication Union
(ITU-T) G.729EV audio codec. A media type registration is included (ITU-T) G.729.1 audio codec. 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. Embedded bit rates considerations . . . . . . . . . . . . . . 4 3. Embedded bit rates considerations . . . . . . . . . . . . . . 4
4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4 4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4
5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5 5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5
5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 6 5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 6
5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 7 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 7
5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Payload format parameters . . . . . . . . . . . . . . . . . . 8 6. Payload format parameters . . . . . . . . . . . . . . . . . . 8
6.1. Media type registration . . . . . . . . . . . . . . . . . 8 6.1. Media type registration . . . . . . . . . . . . . . . . . 8
6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 10 6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9
6.2.1. Offer-answer model considerations . . . . . . . . . . 10 6.2.1. Offer-answer model considerations . . . . . . . . . . 10
6.2.2. Declarative SDP considerations . . . . . . . . . . . . 12 6.2.2. Declarative SDP considerations . . . . . . . . . . . . 12
7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12
8. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. Security considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13
10.2. Informative references . . . . . . . . . . . . . . . . . . 14 10.2. Informative references . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) recommendation The International Telecommunication Union (ITU-T) recommendation
G.729EV [1] is a scalable and wideband extension of the G.729.1 [1] is a scalable and wideband extension of the
recommendation G.729 [9] audio codec. This document specifies the recommendation G.729 [9] audio codec. This document specifies the
payload format for packetization of G.729EV encoded audio signals payload format for packetization of G.729.1 encoded audio signals
into the real-time transport protocol (RTP). into the real-time transport protocol (RTP).
The payload format itself is described in Section 5. A media type The payload format itself is described in Section 5. A media type
registration and the details for the use of G.729EV with SDP are registration and the details for the use of G.729.1 with SDP are
given in Section 6. 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 [2]. document are to be interpreted as described in RFC 2119 [2].
2. Background 2. Background
G.729EV is a 8-32 kbps scalable wideband (50-7000 Hz) speech and G.729.1 is a 8-32 kbps scalable wideband (50-7000 Hz) speech and
audio coding algorithm interoperable with G.729, G.729 Annex A, and audio coding algorithm interoperable with G.729, G.729 Annex A, and
G.729 Annex B. It provides a standardized solution for packetized G.729 Annex B. It provides a standardized solution for packetized
voice applications that allows a smooth transition from narrowband to voice applications that allows a smooth transition from narrowband to
wideband telephony. wideband telephony.
The most important services addressed are IP telephony and The most important services addressed are IP telephony and
videoconferencing, either for enterprise corporate networks or for videoconferencing, either for enterprise corporate networks or for
mass market (like PSTN emulation over DSL or wireless access). mass market (like PSTN emulation over DSL or wireless access).
Target devices can be IP phones or other VoIP handsets, home Target devices can be IP phones or other VoIP handsets, home
gateways, media gateways, IPBX, trunking equipment, voice messaging gateways, media gateways, IPBX, trunking equipment, voice messaging
servers, etc. servers, etc.
For all those applications, the scalability feature allows to tune For all those applications, the scalability feature allows to tune
the bit rate versus quality trade-off, possibly in a dynamic way the bit rate versus quality trade-off, possibly in a dynamic way
during a session, taking into account service requirements and during a session, taking into account service requirements and
network transport constraints. network transport constraints.
The G.729EV coder produces an embedded bitstream structured in 12 The G.729.1 coder produces an embedded bitstream structured in 12
layers corresponding to 12 available bit rates between 8 and 32 kbps. layers corresponding to 12 available bit rates between 8 and 32 kbps.
The first layer, at 8 kbps, is called the core layer and is bitstream The first layer, at 8 kbps, is called the core layer and is bitstream
compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second
layer improves the narrowband quality. Upper layers provides layer improves the narrowband quality. Upper layers provides
wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps
granularity allowing graceful quality improvements. Only the core granularity allowing graceful quality improvements. Only the core
layer is mandatory to decode understandable speech, upper layers layer is mandatory to decode understandable speech, upper layers
provide quality enhancement and wideband enlargement. provide quality enhancement and wideband enlargement.
The codec operates on 20 ms frames, and the default sampling rate is The codec operates on 20 ms frames, and the default sampling rate is
skipping to change at page 4, line 16 skipping to change at page 4, line 16
Audio codecs often support voice activity detection (VAD) and comfort Audio codecs often support voice activity detection (VAD) and comfort
noise generation (CNG). During silence periods, the coder may noise generation (CNG). During silence periods, the coder may
significantly decrease the transmitted bit rate by sending only significantly decrease the transmitted bit rate by sending only
comfort noise parameters in special small frames called silence comfort noise parameters in special small frames called silence
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.729.1 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 and content of a SID frame are not yet standardized. size and content of a SID frame are not yet standardized.
3. Embedded bit rates considerations 3. Embedded bit rates considerations
The embedded property of G.729EV streams provides a mechanism to The embedded property of G.729.1 streams provides a mechanism to
adjust the bandwidth demand. At any time, a sender can change its adjust the bandwidth demand. At any time, a sender can change its
sending bit rate without an external signalling, and the receiver sending bit rate without an external signalling, and the receiver
will be able to properly decode the frames. It may help to control will be able to properly decode the frames. It may help to control
congestion, since the bandwidth can be adjusted by selecting another congestion, since the bandwidth can be adjusted by selecting another
bit rate. bit rate.
It may also help to share a fixed bandwidth dedicated to voice calls, 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 for example in a residential or trunking gateway. In that case, the
system can change the bit rates depending on the number of system can change the bit rates depending on the number of
simultaneous calls. Since it only impacts the sending bandwidth, we simultaneous calls. Since it only impacts the sending bandwidth, we
introduce an in-band signalling to request the other party to change introduce an in-band signalling to request the other party to change
its own sending bit rate, in order to adjust the receiving bandwidth 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 as well. This in-band request is called MBS, for Maximum Bit rate
Supported, is described in the following payload format (see Supported. It is described in the following payload format (see
Section 5.2). Note that it is only useful for two-way unicast Section 5.2). Note that it is only useful for two-way unicast
G.729EV traffic, because when A sends an in-band MBS to B, it is to G.729.1 traffic, because when A sends an in-band MBS to B, it is to
request B to modify its sending bit rate, that is for the stream from request B to modify its sending bit rate, that is for the stream from
B to A. If there is no G.729EV stream in the reverse direction, the B to A. If there is no G.729.1 stream in the reverse direction, the
MBS will have no effect. MBS will have no effect.
4. RTP header usage 4. RTP header usage
The format of the RTP header is specified in RFC 3550 [3]. This 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 default sampling The RTP timestamp clock frequency is the same as the default sampling
frequency, that is 16 kHz. frequency, that is 16 kHz.
G.729EV has also the capability to operate with 8 kHz sampled input/ G.729.1 has also the capability to operate with 8 kHz sampled input/
output signals at all bit rates. It does not affect the bitstream output signals at all bit rates. It does not affect the bitstream
and the decoder does not require a priori knowledge about the and the decoder does not require a priori knowledge about the
sampling rate of the original signal at the input of the encoder. sampling rate of the original signal at the input of the encoder.
Therefore, depending on the implementation and the audio acoustic Therefore, depending on the implementation and the audio acoustic
capabilities of the devices, the input of the encoder and/or the capabilities of the devices, the input of the encoder and/or the
output of the decoder can be configured at 8 kHz; however, a 16 kHz output of the decoder can be configured at 8 kHz; however, a 16 kHz
RTP clock rate MUST always be used. RTP clock rate MUST always be used.
The duration of one frame is 20 ms, corresponding to 320 samples at The duration of one frame is 20 ms, corresponding to 320 samples at
16 kHz. Thus the timestamp is increased by 320 for each consecutive 16 kHz. Thus the timestamp is increased by 320 for each consecutive
skipping to change at page 7, line 52 skipping to change at page 7, line 52
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 size of one frame is given by the FT field, as per the table in The size of one frame is given by the FT field, as per the table in
Section 5.3, and the actual number of frame is easy to infer from the Section 5.3, and the actual number of frame is easy to infer from the
size of the audio data part: size of the 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
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 [4]). Since
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
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
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.
6. 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.729.1 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.729.1 codec. A mapping of the parameters into
the Session Description Protocol (SDP) [5] 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.
6.1. Media type registration 6.1. Media type registration
[Note to RFC Editor: Please replace all occurrences of RFC XXXX by [Note to RFC Editor: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document, and all references to RFC the RFC number assigned to this document, and all references to RFC
YYYY with the RFC number that will be assigned to the latest SDP YYYY with the RFC number that will be assigned to the latest SDP
specification [5]] specification [5]]
This registration is done using the template defined in RFC 4288 [6] This registration is done using the template defined in RFC 4288 [6]
and following RFC 3555 [7]. and following RFC 3555 [7].
Type name: audio Type name: audio
Subtype name: G729EV Subtype name: G7291
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, but future annexes first version of G.729.1 will not support DTX, but future annexes
are expected to add DTX support which can be signalled using this are expected to add DTX support which can be signalled using this
parameter. parameter.
maxbitrate: the absolute maximum codec bit rate for the session, in maxbitrate: the absolute maximum codec bit rate for the session, in
bits per second. Permissible values are 8000, 12000, 14000, bits per second. Permissible values are 8000, 12000, 14000,
16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000.
32000 is implied if this parameter is omitted. The maxbitrate 32000 is implied if this parameter is omitted. The maxbitrate
restricts the range of bit rates which can be used. The bit rates restricts the range of bit rates which can be used. The bit rates
indicated by FT and MBS fields in the RTP packets MUST NOT exceed indicated by FT and MBS fields in the RTP packets MUST NOT exceed
maxbitrate. maxbitrate.
skipping to change at page 10, line 4 skipping to change at page 9, line 45
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 [3]. hence is only defined for transfer via RTP [3].
Author: Aurelien Sollaud Author: Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG from the IESG
6.2. Mapping to SDP parameters 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)
[5], 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.729.1 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 ("G7291") goes in SDP "a=rtpmap" as the encoding
encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729.1.
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
"a=maxptime" attributes, respectively. "a=maxptime" attributes, respectively.
o Any remaining parameters go in the SDP "a=fmtp" attribute by o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type string as a semicolon copying them directly from the media type string as a semicolon
separated list of parameter=value pairs. separated list of parameter=value pairs.
Some example SDP session descriptions utilizing G.729EV encodings Some example SDP session descriptions utilizing G.729.1 encodings
follow. follow.
Example 1: default parameters Example 1: default parameters
m=audio 53146 RTP/AVP 98 m=audio 53146 RTP/AVP 98
a=rtpmap:98 G729EV/16000 a=rtpmap:98 G7291/16000
Example 2: recommended packet duration of 40 ms (=2 frames), maximum Example 2: recommended packet duration of 40 ms (=2 frames), maximum
bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a
loaded PSTN gateway which can operate at 12 kbps but asks to loaded PSTN gateway which can operate at 12 kbps but asks to
initially reduce the bit rate at 8 kbps. initially reduce the bit rate at 8 kbps.
m=audio 51258 RTP/AVP 99 m=audio 51258 RTP/AVP 99
a=rtpmap:99 G729EV/16000 a=rtpmap:99 G7291/16000
a=fmtp:99 maxbitrate=12000; mbs=8000 a=fmtp:99 maxbitrate=12000; mbs=8000
a=ptime:40 a=ptime:40
6.2.1. Offer-answer model considerations 6.2.1. Offer-answer model considerations
The following considerations apply when using SDP offer-answer The following considerations apply when using SDP offer-answer
procedures [8] to negotiate the use of G.729EV payload in RTP: procedures [8] to negotiate the use of G.729.1 payload in RTP:
o Since G.729EV is an extension of G.729, the offerer SHOULD o Since G.729.1 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.729.1
preferred. This will allow interoperability with both G.729EV and preferred. This will allow interoperability with both G.729.1 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 G729.1/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.729.1, 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.729.1.
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 Section using G.729 (the payload format for G.729 is defined in Section
4.5.6 of RFC 3551 [4]). 4.5.6 of RFC 3551 [4]).
Note that when used at 8 kbps in G.729-compatible mode, the Note that when used at 8 kbps in G.729-compatible mode, the
G.729EV decoder supports G.729 Annex B. Therefore Annex B can be G.729.1 decoder supports G.729 Annex B. Therefore Annex B can be
advertised (by default annexb=yes for G729 media type, see Section advertised (by default annexb=yes for G729 media type, see Section
4.1.9 of RFC 3555 [7]). 4.1.9 of RFC 3555 [7]).
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
skipping to change at page 12, line 19 skipping to change at page 12, line 13
parameter MUST be handled in the same way. parameter MUST be handled in the same way.
Some special rules apply for mono-directional traffic: Some special rules apply for mono-directional traffic:
o For sendonly streams, the "mbs" parameter is useless and SHOULD o For sendonly streams, the "mbs" parameter is useless and SHOULD
NOT be used. NOT be used.
o For recvonly streams, the "mbs" parameter is the only way to o For recvonly streams, the "mbs" parameter is the only way to
communicate the MBS to the sender, since there is no RTP stream communicate the MBS to the sender, since there is no RTP stream
towards it. So to request a bit rate change, the receiver will 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. need to use an out-of-band mechanism, like a SIP RE-INVITE.
Some special rules apply for multicast: Some special rules apply for multicast:
o The "mbs" parameter MUST NOT be used. o The "mbs" parameter MUST NOT be used.
o The "maxbitrate" and "dtx" parameter become declarative and MUST o The "maxbitrate" and "dtx" parameter become declarative and MUST
NOT be negotiated. These parameters are fixed, and a participant NOT be negotiated. These parameters are fixed, and a participant
MUST use the configuration that is provided for the session. MUST use the configuration that is provided for the session.
6.2.2. Declarative SDP considerations 6.2.2. Declarative SDP considerations
skipping to change at page 12, line 44 skipping to change at page 12, line 38
o The "mbs" parameter MUST NOT be used. o The "mbs" parameter MUST NOT be used.
o The "maxbitrate" and "dtx" parameters are declarative and provide o The "maxbitrate" and "dtx" parameters are declarative and provide
the parameters that SHALL be used when receiving and/or sending the parameters that SHALL be used when receiving and/or sending
the configured stream. the configured stream.
7. Congestion control 7. Congestion control
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[3] and any appropriate profile (for example, RFC 3551 [4]). The [3] and any appropriate profile (for example, RFC 3551 [4]). The
embedded and variable bit rates capability of G.729EV provides a embedded and variable bit rates capability of G.729.1 provides a
mechanism that may help to control congestion, see Section 3. mechanism that may help to control congestion, see Section 3.
The number of frames encapsulated in each RTP payload influences the The number of frames encapsulated in each RTP payload influences the
overall bandwidth of the RTP stream, due to the header overhead. overall bandwidth of the RTP stream, due to the header overhead.
Packing more frames in each RTP payload can reduce the number of Packing more frames in each RTP payload can reduce the number of
packets sent and hence the header overhead, at the expense of packets sent and hence the header overhead, at the expense of
increased delay and reduced error robustness. increased delay and reduced error robustness.
8. Security considerations 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 [3] and any appropriate profile (for example, RFC RTP specification [3] and any appropriate profile (for example, RFC
3551 [4]). 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, integrity protection, and issues include confidentiality, integrity protection, and
authentication of the speech/audio itself. The payload format itself authentication of the speech/audio itself. The payload format itself
does not have any built-in security mechanisms. Any suitable does not have any built-in security mechanisms. Any suitable
external mechanisms, such as SRTP [12], MAY be used. external mechanisms, such as SRTP [12], MAY be used.
skipping to change at page 13, line 22 skipping to change at page 13, line 15
are subject to the general security considerations discussed in the are subject to the general security considerations discussed in the
RTP specification [3] and any appropriate profile (for example, RFC RTP specification [3] and any appropriate profile (for example, RFC
3551 [4]). 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, integrity protection, and issues include confidentiality, integrity protection, and
authentication of the speech/audio itself. The payload format itself authentication of the speech/audio itself. The payload format itself
does not have any built-in security mechanisms. Any suitable does not have any built-in security mechanisms. Any suitable
external mechanisms, such as SRTP [12], MAY be used. external mechanisms, such as SRTP [12], MAY be used.
This payload format and the G.729EV encoding do not exhibit any This payload format and the G.729.1 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.
9. 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/G7291) is
registered by IANA, see Section 6.1. registered by IANA, see Section 6.1.
10. References 10. References
10.1. Normative references 10.1. Normative references
[1] International Telecommunications Union, "An 8-32 kbit/s scalable [1] International Telecommunications Union, "An 8-32 kbit/s scalable
wideband speech and audio coder bitstream interoperable with wideband speech and audio coder bitstream interoperable with
G.729", ITU-T Draft Recommendation G.729EV, April 2006. G.729", ITU-T Draft Recommendation G.729.1, April 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [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.
[3] 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.
[4] 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.
 End of changes. 40 change blocks. 
53 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/