[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-02.txt                                         F. Liu
October 24, 2001                                           J. Villasenor
Expires: April 24 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 any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as work in progress.

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

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


ABSTRACT

   This document specifies a payload format for generic forward error
   correction to achieve uneven level protection (ULP) of media
   encapsulated in RTP. It is an extension to the forward error
   correction scheme specified in RFC 2733 [1], and it is also based on
   the exclusive-or (parity) operation. The payload format allows end
   systems to transmit using arbitrary protection length and levels, in
   additional to using arbitrary block lengths. It also allows for the
   both complete recovery of the critical payload and RTP header fields,
   and partial recovery when complete recovery is not possible due to
   the packet lost situation. This scheme is backward compatible with
   non-FEC capable hosts, and hosts that are only capable of FEC schemes
   specified in RFC 2733 [1], so that receivers which do not wish to
   implement ULP forward error correction can just ignore the
   extensions.





Adam H. Li, et al.                                              [Page 1]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


Table of Contents

   1. Introduction ................................................... 2
   2. Terminology ..... .............................................. 4
   3. Basic Operation ................................................ 4
   4. RTP Media Packet Structure ..................................... 6
   5. ULP FEC Packet Structure ....................................... 6
   5.1. RTP Header of ULP FEC Packets ................................ 6
   5.2. FEC Header ................................................... 7
   5.3. ULP Layer Header ............................................. 7
   6. Protection Operation ........................................... 8
   6.1. Protection Level 0 ........................................... 9
   6.2. Protection Level 1 and Higher ............................... 10
   7. Recovery Procedure ............................................ 10
   7.1. Reconstruction of Level 0 ................................... 10
   7.2. Reconstruction of Level 1 and Higher ........................ 12
   8. Examples ...................................................... 12
   8.1. An Example That Has Only Protection Level 0 ................. 12
   8.2. An Example That Generates Idential Protection as in RFC 2733  14
   8.3. An Example That Has Two Protection Levels (0 and 1) ......... 15
   9. Security and Congestion Considerations ........................ 19
   10. Indication ULP FEC Usage in SDP .............................. 20
   10.1. ULP FEC as a Separate Stream ............................... 20
   10.2. Use with Redundant Encoding ................................ 21
   10.3. Usage with RTSP ............................................ 22
   11. MIME Registrations ........................................... 22
   11.1. Registration of audio/ulpfec ............................... 22
   11.2. Registration of video/ulpfec ............................... 23
   11.3. Registration of text/ulpfec ................................ 24
   11.4. Registration of application/ulpfec ......................... 26
   12. Acknowledgements ............................................. 27
   13. Bibliography ................................................. 27
   14. Authors' Address ............................................. 28


1. Introduction

   Because of the real time nature of many applications, they have more
   strict delay requirement than a pure data transmission. As a result,
   retransmission of the lost packets is generally not a valid option
   such applications. A better way to attempt to recover information
   about a lost packet in this case is FEC. Thus forward error
   correction (FEC) has been used to compensate for packet loss in the
   Internet [2]. In particular, the error correction has to be on the
   packet level, because any correction within the packet will be
   useless if the whole packet is lost.

   In many cases for the network connections, the bandwidth is a very
   limited resource. However, many traditional FEC schemes are not
   designed for optimal usage of the limited bandwidth resource. A more
   efficient way is to provide different protection levels for different
   parts of the data stream of different importance. These unequal error
   protection schemes make more efficient use of the bandwidth to

Adam H. Li, et al.                                              [Page 2]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   provide overall better protection of the data stream against the
   lost. To support these mechanisms, protocol support is required.
   However, most of the unequal error protection schemes require the
   knowledge of the importance level or class of data stream. As a
   result, most of such schemes depend on the nature and structure of
   the media being protected, and are not generic.

   In many cases for multimedia streams, we have some very important
   knowledge about the stream. In general, 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 if the data is variable length
   coded. Also, almost all media formats have the frame headers at the
   beginning of the packet.

   For video streams, most modern formats have optional data
   partitioning modes to improve error resilience, where the video
   macroblock header data, the motion vector data and DCT coefficient
   data are separated in their individual partitions. In ITU-T H.263
   version 3, when the optional data partitioned syntax of Annex V is
   enabled, when the optional data partitioning mode is enabled in MPEG-
   4 Visual Simple Profile, the video macroblock (MB) header and motion
   vector partitions (which are much more important to the quality of
   video reconstruction) transmitted in the partition 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 the order of more
   important data to less important data, it would help to provide more
   protection to the beginning part of the packet.

   In case of audio stream, many new audio codecs do encode into
   bitstream data of different importance classes and transmit them in
   the order of more important to less important. Applying more
   protection to the beginning of the packet would benefit. Even for
   uniform-significance audio streams, special stretching techniques can
   be applied the partially recovered audio data packets. Also, if there
   is audio redundancy coding, it makes sense to have more protection
   applied to the original data which is at the first half of the
   packet, while with no protections for the redundant copies which is
   at the trailing half of the packet.

   So the application should benefit from unequal error protections
   scheme with more emphasis on the beginning part of the packets. This
   document defines a payload format for RTP [3] which allows for
   generic forward error correction with unequal error protection for
   real time media. The payload data is protected by one or more
   protection levels. The lower protection level provides more
   protection by using smaller group size (compare to higher protection
   levels) to generate the FEC packet. The data that is closer to the
   beginning of the packet is protected by lower protection levels
   because these data are in general more important and carrying more
   information than those further behind.

Adam H. Li, et al.                                              [Page 3]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001



   In this context, generic means that the FEC protocol is (1)
   independent of the nature of the media being protected, be it audio,
   video, or otherwise, (2) flexible enough to support a wide variety of
   FEC mechanisms, (3) designed for adaptivity so that the FEC technique
   can be modified easily without out of band signaling, and (4)
   supportive of a number of different mechanisms for transporting the
   FEC packets.


2. Terminology

   The following terms are used throughout this document:

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

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

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

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

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

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

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].


3. Basic Operation

   The payload format described here is used whenever a participant in
   an RTP session would like to protect a media stream it is sending
   with uneven level protection (ULP) FEC. The ULP FEC supported by the
   format are based on simple exclusive-or (xor) parities as used also
   in RFC 2733 [1]. The sender takes the packets from the media stream
   that need to be protected, and determines the protection level it
   wants for these packets and the length for each level. The data of

Adam H. Li, et al.                                              [Page 4]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   each level are grouped in a way that is described below to provide
   each level a different error resilience capability by adjusting the
   size of the group. An xor operation is applied across the payload to
   generate the ULP FEC information for that level. The lower protection
   levels (which provides high protection, or high error resilience) are
   applied to the data that is closer to the beginning of the packet to
   ensure more protection there. Based on the procedures defined here,
   the result is an RTP packet containing ULP FEC information. This
   packet can be used at the receiver to recover any one packets used to
   generate the ULP FEC packet, or to recover part of the packet
   depending on the packet lost situation. 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 this
   ULP FEC packet and the protection levels and lengths for each of
   them. Specifically, each ULP FEC packet contains a set of protection
   length and bitmask, called the offset mask, for each protection
   level. If bit i in the mask m(k) (i.e., the mask for protection level
   k) is set to 1, data of length L(k) in the media packet with sequence
   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 protection length, offset mask and payload type are
   sufficient to signal arbitrary parity based forward error correction
   schemes with little overhead. There are a set of rules as described
   below on how the mask should be set for different protection levels.
   This will ensure that if data of protection level k for a packet is
   recoverable, all the data of protection level lower than k is
   recoverable for that particular packet.

   This document also describes procedures that allow the receiver to
   make use of the ULP FEC without having to know the details of
   specific codes. This allows the sender much flexibility; it can adapt
   the code in use based on network conditions, and be certain the
   receivers can still make use of the 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
   loss, the ULP FEC packets can be combined with other media and ULP
   FEC packets that have been received, resulting in recovery of the
   whole or part of the missing media packets.

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







Adam H. Li, et al.                                              [Page 5]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


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


5. ULP FEC Packet Structure

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


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ULP Layer 0 Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ULP Layer 0 Payload                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ULP Layer 1 Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ULP Layer 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. It MAY
   be different if the FEC stream is being demultiplexed via the SSRC
   value. The CC value is computed via the protection operation. The
   CSRC list is never present, independent of the value of the CC field.
   The extension is never present, independent of the value of the X
   bit. The marker bit is computed via the protection operation.



Adam H. Li, et al.                                              [Page 6]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   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. This results in the
   TS value in FEC packets to be monotonically increasing, independent
   of the FEC scheme.

   The payload type for the ULP FEC packet is determined through
   dynamic, out of band means. According to RFC 1889 [3], RTP
   participants which 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.

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 as the FEC header used in RFC 2733 [1]. The usage
   will also be the exactly the same as specified as in RFC 2733, except
   that the E bit MUST set to one for this version.

5.3. ULP Layer Header

   The ULP Layer Header is 2 bytes for ULP layer 0, and 5 bytes for ULP
   layer 1 and higher. The format of the header is shown in Figure 3 and
   Figure 4, and consists of a Protection Length field, and mask field
   (for layer 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 Layer Header Format (Level 0)

Adam H. Li, et al.                                              [Page 7]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001




    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 Layer Header Format (Level 1 and higher)


   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. The detail is described in the next section
   on the protection operation


6. Protection Operation

   The protection operation involves copying the payload, padding with
   zeroes, and computing the xor across the resulting bit strings. In
   additional, for protection of level 0, it also involves concatenating
   specific fields from the RTP header of the media packet before the

Adam H. Li, et al.                                              [Page 8]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   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 followed, 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:

      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 for the pad may be used. 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. 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

Adam H. Li, et al.                                              [Page 9]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   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.

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 at all
   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


Adam H. Li, et al.                                             [Page 10]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


          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.

      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.






Adam H. Li, et al.                                             [Page 11]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


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.

      3.  Perform the exclusive-or (parity) operation across the bit
          strings, resulting in a recovery bit string.

   Because the data protected at lower protection level is always
   recoverable if the higher level protected data is recoverable. This
   procedure (together with the procedure for the lower protection
   levels) will 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, with
   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 That Has 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.















Adam H. Li, et al.                                             [Page 12]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


              +------:------------+
   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 layer 0 in the ULP FEC packet is shown in Figure
   8.


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

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

   Figure 6: RTP Header of ULP FEC for Packets A, B, C and D (one level)





Adam H. Li, et al.                                             [Page 13]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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
      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 Layer Header (Level 0)


8.2. An Example That Generates Identical Protection as in RFC 2733

   We can choose to extend the level 0 protection to cover all the
   length of the packets (as shown in Figure 9). This is give us 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 extra flexbility.















Adam H. Li, et al.                                             [Page 14]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


              +-------------------+             :
   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 layer
   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 Layer Header (Level 0)


8.3. An Example That Has Two Protection Levels (0 and 1)

   A more complete example is to use ULP at two levels. The level 0 ULP
   will put more 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.










Adam H. Li, et al.                                             [Page 15]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


              +------:--------:---+
   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.


    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


Adam H. Li, et al.                                             [Page 16]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001



   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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
      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 Layer Header (Level 0) for ULP FEC Packet #1


   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

Adam H. Li, et al.                                             [Page 17]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


      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
      TS rec.:   6    [7 xor 9]

   Figure 16: FEC Header of ULP Packet #2


    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 Layer 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

      The payload length for level 1 is 90 bytes.

   Figure 18: ULP Layer Header (Level 1) for ULP Packet #2


Adam H. Li, et al.                                             [Page 18]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001



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 permutations on the usage of
   encryption. In particular:

      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 any application level
   signaling protocols to be aware of the usage of ULP FEC, and to thus
   exchange keys for it and negotiate its 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 violation, as ULP
   FEC packets should really be treated no differently than other RTP
   packets. Encrypting just one may also make certain known-plaintext
   attacks possible. For these reasons, applications utilizing
   encryption SHOULD encrypt both streams.

   The changing of keys is another issue needs to be taken good care of.
   For example, if two packets a and b are sent, and ULP FEC packet
   protects a and b is sent, and the keys used for a and b are
   different, which key should be used to decode the ULP FEC packet? In
   general, old keys will likely need to be cached, so that when the
   keys change for the media stream, the old key is kept, and used,
   until it is determined that the key has changed on 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 are
   induced by congestions. In such scenarios, adding FEC in the face of
   increasing network losses should be avoided, as it can lead to
   increased congestion and eventual congestion collapse if done on a
   widespread basis. The applications may include stronger protections
   while at the same time reduce the bandwidth for the payload packets.
   In any event, implementers MUST NOT substantially increase the total
   amount of bandwidth (including the payload and the ULP FEC) in use as
   network losses increase.





Adam H. Li, et al.                                             [Page 19]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


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 can mean they are 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
   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:


Adam H. Li, et al.                                             [Page 20]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


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




Adam H. Li, et al.                                             [Page 21]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


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.


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

Adam H. Li, et al.                                             [Page 22]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001



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


Adam H. Li, et al.                                             [Page 23]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   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.

   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

Adam H. Li, et al.                                             [Page 24]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001



   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

   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.




Adam H. Li, et al.                                             [Page 25]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   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.

   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
      Los Angeles, CA 90095

Adam H. Li, et al.                                             [Page 26]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


      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, and Stephen
   Wenger.


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.

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


Adam H. Li, et al.                                             [Page 27]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


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


14. Author's Addresses

   Adam H. Li
   Electronic 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
   Electronic 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

   John D. Villasenor
   Electronic Engineering Department
   University of California, Los Angeles
   Los Angeles, CA 90095
   USA
   Phone: +1-310-825-5178
   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



Adam H. Li, et al.                                             [Page 28]

I-Draft      An RTP Payload Format for Generic FEC with ULP October 2001


   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 29]


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