Network Working Group A. Sollaud Internet-Draft France Telecom Expires: September 22, 2005 March 21, 2005 RTP payload format for the future scalable and wideband extension of G.729 audio codec draft-sollaud-avt-rtp-g729-scal-wb-ext-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3978. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a real-time transport protocol (RTP) payload format to be used for the future scalable and wideband extension of the International Telecommunication Union (ITU-T) G.729 audio codec. A media type registration is included for this payload format. Sollaud Expires September 22, 2005 [Page 1]
Internet-Draft RTP payload format for G.729X March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTP Payload format . . . . . . . . . . . . . . . . . . . . . . 4 3.1 RTP header usage . . . . . . . . . . . . . . . . . . . . . 4 3.2 Payload format . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Payload structure . . . . . . . . . . . . . . . . . . 5 3.2.2 Payload Header . . . . . . . . . . . . . . . . . . . . 5 3.2.3 Table of contents . . . . . . . . . . . . . . . . . . 6 3.2.4 Audio data . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5 Payload example . . . . . . . . . . . . . . . . . . . 8 3.3 MBS operations . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 MBS decreasing . . . . . . . . . . . . . . . . . . . . 10 3.3.2 MBS increasing . . . . . . . . . . . . . . . . . . . . 11 4. Payload format parameters . . . . . . . . . . . . . . . . . . 11 4.1 Media type registration . . . . . . . . . . . . . . . . . 11 4.2 Mapping to SDP parameters . . . . . . . . . . . . . . . . 12 4.3 Offer-answer model considerations . . . . . . . . . . . . 13 5. Security considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1 Normative references . . . . . . . . . . . . . . . . . . . 14 7.2 Informative references . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Sollaud Expires September 22, 2005 [Page 2]
Internet-Draft RTP payload format for G.729X March 2005 1. Introduction International Telecommunication Union (ITU-T) is working on a scalable and wideband extension of its recommendation G.729 [7]. This future audio codec will be called G.729X in the following text. This document specifies the payload format for packetization of G.729X encoded audio signals into the real-time transport protocol (RTP). The payload format itself and the handling of variable bit rate are described in Section 3. The details for the use of G.729X with MIME and SDP are given in Section 4. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. Background G.729X 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 is 16000 Hz and the frame size is 20 ms. This G.729-based codec produces an embedded bitstream providing an improved narrow band quality [300, 3400 Hz] at 12 kbps, and an enhanced and gracefully improving wideband quality [50, 7000 Hz] from 14 kbps to 32 kbps, by steps of 2 kbps. At 8 kbps it generates a G.729 bitstream (with annex B, that is supporting silence suppression). It has been mainly designed for packetized wideband voice applications (Voice over IP or ATM, Telephony over IP, private networks...) and particularly for those requiring scalable bandwidth, enhanced quality above G.729, and easy integration into existing infrastructures. G.729X is also designed to cope with other services like high quality audio/video conferencing, archival, messaging, etc. For all those applications, the scalability feature allows to tune the bit rate versus quality compromise, possibly in a dynamic way during a session, taking into account service requirements and network transport constraints. G.729X produces frames that are said embedded because they are composed of embedded layers. The first layer is called the core layer and is bitstream compatible with the ITU-T G.729 with annex B coder. Upper layers are added while bit rate increases, to improve Sollaud Expires September 22, 2005 [Page 3]
Internet-Draft RTP payload format for G.729X March 2005 quality and enlarge audio bandwidth from narrowband to wideband. As a result, a received frame can be decoded at its original bit rate or at any lower bit rate corresponding to lower layers which are embedded. Only the core layer is mandatory to decode understandable speech, upper layers provide quality enhancement and wideband enlargement. G.729X can be used in cases where bit rate can change during the communication session, due to bandwidth temporarily shared for example. Then the sender will decrease its own sending rate. But if its receiving bandwidth has decreased, it needs to tell the receiver to decrease its sending rate. To do so, the sender will send an in-band request to the receiver: the maximum bit rate supported (MBS). The receiver must acknowledge the receiving of the MBS and modify its sending rate accordingly, if possible. Thanks to the embedded property of the coding scheme, note that it can send at the MBS rate or any lower rate. G.729X supports 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 informations. This operation of sending low bit rate comfort noise parameters during silence periods is usually called discontinuous transmission (DTX). 3. RTP Payload format 3.1 RTP header usage The format of the RTP header is specified in [2]. This payload format uses the fields of the header in a manner consistent with that specification. The RTP timestamp clock frequency is the same as the sampling 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 frame. Thus the timestamp is increased by 320 for each consecutive frame. The M bit should be set as specified in the applicable RTP profile, for example, [3]. The assignment of an RTP payload type for this packet format is outside the scope of the document, and will not be specified here. It is expected that the RTP profile under which this payload format Sollaud Expires September 22, 2005 [Page 4]
Internet-Draft RTP payload format for G.729X March 2005 is being used will assign a payload type for this codec or specify that the payload type is to be bound dynamically (see Section 4.2). 3.2 Payload format 3.2.1 Payload structure The complete payload consists of an OPTIONAL payload header, a payload table of contents and audio data representing one or more frame. The following diagram shows the general format layout: +------------------+-------------------+-----------------+ | (Payload header) | Table of contents | Speech data ... | +------------------+-------------------+-----------------+ 3.2.2 Payload Header The payload header is OPTIONAL and is used to indicate to the remote host a MBS value or to acknowledge a MBS request received from the remote host. When no MBS operation is needed, this payload header SHOULD NOT be present. The payload header is one octet, as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1|A|R|R| MBS | +-+-+-+-+-+-+-+-+ The first bit is always set to 1, that is how the presence of the header is detected. A (1 bit): MBS Acknowledge. Set to 1 to acknowledge a MBS request. Otherwise set to 0. It is used to provide reliability to the MBS transmission. R (1 bit): Reserved. MUST be set to zero and SHOULD be ignored by the receiver. MBS (4 bits): maximum bit rate supported. Indicates a bit rate request to the encoder at the site of the receiver of this payload (see end of Section 2 and Section 3.3). The request is a maximum bit rate, as per the following table: Sollaud Expires September 22, 2005 [Page 5]
Internet-Draft RTP payload format for G.729X March 2005 +-------+--------------------+ | MBS | max rate supported | +-------+--------------------+ | 0 | 8 kbps | | 1 | 12 kbps | | 2 | 14 kbps | | 3 | 16 kbps | | 4 | 18 kbps | | 5 | 20 kbps | | 6 | 22 kbps | | 7 | 24 kbps | | 8 | 26 kbps | | 9 | 28 kbps | | 10 | 30 kbps | | 11 | 32 kbps | | 12-14 | (reserved) | | 15 | NO_MBS | +-------+--------------------+ The value 15 (NO_MBS) indicates that no rate request is present. It is used either to send a MBS ACK without a MBS, or when the sender can not remove the payload header and has no MBS to send. 3.2.3 Table of contents Two types of Table of Contents (ToC) are described below. In a Standard ToC, each ToC entry describes one frame. When all frames in a packet are at the same bit rate, the sender MAY use a Compact ToC, with only one ToC entry to describe the whole packet. Both types of ToC MUST be supported by the receiver. 3.2.3.1 Standard ToC The standard table of contents (ToC) consists of a list of ToC entries. Each ToC entry describes one frame. A ToC entry is one octet, as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|F|R|R| FT | +-+-+-+-+-+-+-+-+ The first bit is always set to 0. F (1 bit): Set to 1 to indicate that this ToC entry is followed by another one. Set to 0 to indicate that this ToC entry is the last one in this payload. Sollaud Expires September 22, 2005 [Page 6]
Internet-Draft RTP payload format for G.729X March 2005 R (1 bit): Reserved. MUST be set to zero and SHOULD be ignored by the receiver. FT (4 bits): Frame type, as per the following table: +-------+---------------+------------+ | FT | encoding rate | frame size | +-------+---------------+------------+ | 0 | 8 kbps | 20 octets | | 1 | 12 kbps | 30 octets | | 2 | 14 kbps | 35 octets | | 3 | 16 kbps | 40 octets | | 4 | 18 kbps | 45 octets | | 5 | 20 kbps | 50 octets | | 6 | 22 kbps | 55 octets | | 7 | 24 kbps | 60 octets | | 8 | 26 kbps | 65 octets | | 9 | 28 kbps | 70 octets | | 10 | 30 kbps | 75 octets | | 11 | 32 kbps | 80 octets | | 12-13 | (reserved) | | | 14 | SID | 2 octets | | 15 | NO_DATA | 0 | +-------+---------------+------------+ The FT value 15 (NO_DATA) indicates that a frame is either lost or not transmitted. 3.2.3.2 Compact ToC In most cases, the bit rate will not change very often, thus all frames in a payload are likely to be at the same bit rate. When this occurs, the sender MAY put only one ToC entry to indicate the bit rate of all frames in the packet. The receiver will easily detect that there is only one ToC entry (bit F=0) and that the size of the audio data part of the payload is a multiple of the size of one frame at the considered bit rate. So the actual number of frame is easy to infer from the size of the audio data part : nb_frames=(size_of_audio_data)/(size_of_one_frame). This ToC simplification is compatible with DTX, with the restriction that the SID frame MUST be at the end of the payload (it is in consistent with the payload format of G.729 described in section 4.5.6 of [3]). 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 without the need of adding a Toc entry with FT=14. Actually the presence of a SID frame will be inferred by the result of the above division not being an Sollaud Expires September 22, 2005 [Page 7]
Internet-Draft RTP payload format for G.729X March 2005 integer. The receiver MUST support this compact ToC format. Note well that this simplification of the ToC is acceptable only if ALL frames are at the same bit rate. It can not be used if several sequential frames are at the same bit rate R1 and the following group of frames are at another bit rate R2, because the receiver will not be able to determine how many frames of each bit rate there are. If compact Toc is used, there MUST be only ONE ToC entry. Below are short examples illustrating the compact ToC and the calculation of the number of frames. See Section 3.2.5.3 for a complete payload. Example 1 : one ToC entry with FT=4 and 135 octets of audio data following. The receiver knows that for FT=4, a frame is 45 octets long. So there is 135/45 = 3 frames in the payload. Example 2 : one ToC entry with FT=9 and 142 octets of audio data following. The receiver knows that for FT=9, a frame is 70 octets long. So there is 142/70 = 2 frames in the payload + a 2 octets rest which is a SID frame. 3.2.4 Audio data Audio data of a payload contains one or more audio frame as described in the table of contents of the payload. The audio frames are packed in the same order as their corresponding ToC entries are arranged in the table of contents. If the Compact ToC is used, the audio frames are packed in order of time, that is the older first. Note that for ToC entries with FT=15, there will be no corresponding audio frame in the payload. 3.2.5 Payload example Sollaud Expires September 22, 2005 [Page 8]
Internet-Draft RTP payload format for G.729X March 2005 3.2.5.1 Payload carrying a single frame and no MBS The following diagram shows a G.729X payload that contains a single speech frame at 24 kbps (FT=7; size=60 octets) and no MBS. 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|0|R|R| FT=7 | f(1/60) | f(2/60) | f(3/60) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f(4/60) | f(5/60) | f(6/60) | f(7/60) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f(60/60) | +-+-+-+-+-+-+-+-+ 3.2.5.2 Payload carrying multiple frames at various bit rates and a MBS The following diagram shows a G.729X payload that contains 3 frames, two at 20 kbps (FT=5; size=50 octets) and one at 32 kbps (FT=11; size=80 octets), and a MBS of 32 kbps (MBS=11). The first octet is the payload header (MBS) and is inserted before the ToC. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|R|R| MBS=11|0|1|R|R| FT=5 |0|1|R|R| FT=5 |0|0|R|R| FT=11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(1/50) | f1(2/50) | f1(3/50) | f1(4/50) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(49/50) | f1(50/50) | f2(1/50) | f2(2/50) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(47/50) | f2(48/50) | f2(49/50) | f2(50/50) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3(1/80) | f3(2/80) | f3(3/80) | f3(4/80) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3(77/80) | f3(78/80) | f3(79/80) | f3(80/80) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sollaud Expires September 22, 2005 [Page 9]
Internet-Draft RTP payload format for G.729X March 2005 3.2.5.3 Payload carrying multiple frames at the same bit rate and no MBS The following diagram shows a G.729X payload that contains 2 frames at 14 kbps (FT=2; size=35 octets) and no MBS. There is only one ToC entry, the number of frames is inferred from the payload size. 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|0|R|R| FT=2 | f1(1/35) | f1(2/35) | f1(3/35) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(32/35) | f1(33/35) | f1(34/35) | f1(35/35) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(1/35) | f2(2/35) | f2(3/35) | f2(4/35) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(33/35) | f2(34/35) | f2(35/35) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 MBS operations The MBS value located in the optional payload header is used to tell the other party that the maximum bit rate one can receive has changed. Examples of MBS usage are following. The content of the optional payload header will be written {A=x; MSB=y}. 3.3.1 MBS decreasing Say Alice and Bob are in a voice call using G.729X operating at the maximum bit rate of 32 kbps. Alice and Bob both have a MBS of 32 kbps. For any reason, at a moment, Alice needs to free bandwidth. She will decrease her sending rate to 12 kbps for example and insert a payload header {A=0; MBS=1} to request Bob to decrease his sending rate. In all consecutive payloads she will insert this payload header, waiting for acknowledgement. Bob will receive the MBS information, he will decrease his sending rate accordingly and insert a payload header {A=1;MBS=15} to acknowledge. Bob will insert this header in all consecutive payloads as long as he receives the MBS from Alice. When Alice receives the acknowledgement, she will remove the payload header with the MBS. Then Bob will remove his payload header. This example shows the acknowledgement procedure. Note that Bob can Sollaud Expires September 22, 2005 [Page 10]
Internet-Draft RTP payload format for G.729X March 2005 now send at 12 kbps (value of the MBS received) but also any bit rate lower, in this case 8 kbps. Bob does not send a MBS to Alice because Bob's receiving conditions did not change, that is why Bob replies with a simple MBS ACK, without specifying a MBS (MBS=15). 3.3.2 MBS increasing We start from the previous situation. Alice and Bod are now operating at 12 kbps, but Alice's MBS is 12 kbps whereas Bob's MBS is still 32 kbps. At a moment, Alice has more bandwidth, she switches back to 32 kbps. She can do this straight because Bob's MBS is 32 kbps. To request Bob to increase his sending rate, she sends a MBS {A=0; MBS=11} to Bob. Bob receives the MBS and acknowledges it by a MBS ACK {A=1; MBS=15}. Now Bob knows he can send up to 32 kbps to Alice. For any reason Bob's sending bandwidth is currently limited and Bob chooses to keep sending at 12 kbps. At this point, Alice is sending 32 kbps to Bob and Bob is sending 12 kbps to Alice. Each endpoint knows the MBS of the other is 32 kbps. So later, Bob may increase his sending bit rate without any previous notice. This case illustrates the fact that the proper receiving and acknowledgement of a MBS does not imply an immediate bit rate increasing. 4. Payload format parameters This section defines the parameters that may be used to configure optional features in the G.729X RTP transmission. The parameters are defined here as part of the MIME subtype registration for the G.729X codec. A mapping of the parameters into the Session Description Protocol (SDP) [4] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol. 4.1 Media type registration MIME media type name: audio MIME subtype name: G729X [to be replaced by the actual annex letter] Required parameters: none Optional parameters: Sollaud Expires September 22, 2005 [Page 11]
Internet-Draft RTP payload format for G.729X March 2005 dtx: indicates that discontinuous transmission (DTX) is used or 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. init-MBS: indicates an initial value of MBS. Permissible values are legal values of MBS, that is between 0 and 11 (see table in Section 3.2.2 of RFC XXXX). The maximum MBS, that is 11, is implied if this parameter is omitted. ptime: the recommended length of time in milliseconds represented by the media in a packet. See RFC 2327 [4]. maxptime: the maximum length of time in milliseconds which can be encapsulated in a packet. Encoding considerations: This type is only defined for transfer via RTP [2]. Security considerations: See Section 5 of RFC XXXX Interoperability considerations: none Published specification: RFC XXXX Applications which use this media type: Audio and video conferencing tools. Additional information: none Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@francetelecom.com Intended usage: COMMON Author/Change controller: IETF Audio/Video Transport working group delegated from the IESG 4.2 Mapping to SDP parameters The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [4], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.729X codec, the mapping is as follows : o The media type ("audio") goes in SDP "m=" as the media name. Sollaud Expires September 22, 2005 [Page 12]
Internet-Draft RTP payload format for G.729X March 2005 o The media subtype ("G729X") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729X. o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated list of parameter=value pairs. Some example SDP session descriptions utilizing G.729X encodings follow. Exemple 1: default parameters m=audio 53146 RTP/AVP 98 a=rtpmap:98 G729X/16000 Exemple 2: recommended packet duration of 40 ms (=2 frames), no DTX and initial MBS to 26 kbps m=audio 51258 RTP/AVP 99 a=rtpmap:99 G729X/16000 a=ptime:40 a=fmtp:99 dtx=1; init-MBS=8 4.3 Offer-answer model considerations The following considerations apply when using SDP offer-answer procedures to negotiate the use of G.729X payload in RTP: o Since G.729X is an extension of G.729, the offerer SHOULD announce G.729 support in its "m=audio" line, with G.729X preferred. This will allow interoperability with both G.729X and G.729-only capable parties. Below is an example of such an offer: m=audio 55954 RTP/AVP 98 18 a=rtpmap:98 G729X/16000 a=rtpmap:18 G729/8000 If the answerer supports G.729X, it will keep the payload type 98 in its answer and the conversation will be done using G.729X. 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 using G.729. Sollaud Expires September 22, 2005 [Page 13]
Internet-Draft RTP payload format for G.729X March 2005 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 "init-MBS" parameter is not symmetric. Values in the offer and the answer are independant and take into account local bandwidth constraints. Anyway, one party MUST NOT start sending frames at a bit rate higher than the "init-MBS" of the other party. o The parameters "maxptime" and "ptime" will in most cases not affect interoperability. The SDP offer-answer handling of the "ptime" parameter is described in [5]. The "maxptime" parameter MUST be handled in the same way. 5. Security considerations RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in the RTP specification [2] and any appropriate profile (for example, [3]). As this format transports encoded speech/audio, the main security issues include confidentiality and authentication of the speech/audio itself. The payload format itself does not have any built-in security mechanisms. Confidentiality of the media streams is achieved by encryption, therefore external mechanisms, such as SRTP [6], MAY be used for that purpose. The data compression used with this payload format is applied end-to-end; hence encryption may be performed after compression with no conflict between the two operations. This payload format and the G.729X encoding do not exhibit any significant non-uniformity in the receiver-end computational load and thus in unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams. 6. IANA considerations It is requested that one new MIME subtype (audio/G729X) is registered by IANA, see Section 4.1. 7. References 7.1 Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sollaud Expires September 22, 2005 [Page 14]
Internet-Draft RTP payload format for G.729X March 2005 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 7.2 Informative references [7] International Telecommunications Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. Author's Address Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France Phone: +33 2 96 05 15 06 Email: aurelien.sollaud@francetelecom.com Sollaud Expires September 22, 2005 [Page 15]
Internet-Draft RTP payload format for G.729X March 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 (2005). 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 Funding for the RFC Editor function is currently provided by the Internet Society. Sollaud Expires September 22, 2005 [Page 16]
