idnits 2.17.1 draft-ietf-avt-rtp-g729-scal-wb-ext-03.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 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. ** 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 (March 1, 2006) is 6631 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) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: September 2, 2006 March 1, 2006 6 RTP payload format for the G.729EV audio codec 7 draft-ietf-avt-rtp-g729-scal-wb-ext-03 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 September 2, 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 . . . . . . . . . . . . . . . . . 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.3. Offer-answer model considerations . . . . . . . . . . . . 10 60 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12 61 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 62 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 65 10.2. Informative references . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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 [9] 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 and content of a SID frame are 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 NOT exceed the sending rate indicated by 229 the received MBS. Thanks to the embedded property of the coding 230 scheme, note that it can send frames at the MBS rate or any lower 231 rate. As long as it does not exceed the MBS, it can change its bit 232 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, and MUST be ignored on packets received from a multicast 245 group. 247 The MBS field MUST be set to 15 in all packets when the actual MBS 248 value is sent through non-RTP means. This is out of the scope of 249 this specification. 251 See Section 7 for more details on the use of MBS for congestion 252 control. 254 5.3. Payload Header: FT field 256 FT (4 bits): Frame type of the frame(s) in this packet, as per the 257 following table: 259 +-------+---------------+------------+ 260 | FT | encoding rate | frame size | 261 +-------+---------------+------------+ 262 | 0 | 8 kbps | 20 octets | 263 | 1 | 12 kbps | 30 octets | 264 | 2 | 14 kbps | 35 octets | 265 | 3 | 16 kbps | 40 octets | 266 | 4 | 18 kbps | 45 octets | 267 | 5 | 20 kbps | 50 octets | 268 | 6 | 22 kbps | 55 octets | 269 | 7 | 24 kbps | 60 octets | 270 | 8 | 26 kbps | 65 octets | 271 | 9 | 28 kbps | 70 octets | 272 | 10 | 30 kbps | 75 octets | 273 | 11 | 32 kbps | 80 octets | 274 | 12-14 | (reserved) | | 275 | 15 | NO_DATA | 0 | 276 +-------+---------------+------------+ 278 The FT value 15 (NO_DATA) indicates that there is no audio data in 279 the payload. This MAY be used to update the MBS value when there is 280 no audio frame to transmit. The payload will then be reduced to the 281 payload header. 283 If a payload with an invalid FT value is received, the whole payload 284 MUST be ignored. 286 5.4. Audio data 288 Audio data of a payload contains one or more consecutive audio frames 289 at the same bit rate. The audio frames are packed in order of time, 290 that is the older first. 292 The actual number of frame is easy to infer from the size of the 293 audio data part: 295 nb_frames = (size_of_audio_data) / (size_of_one_frame). 297 This is compatible with DTX, with the restriction that the SID frame 298 MUST be at the end of the payload (it is consistent with the payload 299 format of G.729 described in section 4.5.6 of RFC 3551 [4]). Since 300 the SID frame is much smaller than any other frame, it will not 301 hinder the calculation of the number of frames at the receiver side 302 and can be easily detected. Actually the presence of a SID frame 303 will be inferred by the result of the above division not being an 304 integer. 306 Note that if FT=15, there will be no audio frame in the payload. 308 6. Payload format parameters 310 This section defines the parameters that may be used to configure 311 optional features in the G.729EV RTP transmission. 313 The parameters are defined here as part of the media subtype 314 registration for the G.729EV codec. A mapping of the parameters into 315 the Session Description Protocol (SDP) [5] is also provided for those 316 applications that use SDP. In control protocols that do not use MIME 317 or SDP, the media type parameters must be mapped to the appropriate 318 format used with that control protocol. 320 6.1. Media type registration 322 [Note to RFC Editor: Please replace all occurrences of RFC XXXX by 323 the RFC number assigned to this document, and all references to RFC 324 YYYY with the RFC number that will be assigned to the latest SDP 325 specification [5]] 327 This registration is done using the template defined in RFC 4288 [6] 328 and following RFC 3555 [7]. 330 Type name: audio 332 Subtype name: G729EV 334 Required parameters: none 336 Optional parameters: 338 dtx: indicates that discontinuous transmission (DTX) is used or 339 preferred. DTX means voice activity detection and non 340 transmission of silent frames. Permissible values are 0 and 1. 0 341 means no DTX. 0 is implied if this parameter is omitted. The 342 first version of G.729EV will not support DTX, but future annexes 343 are expected to add DTX support which can be signalled using this 344 parameter. 346 maxbitrate: the absolute maximum codec bit rate for the session, in 347 bits per second. Permissible values are 8000, 12000, 14000, 348 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 349 32000 is implied if this parameter is omitted. The maxbitrate 350 restricts the range of bit rates which can be used. The bit rates 351 indicated by FT and MBS fields in the RTP packets MUST NOT exceed 352 maxbitrate. 354 mbs: the current maximum codec bit rate supported as a receiver, in 355 bits per second. Permissible values are in the same set as for 356 the maxbitrate parameter, with the constraint that mbs MUST be 357 lower or equal to maxbitrate. If the mbs parameter is omitted, it 358 is set to the maxbitrate value. So if both mbs and maxbitrate are 359 omitted, they are both set to 32000. The mbs parameter 360 corresponds to a MBS value in the RTP packets as per table in 361 Section 5.2 of RFC XXXX. Note that this parameter will be 362 dynamically updated by the MBS field of the RTP packets sent, it 363 is not an absolute value for the session. The goal is to announce 364 this value, prior to the sending of any packet, to avoid the 365 remote sender to exceed the MBS at the beginning of the session. 367 ptime: the recommended length of time in milliseconds represented by 368 the media in a packet. See Section 6 of RFC YYYY [5]. 370 maxptime: the maximum length of time in milliseconds which can be 371 encapsulated in a packet. See Section 6 of RFC YYYY [5] 373 Encoding considerations: This media type is framed and contains 374 binary data, see section 4.8 of RFC 4288 [6]. 376 Security considerations: See Section 8 of RFC XXXX 378 Interoperability considerations: none 380 Published specification: RFC XXXX 382 Applications which use this media type: Audio and video conferencing 383 tools. 385 Additional information: none 387 Person & email address to contact for further information: Aurelien 388 Sollaud, aurelien.sollaud@francetelecom.com 390 Intended usage: COMMON 392 Restrictions on usage: This media type depends on RTP framing, and 393 hence is only defined for transfer via RTP [3]. 395 Author: Aurelien Sollaud 397 Change controller: IETF Audio/Video Transport working group delegated 398 from the IESG 400 6.2. Mapping to SDP parameters 402 The information carried in the media type specification has a 403 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.729EV 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 ("G729EV") goes in SDP "a=rtpmap" as the 411 encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for 412 G.729EV. 414 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 415 "a=maxptime" attributes, respectively. 417 o Any remaining parameters go in the SDP "a=fmtp" attribute by 418 copying them directly from the media type string as a semicolon 419 separated list of parameter=value pairs. 421 Some example SDP session descriptions utilizing G.729EV encodings 422 follow. 424 Example 1: default parameters 426 m=audio 53146 RTP/AVP 98 427 a=rtpmap:98 G729EV/16000 429 Example 2: recommended packet duration of 40 ms (=2 frames), DTX off, 430 and initial MBS set to 26 kbps 432 m=audio 51258 RTP/AVP 99 433 a=rtpmap:99 G729EV/16000 434 a=fmtp:99 dtx=0; mbs=26000 435 a=ptime:40 437 6.3. Offer-answer model considerations 439 The following considerations apply when using SDP offer-answer 440 procedures to negotiate the use of G.729EV payload in RTP: 442 o Since G.729EV is an extension of G.729, the offerer SHOULD 443 announce G.729 support in its "m=audio" line, with G.729EV 444 preferred. This will allow interoperability with both G.729EV and 445 G.729-only capable parties. 447 Below is an example of such an offer: 449 m=audio 55954 RTP/AVP 98 18 450 a=rtpmap:98 G729EV/16000 451 a=rtpmap:18 G729/8000 453 If the answerer supports G.729EV, it will keep the payload type 98 454 in its answer and the conversation will be done using G.729EV. 455 Else, if the answerer supports only G.729, it will leave only the 456 payload type 18 in its answer and the conversation will be done 457 using G.729 (the payload format for G.729 is defined in RFC 3551 458 [4]). 460 o The "dtx" parameter concerns both sending and receiving, so both 461 sides of a bi-directional session MUST use the same "dtx" value. 462 If one party indicates it does not support DTX, DTX must be 463 deactivated both ways. 465 o The "maxbitrate" parameter is bi-directional. If the offerer sets 466 a maxbitrate value, the answerer MUST reply with a smaller or 467 equal value. The actual maximum bit rate for the session will be 468 the minimum. 470 o If the received value for "maxbitrate" is between 8000 and 32000 471 but not in the permissible values set, it SHOULD be read as the 472 closest lower valid value. If the received value is lower than 473 8000 or greater than 32000, the session MUST be rejected. 475 o The "mbs" parameter is not symmetric. Values in the offer and the 476 answer are independent and take into account local constraints. 477 Anyway, one party MUST NOT start sending frames at a bit rate 478 higher than the "mbs" of the other party. 480 o If the received value for "mbs" is greater or equal to 8000 but 481 not in the permissible values set, it SHOULD be read as the 482 closest lower valid value. If the received value is lower than 483 8000, the session MUST be rejected. 485 o The parameters "ptime" and "maxptime" will in most cases not 486 affect interoperability. The SDP offer-answer handling of the 487 "ptime" parameter is described in RFC 3264 [8]. The "maxptime" 488 parameter MUST be handled in the same way. 490 Some special rules apply for mono-directional traffic: 492 o For sendonly streams, the "mbs" parameter is useless and SHOULD 493 NOT be used. 495 o For recvonly streams, the "mbs" parameter is the only way to 496 communicate the MBS to the sender, since there is no RTP stream 497 towards it. So to request a bit rate change, the receiver will 498 need to use an out-of-band mechanism, like a SIP RE-INIVTE. 500 Some special rules apply for multicast: 502 o The "mbs" parameter is useless and SHOULD NOT be used. 504 o The "maxbitrate" and "dtx" parameter become declarative and MUST 505 NOT be negotiated. These parameters are fixed, and a participant 506 MUST use the configuration that is provided for the session. 508 7. Congestion control 510 Congestion control for RTP SHALL be used in accordance with RFC 3550 511 [3] and any appropriate profile (for example, RFC 3551 [4]). The 512 embedded and variable bit rates capability of G.729EV provides a 513 mechanism that may help to control congestion, see Section 3. 515 The number of frames encapsulated in each RTP payload influences the 516 overall bandwidth of the RTP stream, due to the header overhead. 517 Packing more frames in each RTP payload can reduce the number of 518 packets sent and hence the header overhead, at the expense of 519 increased delay and reduced error robustness. 521 8. Security considerations 523 RTP packets using the payload format defined in this specification 524 are subject to the general security considerations discussed in the 525 RTP specification [3] and any appropriate profile (for example, RFC 526 3551 [4]). 528 As this format transports encoded speech/audio, the main security 529 issues include confidentiality, integrity protection, and 530 authentication of the speech/audio itself. The payload format itself 531 does not have any built-in security mechanisms. Any suitable 532 external mechanisms, such as SRTP [10], MAY be used. 534 This payload format and the G.729EV encoding do not exhibit any 535 significant non-uniformity in the receiver-end computational load and 536 thus in unlikely to pose a denial-of-service threat due to the 537 receipt of pathological datagrams. 539 9. IANA considerations 541 It is requested that one new media subtype (audio/G729EV) is 542 registered by IANA, see Section 6.1. 544 10. References 546 10.1. Normative references 548 [1] International Telecommunications Union, "TBD", ITU- 549 T Recommendation TBD, 2006. 551 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 552 Levels", BCP 14, RFC 2119, March 1997. 554 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 555 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 556 RFC 3550, July 2003. 558 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 559 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 561 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 562 Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in 563 progress), January 2006. 565 [6] Freed, N. and J. Klensin, "Media Type Specifications and 566 Registration Procedures", BCP 13, RFC 4288, December 2005. 568 [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 569 Payload Formats", RFC 3555, July 2003. 571 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 572 Session Description Protocol (SDP)", RFC 3264, June 2002. 574 10.2. Informative references 576 [9] International Telecommunications Union, "Coding of speech at 8 577 kbit/s using conjugate-structure algebraic-code-excited linear- 578 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 580 [10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 582 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 583 RFC 3711, March 2004. 585 Author's Address 587 Aurelien Sollaud 588 France Telecom 589 2 avenue Pierre Marzin 590 Lannion Cedex 22307 591 France 593 Phone: +33 2 96 05 15 06 594 Email: aurelien.sollaud@francetelecom.com 596 Intellectual Property Statement 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Disclaimer of Validity 622 This document and the information contained herein are provided on an 623 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 624 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 625 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 626 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 627 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Copyright Statement 632 Copyright (C) The Internet Society (2006). This document is subject 633 to the rights, licenses and restrictions contained in BCP 78, and 634 except as set forth therein, the authors retain all their rights. 636 Acknowledgment 638 Funding for the RFC Editor function is currently provided by the 639 Internet Society.