doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc2198.txt b/doc/rfc/rfc2198.txt
new file mode 100644
index 0000000..5745258
--- /dev/null
+++ b/doc/rfc/rfc2198.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                        C. Perkins
+Request for Comments: 2198                                  I. Kouvelas
+Category: Standards Track                                     O. Hodson
+                                                             V. Hardman
+                                              University College London
+                                                             M. Handley
+                                                                    ISI
+                                                             J.C. Bolot
+                                                         A. Vega-Garcia
+                                                       S. Fosse-Parisis
+                                                 INRIA Sophia Antipolis
+                                                         September 1997
+
+
+                  RTP Payload for Redundant Audio Data
+
+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.
+
+Abstract
+
+   This document describes a payload format for use with the real-time
+   transport protocol (RTP), version 2, for encoding redundant audio
+   data.  The primary motivation for the scheme described herein is the
+   development of audio conferencing tools for use with lossy packet
+   networks such as the Internet Mbone, although this scheme is not
+   limited to such applications.
+
+1  Introduction
+
+   If multimedia conferencing is to become widely used by the Internet
+   Mbone community, users must perceive the quality to be sufficiently
+   good for most applications.  We have identified a number of problems
+   which impair the quality of conferences, the most significant of
+   which is packet loss.  This is a persistent problem, particularly
+   given the increasing popularity, and therefore increasing load, of
+   the Internet.  The disruption of speech intelligibility even at low
+   loss rates which is currently experienced may convince a whole
+   generation of users that multimedia conferencing over the Internet is
+   not viable.  The addition of redundancy to the data stream is offered
+   as a solution [1].  If a packet is lost then the missing information
+   may be reconstructed at the receiver from the redundant data that
+   arrives in the following packet(s), provided that the average number
+
+
+
+Perkins, et. al.            Standards Track                     [Page 1]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+   of consecutively lost packets is small.  Recent work [4,5] shows that
+   packet loss patterns in the Internet are such that this scheme
+   typically functions well.
+
+   This document describes an RTP payload format for the transmission of
+   audio data encoded in such a redundant fashion.  Section 2 presents
+   the requirements and motivation leading to the definition of this
+   payload format, and does not form part of the payload format
+   definition.  Sections 3 onwards define the RTP payload format for
+   redundant audio data.
+
+2  Requirements/Motivation
+
+   The requirements for a redundant encoding scheme under RTP are as
+   follows:
+
+     o Packets have to carry a primary encoding and one or more
+       redundant encodings.
+
+     o As a multitude of encodings may be used for redundant
+       information, each block of redundant encoding has to have an
+       encoding type identifier.
+
+     o As the use of variable size encodings is desirable, each encoded
+       block in the packet has to have a length indicator.
+
+     o The RTP header provides a timestamp field that corresponds to
+       the time of creation of the encoded data.  When redundant
+       encodings are used this timestamp field can refer to the time of
+       creation of the primary encoding data.  Redundant blocks of data
+       will correspond to different time intervals than the primary
+       data, and hence each block of redundant encoding will require its
+       own timestamp.  To reduce the number of bytes needed to carry the
+       timestamp, it can be encoded as the difference of the timestamp
+       for the redundant encoding and the timestamp of the primary.
+
+   There are two essential means by which redundant audio may be added
+   to the standard RTP specification:  a header extension may hold the
+   redundancy, or one, or more, additional payload types may be defined.
+
+   Including all the redundancy information for a packet in a header
+   extension would make it easy for applications that do not implement
+   redundancy to discard it and just process the primary encoding data.
+   There are, however, a number of disadvantages with this scheme:
+
+
+
+
+
+
+
+Perkins, et. al.            Standards Track                     [Page 2]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+     o There is a large overhead from the number of bytes needed for
+       the extension header (4) and the possible padding that is needed
+       at the end of the extension to round up to a four byte  boundary
+       (up to 3 bytes).  For many applications this overhead is
+       unacceptable.
+
+     o Use of the header extension limits applications to a single
+       redundant encoding, unless further structure is introduced into
+       the extension.  This would result in further overhead.
+
+   For these reasons, the use of RTP header extension to hold redundant
+   audio encodings is disregarded.
+
+   The RTP profile for audio and video conferences [3] lists a set of
+   payload types and provides for a dynamic range of 32 encodings that
+   may be defined through a conference control protocol.  This leads to
+   two possible schemes for assigning additional RTP payload types for
+   redundant audio applications:
+
+     1.A dynamic encoding scheme may be defined, for each combination
+       of primary/redundant payload types, using the RTP dynamic payload
+       type range.
+
+     2.A single fixed payload type may be defined to represent a packet
+       with redundancy.  This may then be assigned to either a static
+       RTP payload type, or the payload type for this may be assigned
+       dynamically.
+
+   It is possible to define a set of payload types that signify a
+   particular combination of primary and secondary encodings for each of
+   the 32 dynamic payload types provided.  This would be a slightly
+   restrictive yet feasible solution for packets with a single block of
+   redundancy as the number of possible combinations is not too large.
+   However the need for multiple blocks of redundancy greatly increases
+   the number of encoding combinations and makes this solution not
+   viable.
+
+   A modified version of the above solution could be to decide prior to
+   the beginning of a conference on a set a 32 encoding combinations
+   that will be used for the duration of the conference.  All tools in
+   the conference can be initialized with this working set of encoding
+   combinations.  Communication of the working set could be made through
+   the use of an external, out of band, mechanism.  Setup is complicated
+   as great care needs to be taken in starting tools with identical
+   parameters.  This scheme is more efficient as only one byte is used
+   to identify combinations of encodings.
+
+
+
+
+
+Perkins, et. al.            Standards Track                     [Page 3]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+   It is felt that the complication inherent in distributing the mapping
+   of payload types onto combinations of redundant data preclude the use
+   of this mechanism.
+
+   A more flexible solution is to have a single payload type which
+   signifies a packet with redundancy. That packet then becomes a
+   container, encapsulating multiple payloads into a single RTP packet.
+   Such a scheme is flexible, since any amount of redundancy may be
+   encapsulated within a single packet.  There is, however, a small
+   overhead since each encapsulated payload must be preceded by a header
+   indicating the type of data enclosed.  This is the preferred
+   solution, since it is both flexible, extensible, and has a relatively
+   low overhead.  The remainder of this document describes this
+   solution.
+
+3  Payload Format Specification
+
+   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 RFC2119 [7].
+
+   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.
+
+   An RTP packet containing redundant data shall have a standard RTP
+   header, with payload type indicating redundancy.  The other fields of
+   the RTP header relate to the primary data block of the redundant
+   data.
+
+   Following the RTP header are a number of additional headers, defined
+   in the figure below, which specify the contents of each of the
+   encodings carried by the packet.  Following these additional headers
+   are a number of data blocks, which contain the standard RTP payload
+   data for these encodings.  It is noted that all the headers are
+   aligned to a 32 bit boundary, but that the payload data will
+   typically not be aligned.  If multiple redundant encodings are
+   carried in a packet, they should correspond to different time
+   intervals:  there is no reason to include multiple copies of data for
+   a single time interval within a packet.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |F|   block PT  |  timestamp offset         |   block length    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Perkins, et. al.            Standards Track                     [Page 4]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+   The bits in the header are specified as follows:
+
+
+   F: 1 bit First bit in header indicates whether another header block
+       follows.  If 1 further header blocks follow, if 0 this is the
+       last header block.
+
+   block PT: 7 bits RTP payload type for this block.
+
+   timestamp offset:  14 bits Unsigned offset of timestamp of this block
+       relative to timestamp given in RTP header.  The use of an unsigned
+       offset implies that redundant data must be sent after the primary
+       data, and is hence a time to be subtracted from the current
+       timestamp to determine the timestamp of the data for which this
+       block is the redundancy.
+
+   block length:  10 bits Length in bytes of the corresponding data
+       block excluding header.
+
+   It is noted that the use of an unsigned timestamp offset limits the
+   use of redundant data slightly:  it is not possible to send
+   redundancy before the primary encoding.  This may affect schemes
+   where a low bandwidth coding suitable for redundancy is produced
+   early in the encoding process, and hence could feasibly be
+   transmitted early.  However, the addition of a sign bit would
+   unacceptably reduce the range of the timestamp offset, and increasing
+   the size of the field above 14 bits limits the block length field.
+   It seems that limiting redundancy to be transmitted after the primary
+   will cause fewer problems than limiting the size of the other fields.
+
+   The timestamp offset for a redundant block is measured in the same
+   units as the timestamp of the primary encoding (ie:  audio samples,
+   with the same clock rate as the primary).  The implication of this is
+   that the redundant encoding MUST be sampled at the same rate as the
+   primary.
+
+   It is further noted that the block length and timestamp offset are 10
+   bits, and 14 bits respectively; rather than the more obvious 8 and 16
+   bits.  Whilst such an encoding complicates parsing the header
+   information slightly, and adds some additional processing overhead,
+   there are a number of problems involved with the more obvious choice:
+   An 8 bit block length field is sufficient for most, but not all,
+   possible encodings:  for example 80ms PCM and DVI audio packets
+   comprise more than 256 bytes, and cannot be encoded with a single
+   byte length field.  It is possible to impose additional structure on
+   the block length field (for example the high bit set could imply the
+   lower 7 bits code a length in words, rather than bytes), however such
+   schemes are complex.  The use of a 10 bit block length field retains
+
+
+
+Perkins, et. al.            Standards Track                     [Page 5]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+   simplicity and provides an enlarged range, at the expense of a
+   reduced range of timestamp values.
+
+   The primary encoding block header is placed last in the packet.  It
+   is therefore possible to omit the timestamp and block-length fields
+   from the header of this block, since they may be determined from the
+   RTP header and overall packet length.  The header for the primary
+   (final) block comprises only a zero F bit, and the block payload type
+   information, a total of 8 bits.  This is illustrated in the figure
+   below:
+
+                      0 1 2 3 4 5 6 7
+                     +-+-+-+-+-+-+-+-+
+                     |0|   Block PT  |
+                     +-+-+-+-+-+-+-+-+
+
+   The final header is followed, immediately, by the data blocks, stored
+   in the same order as the headers.  There is no padding or other
+   delimiter between the data blocks, and they are typically not 32 bit
+   aligned.  Again, this choice was made to reduce bandwidth overheads,
+   at the expense of additional decoding time.
+
+   The choice of encodings used should reflect the bandwidth
+   requirements of those encodings.  It is expected that the redundant
+   encoding shall use significantly less bandwidth that the primary
+   encoding:  the exception being the case where the primary is very
+   low-bandwidth and has high processing requirement, in which case a
+   copy of the primary MAY be used as the redundancy.  The redundant
+   encoding MUST NOT be higher bandwidth than the primary.
+
+   The use of multiple levels of redundancy is rarely necessary.
+   However, in those cases which require it, the bandwidth required by
+   each level of redundancy is expected to be significantly less than
+   that of the previous level.
+
+4  Limitations
+
+   The RTP marker bit is not preserved for redundant data blocks.  Hence
+   if the primary (containing this marker) is lost, the marker is lost.
+   It is believed that this will not cause undue problems:  even if the
+   marker bit was transmitted with the redundant information, there
+   would still be the possibility of its loss, so applications would
+   still have to be written with this in mind.
+
+   In addition, CSRC information is not preserved for redundant data.
+   The CSRC data in the RTP header of a redundant audio packet relates
+   to the primary only.  Since CSRC data in an audio stream is expected
+   to change relatively infrequently, it is recommended that
+
+
+
+Perkins, et. al.            Standards Track                     [Page 6]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+   applications which require this information assume that the CSRC data
+   in the RTP header may be applied to the reconstructed redundant data.
+
+5  Relation to SDP
+
+   When a redundant payload is used, it may need to be bound to an RTP
+   dynamic payload type.  This may be achieved through any out-of-band
+   mechanism, but one common way is to communicate this binding using
+   the Session Description Protocol (SDP) [6].  SDP has a mechanism for
+   binding a dynamic payload types to particular codec, sample rate, and
+   number of channels using the "rtpmap" attribute.  An example of its
+   use (using the RTP audio/video profile [3]) is:
+
+       m=audio 12345 RTP/AVP 121 0 5
+       a=rtpmap:121 red/8000/1
+
+   This specifies that an audio stream using RTP is using payload types
+   121 (a dynamic payload type), 0 (PCM u-law) and 5 (DVI). The "rtpmap"
+   attribute is used to bind payload type 121 to codec "red" indicating
+   this codec is actually a redundancy frame, 8KHz, and monaural.  When
+   used with SDP, the term "red" is used to indicate the redundancy
+   format discussed in this document.
+
+   In this case the additional formats of PCM and DVI are specified.
+   The receiver must therefore be prepared to use these formats.  Such a
+   specification means the sender will send redundancy by default, but
+   also may send PCM or DVI. However, with a redundant payload we
+   additionally take this to mean that no codec other than PCM or DVI
+   will be used in the redundant encodings.  Note that the additional
+   payload formats defined in the "m=" field may themselves be dynamic
+   payload types, and if so a number of additional "a=" attributes may
+   be required to describe these dynamic payload types.
+
+   To receive a redundant stream, this is all that is required.  However
+   to send a redundant stream, the sender needs to know which codecs are
+   recommended for the primary and secondary (and tertiary, etc)
+   encodings.  This information is specific to the redundancy format,
+   and is specified using an additional attribute "fmtp" which conveys
+   format-specific information.  A session directory does not parse the
+   values specified in an fmtp attribute but merely hands it to the
+   media tool unchanged.  For redundancy, we define the format
+   parameters to be a slash "/" separated list of RTP payload types.
+
+   Thus a complete example is:
+
+       m=audio 12345 RTP/AVP 121 0 5
+       a=rtpmap:121 red/8000/1
+       a=fmtp:121 0/5
+
+
+
+Perkins, et. al.            Standards Track                     [Page 7]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+   This specifies that the default format for senders is redundancy with
+   PCM as the primary encoding and DVI as the secondary encoding.
+   Encodings cannot be specified in the fmtp attribute unless they are
+   also specified as valid encodings on the media ("m=") line.
+
+6  Security Considerations
+
+   RTP packets containing redundant information are subject to the
+   security considerations discussed in the RTP specification [2], and
+   any appropriate RTP profile (for example [3]).  This implies that
+   confidentiality of the media streams is achieved by encryption.
+   Encryption of a redundant data stream may occur in two ways:
+
+     1.The entire stream is to be secured, and all participants are
+       expected to have keys to decode the entire stream.  In this case,
+       nothing special need be done, and encryption is performed in the
+       usual manner.
+
+     2.A portion of the stream is to be encrypted with a different
+       key to the remainder.  In this case a redundant copy of the last
+       packet of that portion cannot be sent, since there is no
+       following packet which is encrypted with the correct key in which
+       to send it.  Similar limitations may occur when
+       enabling/disabling encryption.
+
+   The choice between these two is a matter for the encoder only.
+   Decoders can decrypt either form without modification.
+
+   Whilst the addition of low-bandwidth redundancy to an audio stream is
+   an effective means by which that stream may be protected against
+   packet loss, application designers should be aware that the addition
+   of large amounts of redundancy will increase network congestion, and
+   hence packet loss, leading to a worsening of the problem which the
+   use of redundancy was intended to solve.  At its worst, this can lead
+   to excessive network congestion and may constitute a denial of
+   service attack.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et. al.            Standards Track                     [Page 8]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+7  Example Packet
+
+   An RTP audio data packet containing a DVI4 (8KHz) primary, and a
+   single block of redundancy encoded using 8KHz LPC (both 20ms
+   packets), as defined in the RTP audio/video profile [3] is
+   illustrated:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X| CC=0  |M|      PT     |   sequence number of primary  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              timestamp  of primary encoding                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1| block PT=7  |  timestamp offset         |   block length    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0| block PT=5  |                                               |
+   +-+-+-+-+-+-+-+-+                                               +
+   |                                                               |
+   +                LPC encoded redundant data (PT=7)              +
+   |                (14 bytes)                                     |
+   +                                               +---------------+
+   |                                               |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +                                                               +
+   |                DVI4 encoded primary data (PT=5)               |
+   +                (84 bytes, not to scale)                       +
+   /                                                               /
+   +                                                               +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +                                               +---------------+
+   |                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Perkins, et. al.            Standards Track                     [Page 9]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+8  Authors' Addresses
+
+   Colin Perkins/Isidor Kouvelas/Orion Hodson/Vicky Hardman
+   Department of Computer Science
+   University College London
+   London WC1E 6BT
+   United Kingdom
+
+   EMail:  {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.uk
+
+
+   Mark Handley
+   USC Information Sciences Institute
+   c/o MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   EMail:  mjh@isi.edu
+
+
+   Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis
+   INRIA Sophia Antipolis
+   2004 Route des Lucioles, BP 93
+   06902 Sophia Antipolis
+   France
+
+   EMail:  {bolot|avega|sfosse}@sophia.inria.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et. al.            Standards Track                    [Page 10]
+
+RFC 2198          RTP Payload for Redundant Audio Data    September 1997
+
+
+9  References
+
+   [1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson; Reliable
+   Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu,
+   Hawaii, September 1995.  http://www.isoc.org/in95prc/
+
+   [2] Schulzrinne, H., Casner, S., Frederick R., and V. Jacobson, "RTP:
+   A Transport Protocol for Real-Time Applications", RFC 1889, January
+   1996.
+
+   [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
+   with Minimal Control", RFC 1890, January 1996.
+
+   [4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation in
+   the MBone multicast network; IEEE Globecom Internet workshop, London,
+   November 1996
+
+   [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error
+   control for packet audio in the Internet; ACM Multimedia Systems,
+   1997
+
+   [6] Handley, M., and V. Jacobson, "SDP: Session Description Protocol
+   (draft 03.2)", Work in Progress.
+
+   [7] Bradner, S., "Key words for use in RFCs to indicate requirement
+   levels", RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et. al.            Standards Track                    [Page 11]
+