[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                                                     A. Li
               draft-ietf-avt-ulp-05.txt                                         F. Liu
               April 28, 2002                                             J. Villasenor
               Expires: October 28, 2002                            Univ. of Calif., LA
                                                                              J.H. Park
                                                                              D.S. Park
                                                                               Y.L. Lee
                                                                    Samsung Electronics
               
                   An RTP Payload Format for Generic FEC with Uneven Level Protection
               
               
               STATUS OF THIS MEMO
               
                   This document is an Internet-Draft and is in full conformance with
                   all provisions of Section 10 of RFC 2026.
               
                   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
                   anytime. 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.
               
               
               ABSTRACT
               
                   This document specifies a payload format for generic forward error
                   correction to achieve uneven level protection (ULP) for media data
                   encapsulated in RTP. It is an extension of the forward error
                   correction scheme specified in RFC 2733 [1], and it is based on the
                   same exclusive-or (parity) operation. This payload format allows end
                   systems to apply protection using arbitrary protection lengths and
                   levels, in addition to using arbitrary protection group sizes. It
                   also enables both complete recovery or partial recovery of the
                   critical payload and RTP header fields depending on the packet loss
                   situation. This scheme is completely backward compatible with non-FEC
                   capable hosts and with hosts that are only capable of handling the
                   FEC schemes specified in RFC 2733 [1]. Those receivers that do not
                   know about ULP forward error correction can simply ignore the
                   extensions.
               
               
               
               
               Adam H. Li, et al.                                              [Page 1]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
               Table of Contents
               
                   1. Introduction ................................................... 3
                   1.1. General Overview ............................................. 3
                   1.2. Application Statement ........................................ 4
                   2. Terminology .................................................... 6
                   3. Basic Operation ................................................ 6
                   4. RTP Media Packet Structure ..................................... 7
                   5. ULP FEC Packet Structure ....................................... 8
                   5.1. RTP Header of ULP FEC Packets ................................ 8
                   5.2. FEC Header ................................................... 9
                   5.3. ULP Level Header ............................................. 9
                   6. Protection Operation .......................................... 10
                   6.1. Protection Level 0 .......................................... 10
                   6.2. Protection Level 1 and Higher ............................... 12
                   7. Recovery Procedure ............................................ 12
                   7.1. Reconstruction of Level 0 ................................... 12
                   7.2. Reconstruction of Level 1 and Higher ........................ 13
                   8. Examples ...................................................... 14
                   8.1. An Example With Only Protection Level 0 ..................... 14
                   8.2. An Example That Has Identical Protection as in RFC 2733 ..... 16
                   8.3. An Example With Two Protection Levels (0 and 1) ............. 17
                   9. Security and Congestion Considerations ........................ 20
                   10. Indication ULP FEC Usage in SDP .............................. 21
                   10.1. ULP FEC as a Separate Stream ............................... 21
                   10.2. Use with Redundant Encoding ................................ 22
                   10.3. Usage with RTSP ............................................ 23
                   11. MIME Registrations ........................................... 24
                   11.1. Registration of audio/ulpfec ............................... 24
                   11.2. Registration of video/ulpfec ............................... 25
                   11.3. Registration of text/ulpfec ................................ 26
                   11.4. Registration of application/ulpfec ......................... 27
                   12. Acknowledgements ............................................. 28
                   13. Bibliography ................................................. 28
                   14. Authors' Address ............................................. 29
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               Adam H. Li, et al.                                              [Page 2]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               1. Introduction
               
               1.1. General Overview
               
                   Because of the real-time nature of many applications, they 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 has been one of the main methods used to
                   protect against packet loss over packet switched networks [2].
               
                   In many cases, the bandwidth of the network connections is a very
                   limited resource. However, most of traditional FEC schemes are not
                   designed for optimal utilization of the limited bandwidth resource. A
                   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.
                   These unequal error protection schemes can 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. However, the application
                   of most of the unequal error protection schemes requires the
                   knowledge of the importance for different parts of the data stream.
                   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.
               
                   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. Also, 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.
               
               
               
               Adam H. Li, et al.                                              [Page 3]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   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. Thus, 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.
               
                   It is clear that audio/video applications would generally benefit
                   from an unequal error protection scheme that gives more protection to
                   the beginning part of each packet. This document defines a payload
                   format for RTP [3] that allows for generic forward error correction
                   with unequal error protection for real-time media. 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.
                   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.
               
                   This document specifies an RTP payload format that extends the
                   generic forward error correction schemes as specified in RFC 2733
                   [1]. This extension enables different levels of protection to be
                   applied to different parts of the packet. While the whole packet can
                   always be treated as a single level (same as in RFC 2733), this
                   multiple Uneven Level Protection (ULP) can potentially achieve more
                   efficient protection of the media payload.
               
               1.2. Application Statement
               
                   The ULP algorithm specified in this document is designed to deal with
                   any type of packet loss occurring in transmission, just as does RFC
                   2733, which it extends. The ULP algorithm is designed to be fully
                   interoperable between the hosts that are ULP-capable and those that
                   are not. Since the media payload is not altered and the protection is
                   sent as additional information, the receivers that are unaware of ULP
                   can simply ignore the additional ULP 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 ULP algorithm 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
               
               Adam H. Li, et al.                                              [Page 4]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   signaling, and (4) it supports a number of different mechanisms for
                   transporting the FEC packets.
               
                   An Unequal Erasure Protection (UXP) scheme has also 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.
                   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
               
               
               Adam H. Li, et al.                                              [Page 5]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   technique. Both schemes have their own unique characteristics, and
                   each can be applied to scenarios with different requirements.
               
               
               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.
               
                   ULP FEC Packet: The uneven level protection 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 ULP FEC packets, which contain redundant media data used for
                   error correction. The ULP 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 ULP FEC packet is said to be "associated" with one or
                   more media packets when those media packets are used to generate the
                   ULP FEC packet (by use of the exclusive-or operation).
               
                   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                   document are to be interpreted as described in RFC 2119 [4].
               
               
               3. Basic Operation
               
                   The payload format described here is used whenever  the sender in an
                   RTP session would like to protect the media stream it is sending with
                   uneven level protection (ULP) FEC. The ULP FEC supported by the
                   format is based on the same simple exclusive-or (XOR) parities used
                   in RFC 2733 [1]. The sender takes the packets from the media stream
                   requiring protection and determines the protection levels for these
                   packets and the protection length for each level. The data of each
                   level are grouped as described below in Section 6 to provide each
                   level with a different degree of error resilience. An XOR operation
                   is applied across the payload to generate the ULP FEC information for
                   each level. The lower protection levels (which provide higher
                   protection, or greater error resilience) are applied to the data that
                   are closer to the beginning of the packet to ensure more protection.
                   The result based on the procedures defined here is an RTP packet
               
               Adam H. Li, et al.                                              [Page 6]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   containing ULP FEC information. This packet can be used at the
                   receiver to recover the packets or parts of the packets used to
                   generate the ULP FEC packet. By using uneven error protection, this
                   scheme can make more efficient use of the channel bandwidth, and
                   provide more efficient error resilience for transmission over error
                   prone channels.
               
                   The payload format contains information that allows the sender to
                   tell the receiver exactly which media packets are protected by the
                   ULP FEC packet, and the protection levels and lengths for each of the
                   levels. Specifically, each ULP FEC packet contains a protection
                   length L(k) and 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 ULP FEC packet at level k. N is called the
                   sequence number base, and is sent in the ULP FEC packet as well. The
                   amount of data that are protected at level k is indicated by L(k).
                   The protection length, offset mask and payload type are sufficient to
                   signal ULP forward error correction schemes based on arbitrarily
                   defined parity protection with little overhead. A set of rules is
                   described in Section 5.3 that defines how the mask should be set for
                   different protection levels, with examples in Section 8.
               
                   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 code to current network
                   conditions and be certain the receivers can still make use of the ULP
                   FEC for recovery.
               
                   At the receiver, the ULP FEC and original media are received. If no
                   media packets are lost, the ULP FEC can be ignored. In the event of a
                   loss, the ULP FEC packets can be combined with other received media
                   and ULP FEC packets to recover all or part of the missing media
                   packets. When ULP is used, the decoder is expected to receive and
                   handle partially recovered packets with contiguous pieces missing at
                   the end of the packets.
               
                   RTP packets that contain data formatted according to this
                   specification (i.e., ULP FEC packets) use dynamic RTP payload types.
               
               
               4. RTP Media Packet Structure
               
                   The formatting of the media packets is unaffected by ULP FEC. If the
                   ULP FEC is sent as a separate stream, the media packets are sent as
                   if there was no FEC.
               
                   This scheme leads to a very efficient encoding. When little or no ULP
                   FEC is used, the transmitted stream contains mostly media packets.
                   The overhead for using the ULP FEC scheme is only present in ULP FEC
                   packets, and can be easily monitored and adjusted by tracking the
                   amount of FEC in use.
               
               
               
               Adam H. Li, et al.                                              [Page 7]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
               5. ULP FEC Packet Structure
               
                   A ULP FEC packet is constructed by placing an FEC header and the ULP
                   FEC payload into the RTP payload, as shown in Figure 1:
               
               
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                         RTP Header                            |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                    FEC Header (12 octets)                     |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                 ULP Level 0 Header (2 octets)                 |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                     ULP Level 0 Payload                       |
                   |                                                               |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                 ULP Level 1 Header (5 octets)                 |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                     ULP Level 1 Payload                       |
                   |                                                               |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                            Cont.                              |
                   |                                                               |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                   Figure 1: ULP FEC Packet Structure
               
               
               5.1. RTP Header of ULP FEC Packets
               
                   The version field is set to 2. The padding bit is computed via the
                   protection operation, defined below. The extension bit is also
                   computed via the protection operation. The SSRC value will generally
                   be the same as the SSRC value of the media stream it protects, though
                   it MAY be different if the FEC stream is being demultiplexed via the
                   SSRC value. The CC value is computed from the protection operation.
                   The CSRC list is never present, independent of the value of the CC
                   field. The extension is never present, independent of the value of
                   the X bit. The marker bit is computed via the protection operation.
               
                   The sequence number has the standard definition: it MUST be one
                   higher than the sequence number in the previously transmitted FEC
                   packet. The timestamp MUST be set to the value of the media RTP clock
                   at the instant the ULP FEC packet is transmitted. Thus, the TS value
                   in FEC packets is always monotonically increasing.
               
                   The payload type for the ULP FEC packet is determined through
                   dynamic, out of band means. According to RFC 1889 [3], RTP
                   participants that cannot recognize a payload type must discard it.
                   This provides backwards compatibility. The ULP FEC mechanisms can
                   then be used in a multicast group with mixed ULP-FEC-capable and ULP-
                   FEC-incapable receivers. In such a case, the ULP stream will have a
               
               Adam H. Li, et al.                                              [Page 8]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   payload type which is not recognized by the ULP-FEC-incapable
                   receivers, and will thus be disregarded.
               
               5.2. FEC Header
               
                   This header is 12 bytes. The format of the header is shown in Figure
                   2 and consists of an SN base field, length recovery field, E field,
                   PT recovery field, mask field and TS recovery 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
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |           SN base             |        length recovery        |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |E| PT recovery |                     mask                      |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                          TS recovery                          |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                   Figure 2: FEC Header Format
               
               
                   This is exactly the same as the FEC header used in RFC 2733 [1]. The
                   usage will also be exactly the same as specified as in RFC 2733,
                   except that the E bit MUST be set to one for this version.
               
               5.3. ULP Level Header
               
                   The ULP Level Header is 2 bytes for ULP level 0, and 5 bytes for ULP
                   level 1 and higher. The formats of the headers are shown in Figure 3
                   and Figure 4, and consist of a Protection Length field and a mask
                   field (for level 1 and higher headers).
               
               
                    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)
               
               
                    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.) |
                   +-+-+-+-+-+-+-+-+
               
                   Figure 4: ULP Level Header Format (Level 1 and higher)
               
               Adam H. Li, et al.                                              [Page 9]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
               
                   The Protection Length field is 16 bits. It indicates the protection
                   length provided by the ULP FEC for the current protection level
                   (i.e., the payload length for the current protection level after the
                   header).
               
                   The mask field is 24 bits. If bit i in the mask is set to 1, then the
                   media packet with sequence number N + i is associated with this ULP
                   FEC packet of current protection level, where N is the SN Base field
                   in the ULP FEC packet header. The least significant bit corresponds
                   to i=0, and the most significant to i=23.
               
                   The SN base field in the FEC header MUST be set to the minimum
                   sequence number of those media packets protected by ULP FEC. This
                   allows for the ULP FEC operation to extend over any string of at most
                   24 packets.
               
                   The setting of mask field shall follow the following rules:
               
                      a. A media packet can only be protected at each protection level
                         once.
               
                      b. For a media packet to be protected at level p, it must also be
                         protect at level p-1.
               
                      c. If an ULP FEC packet contains protection at level p, it must
                         also contain protection at level p-1.
               
                   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. Details are described in the next section on
                   the protection operation.
               
               
               6. Protection Operation
               
                   The protection operation involves copying the payload, padding it
                   with zeroes, and computing the parity (XOR) across the resulting bit
                   strings. In addition, for protection of level 0, it also involves
                   concatenating specific fields from the RTP header of the media packet
                   before the payload data. 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.
               
               6.1. Protection Level 0
               
                   For each media packet to be protected, a bit string is generated by
                   concatenating the following fields together in the order specifed:
               
               Adam H. Li, et al.                                             [Page 10]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
                      o Padding Bit (1 bit)
               
                      o Extension Bit (1 bit)
               
                      o CC bits (4 bits)
               
                      o Marker bit (1 bit)
               
                      o Payload Type (7 bits)
               
                      o Timestamp (32 bits)
               
                      o Unsigned network-ordered 16 bit representation of the sum of the
                        lengths of the CSRC List, length of the padding, length of the
                        extension, and length of the media packet (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 Padding, if present (variable length)
               
                   Note that the Padding Bit (first entry above) forms the most
                   significant bit of the bit string.
               
                   If the lengths of the bit strings are not equal, each bit string that
                   is shorter than the Protection Length 0 plus 96 bits, MUST be padded
                   to that length. Any value may be used for padding. The pad MUST be
                   added at the end of the bit string.
               
                   The parity operation is then applied across the bit strings. The
                   result is the bit string used to build the ULP FEC packet. We will
                   call this the ULP FEC bit string (level 0).
               
                   The first (most significant) bit in the ULP FEC bit string is written
                   into the Padding Bit of the ULP FEC packet. The second bit in the ULP
                   FEC bit string is written into the Extension bit of the ULP FEC
                   packet. The next four bits of the ULP FEC bit string are written into
                   the CC field of the ULP FEC packet. The next bit of the ULP FEC bit
                   string is written into the marker bit of the ULP FEC packet. The next
                   7 bits of the ULP FEC bit string are written into the PT recovery
                   field in the ULP FEC packet header. The next 32 bits of the ULP FEC
                   bit string are written into the TS recovery field in the packet
                   header. The next 16 bits are written into the length recovery field
                   in the ULP FEC packet header. This is exactly the same as in RFC 2733
                   [1].
               
                   The remaining bits (of length Protection Length 0) are set to be the
                   payload of the ULP FEC packet.
               
               
               Adam H. Li, et al.                                             [Page 11]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               6.2. Protection Level 1 and Higher
               
                   The protected data of the corresponding packets are copied into the
                   bit strings. If the packet ends before the Protection Length of the
                   current level is reached, the string is padded to that length. Any
                   value may be used for the padding. The padding MUST be added at the
                   end of the bit string.
               
                   The parity operation is applied across the protected data of the
                   corresponding packets. The generated ULP FEC bit of that level is
                   then appended to the payload of the ULP FEC packet.
               
               
               7. Recovery Procedures
               
                   The ULP 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
                   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.
               
               7.1. Reconstruction of Level 0
               
                   Let T be the list of packets (ULP 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 bit string as
                         described in the protection operation of the previous section.
               
                      2.  For the ULP FEC packet in T, compute the bit string in the
                         same fashion, except always set the CSRC list, extension, and
                         padding to null. Read the Protection Length 0. Read string of
                         that length from that ULP FEC packet.
               
                      3.  If any of the bit strings generated from the media packets are
                         shorter than the bit string generated from the ULP FEC packet,
                         pad them to be the same length as the bit string generated
                         from the ULP FEC. The padding MUST be added at the end of the
                         bit string, and MAY be of any value.
               
                      4.  Perform the exclusive-or (parity) operation across the bit
                         strings, resulting in a recovery bit string.
               
               
               
               Adam H. Li, et al.                                             [Page 12]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                      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.
               
                      7.  Set the Padding bit in the new packet to the first bit in the
                         recovery bit string.
               
                      8.  Set the Extension bit in the new packet to the second bit in
                         the recovery bit string.
               
                      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.
               
                      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 padding.
               
                      15. Set the SSRC of the new packet to the SSRC of the media stream
                         it's protecting.
               
                   This procedure will recover both the header and payload of an RTP
                   packet up to the Protection Length of level 0.
               
               7.2. Reconstruction of Level 1 and Higher
               
                   Let T be the list of packets (ULP FEC and media) which can be
                   combined to recover some media packet xi. The procedure is as
                   follows:
               
                      1.  For the media packet in T, get the protection length of that
                         level. Copy the data of the that protection level (data of the
                         length read following the level header) to the bit strings.
               
                      2.  If any of the bit strings generated from the media packets are
                         shorter than the Protection Length of the current level, pad
                         them to that length. The padding MUST be added at the end of
                         the bit string, and MUST be of the same value as used in the
                         process of generating the ULP FEC packets.
               
               
               Adam H. Li, et al.                                             [Page 13]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                      3.  Perform the exclusive-or (parity) operation across the bit
                         strings, resulting in a recovery bit string.
               
                   The data protected at lower protection level is almost always
                   recoverable 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.
               
               
               8. Examples
               
                   Consider 4 media packets 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 is
                   has 200 bytes of payload, packet B 140, packet C 100 and packet D
                   340. Packet A and C have their marker bit set.
               
               8.1. An Example With Only Protection Level 0
               
                   Suppose we want to protect the data of length L0 = 70 bytes of them
                   at the beginning of these packets, as illustrated in Figure 5 below.
               
               
                              +------:------------+
                   Packet A   |      :            |
                              +------:------+-----+
                   Packet B   |      :      |
                              +------:--+---+
                   Packet C   |      :  |
                              +------:--+-----------------------+
                   Packet D   |      :                          |
                              +------:--------------------------+
                                     :
                              +------+
                   Packet FEC |      |
                              +------+
                              :      :
                              :<-L0->:
               
                   Figure 5 ULP FEC scheme with only protection level 0
               
               
                   An ULP 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 6.
               
                   The FEC header in the ULP FEC packet is shown in Figure 7.
               
                   The ULP header for level 0 in the ULP FEC packet is shown in Figure
                   8.
               
               
               Adam H. Li, et al.                                             [Page 14]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
                    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
                      PT:        127
                      SN:        1
                      TS:        9
                      SSRC:      2
               
                   Figure 6: RTP Header of ULP FEC for Packets A, B, C and D (one level)
               
               
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |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|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 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|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                      SN base:   8    [min(8,9,10,11)]
                      len. rec.: 372  [200 XOR 140 XOR 100 XOR 340]
                      E:         1    [ULP FEC]
                      PT rec.:   0    [11 XOR 18 XOR 11 XOR 18]
                      mask:      15   [with Packet 8, 9, 10, and 11 marked]
                      TS rec.:   8    [3 XOR 5 XOR 7 XOR 9]
               
                   Figure 7: FEC Header of ULP Packet (one level)
               
               
                    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 8: ULP Level Header (Level 0)
               
               
               Adam H. Li, et al.                                             [Page 15]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
               8.2. An Example That Has Identical Protection as in RFC 2733
               
                   We can choose to extend the level 0 protection to cover the whole
                   length of the packets (as shown in Figure 9). This gives almost
                   identical protection as provided in RFC 2733. Please note that when
                   using ULP this way, each ULP FEC packet will use two more bytes (for
                   the level 0 payload length field) than that of RFC 2733 - a small
                   price to pay for the added flexbility.
               
               
                              +-------------------+             :
                   Packet A   |                   |             :
                              +-------------+-----+             :
                   Packet B   |             |                   :
                              +---------+---+                   :
                   Packet C   |         |                       :
                              +---------+-----------------------+
                   Packet D   |                                 |
                              +---------------------------------+
                                                                :
                              +---------------------------------+
                   Packet FEC |                                 |
                              +---------------------------------+
                              :                                 :
                              :<------------- L0 -------------->:
               
                   Figure 9 ULP FEC scheme with only protection level 0
               
               
                   The resulting ULP FEC packet will have the RTP header same as shown
                   in Figure 6 and FEC header same as shown in Figure 7. The ULP level
                   header is shown in Figure 10.
               
               
                    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 1 0 1 0 1 0 1 0 0|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                      L0:        340  [max(200,140,100,340)]
               
                      The payload length for level 0 is 340 bytes.
               
                   Figure 10: ULP Level Header (Level 0)
               
               
               
               
               
               
               
               
               Adam H. Li, et al.                                             [Page 16]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
               8.3. An Example With Two Protection Levels (0 and 1)
               
                   A more complete example is to use ULP at two levels. The level 0 ULP
                   will provide greater protection to the beginning part of the payload
                   packets. The level 1 ULP will apply additional protection to the rest
                   of the packets. This is illustrated in Figure 11. In this example, we
                   take L0 = 70 and L1 = 90.
               
               
                              +------:--------:---+
                   Packet A   |      :        :   |
                              +------:------+-:---+
                   Packet B   |      :      | :
                              +------:--+---+ :
                                     :        :
                              +------+        :
                   ULP #1     |      |        :
                              +------+        :
                                     :        :
                              +------:--+     :
                   Packet C   |      :  |     :
                              +------:--+-----:-----------------+
                   Packet D   |      :        :                 |
                              +------:--------:-----------------+
                                     :        :
                              +------:--------+
                   ULP #2     |      :        |
                              +------:--------+
                              :      :        :
                              :<-L0->:<--L1-->:
               
                   Figure 11 ULP FEC scheme with protection level 0 and level 1
               
               
                   This will result in two ULP FEC packets - #1 and #2.
               
                   The resulting ULP FEC packet #1 will have the RTP header as shown in
                   Figure 12. The FEC header for ULP FEC packet #1 will be as shown in
                   Figure 13. The level 0 ULP header for #1 will be shown in Figure 14.
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               Adam H. Li, et al.                                             [Page 17]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                    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 12: RTP Header of ULP FEC #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 1 0 0 0 1 0 0|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1|0 0 1 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 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 0 0 1 1 0|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                      SN base:   8    [min(8,9)]
                      len. rec.: 68   [200 XOR 140]
                      E:         1    [ULP FEC]
                      PT rec.:   25   [11 XOR 18]
                      mask:      3    [Packet 8 and 9 marked]
                      TS rec.:   6    [3 XOR 5]
               
                   Figure 13: 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 14: ULP Level Header (Level 0) for ULP FEC Packet #1
               
               
               
               Adam H. Li, et al.                                             [Page 18]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   The resulting ULP FEC packet #2 will have the RTP header as shown in
                   Figure 15. The FEC header for ULP FEC packet #2 will be as shown in
                   Figure 16. The level 0 ULP header for #2 will be shown in Figure 17.
                   The level 1 ULP header for #2 will be shown in Figure 18.
               
               
                    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 15: RTP Header of ULP FEC Packet #2
               
               
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |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 0 1 1 0 1 0 0|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1|0 0 1 1 0 0 1|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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                      SN base:   8    [min(8,9,10,11)]
                      len. rec.: 308  [100 XOR 340]
                      E:         1    [ULP FEC]
                      PT rec.:   25   [11 XOR 18]
                      mask:      12   [Packet 10 and 11 marked]
                      TS rec.:   6    [7 XOR 9]
               
                   Figure 16: FEC Header of ULP Packet #2
               
               
               
               
               
               
               
               
               
               
               Adam H. Li, et al.                                             [Page 19]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                    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 17: ULP Level Header (Level 0) for ULP 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|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0 0 0 0 1 1 1 1|
                   +-+-+-+-+-+-+-+-+
               
                      L1:        90
                      mask:      15   [Packet 8, 9, 10, and 11 marked]
               
                      The payload length for level 1 is 90 bytes.
               
                   Figure 18: ULP Level Header (Level 1) for ULP Packet #2
               
               
               9. Security and Congestion Considerations
               
                   The use of ULP FEC has implications on the usage and changing of keys
                   for encryption. As the ULP FEC packets do consist of a separate
                   stream, there are a number of combinations on the usage of
                   encryption. These include:
               
                      o The ULP FEC stream may be encrypted, while the media stream is
                        not.
               
                      o The media stream may be encrypted, while the ULP FEC stream is
                        not.
               
                      o The media stream and ULP FEC stream are both encrypted, but
                        using different keys.
               
                      o The media stream and ULP 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 ULP FEC, and to
                   thus exchange keys and negotiate encryption usage on the media and
                   ULP FEC streams separately. In the final case, no such additional
                   mechanisms are needed. The first two cases present a layering
               
               Adam H. Li, et al.                                             [Page 20]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   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 ULP FEC packet that protects them. The keys used to encrypt
                   a and b are different, so which key should be used to decode the ULP
                   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.
               
                   Another issue with the use of ULP 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 ULP FEC) as network losses increase.
               
               
               10. Indicating ULP 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 ULP FEC can even be carried in
                   packets containing media using the redundant encoding payload format
                   [5]. 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 [6].
               
               10.1. ULP FEC as a Separate Stream
               
                   In the first case, the ULP 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. When this is done, several pieces of
                   information must be conveyed:
               
                   o The address and port where the ULP FEC is being sent to
               
                   o The payload type number for the ULP FEC
               
                   o Which media stream the ULP FEC is protecting
               
                   The payload type number for the ULP FEC is conveyed in the m line of
                   the media it is protecting, listed as if it were another valid
                   encoding for the stream. There is no static payload type assignment
                   for ULP FEC, so dynamic payload type numbers MUST be used. The
               
               
               Adam H. Li, et al.                                             [Page 21]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   binding to the number is indicated by an rtpmap attribute. The name
                   used in this binding is "ulpfec".
               
                   The presence of the payload type number in the m line of the media it
                   is protecting does not mean the ULP FEC is sent to the same address
                   and port as the media. Instead, this information is conveyed through
                   an fmtp attribute line. The presence of the ULP FEC payload type on
                   the m line of the media serves only to indicate which stream the ULP
                   FEC is protecting.
               
                   The format for the fmtp line for ULP FEC is:
               
                      a=fmtp:<number> <port> <network type> <addresss type> <connection
                   address>
               
                   where 'number' is the payload type number present in the m line. Port
                   is the port number where the ULP FEC is sent to. The remaining three
                   items - network type, address type, and connection address - have the
                   same syntax and semantics as the c line from SDP. This allows the
                   fmtp line to be partially parsed by the same parser used on the c
                   lines. Note that since ULP FEC cannot be hierarchically encoded, the
                   <number of addresses> parameter MUST NOT appear in the connection
                   address.
               
                   The following is an example SDP for ULP FEC:
               
                      v=0
                      o=hamming 2890844526 2890842807 IN IP4 128.97.90.168
                      s=ULP FEC Seminar
                      c=IN IP4 224.2.17.12/127
                      t=0 0
                      m=audio 49170 RTP/AVP 0 78
                      a=rtpmap:78 ulpfec/8000
                      a=fmtp:78 49172 IN IP4 224.2.17.12/127
                      m=video 51372 RTP/AVP 31 79
                      a=rtpmap:79 ulpfec/8000
                      a=fmtp:79 51372 IN IP4 224.2.17.13/127
               
                   The presence of two m lines in this SDP indicates that there are two
                   media streams - one audio and one video. The media format of 0
                   indicates that the audio uses PCM, and is protected by ULP FEC with
                   payload type number 78. The ULP FEC is sent to the same multicast
                   group and TTL as the audio, but on a port number two higher (49172).
                   The video is protected by ULP FEC with payload type number 79. The
                   ULP FEC appears on the same port as the video (51372), but on a
                   different multicast address.
               
               10.2. Use with Redundant Encoding
               
                   When the ULP 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 [5] are used to signal the
                   use of redundant encoding. The ULP FEC payload type is indicated in
               
               Adam H. Li, et al.                                             [Page 22]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   the same fashion as any other secondary codec. An rtpmap attribute
                   MUST be used to indicate a dynamic payload type number for the ULP
                   FEC packets. The ULP FEC MUST protect only the main codec. In this
                   case, the fmtp attribute for the ULP FEC MUST NOT be present.
               
                   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 read
                   through the rtpmap attribute), or ULP FEC (media format 100, which is
                   bound to ulpfec through the rtpmap attribute). Although the ULP FEC
                   format is specified as a possible coding for this stream, the ULP 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 ULP FEC as a tertiary encoding.
               
               10.3. Usage with RTSP
               
                   RTSP [7] can be used to request ULP FEC packets to be sent as a
                   separate stream. When SDP is used with RTSP, the Session Description
                   does not include a connection address and port number for each
                   stream. Instead, RTSP uses the concept of a "Control URL". Control
                   URLs are used in SDP in two distinct ways.
               
                   1.   There is a single control URL for all streams. This is referred
                   to as "aggregate control". In this case, the fmtp line for the ULP
                   FEC stream is omitted.
               
                   2.   There is a Control URL assigned to each stream. This is
                   referred to as "non-aggregate control". In this case, the
                   fmtp line specifies the Control URL for the stream of ULP FEC
                   packets. The URL may be used in a SETUP command by an RTSP client.
               
                   The format for the fmtp line for ULP FEC with RTSP and non-aggregate
                   control is:
               
                      a=fmtp:<number> <control URL>
               
                   where 'number' is the payload type number present in the m line.
                   Control URL is the URL used to control the stream of ULP FEC packets.
                   Note that the Control URL does not need to be an absolute URL. The
                   rules for converting a relative Control URL to an absolute URL are
                   given in RFC 2326, Section C.1.1.
               
               
               
               Adam H. Li, et al.                                             [Page 23]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               11. MIME Registrations
               
                   Four new MIME sub-type as described in this section is to be
                   registered.
               
               11.1. Registration of audio/ulpfec
               
                   To: ietf-types@iana.org
               
                   Subject: Registration of MIME media type audio/ulpfec
               
                   MIME media type name: audio
               
                   MIME subtype name: ulpfec
               
                   Required parameters: none
               
                   Note that it is mandated that RTP payload formats without a defined
                   rate must define a rate parameter as part of their MIME registration.
                   The payload format for ULP FEC does not specify a rate parameter.
                   However, the rate for ULP FEC data is equal to the rate of the media
                   data it protects.
               
                   Optional parameters: none
               
                   Typical optional parameters [8], such as the number of channels, and
                   the duration of audio per packet, do not apply to ULP FEC data.  The
                   number of channels is effectively the same as the media data it
                   protects; the same is true for the duration of audio per packet.
               
                   Encoding considerations: This format is only defined for transport
                   within the Real Time Transport protocol (RTP) [3].  Its transport
                   within RTP is fully specified with RFC xxxx.
               
                   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
               
                   Person & email address to contact for further information:
               
                      Adam Li
                      Department of Electrical Engineering
                      University of California
               
               Adam H. Li, et al.                                             [Page 24]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                      Los Angeles, CA 90095
                      adamli@icsl.ucla.edu
               
                   Intended usage: COMMON
               
                   Author/Change controller: This registration is part of the IETF
                   registration tree.
               
                   RTP and SDP Issues: Usage of this format within RTP and the Session
                   Description Protocol (SDP) [6] are fully specified within Section 10
                   of RFC xxxx.
               
               11.2. Registration of video/ulpfec
               
                   To: ietf-types@iana.org
               
                   Subject: Registration of MIME media type video/ulpfec
               
                   MIME media type name: video
               
                   MIME subtype name: ulpfec
               
                   Required parameters: none
               
                   Note that it is mandated that RTP payload formats without a defined
                   rate must define a rate parameter as part of their MIME registration.
                   The payload format for ULP FEC does not specify a rate parameter.
                   However, the rate for ULP FEC data is equal to the rate of the media
                   data it protects.
               
                   Optional parameters: none
               
                   Typical optional parameters [8], such as the number of channels, and
                   the duration of audio per packet, do not apply to ULP FEC data.  The
                   number of channels is effectively the same as the media data it
                   protects; the same is true for the duration of video per packet.
               
                   Encoding considerations: This format is only defined for transport
                   within the Real Time Transport protocol (RTP) [3].  Its transport
                   within RTP is fully specified with RFC xxxx.
               
                   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, et al.                                             [Page 25]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   Additional information: none
               
                   Person & email address to contact for further information:
               
                      Adam Li
                      Department of Electrical Engineering
                      University of California
                      Los Angeles, CA 90095
                      adamli@icsl.ucla.edu
               
                   Intended usage: COMMON
               
                   Author/Change controller: This registration is part of the IETF
                   registration tree.
               
                   RTP and SDP Issues: Usage of this format within RTP and the Session
                   Description Protocol (SDP) [6] are fully specified within Section 10
                   of RFC xxxx.
               
               11.3. Registration of text/ulpfec
               
                   To: ietf-types@iana.org
               
                   Subject: Registration of MIME media type text/ulpfec
               
                   MIME media type name: text
               
                   MIME subtype name: ulpfec
               
                   Required parameters: none
               
                   Note that it is mandated that RTP payload formats without a defined
                   rate must define a rate parameter as part of their MIME registration.
                   The payload format for ULP FEC does not specify a rate parameter.
                   However, the rate for ULP FEC data is equal to the rate of the media
                   data it protects.
               
                   Optional parameters: none
               
                   Typical optional parameters [8], such as the number of channels, and
                   the duration of audio per packet, do not apply to ULP FEC data.  The
                   number of channels is effectively the same as the media data it
                   protects; the same is true for the duration of video per packet.
               
                   Encoding considerations: This format is only defined for transport
                   within the Real Time Transport protocol (RTP) [3].  Its transport
                   within RTP is fully specified with RFC xxxx.
               
                   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, et al.                                             [Page 26]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
               
                   Published specification: RFC xxxx.
               
                   Applications which use this media type: Audio, video and text
                   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
                      Department of Electrical Engineering
                      University of California
                      Los Angeles, CA 90095
                      adamli@icsl.ucla.edu
               
                   Intended usage: COMMON
               
                   Author/Change controller: This registration is part of the IETF
                   registration tree.
               
                   RTP and SDP Issues: Usage of this format within RTP and the Session
                   Description Protocol (SDP) [6] are fully specified within Section 10
                   of RFC xxxx.
               
               11.4. Registration of application/ulpfec
               
                   To: ietf-types@iana.org
               
                   Subject: Registration of MIME media type application/ulpfec
               
                   MIME media type name: application
               
                   MIME subtype name: ulpfec
               
                   Required parameters: none
               
                   Note that it is mandated that RTP payload formats without a defined
                   rate must define a rate parameter as part of their MIME registration.
                   The payload format for ULP FEC does not specify a rate parameter.
                   However, the rate for ULP FEC data is equal to the rate of the media
                   data it protects.
               
                   Optional parameters: none
               
                   Typical optional parameters [8], such as the number of channels, and
                   the duration of audio per packet, do not apply to ULP FEC data.  The
                   number of channels is effectively the same as the media data it
                   protects; the same is true for the duration of video per packet.
               
               
               
               
               Adam H. Li, et al.                                             [Page 27]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   Encoding considerations: This format is only defined for transport
                   within the Real Time Transport protocol (RTP) [3].  Its transport
                   within RTP is fully specified with RFC xxxx.
               
                   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/video streaming tools
                   and other applications 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
                      Department of Electrical Engineering
                      University of California
                      Los Angeles, CA 90095
                      adamli@icsl.ucla.edu
               
                   Intended usage: COMMON
               
                   Author/Change controller: This registration is part of the IETF
                   registration tree.
               
                   RTP and SDP Issues: Usage of this format within RTP and the Session
                   Description Protocol (SDP) [6] are fully specified within Section 10
                   of RFC xxxx.
               
               
               12. Acknowledgments
               
                   This text is partially based on an RFC 2733 [1] and RFC 3009 [9] on
                   generic RTP FEC payload format by H. Schulzrinne and J. Rosenburg.
                   The authors would also like to acknowledge the suggestions from many
                   people, particularly Tao Tian, Matthieu Tisserand, Stephen Wenger,
                   Jay Fahlen, and Jeffery Tseng.
               
               
               13. Bibliography
               
                   [1] J. Rosenberg and H. Schulzrine, "An RTP Payload Format for
                   Generic Forward Error Correction," Request for Comments (Proposed
                   Standard) 2733, Internet Engineering Task Force, December 1999.
               
               
               
               
               Adam H. Li, et al.                                             [Page 28]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   [2] C. Perkins and O. Hodson, "Options for repair of streaming media,
                   "Request for Comments (Informational) 2354, Internet Engineering Task
                   Force, June 1998.
               
                   [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
                   transport protocol for real-time applications," Request for Comments
                   (Proposed Standard) 1889, Internet Engineering Task Force, January
                   1996.
               
                   [4] 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.
               
                   [5] 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", RFC 2198, September 1997.
               
                   [6] M. Handley, and V. Jacobson, "SDP: Session Description Protocol",
                   RFC 2327, April 1998.
               
                   [7] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming
                   Protocol (RTSP)", RFC 2326, April 1998.
               
                   [8] S. Casner, and P. Hoschka, "MIME type registration of RTP payload
                   formats", Work in Progress.
               
                   [9] J. Rosenberg and H. Schulzrine, "Registration of parityfec MIME
                   types", Request for Comments (Proposed Standard) 3009, Internet
                   Engineering Task Force, November 2000.
               
               
               14. Authors' Addresses
               
                   Adam H. Li
                   Electrical Engineering Department
                   University of California, Los Angeles
                   Los Angeles, CA 90095
                   USA
                   Phone: +1-310-825-5178
                   Fax  : +1-310-825-7928
                   EMail: adamli@icsl.ucla.edu
               
                   Fang Liu
                   Electrical Engineering Department
                   University of California, Los Angeles
                   Los Angeles, CA 90095
                   USA
                   Phone: +1-310-825-5178
                   Fax  : +1-310-825-7928
                   EMail: fanliu@icsl.ucla.edu
               
               
               
               
               Adam H. Li, et al.                                             [Page 29]
               

               I-Draft      An RTP Payload Format for Generic FEC with ULP   April 2002
               
               
                   John D. Villasenor
                   Electrical Engineering Department
                   University of California, Los Angeles
                   Los Angeles, CA 90095
                   USA
                   Phone: +1-310-825-0228
                   Fax  : +1-310-825-7928
                   EMail: villa@icsl.ucla.edu
               
                   Jeong-Hoon Park
                   Samsung Electronics
                   Suwon City, Kyungki-Do
                   Korea
                   442-742
                   Phone: +82-31-200-3747
                   Fax  : +82-31-200-3147
                   Email: jeonghoon@samsung.com
               
                   Dong-Seek Park
                   Samsung Electronics
                   Suwon City, Kyungki-Do
                   Korea
                   442-742
                   Phone: +82-31-200-3674
                   Fax  : +82-31-200-3147
                   Email: dspark@samsung.com
               
                   Yung-Lyul Lee
                   Samsung Electronics
                   Suwon City, Kyungki-Do
                   Korea
                   442-742
                   Phone: +82-31-200-3719
                   Fax  : +82-31-200-3147
                   Email: yllee@samsung.com
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               Adam H. Li, et al.                                             [Page 30]
               

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/