idnits 2.17.1 draft-li-ulp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 619 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 126 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 596 looks like a reference -- Missing reference section? '2' on line 600 looks like a reference -- Missing reference section? '3' on line 604 looks like a reference -- Missing reference section? '4' on line 608 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Li 2 draft-li-ulp-00.txt F. Liu 3 July 4, 2000 J. Villasenor 4 Expires: January 2001 Univ. of Calif., LA 5 J.H. Park 6 D.S. Park 7 Samsung Electronics 9 An RTP Payload Format for Generic FEC with Uneven Level Protection 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1 Abstract 33 This document specifies a payload format for generic forward error 34 correction to achieve uneven level protection (ULP) of media 35 encapsulated in RTP. It is an extension to the forward error correction 36 scheme specified in RFC 2733 [1], and it is also based on the 37 exclusive-or (parity) operation. The payload format allows end systems 38 to transmit using arbitrary protection length and levels, in additional 39 to using arbitrary block lengths. It also allows for the both complete 40 recovery of the critical payload and RTP header fields, and partial 41 recovery when complete recovery is not possible due to the packet lost 42 situation. This scheme is backward compatible with non-FEC capable 43 hosts, and hosts that are only capable of FEC schemes specified in 44 RFC2733 [1], so that receivers which do not wish to implement ULP 45 forward error correction can just ignore the extensions. 47 2 Introduction 49 Because of the real time nature of many applications, they have more 50 strict delay requirement than a pure data transmission. As a result, 51 retransmission of the lost packets is generally not a valid option for 52 such applications. A better way to attempt to recover information about 53 a lost packet in this case is FEC. Thus forward error correction (FEC) 54 has been used to compensate for packet loss in the Internet [2]. In 55 particular, the error correction has to be on the packet level, because 56 any correction within the packet will be useless if the whole packet is 57 lost. 59 In many cases for the network connections, the bandwidth is a very 60 limited resource. However, many traditional FEC schemes are not designed 61 for optimal usage of the limited bandwidth resource. A more efficient 62 way is to provide different protection levels for different parts of the 63 data stream of different importance. These unequal error protection 64 schemes make more efficient use of the bandwidth to provide overall 65 better protection of the data stream against the losts. To support these 66 mechanisms, protocol support is required. However, most of the unequal 67 error protection schemes require the knowledge of the importance level 68 or class of data stream. As a result, most of such schemes depend on the 69 nature and structure of the media being protected, and are not generic. 71 In many cases for multimedia streams, we have some very important 72 knowledge about the stream. In general, the more important parts of the 73 data are always at the beginning of the data packet. This is the common 74 practice for most codecs, since the beginning of the packet is closer to 75 the re-synchronization marker at the header and thus is more likely to 76 be correctly decoded if the data is variable length coded. Also, almost 77 all media formats have the frame headers at the beginning of the packet. 79 For video streams, most modern formats have optional data patitioning 80 modes to improve error resilience, where where the video macroblock 81 header data, the motion vector data and DCT coefficient data are 82 seperated in their individual partitions. In ITU-T H.263 version 3, when 83 the optional data partitioned syntax of Annex V is enabled, when the 84 optional data partioning mode is enabled and MPEG-4 Visual Simple 85 Profile, the video macroblock (MB) header and motion vector partitions 86 (which are much more important to the quality of video reconstruction) 87 transmitted in the partition at the beginning of the video packet while 88 residue DCT coefficient partitions (which are less important) are 89 transmitted in the partition close to the end of the packet. Because the 90 data is arranged in the order of more important data to less important 91 data, it would help to provide more protection to the beginning part of 92 the packet. 94 In case of audio stream, many new audio codecs do encode into bitstream 95 data of different importance classes and transmit them in the order of 96 more important to less important. Applying more protection to the 97 beginning of the packet would benifit. Even for uniform-significance 98 audio streams, special stretching techniques can be applied the 99 partially recovered audio data packets. Also, if there is audio 100 redundancy coding, it makes sense to have more protection applied to the 101 original data which is at the first half of the packet, while with no 102 protections for the redundant copies which is at the trailing half of 103 the packet. 105 So the application should benefit from unequal error protections scheme 106 with more emphasis on the beginning part of the packets. This document 107 defines a payload format for RTP [3] which allows for generic forward 108 error correction with unequal error protection for real time media. The 109 payload data is protected by one or more protection levels. The lower 110 protection level provides more protection by using smaller group size 111 (compare to higher protection levels) to generate the FEC packet. The 112 data that is closer to the beginning of the packet is protected by lower 113 protection levels because these data are in general more important and 114 carrying more information than those further behind. 116 In this context, generic means that the FEC protocol is (1) 117 independent of the nature of the media being protected, be it audio, 118 video, or otherwise, (2) flexible enough to support a wide variety of 119 FEC mechanisms, (3) designed for adaptivity so that the FEC technique 120 can be modified easily without out of band signaling, and (4) supportive 121 of a number of different mechanisms for transporting the FEC 122 packets. 124 3 Terminology 126 The following terms are used throughout this document: 128 Media Payload: is a piece of raw, un-protected user data which is 129 to be transmitted from the sender. The media payload is placed 130 inside of an RTP packet. 132 Media Header: is the RTP header for the packet containing the 133 media payload. 135 Media Packet: The combination of a media payload and media header 136 is called a media packet. 138 FEC Packet: The forward error correction algorithms at the 139 transmitter take the media packets as an input. They output both 140 the media packets that they are passed, and new packets called FEC 141 packets. The FEC packets are formatted according to the rules 142 specified in this document. 144 FEC Header: The FEC header is the header information contained in 145 an FEC packet. 147 FEC Payload: The FEC payload is the payload in an FEC packet. 149 Associated: An FEC packet is said to be "associated" with one or 150 more media packets when those media packets are used to generate 151 the FEC packet (by use of the exclusive or operation). 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [4]. 157 4 Basic Operation 159 The payload format described here is used whenever a participant in an 160 RTP session would like to protect a media stream it is sending with 161 uneven level protection (ULP) FEC. The ULP FEC supported by the format 162 are based on simple exclusive or (xor) parities as used also in RFC 2733 163 [1]. The sender takes the packets from the media stream that need to be 164 protected, and determines the protection level it wants for these 165 packets and the length for each level. The data of each level are 166 grouped in a way that is described below to provide each level a 167 different error resilience capability by adjusting the size of the 168 group. An xor operation is applied across the payload to generate the 169 FEC information for that level. The lower protection levels (which 170 provides high protection, or high error resilience) are applied to the 171 data that is closer to the beginning of the packet to ensure more 172 protection there. Based on the procedures defined here, the result is an 173 RTP packet containing ULP FEC information. This packet can be used at 174 the receiver to recover any one packets used to generate the FEC packet, 175 or to recover part of the packet depending on the packet lost situation. 176 By using uneven error protection, this scheme can make more efficient 177 use of the channel bandwidth, and provide more efficient error 178 resilience for transmission over error prone channels. 180 The payload format contains information that allows the sender to tell 181 the receiver exactly which media packets are protected by this ULP FEC 182 packet and the protection levels and lengths for each of them. 183 Specifically, each ULP FEC packet contains a set of protection length 184 and bitmask, called the offset mask, for each protection level. If bit i 185 in the mask m(k) (i.e., the mask for protection level k) is set to 1, 186 data of length L(k) in the media packet with sequence number N + i is 187 protected by this ULP FEC packet at level k. N is called the sequence 188 number base, and is sent in the FEC packet as well. The protection 189 length, offset mask and payload type are sufficient to signal arbitrary 190 parity based forward error correction schemes with little overhead. 191 There are a set of rules as described below on how the mask should be 192 set for different protection levels. This will ensure that if data of 193 protection level k for a packet is recoverable, all the data of 194 protection level lower than k is recoverable for that particular packet. 196 This document also describes procedures that allow the receiver to make 197 use of the ULP FEC without having to know the details of specific codes. 198 This allows the sender much flexibility; it can adapt the code in use 199 based on network conditions, and be certain the receivers can still make 200 use of the FEC for recovery. 202 At the receiver, the ULP FEC and original media are received. If no 203 media packets are lost, the ULP FEC can be ignored. In the event of 204 loss, the FEC packets can be combined with other media and FEC packets 205 that have been received, resulting in recovery of the whole or part of 206 the missing media packets. 208 RTP packets which contain data formatted according to this specification 209 (i.e., ULP FEC packets) are using dynamic RTP payload types. 211 5 RTP Media Packet Structure 213 The formatting of the media packets is unaffected by FEC. If the FEC is 214 sent as a separate stream, the media packets are sent as if there was 215 no FEC. 217 This lends to a very efficient encoding. When little (or no) FEC is 218 used, there are mostly media packets being sent. This means that the 219 overhead (present in FEC packets only) tracks the amount of FEC in use. 221 6 FEC Packet Structure 223 An FEC packet is constructed by placing an ULP FEC header and ULP FEC 224 payload in the RTP payload, as shown in Figure 1: 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | RTP Header | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | FEC Header | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ULP Layer 0 Header | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ULP Layer 0 Payload | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | ULP Layer 1 Header | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ULP Layer 1 Payload | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Cont. | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1: ULP FEC Packet Structure 247 6.1 RTP Header of FEC Packets 249 The version field is set to 2. The padding bit is computed via the 250 protection operation, defined below. The extension bit is also computed 251 via the protection operation. The SSRC value will generally be the same 252 as the SSRC value of the media stream it protects. It MAY be different 253 if the FEC stream is being demultiplexed via the SSRC value. The CC 254 value is computed via the protection operation. The CSRC list is never 255 present, independent of the value of the CC field. The extension is 256 never present, independent of the value of the X bit. The marker bit is 257 computed via the protection operation. 259 The sequence number has the standard definition: it MUST be one higher 260 than the sequence number in the previously transmitted FEC packet. The 261 timestamp MUST be set to the value of the media RTP clock at the 262 instant the FEC packet is transmitted. This results in the TS value in 263 FEC packets to be monotonically increasing, independent of the FEC 264 scheme. 266 The payload type for the FEC packet is determined through dynamic, out 267 of band means. According to RFC1889 [3], RTP participants which cannot 268 recognize a payload type must discard it. This provides backwards 269 compatibility. The FEC mechanisms can then be used in a multicast group 270 with mixed FEC-capable and FEC-incapable receivers. 272 6.2 FEC Header 274 This header is 12 bytes. The format of the header is shown in Figure 2, 275 and consists of an SN base field, length recovery field, E field, PT 276 recovery field, mask field and TS recovery field. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | SN base | length recovery | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |E| PT recovery | mask | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | TS recovery | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 2: FEC Header Format 290 This is exactly as the FEC header used in RFC 2733 [1]. The usage will 291 also be the exactly the same as specified as in RFC 2733, except that 292 the E bit MUST set to one for this version. 294 6.3 ULP Layer Header 296 The ULP Layer Header is 2 bytes for ULP layer 0, and 5 bytes for ULP 297 layer 1 and higher. The format of the header is shown in Figure 3 and 298 Figure 4, and consists of a Protection Length field, and mask field (for 299 layer 1 and higher headers). 301 0 1 302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Protection Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 3: ULP Layer Header Format (Level 0) 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Protection Length | mask | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | mask (cont.) | 315 +-+-+-+-+-+-+-+-+ 317 Figure 4: ULP Layer Header Format (Level 1 and higher) 319 The Protection Length field is 16 bits. It indicates the protection 320 length provided by the ULP FEC for the current protection level (i.e., 321 the payload length for the current protection level after the header). 323 The mask field is 24 bits. If bit i in the mask is set to 1, then 324 the media packet with sequence number N + i is associated with this ULP 325 FEC packet of current protection level, where N is the SN Base field in 326 the ULP FEC packet header. The least significant bit corresponds to 327 i=0, and the most significant to i=24. 329 The SN base field in the FEC header MUST be set to the minimum sequence 330 number of those media packets protected by ULP FEC. This allows for the 331 ULP FEC operation to extend over any string of at most 24 packets. 333 The setting of mask field shall follow the following rules: 335 a. A packet can only be protected by each protection level once. 337 b. For a packet to be protected at level p, it must also be protect 338 at level p-1. 340 c. Packets that are protected by one ULP FEC packet at level p-1 must 341 also be protected within a same ULP FEC packet at level p. Note: 342 the protection level p might be in different ULP FEC packet from 343 protection level p-1. 345 d. Packets that are protected in a packet with protection level p 346 (even the packet is not protected at that level), must not be 347 protected by levels equal or lower than p at later FEC packets. 349 The payload of the FEC packet of each level is the protection operation 350 applied to the concatenation of the CSRC list, RTP extension, media 351 payload, and padding of the media packets associated with the FEC 352 packet. The detail is described in the next section on the protection 353 operation 355 7 Protection Operation 357 The protection operation involves copying the payload, padding with 358 zeroes, and computing the xor across the resulting bit strings. In 359 additional, for protection of level 0, it also involves concatenating 360 specific fields from the RTP header of the media packet before the 361 payload data. The resulting bit string is used to generate the ULP FEC 362 packet. 364 The following procedure MAY be followed for the protection operation. 365 Other procedures MAY be followed, but the end result MUST be identical 366 to the one described here. 368 7.1 Protection Level 0 370 For each media packet to be protected, a bit string is generated by 371 concatenating the following fields together in the order specifed: 373 o Padding Bit (1 bit) 375 o Extension Bit (1 bit) 377 o CC bits (4 bits) 379 o Marker bit (1 bit) 381 o Payload Type (7 bits) 383 o Timestamp (32 bits) 385 o Unsigned network-ordered 16 bit representation of the sum of the 386 lengths of the CSRC List, length of the padding, length of the 387 extension, and length of the media packet (16 bits) 389 o if CC is nonzero, the CSRC List (variable length) 391 o if X is 1, the Header Extension (variable length) 393 o the payload (variable length) 395 o Padding, if present (variable length) 397 Note that the Padding Bit (first entry above) forms the most 398 significant bit of the bit string. 400 If the lengths of the bit strings are not equal, each bit string that is 401 shorter than the Protection Length 0 plus 62 bits, MUST be padded to 402 that length. Any value for the pad may be used. The pad MUST be added at 403 the end of the bit string. 405 The parity operation is then applied across the bit strings. The result 406 is the bit string used to build the FEC packet. Call this the ULP FEC 407 bit string (level 0). 409 The first (most significant) bit in the FEC bit string is written into 410 the Padding Bit of the FEC packet. The second bit in the FEC bit string 411 is written into the Extension bit of the FEC packet. The next four bits 412 of the FEC bit string are written into the CC field of the FEC packet. 413 The next bit of the FEC bit string is written into the marker bit of the 414 FEC packet. The next 7 bits of the FEC bit string are written into the 415 PT recovery field in the FEC packet header. The next 32 bits of the FEC 416 bit string are written into the TS recovery field in the packet header. 417 The next 16 bits are written into the length recovery field in the FEC 418 packet header. This is exactly the same as in RFC 2733 [1]. 420 The remaining bits (of length Protection Length 0) are set to be the 421 payload of the ULP FEC packet. 423 7.2 Protection Level 1 and higher 425 The protected data of the corresponding packets are copied into the bit 426 strings. If the packet ends before the Protection Length of the current 427 level is reached, the string is padded to that length. Any value for 428 the pad may be used. The pad MUST be added at the end of the bit 429 string. 431 The parity operation is applied across the protected data of the 432 corresponding packets. The generated ULP FEC bit of that level is then 433 appended to the payload of the ULP FEC packet. 435 8 Recovery Procedures 437 The FEC packets allow end systems to recover from the loss of media 438 packets. All of the header fields of the missing packets, including 439 CSRC lists, extensions, padding bits, marker and payload type, are 440 recoverable. This section describes the procedure for performing this 441 recovery. 443 Recovery requires two distinct operations. The first determines which 444 packets (media and FEC) must be combined in order to recover a missing 445 packet. Once this is done, the second step is to actually reconstruct 446 the data. The second step MUST be performed as described below. The 447 first step MAY be based on any algorithm chosen by the implementor. 448 Different algorithms result in a tradeoff between complexity and the 449 ability to recover missing packets if at all possible. 451 8.1 Reconstruction of Level 0 453 Let T be the list of packets (FEC and media) which can be combined to 454 recover some media packet xi. The procedure is as follows: 456 1. For the media packets in T, compute the bit string as 457 described in the protection operation of the previous section. 459 2. For the FEC packet in T, compute the bit string in the same 460 fashion, except always set the CSRC list, extension, and padding 461 to null. Read the Protection Length 0. Read string of that length 462 from that FEC packet. 464 3. If any of the bit strings generated from the media packets 465 are shorter than the bit string generated from the FEC packet, pad 466 them to be the same length as the bit string generated from the 467 FEC. The padding MUST be added at the end of the bit string, and 468 MAY be of any value. 470 4. Perform the exclusive or (parity) operation across the bit 471 strings, resulting in a recovery bit string. 473 5. Create a new packet with the standard 12 byte RTP header and 474 no payload. 476 6. Set the version of the new packet to 2. 478 7. Set the Padding bit in the new packet to the first bit in the 479 recovery bit string. 481 8. Set the Extension bit in the new packet to the second bit in 482 the recovery bit string. 484 9. Set the CC field to the next four bits in the recovery bit 485 string. 487 10. Set the marker bit in the new packet to the next bit in the 488 recovery bit string. 490 11. Set the payload type in the new packet to the next 7 bits in 491 the recovery bit string. 493 12. Set the SN field in the new packet to xi. 495 13. Set the TS field in the new packet to the next 32 bits in the 496 recovery bit string. 498 14. Take the next 16 bits of the recovery bit string. Whatever 499 unsigned integer this represents (assuming network-order), take 500 that many bytes from the recovery bit string and append them to 501 the new packet. This represents the CSRC list, extension, payload, 502 and padding. 504 15. Set the SSRC of the new packet to the SSRC of the media 505 stream it's protecting. 507 This procedure will recover both the header and payload of an RTP 508 packet up to the Protection Length of level 0. 510 8.2 Reconstruction of Level 1 and higher 512 Let T be the list of packets (FEC and media) which can be combined to 513 recover some media packet xi. The procedure is as follows: 515 1. For the media packet in T, get the protection length of that 516 level. Copy the data of the that protection level (data of the 517 length read following the level header) to the bit strings. 519 2. If any of the bit strings generated from the media packets 520 are shorter than the Protection Length of the current level, pad 521 them to that length. The padding MUST be added at the end of the 522 bit string, and MUST be of the same value as used in the process 523 of generating the ULP FEC packets. 525 3. Perform the exclusive or (parity) operation across the bit 526 strings, resulting in a recovery bit string. 528 Because the data protected at lower protection level is always 529 recoverable if the higher level protected data is recoverable. This 530 procedure (together with the procedure for the lower protection levels) 531 will recover both the header and payload of an RTP packet up to the 532 Protection Length of the current level. 534 9 Examples 536 9.1 An example that generates identical protection as in RFC 2733 538 9.2 An example that has only protection level 0 540 9.3 An example that has two protection levels (0 and 1) 542 10 Acknowledgments 544 This text is partially based on an RFC 2733 on FEC by H. Schulzrinne and 545 J. Rosenburg. The authors would also like to acknowledge the suggestions 546 from many people, particularly Tao Tian, Matthieu Tisserand, and Stephen 547 Wenger. 549 11 Author's Addresses 551 Adam H. Li 552 Electronic Engineering Department 553 University of California, Los Angeles 554 Los Angeles, CA 90095 555 USA 556 Phone: +1-310-825-5178 557 Fax : +1-310-825-7928 558 EMail: adamli@icsl.ucla.edu 560 Fang Liu 561 Electronic Engineering Department 562 University of California, Los Angeles 563 Los Angeles, CA 90095 564 USA 565 Phone: +1-310-825-5178 566 Fax : +1-310-825-7928 567 EMail: fanliu@icsl.ucla.edu 569 John D. Villasenor 570 Electronic Engineering Department 571 University of California, Los Angeles 572 Los Angeles, CA 90095 573 USA 574 Phone: +1-310-825-5178 575 Fax : +1-310-825-7928 576 EMail: villa@icsl.ucla.edu 578 Jeong-Hoon Park 579 Samsung Electronics 580 Suwon, Kyoungi 442-742 581 Korea 582 Phone: +82-331-200-3674 583 Fax : +82-331-200-3174 584 Email: jhpark@mmrnd.sec.samsung.co.kr 586 Dong-Seek Park 587 Samsung Electronics 588 Suwon, Kyoungi 442-742 589 Korea 590 Phone: +82-331-200-3674 591 Fax : +82-331-200-3174 592 Email: dspark@mmrnd.sec.samsung.co.kr 594 12 Bibliography 596 [1] J. Rosenberg and H. Schulzrine, "An RTP Payload Format for Generic 597 Forward Error Correction," Request for Comments (Proposed Standard) 598 2733, Internet Engineering Task Force, Dec. 1999. 600 [2] C. Perkins and O. Hodson, "Options for repair of streaming media," 601 Request for Comments (Informational) 2354, Internet Engineering Task 602 Force, June 1998. 604 [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 605 transport protocol for real-time applications," Request for Comments 606 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 608 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 609 levels," Request for Comments (Best Current Practice) 2119, Internet 610 Engineering Task Force, Mar. 1997.