rfc2733.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       J. Rosenberg
Request for Comments: 2733                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                           December 1999


       An RTP Payload Format for Generic Forward Error Correction


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 specifies a payload format for generic forward error
   correction of media encapsulated in RTP. It is engineered for FEC
   algorithms based on the exclusive-or (parity) operation. The payload
   format allows end systems to transmit using arbitrary block lengths
   and parity schemes. It also allows for the recovery of both the
   payload and critical RTP header fields. Since FEC is sent as a
   separate stream, it is backwards compatible with non-FEC capable
   hosts, so that receivers which do not wish to implement FEC can just
   ignore the extensions.

Table of Contents

   1     Introduction ...........................................    2
   2     Terminology ............................................    2
   3     Basic Operation ........................................    3
   4     Parity Codes ...........................................    5
   5     RTP Media Packet Structure .............................    6
   6     FEC Packet Structure ...................................    7
   6.1   RTP Header of FEC Packets ..............................    7
   6.2   FEC Header .............................................    7
   7     Protection Operation ...................................    9
   8     Recovery Procedures ....................................   10
   8.1   Reconstruction .........................................   10
   8.2   Determination of When to Recover .......................   12



Rosenberg & Schulzrinne     Standards Track                     [Page 1]

RFC 2733                      Generic FEC                  December 1999


   9     Example ................................................   16
   10    Use with Redundant Encodings ...........................   17
   11    Indicating FEC Usage in SDP ............................   20
   11.1  FEC as a Separate Stream ...............................   20
   11.2  Use with Redundant Encodings ...........................   21
   11.3  Usage with RTSP ........................................   22
   12    Security Considerations ................................   23
   13    Acknowledgments ........................................   24
   14    Authors' Addresses .....................................   24
   15    Bibliography ...........................................   25
   16    Full Copyright Statement ...............................   26

1 Introduction

   The quality of packet voice on the Internet has been mediocre due, in
   part, to high packet loss rates. This is especially true on wide-area
   connections. Unfortunately, the strict delay requirements of real-
   time multimedia usually eliminate the possibility of retransmissions.

   It is for this reason that forward error correction (FEC) has been
   proposed to compensate for packet loss in the Internet [1] [2]. In
   particular, the use of traditional error correcting codes, such as
   parity, Reed-Solomon, and Hamming codes, has attracted attention. To
   support these mechanisms, protocol support is required.

   This document defines a payload format for RTP [3] which allows for
   generic forward error correction of real time media. In this context,
   generic means that the FEC protocol is (1) independent of the nature
   of the media being protected, be it audio, video, or otherwise, (2)
   flexible enough to support a wide variety of FEC mechanisms, (3)
   designed for adaptivity so that the FEC technique can be modified
   easily without out of band signaling, and (4) supportive of a number
   of different mechanisms for transporting the FEC packets.

2 Terminology

   The following terms are used throughout this document:

       Media Payload: is a piece of raw, un-protected user data which
            is to be transmitted from the sender. The media payload is
            placed inside of an RTP packet.

       Media Header: is the RTP header for the packet containing the
            media payload.

       Media Packet: The combination of a media payload and media
            header is called a media packet.




Rosenberg & Schulzrinne     Standards Track                     [Page 2]

RFC 2733                      Generic FEC                  December 1999


       FEC Packet: The forward error correction algorithms at the
            transmitter take the media packets as an input. They output
            both the media packets that they are passed, and new
            packets called FEC packets. The FEC packets are formatted
            according to the rules specified in this document.

       FEC Header: The FEC header is the header information contained
            in an FEC packet.

       FEC Payload: The FEC payload is the payload in an FEC packet.

       Associated: An FEC packet is said to be "associated" with one or
            more media packets when those media packets are used to
            generate the FEC packet (by use of the exclusive or
            operation).

   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 [4].

3 Basic Operation

   The payload format described here is used whenever a participant in
   an RTP session would like to protect a media stream it is sending
   with forward error correction (FEC). The FEC supported by the format
   are those codes based on simple exclusive or (xor) parities. The
   sender takes some set of packets from the media stream, and applies
   an xor operation across the payloads. The sender also applies the xor
   operation over components of the RTP headers. Based on the procedures
   defined here, the result is an RTP packet containing FEC information.
   This packet can be used at the receiver to recover any one of the
   packets used to generate the FEC packet. This document does not
   mandate the particular set of media packets combined to generate an
   FEC packet (such a set [is] referred to as a code). Use of differing
   sets results in a tradeoff between overhead, delay, and
   recoverability.  Section 4 outlines some possible combinations.

   The payload format contains information that allows the sender to
   tell the receiver exactly which media packets have been used to
   generate the FEC. Specifically, each FEC packet contains a bitmask,
   called the offset mask, containing 24 bits. If bit i in the mask is
   set to 1, the media packet with sequence number N + i was used to
   generate this FEC packet. N is called the sequence number base, and
   is sent in the FEC packet as well. The offset mask and payload type
   are sufficient to signal arbitrary parity based forward error
   correction schemes with little overhead.





Rosenberg & Schulzrinne     Standards Track                     [Page 3]

RFC 2733                      Generic FEC                  December 1999


   This document also describes procedures that allow the receiver to
   make use of the FEC without having to know the details of specific
   codes. This allows the sender much flexibility; it can adapt the code
   in use based on network conditions, and be certain the receivers can
   still make use of the FEC for recovery.

   As the sender generates FEC packets, they are sent to the receivers.
   The sender still usually sends the original media stream, as if there
   were no FEC. This allows the media stream to still be used by
   receivers who are not FEC capable. However, some FEC codes do not
   require the original media to be sent; the FEC stream is sufficient
   for recovery. These codes have the drawback that all receivers must
   be FEC capable. However, they are supported by this format.

   The FEC packets are not sent in the same RTP stream as the media
   packets. They can be sent as a separate stream, or as a secondary
   codec in the redundant codec payload format [5]. When sent as a
   separate stream, the FEC packets have their own sequence number
   space. Although the timestamps for the FEC packets are derived from
   the media packets, they increment monotonically. FEC packet streams
   thus work well with any header compression mechanism which requires
   fixed deltas between fields in the packet header.

   This document does not prescribe the definition of "separate
   streams", but leaves this to applications and higher level protocols
   to define. For multicast, the separate stream may be implemented by
   separate multicast groups, different ports in the same group, or by a
   different SSRC within the same group/port. For unicast, different
   ports or different SSRC may be used. Each of these approaches has
   drawbacks and benefits which depend on the application.

   At the receiver, the FEC and original media are received. If no media
   packets are lost, the FEC can be ignored. In the event of loss, the
   FEC packets can be combined with other media and FEC packets that
   have been received, resulting in recovery of missing media packets.
   The recovery is exact; the payload is perfectly reconstructed, along
   with most components of the header.

   RTP packets which contain data formatted according to this
   specification (i.e., FEC packets) are signaled using dynamic RTP
   payload types.










Rosenberg & Schulzrinne     Standards Track                     [Page 4]

RFC 2733                      Generic FEC                  December 1999


4 Parity Codes

   For brevity, we define the function f(x,y,..) to be the XOR (parity)
   operator applied to the packets x,y,... The output of this function
   is another packet, called the parity packet. For simplicity, we
   assume here that the parity packet is computed as the bitwise XOR of
   the input packets. The exact procedure is specified in section 6.

   Recovery of data packets using parity codes is accomplished by
   generating one or more parity packets over a group of data packets.
   To be effective, the parity packets must be generated by linearly
   independent combinations of data packets. The particular combination
   is called a parity code. One class of codes takes a group of k data
   packets, and generates n-k parity packets. There are a large number
   of possible parity codes for a given n,k. The payload format does not
   mandate a particular code.

   For example, consider a parity code which generates a single parity
   packet over two data packets. If the original media packets are
   a,b,c,d, the packets generated by the sender are:

   a        b        c        d               <-- media stream
              f(a,b)            f(c,d)        <-- FEC stream

   where time increases to the right. In this example, the error
   correction scheme (we use the terms scheme and code interchangeably)
   introduces a 50% overhead. But if b is lost, a and f(a,b) can be used
   to recover b.

   Some additional codes are listed below. In each, the original media
   stream consists of packets a,b,c,d and so on.

   Scheme 1
   --------

   This scheme is the similar to the one in the example above. However,
   instead of sending b, followed by f(a,b), f(a,b) is sent before b.
   Doing this clearly requires additional delay at the sender. However,
   if allows some bursts of two consecutive packet losses to be
   recovered. The packets generated by the sender look like:

   a        b        c        d        e        <-- media stream
     f(a,b)   f(b,c)   f(c,d)   f(d,e)          <-- FEC stream








Rosenberg & Schulzrinne     Standards Track                     [Page 5]

RFC 2733                      Generic FEC                  December 1999


   Scheme 2
   --------

   It is not strictly necessary for the original media stream to be
   transmitted. In this scheme, only FEC packets are transmitted.  This
   scheme allows for recovery of all single packet losses and some
   consecutive packet losses, but with slightly less overhead than
   scheme 1. The packets generated by the sender look like:

   f(a,b)  f(a,c)  f(a,b,c)  f(c,d)  f(c,e)  f(c,d,e)  <-- FEC stream

   Scheme 3
   --------

   This scheme requires the receiver to wait an additional four packet
   intervals to recover the original media packets. However, it can
   recover from one, two or three consecutive packet losses. The packets
   generated by the sender look like:

   a         b          c                    d     <-- media stream
               f(a,b,c)    f(a,c,d) f(a,b,d)       <-- FEC stream

5 RTP Media Packet Structure

   The formatting of the media packets is unaffected by FEC. If the FEC
   is sent as a separate stream, the media packets are sent as if there
   was no FEC. If the FEC is being sent as a redundant codec, the media
   packets are sent as the main codec as defined in RFC 2198 [5].

   This lends to a very efficient encoding. When little (or no) FEC is
   used, there are mostly media packets being sent. This means that the
   overhead (present in FEC packets only) tracks the amount of FEC in
   use.


















Rosenberg & Schulzrinne     Standards Track                     [Page 6]

RFC 2733                      Generic FEC                  December 1999


6 FEC Packet Structure

   An FEC packet is constructed by placing an FEC header and FEC payload
   in the RTP payload, as shown in Figure 1:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC Payload                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: FEC Packet Structure

6.1 RTP Header of FEC Packets

   The version field is set to 2. The padding bit is computed via the
   protection operation, defined below. The extension bit is also
   computed via the protection operation. The SSRC value will generally
   be the same as the SSRC value of the media stream it protects. It MAY
   be different if the FEC stream is being demultiplexed via the SSRC