doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2658.txt b/doc/rfc/rfc2658.txt
new file mode 100644
index 0000000..9298fb8
--- /dev/null
+++ b/doc/rfc/rfc2658.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                           K. McKay
+Request for Comments: 2658                         QUALCOMM Incorporated
+Category: Standards Track                                    August 1999
+
+
+               RTP Payload Format for PureVoice(tm) Audio
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+ABSTRACT
+
+   This document describes the RTP payload format for PureVoice(tm)
+   Audio.  The packet format supports variable interleaving to reduce
+   the effect of packet loss on audio quality.
+
+1 Introduction
+
+   This document describes how compressed PureVoice audio as produced by
+   the Qualcomm PureVoice CODEC [1] may be formatted for use as an RTP
+   payload type.  A method is provided to interleave the output of the
+   compressor to reduce quality degradation due to lost packets.
+   Furthermore, the sender may choose various interleave settings based
+   on the importance of low end-to-end delay versus greater tolerance
+   for lost packets.
+
+   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 [3].
+
+2 Background
+
+   The Electronic Industries Association (EIA) & Telecommunications
+   Industry Association (TIA) standard IS-733 [1] defines an audio
+   compression algorithm for use in CDMA applications.  In addition to
+   being the standard CODEC for all wireless CDMA terminals, the
+   Qualcomm PureVoice CODEC (a.k.a. Qcelp) is used in several Internet
+   applications most notably JFax(tm), Apple(r) QuickTime(tm), and
+   Eudora(r).
+
+
+
+K. McKay                    Standards Track                     [Page 1]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+   The Qcelp CODEC [1] compresses each 20 milliseconds of 8000 Hz, 16-
+   bit sampled input speech into one of four different size output
+   frames:  Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits)
+   or Rate 1/8 (20 bits).  The CODEC chooses the output frame rate based
+   on analysis of the input speech and the current operating mode
+   (either normal or reduced rate).  For typical speech patterns, this
+   results in an average output of 6.8 k bits/sec for normal mode and
+   4.7 k bits/sec for reduced rate mode.
+
+3 RTP/Qcelp Packet Format
+
+   The RTP timestamp is in 1/8000 of a second units.  The RTP payload
+   data for the Qcelp CODEC has the following format:
+
+    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 [2]                           |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |RR | LLL | NNN |                                               |
+   +-+-+-+-+-+-+-+-+       one or more codec data frames           |
+   |                             ....                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The RTP header has the expected values as described in [2].  The
+   extension bit is not set and this payload type never sets the marker
+   bit.  The codec data frames are aligned on octet boundaries.  When
+   interleaving is in use and/or multiple codec data frames are present
+   in a single RTP packet, the timestamp is, as always, that of the
+   oldest data represented in the RTP packet.  The other fields have the
+   following meaning:
+
+   Reserved (RR): 2 bits
+      MUST be set to zero by sender, SHOULD be ignored by receiver.
+
+   Interleave (LLL): 3 bits
+      MUST have a value between 0 and 5 inclusive.  The remaining two
+      values (6 and 7) MUST not be used by senders.  If this field is
+      non-zero, interleaving is enabled.  All receivers MUST support
+      interleaving.  Senders MAY support interleaving.  Senders that do
+      not support interleaving MUST set field LLL and NNN to zero.
+
+   Interleave Index (NNN): 3 bits
+      MUST have a value less than or equal to the value of LLL.  Values
+      of NNN greater than the value of LLL are invalid.
+
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 2]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+3.1 Receiving Invalid Values
+
+   On receipt of an RTP packet with an invalid value of the LLL or NNN
+   field, the RTP packet MUST be treated as lost by the receiver for the
+   purpose of generating erasure frames as described in section 4.
+
+3.2 CODEC data frame format
+
+   The output of the Qcelp CODEC must be converted into CODEC data
+   frames for inclusion in the RTP payload as follows:
+
+   a. Octet 0 of the CODEC data frame indicates the rate and total size
+      of the CODEC data frame as indicated in this table:
+
+      OCTET 0   RATE      TOTAL CODEC data frame size (in octets)
+      -----------------------------------------------------------
+        0       Blank     1
+        1       1/8       4
+        2       1/4       8
+        3       1/2       17
+        4       1         35
+        5       reserved  8 (SHOULD be treated as a reserved value)
+       14       Erasure   1 (SHOULD NOT be transmitted by sender)
+       other    n/a       reserved
+
+      Receipt of a CODEC data frame with a reserved value in octet 0
+      MUST be considered invalid data as described in 3.1.
+
+   b. The bits as numbered in the standard [1] from highest to lowest
+      are packed into octets.  The highest numbered bit (265 for Rate 1,
+      123 for Rate 1/2, 53 for Rate 1/4 and 19 for Rate 1/8) is placed
+      in the most significant bit (Internet bit 0) of octet 1 of the
+      CODEC data frame.  The second highest numbered bit (264 for Rate
+      1, etc.) is placed in the second most significant bit (Internet
+      bit 1) of octet 1 of the data frame.  This continues so that bit
+      258 from the standard Rate 1 frame is placed in the least
+      significant bit of octet 1.  Bit 257 from the standard is placed
+      in the most significant bit of octet 2 and so on until bit 0 from
+      the standard Rate 1 frame is placed in Internet bit 1 of octet 34
+      of the CODEC data frame.  The remaining unused bits of the last
+      octet of the CODEC data frame MUST be set to zero.
+
+
+
+
+
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 3]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+      Here is a detail of how a Rate 1/8 frame is converted into a CODEC
+      data frame:
+                              CODEC data frame
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               |1|1|1|1|1|1|1|1|1|1| | | | | | | | | | | | | | |
+      | 1 (Rate 1/8)  |9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|Z|Z|Z|Z|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Octet 0 of the data frame has value 1 (see table above) indicating
+      the total data frame length (including octet 0) is 4 octets.  Bits
+      19 through 0 from the standard Rate 1/8 frame are placed as
+      indicated with bits marked with "Z" being set to zero.  The Rate
+      1, 1/4 and 1/2 standard frames are converted similarly.
+
+3.3 Bundling CODEC data frames
+
+   As indicated in section 3, more than one CODEC data frame MAY be
+   included in a single RTP packet by a sender.  Receivers MUST handle
+   bundles of up to 10 CODEC data frames in a single RTP packet.
+
+   Furthermore, senders have the following additional restrictions:
+
+   o  MUST not bundle more CODEC data frames in a single RTP packet than
+      will fit in the MTU of the RTP transport protocol.  For the
+      purpose of computing the maximum bundling value, all CODEC data
+      frames should be assumed to have the Rate 1 size.
+
+   o  MUST never bundle more than 10 CODEC data frames in a single RTP
+      packet.
+
+   o  Once beginning transmission with a given SSRC and given bundling
+      value, MUST NOT increase the bundling value.  If the bundling
+      value needs to be increased, a new SSRC number MUST be used.
+
+   o  MAY decrease the bundling value only between interleave groups
+      (see section 3.4).  If the bundling value is decreased, it MUST
+      NOT be increased (even to the original value), although it may be
+      decreased again at a later time.
+
+
+
+
+
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 4]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+3.3.1 Determining the number of bundled CODEC data frames
+
+   Since no count is transmitted as part of the RTP payload and the
+   CODEC data frames have differing lengths, the only way to determine
+   how many CODEC data frames are present in the RTP packet is to
+   examine octet 0 of each CODEC data frame in sequence until the end of
+   the RTP packet is reached.
+
+3.4 Interleaving CODEC data frames
+
+   Interleaving is meaningful only when more than one CODEC data frame
+   is bundled into a single RTP packet.
+
+   All receivers MUST support interleaving.  Senders MAY support
+   interleaving.
+
+   Given a time-ordered sequence of output frames from the Qcelp CODEC
+   numbered 0..n, a bundling value B, and an interleave value L where n
+   = B * (L+1) - 1, the output frames are placed into RTP packets as
+   follows (the values of the fields LLL and NNN are indicated for each
+   RTP packet):
+
+   First RTP Packet in Interleave group:
+      LLL=L, NNN=0
+      Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of
+      B frames
+
+   Second RTP Packet in Interleave group:
+      LLL=L, NNN=1
+      Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a
+      total of B frames
+
+   This continues to the last RTP packet in the interleave group:
+
+   L+1 RTP Packet in Interleave group:
+      LLL=L, NNN=L
+      Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a
+      total of B frames
+
+   Senders MUST transmit in timestamp-increasing order.  Furthermore,
+   within each interleave group, the RTP packets making up the
+   interleave group MUST be transmitted in value-increasing order of the
+   NNN field.  While this does not guarantee reduced end-to-end delay on
+   the receiving end, when packets are delivered in order by the
+   underlying transport, delay will be reduced to the minimum possible.
+
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 5]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+   Additionally, senders have the following restrictions:
+
+   o  Once beginning transmission with a given SSRC and given interleave
+      value, MUST NOT increase the interleave value.  If the interleave
+      value needs to be increased, a new SSRC number MUST be used.
+
+   o  MAY decrease the interleave value only between interleave groups.
+      If the interleave value is decreased, it MUST NOT be increased
+      (even to the original value), although it may be decreased again
+      at a later time.
+
+3.5 Finding Interleave Group Boundaries
+
+   Given an RTP packet with sequence number S, interleave value (field
+   LLL) L, and interleave index value (field NNN) N, the interleave
+   group consists of RTP packets with sequence numbers from S-N to S-N+L
+   inclusive.  In other words, the Interleave group always consists of
+   L+1 RTP packets with sequential sequence numbers.  The bundling value
+   for all RTP packets in an interleave group MUST be the same.
+
+   The receiver determines the expected bundling value for all RTP
+   packets in an interleave group by the number of CODEC data frames
+   bundled in the first RTP packet of the interleave group received.
+   Note that this may not be the first RTP packet of the interleave
+   group sent if packets are delivered out of order by the underlying
+   transport.
+
+   On receipt of an RTP packet in an interleave group with other than
+   the expected bundling value, the receiver MAY discard CODEC data
+   frames off the end of the RTP packet or add erasure CODEC data frames
+   to the end of the packet in order to manufacture a substitute packet
+   with the expected bundling value.  The receiver MAY instead choose to
+   discard the whole interleave group and play silence.
+
+3.6 Reconstructing Interleaved Audio
+
+   Given an RTP sequence number ordered set of RTP packets in an
+   interleave group numbered 0..L, where L is the interleave value and B
+   is the bundling value, and CODEC data frames within each RTP packet
+   that are numbered in order from first to last with the numbers 1..B,
+   the original, time-ordered sequence of output frames from the CODEC
+   may be reconstructed as follows:
+
+   First L+1 frames:
+      Frame 0 from packet 0 of interleave group
+      Frame 0 from packet 1 of interleave group
+      And so on up to...
+      Frame 0 from packet L of interleave group
+
+
+
+K. McKay                    Standards Track                     [Page 6]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+   Second L+1 frames:
+      Frame 1 from packet 0 of interleave group
+      Frame 1 from packet 1 of interleave group
+      And so on up to...
+      Frame 1 from packet L of interleave group
+
+   And so on up to...
+
+   Bth L+1 frames:
+      Frame B from packet 0 of interleave group
+      Frame B from packet 1 of interleave group
+      And so on up to...
+      Frame B from packet L of interleave group
+
+3.6.1 Additional Receiver Responsibility
+
+   Assume that the receiver has begun playing frames from an interleave
+   group.  The time has come to play frame x from packet n of the
+   interleave group.  Further assume that packet n of the interleave
+   group has not been received.  As described in section 4, an erasure
+   frame will be sent to the Qcelp CODEC.
+
+   Now, assume that packet n of the interleave group arrives before
+   frame x+1 of that packet is needed.  Receivers SHOULD use frame x+1
+   of the newly received packet n rather than substituting an erasure
+   frame.  In other words, just because packet n wasn't available the
+   first time it was needed to reconstruct the interleaved audio, the
+   receiver SHOULD NOT assume it's not available when it's subsequently
+   needed for interleaved audio reconstruction.
+
+4 Handling lost RTP packets
+
+   The Qcelp CODEC supports the notion of erasure frames.  These are
+   frames that for whatever reason are not available.  When
+   reconstructing interleaved audio or playing back non-interleaved
+   audio, erasure frames MUST be fed to the Qcelp CODEC for all of the
+   missing packets.
+
+   Receivers MUST use the timestamp clock to determine how many CODEC
+   data frames are missing.  Each CODEC data frame advances the
+   timestamp clock EXACTLY 160 counts.
+
+   Since the bundling value may vary (it can only decrease), the
+   timestamp clock is the only reliable way to calculate exactly how
+   many CODEC data frames are missing when a packet is dropped.
+
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 7]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+   Specifically when reconstructing interleaved audio, a missing RTP
+   packet in the interleave group should be treated as containing B
+   erasure CODEC data frames where B is the bundling value for that
+   interleave group.
+
+5 Discussion
+
+   The Qcelp CODEC interpolates the missing audio content when given an
+   erasure frame.  However, the best quality is perceived by the
+   listener when erasure frames are not consecutive.  This makes
+   interleaving desirable as it increases audio quality when dropped
+   packets are more likely.
+
+   On the other hand, interleaving can greatly increase the end-to-end
+   delay.  Where an interactive session is desired, an interleave (field
+   LLL) value of 0 or 1 and a bundling factor of 4 or less is
+   recommended.
+
+   When end-to-end delay is not a concern, a bundling value of at least
+   4 and an interleave (field LLL) value of 4 or 5 is recommended
+   subject to MTU limitations.
+
+   The restrictions on senders set forth in sections 3.3 and 3.4
+   guarantee that after receipt of the first payload packet from the
+   sender, the receiver can allocate a well-known amount of buffer space
+   that will be sufficient for all future reception from the same SSRC
+   value.  Less buffer space may be required at some point in the future
+   if the sender decreases the bundling value or interleave, but never
+   more buffer space.  This prevents the possibility of the receiver
+   needing to allocate more buffer space (with the possible result that
+   none is available) should the bundling value or interleave value be
+   increased by the sender.  Also, were the interleave or bundling value
+   to increase, the receiver could be forced to pause playback while it
+   receives the additional packets necessary for playback at an
+   increased bundling value or increased interleave.
+
+6 Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [2], and any appropriate profile (for example [4]).
+   This implies that confidentiality of the media streams is achieved by
+   encryption.  Because the data compression used with this payload
+   format is applied end-to-end, encryption may be performed after
+   compression so there is no conflict between the two operations.
+
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 8]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+   A potential denial-of-service threat exists for data encodings 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
+   be overloaded.  However, this encoding does not exhibit any
+   significant non-uniformity.
+
+   As with any IP-based protocol, in some circumstances, a receiver may
+   be overloaded simply by the receipt of too many packets, either
+   desired or undesired.  Network-layer authentication may be used to
+   discard packets from undesired sources, but the processing cost of
+   the authentication itself may be too high.  In a multicast
+   environment, pruning of specific sources may be implemented in future
+   versions of IGMP [5] and in multicast routing protocols to allow a
+   receiver to select which sources are allowed to reach it.
+
+7 References
+
+   [1]  TIA/EIA/IS-733.  TR45: High Rate Speech Service Option for
+        Wideband Spread Spectrum Communications Systems.  Available from
+        Global Engineering +1 800 854 7179 or +1 303 792 2181.  May also
+        be ordered online at http://www.eia.org/eng/.
+
+   [2]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP:  A Transport Protocol for Real-Time Applications", RFC
+        1889, January 1996.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Schulzrinne, H., "RTP Profile for Audio and Video Conferences
+        with Minimal Control", RFC 1890, January 1996.
+
+   [5]  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
+        1112, August 1989.
+
+8 Author's Address
+
+   Kyle J. McKay
+   QUALCOMM Incorporated
+   5775 Morehouse Drive
+   San Diego, CA 92121-1714
+   USA
+
+   Phone: +1 858 587 1121
+   EMail: kylem@qualcomm.com
+
+
+
+
+
+K. McKay                    Standards Track                     [Page 9]
+
+RFC 2658       RTP Payload Format for PureVoice(tm) Audio    August 1999
+
+
+9 Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+K. McKay                    Standards Track                    [Page 10]
+