Internet Draft A. Li draft-ietf-avt-ulp-03.txt F. Liu December 18, 2001 J. Villasenor Expires: June 18 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 completely backward compatible with non-FEC capable hosts, and hosts that are only capable of FEC schemes specified in RFC 2733 [1], as that receivers which do not know about 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 Dec 2001 Table of Contents 1. Introduction ................................................... 3 2. Terminology ..... .............................................. 5 3. Basic Operation ................................................ 5 4. RTP Media Packet Structure ..................................... 6 5. ULP FEC Packet Structure ....................................... 7 5.1. RTP Header of ULP FEC Packets ................................ 7 5.2. FEC Header ................................................... 8 5.3. ULP Layer Header ............................................. 8 6. Protection Operation ........................................... 9 6.1. Protection Level 0 ........................................... 9 6.2. Protection Level 1 and Higher ............................... 11 7. Recovery Procedure ............................................ 11 7.1. Reconstruction of Level 0 ................................... 11 7.2. Reconstruction of Level 1 and Higher ........................ 12 8. Examples ...................................................... 13 8.1. An Example That Has Only Protection Level 0 ................. 13 8.2. An Example That Generates Idential Protection as in RFC 2733 15 8.3. An Example That Has Two Protection Levels (0 and 1) ......... 16 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 ........................................... 23 11.1. Registration of audio/ulpfec ............................... 23 11.2. Registration of video/ulpfec ............................... 24 11.3. Registration of text/ulpfec ................................ 25 11.4. Registration of application/ulpfec ......................... 26 12. Acknowledgements ............................................. 27 13. Bibliography ................................................. 27 14. AuthorsĖ Address ............................................. 28 Adam H. Li, et al. [Page 2] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 1. Introduction Because of the real time nature of many applications, they have more strict 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 way to attempt recovering information of lost packets is Forward Error Correction (FEC). FEC has been one of the main methods to protect against packet loss in the Internet [2]. In particular, the forward error correction discussed here is on the packet level, because any correction within the packet will be useless if the whole packet is lost. In many cases, the bandwidth of the network connections is very limited resource. However, most of traditional FEC schemes are not designed for optimal utilization of the limited bandwidth resource. A more efficient way would be to provide different protection levels for different parts of the data stream of different 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 lost. Proper protocol support is essential for realizing these unequal error protection mechanisms. However, application of most of the unequal error protection schemes require the knowledge of the importance level or class of data stream. Most of such schemes are designed for a particular type of media according to structure of the media protected, and as a result, 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 from more important data to less important data, it would help to provide more protection to the beginning part of the packet in transmission. 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 Adam H. Li, et al. [Page 3] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. The application would 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 in the packet. This document specifies a RTP payload format that extends the generic forward error correction schemes as specified in RFC 2733 [1]. This extension enables different levels of protection being applied to different parts of the packet. While it is always a option to treat the whole packet 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. The ULP algorithm specified in this document is designed to deal with any type of packet lose occurred in transmission, just as RFC 2733 it extends. It is not designed to recover bit error within a packet, and it is assumed that all the RTP packet received are free of bit error. The ULP algorithm is designed to be fully interoperable between the hosts that are ULP-capable, and the hosts that do not know about it. Since the media payload are not altered and the protection is sent as additional information, the receivers which do not know about 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 the scenario that many different hosts are in need of communication with each other as the same time, such as multicast. The ULP algorithm is also a generic protection algorithm with the following features: (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. Adam H. Li, et al. [Page 4] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. 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 new packets called ULP FEC packets. The ULP 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 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 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 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 Adam H. Li, et al. [Page 5] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. 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. Adam H. Li, et al. [Page 6] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. 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. Adam H. Li, et al. [Page 7] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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) 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) Adam H. Li, et al. [Page 8] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 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) Adam H. Li, et al. [Page 9] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 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 10] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 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 11] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 12] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. +------:------------+ 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. Adam H. Li, et al. [Page 13] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 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) Adam H. Li, et al. [Page 14] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. +-------------------+ : 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) Adam H. Li, et al. [Page 15] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. +------:--------:---+ 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 16] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 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 Adam H. Li, et al. [Page 17] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 TS rec.: 6 [7 xor 9] Figure 16: FEC Header of ULP Packet #2 Adam H. Li, et al. [Page 18] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 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 Adam H. Li, et al. [Page 19] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. 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 Adam H. Li, et al. [Page 20] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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: 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 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 21] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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: 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 22] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 23] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 24] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 25] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 26] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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. 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. Adam H. Li, et al. [Page 27] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 [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. 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 Adam H. Li, et al. [Page 28] I-Draft An RTP Payload Format for Generic FEC with ULP Dec 2001 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 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]