GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3952

Network Working Group A. Duric Request for Comments: 3952 Telio Category: Experimental S. Andersen

                                                    Aalborg University
                                                         December 2004
         Real-time Transport Protocol (RTP) Payload Format
           for internet Low Bit Rate Codec (iLBC) Speech

Status of this Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This document describes the Real-time Transport Protocol (RTP)
 payload format for the internet Low Bit Rate Codec (iLBC) Speech
 developed by Global IP Sound (GIPS).  Also, within the document there
 are included necessary details for the use of iLBC with MIME and
 Session Description Protocol (SDP).

Table of Contents

 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2. Background. . . . . . . . . . . . . . . . . . . . . . . . . . .  2
 3. RTP Payload Format. . . . . . . . . . . . . . . . . . . . . . .  3
    3.1. Bitstream definition . . . . . . . . . . . . . . . . . . .  3
    3.2. Multiple iLBC frames in a RTP packet . . . . . . . . . . .  6
 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
    4.1. Storage Mode . . . . . . . . . . . . . . . . . . . . . . .  7
    4.2. MIME registration of iLBC. . . . . . . . . . . . . . . . .  8
 5. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . .  9
 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
    7.2. Informative References . . . . . . . . . . . . . . . . . . 12
 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 12
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13

Duric & Andersen Experimental [Page 1] RFC 3952 RTP Payload Format for iLBC Speech December 2004

1. Introduction

 This document describes how compressed iLBC speech, as produced by
 the iLBC codec [1], may be formatted for use as an RTP payload type.
 Methods are provided to packetize the codec data frames into RTP
 packets.  The sender may send one or more codec data frames per
 packet depending on the application scenario or based on the
 transport network condition, bandwidth restriction, delay
 requirements and packet-loss tolerance.
 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 BCP 14, RFC 2119 [2].

2. Background

 Global IP Sound (GIPS) has developed a speech compression algorithm
 for use in IP based communications [1].  The iLBC codec enables
 graceful speech quality degradation in the case of lost frames, which
 occurs in connection with lost or delayed IP packets.
 This codec is suitable for real time communications such as,
 telephony and videoconferencing, streaming audio, archival and
 messaging.
 The iLBC codec [1] is an algorithm that compresses each basic frame
 (20 ms or 30 ms) of 8000 Hz, 16-bit sampled input speech, into output
 frames with rate of 400 bits for 30 ms basic frame size and 304 bits
 for 20 ms basic frame size.
 The codec supports two basic frame lengths: 30 ms at 13.33 kbit/s and
 20 ms at 15.2 kbit/s, using a block independent linear-predictive
 coding (LPC) algorithm.  When the codec operates at block lengths of
 20 ms, it produces 304 bits per block which MUST be packetized in 38
 bytes.  Similarly, for block lengths of 30 ms it produces 400 bits
 per block which MUST be packetized in 50 bytes.  This algorithm
 results in a speech coding system with a controlled response to
 packet losses similar to what is known from pulse code modulation
 (PCM) with a packet loss concealment (PLC), such as ITU-T G711
 standard [7], which operates at a fixed bit rate of 64 kbit/s.  At
 the same time, this algorithm enables fixed bit rate coding with a
 quality-versus-bit rate tradeoff close to what is known from code-
 excited linear prediction (CELP).

Duric & Andersen Experimental [Page 2] RFC 3952 RTP Payload Format for iLBC Speech December 2004

3. RTP Payload Format

 The iLBC codec uses 20 or 30 ms frames and a sampling rate clock of 8
 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. The
 RTP payload for iLBC has the format shown in the figure bellow. No
 addition header specific to this payload format is required.
 This format is intended for the situations where the sender and the
 receiver send one or more codec data frames per packet.  The RTP
 packet looks as follows:
 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      RTP Header [3]                           |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                                                               |
 +                 one or more frames of iLBC [1]                |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 1, Packet format diagram
 The RTP header of the packetized encoded iLBC speech has the expected
 values as described in [3].  The usage of M bit SHOULD be as
 specified in the applicable RTP profile, for example, RFC 3551 [4]
 specifies that if the sender does not suppress silence (i.e., sends a
 frame on every frame interval), the M bit will always be zero.  When
 more then one codec data frame is present in a single RTP packet, the
 timestamp is, as always, the oldest data frame represented in the RTP
 packet.
 The assignment of an RTP payload type for this new packet format is
 outside the scope of this document, and will not be specified here.
 It is expected that the RTP profile for a particular class of
 applications will assign a payload type for this encoding, or if that
 is not done, then a payload type in the dynamic range shall be chosen
 by the sender.

3.1. Bitstream definition

 The total number of bits used to describe one frame of 20 ms speech
 is 304, which fits in 38 bytes and results in a bit rate of 15.20
 kbit/s.  For the case with a frame length of 30 ms speech the total
 number of bits used is 400, which fits in 50 bytes and results in a
 bit rate of 13.33 kbit/s.  In the bitstream definition, the bits are
 distributed into three classes according to their bit error or loss
 sensitivity.  The most sensitive bits (class 1) are placed first in

Duric & Andersen Experimental [Page 3] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 the bitstream for each frame.  The less sensitive bits (class 2) are
 placed after the class 1 bits.  The least sensitive bits (class 3)
 are placed at the end of the bitstream for each frame.
 Looking at the 20/30 ms frame length cases for each class: The class
 1 bits occupy a total of 6/8 bytes (48/64 bits), the class 2 bits
 occupy 8/12 bytes (64/96 bits), and the class 3 bits occupy 24/30
 bytes (191/239 bits).  This distribution of the bits enables the use
 of uneven level protection (ULP).  The detailed bit allocation is
 shown in the table below.  When a quantization index is distributed
 between more classes the more significant bits belong to the lowest
 class.

Duric & Andersen Experimental [Page 4] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 Bitstream structure:
  1. —————————————————————–+

Parameter | Bits Class <1,2,3> |

                                   |  20 ms frame  |  30 ms frame  |
 ----------------------------------+---------------+---------------+
                          Split 1  |   6 <6,0,0>   |   6 <6,0,0>   |
                 LSF 1    Split 2  |   7 <7,0,0>   |   7 <7,0,0>   |
 LSF                      Split 3  |   7 <7,0,0>   |   7 <7,0,0>   |
                 ------------------+---------------+---------------+
                          Split 1  | NA (Not Appl.)|   6 <6,0,0>   |
                 LSF 2    Split 2  |      NA       |   7 <7,0,0>   |
                          Split 3  |      NA       |   7 <7,0,0>   |
                 ------------------+---------------+---------------+
                 Sum               |  20 <20,0,0>  |  40 <40,0,0>  |
 ----------------------------------+---------------+---------------+
 Block Class.                      |   2 <2,0,0>   |   3 <3,0,0>   |
 ----------------------------------+---------------+---------------+
 Position 22 sample segment        |   1 <1,0,0>   |   1 <1,0,0>   |
 ----------------------------------+---------------+---------------+
 Scale Factor State Coder          |   6 <6,0,0>   |   6 <6,0,0>   |
 ----------------------------------+---------------+---------------+
                 Sample 0          |   3 <0,1,2>   |   3 <0,1,2>   |
 Quantized       Sample 1          |   3 <0,1,2>   |   3 <0,1,2>   |
 Residual           :              |   :    :      |   :    :      |
 State              :              |   :    :      |   :    :      |
 Samples            :              |   :    :      |   :    :      |
                 Sample 56         |   3 <0,1,2>   |   3 <0,1,2>   |
                 Sample 57         |      NA       |   3 <0,1,2>   |
                 ------------------+---------------+---------------+
                 Sum               | 171 <0,57,114>| 174 <0,58,116>|
 ----------------------------------+---------------+---------------+
                          Stage 1  |   7 <6,0,1>   |   7 <4,2,1>   |
 CB for 22/23             Stage 2  |   7 <0,0,7>   |   7 <0,0,7>   |
 sample block             Stage 3  |   7 <0,0,7>   |   7 <0,0,7>   |
                 ------------------+---------------+---------------+
                 Sum               |  21 <6,0,15>  |  21 <4,2,15>  |
 ----------------------------------+---------------+---------------+
                          Stage 1  |   5 <2,0,3>   |   5 <1,1,3>   |
 Gain for 22/23           Stage 2  |   4 <1,1,2>   |   4 <1,1,2>   |
 sample block             Stage 3  |   3 <0,0,3>   |   3 <0,0,3>   |
                 ------------------+---------------+---------------+
                 Sum               |  12 <3,1,8>   |  12 <2,2,8>   |
 ----------------------------------+---------------+---------------+
                          Stage 1  |   8 <7,0,1>   |   8 <6,1,1>   |
             sub-block 1  Stage 2  |   7 <0,0,7>   |   7 <0,0,7>   |
                          Stage 3  |   7 <0,0,7>   |   7 <0,0,7>   |
                 ------------------+---------------+---------------+

Duric & Andersen Experimental [Page 5] RFC 3952 RTP Payload Format for iLBC Speech December 2004

                          Stage 1  |   8 <0,0,8>   |   8 <0,7,1>   |
             sub-block 2  Stage 2  |   8 <0,0,8>   |   8 <0,0,8>   |
 Indices                  Stage 3  |   8 <0,0,8>   |   8 <0,0,8>   |
 for CB          ------------------+---------------+---------------+
 sub-blocks               Stage 1  |      NA       |   8 <0,7,1>   |
             sub-block 3  Stage 2  |      NA       |   8 <0,0,8>   |
                          Stage 3  |      NA       |   8 <0,0,8>   |
                 ------------------+---------------+---------------+
                          Stage 1  |      NA       |   8 <0,7,1>   |
             sub-block 4  Stage 2  |      NA       |   8 <0,0,8>   |
                          Stage 3  |      NA       |   8 <0,0,8>   |
                 ------------------+---------------+---------------+
                 Sum               |  46 <7,0,39>  |  94 <6,22,66> |
 ----------------------------------+---------------+---------------+
                          Stage 1  |   5 <1,2,2>   |   5 <1,2,2>   |
             sub-block 1  Stage 2  |   4 <1,1,2>   |   4 <1,2,1>   |
                          Stage 3  |   3 <0,0,3>   |   3 <0,0,3>   |
                 ------------------+---------------+---------------+
                          Stage 1  |   5 <1,1,3>   |   5 <0,2,3>   |
             sub-block 2  Stage 2  |   4 <0,2,2>   |   4 <0,2,2>   |
                          Stage 3  |   3 <0,0,3>   |   3 <0,0,3>   |
 Gains for       ------------------+---------------+---------------+
 sub-blocks               Stage 1  |      NA       |   5 <0,1,4>   |
             sub-block 3  Stage 2  |      NA       |   4 <0,1,3>   |
                          Stage 3  |      NA       |   3 <0,0,3>   |
                 ------------------+---------------+---------------+
                          Stage 1  |      NA       |   5 <0,1,4>   |
             sub-block 4  Stage 2  |      NA       |   4 <0,1,3>   |
                          Stage 3  |      NA       |   3 <0,0,3>   |
                 ------------------+---------------+---------------+
                 Sum               |  24 <3,6,15>  |  48 <2,12,34> |
 -------------------------------------------------------------------
 Empty frame indicator             |   1 <0,0,1>   |   1 <0,0,1>   |
 -------------------------------------------------------------------
 SUM                                 304 <48,64,192> 400 <64,96,240>
 Table 3.1 The bitstream definition for iLBC.
 When packetized into the payload, all the class 1 bits MUST be sorted
 in order (from top and down) as they were specified in the table.
 Additionally, all the class 2 bits MUST be sorted (from top and down)
 and all the class 3 bits MUST be sorted in the same sequential order.

3.2. Multiple iLBC frames in a RTP packet

 More than one iLBC frame may be included in a single RTP packet by a
 sender.

Duric & Andersen Experimental [Page 6] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 It is important to observe that senders have the following additional
 restrictions:
 o  SHOULD NOT include more iLBC frames in a single RTP packet than
    will fit in the MTU of the RTP transport protocol.
 o  Frames MUST NOT be split between RTP packets.
 o  Frames of the different modes (20 ms and 30 ms) MUST NOT be
    included within the same packet.
 It is RECOMMENDED that the number of frames contained within an RTP
 packet are consistent with the application.  For example, in
 telephony and other real time applications where delay is important,
 the delay is lower depending on the amount of frames per packet
 (i.e., fewer frames per packet, the lower the delay).  Whereas for
 bandwidth constrained links or delay insensitive streaming messaging
 application, one or more frames per packet would be acceptable.
 Information describing the number of frames contained in an RTP
 packet is not transmitted as part of the RTP payload.  The way to
 determine the number of iLBC frames is to count the total number of
 octets within the RTP packet, and divide the octet count by the
 number of expected octets per frame (32/50 per frame).

4. IANA Considerations

 One new MIME sub-type as described in this section has been
 registered.

4.1. Storage Mode

 The storage mode is used for storing speech frames (e.g., as a file
 or email attachment).
 +------------------+
 | Header           |
 +------------------+
 | Speech frame 1   |
 +------------------+
 :                  :
 +------------------+
 | Speech frame n   |
 +------------------+
 Figure 2, Storage format diagram

Duric & Andersen Experimental [Page 7] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 The file begins with a header that includes only a magic number to
 identify that it is an iLBC file.
 The magic number for iLBC file MUST correspond to the ASCII character
 string:
    o for 30 ms frame size mode:"#!iLBC30\n", or "0x23 0x21 0x69
    0x4C 0x42 0x43 0x33 0x30 0x0A" in hexadecimal form,
    o for 20 ms frame size mode:"#!iLBC20\n", or "0x23 0x21 0x69
    0x4C 0x42 0x43 0x32 0x30 0x0A" in hexadecimal form.
 After the header, follow the speech frames in consecutive order.
 Speech frames lost in transmission MUST be stored as "empty frames",
 as defined in [1].

4.2. MIME Registration of iLBC

 MIME media type name: audio
 MIME subtype: iLBC
 Optional parameters:
 All of the parameters does apply for RTP transfer only.
 maxptime:The maximum amount of media which can be encapsulated in
          each packet, expressed as time in milliseconds.  The time
          SHALL be calculated as the sum of the time the media present
          in the packet represents.  The time SHOULD be a multiple of
          the frame size.  This attribute is probably only meaningful
          for audio data, but may be used with other media types if it
          makes sense.  It is a media attribute, and is not dependent
          on charset.  Note that this attribute was introduced after
          RFC 2327, and non updated implementations will ignore this
          attribute.
 mode:    The iLBC operating frame mode (20 or 30 ms) that will be
          encapsulated in each packet.  Values can be 0, 20 and 30
          (where 0 is reserved, 20 stands for preferred 20 ms frame
          size and 30 stands for preferred 30 ms frame size).
 ptime:   Defined as usual for RTP audio (see [5]).
 Encoding considerations:
          This type is defined for transfer via both RTP (RFC 3550)
          and stored-file methods as described in Section 4.1, of RFC

Duric & Andersen Experimental [Page 8] RFC 3952 RTP Payload Format for iLBC Speech December 2004

          3952.  Audio data is binary data, and must be encoded for
          non-binary transport; the Base64 encoding is suitable for
          email.
 Security considerations:
          See Section 6 of RFC 3952.
 Public specification:
          Please refer to RFC 3951 [1].
 Additional information:
          The following applies to stored-file transfer methods:
          Magic number:
          ASCII character string for:
          o 30 ms frame size mode "#!iLBC30\n" (or 0x23 0x21
          0x69 0x4C 0x42 0x43 0x33 0x30 0x0A in hexadecimal)
          o 20 ms frame size mode "#!iLBC20\n" (or 0x23 0x21
          0x69 0x4C 0x42 0x43 0x32 0x30 0x0A in hexadecimal)
          File extensions: lbc, LBC
          Macintosh file type code: none
          Object identifier or OID: none
 Person & email address to contact for further information:
          alan.duric@telio.no
 Intended usage: COMMON.
          It is expected that many VoIP applications will use this
          type.
 Author/Change controller:
          alan.duric@telio.no
          IETF Audio/Video transport working group

5. Mapping To SDP Parameters

 The information carried in the MIME 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 iLBC codec, the mapping is as
 follows:
 o  The MIME type ("audio") goes in SDP "m=" as the media name.
 o  The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
    the encoding name.

Duric & Andersen Experimental [Page 9] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
    "a=maxptime" attributes, respectively.
 o  The parameter "mode" goes in the SDP "a=fmtp" attribute by copying
    it directly from the MIME media type string as "mode=value".
 When conveying information by SDP, the encoding name SHALL be "iLBC"
 (the same as the MIME subtype).
 An example of the media representation in SDP for describing iLBC
 might be:
    m=audio 49120 RTP/AVP 97
    a=rtpmap:97 iLBC/8000
 If 20 ms frame size mode is used, remote iLBC encoder SHALL receive
 "mode" parameter in the SDP "a=fmtp" attribute by copying them
 directly from the MIME media type string as a semicolon separated
 with parameter=value, where parameter is "mode", and values can be 0
 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame
 size).  An example of the media representation in SDP for describing
 iLBC when 20 ms frame size mode is used might be:
    m=audio 49120 RTP/AVP 97
    a=rtpmap:97 iLBC/8000
    a=fmtp:97 mode=20
 It is important to emphasize the bi-directional character of the
 "mode" parameter - both sides of a bi-directional session MUST use
 the same "mode" value.
 The offer contains the preferred mode of the offerer.  The answerer
 may agree to that mode by including the same mode in the answer, or
 may include a different mode.  The resulting mode used by both
 parties SHALL be the lower of the bandwidth modes in the offer and
 answer.
 That is, an offer of "mode=20" receiving an answer of "mode=30" will
 result in "mode=30" being used by both participants.  Similarly, an
 offer of "mode=30" and an answer of "mode=20" will result in
 "mode=30" being used by both participants.
 This is important when one end point utilizes a bandwidth constrained
 link (e.g., 28.8k modem link or slower), where only the lower frame
 size will work.

Duric & Andersen Experimental [Page 10] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 Parameter ptime can not be used for the purpose of specifying iLBC
 operating mode, due to fact that for the certain values it will be
 impossible to distinguish which mode is about to be used (e.g., when
 ptime=60, it would be impossible to distinguish if packet is carrying
 2 frames of 30 ms or 3 frames of 20 ms, etc.).
 Note that the payload format (encoding) names are commonly shown in
 upper case.  MIME subtypes are commonly shown in lower case.  These
 names are case-insensitive in both places.  Similarly, parameter
 names are case-insensitive both in MIME types and in the default
 mapping to the SDP a=fmtp attribute

6. Security Considerations

 RTP packets using the payload format defined in this specification
 are subject to the general security considerations discussed in [3]
 and any appropriate profile (e.g., [4]).
 As this format transports encoded speech, the main security issues
 include confidentiality and authentication of the speech itself.  The
 payload format itself does not have any built-in security mechanisms.
 Confidentiality of the media streams is achieved by encryption,
 therefore external mechanisms, such as SRTP [6], MAY be used for that
 purpose.  The data compression used with this payload format is
 applied end-to-end; hence encryption may be performed after
 compression with no conflict between the two operations.
 A potential denial-of-service threat exists for data encoding using
 compression techniques that have non-uniform receiver-end
 computational load.  The attacker can inject pathological datagrams
 into the stream which are complex to decode and cause the receiver to
 become overloaded.  However, the encodings covered in this document
 do not exhibit any significant non-uniformity.

7. References

7.1. Normative References

 [1]  Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and
      J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951,
      December 2004.
 [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.

Duric & Andersen Experimental [Page 11] RFC 3952 RTP Payload Format for iLBC Speech December 2004

 [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. and V. Jacobson, "SDP: Session Description
      Protocol", RFC 2327, April 1998.
 [6]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
      Norrman, "The Secure Real-time Transport Protocol", RFC 3711,
      March 2004.

7.2. Informative References

 [7]  ITU-T Recommendation G.711, available online from the ITU
      bookstore at http://www.itu.int.

8. Acknowledgements

 Henry Sinnreich, Patrik Faltstrom, Alan Johnston and Jean-Francois
 Mule for great support of the iLBC initiative and for valuable
 feedback and comments.

Authors' Addresses

 Alan Duric
 Telio AS
 Stoperigt. 2
 Oslo, N-0250
 Norway
 Phone:  +47 21673505
 EMail:  alan.duric@telio.no
 Soren Vang Andersen
 Department of Communication Technology
 Aalborg University
 Fredrik Bajers Vej 7A
 9200 Aalborg
 Denmark
 Phone:  ++45 9 6358627
 EMail:  sva@kom.auc.dk

Duric & Andersen Experimental [Page 12] RFC 3952 RTP Payload Format for iLBC Speech December 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 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.
 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.

Intellectual Property

 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 IETF's procedures with respect to rights in IETF 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.

Acknowledgement

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

Duric & Andersen Experimental [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3952.txt · Last modified: 2004/12/01 23:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki