Network Working Group A. Sollaud Internet-Draft France Telecom Expires: October 26, 2006 April 24, 2006 RTP payload format for the G.729EV audio codec draft-ietf-avt-rtp-g729-scal-wb-ext-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a real-time transport protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729EV audio codec. A media type registration is included for this payload format. Sollaud Expires October 26, 2006 [Page 1] Internet-Draft RTP payload format for G.729EV April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Embedded bit rates considerations . . . . . . . . . . . . . . 4 4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5 5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 6 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 7 5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Payload format parameters . . . . . . . . . . . . . . . . . . 8 6.1. Media type registration . . . . . . . . . . . . . . . . . 8 6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 10 6.2.1. Offer-answer model considerations . . . . . . . . . . 10 6.2.2. Declarative SDP considerations . . . . . . . . . . . . 12 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 10.2. Informative references . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Sollaud Expires October 26, 2006 [Page 2] Internet-Draft RTP payload format for G.729EV April 2006 1. Introduction The International Telecommunication Union (ITU-T) recommendation G.729EV [1] is a scalable and wideband extension of the recommendation G.729 [9] audio codec. This document specifies the payload format for packetization of G.729EV encoded audio signals into the real-time transport protocol (RTP). The payload format itself is described in Section 5. A media type registration and the details for the use of G.729EV with SDP are given in Section 6. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 2. Background G.729EV is a 8-32 kbps scalable wideband (50-7000 Hz) speech and audio coding algorithm interoperable with G.729, G.729 Annex A, and G.729 Annex B. It provides a standardized solution for packetized voice applications that allows a smooth transition from narrowband to wideband telephony. The most important services addressed are IP telephony and videoconferencing, either for enterprise corporate networks or for mass market (like PSTN emulation over DSL or wireless access). Target devices can be IP phones or other VoIP handsets, home gateways, media gateways, IPBX, trunking equipment, voice messaging servers, etc. For all those applications, the scalability feature allows to tune the bit rate versus quality trade-off, possibly in a dynamic way during a session, taking into account service requirements and network transport constraints. The G.729EV coder produces an embedded bitstream structured in 12 layers corresponding to 12 available bit rates between 8 and 32 kbps. The first layer, at 8 kbps, is called the core layer and is bitstream compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second layer improves the narrowband quality. Upper layers provides wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps granularity allowing graceful quality improvements. Only the core layer is mandatory to decode understandable speech, upper layers provide quality enhancement and wideband enlargement. The codec operates on 20 ms frames, and the default sampling rate is Sollaud Expires October 26, 2006 [Page 3] Internet-Draft RTP payload format for G.729EV April 2006 16 kHz. Input and output at 8 kHz is also supported, at all bit rates. Audio codecs often support voice activity detection (VAD) and comfort noise generation (CNG). During silence periods, the coder may significantly decrease the transmitted bit rate by sending only comfort noise parameters in special small frames called silence insertion descriptors (SID). The receiver's decoder will generate comfort noise according to the SID information. This operation of sending low bit rate comfort noise parameters during silence periods is usually called discontinuous transmission (DTX). G.729EV will be first released without support for DTX. Anyway, this functionality is planned and will be defined in a separate annex later. Thus this specification provides DTX signalling, even if the size and content of a SID frame are not yet standardized. 3. Embedded bit rates considerations The embedded property of G.729EV streams provides a mechanism to adjust the bandwidth demand. At any time, a sender can change its sending bit rate without an external signalling, and the receiver will be able to properly decode the frames. It may help to control congestion, since the bandwidth can be adjusted by selecting another bit rate. It may also help to share a fixed bandwidth dedicated to voice calls, for example in a residential or trunking gateway. In that case, the system can change the bit rates depending on the number of simultaneous calls. Since it only impacts the sending bandwidth, we introduce an in-band signalling to request the other party to change its own sending bit rate, in order to adjust the receiving bandwidth as well. This in-band request is called MBS, for Maximum Bit rate Supported, is described in the following payload format (see Section 5.2). Note that it is only useful for two-way unicast G.729EV traffic, because when A sends an in-band MBS to B, it is to request B to modify its sending bit rate, that is for the stream from B to A. If there is no G.729EV stream in the reverse direction, the MBS will have no effect. 4. RTP header usage The format of the RTP header is specified in RFC 3550 [3]. This payload format uses the fields of the header in a manner consistent with that specification. Sollaud Expires October 26, 2006 [Page 4] Internet-Draft RTP payload format for G.729EV April 2006 The RTP timestamp clock frequency is the same as the default sampling frequency, that is 16 kHz. G.729EV has also the capability to operate with 8 kHz sampled input/ output signals at all bit rates. It does not affect the bitstream and the decoder does not require a priori knowledge about the sampling rate of the original signal at the input of the encoder. Therefore, depending on the implementation and the audio acoustic capabilities of the devices, the input of the encoder and/or the output of the decoder can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST always be used. The duration of one frame is 20 ms, corresponding to 320 samples at 16 kHz. Thus the timestamp is increased by 320 for each consecutive frame. If DTX is used, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit (M) in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. If DTX is not used, the M bit MUST be set to zero in all packets. The assignment of an RTP payload type for this packet format is outside the scope of the document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this codec or specify that the payload type is to be bound dynamically (see Section 6.2). 5. Payload format 5.1. Payload structure The complete payload consists of a payload header of 1 octet, generally followed by audio data representing one or more consecutive frames at the same bit rate. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBS | FT | | +-+-+-+-+-+-+-+-+ + : zero or more frames at the same bit rate : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sollaud Expires October 26, 2006 [Page 5] Internet-Draft RTP payload format for G.729EV April 2006 5.2. Payload Header: MBS field MBS (4 bits): maximum bit rate supported. Indicates a maximum bit rate to the encoder at the site of the receiver of this payload. The value of the MBS field is set according to the following table: +-------+--------------+ | MBS | max bit rate | +-------+--------------+ | 0 | 8 kbps | | 1 | 12 kbps | | 2 | 14 kbps | | 3 | 16 kbps | | 4 | 18 kbps | | 5 | 20 kbps | | 6 | 22 kbps | | 7 | 24 kbps | | 8 | 26 kbps | | 9 | 28 kbps | | 10 | 30 kbps | | 11 | 32 kbps | | 12-14 | (reserved) | | 15 | NO_MBS | +-------+--------------+ The MBS is used to tell the other party the maximum bit rate one can receive. The encoder MUST NOT exceed the sending rate indicated by the received MBS. Thanks to the embedded property of the coding scheme, note that it can send frames at the MBS rate or any lower rate. As long as it does not exceed the MBS, it can change its bit rate at any time without previous notice. Note that the MBS is a codec bit rate, the actual network bit rate is higher and depends on the overhead of the underlying protocols. The MBS received is valid until the next MBS is received, i.e. a newly received MBS value overrides the previous one. If a payload with an invalid MBS value is received, the MBS MUST be ignored. The MBS field MUST be set to 15 for packets sent to a multicast group, and MUST be ignored on packets received from a multicast group. The MBS field MUST be set to 15 in all packets when the actual MBS value is sent through non-RTP means. This is out of the scope of this specification. Sollaud Expires October 26, 2006 [Page 6] Internet-Draft RTP payload format for G.729EV April 2006 See Section 3 and Section 7 for more details on the use of MBS for congestion control. 5.3. Payload Header: FT field FT (4 bits): Frame type of the frame(s) in this packet, as per the following table: +-------+---------------+------------+ | FT | encoding rate | frame size | +-------+---------------+------------+ | 0 | 8 kbps | 20 octets | | 1 | 12 kbps | 30 octets | | 2 | 14 kbps | 35 octets | | 3 | 16 kbps | 40 octets | | 4 | 18 kbps | 45 octets | | 5 | 20 kbps | 50 octets | | 6 | 22 kbps | 55 octets | | 7 | 24 kbps | 60 octets | | 8 | 26 kbps | 65 octets | | 9 | 28 kbps | 70 octets | | 10 | 30 kbps | 75 octets | | 11 | 32 kbps | 80 octets | | 12-14 | (reserved) | | | 15 | NO_DATA | 0 | +-------+---------------+------------+ The FT value 15 (NO_DATA) indicates that there is no audio data in the payload. This MAY be used to update the MBS value when there is no audio frame to transmit. The payload will then be reduced to the payload header. If a payload with an invalid FT value is received, the whole payload MUST be ignored. 5.4. Audio data Audio data of a payload contains one or more consecutive audio frames at the same bit rate. The audio frames are packed in order of time, that is the older first. The size of one frame is given by the FT field, as per the table in Section 5.3, and the actual number of frame is easy to infer from the size of the audio data part: nb_frames = (size_of_audio_data) / (size_of_one_frame). This is compatible with DTX, with the restriction that the SID frame Sollaud Expires October 26, 2006 [Page 7] Internet-Draft RTP payload format for G.729EV April 2006 MUST be at the end of the payload (it is consistent with the payload format of G.729 described in section 4.5.6 of RFC 3551 [4]). Since the SID frame is much smaller than any other frame, it will not hinder the calculation of the number of frames at the receiver side and can be easily detected. Actually the presence of a SID frame will be inferred by the result of the above division not being an integer. Note that if FT=15, there will be no audio frame in the payload. 6. Payload format parameters This section defines the parameters that may be used to configure optional features in the G.729EV RTP transmission. The parameters are defined here as part of the media subtype registration for the G.729EV codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol. 6.1. Media type registration [Note to RFC Editor: Please replace all occurrences of RFC XXXX by the RFC number assigned to this document, and all references to RFC YYYY with the RFC number that will be assigned to the latest SDP specification [5]] This registration is done using the template defined in RFC 4288 [6] and following RFC 3555 [7]. Type name: audio Subtype name: G729EV Required parameters: none Optional parameters: dtx: indicates that discontinuous transmission (DTX) is used or preferred. DTX means voice activity detection and non transmission of silent frames. Permissible values are 0 and 1. 0 means no DTX. 0 is implied if this parameter is omitted. The first version of G.729EV will not support DTX, but future annexes are expected to add DTX support which can be signalled using this parameter. Sollaud Expires October 26, 2006 [Page 8] Internet-Draft RTP payload format for G.729EV April 2006 maxbitrate: the absolute maximum codec bit rate for the session, in bits per second. Permissible values are 8000, 12000, 14000, 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 32000 is implied if this parameter is omitted. The maxbitrate restricts the range of bit rates which can be used. The bit rates indicated by FT and MBS fields in the RTP packets MUST NOT exceed maxbitrate. mbs: the current maximum codec bit rate supported as a receiver, in bits per second. Permissible values are in the same set as for the maxbitrate parameter, with the constraint that mbs MUST be lower or equal to maxbitrate. If the mbs parameter is omitted, it is set to the maxbitrate value. So if both mbs and maxbitrate are omitted, they are both set to 32000. The mbs parameter corresponds to a MBS value in the RTP packets as per table in Section 5.2 of RFC XXXX. Note that this parameter may be dynamically updated by the MBS field of the RTP packets sent, it is not an absolute value for the session. ptime: the recommended length of time in milliseconds represented by the media in a packet. See Section 6 of RFC YYYY [5]. maxptime: the maximum length of time in milliseconds which can be encapsulated in a packet. See Section 6 of RFC YYYY [5] Encoding considerations: This media type is framed and contains binary data, see section 4.8 of RFC 4288 [6]. Security considerations: See Section 8 of RFC XXXX Interoperability considerations: none Published specification: RFC XXXX Applications which use this media type: Audio and video conferencing tools. Additional information: none Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@francetelecom.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [3]. Author: Aurelien Sollaud Sollaud Expires October 26, 2006 [Page 9] Internet-Draft RTP payload format for G.729EV April 2006 Change controller: IETF Audio/Video Transport working group delegated from the IESG 6.2. Mapping to SDP parameters The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.729EV codec, the mapping is as follows: o The media type ("audio") goes in SDP "m=" as the media name. o The media subtype ("G729EV") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729EV. o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type string as a semicolon separated list of parameter=value pairs. Some example SDP session descriptions utilizing G.729EV encodings follow. Example 1: default parameters m=audio 53146 RTP/AVP 98 a=rtpmap:98 G729EV/16000 Example 2: recommended packet duration of 40 ms (=2 frames), maximum bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a loaded PSTN gateway which can operate at 12 kbps but asks to initially reduce the bit rate at 8 kbps. m=audio 51258 RTP/AVP 99 a=rtpmap:99 G729EV/16000 a=fmtp:99 maxbitrate=12000; mbs=8000 a=ptime:40 6.2.1. Offer-answer model considerations The following considerations apply when using SDP offer-answer procedures [8] to negotiate the use of G.729EV payload in RTP: Sollaud Expires October 26, 2006 [Page 10] Internet-Draft RTP payload format for G.729EV April 2006 o Since G.729EV is an extension of G.729, the offerer SHOULD announce G.729 support in its "m=audio" line, with G.729EV preferred. This will allow interoperability with both G.729EV and G.729-only capable parties. Below is an example of such an offer: m=audio 55954 RTP/AVP 98 18 a=rtpmap:98 G729EV/16000 a=rtpmap:18 G729/8000 If the answerer supports G.729EV, it will keep the payload type 98 in its answer and the conversation will be done using G.729EV. Else, if the answerer supports only G.729, it will leave only the payload type 18 in its answer and the conversation will be done using G.729 (the payload format for G.729 is defined in Section 4.5.6 of RFC 3551 [4]). Note that when used at 8 kbps in G.729-compatible mode, the G.729EV decoder supports G.729 Annex B. Therefore Annex B can be advertised (by default annexb=yes for G729 media type, see Section 4.1.9 of RFC 3555 [7]). o The "dtx" parameter concerns both sending and receiving, so both sides of a bi-directional session MUST use the same "dtx" value. If one party indicates it does not support DTX, DTX must be deactivated both ways. o The "maxbitrate" parameter is bi-directional. If the offerer sets a maxbitrate value, the answerer MUST reply with a smaller or equal value. The actual maximum bit rate for the session will be the minimum. o If the received value for "maxbitrate" is between 8000 and 32000 but not in the permissible values set, it SHOULD be read as the closest lower valid value. If the received value is lower than 8000 or greater than 32000, the session MUST be rejected. o The "mbs" parameter is not symmetric. Values in the offer and the answer are independent and take into account local constraints. Anyway, one party MUST NOT start sending frames at a bit rate higher than the "mbs" of the other party. The parameter allows to announce this value, prior to the sending of any packet, to avoid the remote sender to exceed the MBS at the beginning of the session. o If the received value for "mbs" is greater or equal to 8000 but not in the permissible values set, it SHOULD be read as the closest lower valid value. If the received value is lower than Sollaud Expires October 26, 2006 [Page 11] Internet-Draft RTP payload format for G.729EV April 2006 8000, the session MUST be rejected. o The parameters "ptime" and "maxptime" will in most cases not affect interoperability. The SDP offer-answer handling of the "ptime" parameter is described in RFC 3264 [8]. The "maxptime" parameter MUST be handled in the same way. Some special rules apply for mono-directional traffic: o For sendonly streams, the "mbs" parameter is useless and SHOULD NOT be used. o For recvonly streams, the "mbs" parameter is the only way to communicate the MBS to the sender, since there is no RTP stream towards it. So to request a bit rate change, the receiver will need to use an out-of-band mechanism, like a SIP RE-INIVTE. Some special rules apply for multicast: o The "mbs" parameter MUST NOT be used. o The "maxbitrate" and "dtx" parameter become declarative and MUST NOT be negotiated. These parameters are fixed, and a participant MUST use the configuration that is provided for the session. 6.2.2. Declarative SDP considerations For declarative use of SDP such as in SAP [10] and RTSP [11], the following considerations apply: o The "mbs" parameter MUST NOT be used. o The "maxbitrate" and "dtx" parameters are declarative and provide the parameters that SHALL be used when receiving and/or sending the configured stream. 7. Congestion control Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any appropriate profile (for example, RFC 3551 [4]). The embedded and variable bit rates capability of G.729EV provides a mechanism that may help to control congestion, see Section 3. The number of frames encapsulated in each RTP payload influences the overall bandwidth of the RTP stream, due to the header overhead. Sollaud Expires October 26, 2006 [Page 12] Internet-Draft RTP payload format for G.729EV April 2006 Packing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness. 8. Security considerations RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in the RTP specification [3] and any appropriate profile (for example, RFC 3551 [4]). As this format transports encoded speech/audio, the main security issues include confidentiality, integrity protection, and authentication of the speech/audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [12], MAY be used. This payload format and the G.729EV encoding do not exhibit any significant non-uniformity in the receiver-end computational load and thus in unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams. 9. IANA considerations It is requested that one new media subtype (audio/G729EV) is registered by IANA, see Section 6.1. 10. References 10.1. Normative references [1] International Telecommunications Union, "An 8-32 kbit/s scalable wideband speech and audio coder bitstream interoperable with G.729", ITU-T Draft Recommendation G.729EV, April 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Sollaud Expires October 26, 2006 [Page 13] Internet-Draft RTP payload format for G.729EV April 2006 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. [6] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 10.2. Informative references [9] International Telecommunications Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear- prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. [10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Sollaud Expires October 26, 2006 [Page 14] Internet-Draft RTP payload format for G.729EV April 2006 Author's Address Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France Phone: +33 2 96 05 15 06 Email: aurelien.sollaud@francetelecom.com Sollaud Expires October 26, 2006 [Page 15] Internet-Draft RTP payload format for G.729EV April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sollaud Expires October 26, 2006 [Page 16]