Network Working Group                                         A. Sollaud
Internet-Draft                                            France Telecom
Expires: September 2, 2006                                 March 1, 2006

             RTP payload format for the G.729EV audio codec

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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 September 2, 2006               [Page 1]

Internet-Draft       RTP payload format for G.729EV           March 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  . . . . . . . . . . . . . . . .  5
     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.3.  Offer-answer model considerations  . . . . . . . . . . . . 10
   7.  Congestion control . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative references . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative references . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Sollaud                 Expires September 2, 2006               [Page 2]

Internet-Draft       RTP payload format for G.729EV           March 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",
   document are to be interpreted as described in RFC 2119 [2].

2.  Background

   G.729EV is mainly designed to be used as a speech codec, but it can
   be used for music at the highest bit rates.  The sampling frequency
   is 16000 Hz and the frame size is 20 ms.

   This G.729-based codec produces an embedded bitstream providing an
   improved narrow band quality [300, 3400 Hz] at 12 kbps, and an
   enhanced and gracefully improving wideband quality [50, 7000 Hz] from
   14 kbps to 32 kbps, by steps of 2 kbps.  At 8 kbps it generates a
   G.729 bitstream.

   It has been mainly designed for packetized wideband voice
   applications (Voice over IP or ATM, Telephony over IP, private
   networks...) and particularly for those requiring scalable bandwidth,
   enhanced quality above G.729, and easy integration into existing

   G.729EV is also designed to cope with other services like high
   quality audio/video conferencing, archival, messaging, 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.

   G.729EV produces frames that are said embedded because they are
   composed of embedded layers.  The first layer is called the core
   layer and is bitstream compatible with the ITU-T G.729 with annex B
   coder.  Upper layers are added while bit rate increases, to improve
   quality and enlarge audio bandwidth from narrowband to wideband.  As

Sollaud                 Expires September 2, 2006               [Page 3]

Internet-Draft       RTP payload format for G.729EV           March 2006

   a result, a received frame can be decoded at its original bit rate or
   at any lower bit rate corresponding to lower layers which are
   embedded.  Only the core layer is mandatory to decode understandable
   speech, upper layers provide quality enhancement and wideband

   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, and is described in the following payload format (see
   Section 5.2).  Note that it is only useful for two-way G.729EV
   traffic, since the MBS request is piggy-backed over the speech frames
   in the reverse direction.

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 September 2, 2006               [Page 4]

Internet-Draft       RTP payload format for G.729EV           March 2006

   The RTP timestamp clock frequency is the same as the sampling
   frequency, that is 16 kHz.  So the timestamp unit is in samples.

   The duration of one frame is 20 ms, corresponding to 320 samples per
   frame.  Thus the timestamp is increased by 320 for each consecutive

   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,
   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  |                                               |
     +-+-+-+-+-+-+-+-+                                               +
     :                one ore more frames at the same bit rate       :
     :                                                               :

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:

Sollaud                 Expires September 2, 2006               [Page 5]

Internet-Draft       RTP payload format for G.729EV           March 2006

                         |  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.

   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

   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 field MUST be set to 15 for packets sent to a multicast
   group, and MUST be ignored on packets received from a multicast

   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.

   See Section 7 for more details on the use of MBS for congestion

Sollaud                 Expires September 2, 2006               [Page 6]

Internet-Draft       RTP payload format for G.729EV           March 2006

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 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
   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

Sollaud                 Expires September 2, 2006               [Page 7]

Internet-Draft       RTP payload format for G.729EV           March 2006

   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

   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

Sollaud                 Expires September 2, 2006               [Page 8]

Internet-Draft       RTP payload format for G.729EV           March 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

   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 will be
      dynamically updated by the MBS field of the RTP packets sent, it
      is not an absolute value for the session.  The goal is 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.

   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

   Additional information: none

   Person & email address to contact for further information: Aurelien

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [3].

Sollaud                 Expires September 2, 2006               [Page 9]

Internet-Draft       RTP payload format for G.729EV           March 2006

   Author: Aurelien Sollaud

   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

   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

   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), DTX off,
   and initial MBS set to 26 kbps

      m=audio 51258 RTP/AVP 99
      a=rtpmap:99 G729EV/16000
      a=fmtp:99 dtx=0; mbs=26000

6.3.  Offer-answer model considerations

   The following considerations apply when using SDP offer-answer
   procedures to negotiate the use of G.729EV payload in RTP:

Sollaud                 Expires September 2, 2006              [Page 10]

Internet-Draft       RTP payload format for G.729EV           March 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 RFC 3551

   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.

   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
      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.

Sollaud                 Expires September 2, 2006              [Page 11]

Internet-Draft       RTP payload format for G.729EV           March 2006

   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 is useless and SHOULD 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.

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.
   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 [10], MAY be used.

   This payload format and the G.729EV encoding do not exhibit any

Sollaud                 Expires September 2, 2006              [Page 12]

Internet-Draft       RTP payload format for G.729EV           March 2006

   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, "TBD", ITU-
        T Recommendation TBD, 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.

   [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]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.

Sollaud                 Expires September 2, 2006              [Page 13]

Internet-Draft       RTP payload format for G.729EV           March 2006

         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

Sollaud                 Expires September 2, 2006              [Page 14]

Internet-Draft       RTP payload format for G.729EV           March 2006

Author's Address

   Aurelien Sollaud
   France Telecom
   2 avenue Pierre Marzin
   Lannion Cedex  22307

   Phone: +33 2 96 05 15 06

Sollaud                 Expires September 2, 2006              [Page 15]

Internet-Draft       RTP payload format for G.729EV           March 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Sollaud                 Expires September 2, 2006              [Page 16]