idnits 2.17.1 draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 629. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2005) is 6856 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Sollaud 3 Internet-Draft France Telecom 4 Expires: January 14, 2006 July 13, 2005 6 RTP payload format for the future scalable and wideband extension of 7 G.729 audio codec 8 draft-sollaud-avt-rtp-g729-scal-wb-ext-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 14, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document specifies a real-time transport protocol (RTP) payload 42 format to be used for the future scalable and wideband extension of 43 the International Telecommunication Union (ITU-T) G.729 audio codec. 44 A media type registration is included for this payload format. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. RTP Payload format . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1 RTP header usage . . . . . . . . . . . . . . . . . . . . . 4 52 3.2 Payload format . . . . . . . . . . . . . . . . . . . . . . 4 53 3.2.1 Payload structure . . . . . . . . . . . . . . . . . . 4 54 3.2.2 Payload Header . . . . . . . . . . . . . . . . . . . . 5 55 3.2.3 Table of contents . . . . . . . . . . . . . . . . . . 6 56 3.2.4 Audio data . . . . . . . . . . . . . . . . . . . . . . 8 57 3.2.5 Payload examples . . . . . . . . . . . . . . . . . . . 8 58 4. Payload format parameters . . . . . . . . . . . . . . . . . . 10 59 4.1 Media type registration . . . . . . . . . . . . . . . . . 10 60 4.2 Mapping to SDP parameters . . . . . . . . . . . . . . . . 11 61 4.3 Offer-answer model considerations . . . . . . . . . . . . 12 62 5. Security considerations . . . . . . . . . . . . . . . . . . . 13 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7.1 Normative references . . . . . . . . . . . . . . . . . . . 13 66 7.2 Informative references . . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . 15 70 1. Introduction 72 The International Telecommunication Union (ITU-T) is working on a 73 scalable and wideband extension of its recommendation G.729 [7]. 74 This future audio codec will be called G.729X in the following text. 75 This document specifies the payload format for packetization of 76 G.729X encoded audio signals into the real-time transport protocol 77 (RTP). 79 The payload format itself and the handling of variable bit rate are 80 described in Section 3. A media type registration and the details 81 for the use of G.729X with SDP are given in Section 4. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [1]. 87 2. Background 89 G.729X is mainly designed to be used as a speech codec, but it can be 90 used for music at the highest bit rates. The sampling frequency is 91 16000 Hz and the frame size is 20 ms. 93 This G.729-based codec produces an embedded bitstream providing an 94 improved narrow band quality [300, 3400 Hz] at 12 kbps, and an 95 enhanced and gracefully improving wideband quality [50, 7000 Hz] from 96 14 kbps to 32 kbps, by steps of 2 kbps. At 8 kbps it generates a 97 G.729 bitstream (with annex B, that is supporting silence 98 suppression). 100 It has been mainly designed for packetized wideband voice 101 applications (Voice over IP or ATM, Telephony over IP, private 102 networks...) and particularly for those requiring scalable bandwidth, 103 enhanced quality above G.729, and easy integration into existing 104 infrastructures. 106 G.729X is also designed to cope with other services like high quality 107 audio/video conferencing, archival, messaging, etc. 109 For all those applications, the scalability feature allows to tune 110 the bit rate versus quality trade-off, possibly in a dynamic way 111 during a session, taking into account service requirements and 112 network transport constraints. 114 G.729X produces frames that are said embedded because they are 115 composed of embedded layers. The first layer is called the core 116 layer and is bitstream compatible with the ITU-T G.729 with annex B 117 coder. Upper layers are added while bit rate increases, to improve 118 quality and enlarge audio bandwidth from narrowband to wideband. As 119 a result, a received frame can be decoded at its original bit rate or 120 at any lower bit rate corresponding to lower layers which are 121 embedded. Only the core layer is mandatory to decode understandable 122 speech, upper layers provide quality enhancement and wideband 123 enlargement. 125 G.729X supports voice activity detection (VAD) and comfort noise 126 generation (CNG). During silence periods, the coder may 127 significantly decrease the transmitted bit rate by sending only 128 comfort noise parameters in special small frames called silence 129 insertion descriptors (SID). The receiver's decoder will generate 130 comfort noise according to the SID information. This operation of 131 sending low bit rate comfort noise parameters during silence periods 132 is usually called discontinuous transmission (DTX). 134 3. RTP Payload format 136 3.1 RTP header usage 138 The format of the RTP header is specified in [2]. This payload 139 format uses the fields of the header in a manner consistent with that 140 specification. 142 The RTP timestamp clock frequency is the same as the sampling 143 frequency, that is 16 kHz. So the timestamp unit is in samples. 145 The duration of one frame is 20 ms, corresponding to 320 samples per 146 frame. Thus the timestamp is increased by 320 for each consecutive 147 frame. 149 The M bit should be set as specified in the applicable RTP profile, 150 for example, [3]. 152 The assignment of an RTP payload type for this packet format is 153 outside the scope of the document, and will not be specified here. 154 It is expected that the RTP profile under which this payload format 155 is being used will assign a payload type for this codec or specify 156 that the payload type is to be bound dynamically (see Section 4.2). 158 3.2 Payload format 160 3.2.1 Payload structure 162 The complete payload consists of a payload header, a payload table of 163 contents, and audio data representing one or more frame. The 164 following diagram shows the general format layout: 166 +----------------+-------------------+-----------------+ 167 | Payload header | Table of contents | Speech data ... | 168 +----------------+-------------------+-----------------+ 170 3.2.2 Payload Header 172 The payload header is one octet, as follows: 174 0 1 2 3 4 5 6 7 175 +-+-+-+-+-+-+-+-+ 176 |R|R|R|R| MBS | 177 +-+-+-+-+-+-+-+-+ 179 R (1 bit): Reserved. MUST be set to zero and SHOULD be ignored by 180 the receiver. 182 MBS (4 bits): maximum bit rate supported. Indicates a maximum bit 183 rate to the encoder at the site of the receiver of this payload. The 184 value of the MBS field is set according to the following table: 186 +-------+--------------+ 187 | MBS | max bit rate | 188 +-------+--------------+ 189 | 0 | 8 kbps | 190 | 1 | 12 kbps | 191 | 2 | 14 kbps | 192 | 3 | 16 kbps | 193 | 4 | 18 kbps | 194 | 5 | 20 kbps | 195 | 6 | 22 kbps | 196 | 7 | 24 kbps | 197 | 8 | 26 kbps | 198 | 9 | 28 kbps | 199 | 10 | 30 kbps | 200 | 11 | 32 kbps | 201 | 12-15 | (reserved) | 202 +-------+--------------+ 204 The MBS is used to tell the other party the maximum bit rate one can 205 receive. The encoder MUST follow the received MBS. It MUST NOT send 206 frames at a bit rate higher than the received MBS. Thanks to the 207 embedded property of the coding scheme, note that it can send frames 208 at the MBS rate or any lower rate. As long as it does not exceed the 209 MBS, it can change its bit rate at any time without previous notice. 211 The MBS value MUST be set to 11 (that is 32 kbps, the maximum) when 212 there is no bit rate constraint. 214 The MBS received is valid until the next MBS is received, i.e. a 215 newly received MBS value overrides the previous one. 217 If a payload with an invalid MBS value is received, the MBS MUST be 218 ignored. 220 Note that the MBS is a codec bit rate, the actual network bit rate is 221 higher and depends on the overhead of the underlying protocols. 223 3.2.3 Table of contents 225 The Table of Contents (ToC) is composed of one or more ToC entries. 226 Two types of ToC are described below. In a Standard ToC, each ToC 227 entry describes one frame. When all frames in a packet are at the 228 same bit rate, the sender SHOULD use a Compact ToC, with only one ToC 229 entry to describe the whole packet. Both types of ToC MUST be 230 supported by the receiver. 232 3.2.3.1 Standard ToC 234 The standard table of contents (ToC) consists of a list of ToC 235 entries. Each ToC entry describes one frame. 237 A ToC entry is one octet, as follows: 239 0 1 2 3 4 5 6 7 240 +-+-+-+-+-+-+-+-+ 241 |F|R|R|R| FT | 242 +-+-+-+-+-+-+-+-+ 244 F (1 bit): Set to 1 to indicate that this ToC entry is followed by 245 another one. Set to 0 to indicate that this ToC entry is the last 246 one in this payload. 248 R (1 bit): Reserved. MUST be set to zero and SHOULD be ignored by 249 the receiver. 251 FT (4 bits): Frame type, as per the following table: 253 +-------+---------------+------------+ 254 | FT | encoding rate | frame size | 255 +-------+---------------+------------+ 256 | 0 | 8 kbps | 20 octets | 257 | 1 | 12 kbps | 30 octets | 258 | 2 | 14 kbps | 35 octets | 259 | 3 | 16 kbps | 40 octets | 260 | 4 | 18 kbps | 45 octets | 261 | 5 | 20 kbps | 50 octets | 262 | 6 | 22 kbps | 55 octets | 263 | 7 | 24 kbps | 60 octets | 264 | 8 | 26 kbps | 65 octets | 265 | 9 | 28 kbps | 70 octets | 266 | 10 | 30 kbps | 75 octets | 267 | 11 | 32 kbps | 80 octets | 268 | 12-13 | (reserved) | | 269 | 14 | SID | 2 octets | 270 | 15 | NO_DATA | 0 | 271 +-------+---------------+------------+ 273 The FT value 15 (NO_DATA) indicates that a frame is either lost or 274 not transmitted. For a ToC entry with FT=15, there will be no 275 corresponding audio frame in the payload. Note that packets 276 containing only NO_DATA frames SHOULD NOT be transmitted. 278 If a ToC entry with an invalid FT value is received, the entire 279 payload MUST be discarded. 281 3.2.3.2 Compact ToC 283 In most cases, the bit rate will not change very often, thus all 284 frames in a payload are likely to be at the same bit rate. When this 285 occurs, the sender SHOULD put only one ToC entry to indicate the bit 286 rate of all frames in the packet. The receiver will easily detect 287 that there is only one ToC entry (bit F=0) and that the size of the 288 audio data part of the payload is a multiple of the size of one frame 289 at the considered bit rate. So the actual number of frame is easy to 290 infer from the size of the audio data part: 292 nb_frames = (size_of_audio_data) / (size_of_one_frame). 294 This ToC simplification is compatible with DTX, with the restriction 295 that the SID frame MUST be at the end of the payload (it is in 296 consistent with the payload format of G.729 described in section 297 4.5.6 of [3]). Since the SID frame is much smaller than any other 298 frame, it will not hinder the calculation of the number of frames at 299 the receiver side and can be easily detected without the need of 300 adding a Toc entry with FT=14. Actually the presence of a SID frame 301 will be inferred by the result of the above division not being an 302 integer. 304 The receiver MUST support this compact ToC format. 306 Note well that this simplification of the ToC is acceptable only if 307 ALL frames are at the same bit rate. It can not be used if several 308 sequential frames are at the same bit rate R1 and the following group 309 of frames are at another bit rate R2, because the receiver will not 310 be able to determine how many frames of each bit rate there are. If 311 compact Toc is used, there MUST be only ONE ToC entry. 313 Below are short examples illustrating the compact ToC and the 314 calculation of the number of frames. See Section 3.2.5.3 for a 315 complete payload. 317 Example 1 : one ToC entry with FT=4 and 135 octets of audio data 318 following. The receiver knows that for FT=4, a frame is 45 octets 319 long. So there is 135/45 = 3 frames in the payload. 321 Example 2 : one ToC entry with FT=9 and 142 octets of audio data 322 following. The receiver knows that for FT=9, a frame is 70 octets 323 long. So there is 142/70 = 2 frames in the payload + a 2 octets rest 324 which is a SID frame. 326 3.2.4 Audio data 328 Audio data of a payload contains one or more audio frame as described 329 in the table of contents of the payload. The audio frames are packed 330 in the same order as their corresponding ToC entries are arranged in 331 the table of contents. If the Compact ToC is used, the audio frames 332 are packed in order of time, that is the older first. 334 Note that for ToC entries with FT=15, there will be no corresponding 335 audio frame in the payload. 337 3.2.5 Payload examples 338 3.2.5.1 Payload carrying a single frame 340 The following diagram shows a G.729X payload that contains a single 341 speech frame at 24 kbps (FT=7; size=60 octets) and a MBS of 24 kbps 342 (MBS=7). 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |R|R|R|R| MBS=7 |0|R|R|R| FT=7 | f(1/60) | f(2/60) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 : ... : 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | f(59/60) | f(60/60) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 3.2.5.2 Payload carrying multiple frames at various bit rates 356 The following diagram shows a G.729X payload that contains 3 frames, 357 two at 20 kbps (FT=5; size=50 octets) and one at 32 kbps (FT=11; 358 size=80 octets), and a MBS of 32 kbps (MBS=11). 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |R|R|R|R| MBS=11|1|R|R|R| FT=5 |1|R|R|R| FT=5 |0|R|R|R| FT=11 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | f1(1/50) | f1(2/50) | f1(3/50) | f1(4/50) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 : ... : 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | f1(49/50) | f1(50/50) | f2(1/50) | f2(2/50) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 : ... : 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | f2(47/50) | f2(48/50) | f2(49/50) | f2(50/50) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | f3(1/80) | f3(2/80) | f3(3/80) | f3(4/80) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 : ... : 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | f3(77/80) | f3(78/80) | f3(79/80) | f3(80/80) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 3.2.5.3 Payload carrying multiple frames at the same bit rate 384 The following diagram shows a G.729X payload that contains 2 frames 385 at 14 kbps (FT=2; size=35 octets) and a MBS of 32 kbps (MBS=11). It 386 illustrates the Compact ToC: there is only one ToC entry, the number 387 of frames is inferred from the payload size. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |R|R|R|R| MBS=11|0|R|R|R| FT=2 | f1(1/35) | f1(2/35) | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 : ... : 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | f1(35/35) | f2(1/35) | f2(2/35) | f2(3/35) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 : ... : 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | f2(32/35) | f2(33/35) | f2(34/35) | f2(35/35) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 4. Payload format parameters 405 This section defines the parameters that may be used to configure 406 optional features in the G.729X RTP transmission. 408 The parameters are defined here as part of the media subtype 409 registration for the G.729X codec. A mapping of the parameters into 410 the Session Description Protocol (SDP) [4] is also provided for those 411 applications that use SDP. In control protocols that do not use MIME 412 or SDP, the media type parameters must be mapped to the appropriate 413 format used with that control protocol. 415 4.1 Media type registration 417 Type name: audio 419 Subtype name: G729X [to be replaced by the actual annex letter] 421 Required parameters: none 423 Optional parameters: 425 dtx: indicates that discontinuous transmission (DTX) is used or 426 preferred. DTX means voice activity detection and non 427 transmission of silent frames. Permissible values are 0 and 1. 0 428 means no DTX. 0 is implied if this parameter is omitted. 430 init-MBS: indicates an initial value of MBS. Permissible values 431 are legal values of MBS, that is between 0 and 11 (see table in 432 Section 3.2.2 of RFC XXXX). The maximum MBS, that is 11, is 433 implied if this parameter is omitted. 435 ptime: the recommended length of time in milliseconds represented 436 by the media in a packet. See RFC 2327 [4]. 438 maxptime: the maximum length of time in milliseconds which can be 439 encapsulated in a packet. 441 Encoding considerations: This media type is framed and contains 442 binary data. 444 Security considerations: See Section 5 of RFC XXXX 446 Interoperability considerations: none 448 Published specification: RFC XXXX 450 Applications which use this media type: Audio and video conferencing 451 tools. 453 Additional information: none 455 Person & email address to contact for further information: Aurelien 456 Sollaud, aurelien.sollaud@francetelecom.com 458 Intended usage: COMMON 460 Restrictions on usage: This media type depends on RTP framing, and 461 hence is only defined for transfer via RTP [2]. 463 Author/Change controller: IETF Audio/Video Transport working group 464 delegated from the IESG 466 4.2 Mapping to SDP parameters 468 The information carried in the media type specification has a 469 specific mapping to fields in the Session Description Protocol (SDP) 470 [4], which is commonly used to describe RTP sessions. When SDP is 471 used to specify sessions employing the G.729X codec, the mapping is 472 as follows : 474 o The media type ("audio") goes in SDP "m=" as the media name. 476 o The media subtype ("G729X") goes in SDP "a=rtpmap" as the encoding 477 name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729X. 479 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 480 "a=maxptime" attributes, respectively. 482 o Any remaining parameters go in the SDP "a=fmtp" attribute by 483 copying them directly from the media type string as a semicolon 484 separated list of parameter=value pairs. 486 Some example SDP session descriptions utilizing G.729X encodings 487 follow. 489 Example 1: default parameters 491 m=audio 53146 RTP/AVP 98 492 a=rtpmap:98 G729X/16000 494 Example 2: recommended packet duration of 40 ms (=2 frames), DTX on, 495 and initial MBS to 26 kbps 497 m=audio 51258 RTP/AVP 99 498 a=rtpmap:99 G729X/16000 499 a=ptime:40 500 a=fmtp:99 dtx=1; init-MBS=8 502 4.3 Offer-answer model considerations 504 The following considerations apply when using SDP offer-answer 505 procedures to negotiate the use of G.729X payload in RTP: 507 o Since G.729X is an extension of G.729, the offerer SHOULD announce 508 G.729 support in its "m=audio" line, with G.729X preferred. This 509 will allow interoperability with both G.729X and G.729-only 510 capable parties. 512 Below is an example of such an offer: 514 m=audio 55954 RTP/AVP 98 18 515 a=rtpmap:98 G729X/16000 516 a=rtpmap:18 G729/8000 518 If the answerer supports G.729X, it will keep the payload type 98 519 in its answer and the conversation will be done using G.729X. 520 Else, if the answerer supports only G.729, it will leave only the 521 payload type 18 in its answer and the conversation will be done 522 using G.729. 524 o The "dtx" parameter concerns both sending and receiving, so both 525 sides of a bi-directional session MUST use the same "dtx" value. 526 If one party indicates it does not support DTX, DTX must be 527 deactivated both ways. 529 o The "init-MBS" parameter is not symmetric. Values in the offer 530 and the answer are independent and take into account local 531 bandwidth constraints. Anyway, one party MUST NOT start sending 532 frames at a bit rate higher than the "init-MBS" of the other 533 party. 535 o The parameters "maxptime" and "ptime" will in most cases not 536 affect interoperability. The SDP offer-answer handling of the 537 "ptime" parameter is described in [5]. The "maxptime" parameter 538 MUST be handled in the same way. 540 5. Security considerations 542 RTP packets using the payload format defined in this specification 543 are subject to the general security considerations discussed in the 544 RTP specification [2] and any appropriate profile (for example, [3]). 546 As this format transports encoded speech/audio, the main security 547 issues include confidentiality and authentication of the speech/audio 548 itself. The payload format itself does not have any built-in 549 security mechanisms. Confidentiality of the media streams is 550 achieved by encryption, therefore external mechanisms, such as SRTP 551 [6], MAY be used for that purpose. The data compression used with 552 this payload format is applied end-to-end; hence encryption may be 553 performed after compression with no conflict between the two 554 operations. 556 This payload format and the G.729X encoding do not exhibit any 557 significant non-uniformity in the receiver-end computational load and 558 thus in unlikely to pose a denial-of-service threat due to the 559 receipt of pathological datagrams. 561 6. IANA considerations 563 It is requested that one new media subtype (audio/G729X) is 564 registered by IANA, see Section 4.1. 566 7. References 568 7.1 Normative references 570 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 571 Levels", BCP 14, RFC 2119, March 1997. 573 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 574 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 575 RFC 3550, July 2003. 577 [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 578 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 580 [4] Handley, M. and V. Jacobson, "SDP: Session Description 581 Protocol", RFC 2327, April 1998. 583 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 584 Session Description Protocol (SDP)", RFC 3264, June 2002. 586 [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 587 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 588 RFC 3711, March 2004. 590 7.2 Informative references 592 [7] International Telecommunications Union, "Coding of speech at 8 593 kbit/s using conjugate-structure algebraic-code-excited linear- 594 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 596 Author's Address 598 Aurelien Sollaud 599 France Telecom 600 2 avenue Pierre Marzin 601 Lannion Cedex 22307 602 France 604 Phone: +33 2 96 05 15 06 605 Email: aurelien.sollaud@francetelecom.com 607 Intellectual Property Statement 609 The IETF takes no position regarding the validity or scope of any 610 Intellectual Property Rights or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; nor does it represent that it has 614 made any independent effort to identify any such rights. Information 615 on the procedures with respect to rights in RFC documents can be 616 found in BCP 78 and BCP 79. 618 Copies of IPR disclosures made to the IETF Secretariat and any 619 assurances of licenses to be made available, or the result of an 620 attempt made to obtain a general license or permission for the use of 621 such proprietary rights by implementers or users of this 622 specification can be obtained from the IETF on-line IPR repository at 623 http://www.ietf.org/ipr. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights that may cover technology that may be required to implement 628 this standard. Please address the information to the IETF at 629 ietf-ipr@ietf.org. 631 Disclaimer of Validity 633 This document and the information contained herein are provided on an 634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 636 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 637 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 638 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 641 Copyright Statement 643 Copyright (C) The Internet Society (2005). This document is subject 644 to the rights, licenses and restrictions contained in BCP 78, and 645 except as set forth therein, the authors retain all their rights. 647 Acknowledgment 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.