idnits 2.17.1 draft-sollaud-avt-rtp-g711wb-00.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, updated by RFC 4748 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 634. 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 IETF Trust 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 18, 2008) is 5909 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) Summary: 3 errors (**), 0 flaws (~~), 2 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 Intended status: Standards Track February 18, 2008 5 Expires: August 21, 2008 7 RTP Payload Format for ITU-T Recommendation G.711.1 8 draft-sollaud-avt-rtp-g711wb-00 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 August 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 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.711.1 audio codec. Media type registrations are also 44 included. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4.1. Dynamic Mode Payload Format . . . . . . . . . . . . . . . 5 53 4.1.1. Payload Header . . . . . . . . . . . . . . . . . . . . 5 54 4.1.2. Audio Data . . . . . . . . . . . . . . . . . . . . . . 6 55 4.2. Fixed Mode Payload Format . . . . . . . . . . . . . . . . 6 56 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 7 57 5.1. PCMA-WB Media Type Registration . . . . . . . . . . . . . 7 58 5.2. PCMU-WB Media Type Registration . . . . . . . . . . . . . 8 59 5.3. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 9 60 5.3.1. Offer-Answer Model Considerations . . . . . . . . . . 10 61 5.3.2. Declarative SDP Considerations . . . . . . . . . . . . 12 62 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 12 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 67 9.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.711.1 [1] is an embedded wideband extension of the Recommendation 75 G.711 [9] audio codec. This document specifies a payload format for 76 packetization of G.711.1 encoded audio signals into the Real-time 77 Transport Protocol (RTP). 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [2]. 83 2. Background 85 G.711.1 is a G.711 embedded wideband speech and audio coding 86 algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is 87 fully interoperable with G.711. Hence, an efficient deployment in 88 existing G.711 based VoIP infrastructures is foreseen. 90 The codec operates on 5 ms frames, and the default sampling rate is 91 16 kHz. Input and output at 8 kHz are also supported for narrowband 92 modes. 94 The encoder produces an embedded bitstream structured in three layers 95 corresponding to three available bit rates: 64, 80, and 96 kbps. The 96 bitstream can be truncated at the decoder side or by any component of 97 the communication system to adjust "on the fly" the bit rate to the 98 desired value. 100 The following table gives more details on these layers. 102 +-------+------------------------+---------+ 103 | Layer | Description | Bitrate | 104 +-------+------------------------+---------+ 105 | L0 | G.711 compatible | 64 kbps | 106 | L1 | narrowband enhancement | 16 kbps | 107 | L2 | wideband enhancement | 16 kbps | 108 +-------+------------------------+---------+ 110 Table 1: Layers description 112 The combinations of these 3 layers results in the definition of 4 113 modes, as per the following table. 115 +------+----+----+----+------------+---------+ 116 | Mode | L0 | L1 | L2 | Audio band | Bitrate | 117 +------+----+----+----+------------+---------+ 118 | R1 | x | | | narrowband | 64 kbps | 119 | R2a | x | x | | narrowband | 80 kbps | 120 | R2b | x | | x | wideband | 80 kbps | 121 | R3 | x | x | x | wideband | 96 kbps | 122 +------+----+----+----+------------+---------+ 124 Table 2: Modes description 126 3. RTP Header Usage 128 The format of the RTP header is specified in RFC 3550 [3]. The 129 payload format defined in this document uses the fields of the header 130 in a manner consistent with that specification. 132 The RTP timestamp clock frequency is the same as the default sampling 133 frequency: 16 kHz. 135 G.711.1 has also the capability to operate with 8 kHz sampled input/ 136 output signals. It does not affect the bitstream, and the decoder 137 does not require a priori knowledge about the sampling rate of the 138 original signal at the input of the encoder. Therefore, depending on 139 the implementation and the audio acoustic capabilities of the 140 devices, the input of the encoder and/or the output of the decoder 141 can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST 142 always be used. 144 The duration of one frame is 5 ms, corresponding to 80 samples at 16 145 kHz. Thus the timestamp is increased by 80 for each consecutive 146 frame. 148 G.711.1 does not define anything specific regarding Discontinuous 149 Transmission (DTX), a.k.a. silence suppression. Codec-independant 150 mechanisms may be used, like the generic comfort noise payload format 151 defined in RFC 3389 [10]. For applications which send either no 152 packets or occasional comfort-noise packets during silence, the first 153 packet of a talkspurt, that is, the first packet after a silence 154 period during which packets have not been transmitted contiguously, 155 SHOULD be distinguished by setting the marker bit in the RTP data 156 header to one. The marker bit in all other packets is zero. The 157 beginning of a talkspurt MAY be used to adjust the playout delay to 158 reflect changing network delays. Applications without silence 159 suppression MUST set the marker bit to zero. 161 The assignment of an RTP payload type for this packet format is 162 outside the scope of the document, and will not be specified here. 163 It is expected that the RTP profile under which this payload format 164 is being used will assign a payload type for this codec or specify 165 that the payload type is to be bound dynamically (see Section 5.3). 167 4. Payload Format 169 To take into account the foreseen usages of G.711.1, two sub-formats 170 are defined: dynamic mode and fixed mode. Only one format is allowed 171 per RTP payload type. See Section 5 for configuration details. 173 4.1. Dynamic Mode Payload Format 175 In this configuration, the mode can be changed between payloads, but 176 not within a payload. 178 The complete payload consists of a payload header of 1 octet, 179 followed by one or more consecutive G.711.1 audio frames of the same 180 mode. 182 4.1.1. Payload Header 184 The payload header is illustrated below. 186 0 1 2 3 4 5 6 7 187 +-+-+-+-+-+-+-+-+ 188 |0 0 0 0 0| MI | 189 +-+-+-+-+-+-+-+-+ 191 The 5 most significant bits are reserved for further extension and 192 MUST be set to zero. 194 The MI field (3 bits) gives the mode of the following frame(s) as per 195 the table: 197 +------------+--------------+------------+ 198 | Mode Index | G.711.1 mode | Frame size | 199 +------------+--------------+------------+ 200 | 1 | R1 | 40 octets | 201 | 2 | R2a | 50 octets | 202 | 3 | R2b | 50 octets | 203 | 4 | R3 | 60 octets | 204 +------------+--------------+------------+ 206 Table 3: Modes in payload header 208 All other values of MI are reserved for future used and MUST NOT be 209 used. 211 Payloads received with an undefined MI value MUST be discarded. 213 4.1.2. Audio Data 215 After this payload header, the audio frames are packed in order of 216 time, that is, oldest first. All frames MUST be of the same mode, 217 indicated by the MI field of the payload header. 219 Within a frame, layers are always packed in the same order: L0 then 220 L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode 221 R3. This is illustrated bellow. 223 +-------------------------------+ 224 R1 | L0 | 225 +-------------------------------+ 227 +-------------------------------+--------+ 228 R2a | L0 | L1 | 229 +-------------------------------+--------+ 231 +-------------------------------+--------+ 232 R2b | L0 | L2 | 233 +-------------------------------+--------+ 235 +-------------------------------+--------+--------+ 236 R3 | L0 | L1 | L2 | 237 +-------------------------------+--------+--------+ 239 The size of one frame is given by the mode, as per Table 3, and the 240 actual number of frames is easy to infer from the size of the audio 241 data part: 243 nb_frames = (size_of_audio_data) / (size_of_one_frame). 245 Only full frames must be considered. So if there is a remainder to 246 the division above, the corresponding remaining bytes in the received 247 payload MUST be ignored. 249 4.2. Fixed Mode Payload Format 251 In this configuration, the G.711.1 mode is fixed by the signaling. 252 So one RTP payload type is attached to a single mode. 254 The payload simply consists of one or more consecutive G.711.1 audio 255 frames of the fixed mode. There is no payload header. 257 The audio frames are packed in order of time, that is, oldest first. 259 The layer packing within a frame, and the frame count considerations, 260 are the same as in Section 4.2 262 5. Payload Format Parameters 264 This section defines the parameters that may be used to configure 265 optional features in the G.711.1 RTP transmission. 267 Both A-law and mu-law G.711 are supported in the core layer L0, but 268 there is no interoperability between A-law and mu-law. So two media 269 types with the same parameters will be defined: audio/PCMA-WB for 270 A-law core, and audio/PCMU-WB for mu-law core. This is consistent 271 with the audio/PCMA and audio/PCMU media types separation for G.711 272 audio. 274 The parameters are defined here as part of the media subtype 275 registrations for the G.711.1 codec. A mapping of the parameters 276 into the Session Description Protocol (SDP) [5] is also provided for 277 those applications that use SDP. In control protocols that do not 278 use MIME or SDP, the media type parameters must be mapped to the 279 appropriate format used with that control protocol. 281 5.1. PCMA-WB Media Type Registration 283 [Note to RFC Editor: Please replace all occurrences of RFC XXXX by 284 the RFC number assigned to this document] 286 This registration is done using the template defined in RFC 4288 [6] 287 and following RFC 4855 [7]. 289 Type name: audio 291 Subtype name: PCMA-WB 293 Required parameters: none 295 Optional parameters: 297 fixed-mode: the fixed mode of the stream. Possible values are 1, 2, 298 3, or 4 (see Table 3 of RFC XXXX). If fixed-mode is specified, 299 the fixed mode payload format MUST be used (see Section 4.2 of RFC 300 XXXX), and frames encoded with other modes than fixed-mode MUST 301 NOT be sent in any payload. If fixed-mode is not present, the 302 dynamic mode payload format (see Section 4.1 of RFC XXXX) MUST be 303 used. 305 ptime: the recommended length of time (in milliseconds) represented 306 by the media in a packet. See Section 6 of RFC 4566. 308 maxptime: the maximum length of time (in milliseconds) that can be 309 encapsulated in a packet. See Section 6 of RFC 4566. 311 Encoding considerations: This media type is framed and contains 312 binary data; see Section 4.8 of RFC 4288. 314 Security considerations: See Section 7 of RFC XXXX 316 Interoperability considerations: none 318 Published specification: RFC XXXX 320 Applications which use this media type: Audio and video conferencing 321 tools. 323 Additional information: none 325 Person & email address to contact for further information: Aurelien 326 Sollaud, aurelien.sollaud@orange-ftgroup.com 328 Intended usage: COMMON 330 Restrictions on usage: This media type depends on RTP framing, and 331 hence is only defined for transfer via RTP. 333 Author: Aurelien Sollaud 335 Change controller: IETF Audio/Video Transport working group delegated 336 from the IESG 338 5.2. PCMU-WB Media Type Registration 340 This registration is done using the template defined in RFC 4288 [6] 341 and following RFC 4855 [7]. 343 Type name: audio 345 Subtype name: PCMU-WB 347 Required parameters: none 349 Optional parameters: 351 fixed-mode: the fixed mode of the stream. Possible values are 1, 2, 352 3, or 4 (see Table 3 of RFC XXXX). If fixed-mode is specified, 353 the fixed mode payload format MUST be used (see Section 4.2 of RFC 354 XXXX), and frames encoded with other modes than fixed-mode MUST 355 NOT be sent in any payload. If fixed-mode is not present, the 356 dynamic mode payload format (see Section 4.1 of RFC XXXX) MUST be 357 used. 359 ptime: the recommended length of time (in milliseconds) represented 360 by the media in a packet. See Section 6 of RFC 4566. 362 maxptime: the maximum length of time (in milliseconds) that can be 363 encapsulated in a packet. See Section 6 of RFC 4566. 365 Encoding considerations: This media type is framed and contains 366 binary data; see Section 4.8 of RFC 4288. 368 Security considerations: See Section 7 of RFC XXXX 370 Interoperability considerations: none 372 Published specification: RFC XXXX 374 Applications which use this media type: Audio and video conferencing 375 tools. 377 Additional information: none 379 Person & email address to contact for further information: Aurelien 380 Sollaud, aurelien.sollaud@orange-ftgroup.com 382 Intended usage: COMMON 384 Restrictions on usage: This media type depends on RTP framing, and 385 hence is only defined for transfer via RTP. 387 Author: Aurelien Sollaud 389 Change controller: IETF Audio/Video Transport working group delegated 390 from the IESG 392 5.3. Mapping to SDP Parameters 394 The information carried in the media type specification has a 395 specific mapping to fields in the Session Description Protocol (SDP) 396 [5], which is commonly used to describe RTP sessions. When SDP is 397 used to specify sessions employing the G.711.1 codec, the mapping is 398 as follows: 400 o The media type ("audio") goes in SDP "m=" as the media name. 402 o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap" 403 as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 404 16000 for G.711.1. 406 o The parameter "fixed-mode" goes in the SDP "a=fmtp" attribute by 407 copying it as a "fixed-mode=" string. 409 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 410 "a=maxptime" attributes, respectively. 412 5.3.1. Offer-Answer Model Considerations 414 The following considerations apply when using SDP offer-answer 415 procedures [8] to negotiate the use of G.711.1 payload in RTP: 417 o Since G.711.1 is an extension of G.711, the offerer SHOULD 418 announce G.711 support in its "m=audio" line, with G.711.1 419 preferred. This will allow interoperability with both G.711.1 and 420 G.711-only capable parties. 422 Below is an example part of such an offer: 424 m=audio 54874 RTP/AVP 96 8 425 a=rtpmap:96 PCMA-WB/16000 426 a=rtpmap:8 PCMA/8000 428 As a reminder, the payload format for G.711 is defined in Section 429 4.5.14 of RFC 3551 [4]. 431 o The parameter "fixed-mode" is bi-directional, i.e., the restricted 432 mode applies to media both to be received and sent by the 433 declaring entity. If a mode is supplied in the offer, the 434 answerer MUST return the same mode or remove the payload type. If 435 "fixed-mode" is not present in the offer, the anwerer may return a 436 "fixed-mode" to restrict the possible mode. In any cases, the 437 mode in the answer then applies for both offerer and answerer. 438 The offerer MUST NOT send frames of a mode that has been removed 439 by the answerer. 441 For multicast sessions, if "fixed-mode" is supplied in the offer, 442 the answerer SHALL only participate in the session if it supports 443 the offered mode. 445 o The parameters "ptime" and "maxptime" will in most cases not 446 affect interoperability. The SDP offer-answer handling of the 447 "ptime" parameter is described in RFC 3264 [8]. The "maxptime" 448 parameter MUST be handled in the same way. 450 o Any unknown parameter in an offer MUST be ignored by the receiver 451 and MUST NOT be included in the answer. 453 Below are some example parts of SDP offer-answer exchanges. 455 o Example 1 457 Offer: dynamic mode 458 m=audio 54874 RTP/AVP 96 459 a=rtpmap:96 PCMA-WB/16000 461 Answer: dynamic mode accepted 462 m=audio 59452 RTP/AVP 96 463 a=rtpmap:96 PCMA-WB/16000 465 o Example 2 467 Offer: dynamic mode 468 m=audio 54874 RTP/AVP 96 469 a=rtpmap:96 PCMA-WB/16000 471 Answer: wants only mode R3 472 m=audio 59452 RTP/AVP 96 473 a=rtpmap:96 PCMA-WB/16000 474 a=fmtp:96 fixed-mode=4 476 o Example 3 478 Offer: two fixed modes, R2b and R3, with R3 preferred 479 m=audio 54874 RTP/AVP 96 97 480 a=rtpmap:96 PCMA-WB/16000 481 a=fmtp:96 fixed-mode=4 482 a=rtpmap:97 PCMA-WB/16000 483 a=fmtp:97 fixed-mode=3 485 Answer: accepted 486 m=audio 59452 RTP/AVP 96 97 487 a=rtpmap:96 PCMA-WB/16000 488 a=fmtp:96 fixed-mode=4 489 a=rtpmap:97 PCMA-WB/16000 490 a=fmtp:97 fixed-mode=3 492 If the answerer wanted to restrict to one mode, it would have 493 removed the unwanted payload type. 495 5.3.2. Declarative SDP Considerations 497 For declarative use of SDP, nothing specific is defined for this 498 payload format. The configuration given by the SDP MUST be used when 499 sending and/or receiving media in the session. 501 6. Congestion Control 503 Congestion control for RTP SHALL be used in accordance with RFC 3550 504 [3] and any appropriate profile (for example, RFC 3551 [4]). 506 The embedded nature of G.711.1 audio data can be helpful for 507 congestion control, since a coding mode with a lower bit rate can be 508 selected when needed. When using the dynamic mode payload format, it 509 is can be done directly. When using the fixed mode payload format, 510 it can be done by switching to another payload type, if several modes 511 were negociated. 513 The number of frames encapsulated in each RTP payload influences the 514 overall bandwidth of the RTP stream, due to the header overhead. 515 Packing more frames in each RTP payload can reduce the number of 516 packets sent and hence the header overhead, at the expense of 517 increased delay and reduced error robustness. 519 7. Security Considerations 521 RTP packets using the payload format defined in this specification 522 are subject to the general security considerations discussed in the 523 RTP specification [3] and any appropriate profile (for example, RFC 524 3551 [4]). 526 As this format transports encoded speech/audio, the main security 527 issues include confidentiality, integrity protection, and 528 authentication of the speech/audio itself. The payload format itself 529 does not have any built-in security mechanisms. Any suitable 530 external mechanisms, such as SRTP [11], MAY be used. 532 This payload format and the G.711.1 encoding do not exhibit any 533 significant non-uniformity in the receiver-end computational load and 534 thus are unlikely to pose a denial-of-service threat due to the 535 receipt of pathological datagrams. 537 8. IANA Considerations 539 It is requested that two new media subtype (audio/PCMA-WB and audio/ 540 PCMU-WB) are registered by IANA, see Section 5.1 and Section 5.2. 542 9. References 544 9.1. Normative References 546 [1] International Telecommunications Union, "Wideband embedded 547 extension for G.711 pulse code modulation", ITU- 548 T Recommendation G.711.1 [awaiting approval], ? 2008. 550 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 551 Levels", BCP 14, RFC 2119, March 1997. 553 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 554 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 555 RFC 3550, July 2003. 557 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 558 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 560 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 561 Description Protocol", RFC 4566, July 2006. 563 [6] Freed, N. and J. Klensin, "Media Type Specifications and 564 Registration Procedures", BCP 13, RFC 4288, December 2005. 566 [7] Casner, S., "Media Type Registration of RTP Payload Formats", 567 RFC 4855, February 2007. 569 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 570 Session Description Protocol (SDP)", RFC 3264, June 2002. 572 9.2. Informative References 574 [9] International Telecommunications Union, "Pulse code modulation 575 (PCM) of voice frequencies", ITU-T Recommendation G.711, 576 November 1988. 578 [10] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 579 Comfort Noise (CN)", RFC 3389, September 2002. 581 [11] 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@orange-ftgroup.com 596 Full Copyright Statement 598 Copyright (C) The IETF Trust (2008). 600 This document is subject to the rights, licenses and restrictions 601 contained in BCP 78, and except as set forth therein, the authors 602 retain all their rights. 604 This document and the information contained herein are provided on an 605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 607 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 608 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 609 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 Intellectual Property 614 The IETF takes no position regarding the validity or scope of any 615 Intellectual Property Rights or other rights that might be claimed to 616 pertain to the implementation or use of the technology described in 617 this document or the extent to which any license under such rights 618 might or might not be available; nor does it represent that it has 619 made any independent effort to identify any such rights. Information 620 on the procedures with respect to rights in RFC documents can be 621 found in BCP 78 and BCP 79. 623 Copies of IPR disclosures made to the IETF Secretariat and any 624 assurances of licenses to be made available, or the result of an 625 attempt made to obtain a general license or permission for the use of 626 such proprietary rights by implementers or users of this 627 specification can be obtained from the IETF on-line IPR repository at 628 http://www.ietf.org/ipr. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights that may cover technology that may be required to implement 633 this standard. Please address the information to the IETF at 634 ietf-ipr@ietf.org. 636 Acknowledgment 638 Funding for the RFC Editor function is provided by the IETF 639 Administrative Support Activity (IASA).