doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3952.txt b/doc/rfc/rfc3952.txt
new file mode 100644
index 0000000..eade7cd
--- /dev/null
+++ b/doc/rfc/rfc3952.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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:
+
+   ------------------------------------------------------------------+
+   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]
+