Internet Engineering Task Force                 Audio Video Transport WG
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-avt-fec-03.txt                  Bell Laboratories,Columbia U.
July 30, 1998
Expires: January 30, 1998

       An RTP Payload Format for Generic Forward Error Correction


   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference mate-
   rial or to cite them other than as ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

   Distribution of this document is unlimited.

1 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 or Reed Solo-
   mon codes, although it can be used with other techniques. The payload
   format allows end systems to transmit using arbitrary block lengths
   and parity schemes. It also allows for the recovery of both the pay-
   load 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

2 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

J.Rosenberg,H.Schulzrinne                                     [Page 1]

Internet Draft                Generic FEC                  July 30, 1998

   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 which allows for gen-
   eric 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.

3 Terminology

   The following terms are used throughout this document:

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

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

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

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

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

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

     7.   Associated: An FEC packet is said to be associated with one or
          more media packets when those media packets are used to gener-
          ate the FEC packet (by use of the exclusive or operation, for

4 Basic Operation

   The FEC packets are sent as a separate stream from the media packets.
   This implies that the FEC packets have their own sequence number and

J.Rosenberg,H.Schulzrinne                                     [Page 2]

Internet Draft                Generic FEC                  July 30, 1998

   timestamp space. The media packet stream is essentially unaffected by
   the use of FEC. This allows the two to be sent on a separate multi-
   cast group, so that non-FEC receivers can ignore the FEC and just
   receive the original media. The separation also allows for coherent
   values for the sequence numbers and timestamps.

   This document does not prescibe 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 differ-
   ent 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, arriving FEC and media packets are used to generate
   a stream of media packets for direct use by the application. This
   results in a clean separation of error protection from the applica-

   The coding scheme used for generating the FEC packets is indicated by
   means of the payload type field in the RTP header of the FEC packets.
   Currently, two mechanisms are defined: parity codes and Reed-Solomon

5 Parity Codes

   For brevity, we define the function f(x,y,..) to be the XOR (parity)
   operator applied to the data blocks x,y,... Each data block is simply
   a set of bits of length L. The function is only well defined when the
   lengths of the data blocks it operates on are equal. The output of
   this function is a single data block equal in length to the inputs,
   called the parity block. The parity block is the bitwise XOR of the
   input blocks. Note that f(x) = x.

   Recovery of data blocks using parity codes is accomplished by gener-
   ating one or more parity blocks over a group of k packets. To be
   effective, the parity blocks must be generated by linearly indepen-
   dent combinations of data blocks. The particular combination is
   called a parity code. After the parity operation, there will be a
   total of n data plus parity blocks (i.e., n-k parity blocks). There
   are a large number of possible parity codes for a given n,k. Reason-
   able codes exist for large ranges of n and k. The payload format does
   not mandate a particular code.

   For example, consider a parity code which generates a single parity
   block over two data blocks. The stream of blocks generated by the
   code is thus:

J.Rosenberg,H.Schulzrinne                                     [Page 3]

Internet Draft                Generic FEC                  July 30, 1998

   a, b, f(a,b), c, d, f(c,d)

   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 letters on the
   left represent the stream of input data blocks, and the right repre-
   sents the stream of data and parity blocks.

   Scheme 0

   This scheme is null, and has no error correction. The scheme is
   formally defined as:

   a,b,c,d, ...  -> a, b, c, d, ....

   Scheme 1

   This scheme is the similar to the one in the example above. The
   switching of the positions of f(b) and f(a,b) allow some bursts of two
   consecutive packet losses to be recovered. It is defined as:

   a,b,c,d,e,f -> a, f(a,b), b, f(b,c), c, f(c,d), d, ...

   Scheme 2

   This scheme allows for recovery of all single packet losses and some
   consecutive packet losses, but with less overhead than scheme 1:

   a,b,c,d,e,f,g -> f(a,b),f(a,c),f(a,b,c),f(c,d),f(c,e),f(c,d,e)...

   Scheme 3

   This scheme requires 4 packet delays to recover the original media
   payloads, but it can recover from 1,2, or 3 consecutive packet losses:

   a,b,c,d,e,f -> f(a),f(b),f(a,b,c),f(c),f(a,c,d),f(a,b,d),f(d), ...

J.Rosenberg,H.Schulzrinne                                     [Page 4]

Internet Draft                Generic FEC                  July 30, 1998

   The FEC protocol takes the media payloads as data blocks, and uses
   the XOR operator on them to generate parity blocks which are the FEC
   payloads. The xor operator is also applied to portions of the media
   headers to assist in their recovery.

   In order to decode the FEC payloads to media payloads, all that is
   necessary is for the receiver to know the set of media payloads in
   each FEC payload to which it is applied. This is exactly the informa-
   tion provided by the payload format.

   To determine which packets are associated with the FEC packet, a
   field is present in the FEC header, called the offset mask. Assume
   this mask is M bits. If bit i in the mask is set to 1, then the media
   packet with sequence number N + i is associated with this FEC packet,
   where N is the sequence number base in the FEC packet header. This
   effectively allows an FEC packet to be associated with any of the M
   packets before it.

   The offset mask and payload type are sufficient to signal arbitary
   parity based forward error correction schemes with little overhead.

6 Reed Solomon Codes

   Reed Solomon codes offer better protection than parity codes, but at
   an increased processing cost. The detailed operation of the codes is
   not important here. A Reed Solomon code takes a group of k data
   blocks and generates n - k FEC blocks. A receiver needs to receive
   any k of the n data or FEC blocks in order to recover the k data
   blocks. Besides k and n, the only parameters of the algorithm are the
   symbol length, which is the number of bits per symbol used in the
   algorithm. If the symbol length is l, the size of the data block must
   be a multiple of l.

7 RTP Media Packet Structure

   The media packets and FEC packets are sent as separate streams. The
   media packets are unaffected by FEC, and are sent in the same fashion
   they would be sent if there were no FEC.

   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

8 FEC Packet Structure

   When a packet is to be transmitted which contains FEC data (i.e., its
   payload is derived from one or more media payloads), the RTP header

J.Rosenberg,H.Schulzrinne                                     [Page 5]

Internet Draft                Generic FEC                  July 30, 1998

   is followed by an FEC header. We first discuss the semantics of the
   RTP header fields.

   The version field is set to 2. The padding bit is computed via the
   protection operation, defined below. The extension bit is also com-
   puted via the protection operation. The SSRC value should 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
   value. The CC value is computed via the protection operation. The
   CSRC list is never present, independent of the value of the CC field.
   The extension is never present, independent of the value of the X
   bit. The marker bit is computed via the protection operation.

   The sequence number has the standard definition: it is one higher
   than the sequence number in the previously transmitted FEC packet.
   The timestamp is set in the following fashion. When the FEC packet is
   sent, the value of the media RTP timestamp is examined. This value is
   used as the timestamp of the FEC packet. This results in the TS value
   in FEC packets to be monotonically increasing, independent of the FEC

   The payload type for the FEC packet is set as described above. End
   systems which cannot recognize a payload type must discard it anyway.
   This provides backwards compatibility. The FEC mechanisms can then be
   used in a multicast group with mixed FEC-capable and FEC-uncapable

   Following the RTP header is the FEC header. The header is different
   depending on whether Reed-Solomon or parity codes are in use,

8.1 Parity Header

   This header is nominally 96 bits, and may be optionally extended to
   128 bits. The format of the header is as follows:

      |      SN Base                  |        length recovery        |
      |E| PT Recovery |                 Mask                          |
      |                          TS Recovery                          |
      |                    Additional Offset Mask                     |

J.Rosenberg,H.Schulzrinne                                     [Page 6]

Internet Draft                Generic FEC                  July 30, 1998

   The length recovery field is used to determine the length of any
   recovered packets. It is computed via the protection operation
   applied to the 16 bit natural binary representation of the lengths
   (in bytes) of the media payload, CSRC list, extension and padding of
   media packets associated with this FEC packet (in other words, the
   CSRC list, extension, and padding, if present, are counted as part of
   the payload). This allows for the FEC procedure to be applied even
   when the lengths of the media packets are not identical. For example,
   assume an FEC packet is being generated by xor'ing two media packets
   together. The length of the two media packets are 3 (0b011) and 5
   (0b101) bytes, respectively. The length recovery field is then
   encoded as 0b011 xor 0b101 = 0b110.

   The E bit indicates a header extension. When set to 1, it indicates
   that an additional 32 bits of header follow.

   The PT recovery field is obtained via the protection operation
   applied to the payload types of the media packets associated with the
   FEC packet.

   The mask field is either 24 bits or 56 bits, depending on the value
   of E. If bit i in the mask is set to 1, then the media packet with
   sequence number N + i is associated with this FEC packet, where N is
   the SN Base field in the FEC packet header. When only the 24 bit mask
   is present, the LSB coresponds to i=0, and the MSB to i=23. When both
   the 24 bit mask and the extension are present, the LSB of the addi-
   tional mask corresponds to i=24, the MSB of the additional mask cor-
   responds to i=55, the LSB of the normal mask corresponds to i=0, and
   its MSB to i=23.

   The SN base field is always set to the minimum sequence number of
   those media packets protected by FEC. This allows for the FEC opera-
   tion to extend over any string of at most 24 (56 with the extensions)
   packets, whose range in sequence numbers is no more than 24 (56).

   The TS recovery field is computed via the protection operation
   applied to the timestamps of the media packets associated with this
   FEC packet. This allows the timestamp to be completely recovered.

   The payload of the FEC packet is the protection operation applied to
   the CSRC List plus payloads of the media packets associated with the
   FEC packet.

8.2 Reed Solomon Header

   The format of the Reed-Solomon FEC header is shown below.

J.Rosenberg,H.Schulzrinne                                     [Page 7]

Internet Draft                Generic FEC                  July 30, 1998

      |      SN Base                  |        length recovery        |
      |E| PT Recovery |       N       |        k      |       i       |
      |                          TS Recovery                          |

   The length recovery, E, PT Recovery and TS Recovery have the same
   syntax and semantics as for the parity header. The SN base is the
   sequence number of the first media packet in the group protected by
   FEC. The k field is the number of media packets in the block, minus
   1. The N field is the total number of FEC plus data packets in the
   block, minus 1. The i field indicates that this packet is the i+1th
   FEC packet of the N-K FEC packets in the code. The symbol length of
   the code is indicated by means of the payload type field in the RTP
   header. Currently, a value of 8 bits is denoted by the payload type
   [to be registered with IANA].

   The payload of the FEC packet is the protection operation applied to
   the CSRC List plus payloads of the media packets associated with the
   FEC packet, just like the parity codes.

9 Protection Operation

   The protection operation involves taking a variety of fields from the
   various headers, adding the payloads, appending the whole thing
   together, padding zeroes, and then computing the FEC across the
   resulting binary block. The result is then placed into the FEC

   For each media packet to be protected, a binary array is generated by
   appending the following fields together:

     oPadding Bit (1 bit)

     oExtension Bit (1 bit)

     oCC bits (3 bits)

     oMarker bit (1 bit)

     oPayload Type (7 bits)

     oTimestamp (32 bits)

J.Rosenberg,H.Schulzrinne                                     [Page 8]

Internet Draft                Generic FEC                  July 30, 1998

     oNatural binary representation of the length of the CSRC List plus
      padding plus payload plus extension of the media packet (16 bits)

     oCSRC List (if CC is 1), else null (variable)

     oHeader Extension (if X is 1), else null (variable)

     othe payload (variable)

     oPadding, if present (variable)

If the lengths of the binary arrays are not equal, they are padded with
zeroes to be the length of the longest binary array.

The FEC operation (R-S or parity) is then applied across the binary
arrays. The result is the binary array of the FEC packet.

The first bit in the FEC packet binary array is written into the Padding
Bit of the FEC packet. The second bit in the FEC packet binary array is
written into the Extension bit of the FEC packet. The next three bits of
the FEC packet binary array are written into the CC field of the FEC
packet. The next bit of the FEC packet binary array is written into the
marker bit of the FEC packet. The next 7 bits of the FEC packet binary
array are written into the PT recovery field in the FEC packet header.
The next 32 bits of the FEC packet binary array are written into the TS
recovery field in the packet header. The next 16 bits are written into
the Length Recovery field in the FEC packet header. The remaining bits
are set to be the payload of the FEC packet.

10 Recovery Procedures

   The FEC packets allow end systems to recover from the loss of media
   packets. All of the header fields of the missing packets, including
   CSRC lists, extensions, padding bits, marker and payload type, are
   recoverable.  This section describes the procedure for performing
   this recovery.

   Recovery requires two distinct operations. The first determines which
   packets (media and FEC) must be combined in order to recover a miss-
   ing packet. Once this is done, the second step is to actually recon-
   struct the data. The second step must be performed as described
   below. The first step can be based on any algorithm chosen by the
   implementor. Different algorithms result in a tradeoff between com-
   plexity and the ability to recover missing packets if at all possi-

10.1 Reconstruction

J.Rosenberg,H.Schulzrinne                                     [Page 9]

Internet Draft                Generic FEC                  July 30, 1998

   Let T be the list of packets (FEC and media) which can be combined to
   recover some media packet xi. In the case of Reed-Solomon, T is any k
   of the n data plus FEC packets in the group. For parity, this is an
   FEC packet plus all but one of the media packets indicated by the
   mask. The procedure is as follows:

     1.   For the media packets in T, compute the binary array as
          described in the previous section.

     2.   For the FEC packets in T, compute the binary array in the same
          fashion, except always set the CSRC list, extension, and pad-
          ding to null.

     3.   If the resulting binary arrays are not of equal length, pad
          them with zeroes to be the length of the longest binary array.

     4.   Apply the reconstruction to the binary arrays (XOR for parity
          codes, the RS procedure for Reed-Solomon codes), resulting in
          a recovery array.

     5.   Create a new packet with the standard 12 byte header and no

     6.   Set the version of the new packet to 2.

     7.   Set the Padding bit in the new packet to the first bit in the
          recovery array.

     8.   Set the Extension bit in the new packet to the second bit in
          the recovery array.

     9.   Set the CC field to the next three bits in the recovery array.

     10.  Set the marker bit in the new packet to the next bit in the
          recovery array.

     11.  Set the payload type in the new packet to the next 7 bits in
          the recovery array.

     12.  Set the SN field in the new packet to xi.

     13.  Set the TS field in the new packet to the next 32 bits in the
          recovery array.

     14.  Take the next 16 bits of the recovery array. Whatever the nat-
          ural binary number this corresponds to, take that many bytes
          from the recovery array and append them to the new packet.
          This represents the CSRC list, extension, payload, and

J.Rosenberg,H.Schulzrinne                                    [Page 10]

Internet Draft                Generic FEC                  July 30, 1998


     15.  Set the SSRC of the new packet to the SSRC of the media stream
          its protecting

This procedure will completely recover both the header and payload of an
RTP packet.

10.2 Determination of when to recover

10.2.1 Parity Codes

   The previous section discussed how to recover a media packet with
   sequence number xi when all of the packets needed to recover it were
   available. The decision about whether to attempt recovery of some
   media packet, and how to determine if sufficient data is available to
   recover it, is left to the implementor. However, this section pro-
   vides a simple algorithm which may be used for this purpose.

   The algorithm is described below in C code. The code assumes that
   several functions exist. recover_packet() takes the sequence number
   of a packet, and an FEC packet. Using the FEC packet and data packets
   received previously, the data packet with the given sequence number
   is recovered. add_fec_to_pending_list() adds the given FEC packet to
   a linked list of FEC packets which have not yet been used for recov-
   ery. wait_for_packet() waits for a packet, FEC or data, from the net-
   work. remove_from_pending_list() removes the FEC packet from the
   pending list. The structure packet contains a boolean variable fec
   which is true when the packet is FEC, false if its media. When its an
   FEC packet, the mask and snbase field contain those values from the
   FEC packet header. When its a media packet, the sn variable contains
   the sequence number of the packet. The global array A indicates which
   media packets have been received, and which have not. It is indexed
   by the sequence number of the packet.

   typedef struct packet_s {

     int sn;
     packet_s *next;
     BOOLEAN fec;

     BOOLEAN mask[24];
     int snbase;

   } packet;

J.Rosenberg,H.Schulzrinne                                    [Page 11]

Internet Draft                Generic FEC                  July 30, 1998

   BOOLEAN A[65535];
   packet *pending_list;

   packet *recover_with_fec(packet *fec_pkt) {

     packet *data_pkt;
     int pkts_present,  /* number of packets from the mask that are present */
       pkts_needed,    /* number of packets needed is the number of ones in
                    the mask minus 1 */
       pkt_to_recover, /* sn of the packet we are recovering */

     pkts_present = 0;
     pkts_needed = -1;
     for(i = 0; i < 24; i++) {
       if(A[i+fec_pkt->snbase] && mask[i]) pkts_present++;
       if(mask[i]) pkts_needed++;
       if(!A[i+fec_pkt->snbase] && mask[i]) pkt_to_recover = i+fec_pkt->snbase;

     if(pkts_present == pkts_needed) {
       data_pkt = recover_packet(pkt_to_recover, fec_pkt);
     }  else {
       data_pkt = NULL;


   void fec_recovery {

     packet *p,    /* packet received or regenerated */
       *fecp;      /* fec packet from pending list */

     while(1) {

       p = wait_for_packet();    /* get packet from network */

       while(p) {

         /* if its an FEC packet, try to recover with it. Otherwise,
         if its a data packet, mark it as received, and check if
         we can now recover a data packet with the list of pending
         FEC packets */

         if(p->fec == TRUE) {

J.Rosenberg,H.Schulzrinne                                    [Page 12]

Internet Draft                Generic FEC                  July 30, 1998

         p = recover_with_fec(p);
         } else {

        /* Mark this data packet as here */
        A[p->sn] = TRUE;

        /* Go through pending list. Try and recover a packet using
           each FEC. If we are successful, add the data packet to
           the list of received packets, remove the FEC packet from the
           pending list, since we've used it, and then try to recover
           some more */

        for(fecp = pending_list; fecp != NULL; fecp = fecp->next) {
          p = recover_with_fec(fecp);
          if(p) {
            A[p->sn] = TRUE;




   This simple recovery algorithm works efficiently for schemes which
   send a single FEC packet, and it will operate at lower effectiveness
   for schemes which send more. Clearly, storage of previously received
   FEC packets, and reexamination of them when later recoveries are
   made, can vastly improve performance. Such procedures are left to

10.2.2 Reed Solomon Codes

   The determination of when to recover is much more straightforward for
   Reed Solomon. When an FEC packet is received, the SN Base field is
   noted, and the FEC is placed in a bin according to the SN Base. Other
   FEC packets which arrive with the same SN Base are placed in that
   bin. When a data packet arrives, it is placed in the bin if its
   sequence number is within k of the SN Base, where k is obtained from
   the FEC packet header. When there are k packets in a bin, recovery
   can take place.

J.Rosenberg,H.Schulzrinne                                    [Page 13]

Internet Draft                Generic FEC                  July 30, 1998

11 Parity Example

   Consider 2 media packets to be sent, x and y. We wish to protect them
   by sending one FEC packet which is derived from x and y. The three
   packets are:

   Media Packet x

   Version:   2    (10)
   Padding:   0    (0)
   Extension: 0    (0)
   Marker:    0    (0)
   PTI:       11   (01011)
   SN:        8    (1000)
   TS:        3    (011)
   SSRC:      2    (10)

   The payload length is 10 bytes.

   Media Packet y

   Version:   2    (10)
   Padding:   0    (0)
   Extension: 0    (0)
   Marker:    1    (1)
   PTI:       18   (10010)
   SN:        9    (1001)
   TS:        5    (101)
   SSRC:      2    (10)

   The payload length is 11 bytes.

   The FEC packet is then:

   FEC Packet (contains a xor b)

   Version:   2    (10)
   Padding:   0    (0)
   Extension: 0    (0)
   Marker:    1    (1)     (NOTE: 0 xor 1 = 1)

J.Rosenberg,H.Schulzrinne                                    [Page 14]

Internet Draft                Generic FEC                  July 30, 1998

   PTI:       191          (NOTE: Assume PTI 191 implies XOR FEC)
   SN:        1
   TS:        5
   SSRC:      2    (10)

   len. rec.: 1    (1)         (NOTE: 0b1010 xor 0b1011 = 0001)
   PTI rec.:  24   (11001)
   SN base:   8
   TS rec.:   6    (110)  (3 xor 5 = 6)
   E:         0    (0)
   mask:      3   (000000000000000000000011)

   The payload length is 11 bytes.

12 Use with Redundant Encodings

   One can consider an FEC packet as a redundant coding of the media.
   Because of this, the payload format for encoding of redundant audio
   data [3] can be used to carry the FEC data along with the media. The
   procedure for this is simple. In some media packet, the payload type
   is set to the value for redundant encodings. The secondary coder is
   then set to be the FEC data. This means that the PTI of the secondary
   coder is set to the PTI value which indicates FEC. The block length
   of the secondary coder is set to the length of the FEC header and
   payload. The timestamp offset is set to the difference between the
   media timestamp and the timestamp from the FEC packet. The secondary
   coder payload includes the FEC header and FEC payload.

   This procedure only works if an FEC packet is sent after at least one
   of the media packets it is associated with has been sent. Otherwise,
   the timestamp offset would be negative, which is not allowed.

   Using the redundant encodings payload format also implies that the
   marker bit cannot be recovered.

   An advantage of this approach is a reduction in the overhead for
   sending FEC packets.

13 Conclusion

   This document has presented a new RTP payload format which allows for
   forward error correction of audio visual media. It is generic, allow-
   ing nearly any parity or Reed Solomon Code to be used. It is also
   backwards compatible with existing RTP implementations. Receivers
   which cannot understand FEC can discard the FEC packets, and still

J.Rosenberg,H.Schulzrinne                                    [Page 15]

Internet Draft                Generic FEC                  July 30, 1998

   receive the media packets.

14 Security Considerations

   There are no security considerations beyond those discussed in [4]
   and [5].

15 Full Copyright Statement

   Copyright (C) The Internet Society (1998). 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 implmentation 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 Soci-
   ety 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 fol-
   lowed, or as required to translate it into languages other than

   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

16 Author's Addresses

   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Rm. 4C-526

   Henning Schulzrinne
   Columbia University

J.Rosenberg,H.Schulzrinne                                    [Page 16]

Internet Draft                Generic FEC                  July 30, 1998

   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

17 Bibliography

   [1] J.-C. Bolot and A. Garcia, The case for fec-based error control
   for packet audio in the internet,   Multimedia Systems , 1997.

   [2] O. Hodson and C. Perkins, Options for repair of streaming media,
   Request for Comments (Informational) 2354, Internet Engineering Task
   Force, June 1998.

   [3] O. Hodson, I. Kouvelas, O. Hodson, M. Handley, and J. Bolot, RTP
   payload for redundant audio data, Request for Comments (Proposed
   Standard) 2198, Internet Engineering Task Force, Sept. 1997.

   [4] H. Schulzrinne, RTP profile for audio and video conferences with
   minimal control, Request for Comments (Proposed Standard) 1890,
   Internet Engineering Task Force, Jan. 1996.

   [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a
   transport protocol for real-time applications, Request for Comments
   (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.

J.Rosenberg,H.Schulzrinne                                    [Page 17]