[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-li-ulp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 RFC 5109

Internet Draft                                                  Adam Li
draft-ietf-avt-ulp-16.txt                                        Editor
February 28, 2006
Expires: August 28, 2006


        RTP Payload Format for Generic Forward Error Correction


STATUS OF THIS MEMO

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working 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
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a submission of the IETF AVT WG. Comments should be
   directed to the AVT WG mailing list, avt@ietf.org.


ABSTRACT

   This document specifies a payload format for generic Forward
   Error Correction (FEC) for media data encapsulated in RTP. It is
   based on the exclusive-or (parity) operation, and it is a
   generalized algorithm that includes Uneven Level Protection
   (ULP). The payload format described in this draft allows end
   systems to apply protection using arbitrary protection lengths
   and levels, in addition to using arbitrary protection group
   sizes. It enables complete recovery of the protected packets or
   partial recovery of the critical parts of the payload depending
   on the packet loss situation. This scheme is completely backward
   compatible with non-FEC capable hosts. The receivers that do not



Adam H. Li                                                     [Page 1]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   implement FEC can still work by simply ignoring the protection
   data. This specification obsoletes RFC 2733 and RFC 3009.



















































Adam H. Li                                                     [Page 2]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


Table of Contents

   1. Introduction .................................................. 4
   2. Terminology ................................................... 6
   3. Basic Operation ............................................... 6
   4. Parity Codes .................................................. 7
   5. Uneven Level Protection ....................................... 8
   6. RTP Media Packet Structure .................................... 9
   7. FEC Packet Structure .......................................... 9
   7.1. Baseline Mode FEC ........................................... 9
   7.2. Extended Mode FEC .......................................... 10
   7.3. RTP Header for FEC Packets ................................. 10
   7.4. FEC Header for FEC packets ................................. 11
   7.5. ULP Level Header for FEC Packets ........................... 12
   8. Protection Operation ......................................... 15
   8.1. Generation of Protected Bit String and FEC Bit String ...... 15
   8.2. Protection Operation in the Baseline Mode .................. 16
   8.3. Protection Operation in the Extended Mode .................. 16
   9. Recovery Procedure ........................................... 16
   9.1. Reconstruction in the Baseline Mode ........................ 17
   9.2. Reconstruction in the Extended Mode ........................ 18
   9.2.1. Extended Mode - Reconstruction of Level 0 ................ 18
   9.2.2. Extended Mode - Reconstruction of Level 1 and Higher ..... 18
   10. Examples .................................................... 19
   10.1. A Baseline Mode Example ................................... 20
   10.2. An Extended Mode Example With one Protection Level ........ 21
   10.3. An Extended Mode Example With Two Protection Levels ....... 23
   10.4. An Extended Mode Example With FEC As Redundant Coding ..... 27
   11. Security Considerations ..................................... 30
   12. Congestion Considerations ................................... 31
   13. IANA Considerations ......................................... 32
   13.1. Registration of audio/ulpfec .............................. 32
   13.2. Registration of video/ulpfec .............................. 33
   13.3. Registration of text/ulpfec ............................... 34
   13.4. Registration of application/ulpfec ........................ 35
   14. Multiplexing of FEC ......................................... 36
   14.1. FEC as a Separate Stream .................................. 36
   14.2. FEC as Redundant Encoding ................................. 37
   15. Indication FEC Usage in SDP ................................. 37
   15.1. FEC as a Separate Stream .................................. 37
   15.2. FEC as Redundant Encoding ................................. 38
   15.3. Offer / Answer Consideration .............................. 39
   16. Application Statement ....................................... 40
   17. Acknowledgements ............................................ 41
   18. Bibliography ................................................ 41
   18.1. Normative References ...................................... 41
   18.2. Informative References .................................... 42
   19. Author's Address ............................................ 43
   Copyright Statement ............................................. 44
   Disclaimer of Validity .......................................... 44



Adam H. Li                                                     [Page 3]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


1. Introduction

   The nature of real-time applications implies that they usually have
   more stringent delay requirements than normal data transmissions. As
   a result, retransmission of the lost packets is generally not a
   valid option for such applications. In these cases, a better method
   to attempt recovery of information from packet loss is through
   Forward Error Correction (FEC). FEC is one of the main methods used
   to protect against packet loss over packet switched networks [9,
   10]. In particular, the use of traditional error correcting codes,
   such as parity, Reed-Solomon, and Hamming codes, has seen much
   application. To apply these mechanisms, protocol support is
   required. RFC 2733 [9] and RFC 3009 [11] defined one of such FEC
   protocols. However, in these two RFCs a few fields (the P, X, and CC
   fields) in the RTP header are specified in ways which are not
   consistent as they are designed in RTP [1]. This prevents the
   payload-independent validity check of the RTP packets.

   This document extends the FEC defined in RFC 2733 and RFC 3009 to
   include unequal error protection on the payload data. It specifies a
   more general algorithm, which includes the algorithm of the two
   previous RFCs as its special cases. This specification also fix the
   above-mentioned inconsistency with RFC 2733 and RFC 3009, and will
   obsolete those two previous RFCs.

   This document defines a payload format for RTP [1] 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
   configurations, (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.

   Furthermore, in many scenarios the bandwidth of the network
   connections is a very limited resource. On the other hand, most of
   traditional FEC schemes are not designed for optimal utilization of
   the limited bandwidth resource. An often more efficient way to
   utilize the limited bandwidth would be to use unequal error
   protection to provide different levels of protection for different
   parts of the data stream which vary in importance. The unequal error
   protection schemes can usually make more efficient use of the
   bandwidth to provide better overall protection of the data stream
   against the loss. Proper protocol support is essential for realizing
   these unequal error protection mechanisms. The application of most
   of the unequal error protection schemes requires having the
   knowledge of the importance for different parts of the data stream.
   For that reason, most of such schemes are designed for a particular
   type of media according to the structure of the media protected, and
   as a result, are not generic.


Adam H. Li                                                     [Page 4]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Besides a simple baseline mode FEC, this document further defines an
   extended mode FEC algorithm and protocol that allows for generic
   forward error correction with unequal error protection for real-time
   media. It is called the Uneven Level Protection (ULP). The payload
   data are protected by one or more protection levels. Lower
   protection levels provide greater protection by using smaller group
   sizes (compared to higher protection levels) for generating the FEC
   packet. As we will discuss below, audio/video applications would
   generally benefit from unequal error protection schemes that give
   more protection to the beginning part of each packet. In the ULP
   algorithm defined in this draft, the data that are closer to the
   beginning of the packet are protected by lower protection levels
   because these data are in general more important and they tend to
   carry more information than the data further behind in the packet.

   It is well known that in many multimedia streams the more important
   parts of the data are always at the beginning of the data packet.
   This is the common practice for most codecs since the beginning of
   the packet is closer to the re-synchronization marker at the header
   and thus is more likely to be correctly decoded. In additional,
   almost all media formats have the frame headers at the beginning of
   the packet, which is the most vital part of the packet.

   For video streams, most modern formats have optional data
   partitioning modes to improve error resilience in which the video
   macroblock header data, the motion vector data, and DCT coefficient
   data are separated into their individual partitions. In ITU-T H.263
   version 3, there is the optional data partitioned syntax of Annex V.
   In MPEG-4 Visual Simple Profile, there is the optional data
   partitioning mode. When these modes are enabled, the video
   macroblock (MB) header and motion vector partitions (which are much
   more important to the quality of the video reconstruction) are
   transmitted in the partition(s) at the beginning of the video packet
   while residue DCT coefficient partitions (which are less important)
   are transmitted in the partition close to the end of the packet.
   Because the data is arranged in descending order of importance, it
   would be beneficial to provide more protection to the beginning part
   of the packet in transmission.

   For audio streams, the bitstreams generated by many of the new audio
   codecs also contain data with different classes of importance. These
   different classes are then transmitted in order of descending
   importance. Applying more protection to the beginning of the packet
   would also be beneficial in these cases. Even for uniform-
   significance audio streams, special stretching techniques can be
   applied to the partially recovered audio data packets. In cases
   where audio redundancy coding is used, more protection should be
   applied to the original data located in the first half of the
   packet. The rest of the packet containing the redundant copies of
   the data does not need the same level of protection.



Adam H. Li                                                     [Page 5]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Audio/video applications would generally benefit from the FEC
   algorithms specified in this document. With the extended mode ULP
   FEC, more efficient protection of the media payload can be
   potentially achieved. This document specifies the protocol and
   algorithm for applying the generic FEC to the RTP media payloads.


2. Terminology

   The following terms are used throughout this document:

   Media Payload: The raw, un-protected user data that are transmitted
   from the sender. The media payload is placed inside of an RTP
   packet.

   Media Header: 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.

   FEC Packet: The FEC algorithms at the transmitter take the media
   packets as an input. They output both the media packets that they
   are passed, and newly generated packets called FEC packets, which
   contain redundant media data used for error correction. The FEC
   packets are formatted according to the rules specified in this
   document.

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

   FEC Payload: The payload of an FEC packet.

   Associated: A FEC packet is said to be "associated" with one or more
   media packets (or vice versa) when those media packets are used to
   generate the FEC packet (by use of the exclusive-or operation). In
   case of extended mode FEC, this refers to only those packets used to
   generate the Level 0 FEC payload, if not explicitly stated
   otherwise.

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


3. Basic Operation

   The payload format described here is used when the sender in an RTP
   session would like to protect the media stream it is sending with
   generic parity FEC. The FEC supported by this format is based on
   simple exclusive-or (XOR) parities operation. The sender takes the
   packets from the media stream requiring protection and determines
   the operation needed, and in case of the extended mode, also the

Adam H. Li                                                     [Page 6]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   protection levels for these packets and the protection length for
   each level. The data are grouped together as described below in
   Section 7. XOR operation is applied across the payload to generate
   the FEC information. The result following the procedures defined
   here are RTP packets containing FEC information. These packets can
   be used at the receiver to recover the packets or parts of the
   packets used to generate the FEC information. By using unequal error
   protection provided by the extended mode, this scheme can
   potentially make more efficient use of the channel bandwidth, and
   provide more efficient error resilience for transmission over error-
   prone channels.

   The payload format for FEC contains information that allows the
   sender to tell the receiver exactly which media packets are
   protected by the FEC packet, and the protection levels and lengths
   for each of the levels. Specifically, each FEC packet contains an
   offset mask m(k) for each protection level k. If the bit i in the
   mask m(k) is set to 1, then media packet number N + i is protected
   by this FEC packet at level k. N is called the sequence number base,
   and is sent in the FEC packet as well. When the extended mode is
   used, the amount of data that are protected at level k is indicated
   by L(k), which is also sent in the FEC packet. The protection
   length, offset mask, payload type, and sequence number base fully
   identify the parity code applied to generate the FEC packet with
   little overhead. A set of rules is described in Section 7.5 that
   defines how the mask should be set for different protection levels,
   with examples in Section 10.

   This document also describes procedures on transmitting all the
   protection operation parameters in-band. This allows the sender
   great flexibility; the sender can adapt the protection to current
   network conditions and be certain the receivers can still make use
   of the ULP FEC for recovery.

   At the receiver, both the FEC and original media are received. If no
   media packets are lost, the FEC packets can be ignored. In the event
   of a loss, the FEC packets can be combined with other received media
   to recover all or part of the missing media packets.


4. Parity Codes

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

   Recovery of data blocks using parity codes is accomplished by
   generating one or more parity blocks over a group of data blocks. To
   be most effective, the parity blocks must be generated by linearly
   independent combinations of data blocks. The particular combination

Adam H. Li                                                     [Page 7]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   is called a parity code. One class of codes takes a group of k data
   blocks, and generates n-k parity blocks. 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
   block over two data blocks. 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.


5. Uneven Level Protection

   As we can see from the simple example above, the protection on the
   data depends on the size of the group. In the above example, the
   group size is 2. So if any one of the three packets (two payload
   packets and one FEC packet) is lost, the original payload data can
   still be recovered.

   In general, the FEC protection operation is a trade off between the
   bandwidth and the protection strength. The more FEC packets that are
   generated as a fraction of the source media packets, the stronger
   the protection against loss but the greater the bandwidth consumed
   by the combined stream.

   As is the common case in most of the media payload, not all the
   parts of the packets are of the same importance. Using this
   property, one can potentially achieve more efficient use of the
   channel bandwidth using unequal error protection, i.e., applying
   different protection for different parts of the packet. More
   bandwidth is spent on protecting the more important parts, while
   less bandwidth on the less important parts.

   A method to apply unequal error protection with the above-described
   parity code is to separate the packet into multiple levels and apply
   parity of different group size to each level. This algorithm is
   called uneven level protection, or ULP.

   The packets are separated into sections of decreasing importance,
   and protection of different strength is applied to each portion -
   the sections are known as "levels". The protection operation is
   applied independently at each level. A single FEC packet can carry
   parity data for multiple levels. As we have discussed in the
   introduction, media streams usually have the more important parts at
   the beginning of the packet. It is usually useful to have the

Adam H. Li                                                     [Page 8]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   stronger protection in the levels close to the beginning of the
   packet, and weaker protection in the levels further back. This is
   not only because the beginning of the packet has more importance,
   but it is also to avoid as much as possible the scenario that a
   earlier section of a packet is unrecoverable while a later section
   can be recovered. In such scenarios, the recovered later section is
   useless and the channel capacity is not fully utilized.

   The selection of the protection scheme of ULP MUST follow the
   protection rules as described in Section 7.5.


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

   This approach has the advantage that media packets can be
   interpreted by receivers which do not support FEC. The overhead for
   using the FEC scheme is only present in FEC packets, and can be
   easily monitored and adjusted by tracking the amount of FEC in use.


7. FEC Packet Structure

   The FEC packets has two modes: Baseline Mode and Extended Mode. The
   baseline mode protects each media packet to its full length with
   equal weight to all the parts of the packet. The extended mode
   provides additional flexibility by allowing different protection to
   be applied to different parts of the packets.

   The packets of the two modes of FEC are distinguished by the
   Extension bit carried in-band in the FEC header. External signaling
   is not needed. Mode can be changed on the fly in the same stream
   during a session.

7.1. Baseline Mode FEC

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












Adam H. Li                                                     [Page 9]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                RTP Header (12 octets or more)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 FEC Header (12 or 16 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC Payload                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: Baseline mode FEC Packet Structure


   Please note that baseline mode FEC packets contain only one payload
   section, and do not have any level headers.

7.2. Extended Mode FEC

   In the extended mode FEC (which is also called ULP FEC), a FEC
   packet is constructed by placing an FEC header and one or more
   levels of FEC header and payload into the RTP payload, as shown in
   Figure 2:


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                RTP Header (12 octets or more)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 FEC Header (12 or 16 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 FEC Level 0 Header (2 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC Level 0 Payload                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               FEC Level 1 Header (4 or 8 octets)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC Level 1 Payload                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Cont.                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: Extended mode FEC Packet Structure


7.3. RTP Header for FEC Packets

   The RTP header for FEC packets is only used when the FEC are sent in
   a separate stream from the protected payload stream (as defined in
   Section 14). Hence much of the discussion below applies only to that
   scenario. All the fields in the RTP header of FEC packets are used


Adam H. Li                                                    [Page 10]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   according to RFC 3550 [1], with some of them further clarified
   below.

   Marker: This field is not used for this payload type, and SHALL be
   set to 0.

   SSRC: The SSRC value SHALL be the same as the SSRC value of the
   media stream it protects.

   Sequence number: The sequence number has the standard definition -
   it MUST be one higher than the sequence number in the previously
   transmitted FEC packet.

   Timestamp: The timestamp MUST be set to the value of the media RTP
   clock at the instant the FEC packet is transmitted. Thus, the TS
   value in FEC packets is always monotonically increasing.

   Payload type: The payload type for the FEC packets is determined
   through dynamic, out-of-band means. According to RFC 3550 [1], RTP
   participants that cannot recognize a payload type must discard it.
   This provides backwards compatibility. The FEC mechanisms can then
   be used in a multicast group with mixed FEC-capable and FEC-
   incapable receivers, particularly when the FEC protection is sent as
   redundant encoding (see Section 14). In such cases, the FEC
   protection will have a payload type which is not recognized by the
   FEC-incapable receivers, and will thus be disregarded.

7.4. FEC Header for FEC Packets

   This header is 12 or 16 octets, depending on whether the long-mask
   flag (the L bit, see below) is set. The format of the header is
   shown in Figure 2 and consists of extension flag (E bit), long-mask
   flag (L bit), P recovery field, X recovery field, CC recovery field,
   M recovery field, PT recovery field, SN base field, TS recovery
   field, and the mask field.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|L|P|X|  CC   |M| PT recovery |            SN base            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TS recovery                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        length recovery        |             mask              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              mask cont. (present only when L = 1)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: FEC Header Format



Adam H. Li                                                    [Page 11]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   The E bit indicates the mode of the current FEC packet. The E bits
   for the baseline mode packets MUST be set to 0. The E bits for the
   extended mode packets MUST be set to 1.

   The L bit indicates whether the long mask is used. When the L bit is
   not set, the mask is 16-bit long. When the L bit is set, the mask is
   then 48-bit long.

   The P recovery field, the X recovery field, the CC recovery field,
   the M recovery field, and the PT recovery field are obtained via the
   protection operation applied to the P, X, CC, M, and PT values of
   the media packets associated with the FEC packet.

   The SN base field MUST be set to the lowest sequence number, taking
   wrap around into account, of those media packets protected by FEC
   (at all levels for the extended mode). This allows for the FEC
   operation to extend over any string of at most 16 packets when the L
   bit is not set or 48 packets when the L bit is set.

   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 length recovery field is used to determine the length of any
   recovered packets. It is computed via the protection operation
   applied to the unsigned network-ordered 16 bit representation of the
   sums of the lengths (in bytes) of the media payload, CSRC list,
   extension and padding of each of the media packets associated with
   this FEC packet (in other words, the CSRC list, RTP extension, and
   padding of the media payload packets, if present, are "counted" as
   part of the payload). This allows the FEC procedure to be applied
   even when the lengths of the protected 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 mask field in the FEC header indicates which packets are
   associated (or associated at level 0 if extended mode is used) with
   the FEC packet. It is either 16 bits or 48 bits depending on whether
   the L bit is set. 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. The
   most significant bit of the mask corresponds to i=0, and the least
   significant to i=15 when the L bit is not set or i=47 when the L bit
   is set.

7.5. ULP Level Header for FEC Packets

   The ULP Level Header is 2 octets for ULP level 0, and 4 or 8 octets
   (depending on whether the L bit is set in the FEC header) for ULP


Adam H. Li                                                    [Page 12]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   level 1 and higher. The formats of the headers are shown in Figure 3
   and Figure 4.

   Figure 3 shows the ULP FEC level header with level 0. It consists of
   only one field for the protection length. The Protection Length
   field is 16 bits. It indicates the protection length provided by the
   ULP FEC for Level 0 (i.e., the payload length after the SSRC field
   in the header).


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Protection Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: ULP Level Header Format (Level 0)


   Figure 4 shows the ULP FEC level header with level 1 and higher. It
   consists of a Protection Length field and a mask field (for level 1
   and higher headers). The protection length field is 16-bit long. The
   mask field is 16-bit long (when the L bit is not set) or 48-bit long
   (when the L bit is set). Its meaning is the same as the mask field
   in the main FEC header, except it now indicates which packets are
   protected by the FEC at the current level.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Protection Length       |             mask              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              mask cont. (present only when L = 1)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: ULP Level Header Format (Level 1 and higher)


   The setting of mask field when the extended mode FEC is used shall
   follow the following rules:

      a. A media packet SHALL be protected only once at each
         protection level higher than level 0. A media packet MAY be
         protected more than once at level 0 by different packets,
         providing the protection lengths of level 0 of these packets
         are equal.

      b. For a media packet to be protected at level p, it MUST also
         be protect at level p-1 in any FEC packets. Please note that
         the protection level p for a media packet can be in a FEC


Adam H. Li                                                    [Page 13]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


         packet that is different from the one which contains
         protection level p-1 for the same media packet.

      c. If an ULP FEC packet contains protection at level p, it MUST
         also contain protection at level p-1. Note that the
         combination of payload packets that are protected in level p
         may be different from those of level p-1.

   One example of the protection combinations is illustrated in Figure
   5 below. In this case, eight payload packets are protected by four
   FEC packets in three different level.


         Payload Packet #  |  FEC packet which protects at level
                           |       0           1           2
      ---------------------+---------------------------------------
                0          |       0           1           3
                1          |       0           1           3
                2          |       1           1           3
                3          |       1           1           3
                4          |       2           3           3
                5          |       2           3           3
                6          |       3           3           3
                7          |       3           3           3

   Figure 5: An example of protection combination


   In this example, FEC packet #0 and #2 only have protection level 0.
   FEC packet #1 has protection level 0 and 1, and FEC packet #3 has
   three protection levels.

   Read across the table, it is shown that payload packet #0 is
   protected by FEC packet #0 at level 0, by FEC packet #1 at level 1,
   and FEC packet #3 at level 2, and so on. Also, it can be easily seen
   from the table that FEC packet #1 protects at level 0 payload
   packets #2 and #3, at level 1 payload packets #0-#4, and so on.

   For more examples with more details, please refer to Section 10
   Examples.

   The payload of the ULP FEC packet of each level is the protection
   operation applied to the concatenation of the CSRC list, RTP
   extension, media payload, and padding of the media packets
   associated with the ULP FEC packet at that level. Details are
   described in the next section on the protection operation.

   Note that it's possible for the FEC packet to be slightly larger
   than the media packets it protects (due to the presence of the FEC
   headers). This could cause difficulties if this results in the FEC
   packet exceeding the Maximum Transmission Unit size for the path
   along which it is sent.

Adam H. Li                                                    [Page 14]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006




8. Protection Operation

   The protection operation involves copying the payload, padding it
   with zeros, and computing the parity (XOR) across the resulting bit
   strings. The resulting bit string is used to generate the ULP FEC
   packet.

   The following procedure MAY be followed for the protection
   operation. Other procedures MAY be used, but the end result MUST be
   identical to the one described here.

   The protection operation can be performed in one of the two modes:
   the baseline mode and the extended mode.

8.1. Generation of Protected Bit String and FEC bit string

   An FEC bit string is generated from the data of the media RTP
   packets for each protection operation at each level. The FEC bit
   string will be used to form the FEC Packets.

   For each media packet to be protected, a bit string is generated by
   concatenating the following fields together in the order specified:

      o The first 64 bits of the RTP header (64 bits)

      o Unsigned network-ordered 16 bit representation of the media
        packet length in bytes minus 12 (for the fixed RTP header),
        i.e., the sum of the lengths of all the following if present:
        the CSRC List, extension header, RTP payload, and RTP padding
        (16 bits)

      o if CC is nonzero, the CSRC List (variable length)

      o if X is 1, the Header Extension (variable length)

      o the payload (variable length)

      o the RTP padding, if present (variable length)

   If the lengths of the bit strings are not equal, each shorter bit
   string MUST be padded to the length of the longest bit string by
   adding octet 0 at the end. These resulting bit strings are known as
   the "protected bit strings" for the media packets.

   The protected bit strings for the media packets are used to generate
   the FEC bit string. The FEC bit string is equal to the bitwise
   exclusive OR of the protected bit strings.




Adam H. Li                                                    [Page 15]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


8.2. Protection Operation in the Baseline Mode

   The protection operation in the baseline mode is performed as the
   following after the FEC bit string is generated as described above.

   The first (most significant) two bits in the FEC bit string are
   skipped. The next bit in the FEC bit string is written into the P
   recovery bit of the FEC header in the FEC packet. The next bit in
   the FEC bit string is written into the E recovery bit of the FEC
   header. The next four bits of the FEC bit string are written into
   the CC recovery field of the FEC header. The next bit is written
   into the M recovery bit of the FEC header. The next 7 bits of the
   FEC bit string are written into the PT recovery field in the FEC
   header. The next 16 bits are skipped. The next 32 bits of the FEC
   bit string are written into the TS recovery field in the FEC header.
   The next 16 bits are written into the length recovery field in the
   packet header. The remaining bits are set to be the payload of the
   FEC packet.

8.3. Protection Operation in the Extended Mode

   For the protection operation at each level, first the FEC bit string
   needs to be generated from the media packets protected at that level
   as described above. Note that the group of protected payload packets
   may be different for each level.

   The FEC header of the FEC packet is generated from the FEC bit
   string for Level 0 in the same way as described above.

   For Protection Level n (n = 0, 1, ...), only Ln octets of data are
   set as the FEC Level n payload data after the Level n ULP header.
   The data is the Ln octets of data starting with the (Sn + 11)th
   octet in the FEC bit string, where:

   Sn = sum(Li : 0 <= i < n).

   Li is the Protection Length of Level i, and S0 is defined to be 0.
   The first 10 octets of the FEC bit string are used to generate the
   RTP header of the FEC packets as described above.


9. 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
   missing packet. Once this is done, the second step is to actually

Adam H. Li                                                    [Page 16]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   reconstruct the data. The second step MUST be performed as described
   below. The first step MAY be based on any algorithm chosen by the
   implementer. Different algorithms result in a tradeoff between
   complexity and the ability to recover missing packets, if possible.

   In the baseline mode, the lost payload packets are always fully
   recovered when it is recoverable from the FEC data. In the extended
   mode, however, the lost payload packets may be recovered in full or
   in parts depending on the data lose situation due to the nature of
   unequal error protection. The partial recovery of the packet can be
   detected by checking the recovery length of the packet retrieved
   from the FEC header against the actual length of the recovered
   payload data. The applications that use the extended mode need to
   have the capability of utilizing partially recovered data in order
   to take advantage of the unequal error protection capacity of the
   extended mode.

9.1. Reconstruction in the Baseline Mode

   Let T be the list of packets (FEC and media) which can be combined
   to recover some media packet xi. The procedure is as follows:

      1.  For the media packets in T, compute the protected bit string
          as described in the previous section.

      2.  For the FEC packet in T, compute the FEC bit string by
          concatenating the first 80 bits of the FEC header with the
          FEC payload.

      3.  If any of the protected bit strings generated from the media
          packets are shorter than the FEC bit string generated from
          the FEC packet, pad them to be the same length as the FEC bit
          string generated from the FEC. The padding of octet 0 MUST be
          added at the end of the protected bit string.

      4.  Calculate the recovery bit string as the bitwise exclusive OR
          of the protected bit string generated from all the media
          packets in T and the FEC bit string generated from all the
          FEC packets in T.

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

      6.  Set the version of the new packet to 2. Skip the first two
          bits in the recovery bit string.

      7.  Set the Padding bit in the new packet to the next bit in the
          recovery bit string.

      8.  Set the Extension bit in the new packet to the next bit in
          the recovery bit string.


Adam H. Li                                                    [Page 17]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


      9.  Set the CC field to the next four bits in the recovery bit
          string.

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

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

      12. Set the SN field in the new packet to xi. Skip the next 16
          bits in the recovery bit string.

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

      14. Take the next 16 bits of the recovery bit string. Whatever
          unsigned integer this represents (assuming network-order),
          take that many bytes from the recovery bit string and append
          them to the new packet. This represents the CSRC list,
          extension, payload, and the padding of the RTP payload.

      15. Set the SSRC of the new packet to the SSRC of the media
          stream it's protecting, i.e., the SSRC of the media stream to
          which the FEC stream is associated with.

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

9.2. Reconstruction in the Extended Mode

9.2.1. Extended Mode - Reconstruction of Level 0

   The reconstruction in the extended mode is the same as the
   reconstruction in the baseline mode, except that in step 14. For
   that step, the number of octets from the recovery bit string
   included into the recovery packet is equal to the Protection Length
   of Level 0 (L0).

   This procedure will recover both the header and payload of an RTP
   packet up to the Protection Length of level 0.

9.2.2. Extended Mode - Reconstruction of Level 1 and Higher

   Let T be the list of packets (FEC and media) which can be combined
   to recover some media packet xi at certain protection level. The
   procedure is as follows:

      1.  Assume that we are reconstructing the data for level n, the
          first step is to get the Protection Length of Level n (Ln)
          from the ULP Header of Level n.



Adam H. Li                                                    [Page 18]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


      2.  For the FEC packets in T, the FEC bit string of Level n is
          FEC Level n Payload, i.e., the Ln octets of data following
          the ULP Header of Level n.

      3.  For the media packets in T, the protected bit string of Level
          n is Ln octets of data starting with the (Sn + 13)th octet of
          the packet. Sn is the same as defined previously in this
          section. Note that the protection of Level 0 starts from the
          13th octet of the media packet after the SSRC field.

      4.  If any of the protected bit strings of Level n generated from
          the media packets are shorter than the Protection Length of
          the current level, pad them to that length. The padding of
          octet 0 MUST be added at the end of the bit string.

      5.  Calculate the recovery bit string as the bitwise exclusive OR
          of the protected bit string of Level n generated from all the
          media packets in T and the FEC bit string of Level n
          generated from all the FEC packets in T.

      6.  The recovery bit string of the current protection level as
          generated above is concatenated with the recovery bit string
          of all the lower levels to form the (fully or partially)
          recovered media packet. Note that the reconstruction
          operation of the lower level MUST be performed before those
          of higher level is performed.

      7.  The total length of the recovered media packet is recovered
          from the recovery operation at protection level 0 of the
          recovered media packet. If the complete recovery operation
          (of all levels) does not recover the packet to its full
          length, the un-recovered part of the packet SHOULD be filled
          (with any data chosen by the implementation) to the total
          length of the packet.

   For the FEC data protection in the extended mode, the data protected
   at lower protection level is recoverable in majority of the cases if
   the higher level protected data is recoverable. This procedure
   (together with the procedure for the lower protection levels) will
   usually recover both the header and payload of an RTP packet up to
   the Protection Length of the current level.


10. Examples

   In the first three examples considered below (Section 10.1, 10.2,
   and 10.3), we assume the FEC streams are sent through a separate RTP
   session as described in Section 14.1. For these examples we assume
   that 4 media packets are to be sent, A, B, C and D, from SSRC 2.
   Their sequence numbers are 8, 9, 10 and 11, respectively, and have
   timestamps of 3, 5, 7 and 9, respectively. Packet A and C uses
   payload type 11, and packet B and D uses payload type 18. Packet A

Adam H. Li                                                    [Page 19]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   has 200 bytes of payload, packet B 140, packet C 100 and packet D
   340. Packet A and C have their marker bit set.

   The fourth example, is to illustrate when the FEC data is sent as
   redundant data with the payload packets.

10.1. A Baseline Mode Example

   We can protect the four payload packet with one FEC packet in the
   baseline mode. The scheme is as shown in Figure 6.


              +-------------------+             :
   Packet A   |                   |             :
              +-------------+-----+             :
   Packet B   |             |                   :
              +---------+---+                   :
   Packet C   |         |                       :
              +---------+-----------------------+
   Packet D   |                                 |
              +---------------------------------+
                                                :
              +---------------------------------+
   Packet FEC |                                 |
              +---------------------------------+
              :                                 :
              :<------------- L0 -------------->:

   Figure 6 FEC scheme in the baseline mode


   An FEC packet is generated from these four packets. We assume that
   payload type 127 is used to indicate an FEC packet. The resulting
   RTP header is shown in Figure 7.

   The FEC header in the FEC packet is shown in Figure 8.


    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 0|0|0|0 0 0 0|0|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:   2
      Padding:   0
      Extension: 0
      Marker:    0

Adam H. Li                                                    [Page 20]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


      PT:        127
      SN:        1
      TS:        9
      SSRC:      2

   Figure 7: RTP Header of FEC Packet (baseline mode)


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0 0 0 0|0|0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      E:         0     [FEC in baseline mode]
      L:         0     [short 16-bit mask]
      P rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      X rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      CC rec.:   0     [0 XOR 0 XOR 0 XOR 0]
      M rec.:    0     [1 XOR 0 XOR 1 XOR 0]
      PT rec.:   0     [11 XOR 18 XOR 11 XOR 18]
      SN base:   8     [min(8,9,10,11)]
      TS rec.:   8     [3 XOR 5 XOR 7 XOR 9]
      len. rec.: 372   [200 XOR 140 XOR 100 XOR 340]
      mask:      61440 [with Bit 1, 2, 3, and 4 marked accordingly for
                        Packet 8, 9, 10, and 11]

   Figure 8: FEC Header of FEC Packet (baseline mode)


10.2. An Extended Mode Example With One Protection Level

   Suppose we want to protect the data of length L0 = 70 bytes of them
   at the beginning of these packets, as illustrated in Figure 9 below.















Adam H. Li                                                    [Page 21]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


              +------:------------+
   Packet A   |      :            |
              +------:------+-----+
   Packet B   |      :      |
              +------:--+---+
   Packet C   |      :  |
              +------:--+-----------------------+
   Packet D   |      :                          |
              +------:--------------------------+
                     :
              +------+
   Packet FEC |      |
              +------+
              :      :
              :<-L0->:

   Figure 9 ULP FEC scheme with only protection level 0


   The resulting FEC packet will have the same RTP header as shown in
   Figure 7.

   The FEC header in the FEC packet is shown in Figure 10. It is the
   same as the FEC header in Figure 8, except that the E bit is set to
   1.

   The ULP header level 0 present before the parity data of level 0 in
   the FEC packet is as shown in Figure 11.

























Adam H. Li                                                    [Page 22]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   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|0|0|0|0 0 0 0|0|0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      E:         1     [FEC in extended mode]
      L:         0     [short 16-bit mask]
      P rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      X rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      CC rec.:   0     [0 XOR 0 XOR 0 XOR 0]
      M rec.:    0     [1 XOR 0 XOR 1 XOR 0]
      PT rec.:   0     [11 XOR 18 XOR 11 XOR 18]
      SN base:   8     [min(8,9,10,11)]
      TS rec.:   8     [3 XOR 5 XOR 7 XOR 9]
      len. rec.: 372   [200 XOR 140 XOR 100 XOR 340]
      mask:      61440 [with Bit 1, 2, 3, and 4 marked accordingly for
                        Packet 8, 9, 10, and 11]

   Figure 10: FEC Header of FEC Packet (extended mode)


   0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L0:        70

      The payload length for level 0 is 70 bytes.

   Figure 11: ULP Level Header (Level 0)


10.3. An Extended Mode Example With Two Protection Levels

   A more complex example is to use extended mode FEC at two levels.
   The level 0 FEC will provide greater protection to the beginning
   part of the payload packets. The level 1 FEC will apply additional
   protection to the rest of the packets. This is illustrated in Figure
   12. In this example, we take L0 = 70 and L1 = 90.







Adam H. Li                                                    [Page 23]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


              +------:--------:---+
   Packet A   |      :        :   |
              +------:------+-:---+
   Packet B   |      :      | :
              +------:--+---+ :
                     :        :
              +------+        :
   ULP #1     |      |        :
              +------+        :
                     :        :
              +------:--+     :
   Packet C   |      :  |     :
              +------:--+-----:-----------------+
   Packet D   |      :        :                 |
              +------:--------:-----------------+
                     :        :
              +------:--------+
   ULP #2     |      :        |
              +------:--------+
              :      :        :
              :<-L0->:<--L1-->:

   Figure 12 ULP FEC scheme with protection level 0 and level 1


   This will result in two extended mode FEC packets - #1 and #2.

   The resulting ULP FEC packet #1 will have the RTP header as shown in
   Figure 13. The FEC header for ULP FEC packet #1 will be as shown in
   Figure 14. The level 0 ULP header for #1 will be shown in Figure 15.


    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 0|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:   2
      Padding:   0
      Extension: 0
      Marker:    1
      PT:        127
      SN:        1
      TS:        5
      SSRC:      2

   Figure 13: RTP Header of FEC Packet #1

Adam H. Li                                                    [Page 24]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006




    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|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      E:         1     [FEC in extended mode]
      L:         0     [short 16-bit mask]
      P rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      X rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      CC rec.:   0     [0 XOR 0 XOR 0 XOR 0]
      M rec.:    0     [1 XOR 0 XOR 1 XOR 0]
      PT rec.:   25    [11 XOR 18]
      SN base:   8     [min(8,9)]
      TS rec.:   6     [3 XOR 5]
      len. rec.: 68    [200 XOR 140]
      mask:      49152 [with Bit 1 and 2 marked accordingly for
                        Packet 8 and 9]

   Figure 14: FEC Header of ULP FEC Packet #1


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L0:        70

      The payload length for level 0 is 70 bytes.

   Figure 15: ULP Level Header (Level 0) for FEC Packet #1


   The resulting FEC packet #2 will have the RTP header as shown in
   Figure 16. The FEC header for FEC packet #2 will be as shown in
   Figure 17. The level 0 ULP header for #2 will be shown in Figure 18.
   The level 1 ULP header for #2 will be shown in Figure 19.








Adam H. Li                                                    [Page 25]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


    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 0|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:   2
      Padding:   0
      Extension: 0
      Marker:    1
      PT:        127
      SN:        2
      TS:        9
      SSRC:      2

   Figure 16: RTP Header of FEC Packet #2


    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|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0|0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      E:         1     [FEC in extended mode]
      L:         0     [short 16-bit mask]
      P rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      X rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      CC rec.:   0     [0 XOR 0 XOR 0 XOR 0]
      M rec.:    0     [1 XOR 0 XOR 1 XOR 0]
      PT rec.:   25    [11 XOR 18]
      SN base:   8     [min(8,9,10,11)]
      TS rec.:   14    [7 XOR 9]
      len. rec.: 304   [100 XOR 340]
      mask:      12288 [with Bit 3 and 4 marked accordingly for
                        Packet 10 and 11]

   Figure 17: FEC Header of FEC Packet #2







Adam H. Li                                                    [Page 26]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L0:        70

      The payload length for level 0 is 70 bytes.

   Figure 18: ULP Level Header (Level 0) for FEC Packet #2


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L1:        90
      mask:      61440 [with Bit 1, 2, 3, and 4 marked accordingly for
                        Packet 8, 9, 10, and 11]

      The payload length for level 1 is 90 bytes.

   Figure 19: ULP Level Header (Level 1) for FEC Packet #2


10.4. An Extended Mode Example With FEC As Redundant Coding

   This example illustrates FEC sent as redundant coding in the same
   stream as the payload. We assume that five media packets are to be
   sent, A, B, C, D, and E, from SSRC 2. Their sequence numbers are 8,
   9, 10, 11, and 12, respectively, and with timestamps of 3, 5, 7, 9,
   and 11, respectively. All the media data are coded with primary
   coding (and FEC as redundant coding only protects the primary
   coding) and uses payload type 11. Packet A has 200 bytes of payload,
   packet B 140, packet C 100, packet D 340, and packet E 160. Packet A
   and C have their marker bit set.

   The FEC scheme we use will be the extended mode with one level as
   illustrated by Figure 9 in Section 10.2. The protection length L0    70 octets in the beginning of the packet.

   A redundant coding packetization is used with payload type 100. The
   payload type of the FEC is assumed to be 127. The first four RED
   packets, RED #1 through RED #4, each contains an individual media
   packet, A, B, C, or D, respectively. The FEC data protecting the
   media data in the first four media packets is generated. The fifth
   packet, RED #5, contains this FEC data as redundant coding along
   with media packet E.


Adam H. Li                                                    [Page 27]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   RED Packet #1:    Media Packet A
   RED Packet #2:    Media Packet B
   RED Packet #3:    Media Packet C
   RED Packet #4:    Media Packet D
   RED Packet #5:    FEC Packet, Media Packet E

   RED packet #1 through #4 will have the structure as shown in Figure
   20. The RTP header of the RED packet #1 is as shown in Figure 21,
   with all the other RED packets in similar format with corresponding
   sequence numbers and time stamps. The primary encoding block header
   of the RED packets is as shown in Figure 22.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 6 octets                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Primary Encoding Block Header (RED) - 1 octet          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Media Packet Data                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 20: RED Packet Structure - Media Data Only


    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 0|0|0|0 0 0 0|0|1 1 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:   2
      Padding:   0
      Extension: 0
      Marker:    0     [Even though media packet A has marker set]
      PT:        100   [Payload type for RED]
      SN:        1
      TS:        5
      SSRC:      2

   Figure 21: RTP Header of RED Packet #1









Adam H. Li                                                    [Page 28]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0|0 0 0 1 0 1 1|
   +-+-+-+-+-+-+-+-+

      F bit:     0     [This is the primary coding data]
      Block PT:  11    [The payload type of media]

   Figure 22: Primary Encoding Block Header


   The FEC data is generated not directly from the RED packets, but
   from the virtual RTP packets containing the media packet data. Those
   virtual RTP packets can be very easily generated from the RED
   packets both with or without redundant coding included. The
   conversion from RED packets to virtual RTP packets is simply done by
   (1) removing any RED block headers and redundant coding data, and
   (2) replace the PT in the RTP header with the PT of the primary
   coding. Note: In the payload format for redundant coding as
   specified by RFC 2198 the marker bit is lost as soon as the primary
   coding is carried in the RED packets. So the marker bit can not be
   recovered regardless the FEC is used or not.

   As mentioned above, RED packet #5 will contain the FEC data (that
   protects media packet A, B, C, and D) as well as the data of media
   packet E. The structure of RED packet #5 is as illustrated in Figure
   23.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 6 octets                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Redundant Encoding Block Header (RED) - 4 octet         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Packet Data                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Primary Encoding Block Header (RED) - 1 octet          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Media Packet Data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 23: RED Packet Structure - With FEC Data


   The RTP header of the RED packets with FEC included is the same as
   shown in Figure 20, with their corresponding sequence numbers and
   time stamps.

   In RED packet #5, the redundant encoding block header for the FEC
   packet data block is as shown below in Figure 24. It will be
   followed by the FEC packet data which, in this case, includes an FEC
   header (12 octets as shown in Figure 25), ULP Level 0 header (2

Adam H. Li                                                    [Page 29]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   octets as shown in Figure 26) and the ULP Level 0 data (70 octets as
   set for Level 0).


    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|0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 1 0 1 0 1 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      F bit:     1     [This is the redundant coding data]
      Block PT:  127   [The dynamic payload type for FEC]
      TS Offset: 0     [The instance at which the FEC data is
                        transmitted]
      Block Len: 84    [FEC header (12 octets) plus ULP Level 0 header
                        (2 octets) and ULP Level 0 data (70 octets)]

   Figure 24: Redundant Encoding Block Header


11. Security Considerations

   There are two ways to use FEC with encryption in secure
   communications: one way is to apply the FEC on already encrypted
   payloads, and the other way is to apply the FEC before the
   encryption.

   Since the protected payload of this FEC are RTP packets, applying
   FEC on encrypted payloads is primarily applicable in the case of
   secure RTP (SRTP) [12]. Because the FEC applies XOR across the
   payload, the FEC packets should be cryptographically as secure as
   the original payload. In such cases, additional encryption of the
   FEC packets is not necessary.

   In the following discussion, it is assumed that the FEC is applied
   to the payload before the encryption. The use of FEC has
   implications on the usage and changing of keys for encryption. As
   the FEC packets do consist of a separate stream, there are a number
   of combinations on the usage of encryption. These include:

      o The FEC stream may be encrypted, while the media stream is not.

      o The media stream may be encrypted, while the FEC stream is not.

      o The media stream and FEC stream are both encrypted, but using
        different keys.

      o The media stream and FEC stream are both encrypted, but using
        the same key.

   The first three of these would require all application level
   signaling protocols used to be aware of the usage of FEC, and to

Adam H. Li                                                    [Page 30]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   thus exchange keys and negotiate encryption usage on the media and
   FEC streams separately. In the final case, no such additional
   mechanisms are needed. The first two cases present a layering
   violation, as ULP FEC packets should be treated no differently than
   other RTP packets. Encrypting just one stream may also make certain
   known-plaintext attacks possible. For these reasons, applications
   utilizing encryption SHOULD encrypt both streams.

   The changing of encryption keys is another crucial issue needs to be
   addressed. Consider the case where two packets a and b are sent
   along with the FEC packet that protects them. The keys used to
   encrypt a and b are different, so which key should be used to decode
   the FEC packet? In general, old keys need to be cached, so that when
   the keys change for the media stream, the old key can be used until
   it is determined that the key has changed for the ULP FEC packets as
   well. The sender and the receiver need to define how the encryption
   is performed and how the keys are used.

   The integrity of the FEC packets can have a big impact on the
   reconstruction operation. Changing some bits in the FEC payload can
   have significant effect on the calculation and the correct recovery
   of the payload packets. For example, change the length recovery
   field can result in the recovery of a packet which is too long.
   Also, the computational complexity of the recovery can be easily
   effected for up to at least one order of magnitude.


12. Congestion Considerations

   Another issue with the use of FEC is its impact on network
   congestion. In many situations, the packet loss in the network is
   induced by congestions. In such scenarios, adding FEC when
   encountering increasing network losses should be avoided. If it is
   used on a widespread basis, this can result in increased congestion
   and eventual congestion collapse. The applications may include
   stronger protections while at the same time reduce the bandwidth for
   the payload packets. In any event, implementations MUST NOT
   substantially increase the total amount of bandwidth in use
   (including the payload and the FEC) as network losses increase.

   The general congestion control considerations for transporting RTP
   data apply, see RTP [1] and any applicable RTP profile like AVP
   [13]. An additional requirement if best-effort service is being used
   is: users of this payload format MUST monitor packet loss to ensure
   that the packet loss rate is within acceptable parameters. Packet
   loss is considered acceptable if a TCP flow across the same network
   path, and experiencing the same network conditions, would achieve an
   average throughput, measured on a reasonable timescale, that is not
   less than the RTP flow is achieving.  This condition can be
   satisfied by implementing congestion control mechanisms to adapt the
   transmission rate (or the number of layers subscribed for a layered


Adam H. Li                                                    [Page 31]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   multicast session), or by arranging for a receiver to leave the
   session if the loss rate is unacceptably high.


13. IANA Considerations

   Four new MIME sub-types as described in this section are to be
   registered with IANA. This registration is done using the
   registration template [3] and following RFC 3555 [4].

13.1. Registration of audio/ulpfec

   MIME media type name: audio

   MIME subtype name: ulpfec

   Required parameters:

      Rate: The RTP timestamp rate which is used to mark the time of
      transmission of the FEC packet in separate stream. In cases it
      is sent as redundant data to another stream the rate SHALL be
      the same as the primary encoding it is used to protect. When
      used in a separate stream the rate SHALL be larger than 1000 Hz
      to provide sufficient resolution to RTCP operations. The
      selected rate MAY be any value above 1000 Hz but is RECOMMENDED
      to match the rate of the media this stream protects.

   Optional parameters: none

   Encoding considerations: This format is framed (see Section 4.8 in
   the template document [3]) and contains binary data.

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [1]. Transport within
   other framing protocols SHALL NOT be defined as this is a robustness
   mechanism for RTP.

   Security considerations: the same security considerations apply to
   these MIME registrations as to the payloads for them, as detailed in
   RFC xxxx.

   Interoperability considerations: none

   Published specification: RFC xxxx.

   Applications which use this media type: Audio and video streaming
   tools which seek to improve resiliency to loss by sending additional
   data with the media stream.

   Additional information: none



Adam H. Li                                                    [Page 32]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Person & email address to contact for further information:
      Adam Li adamli@hyervision.com
      IETF Audio/Video Transport Working Group

   Intended usage: COMMON

   Author:
      Adam Li adamli@hyervision.com

   Change controller:
      IETF Audio/Video Transport Working Group delegated from the
      IESG.

13.2. Registration of video/ulpfec

   MIME media type name: video

   MIME subtype name: ulpfec

   Required parameters:

      Rate: The RTP timestamp rate which is used to mark the time of
      transmission of the FEC packet in separate stream. In cases it
      is sent as redundant data to another stream the rate SHALL be
      the same as the primary encoding it is used to protect. When
      used in a separate stream the rate SHALL be larger than 1000 Hz
      to provide sufficient resolution to RTCP operations. The
      selected rate MAY be any value above 1000 Hz but is RECOMMENDED
      to match the rate of the media this stream protects.

   Optional parameters: none

   Encoding considerations: This format is framed (see Section 4.8 in
   the template document [3]) and contains binary data.

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [1]. Transport within
   other framing protocols SHALL NOT be defined as this is a robustness
   mechanism for RTP.

   Security considerations: the same security considerations apply to
   these MIME registrations as to the payloads for them, as detailed in
   RFC xxxx.

   Interoperability considerations: none

   Published specification: RFC xxxx.

   Applications which use this media type: Audio and video streaming
   tools which seek to improve resiliency to loss by sending additional
   data with the media stream.


Adam H. Li                                                    [Page 33]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Additional information: none

   Person & email address to contact for further information:
      Adam Li adamli@hyervision.com
      IETF Audio/Video Transport Working Group

   Intended usage: COMMON

   Author:
      Adam Li adamli@hyervision.com

   Change controller:
      IETF Audio/Video Transport Working Group delegated from the
      IESG.

13.3. Registration of text/ulpfec

   MIME media type name: text

   MIME subtype name: ulpfec

   Required parameters:

      Rate: The RTP timestamp rate which is used to mark the time of
      transmission of the FEC packet in separate stream. In cases it
      is sent as redundant data to another stream the rate SHALL be
      the same as the primary encoding it is used to protect. When
      used in a separate stream the rate SHALL be larger than 1000 Hz
      to provide sufficient resolution to RTCP operations. The
      selected rate MAY be any value above 1000 Hz but is RECOMMENDED
      to match the rate of the media this stream protects.

   Optional parameters: none

   Encoding considerations: This format is framed (see Section 4.8 in
   the template document [3]) and contains binary data.

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [1]. Transport within
   other framing protocols SHALL NOT be defined as this is a robustness
   mechanism for RTP.

   Security considerations: the same security considerations apply to
   these MIME registrations as to the payloads for them, as detailed in
   RFC xxxx.

   Interoperability considerations: none

   Published specification: RFC xxxx.




Adam H. Li                                                    [Page 34]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Applications which use this media type: Audio and video streaming
   tools which seek to improve resiliency to loss by sending additional
   data with the media stream.

   Additional information: none

   Person & email address to contact for further information:
      Adam Li adamli@hyervision.com
      IETF Audio/Video Transport Working Group

   Intended usage: COMMON

   Author:
      Adam Li adamli@hyervision.com

   Change controller:
      IETF Audio/Video Transport Working Group delegated from the
      IESG.

13.4. Registration of application/ulpfec

   MIME media type name: application

   MIME subtype name: ulpfec

   Required parameters:

      Rate: The RTP timestamp rate which is used to mark the time of
      transmission of the FEC packet in separate stream. In cases it
      is sent as redundant data to another stream the rate SHALL be
      the same as the primary encoding it is used to protect. When
      used in a separate stream the rate SHALL be larger than 1000 Hz
      to provide sufficient resolution to RTCP operations. The
      selected rate MAY be any value above 1000 Hz but is RECOMMENDED
      to match the rate of the media this stream protects.

   Optional parameters: none

   Encoding considerations: This format is framed (see Section 4.8 in
   the template document [3]) and contains binary data.

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [1]. Transport within
   other framing protocols SHALL NOT be defined as this is a robustness
   mechanism for RTP.

   Security considerations: the same security considerations apply to
   these MIME registrations as to the payloads for them, as detailed in
   RFC xxxx.

   Interoperability considerations: none


Adam H. Li                                                    [Page 35]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Published specification: RFC xxxx.

   Applications which use this media type: Audio and video streaming
   tools which seek to improve resiliency to loss by sending additional
   data with the media stream.

   Additional information: none

   Person & email address to contact for further information:
      Adam Li adamli@hyervision.com
      IETF Audio/Video Transport Working Group

   Intended usage: COMMON

   Author:
      Adam Li adamli@hyervision.com

   Change controller:
      IETF Audio/Video Transport Working Group delegated from the
      IESG.


14. Multiplexing of FEC

   The FEC packets can be sent to the receiver along with the protected
   payload primarily in one of the two ways: as a separate stream, or
   in the same stream as redundant encoding.

14.1. FEC as a Separate Stream

   When the FEC packets are sent in a separate stream, several pieces
   of information must be conveyed:

   o The address and port where the FEC is being sent to

   o The payload type number for the FEC

   o Which media stream the FEC is protecting

   There is no static payload type assignment for FEC, so dynamic
   payload type numbers MUST be used. The SSRC of the FEC stream MUST
   be set to that of the protected payload stream. The association of
   the FEC stream with its corresponding stream is done by line
   grouping in SDP [5] with the FEC semantics [6] or other external
   means.

   Following the principles as discussed in Section 5.2 of RFC 3550
   [1], multiplexing of the FEC stream and its associated payload
   stream is usually provided by the destination transport address
   (network address and port number) which is different for each RTP
   session. Sending FEC together with the payload in one single RTP
   session and multiplex only by SSRC or payload type precludes: (1)

Adam H. Li                                                    [Page 36]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   the use of different network paths or network resource allocations
   for the payload and the FEC protection data; (2) reception of a
   subset of the media if desired, particularly for the hosts which do
   not understand FEC; and (3) receiver implementations that use
   separate processes for the different media. In additional,
   multiplexing FEC with payload data streams will affect the timing
   and sequence number space of the original payload stream, which is
   usually undesirable. So the FEC stream and the payload stream SHOULD
   be sent through two separate RTP session, and multiplexing them by
   payload type into one single RTP session SHOULD be avoided. In
   additional, the FEC and the payload MUST NOT be multiplexed by SSRC
   into one single RTP session since they always have the same SSRC.

14.2. FEC as Redundant Encoding

   When the FEC stream is being sent as a secondary codec in the
   redundant encoding format, this must be signaled through SDP. To do
   this, the procedures defined in RFC 2198 [7] are used to signal the
   use of redundant encoding. The FEC payload type is indicated in the
   same fashion as any other secondary codec. The FEC MUST protect only
   the main codec, with the payload of FEC engine coming from virtual
   RTP packets created from the main codec data. The virtual RTP
   packets can be very easily converted from the RFC 2198 packets by
   simply (1) removing all the additional headers and the redundant
   coding data, and (2) replacing the payload type in the RTP header
   with that of the primary codec. Note: In the payload format for
   redundant coding as specified by RFC 2198 the marker bit is lost as
   soon as the primary coding is carried in the RED packets. So the
   marker bit can not be recovered regardless the FEC is used or not.

   Because the FEC data (including the ULP header) is sent in the same
   packets as the protected payload. The FEC data is associated with
   the protected payload by being bundled in the same stream.


15. Indicating FEC Usage in SDP

   FEC packets contain RTP packets with dynamic payload type values. In
   addition, the FEC packets can be sent on separate multicast groups
   or separate ports from the media. The FEC can even be carried in
   packets containing media using the redundant encoding payload format
   [7]. These configuration options MUST be indicated out of band. This
   section describes how this can be accomplished using the Session
   Description Protocol (SDP), specified in RFC 2327 [8].

15.1. FEC as a Separate Stream

   In the case discussed in this subsection, the FEC packets are sent
   as a separate stream. This means that they can be sent on a
   different port and/or multicast group from the media.



Adam H. Li                                                    [Page 37]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Just like any media stream, the port number and the payload type
   number for the FEC stream is conveyed in its m line in the SDP.
   There is no static payload type assignment for FEC, so dynamic
   payload type numbers MUST be used. The binding to the number is
   indicated by an rtpmap attribute. The name used in this binding is
   "ulpfec". The address that the FEC stream is on is conveyed in its
   corresponding c line.

   The association relationship between the FEC stream and the payload
   stream it protects is conveyed through media line grouping in SDP
   (RFC 3388) [5] using FEC semantics (RFC yyyy) [6]. The FEC stream
   and the protected payload stream forms an FEC group.

   The following is an example SDP for FEC application in a multicast
   session:

      v=0
      o=adam 289083124 289083124 IN IP4 host.example.com
      s=ULP FEC Seminar
      t=0 0
      c=IN IP4 224.2.17.12/127
      a=group:FEC 1 2
      a=group:FEC 3 4
      m=audio 30000 RTP/AVP 0
      a=mid:1
      m=application 30002 RTP/AVP 100
      a=rtpmap:100 ulpfec/8000
      a=mid:2
      m=video 30004 RTP/AVP 31
      a=mid:3
      m=application 30004 RTP/AVP 101
      c=IN IP4 224.2.17.13/127
      a=rtpmap:101 ulpfec/8000
      a=mid:4

   The presence of two a=group lines in this SDP indicates that there
   are two FEC groups. The first FEC group, as indicated by the
   "a=group:FEC 1 2" line, consists of stream 1 (an audio stream using
   PCM) and stream 2 (the protecting FEC stream). The FEC stream is
   sent to the same multicast group and has the same TTL as the audio,
   but on a port number two higher. The second FEC group, as indicated
   by the "a=group:FEC 3 4" line, consists of stream 3 (an video
   stream) and stream 4 (the protecting FEC stream). The FEC stream is
   sent to a different multicast address, but has the same port number
   (30004) as the payload video stream.

15.2. FEC as Redundant Encoding

   When the FEC stream is sent as a secondary codec in the redundant
   encoding format, this can signaled through SDP. To do this, the
   procedures defined in RFC 2198 [7] are used to signal the use of
   redundant encoding. The FEC payload type is indicated in the same

Adam H. Li                                                    [Page 38]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   fashion as any other secondary codec. An rtpmap attribute MUST be
   used to indicate a dynamic payload type number for the FEC packets.
   The FEC MUST protect only the main codec.

   For example:

      m=audio 12345 RTP/AVP 121 0 5 100
      a=rtpmap:121 red/8000/1
      a=rtpmap:100 ulpfec/8000
      a=fmtp:121 0/5/100

   This SDP indicates that there is a single audio stream, which can
   consist of PCM (media format 0) , DVI (media format 5), the
   redundant encodings (indicated by media format 121, which is bound
   to red through the rtpmap attribute), or FEC (media format 100,
   which is bound to ulpfec through the rtpmap attribute). Although the
   FEC format is specified as a possible coding for this stream, the
   FEC MUST NOT be sent by itself for this stream. Its presence in the
   m line is required only because non-primary codecs must be listed
   here according to RFC 2198. The fmtp attribute indicates that the
   redundant encodings format can be used, with DVI as a secondary
   coding and FEC as a tertiary encoding.

15.3. Offer / Answer Consideration

   Some considerations are needed when SDP is used for offer / answer
   [RFC 3264] exchange.

   When the FEC is sent as a separate stream and signaled through media
   line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC yyyy)
   [6], the offering side MUST implement both RFC 3388 and RFC yyyy.
   The rules for offer / answer in RFC 3388 and RFC YYYY SHALL be
   followed with the below additional consideration. For all offers
   with FEC, the answerer MAY refuse the separate FEC session by
   setting the port to 0, and remove the "a=group" attribute that
   groups that FEC session with the RTP session being protected. If the
   answerer accepts the usage of FEC, the answer simply accepts the FEC
   RTP session and the grouping in the offer by including them in the
   answer. Note that the rejection of FEC RTP session does not prevent
   the media sessions from being accepted and used without FEC.

   When the FEC stream is sent as a secondary codec in the redundant
   encoding format (RFC 2198) [7], the offering side can indicate the
   FEC stream as specified in Section 14.2. The answer MAY reject the
   FEC stream by removing the payload type for the FEC stream. To
   accept the usage of FEC, the answerer must in the answer include the
   FEC payload type. Note that in cases the redundancy payload format
   [7] is used with FEC as the only secondary codec, when the FEC
   stream is rejected the redundant encoding payload type SHOULD also
   be removed.



Adam H. Li                                                    [Page 39]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


16. Application Statement

   This document describes a generic protocol for Forward Error
   Correction supporting a wide range of short block parity FEC
   algorithms, including for example simple and interleaved parity
   codes and Hamming Codes. The scheme is limited to interleaving
   parity codes over a distance of 48 packets. This FEC algorithm is
   fully backward compatible the hosts that are not FEC-capable. Since
   the media payload is not altered and the protection is sent as
   additional information, the receivers that are unaware of the
   generic FEC as specified in this document can simply ignore the
   additional FEC information and process the main media payload. This
   interoperability is particularly important for backward
   compatibility with existing hosts, and also in the scenario where
   many different hosts need to communicate with each other at the same
   time, such as during multicast.

   The generic FEC algorithm specified in this document is also a
   generic protection algorithm with the following features: (1) it is
   independent of the nature of the media being protected, whether that
   media is audio, video, or otherwise, (2) it is flexible enough to
   support a wide variety of FEC mechanisms and settings, (3) it is
   designed for adaptivity, so that the FEC parameters can be modified
   easily without resorting to out of band signaling, and (4) it
   supports a number of different mechanisms for transporting the FEC
   packets.

   The extended mode of FEC (also called ULP) further generalizes and
   extends the generic FEC algorithm here, and provides user with
   Unequal Error Protection capabilities. Some other algorithms may
   also provide the Unequal Error Protection capabilities thought other
   means. For example, an Unequal Erasure Protection (UXP) scheme has
   been proposed in the AVT Working Group in "An RTP Payload Format for
   Erasure-Resilient Transmission of Progressive Multimedia Streams".
   The UXP scheme applies unequal error protection to the media
   payloads by interleaving the payload stream to be protected with the
   additional redundancy information obtained using Reed-Solomon
   operations.

   By altering the structure of the protected media payload, the UXP
   scheme sacrifices the backward compatibility with terminals that do
   not support UXP. This makes it more difficult to apply UXP when
   backward compatibility is desired. In the case of ULP, however, the
   media payload remains un-altered and can always be used by the
   terminals. The extra protection can simply be ignored if the
   receiving terminals do not support ULP.

   At the same time, also because the structure of the media payload is
   altered in UXP, UXP offers the unique ability to change packet size
   independent of the original media payload structure and protection
   applied, and is only subject to the protocol overhead constraint.


Adam H. Li                                                    [Page 40]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   This property is useful in scenarios when altering the packet size
   of the media at transport level is desired.

   Because of the interleaving used in UXP, delays will be introduced
   at both the encoding and decoding sides. For UXP, all data within a
   transmission block need to arrive before encoding can begin, and a
   reasonable number of packets must be received before a transmission
   block can be decoded. The ULP scheme introduces little delay at the
   encoding side. On the decoding side, correctly received packets can
   be delivered immediately. Delay is only introduced in ULP when
   packet losses occur.

   Because UXP is an interleaved scheme, the un-recoverable errors
   occurring in data protected by UXP usually result in a number of
   corrupted holes in the payload stream. In ULP, on the other hand,
   the unrecoverable errors due to packet loss in the bitstream usually
   appear as contiguous missing pieces at the end of the packets.
   Depending on the encoding of the media payload stream, many
   applications may find it easier to parse and extract data from a
   packet with only a contiguous piece missing at the end than a packet
   with multiple corrupted holes, especially when the holes are not
   coincident with the independently decodable fragment boundaries.

   The exclusive-or (XOR) parity check operation used by ULP is simpler
   and faster than the more complex operations required by Reed-Solomon
   codes. This makes ULP more suitable for applications where
   computational cost is a constraint.

   As discussed above, both the ULP and the UXP schemes apply unequal
   error protection to the RTP media stream, but each uses a different
   technique. Both schemes have their own unique characteristics, and
   each can be applied to scenarios with different requirements.


17. Acknowledgments

   The following authors have made significant contributions to this
   document: Adam H. Li, Fang Liu, John D. Villasenor, Dong-Seek Park,
   Jeong-Hoon, Yung-Lyul Lee, Jonathan D. Rosenberg, and Henning
   Schulzrinne. The authors would also like to acknowledge the
   suggestions from many people, particularly Magnus Westerlund,
   Stephen Casner, Colin Perkins, Tao Tian, Matthieu Tisserand, Stephen
   Wenger, Jay Fahlen, and Jeffery Tseng.


18. Bibliography

18.1. Normative References

   [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
   a transport protocol for real-time applications," Request for


Adam H. Li                                                    [Page 41]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


   Comments (Proposed Standard) 3550, Internet Engineering Task Force,
   July 2003.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments (Best Current Practice) 2119, Internet
   Engineering Task Force, March 1997.

   [3] N. Freed and J. Klensin, "Media Type Specifications and
   Registration Procedures", IETF work in progress.

   [4] S. Casner, and P. Hoschka, "MIME type registration of RTP
   payload formats", Request for Comments (Proposed Standard) 3555,
   Internet Engineering Task Force, July 2003.

   [5] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media
   Lines in the Session Description Protocol (SDP)", RFC 3388, December
   2002.

   [6] A. Li, "FEC Grouping Semantics in SDP", IETF work in progress.

   [7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C.
   Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for
   Redundant Audio Data", Request for Comments (Proposed Standard)
   2198, Internet Engineering Task Force, September 1997.

   [8] M. Handley, and V. Jacobson, "SDP: Session Description
   Protocol", Request for Comments (Proposed Standard) 2327, Internet
   Engineering Task Force, April 1998.

18.2. Informative References

   [9] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for
   Generic Forward Error Correction," Request for Comments (Proposed
   Standard) 2733, Internet Engineering Task Force, December 1999.

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

   [11] J. Rosenberg and H. Schulzrine, "Registration of parityfec MIME
   types", Request for Comments (Proposed Standard) 3009, Internet
   Engineering Task Force, November 2000.

   [12] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, "The
   Secure Real-time Transport Protocol (SRTP)", Request for Comments
   (Proposed Standard) 3711, Internet Engineering Task Force, March
   2004.

   [13] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
   Conferences with Minimal Control", Request for Comments (Proposed
   Standard) 3551, Internet Engineering Task Force, July 2003.


Adam H. Li                                                    [Page 42]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006



19. Author's Addresses

   Adam H. Li
   10194 Wateridge Circle #152
   San Diego, CA 92121
   USA
   Phone: +1 858 622 9038
   Email: adamli@hyervision.com












































Adam H. Li                                                    [Page 43]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and
   restrictions contained in BCP 78, and except as set forth
   therein, the authors retain all their rights.


Disclaimer of Validity

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

   The IETF takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the
   technology described in this document or the extent to which any
   license under such rights might or might not be available; nor
   does it represent that it has made any independent effort to
   identify any such rights. Information on the procedures with
   respect to rights in RFC documents can be found in BCP 78 and
   BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the
   use of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be
   required to implement this standard.  Please address the
   information to the IETF at ietf-ipr@ietf.org.











Adam H. Li                                                    [Page 44]

I-Draft            RTP Payload Format for Generic FEC      Feb. 28, 2006


RFC Editor Considerations

   The RFC editor is kindly requested to perform the following
   editing to this draft:

   - Replace all occurrences of xxxx with the RFC number this
   document receives.

   - Replace reference [6] and all occurrences of RFC yyyy with the
   corresponding title and RFC number of that ID when it is
   published.

   - Remove this and the next section "Changes".

Changes

   Compared to the previous version of this document, draft-ietf-avt-
   ulp-15.txt, the following changes have been made:

   (1)  Minor editorial changes.

This Internet-Draft expires August 28, 2006.































Adam H. Li                                                    [Page 45]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/