idnits 2.17.1 draft-ietf-avt-rtp-g729-scal-wb-ext-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. ** 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 (May 17, 2006) is 6546 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 4288 (ref. '6') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3555 (ref. '7') (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '11') (Obsoleted by RFC 7826) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: November 18, 2006 May 17, 2006 6 RTP payload format for the G.729.1 audio codec 7 draft-ietf-avt-rtp-g729-scal-wb-ext-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document specifies a real-time transport protocol (RTP) payload 41 format to be used for the International Telecommunication Union 42 (ITU-T) G.729.1 audio codec. A media type registration is included 43 for this payload format. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Embedded bit rates considerations . . . . . . . . . . . . . . 4 50 4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4 51 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5 53 5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 6 54 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 7 55 5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Payload format parameters . . . . . . . . . . . . . . . . . . 8 57 6.1. Media type registration . . . . . . . . . . . . . . . . . 8 58 6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9 59 6.2.1. Offer-answer model considerations . . . . . . . . . . 10 60 6.2.2. Declarative SDP considerations . . . . . . . . . . . . 12 61 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12 62 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 63 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 66 10.2. Informative references . . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Intellectual Property and Copyright Statements . . . . . . . . . . 16 70 1. Introduction 72 The International Telecommunication Union (ITU-T) recommendation 73 G.729.1 [1] is a scalable and wideband extension of the 74 recommendation G.729 [9] audio codec. This document specifies the 75 payload format for packetization of G.729.1 encoded audio signals 76 into the real-time transport protocol (RTP). 78 The payload format itself is described in Section 5. A media type 79 registration and the details for the use of G.729.1 with SDP are 80 given in Section 6. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [2]. 86 2. Background 88 G.729.1 is a 8-32 kbps scalable wideband (50-7000 Hz) speech and 89 audio coding algorithm interoperable with G.729, G.729 Annex A, and 90 G.729 Annex B. It provides a standardized solution for packetized 91 voice applications that allows a smooth transition from narrowband to 92 wideband telephony. 94 The most important services addressed are IP telephony and 95 videoconferencing, either for enterprise corporate networks or for 96 mass market (like PSTN emulation over DSL or wireless access). 97 Target devices can be IP phones or other VoIP handsets, home 98 gateways, media gateways, IPBX, trunking equipment, voice messaging 99 servers, etc. 101 For all those applications, the scalability feature allows to tune 102 the bit rate versus quality trade-off, possibly in a dynamic way 103 during a session, taking into account service requirements and 104 network transport constraints. 106 The G.729.1 coder produces an embedded bitstream structured in 12 107 layers corresponding to 12 available bit rates between 8 and 32 kbps. 108 The first layer, at 8 kbps, is called the core layer and is bitstream 109 compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second 110 layer improves the narrowband quality. Upper layers provides 111 wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps 112 granularity allowing graceful quality improvements. Only the core 113 layer is mandatory to decode understandable speech, upper layers 114 provide quality enhancement and wideband enlargement. 116 The codec operates on 20 ms frames, and the default sampling rate is 117 16 kHz. Input and output at 8 kHz is also supported, at all bit 118 rates. 120 Audio codecs often support voice activity detection (VAD) and comfort 121 noise generation (CNG). During silence periods, the coder may 122 significantly decrease the transmitted bit rate by sending only 123 comfort noise parameters in special small frames called silence 124 insertion descriptors (SID). The receiver's decoder will generate 125 comfort noise according to the SID information. This operation of 126 sending low bit rate comfort noise parameters during silence periods 127 is usually called discontinuous transmission (DTX). 129 G.729.1 will be first released without support for DTX. Anyway, this 130 functionality is planned and will be defined in a separate annex 131 later. Thus this specification provides DTX signalling, even if the 132 size and content of a SID frame are not yet standardized. 134 3. Embedded bit rates considerations 136 The embedded property of G.729.1 streams provides a mechanism to 137 adjust the bandwidth demand. At any time, a sender can change its 138 sending bit rate without an external signalling, and the receiver 139 will be able to properly decode the frames. It may help to control 140 congestion, since the bandwidth can be adjusted by selecting another 141 bit rate. 143 It may also help to share a fixed bandwidth dedicated to voice calls, 144 for example in a residential or trunking gateway. In that case, the 145 system can change the bit rates depending on the number of 146 simultaneous calls. Since it only impacts the sending bandwidth, we 147 introduce an in-band signalling to request the other party to change 148 its own sending bit rate, in order to adjust the receiving bandwidth 149 as well. This in-band request is called MBS, for Maximum Bit rate 150 Supported. It is described in the following payload format (see 151 Section 5.2). Note that it is only useful for two-way unicast 152 G.729.1 traffic, because when A sends an in-band MBS to B, it is to 153 request B to modify its sending bit rate, that is for the stream from 154 B to A. If there is no G.729.1 stream in the reverse direction, the 155 MBS will have no effect. 157 4. RTP header usage 159 The format of the RTP header is specified in RFC 3550 [3]. This 160 payload format uses the fields of the header in a manner consistent 161 with that specification. 163 The RTP timestamp clock frequency is the same as the default sampling 164 frequency, that is 16 kHz. 166 G.729.1 has also the capability to operate with 8 kHz sampled input/ 167 output signals at all bit rates. It does not affect the bitstream 168 and the decoder does not require a priori knowledge about the 169 sampling rate of the original signal at the input of the encoder. 170 Therefore, depending on the implementation and the audio acoustic 171 capabilities of the devices, the input of the encoder and/or the 172 output of the decoder can be configured at 8 kHz; however, a 16 kHz 173 RTP clock rate MUST always be used. 175 The duration of one frame is 20 ms, corresponding to 320 samples at 176 16 kHz. Thus the timestamp is increased by 320 for each consecutive 177 frame. 179 If DTX is used, the first packet of a talkspurt, that is, the first 180 packet after a silence period during which packets have not been 181 transmitted contiguously, SHOULD be distinguished by setting the 182 marker bit (M) in the RTP data header to one. The marker bit in all 183 other packets is zero. The beginning of a talkspurt MAY be used to 184 adjust the playout delay to reflect changing network delays. 186 If DTX is not used, the M bit MUST be set to zero in all packets. 188 The assignment of an RTP payload type for this packet format is 189 outside the scope of the document, and will not be specified here. 190 It is expected that the RTP profile under which this payload format 191 is being used will assign a payload type for this codec or specify 192 that the payload type is to be bound dynamically (see Section 6.2). 194 5. Payload format 196 5.1. Payload structure 198 The complete payload consists of a payload header of 1 octet, 199 generally followed by audio data representing one or more consecutive 200 frames at the same bit rate. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | MBS | FT | | 206 +-+-+-+-+-+-+-+-+ + 207 : zero or more frames at the same bit rate : 208 : : 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 5.2. Payload Header: MBS field 213 MBS (4 bits): maximum bit rate supported. Indicates a maximum bit 214 rate to the encoder at the site of the receiver of this payload. The 215 value of the MBS field is set according to the following table: 217 +-------+--------------+ 218 | MBS | max bit rate | 219 +-------+--------------+ 220 | 0 | 8 kbps | 221 | 1 | 12 kbps | 222 | 2 | 14 kbps | 223 | 3 | 16 kbps | 224 | 4 | 18 kbps | 225 | 5 | 20 kbps | 226 | 6 | 22 kbps | 227 | 7 | 24 kbps | 228 | 8 | 26 kbps | 229 | 9 | 28 kbps | 230 | 10 | 30 kbps | 231 | 11 | 32 kbps | 232 | 12-14 | (reserved) | 233 | 15 | NO_MBS | 234 +-------+--------------+ 236 The MBS is used to tell the other party the maximum bit rate one can 237 receive. The encoder MUST NOT exceed the sending rate indicated by 238 the received MBS. Thanks to the embedded property of the coding 239 scheme, note that it can send frames at the MBS rate or any lower 240 rate. As long as it does not exceed the MBS, it can change its bit 241 rate at any time without previous notice. 243 Note that the MBS is a codec bit rate, the actual network bit rate is 244 higher and depends on the overhead of the underlying protocols. 246 The MBS received is valid until the next MBS is received, i.e. a 247 newly received MBS value overrides the previous one. 249 If a payload with an invalid MBS value is received, the MBS MUST be 250 ignored. 252 The MBS field MUST be set to 15 for packets sent to a multicast 253 group, and MUST be ignored on packets received from a multicast 254 group. 256 The MBS field MUST be set to 15 in all packets when the actual MBS 257 value is sent through non-RTP means. This is out of the scope of 258 this specification. 260 See Section 3 and Section 7 for more details on the use of MBS for 261 congestion control. 263 5.3. Payload Header: FT field 265 FT (4 bits): Frame type of the frame(s) in this packet, as per the 266 following table: 268 +-------+---------------+------------+ 269 | FT | encoding rate | frame size | 270 +-------+---------------+------------+ 271 | 0 | 8 kbps | 20 octets | 272 | 1 | 12 kbps | 30 octets | 273 | 2 | 14 kbps | 35 octets | 274 | 3 | 16 kbps | 40 octets | 275 | 4 | 18 kbps | 45 octets | 276 | 5 | 20 kbps | 50 octets | 277 | 6 | 22 kbps | 55 octets | 278 | 7 | 24 kbps | 60 octets | 279 | 8 | 26 kbps | 65 octets | 280 | 9 | 28 kbps | 70 octets | 281 | 10 | 30 kbps | 75 octets | 282 | 11 | 32 kbps | 80 octets | 283 | 12-14 | (reserved) | | 284 | 15 | NO_DATA | 0 | 285 +-------+---------------+------------+ 287 The FT value 15 (NO_DATA) indicates that there is no audio data in 288 the payload. This MAY be used to update the MBS value when there is 289 no audio frame to transmit. The payload will then be reduced to the 290 payload header. 292 If a payload with an invalid FT value is received, the whole payload 293 MUST be ignored. 295 5.4. Audio data 297 Audio data of a payload contains one or more consecutive audio frames 298 at the same bit rate. The audio frames are packed in order of time, 299 that is the older first. 301 The size of one frame is given by the FT field, as per the table in 302 Section 5.3, and the actual number of frame is easy to infer from the 303 size of the audio data part: 305 nb_frames = (size_of_audio_data) / (size_of_one_frame). 307 Note that if FT=15, there will be no audio frame in the payload. 309 6. Payload format parameters 311 This section defines the parameters that may be used to configure 312 optional features in the G.729.1 RTP transmission. 314 The parameters are defined here as part of the media subtype 315 registration for the G.729.1 codec. A mapping of the parameters into 316 the Session Description Protocol (SDP) [5] is also provided for those 317 applications that use SDP. In control protocols that do not use MIME 318 or SDP, the media type parameters must be mapped to the appropriate 319 format used with that control protocol. 321 6.1. Media type registration 323 [Note to RFC Editor: Please replace all occurrences of RFC XXXX by 324 the RFC number assigned to this document, and all references to RFC 325 YYYY with the RFC number that will be assigned to the latest SDP 326 specification [5]] 328 This registration is done using the template defined in RFC 4288 [6] 329 and following RFC 3555 [7]. 331 Type name: audio 333 Subtype name: G7291 335 Required parameters: none 337 Optional parameters: 339 dtx: indicates that discontinuous transmission (DTX) is used or 340 preferred. DTX means voice activity detection and non 341 transmission of silent frames. Permissible values are 0 and 1. 0 342 means no DTX. 0 is implied if this parameter is omitted. The 343 first version of G.729.1 will not support DTX, but future annexes 344 are expected to add DTX support which can be signalled using this 345 parameter. 347 maxbitrate: the absolute maximum codec bit rate for the session, in 348 bits per second. Permissible values are 8000, 12000, 14000, 349 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 350 32000 is implied if this parameter is omitted. The maxbitrate 351 restricts the range of bit rates which can be used. The bit rates 352 indicated by FT and MBS fields in the RTP packets MUST NOT exceed 353 maxbitrate. 355 mbs: the current maximum codec bit rate supported as a receiver, in 356 bits per second. Permissible values are in the same set as for 357 the maxbitrate parameter, with the constraint that mbs MUST be 358 lower or equal to maxbitrate. If the mbs parameter is omitted, it 359 is set to the maxbitrate value. So if both mbs and maxbitrate are 360 omitted, they are both set to 32000. The mbs parameter 361 corresponds to a MBS value in the RTP packets as per table in 362 Section 5.2 of RFC XXXX. Note that this parameter may be 363 dynamically updated by the MBS field of the RTP packets sent, it 364 is not an absolute value for the session. 366 ptime: the recommended length of time in milliseconds represented by 367 the media in a packet. See Section 6 of RFC YYYY [5]. 369 maxptime: the maximum length of time in milliseconds which can be 370 encapsulated in a packet. See Section 6 of RFC YYYY [5] 372 Encoding considerations: This media type is framed and contains 373 binary data, see section 4.8 of RFC 4288 [6]. 375 Security considerations: See Section 8 of RFC XXXX 377 Interoperability considerations: none 379 Published specification: RFC XXXX 381 Applications which use this media type: Audio and video conferencing 382 tools. 384 Additional information: none 386 Person & email address to contact for further information: Aurelien 387 Sollaud, aurelien.sollaud@francetelecom.com 389 Intended usage: COMMON 391 Restrictions on usage: This media type depends on RTP framing, and 392 hence is only defined for transfer via RTP [3]. 394 Author: Aurelien Sollaud 396 Change controller: IETF Audio/Video Transport working group delegated 397 from the IESG 399 6.2. Mapping to SDP parameters 401 The information carried in the media type specification has a 402 specific mapping to fields in the Session Description Protocol (SDP) 404 [5], which is commonly used to describe RTP sessions. When SDP is 405 used to specify sessions employing the G.729.1 codec, the mapping is 406 as follows: 408 o The media type ("audio") goes in SDP "m=" as the media name. 410 o The media subtype ("G7291") goes in SDP "a=rtpmap" as the encoding 411 name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729.1. 413 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 414 "a=maxptime" attributes, respectively. 416 o Any remaining parameters go in the SDP "a=fmtp" attribute by 417 copying them directly from the media type string as a semicolon 418 separated list of parameter=value pairs. 420 Some example SDP session descriptions utilizing G.729.1 encodings 421 follow. 423 Example 1: default parameters 425 m=audio 53146 RTP/AVP 98 426 a=rtpmap:98 G7291/16000 428 Example 2: recommended packet duration of 40 ms (=2 frames), maximum 429 bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a 430 loaded PSTN gateway which can operate at 12 kbps but asks to 431 initially reduce the bit rate at 8 kbps. 433 m=audio 51258 RTP/AVP 99 434 a=rtpmap:99 G7291/16000 435 a=fmtp:99 maxbitrate=12000; mbs=8000 436 a=ptime:40 438 6.2.1. Offer-answer model considerations 440 The following considerations apply when using SDP offer-answer 441 procedures [8] to negotiate the use of G.729.1 payload in RTP: 443 o Since G.729.1 is an extension of G.729, the offerer SHOULD 444 announce G.729 support in its "m=audio" line, with G.729.1 445 preferred. This will allow interoperability with both G.729.1 and 446 G.729-only capable parties. 448 Below is an example of such an offer: 450 m=audio 55954 RTP/AVP 98 18 451 a=rtpmap:98 G729.1/16000 452 a=rtpmap:18 G729/8000 454 If the answerer supports G.729.1, it will keep the payload type 98 455 in its answer and the conversation will be done using G.729.1. 456 Else, if the answerer supports only G.729, it will leave only the 457 payload type 18 in its answer and the conversation will be done 458 using G.729 (the payload format for G.729 is defined in Section 459 4.5.6 of RFC 3551 [4]). 460 Note that when used at 8 kbps in G.729-compatible mode, the 461 G.729.1 decoder supports G.729 Annex B. Therefore Annex B can be 462 advertised (by default annexb=yes for G729 media type, see Section 463 4.1.9 of RFC 3555 [7]). 465 o The "dtx" parameter concerns both sending and receiving, so both 466 sides of a bi-directional session MUST use the same "dtx" value. 467 If one party indicates it does not support DTX, DTX must be 468 deactivated both ways. 470 o The "maxbitrate" parameter is bi-directional. If the offerer sets 471 a maxbitrate value, the answerer MUST reply with a smaller or 472 equal value. The actual maximum bit rate for the session will be 473 the minimum. 475 o If the received value for "maxbitrate" is between 8000 and 32000 476 but not in the permissible values set, it SHOULD be read as the 477 closest lower valid value. If the received value is lower than 478 8000 or greater than 32000, the session MUST be rejected. 480 o The "mbs" parameter is not symmetric. Values in the offer and the 481 answer are independent and take into account local constraints. 482 Anyway, one party MUST NOT start sending frames at a bit rate 483 higher than the "mbs" of the other party. The parameter allows to 484 announce this value, prior to the sending of any packet, to avoid 485 the remote sender to exceed the MBS at the beginning of the 486 session. 488 o If the received value for "mbs" is greater or equal to 8000 but 489 not in the permissible values set, it SHOULD be read as the 490 closest lower valid value. If the received value is lower than 491 8000, the session MUST be rejected. 493 o The parameters "ptime" and "maxptime" will in most cases not 494 affect interoperability. The SDP offer-answer handling of the 495 "ptime" parameter is described in RFC 3264 [8]. The "maxptime" 496 parameter MUST be handled in the same way. 498 Some special rules apply for mono-directional traffic: 500 o For sendonly streams, the "mbs" parameter is useless and SHOULD 501 NOT be used. 503 o For recvonly streams, the "mbs" parameter is the only way to 504 communicate the MBS to the sender, since there is no RTP stream 505 towards it. So to request a bit rate change, the receiver will 506 need to use an out-of-band mechanism, like a SIP RE-INVITE. 508 Some special rules apply for multicast: 510 o The "mbs" parameter MUST NOT be used. 512 o The "maxbitrate" and "dtx" parameter become declarative and MUST 513 NOT be negotiated. These parameters are fixed, and a participant 514 MUST use the configuration that is provided for the session. 516 6.2.2. Declarative SDP considerations 518 For declarative use of SDP such as in SAP [10] and RTSP [11], the 519 following considerations apply: 521 o The "mbs" parameter MUST NOT be used. 523 o The "maxbitrate" and "dtx" parameters are declarative and provide 524 the parameters that SHALL be used when receiving and/or sending 525 the configured stream. 527 7. Congestion control 529 Congestion control for RTP SHALL be used in accordance with RFC 3550 530 [3] and any appropriate profile (for example, RFC 3551 [4]). The 531 embedded and variable bit rates capability of G.729.1 provides a 532 mechanism that may help to control congestion, see Section 3. 534 The number of frames encapsulated in each RTP payload influences the 535 overall bandwidth of the RTP stream, due to the header overhead. 536 Packing more frames in each RTP payload can reduce the number of 537 packets sent and hence the header overhead, at the expense of 538 increased delay and reduced error robustness. 540 8. Security considerations 541 RTP packets using the payload format defined in this specification 542 are subject to the general security considerations discussed in the 543 RTP specification [3] and any appropriate profile (for example, RFC 544 3551 [4]). 546 As this format transports encoded speech/audio, the main security 547 issues include confidentiality, integrity protection, and 548 authentication of the speech/audio itself. The payload format itself 549 does not have any built-in security mechanisms. Any suitable 550 external mechanisms, such as SRTP [12], MAY be used. 552 This payload format and the G.729.1 encoding do not exhibit any 553 significant non-uniformity in the receiver-end computational load and 554 thus in unlikely to pose a denial-of-service threat due to the 555 receipt of pathological datagrams. 557 9. IANA considerations 559 It is requested that one new media subtype (audio/G7291) is 560 registered by IANA, see Section 6.1. 562 10. References 564 10.1. Normative references 566 [1] International Telecommunications Union, "An 8-32 kbit/s scalable 567 wideband speech and audio coder bitstream interoperable with 568 G.729", ITU-T Draft Recommendation G.729.1, April 2006. 570 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 571 Levels", BCP 14, RFC 2119, March 1997. 573 [3] 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 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 578 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 580 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 581 Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in 582 progress), January 2006. 584 [6] Freed, N. and J. Klensin, "Media Type Specifications and 585 Registration Procedures", BCP 13, RFC 4288, December 2005. 587 [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 588 Payload Formats", RFC 3555, July 2003. 590 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 591 Session Description Protocol (SDP)", RFC 3264, June 2002. 593 10.2. Informative references 595 [9] International Telecommunications Union, "Coding of speech at 8 596 kbit/s using conjugate-structure algebraic-code-excited linear- 597 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 599 [10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 600 Protocol", RFC 2974, October 2000. 602 [11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 603 Protocol (RTSP)", RFC 2326, April 1998. 605 [12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 606 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 607 RFC 3711, March 2004. 609 Author's Address 611 Aurelien Sollaud 612 France Telecom 613 2 avenue Pierre Marzin 614 Lannion Cedex 22307 615 France 617 Phone: +33 2 96 05 15 06 618 Email: aurelien.sollaud@francetelecom.com 620 Intellectual Property Statement 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org. 644 Disclaimer of Validity 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 649 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 650 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 651 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Copyright Statement 656 Copyright (C) The Internet Society (2006). This document is subject 657 to the rights, licenses and restrictions contained in BCP 78, and 658 except as set forth therein, the authors retain all their rights. 660 Acknowledgment 662 Funding for the RFC Editor function is currently provided by the 663 Internet Society.