idnits 2.17.1 draft-ietf-avt-rtp-g729-scal-wb-ext-02.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 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 595. ** 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 (February 15, 2006) is 6644 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 2327 (ref. '5') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 4288 (ref. '8') (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 3555 (ref. '9') (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 3267 (ref. '10') (Obsoleted by RFC 4867) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 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: August 19, 2006 February 15, 2006 6 RTP payload format for the G.729EV audio codec 7 draft-ietf-avt-rtp-g729-scal-wb-ext-02 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 August 19, 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 . . . . . . . . . . . . . . . . 5 54 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 6 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.3. Offer-answer model considerations . . . . . . . . . . . . 10 60 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 11 61 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 62 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 65 10.2. Informative references . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 Intellectual Property and Copyright Statements . . . . . . . . . . 15 69 1. Introduction 71 The International Telecommunication Union (ITU-T) recommendation 72 G.729EV [1] is a scalable and wideband extension of the 73 recommendation G.729 [7] audio codec. This document specifies the 74 payload format for packetization of G.729EV encoded audio signals 75 into the real-time transport protocol (RTP). 77 The payload format itself is described in Section 5. A media type 78 registration and the details for the use of G.729EV with SDP are 79 given in Section 6. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [2]. 85 2. Background 87 G.729EV is mainly designed to be used as a speech codec, but it can 88 be used for music at the highest bit rates. The sampling frequency 89 is 16000 Hz and the frame size is 20 ms. 91 This G.729-based codec produces an embedded bitstream providing an 92 improved narrow band quality [300, 3400 Hz] at 12 kbps, and an 93 enhanced and gracefully improving wideband quality [50, 7000 Hz] from 94 14 kbps to 32 kbps, by steps of 2 kbps. At 8 kbps it generates a 95 G.729 bitstream. 97 It has been mainly designed for packetized wideband voice 98 applications (Voice over IP or ATM, Telephony over IP, private 99 networks...) and particularly for those requiring scalable bandwidth, 100 enhanced quality above G.729, and easy integration into existing 101 infrastructures. 103 G.729EV is also designed to cope with other services like high 104 quality audio/video conferencing, archival, messaging, etc. 106 For all those applications, the scalability feature allows to tune 107 the bit rate versus quality trade-off, possibly in a dynamic way 108 during a session, taking into account service requirements and 109 network transport constraints. 111 G.729EV produces frames that are said embedded because they are 112 composed of embedded layers. The first layer is called the core 113 layer and is bitstream compatible with the ITU-T G.729 with annex B 114 coder. Upper layers are added while bit rate increases, to improve 115 quality and enlarge audio bandwidth from narrowband to wideband. As 116 a result, a received frame can be decoded at its original bit rate or 117 at any lower bit rate corresponding to lower layers which are 118 embedded. Only the core layer is mandatory to decode understandable 119 speech, upper layers provide quality enhancement and wideband 120 enlargement. 122 Audio codecs often support voice activity detection (VAD) and comfort 123 noise generation (CNG). During silence periods, the coder may 124 significantly decrease the transmitted bit rate by sending only 125 comfort noise parameters in special small frames called silence 126 insertion descriptors (SID). The receiver's decoder will generate 127 comfort noise according to the SID information. This operation of 128 sending low bit rate comfort noise parameters during silence periods 129 is usually called discontinuous transmission (DTX). 131 G.729EV will be first released without support for DTX. Anyway, this 132 functionality is planned and will be defined in a separate annex 133 later. Thus this specification provides DTX signalling, even if the 134 size of a SID frame is not yet standardized. 136 3. Embedded bit rates considerations 138 The embedded property of G.729EV streams provides a mechanism to 139 adjust the bandwidth demand. At any time, a sender can change its 140 sending bit rate without an external signalling, and the receiver 141 will be able to properly decode the frames. It may help to control 142 congestion, since the bandwidth can be adjusted by selecting another 143 bit rate. 145 It may also help to share a fixed bandwidth dedicated to voice calls, 146 for example in a residential or trunking gateway. In that case, the 147 system can change the bit rates depending on the number of 148 simultaneous calls. Since it only impacts the sending bandwidth, we 149 introduce an in-band signalling to request the other party to change 150 its own sending bit rate, in order to adjust the receiving bandwidth 151 as well. This in-band request is called MBS, for Maximum Bit rate 152 Supported, and is described in the following payload format (see 153 Section 5.2). Note that it is only useful for two-way G.729EV 154 traffic, since the MBS request is piggy-backed over the speech frames 155 in the reverse direction. 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 sampling 164 frequency, that is 16 kHz. So the timestamp unit is in samples. 166 The duration of one frame is 20 ms, corresponding to 320 samples per 167 frame. Thus the timestamp is increased by 320 for each consecutive 168 frame. 170 If DTX is used, the first packet of a talkspurt, that is, the first 171 packet after a silence period during which packets have not been 172 transmitted contiguously, SHOULD be distinguished by setting the 173 marker bit (M) in the RTP data header to one. The marker bit in all 174 other packets is zero. The beginning of a talkspurt MAY be used to 175 adjust the playout delay to reflect changing network delays. 177 If DTX is not used, the M bit MUST be set to zero in all packets. 179 The assignment of an RTP payload type for this packet format is 180 outside the scope of the document, and will not be specified here. 181 It is expected that the RTP profile under which this payload format 182 is being used will assign a payload type for this codec or specify 183 that the payload type is to be bound dynamically (see Section 6.2). 185 5. Payload format 187 5.1. Payload structure 189 The complete payload consists of a payload header of 1 octet, 190 followed by audio data representing one or more consecutive frames at 191 the same bit rate. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | MBS | FT | | 197 +-+-+-+-+-+-+-+-+ + 198 : one ore more frames at the same bit rate : 199 : : 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 5.2. Payload Header: MBS field 204 MBS (4 bits): maximum bit rate supported. Indicates a maximum bit 205 rate to the encoder at the site of the receiver of this payload. The 206 value of the MBS field is set according to the following table: 208 +-------+--------------+ 209 | MBS | max bit rate | 210 +-------+--------------+ 211 | 0 | 8 kbps | 212 | 1 | 12 kbps | 213 | 2 | 14 kbps | 214 | 3 | 16 kbps | 215 | 4 | 18 kbps | 216 | 5 | 20 kbps | 217 | 6 | 22 kbps | 218 | 7 | 24 kbps | 219 | 8 | 26 kbps | 220 | 9 | 28 kbps | 221 | 10 | 30 kbps | 222 | 11 | 32 kbps | 223 | 12-14 | (reserved) | 224 | 15 | NO_MBS | 225 +-------+--------------+ 227 The MBS is used to tell the other party the maximum bit rate one can 228 receive. The encoder MUST follow the received MBS. It MUST NOT send 229 frames at a bit rate higher than the received MBS. Thanks to the 230 embedded property of the coding scheme, note that it can send frames 231 at the MBS rate or any lower rate. As long as it does not exceed the 232 MBS, it can change its bit rate at any time without previous notice. 234 The MBS received is valid until the next MBS is received, i.e. a 235 newly received MBS value overrides the previous one. 237 If a payload with an invalid MBS value is received, the MBS MUST be 238 ignored. 240 Note that the MBS is a codec bit rate, the actual network bit rate is 241 higher and depends on the overhead of the underlying protocols. 243 The MBS field MUST be set to 15 for packets sent to a multicast 244 group. 246 The MBS field MUST be set to 15 in all packets when the actual MBS 247 value is sent through non-RTP means. This is out of the scope of 248 this specification. 250 5.3. Payload Header: FT field 252 FT (4 bits): Frame type of the frame(s) in this packet, as per the 253 following table: 255 +-------+---------------+------------+ 256 | FT | encoding rate | frame size | 257 +-------+---------------+------------+ 258 | 0 | 8 kbps | 20 octets | 259 | 1 | 12 kbps | 30 octets | 260 | 2 | 14 kbps | 35 octets | 261 | 3 | 16 kbps | 40 octets | 262 | 4 | 18 kbps | 45 octets | 263 | 5 | 20 kbps | 50 octets | 264 | 6 | 22 kbps | 55 octets | 265 | 7 | 24 kbps | 60 octets | 266 | 8 | 26 kbps | 65 octets | 267 | 9 | 28 kbps | 70 octets | 268 | 10 | 30 kbps | 75 octets | 269 | 11 | 32 kbps | 80 octets | 270 | 12-14 | (reserved) | | 271 | 15 | NO_DATA | 0 | 272 +-------+---------------+------------+ 274 The FT value 15 (NO_DATA) indicates that there is no audio data in 275 the payload. This MAY be used to update the MBS value when there is 276 no audio frame to transmit. The payload will then be reduced to the 277 payload header. 279 If a payload with an invalid FT value is received, the whole payload 280 MUST be ignored. 282 5.4. Audio data 284 Audio data of a payload contains one or more consecutive audio frames 285 at the same bit rate. The audio frames are packed in order of time, 286 that is the older first. 288 The actual number of frame is easy to infer from the size of the 289 audio data part: 291 nb_frames = (size_of_audio_data) / (size_of_one_frame). 293 This is compatible with DTX, with the restriction that the SID frame 294 MUST be at the end of the payload (it is consistent with the payload 295 format of G.729 described in section 4.5.6 of RFC 3551 [4]). Since 296 the SID frame is much smaller than any other frame, it will not 297 hinder the calculation of the number of frames at the receiver side 298 and can be easily detected. Actually the presence of a SID frame 299 will be inferred by the result of the above division not being an 300 integer. 302 Note that if FT=15, there will be no audio frame in the payload. 304 6. Payload format parameters 306 This section defines the parameters that may be used to configure 307 optional features in the G.729EV RTP transmission. 309 The parameters are defined here as part of the media subtype 310 registration for the G.729EV codec. A mapping of the parameters into 311 the Session Description Protocol (SDP) [5] is also provided for those 312 applications that use SDP. In control protocols that do not use MIME 313 or SDP, the media type parameters must be mapped to the appropriate 314 format used with that control protocol. 316 6.1. Media type registration 318 This registration is done using the template defined in RFC 4288 [8] 319 and following RFC 3555 [9]. 321 Type name: audio 323 Subtype name: G729EV 325 Required parameters: none 327 Optional parameters: 329 dtx: indicates that discontinuous transmission (DTX) is used or 330 preferred. DTX means voice activity detection and non 331 transmission of silent frames. Permissible values are 0 and 1. 0 332 means no DTX. 0 is implied if this parameter is omitted. The 333 first version of G.729EV will not support DTX. 335 maxbitrate: the absolute maximum codec bit rate for the session. 336 Permissible values are between 0 and 11 (see table in Section 5.2 337 of RFC XXXX). 11 is implied if this parameter is omitted. The 338 maxbitrate restricts the range of bit rates which can be used. 339 Frames bit rate (FT) and MBS MUST NOT exceed this value. 341 mbs: the initial value of MBS, that is the current maximum codec bit 342 rate supported as a receiver. Permissible values are between 0 343 and maxbitrate (see table in Section 5.2 of RFC XXXX). The 344 maximum MBS value is implied if this parameter is omitted. Note 345 that this parameter will be dynamically updated by the MBS field 346 of the RTP packets sent, it is not an absolute value for the 347 session. The goal is to announce this value, prior to the sending 348 of any packet, to avoid the remote sender to exceed the MBS at the 349 beginning of the session. 351 ptime: the recommended length of time in milliseconds represented by 352 the media in a packet. See Section 6 of RFC 2327 [5]. 354 maxptime: the maximum length of time in milliseconds which can be 355 encapsulated in a packet. See Section 8 of RFC 3267 [10] 357 Encoding considerations: This media type is framed and contains 358 binary data, see section 4.8 of RFC 4288 [8]. 360 Security considerations: See Section 8 of RFC XXXX 362 Interoperability considerations: none 364 Published specification: RFC XXXX 366 Applications which use this media type: Audio and video conferencing 367 tools. 369 Additional information: none 371 Person & email address to contact for further information: Aurelien 372 Sollaud, aurelien.sollaud@francetelecom.com 374 Intended usage: COMMON 376 Restrictions on usage: This media type depends on RTP framing, and 377 hence is only defined for transfer via RTP [3]. 379 Author: Aurelien Sollaud 381 Change controller: IETF Audio/Video Transport working group delegated 382 from the IESG 384 6.2. Mapping to SDP parameters 386 The information carried in the media type specification has a 387 specific mapping to fields in the Session Description Protocol (SDP) 388 [5], which is commonly used to describe RTP sessions. When SDP is 389 used to specify sessions employing the G.729EV codec, the mapping is 390 as follows: 392 o The media type ("audio") goes in SDP "m=" as the media name. 394 o The media subtype ("G729EV") goes in SDP "a=rtpmap" as the 395 encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for 396 G.729EV. 398 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 399 "a=maxptime" attributes, respectively. 401 o Any remaining parameters go in the SDP "a=fmtp" attribute by 402 copying them directly from the media type string as a semicolon 403 separated list of parameter=value pairs. 405 Some example SDP session descriptions utilizing G.729EV encodings 406 follow. 408 Example 1: default parameters 410 m=audio 53146 RTP/AVP 98 411 a=rtpmap:98 G729EV/16000 413 Example 2: recommended packet duration of 40 ms (=2 frames), DTX off, 414 and initial MBS set to 26 kbps 416 m=audio 51258 RTP/AVP 99 417 a=rtpmap:99 G729EV/16000 418 a=fmtp:99 dtx=0; mbs=8 419 a=ptime:40 421 6.3. Offer-answer model considerations 423 The following considerations apply when using SDP offer-answer 424 procedures to negotiate the use of G.729EV payload in RTP: 426 o Since G.729EV is an extension of G.729, the offerer SHOULD 427 announce G.729 support in its "m=audio" line, with G.729EV 428 preferred. This will allow interoperability with both G.729EV and 429 G.729-only capable parties. 431 Below is an example of such an offer: 433 m=audio 55954 RTP/AVP 98 18 434 a=rtpmap:98 G729EV/16000 435 a=rtpmap:18 G729/8000 437 If the answerer supports G.729EV, it will keep the payload type 98 438 in its answer and the conversation will be done using G.729EV. 439 Else, if the answerer supports only G.729, it will leave only the 440 payload type 18 in its answer and the conversation will be done 441 using G.729 (the payload format for G.729 is defined in RFC 3551 442 [4]). 444 o The "dtx" parameter concerns both sending and receiving, so both 445 sides of a bi-directional session MUST use the same "dtx" value. 446 If one party indicates it does not support DTX, DTX must be 447 deactivated both ways. 449 o The "maxbitrate" parameter is bi-directional. If the offerer sets 450 a maxbitrate value, the answerer MUST reply with a smaller or 451 equal value. The actual maximum bit rate for the session will be 452 the minimum. 454 o The "mbs" parameter is not symmetric. Values in the offer and the 455 answer are independent and take into account local constraints. 456 Anyway, one party MUST NOT start sending frames at a bit rate 457 higher than the "mbs" of the other party. 459 o The parameters "ptime" and "maxptime" will in most cases not 460 affect interoperability. The SDP offer-answer handling of the 461 "ptime" parameter is described in RFC 3264 [6]. The "maxptime" 462 parameter MUST be handled in the same way. 464 Some special rules apply for mono-directional traffic: 466 o For sendonly streams, the "mbs" parameter is useless and SHOULD 467 NOT be used. 469 o For recvonly streams, the "mbs" parameter is the only way to 470 communicate the MBS to the sender, since there is no RTP stream 471 towards it. So to request a bit rate change, the receiver will 472 need to use an out-of-band mechanism, like a SIP RE-INIVTE. 474 Some special rules apply for multicast: 476 o The "mbs" parameter is useless and SHOULD NOT be used. 478 o The "maxbitrate" and "dtx" parameter become declarative and MUST 479 NOT be negotiated. These parameters are fixed, and a participant 480 MUST use the configuration that is provided for the session. 482 7. Congestion control 484 Congestion control for RTP SHALL be used in accordance with RFC 3550 485 [3] and any appropriate profile (for example, RFC 3551 [4]). The 486 embedded and variable bit rates capability of G.729EV provides a 487 mechanism that may help to control congestion, see Section 3. 489 The number of frames encapsulated in each RTP payload influences the 490 overall bandwidth of the RTP stream, due to the header overhead. 491 Packing more frames in each RTP payload can reduce the number of 492 packets sent and hence the header overhead, at the expense of 493 increased delay and reduced error robustness. 495 8. Security considerations 497 RTP packets using the payload format defined in this specification 498 are subject to the general security considerations discussed in the 499 RTP specification [3] and any appropriate profile (for example, RFC 500 3551 [4]). 502 As this format transports encoded speech/audio, the main security 503 issues include confidentiality, integrity protection, and 504 authentication of the speech/audio itself. The payload format itself 505 does not have any built-in security mechanisms. Any suitable 506 external mechanisms, such as SRTP [11], MAY be used. 508 This payload format and the G.729EV encoding do not exhibit any 509 significant non-uniformity in the receiver-end computational load and 510 thus in unlikely to pose a denial-of-service threat due to the 511 receipt of pathological datagrams. 513 9. IANA considerations 515 It is requested that one new media subtype (audio/G729EV) is 516 registered by IANA, see Section 6.1. 518 10. References 520 10.1. Normative references 522 [1] International Telecommunications Union, "TBD", ITU- 523 T Recommendation TBD, 2006. 525 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 526 Levels", BCP 14, RFC 2119, March 1997. 528 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 529 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 530 RFC 3550, July 2003. 532 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 533 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 535 [5] Handley, M. and V. Jacobson, "SDP: Session Description 536 Protocol", RFC 2327, April 1998. 538 [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 539 Session Description Protocol (SDP)", RFC 3264, June 2002. 541 10.2. Informative references 543 [7] International Telecommunications Union, "Coding of speech at 8 544 kbit/s using conjugate-structure algebraic-code-excited linear- 545 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 547 [8] Freed, N. and J. Klensin, "Media Type Specifications and 548 Registration Procedures", BCP 13, RFC 4288, December 2005. 550 [9] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 551 Payload Formats", RFC 3555, July 2003. 553 [10] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real- 554 Time Transport Protocol (RTP) Payload Format and File Storage 555 Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi- 556 Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. 558 [11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 559 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 560 RFC 3711, March 2004. 562 Author's Address 564 Aurelien Sollaud 565 France Telecom 566 2 avenue Pierre Marzin 567 Lannion Cedex 22307 568 France 570 Phone: +33 2 96 05 15 06 571 Email: aurelien.sollaud@francetelecom.com 573 Intellectual Property Statement 575 The IETF takes no position regarding the validity or scope of any 576 Intellectual Property Rights or other rights that might be claimed to 577 pertain to the implementation or use of the technology described in 578 this document or the extent to which any license under such rights 579 might or might not be available; nor does it represent that it has 580 made any independent effort to identify any such rights. Information 581 on the procedures with respect to rights in RFC documents can be 582 found in BCP 78 and BCP 79. 584 Copies of IPR disclosures made to the IETF Secretariat and any 585 assurances of licenses to be made available, or the result of an 586 attempt made to obtain a general license or permission for the use of 587 such proprietary rights by implementers or users of this 588 specification can be obtained from the IETF on-line IPR repository at 589 http://www.ietf.org/ipr. 591 The IETF invites any interested party to bring to its attention any 592 copyrights, patents or patent applications, or other proprietary 593 rights that may cover technology that may be required to implement 594 this standard. Please address the information to the IETF at 595 ietf-ipr@ietf.org. 597 Disclaimer of Validity 599 This document and the information contained herein are provided on an 600 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 601 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 602 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 603 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 604 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 605 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 607 Copyright Statement 609 Copyright (C) The Internet Society (2006). This document is subject 610 to the rights, licenses and restrictions contained in BCP 78, and 611 except as set forth therein, the authors retain all their rights. 613 Acknowledgment 615 Funding for the RFC Editor function is currently provided by the 616 Internet Society.