idnits 2.17.1 draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. ** 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 issues found here. 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 (August 28, 2006) is 6413 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 4566 (ref. '5') (Obsoleted by RFC 8866) ** 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: 6 errors (**), 0 flaws (~~), 2 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 Intended status: Standards Track August 28, 2006 5 Expires: March 1, 2007 7 RTP payload format for the G.729.1 audio codec 8 draft-ietf-avt-rtp-g729-scal-wb-ext-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 1, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document specifies a real-time transport protocol (RTP) payload 42 format to be used for the International Telecommunication Union 43 (ITU-T) G.729.1 audio codec. A media type registration is included 44 for this payload format. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Embedded bit rates considerations . . . . . . . . . . . . . . 4 51 4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5 53 5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5 54 5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 5 55 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 7 56 5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Payload format parameters . . . . . . . . . . . . . . . . . . 8 58 6.1. Media type registration . . . . . . . . . . . . . . . . . 8 59 6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9 60 6.2.1. Offer-answer model considerations . . . . . . . . . . 10 61 6.2.2. Declarative SDP considerations . . . . . . . . . . . . 12 62 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12 63 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 64 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 67 10.2. Informative references . . . . . . . . . . . . . . . . . . 13 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Introduction 73 The International Telecommunication Union (ITU-T) recommendation 74 G.729.1 [1] is a scalable and wideband extension of the 75 recommendation G.729 [9] audio codec. This document specifies the 76 payload format for packetization of G.729.1 encoded audio signals 77 into the real-time transport protocol (RTP). 79 The payload format itself is described in Section 5. A media type 80 registration and the details for the use of G.729.1 with SDP are 81 given in Section 6. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [2]. 87 2. Background 89 G.729.1 is a 8-32 kbps scalable wideband (50-7000 Hz) speech and 90 audio coding algorithm interoperable with G.729, G.729 Annex A, and 91 G.729 Annex B. It provides a standardized solution for packetized 92 voice applications that allows a smooth transition from narrowband to 93 wideband telephony. 95 The most important services addressed are IP telephony and 96 videoconferencing, either for enterprise corporate networks or for 97 mass market (like PSTN emulation over DSL or wireless access). 98 Target devices can be IP phones or other VoIP handsets, home 99 gateways, media gateways, IPBX, trunking equipment, voice messaging 100 servers, etc. 102 For all those applications, the scalability feature allows to tune 103 the bit rate versus quality trade-off, possibly in a dynamic way 104 during a session, taking into account service requirements and 105 network transport constraints. 107 The G.729.1 coder produces an embedded bitstream structured in 12 108 layers corresponding to 12 available bit rates between 8 and 32 kbps. 109 The first layer, at 8 kbps, is called the core layer and is bitstream 110 compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second 111 layer improves the narrowband quality. Upper layers provides 112 wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps 113 granularity allowing graceful quality improvements. Only the core 114 layer is mandatory to decode understandable speech, upper layers 115 provide quality enhancement and wideband enlargement. 117 The codec operates on 20 ms frames, and the default sampling rate is 118 16 kHz. Input and output at 8 kHz are also supported, at all bit 119 rates. 121 3. Embedded bit rates considerations 123 The embedded property of G.729.1 streams provides a mechanism to 124 adjust the bandwidth demand. At any time, a sender can change its 125 sending bit rate without an external signalling, and the receiver 126 will be able to properly decode the frames. It may help to control 127 congestion, since the bandwidth can be adjusted by selecting another 128 bit rate. 130 The ability to adjust the bandwidth may also help when having a fixed 131 bandwidth link dedicated to voice calls, for example in a residential 132 or trunking gateway. In that case, the system can change the bit 133 rates depending on the number of simultaneous calls. Since it only 134 impacts the sending bandwidth, we introduce an in-band signalling to 135 request the other party to change its own sending bit rate, in order 136 to adjust the receiving bandwidth as well. This in-band request is 137 called MBS, for Maximum Bit rate Supported. It is described in 138 Section 5.2. Note that it is only useful for two-way unicast G.729.1 139 traffic, because when A sends an in-band MBS to B, it is to request B 140 to modify its sending bit rate, that is for the stream from B to A. 141 If there is no G.729.1 stream in the reverse direction, the MBS will 142 have no effect. 144 4. RTP header usage 146 The format of the RTP header is specified in RFC 3550 [3]. This 147 payload format uses the fields of the header in a manner consistent 148 with that specification. 150 The RTP timestamp clock frequency is the same as the default sampling 151 frequency, that is 16 kHz. 153 G.729.1 has also the capability to operate with 8 kHz sampled input/ 154 output signals at all bit rates. It does not affect the bitstream 155 and the decoder does not require a priori knowledge about the 156 sampling rate of the original signal at the input of the encoder. 157 Therefore, depending on the implementation and the audio acoustic 158 capabilities of the devices, the input of the encoder and/or the 159 output of the decoder can be configured at 8 kHz; however, a 16 kHz 160 RTP clock rate MUST always be used. 162 The duration of one frame is 20 ms, corresponding to 320 samples at 163 16 kHz. Thus the timestamp is increased by 320 for each consecutive 164 frame. 166 The M bit MUST be set to zero in all packets. 168 The assignment of an RTP payload type for this packet format is 169 outside the scope of the document, and will not be specified here. 170 It is expected that the RTP profile under which this payload format 171 is being used will assign a payload type for this codec or specify 172 that the payload type is to be bound dynamically (see Section 6.2). 174 5. Payload format 176 5.1. Payload structure 178 The complete payload consists of a payload header of 1 octet, 179 followed by zero or more consecutive audio frames at the same bit 180 rate. 182 The payload header consists of two fields: MBS (see Section 5.2) and 183 FT (see Section 5.3). 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | MBS | FT | | 189 +-+-+-+-+-+-+-+-+ + 190 : zero or more frames at the same bit rate : 191 : : 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 5.2. Payload Header: MBS field 196 MBS (4 bits): maximum bit rate supported. Indicates a maximum bit 197 rate to the encoder at the site of the receiver of this payload. The 198 value of the MBS field is set according to the following table: 200 +-------+--------------+ 201 | MBS | max bit rate | 202 +-------+--------------+ 203 | 0 | 8 kbps | 204 | 1 | 12 kbps | 205 | 2 | 14 kbps | 206 | 3 | 16 kbps | 207 | 4 | 18 kbps | 208 | 5 | 20 kbps | 209 | 6 | 22 kbps | 210 | 7 | 24 kbps | 211 | 8 | 26 kbps | 212 | 9 | 28 kbps | 213 | 10 | 30 kbps | 214 | 11 | 32 kbps | 215 | 12-14 | (reserved) | 216 | 15 | NO_MBS | 217 +-------+--------------+ 219 The MBS is used to tell the other party the maximum bit rate one can 220 receive. The encoder MUST NOT exceed the sending rate indicated by 221 the received MBS. Thanks to the embedded property of the coding 222 scheme, note that it can send frames at the MBS rate or any lower 223 rate. As long as it does not exceed the MBS, it can change its bit 224 rate at any time without previous notice. 226 Note that the MBS is a codec bit rate, the actual network bit rate is 227 higher and depends on the overhead of the underlying protocols. 229 The MBS received is valid until the next MBS is received, i.e. a 230 newly received MBS value overrides the previous one. 232 If a payload with a reserved MBS value is received, the MBS MUST be 233 ignored. 235 The MBS field MUST be set to 15 for packets sent to a multicast 236 group, and MUST be ignored on packets received from a multicast 237 group. 239 The MBS field MUST be set to 15 in all packets when the actual MBS 240 value is sent through non-RTP means. This is out of the scope of 241 this specification. 243 See Section 3 and Section 7 for more details on the use of MBS for 244 congestion control. 246 5.3. Payload Header: FT field 248 FT (4 bits): Frame type of the frame(s) in this packet, as per the 249 following table: 251 +-------+---------------+------------+ 252 | FT | encoding rate | frame size | 253 +-------+---------------+------------+ 254 | 0 | 8 kbps | 20 octets | 255 | 1 | 12 kbps | 30 octets | 256 | 2 | 14 kbps | 35 octets | 257 | 3 | 16 kbps | 40 octets | 258 | 4 | 18 kbps | 45 octets | 259 | 5 | 20 kbps | 50 octets | 260 | 6 | 22 kbps | 55 octets | 261 | 7 | 24 kbps | 60 octets | 262 | 8 | 26 kbps | 65 octets | 263 | 9 | 28 kbps | 70 octets | 264 | 10 | 30 kbps | 75 octets | 265 | 11 | 32 kbps | 80 octets | 266 | 12-14 | (reserved) | | 267 | 15 | NO_DATA | 0 | 268 +-------+---------------+------------+ 270 The FT value 15 (NO_DATA) indicates that there is no audio data in 271 the payload. This MAY be used to update the MBS value when there is 272 no audio frame to transmit. The payload will then be reduced to the 273 payload header. 275 If a payload with a reserved FT value is received, the whole payload 276 MUST be ignored. 278 5.4. Audio data 280 Audio data of a payload contains one or more consecutive audio frames 281 at the same bit rate. The audio frames are packed in order of time, 282 that is the older first. 284 The size of one frame is given by the FT field, as per the table in 285 Section 5.3, and the actual number of frames is easy to infer from 286 the size of the audio data part: 288 nb_frames = (size_of_audio_data) / (size_of_one_frame). 290 Only full frames must be considered. So if there is a remainder to 291 the division above, the corresponding remaining bytes in the received 292 payload MUST be ignored. 294 Note that if FT=15, there will be no audio frame in the payload. 296 6. Payload format parameters 298 This section defines the parameters that may be used to configure 299 optional features in the G.729.1 RTP transmission. 301 The parameters are defined here as part of the media subtype 302 registration for the G.729.1 codec. A mapping of the parameters into 303 the Session Description Protocol (SDP) [5] is also provided for those 304 applications that use SDP. In control protocols that do not use MIME 305 or SDP, the media type parameters must be mapped to the appropriate 306 format used with that control protocol. 308 6.1. Media type registration 310 [Note to RFC Editor: Please replace all occurrences of RFC XXXX by 311 the RFC number assigned to this document] 313 This registration is done using the template defined in RFC 4288 [6] 314 and following RFC 3555 [7]. 316 Type name: audio 318 Subtype name: G7291 320 Required parameters: none 322 Optional parameters: 324 maxbitrate: the absolute maximum codec bit rate for the session, in 325 bits per second. Permissible values are 8000, 12000, 14000, 326 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 327 32000 is implied if this parameter is omitted. The maxbitrate 328 restricts the range of bit rates which can be used. The bit rates 329 indicated by FT and MBS fields in the RTP packets MUST NOT exceed 330 maxbitrate. 332 mbs: the current maximum codec bit rate supported as a receiver, in 333 bits per second. Permissible values are in the same set as for 334 the maxbitrate parameter, with the constraint that mbs MUST be 335 lower or equal to maxbitrate. If the mbs parameter is omitted, it 336 is set to the maxbitrate value. So if both mbs and maxbitrate are 337 omitted, they are both set to 32000. The mbs parameter 338 corresponds to a MBS value in the RTP packets as per table in 339 Section 5.2 of RFC XXXX. Note that this parameter may be 340 dynamically updated by the MBS field of the RTP packets sent, it 341 is not an absolute value for the session. 343 ptime: the recommended length of time in milliseconds represented by 344 the media in a packet. See Section 6 of RFC 4566 [5]. 346 maxptime: the maximum length of time in milliseconds which can be 347 encapsulated in a packet. See Section 6 of RFC 4566 [5] 349 Encoding considerations: This media type is framed and contains 350 binary data, see section 4.8 of RFC 4288 [6]. 352 Security considerations: See Section 8 of RFC XXXX 354 Interoperability considerations: none 356 Published specification: RFC XXXX 358 Applications which use this media type: Audio and video conferencing 359 tools. 361 Additional information: none 363 Person & email address to contact for further information: Aurelien 364 Sollaud, aurelien.sollaud@orange-ft.com 366 Intended usage: COMMON 368 Restrictions on usage: This media type depends on RTP framing, and 369 hence is only defined for transfer via RTP [3]. 371 Author: Aurelien Sollaud 373 Change controller: IETF Audio/Video Transport working group delegated 374 from the IESG 376 6.2. Mapping to SDP parameters 378 The information carried in the media type specification has a 379 specific mapping to fields in the Session Description Protocol (SDP) 380 [5], which is commonly used to describe RTP sessions. When SDP is 381 used to specify sessions employing the G.729.1 codec, the mapping is 382 as follows: 384 o The media type ("audio") goes in SDP "m=" as the media name. 386 o The media subtype ("G7291") goes in SDP "a=rtpmap" as the encoding 387 name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729.1. 389 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 390 "a=maxptime" attributes, respectively. 392 o Any remaining parameters go in the SDP "a=fmtp" attribute by 393 copying them directly from the media type string as a semicolon 394 separated list of parameter=value pairs. 396 Some example SDP session descriptions utilizing G.729.1 encodings 397 follow. 399 Example 1: default parameters 401 m=audio 53146 RTP/AVP 98 402 a=rtpmap:98 G7291/16000 404 Example 2: recommended packet duration of 40 ms (=2 frames), maximum 405 bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a 406 loaded PSTN gateway which can operate at 12 kbps but asks to 407 initially reduce the bit rate at 8 kbps. 409 m=audio 51258 RTP/AVP 99 410 a=rtpmap:99 G7291/16000 411 a=fmtp:99 maxbitrate=12000; mbs=8000 412 a=ptime:40 414 6.2.1. Offer-answer model considerations 416 The following considerations apply when using SDP offer-answer 417 procedures [8] to negotiate the use of G.729.1 payload in RTP: 419 o Since G.729.1 is an extension of G.729, the offerer SHOULD 420 announce G.729 support in its "m=audio" line, with G.729.1 421 preferred. This will allow interoperability with both G.729.1 and 422 G.729-only capable parties. 424 Below is an example of such an offer: 426 m=audio 55954 RTP/AVP 98 18 427 a=rtpmap:98 G7291/16000 428 a=rtpmap:18 G729/8000 430 If the answerer supports G.729.1, it will keep the payload type 98 431 in its answer and the conversation will be done using G.729.1. 432 Else, if the answerer supports only G.729, it will leave only the 433 payload type 18 in its answer and the conversation will be done 434 using G.729 (the payload format for G.729 is defined in Section 435 4.5.6 of RFC 3551 [4]). 436 Note that when used at 8 kbps in G.729-compatible mode, the 437 G.729.1 decoder supports G.729 Annex B. Therefore Annex B can be 438 advertised (by default annexb=yes for G729 media type, see Section 439 4.1.9 of RFC 3555 [7]). 441 o The "maxbitrate" parameter is bi-directional. If the offerer sets 442 a maxbitrate value, the answerer MUST reply with a smaller or 443 equal value. The actual maximum bit rate for the session will be 444 the minimum. 446 o If the received value for "maxbitrate" is between 8000 and 32000 447 but not in the permissible values set, it SHOULD be read as the 448 closest lower valid value. If the received value is lower than 449 8000 or greater than 32000, the session MUST be rejected. 451 o The "mbs" parameter is not symmetric. Values in the offer and the 452 answer are independent and take into account local constraints. 453 One party MUST NOT start sending frames at a bit rate higher than 454 the "mbs" of the other party. The parameter allows to announce 455 this value, prior to the sending of any packet, to avoid the 456 remote sender to exceed the MBS at the beginning of the session. 458 o If the received value for "mbs" is greater or equal to 8000 but 459 not in the permissible values set, it SHOULD be read as the 460 closest lower valid value. If the received value is lower than 461 8000, the session MUST be rejected. 463 o The parameters "ptime" and "maxptime" will in most cases not 464 affect interoperability. The SDP offer-answer handling of the 465 "ptime" parameter is described in RFC 3264 [8]. The "maxptime" 466 parameter MUST be handled in the same way. 468 o Any unkown parameter in an offer MUST be ignored by the receiver, 469 and MUST NOT be included in the answer. 471 Some special rules apply for mono-directional traffic: 473 o For sendonly streams, the "mbs" parameter is useless and SHOULD 474 NOT be used. 476 o For recvonly streams, the "mbs" parameter is the only way to 477 communicate the MBS to the sender, since there is no RTP stream 478 towards it. So to request a bit rate change, the receiver will 479 need to use an out-of-band mechanism, like a SIP RE-INVITE. 481 Some special rules apply for multicast: 483 o The "mbs" parameter MUST NOT be used. 485 o The "maxbitrate" parameter becomes declarative and MUST NOT be 486 negotiated. This parameter is fixed, and a participant MUST use 487 the configuration that is provided for the session. 489 6.2.2. Declarative SDP considerations 491 For declarative use of SDP such as in SAP [10] and RTSP [11], the 492 following considerations apply: 494 o The "mbs" parameter MUST NOT be used. 496 o The "maxbitrate" parameter is declarative and provide the 497 parameter that SHALL be used when receiving and/or sending the 498 configured stream. 500 7. Congestion control 502 Congestion control for RTP SHALL be used in accordance with RFC 3550 503 [3] and any appropriate profile (for example, RFC 3551 [4]). The 504 embedded and variable bit rates capability of G.729.1 provides a 505 mechanism that may help to control congestion, see Section 3 for more 506 details. 508 The number of frames encapsulated in each RTP payload influences the 509 overall bandwidth of the RTP stream, due to the header overhead. 510 Packing more frames in each RTP payload can reduce the number of 511 packets sent and hence the header overhead, at the expense of 512 increased delay and reduced error robustness. 514 8. Security considerations 516 RTP packets using the payload format defined in this specification 517 are subject to the general security considerations discussed in the 518 RTP specification [3] and any appropriate profile (for example, RFC 519 3551 [4]). 521 As this format transports encoded speech/audio, the main security 522 issues include confidentiality, integrity protection, and 523 authentication of the speech/audio itself. The payload format itself 524 does not have any built-in security mechanisms. Any suitable 525 external mechanisms, such as SRTP [12], MAY be used. 527 This payload format and the G.729.1 encoding do not exhibit any 528 significant non-uniformity in the receiver-end computational load and 529 thus in unlikely to pose a denial-of-service threat due to the 530 receipt of pathological datagrams. 532 9. IANA considerations 534 It is requested that one new media subtype (audio/G7291) is 535 registered by IANA, see Section 6.1. 537 10. References 539 10.1. Normative references 541 [1] International Telecommunications Union, "G.729 based Embedded 542 Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder 543 bitstream interoperable with G.729", ITU-T Recommendation 544 G.729.1, May 2006. 546 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 547 Levels", BCP 14, RFC 2119, March 1997. 549 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 550 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 551 RFC 3550, July 2003. 553 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 554 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 556 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 557 Description Protocol", RFC 4566, July 2006. 559 [6] Freed, N. and J. Klensin, "Media Type Specifications and 560 Registration Procedures", BCP 13, RFC 4288, December 2005. 562 [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 563 Payload Formats", RFC 3555, July 2003. 565 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 566 Session Description Protocol (SDP)", RFC 3264, June 2002. 568 10.2. Informative references 570 [9] International Telecommunications Union, "Coding of speech at 8 571 kbit/s using conjugate-structure algebraic-code-excited linear- 572 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 574 [10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 575 Protocol", RFC 2974, October 2000. 577 [11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 578 Protocol (RTSP)", RFC 2326, April 1998. 580 [12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 581 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 582 RFC 3711, March 2004. 584 Author's Address 586 Aurelien Sollaud 587 France Telecom 588 2 avenue Pierre Marzin 589 Lannion Cedex 22307 590 France 592 Phone: +33 2 96 05 15 06 593 Email: aurelien.sollaud@orange-ft.com 595 Full Copyright Statement 597 Copyright (C) The Internet Society (2006). 599 This document is subject to the rights, licenses and restrictions 600 contained in BCP 78, and except as set forth therein, the authors 601 retain all their rights. 603 This document and the information contained herein are provided on an 604 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 605 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 606 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 607 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 608 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 609 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 611 Intellectual Property 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Acknowledgment 637 Funding for the RFC Editor function is provided by the IETF 638 Administrative Support Activity (IASA).