idnits 2.17.1 draft-ietf-avt-fec-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (July 30, 1998) is 9403 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 748 looks like a reference -- Missing reference section? '2' on line 751 looks like a reference -- Missing reference section? '24' on line 509 looks like a reference -- Missing reference section? '65535' on line 513 looks like a reference -- Missing reference section? '3' on line 755 looks like a reference -- Missing reference section? '4' on line 759 looks like a reference -- Missing reference section? '5' on line 763 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio Video Transport WG 2 Internet Draft J.Rosenberg,H.Schulzrinne 3 draft-ietf-avt-fec-03.txt Bell Laboratories,Columbia U. 4 July 30, 1998 5 Expires: January 30, 1998 7 An RTP Payload Format for Generic Forward Error Correction 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 1 Abstract 31 This document specifies a payload format for generic forward error 32 correction of media encapsulated in RTP. It is engineered for FEC 33 algorithms based on the exclusive or (parity) operation or Reed Solo- 34 mon codes, although it can be used with other techniques. The payload 35 format allows end systems to transmit using arbitrary block lengths 36 and parity schemes. It also allows for the recovery of both the pay- 37 load and critical RTP header fields. Since FEC is sent as a separate 38 stream, it is backwards compatible with non-FEC capable hosts, so 39 that receivers which do not wish to implement FEC can just ignore the 40 extensions. 42 2 Introduction 44 The quality of packet voice on the Internet has been mediocre due, in 45 part, to high packet loss rates. This is especially true on wide-area 46 connections. Unfortunately, the strict delay requirements of real- 47 time multimedia usually eliminate the possibility of retransmissions. 48 It is for this reason that forward error correction (FEC) has been 49 proposed to compensate for packet loss in the Internet [1] [2]. In 50 particular, the use of traditional error correcting codes, such as 51 parity, Reed-Solomon, and Hamming codes, has attracted attention. To 52 support these mechanisms, protocol support is required. 54 This document defines a payload format for RTP which allows for gen- 55 eric forward error correction of real time media. In this context, 56 generic means that the FEC protocol is (1) independent of the nature 57 of the media being protected, be it audio, video, or otherwise, (2) 58 flexible enough to support a wide variety of FEC mechanisms, (3) 59 designed for adaptivity so that the FEC technique can be modified 60 easily without out of band signaling, and (4) supportive of a number 61 of different mechanisms for transporting the FEC packets. 63 3 Terminology 65 The following terms are used throughout this document: 67 1. Media Payload: is a piece of raw, un-protected user data which 68 is to be transmitted from the sender. The media payload would 69 is placed inside of an RTP packet. 71 2. Media Header: is the RTP header for the packet containing the 72 media payload. 74 3. Media Packet: The combination of a media payload and media 75 header is called a media packet. 77 4. FEC Packet: The forward error correction algorithms at the 78 transmitter take the media packets as an input. They output 79 both the media packets that they are passed, and new packets 80 called FEC packets. The FEC packets are formatted according to 81 the rules specified in this document. 83 5. FEC Header: The FEC header is the header information contained 84 in an FEC packet. 86 6. FEC Payload: The FEC payload is the payload in an FEC packet. 88 7. Associated: An FEC packet is said to be associated with one or 89 more media packets when those media packets are used to gener- 90 ate the FEC packet (by use of the exclusive or operation, for 91 example). 93 4 Basic Operation 95 The FEC packets are sent as a separate stream from the media packets. 96 This implies that the FEC packets have their own sequence number and 97 timestamp space. The media packet stream is essentially unaffected by 98 the use of FEC. This allows the two to be sent on a separate multi- 99 cast group, so that non-FEC receivers can ignore the FEC and just 100 receive the original media. The separation also allows for coherent 101 values for the sequence numbers and timestamps. 103 This document does not prescibe the definition of separate streams, 104 but leaves this to applications and higher level protocols to define. 105 For multicast, the separate stream may be implemented by separate 106 multicast groups, different ports in the same group, or by a differ- 107 ent SSRC within the same group/port. For unicast, different ports or 108 different SSRC may be used. Each of these approaches has drawbacks 109 and benefits which depend on the application. 111 At the receiver, arriving FEC and media packets are used to generate 112 a stream of media packets for direct use by the application. This 113 results in a clean separation of error protection from the applica- 114 tion. 116 The coding scheme used for generating the FEC packets is indicated by 117 means of the payload type field in the RTP header of the FEC packets. 118 Currently, two mechanisms are defined: parity codes and Reed-Solomon 119 Codes. 121 5 Parity Codes 123 For brevity, we define the function f(x,y,..) to be the XOR (parity) 124 operator applied to the data blocks x,y,... Each data block is simply 125 a set of bits of length L. The function is only well defined when the 126 lengths of the data blocks it operates on are equal. The output of 127 this function is a single data block equal in length to the inputs, 128 called the parity block. The parity block is the bitwise XOR of the 129 input blocks. Note that f(x) = x. 131 Recovery of data blocks using parity codes is accomplished by gener- 132 ating one or more parity blocks over a group of k packets. To be 133 effective, the parity blocks must be generated by linearly indepen- 134 dent combinations of data blocks. The particular combination is 135 called a parity code. After the parity operation, there will be a 136 total of n data plus parity blocks (i.e., n-k parity blocks). There 137 are a large number of possible parity codes for a given n,k. Reason- 138 able codes exist for large ranges of n and k. The payload format does 139 not mandate a particular code. 141 For example, consider a parity code which generates a single parity 142 block over two data blocks. The stream of blocks generated by the 143 code is thus: 145 a, b, f(a,b), c, d, f(c,d) 147 In this example, the error correction scheme (we use the terms scheme 148 and code interchangeably) introduces a 50% overhead. But if b is 149 lost, a and f(a,b) can be used to recover b. 151 Some additional codes are listed below. In each, the letters on the 152 left represent the stream of input data blocks, and the right repre- 153 sents the stream of data and parity blocks. 155 Scheme 0 156 -------- 158 This scheme is null, and has no error correction. The scheme is 159 formally defined as: 161 a,b,c,d, ... -> a, b, c, d, .... 163 Scheme 1 164 -------- 166 This scheme is the similar to the one in the example above. The 167 switching of the positions of f(b) and f(a,b) allow some bursts of two 168 consecutive packet losses to be recovered. It is defined as: 170 a,b,c,d,e,f -> a, f(a,b), b, f(b,c), c, f(c,d), d, ... 172 Scheme 2 173 -------- 175 This scheme allows for recovery of all single packet losses and some 176 consecutive packet losses, but with less overhead than scheme 1: 178 a,b,c,d,e,f,g -> f(a,b),f(a,c),f(a,b,c),f(c,d),f(c,e),f(c,d,e)... 180 Scheme 3 181 -------- 183 This scheme requires 4 packet delays to recover the original media 184 payloads, but it can recover from 1,2, or 3 consecutive packet losses: 186 a,b,c,d,e,f -> f(a),f(b),f(a,b,c),f(c),f(a,c,d),f(a,b,d),f(d), ... 188 The FEC protocol takes the media payloads as data blocks, and uses 189 the XOR operator on them to generate parity blocks which are the FEC 190 payloads. The xor operator is also applied to portions of the media 191 headers to assist in their recovery. 193 In order to decode the FEC payloads to media payloads, all that is 194 necessary is for the receiver to know the set of media payloads in 195 each FEC payload to which it is applied. This is exactly the informa- 196 tion provided by the payload format. 198 To determine which packets are associated with the FEC packet, a 199 field is present in the FEC header, called the offset mask. Assume 200 this mask is M bits. If bit i in the mask is set to 1, then the media 201 packet with sequence number N + i is associated with this FEC packet, 202 where N is the sequence number base in the FEC packet header. This 203 effectively allows an FEC packet to be associated with any of the M 204 packets before it. 206 The offset mask and payload type are sufficient to signal arbitary 207 parity based forward error correction schemes with little overhead. 209 6 Reed Solomon Codes 211 Reed Solomon codes offer better protection than parity codes, but at 212 an increased processing cost. The detailed operation of the codes is 213 not important here. A Reed Solomon code takes a group of k data 214 blocks and generates n - k FEC blocks. A receiver needs to receive 215 any k of the n data or FEC blocks in order to recover the k data 216 blocks. Besides k and n, the only parameters of the algorithm are the 217 symbol length, which is the number of bits per symbol used in the 218 algorithm. If the symbol length is l, the size of the data block must 219 be a multiple of l. 221 7 RTP Media Packet Structure 223 The media packets and FEC packets are sent as separate streams. The 224 media packets are unaffected by FEC, and are sent in the same fashion 225 they would be sent if there were no FEC. 227 This lends to a very efficient encoding. When little (or no) FEC is 228 used, there are mostly media packets being sent. This means that the 229 overhead (present in FEC packets only) tracks the amount of FEC in 230 use. 232 8 FEC Packet Structure 234 When a packet is to be transmitted which contains FEC data (i.e., its 235 payload is derived from one or more media payloads), the RTP header 236 is followed by an FEC header. We first discuss the semantics of the 237 RTP header fields. 239 The version field is set to 2. The padding bit is computed via the 240 protection operation, defined below. The extension bit is also com- 241 puted via the protection operation. The SSRC value should generally 242 be the same as the SSRC value of the media stream it protects. It may 243 be different if the FEC stream is being demultiplexed via the SSRC 244 value. The CC value is computed via the protection operation. The 245 CSRC list is never present, independent of the value of the CC field. 246 The extension is never present, independent of the value of the X 247 bit. The marker bit is computed via the protection operation. 249 The sequence number has the standard definition: it is one higher 250 than the sequence number in the previously transmitted FEC packet. 251 The timestamp is set in the following fashion. When the FEC packet is 252 sent, the value of the media RTP timestamp is examined. This value is 253 used as the timestamp of the FEC packet. This results in the TS value 254 in FEC packets to be monotonically increasing, independent of the FEC 255 scheme. 257 The payload type for the FEC packet is set as described above. End 258 systems which cannot recognize a payload type must discard it anyway. 259 This provides backwards compatibility. The FEC mechanisms can then be 260 used in a multicast group with mixed FEC-capable and FEC-uncapable 261 receivers. 263 Following the RTP header is the FEC header. The header is different 264 depending on whether Reed-Solomon or parity codes are in use, 266 8.1 Parity Header 268 This header is nominally 96 bits, and may be optionally extended to 269 128 bits. The format of the header is as follows: 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | SN Base | length recovery | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |E| PT Recovery | Mask | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | TS Recovery | 277 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 278 | Additional Offset Mask | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 The length recovery field is used to determine the length of any 282 recovered packets. It is computed via the protection operation 283 applied to the 16 bit natural binary representation of the lengths 284 (in bytes) of the media payload, CSRC list, extension and padding of 285 media packets associated with this FEC packet (in other words, the 286 CSRC list, extension, and padding, if present, are counted as part of 287 the payload). This allows for the FEC procedure to be applied even 288 when the lengths of the media packets are not identical. For example, 289 assume an FEC packet is being generated by xor'ing two media packets 290 together. The length of the two media packets are 3 (0b011) and 5 291 (0b101) bytes, respectively. The length recovery field is then 292 encoded as 0b011 xor 0b101 = 0b110. 294 The E bit indicates a header extension. When set to 1, it indicates 295 that an additional 32 bits of header follow. 297 The PT recovery field is obtained via the protection operation 298 applied to the payload types of the media packets associated with the 299 FEC packet. 301 The mask field is either 24 bits or 56 bits, depending on the value 302 of E. If bit i in the mask is set to 1, then the media packet with 303 sequence number N + i is associated with this FEC packet, where N is 304 the SN Base field in the FEC packet header. When only the 24 bit mask 305 is present, the LSB coresponds to i=0, and the MSB to i=23. When both 306 the 24 bit mask and the extension are present, the LSB of the addi- 307 tional mask corresponds to i=24, the MSB of the additional mask cor- 308 responds to i=55, the LSB of the normal mask corresponds to i=0, and 309 its MSB to i=23. 311 The SN base field is always set to the minimum sequence number of 312 those media packets protected by FEC. This allows for the FEC opera- 313 tion to extend over any string of at most 24 (56 with the extensions) 314 packets, whose range in sequence numbers is no more than 24 (56). 316 The TS recovery field is computed via the protection operation 317 applied to the timestamps of the media packets associated with this 318 FEC packet. This allows the timestamp to be completely recovered. 320 The payload of the FEC packet is the protection operation applied to 321 the CSRC List plus payloads of the media packets associated with the 322 FEC packet. 324 8.2 Reed Solomon Header 326 The format of the Reed-Solomon FEC header is shown below. 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | SN Base | length recovery | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |E| PT Recovery | N | k | i | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | TS Recovery | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 The length recovery, E, PT Recovery and TS Recovery have the same 337 syntax and semantics as for the parity header. The SN base is the 338 sequence number of the first media packet in the group protected by 339 FEC. The k field is the number of media packets in the block, minus 340 1. The N field is the total number of FEC plus data packets in the 341 block, minus 1. The i field indicates that this packet is the i+1th 342 FEC packet of the N-K FEC packets in the code. The symbol length of 343 the code is indicated by means of the payload type field in the RTP 344 header. Currently, a value of 8 bits is denoted by the payload type 345 [to be registered with IANA]. 347 The payload of the FEC packet is the protection operation applied to 348 the CSRC List plus payloads of the media packets associated with the 349 FEC packet, just like the parity codes. 351 9 Protection Operation 353 The protection operation involves taking a variety of fields from the 354 various headers, adding the payloads, appending the whole thing 355 together, padding zeroes, and then computing the FEC across the 356 resulting binary block. The result is then placed into the FEC 357 packet. 359 For each media packet to be protected, a binary array is generated by 360 appending the following fields together: 362 oPadding Bit (1 bit) 364 oExtension Bit (1 bit) 366 oCC bits (3 bits) 368 oMarker bit (1 bit) 370 oPayload Type (7 bits) 372 oTimestamp (32 bits) 373 oNatural binary representation of the length of the CSRC List plus 374 padding plus payload plus extension of the media packet (16 bits) 376 oCSRC List (if CC is 1), else null (variable) 378 oHeader Extension (if X is 1), else null (variable) 380 othe payload (variable) 382 oPadding, if present (variable) 384 If the lengths of the binary arrays are not equal, they are padded with 385 zeroes to be the length of the longest binary array. 387 The FEC operation (R-S or parity) is then applied across the binary 388 arrays. The result is the binary array of the FEC packet. 390 The first bit in the FEC packet binary array is written into the Padding 391 Bit of the FEC packet. The second bit in the FEC packet binary array is 392 written into the Extension bit of the FEC packet. The next three bits of 393 the FEC packet binary array are written into the CC field of the FEC 394 packet. The next bit of the FEC packet binary array is written into the 395 marker bit of the FEC packet. The next 7 bits of the FEC packet binary 396 array are written into the PT recovery field in the FEC packet header. 397 The next 32 bits of the FEC packet binary array are written into the TS 398 recovery field in the packet header. The next 16 bits are written into 399 the Length Recovery field in the FEC packet header. The remaining bits 400 are set to be the payload of the FEC packet. 402 10 Recovery Procedures 404 The FEC packets allow end systems to recover from the loss of media 405 packets. All of the header fields of the missing packets, including 406 CSRC lists, extensions, padding bits, marker and payload type, are 407 recoverable. This section describes the procedure for performing 408 this recovery. 410 Recovery requires two distinct operations. The first determines which 411 packets (media and FEC) must be combined in order to recover a miss- 412 ing packet. Once this is done, the second step is to actually recon- 413 struct the data. The second step must be performed as described 414 below. The first step can be based on any algorithm chosen by the 415 implementor. Different algorithms result in a tradeoff between com- 416 plexity and the ability to recover missing packets if at all possi- 417 ble. 419 10.1 Reconstruction 420 Let T be the list of packets (FEC and media) which can be combined to 421 recover some media packet xi. In the case of Reed-Solomon, T is any k 422 of the n data plus FEC packets in the group. For parity, this is an 423 FEC packet plus all but one of the media packets indicated by the 424 mask. The procedure is as follows: 426 1. For the media packets in T, compute the binary array as 427 described in the previous section. 429 2. For the FEC packets in T, compute the binary array in the same 430 fashion, except always set the CSRC list, extension, and pad- 431 ding to null. 433 3. If the resulting binary arrays are not of equal length, pad 434 them with zeroes to be the length of the longest binary array. 436 4. Apply the reconstruction to the binary arrays (XOR for parity 437 codes, the RS procedure for Reed-Solomon codes), resulting in 438 a recovery array. 440 5. Create a new packet with the standard 12 byte header and no 441 payload. 443 6. Set the version of the new packet to 2. 445 7. Set the Padding bit in the new packet to the first bit in the 446 recovery array. 448 8. Set the Extension bit in the new packet to the second bit in 449 the recovery array. 451 9. Set the CC field to the next three bits in the recovery array. 453 10. Set the marker bit in the new packet to the next bit in the 454 recovery array. 456 11. Set the payload type in the new packet to the next 7 bits in 457 the recovery array. 459 12. Set the SN field in the new packet to xi. 461 13. Set the TS field in the new packet to the next 32 bits in the 462 recovery array. 464 14. Take the next 16 bits of the recovery array. Whatever the nat- 465 ural binary number this corresponds to, take that many bytes 466 from the recovery array and append them to the new packet. 467 This represents the CSRC list, extension, payload, and 468 padding. 470 15. Set the SSRC of the new packet to the SSRC of the media stream 471 its protecting 473 This procedure will completely recover both the header and payload of an 474 RTP packet. 476 10.2 Determination of when to recover 478 10.2.1 Parity Codes 480 The previous section discussed how to recover a media packet with 481 sequence number xi when all of the packets needed to recover it were 482 available. The decision about whether to attempt recovery of some 483 media packet, and how to determine if sufficient data is available to 484 recover it, is left to the implementor. However, this section pro- 485 vides a simple algorithm which may be used for this purpose. 487 The algorithm is described below in C code. The code assumes that 488 several functions exist. recover_packet() takes the sequence number 489 of a packet, and an FEC packet. Using the FEC packet and data packets 490 received previously, the data packet with the given sequence number 491 is recovered. add_fec_to_pending_list() adds the given FEC packet to 492 a linked list of FEC packets which have not yet been used for recov- 493 ery. wait_for_packet() waits for a packet, FEC or data, from the net- 494 work. remove_from_pending_list() removes the FEC packet from the 495 pending list. The structure packet contains a boolean variable fec 496 which is true when the packet is FEC, false if its media. When its an 497 FEC packet, the mask and snbase field contain those values from the 498 FEC packet header. When its a media packet, the sn variable contains 499 the sequence number of the packet. The global array A indicates which 500 media packets have been received, and which have not. It is indexed 501 by the sequence number of the packet. 503 typedef struct packet_s { 505 int sn; 506 packet_s *next; 507 BOOLEAN fec; 509 BOOLEAN mask[24]; 510 int snbase; 512 } packet; 513 BOOLEAN A[65535]; 514 packet *pending_list; 516 packet *recover_with_fec(packet *fec_pkt) { 518 packet *data_pkt; 519 int pkts_present, /* number of packets from the mask that are present */ 520 pkts_needed, /* number of packets needed is the number of ones in 521 the mask minus 1 */ 522 pkt_to_recover, /* sn of the packet we are recovering */ 523 i; 525 pkts_present = 0; 526 pkts_needed = -1; 527 for(i = 0; i < 24; i++) { 528 if(A[i+fec_pkt->snbase] && mask[i]) pkts_present++; 529 if(mask[i]) pkts_needed++; 530 if(!A[i+fec_pkt->snbase] && mask[i]) pkt_to_recover = i+fec_pkt->snbase; 531 } 533 if(pkts_present == pkts_needed) { 534 data_pkt = recover_packet(pkt_to_recover, fec_pkt); 535 } else { 536 add_fec_to_pending_list(fec_pkt); 537 data_pkt = NULL; 538 } 540 return(data_pkt); 541 } 543 void fec_recovery { 545 packet *p, /* packet received or regenerated */ 546 *fecp; /* fec packet from pending list */ 548 while(1) { 550 p = wait_for_packet(); /* get packet from network */ 552 while(p) { 554 /* if its an FEC packet, try to recover with it. Otherwise, 555 if its a data packet, mark it as received, and check if 556 we can now recover a data packet with the list of pending 557 FEC packets */ 559 if(p->fec == TRUE) { 560 p = recover_with_fec(p); 561 } else { 563 /* Mark this data packet as here */ 564 A[p->sn] = TRUE; 566 /* Go through pending list. Try and recover a packet using 567 each FEC. If we are successful, add the data packet to 568 the list of received packets, remove the FEC packet from the 569 pending list, since we've used it, and then try to recover 570 some more */ 572 for(fecp = pending_list; fecp != NULL; fecp = fecp->next) { 573 p = recover_with_fec(fecp); 574 if(p) { 575 A[p->sn] = TRUE; 576 remove_fec_from_pending_list(fecp); 577 break; 578 } 579 } 580 } 582 } 584 } 586 } 588 This simple recovery algorithm works efficiently for schemes which 589 send a single FEC packet, and it will operate at lower effectiveness 590 for schemes which send more. Clearly, storage of previously received 591 FEC packets, and reexamination of them when later recoveries are 592 made, can vastly improve performance. Such procedures are left to 593 implementors. 595 10.2.2 Reed Solomon Codes 597 The determination of when to recover is much more straightforward for 598 Reed Solomon. When an FEC packet is received, the SN Base field is 599 noted, and the FEC is placed in a bin according to the SN Base. Other 600 FEC packets which arrive with the same SN Base are placed in that 601 bin. When a data packet arrives, it is placed in the bin if its 602 sequence number is within k of the SN Base, where k is obtained from 603 the FEC packet header. When there are k packets in a bin, recovery 604 can take place. 606 11 Parity Example 608 Consider 2 media packets to be sent, x and y. We wish to protect them 609 by sending one FEC packet which is derived from x and y. The three 610 packets are: 612 Media Packet x 613 -------------- 615 Version: 2 (10) 616 Padding: 0 (0) 617 Extension: 0 (0) 618 Marker: 0 (0) 619 PTI: 11 (01011) 620 SN: 8 (1000) 621 TS: 3 (011) 622 SSRC: 2 (10) 624 The payload length is 10 bytes. 626 Media Packet y 627 -------------- 629 Version: 2 (10) 630 Padding: 0 (0) 631 Extension: 0 (0) 632 Marker: 1 (1) 633 PTI: 18 (10010) 634 SN: 9 (1001) 635 TS: 5 (101) 636 SSRC: 2 (10) 638 The payload length is 11 bytes. 640 The FEC packet is then: 642 FEC Packet (contains a xor b) 643 ----------------------------- 645 Version: 2 (10) 646 Padding: 0 (0) 647 Extension: 0 (0) 648 Marker: 1 (1) (NOTE: 0 xor 1 = 1) 649 PTI: 191 (NOTE: Assume PTI 191 implies XOR FEC) 650 SN: 1 651 TS: 5 652 SSRC: 2 (10) 654 len. rec.: 1 (1) (NOTE: 0b1010 xor 0b1011 = 0001) 655 PTI rec.: 24 (11001) 656 SN base: 8 657 TS rec.: 6 (110) (3 xor 5 = 6) 658 E: 0 (0) 659 mask: 3 (000000000000000000000011) 661 The payload length is 11 bytes. 663 12 Use with Redundant Encodings 665 One can consider an FEC packet as a redundant coding of the media. 666 Because of this, the payload format for encoding of redundant audio 667 data [3] can be used to carry the FEC data along with the media. The 668 procedure for this is simple. In some media packet, the payload type 669 is set to the value for redundant encodings. The secondary coder is 670 then set to be the FEC data. This means that the PTI of the secondary 671 coder is set to the PTI value which indicates FEC. The block length 672 of the secondary coder is set to the length of the FEC header and 673 payload. The timestamp offset is set to the difference between the 674 media timestamp and the timestamp from the FEC packet. The secondary 675 coder payload includes the FEC header and FEC payload. 677 This procedure only works if an FEC packet is sent after at least one 678 of the media packets it is associated with has been sent. Otherwise, 679 the timestamp offset would be negative, which is not allowed. 681 Using the redundant encodings payload format also implies that the 682 marker bit cannot be recovered. 684 An advantage of this approach is a reduction in the overhead for 685 sending FEC packets. 687 13 Conclusion 689 This document has presented a new RTP payload format which allows for 690 forward error correction of audio visual media. It is generic, allow- 691 ing nearly any parity or Reed Solomon Code to be used. It is also 692 backwards compatible with existing RTP implementations. Receivers 693 which cannot understand FEC can discard the FEC packets, and still 694 receive the media packets. 696 14 Security Considerations 698 There are no security considerations beyond those discussed in [4] 699 and [5]. 701 15 Full Copyright Statement 703 Copyright (C) The Internet Society (1998). All Rights Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it 707 or assist in its implmentation may be prepared, copied, published and 708 distributed, in whole or in part, without restriction of any kind, 709 provided that the above copyright notice and this paragraph are 710 included on all such copies and derivative works. 712 However, this document itself may not be modified in any way, such as 713 by removing the copyright notice or references to the Internet Soci- 714 ety or other Internet organizations, except as needed for the purpose 715 of developing Internet standards in which case the procedures for 716 copyrights defined in the Internet Standards process must be fol- 717 lowed, or as required to translate it into languages other than 718 English. 720 The limited permissions granted above are perpetual and will not be 721 revoked by the Internet Society or its successors or assigns. 723 This document and the information contained herein is provided on an 724 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 725 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 726 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 727 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 728 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 730 16 Author's Addresses 732 Jonathan Rosenberg 733 Lucent Technologies, Bell Laboratories 734 101 Crawfords Corner Rd. 735 Holmdel, NJ 07733 736 Rm. 4C-526 737 email: jdrosen@bell-labs.com 739 Henning Schulzrinne 740 Columbia University 741 M/S 0401 742 1214 Amsterdam Ave. 743 New York, NY 10027-7003 744 email: schulzrinne@cs.columbia.edu 746 17 Bibliography 748 [1] J.-C. Bolot and A. Garcia, The case for fec-based error control 749 for packet audio in the internet, Multimedia Systems , 1997. 751 [2] O. Hodson and C. Perkins, Options for repair of streaming media, 752 Request for Comments (Informational) 2354, Internet Engineering Task 753 Force, June 1998. 755 [3] O. Hodson, I. Kouvelas, O. Hodson, M. Handley, and J. Bolot, RTP 756 payload for redundant audio data, Request for Comments (Proposed 757 Standard) 2198, Internet Engineering Task Force, Sept. 1997. 759 [4] H. Schulzrinne, RTP profile for audio and video conferences with 760 minimal control, Request for Comments (Proposed Standard) 1890, 761 Internet Engineering Task Force, Jan. 1996. 763 [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a 764 transport protocol for real-time applications, Request for Comments 765 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.