idnits 2.17.1 draft-ietf-avt-rtp-g729-scal-wb-ext-04.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 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 652. ** 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 (April 24, 2006) is 6576 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: October 26, 2006 April 24, 2006 6 RTP payload format for the G.729EV audio codec 7 draft-ietf-avt-rtp-g729-scal-wb-ext-04 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 October 26, 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.729EV 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 . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 13 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.729EV [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.729EV 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.729EV 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.729EV 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.729EV 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.729EV 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.729EV 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, is described in the following payload format (see 151 Section 5.2). Note that it is only useful for two-way unicast 152 G.729EV 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.729EV 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.729EV 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 This is compatible with DTX, with the restriction that the SID frame 308 MUST be at the end of the payload (it is consistent with the payload 309 format of G.729 described in section 4.5.6 of RFC 3551 [4]). Since 310 the SID frame is much smaller than any other frame, it will not 311 hinder the calculation of the number of frames at the receiver side 312 and can be easily detected. Actually the presence of a SID frame 313 will be inferred by the result of the above division not being an 314 integer. 316 Note that if FT=15, there will be no audio frame in the payload. 318 6. Payload format parameters 320 This section defines the parameters that may be used to configure 321 optional features in the G.729EV RTP transmission. 323 The parameters are defined here as part of the media subtype 324 registration for the G.729EV codec. A mapping of the parameters into 325 the Session Description Protocol (SDP) [5] is also provided for those 326 applications that use SDP. In control protocols that do not use MIME 327 or SDP, the media type parameters must be mapped to the appropriate 328 format used with that control protocol. 330 6.1. Media type registration 332 [Note to RFC Editor: Please replace all occurrences of RFC XXXX by 333 the RFC number assigned to this document, and all references to RFC 334 YYYY with the RFC number that will be assigned to the latest SDP 335 specification [5]] 337 This registration is done using the template defined in RFC 4288 [6] 338 and following RFC 3555 [7]. 340 Type name: audio 342 Subtype name: G729EV 344 Required parameters: none 346 Optional parameters: 348 dtx: indicates that discontinuous transmission (DTX) is used or 349 preferred. DTX means voice activity detection and non 350 transmission of silent frames. Permissible values are 0 and 1. 0 351 means no DTX. 0 is implied if this parameter is omitted. The 352 first version of G.729EV will not support DTX, but future annexes 353 are expected to add DTX support which can be signalled using this 354 parameter. 356 maxbitrate: the absolute maximum codec bit rate for the session, in 357 bits per second. Permissible values are 8000, 12000, 14000, 358 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 359 32000 is implied if this parameter is omitted. The maxbitrate 360 restricts the range of bit rates which can be used. The bit rates 361 indicated by FT and MBS fields in the RTP packets MUST NOT exceed 362 maxbitrate. 364 mbs: the current maximum codec bit rate supported as a receiver, in 365 bits per second. Permissible values are in the same set as for 366 the maxbitrate parameter, with the constraint that mbs MUST be 367 lower or equal to maxbitrate. If the mbs parameter is omitted, it 368 is set to the maxbitrate value. So if both mbs and maxbitrate are 369 omitted, they are both set to 32000. The mbs parameter 370 corresponds to a MBS value in the RTP packets as per table in 371 Section 5.2 of RFC XXXX. Note that this parameter may be 372 dynamically updated by the MBS field of the RTP packets sent, it 373 is not an absolute value for the session. 375 ptime: the recommended length of time in milliseconds represented by 376 the media in a packet. See Section 6 of RFC YYYY [5]. 378 maxptime: the maximum length of time in milliseconds which can be 379 encapsulated in a packet. See Section 6 of RFC YYYY [5] 381 Encoding considerations: This media type is framed and contains 382 binary data, see section 4.8 of RFC 4288 [6]. 384 Security considerations: See Section 8 of RFC XXXX 386 Interoperability considerations: none 388 Published specification: RFC XXXX 390 Applications which use this media type: Audio and video conferencing 391 tools. 393 Additional information: none 395 Person & email address to contact for further information: Aurelien 396 Sollaud, aurelien.sollaud@francetelecom.com 398 Intended usage: COMMON 400 Restrictions on usage: This media type depends on RTP framing, and 401 hence is only defined for transfer via RTP [3]. 403 Author: Aurelien Sollaud 404 Change controller: IETF Audio/Video Transport working group delegated 405 from the IESG 407 6.2. Mapping to SDP parameters 409 The information carried in the media type specification has a 410 specific mapping to fields in the Session Description Protocol (SDP) 411 [5], which is commonly used to describe RTP sessions. When SDP is 412 used to specify sessions employing the G.729EV codec, the mapping is 413 as follows: 415 o The media type ("audio") goes in SDP "m=" as the media name. 417 o The media subtype ("G729EV") goes in SDP "a=rtpmap" as the 418 encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for 419 G.729EV. 421 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 422 "a=maxptime" attributes, respectively. 424 o Any remaining parameters go in the SDP "a=fmtp" attribute by 425 copying them directly from the media type string as a semicolon 426 separated list of parameter=value pairs. 428 Some example SDP session descriptions utilizing G.729EV encodings 429 follow. 431 Example 1: default parameters 433 m=audio 53146 RTP/AVP 98 434 a=rtpmap:98 G729EV/16000 436 Example 2: recommended packet duration of 40 ms (=2 frames), maximum 437 bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a 438 loaded PSTN gateway which can operate at 12 kbps but asks to 439 initially reduce the bit rate at 8 kbps. 441 m=audio 51258 RTP/AVP 99 442 a=rtpmap:99 G729EV/16000 443 a=fmtp:99 maxbitrate=12000; mbs=8000 444 a=ptime:40 446 6.2.1. Offer-answer model considerations 448 The following considerations apply when using SDP offer-answer 449 procedures [8] to negotiate the use of G.729EV payload in RTP: 451 o Since G.729EV is an extension of G.729, the offerer SHOULD 452 announce G.729 support in its "m=audio" line, with G.729EV 453 preferred. This will allow interoperability with both G.729EV and 454 G.729-only capable parties. 456 Below is an example of such an offer: 458 m=audio 55954 RTP/AVP 98 18 459 a=rtpmap:98 G729EV/16000 460 a=rtpmap:18 G729/8000 462 If the answerer supports G.729EV, it will keep the payload type 98 463 in its answer and the conversation will be done using G.729EV. 464 Else, if the answerer supports only G.729, it will leave only the 465 payload type 18 in its answer and the conversation will be done 466 using G.729 (the payload format for G.729 is defined in Section 467 4.5.6 of RFC 3551 [4]). 468 Note that when used at 8 kbps in G.729-compatible mode, the 469 G.729EV decoder supports G.729 Annex B. Therefore Annex B can be 470 advertised (by default annexb=yes for G729 media type, see Section 471 4.1.9 of RFC 3555 [7]). 473 o The "dtx" parameter concerns both sending and receiving, so both 474 sides of a bi-directional session MUST use the same "dtx" value. 475 If one party indicates it does not support DTX, DTX must be 476 deactivated both ways. 478 o The "maxbitrate" parameter is bi-directional. If the offerer sets 479 a maxbitrate value, the answerer MUST reply with a smaller or 480 equal value. The actual maximum bit rate for the session will be 481 the minimum. 483 o If the received value for "maxbitrate" is between 8000 and 32000 484 but not in the permissible values set, it SHOULD be read as the 485 closest lower valid value. If the received value is lower than 486 8000 or greater than 32000, the session MUST be rejected. 488 o The "mbs" parameter is not symmetric. Values in the offer and the 489 answer are independent and take into account local constraints. 490 Anyway, one party MUST NOT start sending frames at a bit rate 491 higher than the "mbs" of the other party. The parameter allows to 492 announce this value, prior to the sending of any packet, to avoid 493 the remote sender to exceed the MBS at the beginning of the 494 session. 496 o If the received value for "mbs" is greater or equal to 8000 but 497 not in the permissible values set, it SHOULD be read as the 498 closest lower valid value. If the received value is lower than 499 8000, the session MUST be rejected. 501 o The parameters "ptime" and "maxptime" will in most cases not 502 affect interoperability. The SDP offer-answer handling of the 503 "ptime" parameter is described in RFC 3264 [8]. The "maxptime" 504 parameter MUST be handled in the same way. 506 Some special rules apply for mono-directional traffic: 508 o For sendonly streams, the "mbs" parameter is useless and SHOULD 509 NOT be used. 511 o For recvonly streams, the "mbs" parameter is the only way to 512 communicate the MBS to the sender, since there is no RTP stream 513 towards it. So to request a bit rate change, the receiver will 514 need to use an out-of-band mechanism, like a SIP RE-INIVTE. 516 Some special rules apply for multicast: 518 o The "mbs" parameter MUST NOT be used. 520 o The "maxbitrate" and "dtx" parameter become declarative and MUST 521 NOT be negotiated. These parameters are fixed, and a participant 522 MUST use the configuration that is provided for the session. 524 6.2.2. Declarative SDP considerations 526 For declarative use of SDP such as in SAP [10] and RTSP [11], the 527 following considerations apply: 529 o The "mbs" parameter MUST NOT be used. 531 o The "maxbitrate" and "dtx" parameters are declarative and provide 532 the parameters that SHALL be used when receiving and/or sending 533 the configured stream. 535 7. Congestion control 537 Congestion control for RTP SHALL be used in accordance with RFC 3550 538 [3] and any appropriate profile (for example, RFC 3551 [4]). The 539 embedded and variable bit rates capability of G.729EV provides a 540 mechanism that may help to control congestion, see Section 3. 542 The number of frames encapsulated in each RTP payload influences the 543 overall bandwidth of the RTP stream, due to the header overhead. 545 Packing more frames in each RTP payload can reduce the number of 546 packets sent and hence the header overhead, at the expense of 547 increased delay and reduced error robustness. 549 8. Security considerations 551 RTP packets using the payload format defined in this specification 552 are subject to the general security considerations discussed in the 553 RTP specification [3] and any appropriate profile (for example, RFC 554 3551 [4]). 556 As this format transports encoded speech/audio, the main security 557 issues include confidentiality, integrity protection, and 558 authentication of the speech/audio itself. The payload format itself 559 does not have any built-in security mechanisms. Any suitable 560 external mechanisms, such as SRTP [12], MAY be used. 562 This payload format and the G.729EV encoding do not exhibit any 563 significant non-uniformity in the receiver-end computational load and 564 thus in unlikely to pose a denial-of-service threat due to the 565 receipt of pathological datagrams. 567 9. IANA considerations 569 It is requested that one new media subtype (audio/G729EV) is 570 registered by IANA, see Section 6.1. 572 10. References 574 10.1. Normative references 576 [1] International Telecommunications Union, "An 8-32 kbit/s scalable 577 wideband speech and audio coder bitstream interoperable with 578 G.729", ITU-T Draft Recommendation G.729EV, April 2006. 580 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 581 Levels", BCP 14, RFC 2119, March 1997. 583 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 584 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 585 RFC 3550, July 2003. 587 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 588 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 590 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 591 Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in 592 progress), January 2006. 594 [6] Freed, N. and J. Klensin, "Media Type Specifications and 595 Registration Procedures", BCP 13, RFC 4288, December 2005. 597 [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 598 Payload Formats", RFC 3555, July 2003. 600 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 601 Session Description Protocol (SDP)", RFC 3264, June 2002. 603 10.2. Informative references 605 [9] International Telecommunications Union, "Coding of speech at 8 606 kbit/s using conjugate-structure algebraic-code-excited linear- 607 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 609 [10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 610 Protocol", RFC 2974, October 2000. 612 [11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 613 Protocol (RTSP)", RFC 2326, April 1998. 615 [12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 616 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 617 RFC 3711, March 2004. 619 Author's Address 621 Aurelien Sollaud 622 France Telecom 623 2 avenue Pierre Marzin 624 Lannion Cedex 22307 625 France 627 Phone: +33 2 96 05 15 06 628 Email: aurelien.sollaud@francetelecom.com 630 Intellectual Property Statement 632 The IETF takes no position regarding the validity or scope of any 633 Intellectual Property Rights or other rights that might be claimed to 634 pertain to the implementation or use of the technology described in 635 this document or the extent to which any license under such rights 636 might or might not be available; nor does it represent that it has 637 made any independent effort to identify any such rights. Information 638 on the procedures with respect to rights in RFC documents can be 639 found in BCP 78 and BCP 79. 641 Copies of IPR disclosures made to the IETF Secretariat and any 642 assurances of licenses to be made available, or the result of an 643 attempt made to obtain a general license or permission for the use of 644 such proprietary rights by implementers or users of this 645 specification can be obtained from the IETF on-line IPR repository at 646 http://www.ietf.org/ipr. 648 The IETF invites any interested party to bring to its attention any 649 copyrights, patents or patent applications, or other proprietary 650 rights that may cover technology that may be required to implement 651 this standard. Please address the information to the IETF at 652 ietf-ipr@ietf.org. 654 Disclaimer of Validity 656 This document and the information contained herein are provided on an 657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 659 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 660 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 661 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 664 Copyright Statement 666 Copyright (C) The Internet Society (2006). This document is subject 667 to the rights, licenses and restrictions contained in BCP 78, and 668 except as set forth therein, the authors retain all their rights. 670 Acknowledgment 672 Funding for the RFC Editor function is currently provided by the 673 Internet Society.