rfc2198.txt

RFC 的详细文档！

   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:  [e-mail]


   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]