< draft-ietf-avt-rtp-g729-scal-wb-ext-06.txt   draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt >
Network Working Group A. Sollaud Network Working Group A. Sollaud
Internet-Draft France Telecom Internet-Draft France Telecom
Expires: November 19, 2006 May 18, 2006 Intended status: Standards Track August 28, 2006
Expires: March 1, 2007
RTP payload format for the G.729.1 audio codec RTP payload format for the G.729.1 audio codec
draft-ietf-avt-rtp-g729-scal-wb-ext-06 draft-ietf-avt-rtp-g729-scal-wb-ext-07
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 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 November 19, 2006. This Internet-Draft will expire on March 1, 2007.
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.729.1 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 . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) recommendation The International Telecommunication Union (ITU-T) recommendation
G.729.1 [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.729.1 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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
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
16 kHz. Input and output at 8 kHz is also supported, at all bit 16 kHz. Input and output at 8 kHz are also supported, at all bit
rates. rates.
Audio codecs often support voice activity detection (VAD) and comfort
noise generation (CNG). During silence periods, the coder may
significantly decrease the transmitted bit rate by sending only
comfort noise parameters in special small frames called silence
insertion descriptors (SID). The receiver's decoder will generate
comfort noise according to the SID information. This operation of
sending low bit rate comfort noise parameters during silence periods
is usually called discontinuous transmission (DTX).
G.729.1 will be first released without support for DTX. Anyway, this
functionality is planned and will be defined in a separate annex
later. Thus this specification provides DTX signalling, even if the
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.729.1 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, The ability to adjust the bandwidth may also help when having a fixed
for example in a residential or trunking gateway. In that case, the bandwidth link dedicated to voice calls, for example in a residential
system can change the bit rates depending on the number of or trunking gateway. In that case, the system can change the bit
simultaneous calls. Since it only impacts the sending bandwidth, we rates depending on the number of simultaneous calls. Since it only
introduce an in-band signalling to request the other party to change impacts the sending bandwidth, we introduce an in-band signalling to
its own sending bit rate, in order to adjust the receiving bandwidth request the other party to change its own sending bit rate, in order
as well. This in-band request is called MBS, for Maximum Bit rate to adjust the receiving bandwidth as well. This in-band request is
Supported. It is described in the following payload format (see called MBS, for Maximum Bit rate Supported. It is described in
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.729.1
G.729.1 traffic, because when A sends an in-band MBS to B, it is to traffic, because when A sends an in-band MBS to B, it is to request B
request B to modify its sending bit rate, that is for the stream from to modify its sending bit rate, that is for the stream from B to A.
B to A. If there is no G.729.1 stream in the reverse direction, the If there is no G.729.1 stream in the reverse direction, the MBS will
MBS will have no effect. 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.
skipping to change at page 5, line 21 skipping to change at page 5, line 6
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
frame. frame.
If DTX is used, the first packet of a talkspurt, that is, the first The M bit MUST be set to zero in all packets.
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 6.2). that the payload type is to be bound dynamically (see Section 6.2).
5. Payload format 5. Payload format
5.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,
generally followed by audio data representing one or more consecutive followed by zero or more consecutive audio frames at the same bit
frames at the same bit rate. rate.
The payload header consists of two fields: MBS (see Section 5.2) and
FT (see Section 5.3).
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 | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
: zero or more frames at the same bit rate : : zero or more frames at the same bit rate :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 43 skipping to change at page 6, line 37
scheme, note that it can send frames at the MBS rate or any lower scheme, note that it can send frames at the MBS rate or any lower
rate. As long as it does not exceed the MBS, it can change its bit rate. As long as it does not exceed the MBS, it can change its bit
rate at any time without previous notice. rate at any time without previous notice.
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 received is valid until the next MBS is received, i.e. a The MBS received is valid until the next MBS is received, i.e. a
newly received MBS value overrides the previous one. newly received MBS value overrides the previous one.
If a payload with an invalid MBS value is received, the MBS MUST be If a payload with a reserved MBS value is received, the MBS MUST be
ignored. ignored.
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, and MUST be ignored on packets received from a multicast group, and MUST be ignored on packets received from 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.
skipping to change at page 7, line 37 skipping to change at page 7, line 34
| 11 | 32 kbps | 80 octets | | 11 | 32 kbps | 80 octets |
| 12-14 | (reserved) | | | 12-14 | (reserved) | |
| 15 | NO_DATA | 0 | | 15 | NO_DATA | 0 |
+-------+---------------+------------+ +-------+---------------+------------+
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 a reserved FT value is received, the whole payload
MUST be ignored. MUST be ignored.
5.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 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 frames is easy to infer from
size of the audio data part: the 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).
Only full frames must be considered. So if there is a remainder to
the division above, the corresponding remaining bytes in the received
payload MUST be ignored.
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.729.1 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.729.1 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]
YYYY with the RFC number that will be assigned to the latest SDP
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: G7291 Subtype name: G7291
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
dtx: indicates that discontinuous transmission (DTX) is used or maxbitrate: the absolute maximum codec bit rate for the session, in
preferred. DTX means voice activity detection and non
transmission of silent frames. Permissible values are 0 and 1. 0
means no DTX. 0 is implied if this parameter is omitted. The
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
parameter.
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.
mbs: the current maximum codec bit rate supported as a receiver, in mbs: the current maximum codec bit rate supported as a receiver, in
bits per second. Permissible values are in the same set as for bits per second. Permissible values are in the same set as for
the maxbitrate parameter, with the constraint that mbs MUST be the maxbitrate parameter, with the constraint that mbs MUST be
lower or equal to maxbitrate. If the mbs parameter is omitted, it lower or equal to maxbitrate. If the mbs parameter is omitted, it
is set to the maxbitrate value. So if both mbs and maxbitrate are is set to the maxbitrate value. So if both mbs and maxbitrate are
omitted, they are both set to 32000. The mbs parameter omitted, they are both set to 32000. The mbs parameter
corresponds to a MBS value in the RTP packets as per table in corresponds to a MBS value in the RTP packets as per table in
Section 5.2 of RFC XXXX. Note that this parameter may be Section 5.2 of RFC XXXX. Note that this parameter may be
dynamically updated by the MBS field of the RTP packets sent, it dynamically updated by the MBS field of the RTP packets sent, it
is not an absolute value for the session. is not an absolute value for 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 Section 6 of RFC YYYY [5]. the media in a packet. See Section 6 of RFC 4566 [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. See Section 6 of RFC YYYY [5] encapsulated in a packet. See Section 6 of RFC 4566 [5]
Encoding considerations: This media type is framed and contains Encoding considerations: This media type is framed and contains
binary data, see section 4.8 of RFC 4288 [6]. binary data, see section 4.8 of RFC 4288 [6].
Security considerations: See Section 8 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@orange-ft.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
skipping to change at page 11, line 20 skipping to change at page 11, line 8
in its answer and the conversation will be done using G.729.1. 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.729.1 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
sides of a bi-directional session MUST use the same "dtx" value.
If one party indicates it does not support DTX, DTX must be
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 If the received value for "maxbitrate" is between 8000 and 32000 o If the received value for "maxbitrate" is between 8000 and 32000
but not in the permissible values set, it SHOULD be read as the but not in the permissible values set, it SHOULD be read as the
closest lower valid value. If the received value is lower than closest lower valid value. If the received value is lower than
8000 or greater than 32000, the session MUST be rejected. 8000 or greater than 32000, the session MUST be rejected.
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 One party MUST NOT start sending frames at a bit rate higher than
higher than the "mbs" of the other party. The parameter allows to the "mbs" of the other party. The parameter allows to announce
announce this value, prior to the sending of any packet, to avoid this value, prior to the sending of any packet, to avoid the
the remote sender to exceed the MBS at the beginning of the remote sender to exceed the MBS at the beginning of the session.
session.
o If the received value for "mbs" is greater or equal to 8000 but o If the received value for "mbs" is greater or equal to 8000 but
not in the permissible values set, it SHOULD be read as the not in the permissible values set, it SHOULD be read as the
closest lower valid value. If the received value is lower than closest lower valid value. If the received value is lower than
8000, the session MUST be rejected. 8000, the session MUST be rejected.
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 [8]. The "maxptime" "ptime" parameter is described in RFC 3264 [8]. The "maxptime"
parameter MUST be handled in the same way. parameter MUST be handled in the same way.
o Any unkown parameter in an offer MUST be ignored by the receiver,
and MUST NOT be included in the answer.
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-INVITE. 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" parameter becomes declarative and MUST NOT be
NOT be negotiated. These parameters are fixed, and a participant negotiated. This parameter is fixed, and a participant MUST use
MUST use the configuration that is provided for the session. the configuration that is provided for the session.
6.2.2. Declarative SDP considerations 6.2.2. Declarative SDP considerations
For declarative use of SDP such as in SAP [10] and RTSP [11], the For declarative use of SDP such as in SAP [10] and RTSP [11], the
following considerations apply: following considerations apply:
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" parameter is declarative and provide the
the parameters that SHALL be used when receiving and/or sending parameter that SHALL be used when receiving and/or sending the
the configured stream. 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.729.1 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 for more
details.
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 29 skipping to change at page 13, line 19
9. IANA considerations 9. IANA considerations
It is requested that one new media subtype (audio/G7291) 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, "G.729 based Embedded
wideband speech and audio coder bitstream interoperable with Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder
G.729", ITU-T Draft Recommendation G.729.1, April 2006. bitstream interoperable with G.729", ITU-T Recommendation
G.729.1, May 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.
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in Description Protocol", RFC 4566, July 2006.
progress), January 2006.
[6] Freed, N. and J. Klensin, "Media Type Specifications and [6] 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.
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003. Payload Formats", RFC 3555, July 2003.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [8] 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.
skipping to change at page 15, line 14 skipping to change at page 14, line 24
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@orange-ft.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 15, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 33 change blocks. 
107 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/