idnits 2.17.1 draft-ietf-avt-ulp-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2096. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC3009, but the abstract doesn't seem to directly say this. It does mention RFC3009 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (August 2, 2007) is 6109 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 2019, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4288 (ref. '3') (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3388 (ref. '5') (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 4756 (ref. '6') (Obsoleted by RFC 5956) ** Obsolete normative reference: RFC 2327 (ref. '8') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2733 (ref. '9') (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3009 (ref. '11') (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3452 (ref. '12') (Obsoleted by RFC 5052, RFC 5445) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Adam Li 3 draft-ietf-avt-ulp-23.txt Editor 4 Obsoletes: 2733, 3009 (if approved) 5 August 2, 2007 6 Expires: February 2, 2008 8 RTP Payload Format for Generic Forward Error Correction 10 STATUS OF THIS MEMO 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a submission of the IETF AVT WG. Comments should be 34 directed to the AVT WG mailing list, avt@ietf.org. 36 ABSTRACT 38 This document specifies a payload format for generic Forward 39 Error Correction (FEC) for media data encapsulated in RTP. It is 40 based on the exclusive-or (parity) operation. The payload format 41 described in this draft allows end systems to apply protection 42 using various protection lengths and levels, in addition to 43 using various protection group sizes to adapt to different media 44 and channel characteristic. It enables complete recovery of the 45 protected packets or partial recovery of the critical parts of 46 the payload depending on the packet loss situation. This scheme 47 is completely compatible with non-FEC capable hosts, so the 49 I-Draft RTP Payload Format for Generic FEC August 2, 2007 51 receivers in a multicast group that do not implement FEC can 52 still work by simply ignoring the protection data. This 53 specification obsoletes RFC 2733 and RFC 3009. The FEC specified 54 in this document is not backward compatible with RFC 2733 and 55 RFC 3009. 57 I-Draft RTP Payload Format for Generic FEC August 2, 2007 59 Table of Contents 61 1. Introduction .................................................. 4 62 2. Terminology ................................................... 6 63 3. Basic Operation ............................................... 7 64 4. Parity Codes .................................................. 7 65 5. Uneven Level Protection (ULP) ................................. 8 66 6. RTP Media Packet Structure ................................... 10 67 7. FEC Packet Structure ......................................... 10 68 7.1. Baseline Mode FEC .......................................... 10 69 7.2. RTP Header for FEC Packets ................................. 10 70 7.3. FEC Header for FEC packets ................................. 11 71 7.4. FEC Level Header for FEC Packets ........................... 12 72 8. Protection Operation ......................................... 15 73 8.1. Generation of the FEC Header ............................... 15 74 8.2. Generation of the FEC Payload .............................. 15 75 9. Recovery Procedure ........................................... 16 76 9.1. Reconstruction of the RTP Header ........................... 16 77 9.2. Reconstruction of the RTP Payload .......................... 17 78 10. Examples .................................................... 18 79 10.1. An Example Offers Similar Protection As RFC 2733 .......... 19 80 10.2. An Example With Two Protection Levels ..................... 21 81 10.3. An Example With FEC As Redundant Coding ................... 25 82 11. Security Considerations ..................................... 27 83 12. Congestion Considerations ................................... 29 84 13. IANA Considerations ......................................... 29 85 13.1. Registration of audio/ulpfec .............................. 30 86 13.2. Registration of video/ulpfec .............................. 31 87 13.3. Registration of text/ulpfec ............................... 32 88 13.4. Registration of application/ulpfec ........................ 33 89 14. Multiplexing of FEC ......................................... 34 90 14.1. FEC as a Separate Stream .................................. 35 91 14.2. FEC as Redundant Encoding ................................. 36 92 14.3. Offer / Answer Consideration .............................. 37 93 15. Application Statement ....................................... 38 94 16. Acknowledgements ............................................ 39 95 17. Bibliography ................................................ 40 96 17.1. Normative References ...................................... 40 97 17.2. Informative References .................................... 40 98 18. Author's Address ............................................ 41 99 Copyright Statement ............................................. 42 100 Disclaimer of Validity .......................................... 42 102 I-Draft RTP Payload Format for Generic FEC August 2, 2007 104 1. Introduction 106 The nature of real-time applications implies that they usually have 107 more stringent delay requirements than normal data transmissions. As 108 a result, retransmission of the lost packets is generally not a 109 valid option for such applications. In these cases, a better method 110 to attempt recovery of information from packet loss is through 111 Forward Error Correction (FEC). FEC is one of the main methods used 112 to protect against packet loss over packet switched networks [9, 113 10]. In particular, the use of traditional error correcting codes, 114 such as parity, Reed-Solomon, and Hamming codes, has seen much 115 application. To apply these mechanisms, protocol support is 116 required. RFC 2733 [9] and RFC 3009 [11] defined one of such FEC 117 protocols. However, in these two RFCs a few fields (the P, X, and CC 118 fields) in the RTP header are specified in ways which are not 119 consistent as they are designed in RTP [1]. This prevents the 120 payload-independent validity check of the RTP packets. 122 This document extends the FEC defined in RFC 2733 and RFC 3009 to 123 include unequal error protection on the payload data. It specifies a 124 general algorithm with the two previous RFCs as its special cases. 125 This specification also fixes the above-mentioned inconsistency with 126 RFC 2733 and RFC 3009, and will obsolete those two previous RFCs. 127 Please note that the payload specified in this document is not 128 backward compatible with RFC 2733 and RFC 3009. Because the payload 129 specified in this document is signaled by different MIME from those 130 of RFC 3009, there is no concern of mis-identification of different 131 parity FEC version in capacity exchange. For parity FEC specified 132 here and in RFC 2733 and RFC 3009, the payload data are un-altered 133 and additional FEC data are sent along to protect the payload data. 134 Hence the communication of the payload data would flow without 135 problem between hosts of different parity FEC versions and hosts 136 that did not implement parity FEC. The receiving hosts with 137 incompatible FEC from the sending host would not be able to benefit 138 from the additional FEC data, so it is recommended that existing 139 host implementing RFC 2733 and RFC 3009 should be updated to follow 140 this specification when possible. 142 This document defines a payload format for RTP [1] which allows for 143 generic forward error correction of real time media. In this 144 context, generic means that the FEC protocol is (1) independent of 145 the nature of the media being protected, be it audio, video, or 146 otherwise, (2) flexible enough to support a wide variety of FEC 147 configurations, (3) designed for adaptivity so that the FEC 148 technique can be modified easily without out-of-band signaling, and 149 (4) supportive of a number of different mechanisms for transporting 150 the FEC packets. 152 Furthermore, in many scenarios the bandwidth of the network 153 connections is a very limited resource. On the other hand, most of 154 traditional FEC schemes are not designed for optimal utilization of 155 the limited bandwidth resource. An often used improvement is unequal 157 I-Draft RTP Payload Format for Generic FEC August 2, 2007 159 error protection that provides different levels of protection for 160 different parts of the data stream which vary in importance. The 161 unequal error protection schemes can usually make more efficient use 162 of bandwidth to provide better overall protection of the data stream 163 against the loss. Proper protocol support is essential for realizing 164 these unequal error protection mechanisms. The application of most 165 of the unequal error protection schemes requires having the 166 knowledge of the importance for different parts of the data stream. 167 For that reason, most of such schemes are designed for particular 168 types of media according to the structure of the media protected, 169 and as a result, are not generic. 171 The FEC algorithm and protocol are defined in this document for 172 generic forward error correction with unequal error protection for 173 real-time media. The particular algorithm defined here is called the 174 Uneven Level Protection (ULP). The payload data are protected by one 175 or more protection levels. Lower protection levels can provide 176 greater protection by using smaller group sizes (compared to higher 177 protection levels) for generating the FEC packet. As we will discuss 178 below, audio/video applications would generally benefit from unequal 179 error protection schemes that give more protection to the beginning 180 part of each packet such as ULP. The data that are closer to the 181 beginning of the packet are in general more important and tend to 182 carry more information than the data further behind in the packet. 184 It is well known that in many multimedia streams the more important 185 parts of the data are always at the beginning of the data packet. 186 This is the common practice in codec design since the beginning of 187 the packet is closer to the re-synchronization marker at the header 188 and thus is more likely to be correctly decoded. In additional, 189 almost all media formats have the frame headers at the beginning of 190 the packet, which is the most vital part of the packet. 192 For video streams, most modern formats have optional data 193 partitioning modes to improve error resilience in which the video 194 macroblock header data, the motion vector data, and DCT coefficient 195 data are separated into their individual partitions. For example, in 196 ITU-T H.263 version 3, there is the optional data partitioned syntax 197 of Annex V. In MPEG-4 Visual Simple Profile, there is the optional 198 data partitioning mode. When these modes are enabled, the video 199 macroblock (MB) header and motion vector partitions (which are much 200 more important to the quality of the video reconstruction) are 201 transmitted in the partition(s) at the beginning of the video packet 202 while residue DCT coefficient partitions (which are less important) 203 are transmitted in the partition close to the end of the packet. 204 Because the data is arranged in descending order of importance, it 205 would be beneficial to provide more protection to the beginning part 206 of the packet in transmission. 208 For audio streams, the bitstreams generated by many of the new audio 209 codecs also contain data with different classes of importance. These 210 different classes are then transmitted in order of descending 212 I-Draft RTP Payload Format for Generic FEC August 2, 2007 214 importance. Applying more protection to the beginning of the packet 215 would also be beneficial in these cases. Even for uniform- 216 significance audio streams, various time shifting and stretching 217 techniques can be applied to the partially recovered audio data 218 packets. 220 Audio/video applications would generally benefit from the FEC 221 algorithms specified in this document. With ULP, the efficiency of 222 the protection of the media payload can potentially be further 223 improved. This document specifies the protocol and algorithm for 224 applying the generic FEC to the RTP media payloads. 226 2. Terminology 228 The following terms are used throughout this document: 230 Media Payload: The raw, un-protected user data that are transmitted 231 from the sender. The media payload is placed inside of an RTP 232 packet. 234 Media Header: The RTP header for the packet containing the media 235 payload. 237 Media Packet: The combination of a media payload and media header is 238 called a media packet. 240 FEC Packet: The FEC algorithms at the transmitter take the media 241 packets as an input. They output both the media packets that they 242 are passed, and newly generated packets called FEC packets, which 243 contain redundant media data used for error correction. The FEC 244 packets are formatted according to the rules specified in this 245 document. 247 FEC Header: The header information contained in an FEC packet. 249 FEC Level Header: The header information contained in an FEC packet 250 for each level. 252 FEC Payload: The payload of an FEC packet. It may be divided into 253 multiple levels. 255 Associated: A FEC packet is said to be "associated" with one or more 256 media packets (or vice versa) when those media packets are used to 257 generate the FEC packet (by use of the exclusive-or operation). It 258 refers to only those packets used to generate the Level 0 FEC 259 payload, if not explicitly stated otherwise. 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in RFC 2119 [2]. 265 I-Draft RTP Payload Format for Generic FEC August 2, 2007 267 3. Basic Operation 269 The payload format described here is used when the sender in an RTP 270 session would like to protect the media stream it is sending with 271 generic parity FEC. The FEC supported by this format is based on 272 simple exclusive-or (XOR) parities operation. The sender takes the 273 packets from the media stream requiring protection and determines 274 the protection levels for these packets and the protection length 275 for each level. The data are grouped together as described below in 276 Section 7. XOR operation is applied across the payload to generate 277 the FEC information. The result following the procedures defined 278 here are RTP packets containing FEC information. These packets can 279 be used at the receiver to recover the packets or parts of the 280 packets used to generate the FEC information. 282 The payload format for FEC contains information that allows the 283 sender to tell the receiver exactly which media packets are 284 protected by the FEC packet, and the protection levels and lengths 285 for each of the levels. Specifically, each FEC packet contains an 286 offset mask m(k) for each protection level k. If the bit i in the 287 mask m(k) is set to 1, then media packet number N + i is protected 288 by this FEC packet at level k. N is called the sequence number base, 289 and is sent in the FEC packet as well. The amount of data that are 290 protected at level k is indicated by L(k), which is also sent in the 291 FEC packet. The protection length, offset mask, payload type, and 292 sequence number base fully identify the parity code applied to 293 generate the FEC packet with little overhead. A set of rules is 294 described in Section 7.4 that defines how the mask should be set for 295 different protection levels, with examples in Section 10. 297 This document also describes procedures on transmitting all the 298 protection operation parameters in-band. This allows the sender 299 great flexibility; the sender can adapt the protection to current 300 network conditions and be certain the receivers can still make use 301 of the FEC for recovery. 303 At the receiver, both the FEC and original media are received. If no 304 media packets are lost, the FEC packets can be ignored. In the event 305 of a loss, the FEC packets can be combined with other received media 306 to recover all or part of the missing media packets. 308 4. Parity Codes 310 For brevity, we define the function f(x,y,..) to be the XOR (parity) 311 operator applied to the data blocks x,y,... The output of this 312 function is another block, called the parity block. For simplicity, 313 we assume here that the parity block is computed as the bitwise XOR 314 of the input blocks. The exact procedure is specified in Section 8. 316 I-Draft RTP Payload Format for Generic FEC August 2, 2007 318 Protection of data blocks using parity codes is accomplished by 319 generating one or more parity blocks over a group of data blocks. To 320 be most effective, the parity blocks must be generated by linearly 321 independent combinations of data blocks. The particular combination 322 is called a parity code. The payload format uses XOR parity codes. 324 For example, consider a parity code which generates a single parity 325 block over two data blocks. If the original media packets are 326 a,b,c,d, the packets generated by the sender are: 328 a b c d <-- media stream 329 f(a,b) f(c,d) <-- FEC stream 331 where time increases to the right. In this example, the error 332 correction scheme (we use the terms scheme and code interchangeably) 333 introduces a 50% overhead. But if b is lost, a and f(a,b) can be 334 used to recover b. 336 It may be useful to point out that there are many other types of 337 forward error correction codes that can also be used to protect the 338 payload besides the XOR parity code. One notable example is Reed- 339 Solomon code, and there are many others [12]. However, XOR parity 340 code is used here because of its effectiveness and simplicity in 341 both protocol design and implementation. This is particularly 342 important for implementation in nodes with limited resources. 344 5. Uneven Level Protection (ULP) 346 As we can see from the simple example above, the protection on the 347 data depends on the size of the group. In the above example, the 348 group size is 2. So if any one of the three packets (two payload 349 packets and one FEC packet) is lost, the original payload data can 350 still be recovered. 352 In general, the FEC protection operation is a trade off between the 353 bandwidth and the protection strength. The more FEC packets that are 354 generated as a fraction of the source media packets, the stronger 355 the protection against loss but the greater the bandwidth consumed 356 by the combined stream. 358 As is the common case in most of the media payload, not all the 359 parts of the packets are of the same importance. Using this 360 property, one can potentially achieve more efficient use of the 361 channel bandwidth using unequal error protection, i.e., applying 362 different protection for different parts of the packet. More 363 bandwidth is spent on protecting the more important parts, while 364 less bandwidth on the less important parts. 366 The packets are separated into sections of decreasing importance, 367 and protection of different strength is applied to each portion - 368 the sections are known as "levels". The protection operation is 370 I-Draft RTP Payload Format for Generic FEC August 2, 2007 372 applied independently at each level. A single FEC packet can carry 373 parity data for multiple levels. This algorithm is called uneven 374 level protection, or ULP. 376 The protection of ULP is illustrated in Figure 1 below. In this 377 example, two ULP FEC packets are protecting four payload packets. 379 ULP FEC packet #1 has only one level which protects packet A and B. 380 In stead of applying parity operation to the entire packet of A and 381 B, it only protects a length of data of both packets. The length, 382 which can be chosen and changed dynamically during a session, is 383 called the protection length. 385 ULP FEC packet #2 has two protection levels. The Level 0 protection 386 is the same as for ULP FEC packet #1 except that it is operating on 387 packet C and D. The Level 1 protection is using parity operation 388 applied on data from packets A, B, C, and D. Note that Level 1 389 protection operates on a different set of packets from Level 0 and 390 has a different protection length from Level 0, so are any other 391 levels. Those information are all conveyed in-band through the 392 protocols specified in this document. 394 Packet A ##################### 395 : : 396 Packet B ############### : 397 : : 398 ULP FEC Packet #1 @@@@@@@@ : 399 : : 400 Packet C ########### : 401 : : 402 Packet D ################################### 403 : : 404 ULP FEC Packet #2 @@@@@@@@@@@@@@@@@ 405 : : : 406 :<-L0->:<--L1-->: 408 Figure 1: Unequal Level Protection 410 As we have discussed in the introduction, media streams usually have 411 the more important parts at the beginning of the packet. It is 412 usually useful to have the stronger protection in the levels closer 413 to the beginning of the packet, and weaker protection in the levels 414 further back. ULP algorithm provides such FEC protection. 416 ULP FEC not only provides more protection to the beginning of the 417 packet (which are more important), it also avoids as much as 418 possible the less-efficient scenarios that a earlier section of a 419 packet is unrecoverable while a later section can be recovered (and 420 often has to be discarded). 422 I-Draft RTP Payload Format for Generic FEC August 2, 2007 424 6. RTP Media Packet Structure 426 The formatting of the media packets is unaffected by FEC. If the FEC 427 is sent as a separate stream, the media packets are sent as if there 428 was no FEC. 430 This approach has the advantage that media packets can be 431 interpreted by receivers which do not support FEC. This 432 compatibility with non-FEC capable receivers is particularly useful 433 in the multicast scenarios. The overhead for using the FEC scheme is 434 only present in FEC packets, and can be easily monitored and 435 adjusted by tracking the amount of FEC in use. 437 7. FEC Packet Structure 439 7.1. Packet Structure 441 A FEC packet is constructed by placing an FEC header and one or more 442 levels of FEC header and payload into the RTP payload, as shown in 443 Figure 2: 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | RTP Header (12 octets or more) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | FEC Header (10 octets) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | FEC Level 0 Header | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | FEC Level 0 Payload | 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | FEC Level 1 Header | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | FEC Level 1 Payload | 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Cont. | 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 2: FEC Packet Structure 466 7.2. RTP Header for FEC Packets 468 The RTP header for FEC packets is only used when the FEC are sent in 469 a separate stream from the protected payload stream (as defined in 470 Section 14). Hence much of the discussion below applies only to that 471 scenario. All the fields in the RTP header of FEC packets are used 473 I-Draft RTP Payload Format for Generic FEC August 2, 2007 475 according to RFC 3550 [1], with some of them further clarified 476 below. 478 Marker: This field is not used for this payload type, and SHALL be 479 set to 0. 481 SSRC: The SSRC value SHALL be the same as the SSRC value of the 482 media stream it protects. 484 Sequence number: The sequence number has the standard definition - 485 it MUST be one higher than the sequence number in the previously 486 transmitted FEC packet. 488 Timestamp: The timestamp MUST be set to the value of the media RTP 489 clock at the instant the FEC packet is transmitted. Thus, the TS 490 value in FEC packets is always monotonically increasing. 492 Payload type: The payload type for the FEC packets is determined 493 through dynamic, out-of-band means. According to RFC 3550 [1], RTP 494 participants that cannot recognize a payload type must discard it. 495 This provides backwards compatibility. The FEC mechanisms can then 496 be used in a multicast group with mixed FEC-capable and FEC- 497 incapable receivers, particularly when the FEC protection is sent as 498 redundant encoding (see Section 14). In such cases, the FEC 499 protection will have a payload type which is not recognized by the 500 FEC-incapable receivers, and will thus be disregarded. 502 7.3. FEC Header for FEC Packets 504 The FEC header is 10 octets. The format of the header is shown in 505 Figure 3 and consists of extension flag (E bit), long-mask flag (L 506 bit), P recovery field, X recovery field, CC recovery field, M 507 recovery field, PT recovery field, SN base field, TS recovery field, 508 and length recovery field. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |E|L|P|X| CC |M| PT recovery | SN base | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | TS recovery | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | length recovery | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 3: FEC Header Format 522 The E bit is the extension flag reserved to indicate any future 523 extension to this specification. It SHALL be set to 0, and SHOULD be 524 ignored by the receiver. 526 I-Draft RTP Payload Format for Generic FEC August 2, 2007 528 The L bit indicates whether the long mask is used. When the L bit is 529 not set, the mask is 16-bit long. When the L bit is set, the mask is 530 then 48-bit long. 532 The P recovery field, the X recovery field, the CC recovery field, 533 the M recovery field, and the PT recovery field are obtained via the 534 protection operation applied to the corresponding P, X, CC, M, and 535 PT values from the RTP header of the media packets associated with 536 the FEC packet. 538 The SN base field MUST be set to the lowest sequence number, taking 539 wrap around into account, of those media packets protected by FEC 540 (at all levels). This allows for the FEC operation to extend over 541 any string of at most 16 packets when the L field is set to 0, or 48 542 packets when the L field is set to 1, and so on. 544 The TS recovery field is computed via the protection operation 545 applied to the timestamps of the media packets associated with this 546 FEC packet. This allows the timestamp to be completely recovered. 548 The length recovery field is used to determine the length of any 549 recovered packets. It is computed via the protection operation 550 applied to the unsigned network-ordered 16 bit representation of the 551 sums of the lengths (in bytes) of the media payload, CSRC list, 552 extension and padding of each of the media packets associated with 553 this FEC packet (in other words, the CSRC list, RTP extension, and 554 padding of the media payload packets, if present, are "counted" as 555 part of the payload). This allows the FEC procedure to be applied 556 even when the lengths of the protected media packets are not 557 identical. For example, assume an FEC packet is being generated by 558 xor'ing two media packets together. The length of the payload of two 559 media packets are 3 (0b011) and 5 (0b101) bytes, respectively. The 560 length recovery field is then encoded as 0b011 xor 0b101 = 0b110. 562 7.4. FEC Level Header for FEC Packets 564 The FEC Level Header is 4 or 8 octets (depending on the L bit in the 565 FEC header). The formats of the headers are shown in Figure 4. 567 The FEC Level Headers consist of a Protection Length field and a 568 mask field. The protection length field is 16-bit long. The mask 569 field is 16-bit long (when the L bit is not set) or 48-bit long 570 (when the L bit is set). 572 The mask field in the FEC Level Header indicates which packets are 573 associated with the FEC packet at the current level. It is either 16 574 or 48 bits depending on the value of the L bit. If bit i in the mask 575 is set to 1, then the media packet with sequence number N + i is 576 associated with this FEC packet, where N is the SN Base field in the 577 FEC packet header. The most significant bit of the mask corresponds 579 I-Draft RTP Payload Format for Generic FEC August 2, 2007 581 to i=0, and the least significant to i=15 when the L bit is set to 582 0, or i=47 when the L bit is set to 1. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Protection Length | mask | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | mask cont. (present only when L = 1) | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 4: ULP Level Header Format 594 The setting of mask field shall follow the following rules: 596 a. A media packet SHALL be protected only once at each 597 protection level higher than level 0. A media packet MAY be 598 protected more than once at level 0 by different packets, 599 providing the protection lengths of level 0 of these packets 600 are equal. 602 b. For a media packet to be protected at level p, it MUST also 603 be protect at level p-1 in any FEC packets. Please note that 604 the protection level p for a media packet can be in a FEC 605 packet that is different from the one which contains 606 protection level p-1 for the same media packet. 608 c. If an ULP FEC packet contains protection at level p, it MUST 609 also contain protection at level p-1. Note that the 610 combination of payload packets that are protected in level p 611 may be different from those of level p-1. 613 The rationale for rule (a) is that multiple protection increases the 614 complexity of the recovery implementation. At higher levels, the 615 multiple protection offers diminishing benefit, so its application 616 is restricted to level 0 for simpler implementation. The rationale 617 for rule (b) is that the protection offset (for each associated 618 packet) are not explicitly signaled in the protocol. With this 619 restriction, the offset can be easily deducted from protection 620 lengths of the levels. The rationale of rule (c) is that the level 621 of protection is not explicitly indicated. This rule is set to 622 implicitly specify the levels. 624 One example of the protection combinations is illustrated in Figure 625 5 below. It is the same example as shown in Figure 1. This same 626 example is also shown in more detail in Section 10.2 to illustrate 627 how the fields in the headers are set. 629 I-Draft RTP Payload Format for Generic FEC August 2, 2007 631 Packet A ##################### 632 : : 633 Packet B ############### : 634 : : 635 ULP FEC Packet #1 @@@@@@@@ : 636 : : 637 Packet C ########### : 638 : : 639 Packet D ################################### 640 : : 641 ULP FEC Packet #2 @@@@@@@@@@@@@@@@@ 642 : : : 643 :<-L0->:<--L1-->: 645 Payload Packet # | ULP FEC packet which protects at level 646 | L0 L1 647 ---------------------+--------------------------------------- 648 A | #1 #2 649 B | #1 #2 650 C | #2 #2 651 D | #2 #2 653 Figure 5: An example of protection combination 655 In this example, ULP FEC packet #1 only have protection level 0. ULP 656 FEC packet #1 has protection level 0 and 1. Read across the table, 657 it is shown that payload packet A is protected by ULP FEC packet #1 658 at level 0, by ULP FEC packet #2 at level 1, and so on. Also, it can 659 be easily seen from the table that ULP FEC packet #2 protects at 660 level 0 payload packets C and D, at level 1 payload packets A-D, and 661 so on. For additional examples with more details, please refer to 662 Section 10 Examples. 664 The payload of the ULP FEC packets of each level is the protection 665 operation (XOR) applied to the media payload and padding of the 666 media packets associated with the ULP FEC packet at that level. 667 Details are described in the next section on the protection 668 operation. 670 The size of the ULP FEC packets are determined by the protection 671 lengths chosen for the protection operation. In the above example, 672 the ULP FEC packet #1 has length L0 (plus the header overhead). The 673 ULP FEC packet #2 with two levels has length L0+L1 (plus the header 674 overhead). It is longer than some of the packets it protects (packet 675 B and D in this example), and is shorter than some of the packets it 676 protects (packet A and D in this example). 678 Note that it's possible for the FEC packet (non-ULP and ULP) to be 679 larger than the longest media packets it protects because of the 680 overhead from the headers and/or if a large protection length is 681 chosen for ULP. This could cause difficulties if this results in the 683 I-Draft RTP Payload Format for Generic FEC August 2, 2007 685 FEC packet exceeding the Maximum Transmission Unit size for the path 686 along which it is sent. 688 8. Protection Operation 690 FEC packets are formed from an "FEC bit string" which is generated 691 from the data of the protected media RTP packets. More specifically, 692 the FEC bit string is the bitwise exclusive OR of the "protected bit 693 strings" of the protected media RTP packets. 695 The following procedure MAY be followed for the protection 696 operation. Other procedures MAY be used, but the end result MUST be 697 identical to the one described here. 699 8.1. Generation of the FEC Header 701 In the case of FEC header, the protected bit strings (80 bits in 702 length) are generated for each media packet to be protected at FEC 703 Level 0. It is formed by concatenating the following fields together 704 in the order specified: 706 o The first 64 bits of the RTP header (64 bits) 708 o Unsigned network-ordered 16 bit representation of the media 709 packet length in bytes minus 12 (for the fixed RTP header), 710 i.e., the sum of the lengths of all the following if present: 711 the CSRC List, extension header, RTP payload, and RTP padding 712 (16 bits) 714 After the FEC bit string is formed from applying parity operation on 715 the protected bit strings, the FEC header is generated from the FEC 716 bit string as following: 718 The first (most significant) two bits in the FEC bit string are 719 skipped. The next bit in the FEC bit string is written into the P 720 recovery bit of the FEC header in the FEC packet. The next bit in 721 the FEC bit string is written into the E recovery bit of the FEC 722 header. The next four bits of the FEC bit string are written into 723 the CC recovery field of the FEC header. The next bit is written 724 into the M recovery bit of the FEC header. The next 7 bits of the 725 FEC bit string are written into the PT recovery field in the FEC 726 header. The next 16 bits are skipped. The next 32 bits of the FEC 727 bit string are written into the TS recovery field in the FEC header. 728 The next 16 bits are written into the length recovery field in the 729 packet header. 731 8.2. Generation of the FEC Payload 733 For generation of the FEC payload, the protected bit strings are 734 simply the protected RTP packets. The FEC bit string is thus the 735 bitwise exclusive OR of these protected media RTP packets. Such FEC 737 I-Draft RTP Payload Format for Generic FEC August 2, 2007 739 bit strings need to be generated for each level, as the group of 740 protected payload packets may be different for each level. If the 741 lengths of the protected RTP packets are not equal, each shorter 742 packet MUST be padded to the length of the longest packet by adding 743 octet 0 at the end. 745 For Protection Level n (n = 0, 1, ...), only Ln octets of data are 746 set as the FEC Level n payload data after the Level n ULP header. 747 The data is the Ln octets of data starting with the (Sn + 13)th 748 octet in the FEC bit string, where: 750 Sn = sum(Li : 0 <= i < n). 752 Li is the Protection Length of Level i, and S0 is defined to be 0. 753 The reason for omitting the first 12 octets is that those 754 information are protected by the FEC header already. 756 9. Recovery Procedures 758 The FEC packets allow end systems to recover from the loss of media 759 packets. This section describes the procedure for performing this 760 recovery. 762 Recovery requires two distinct operations. The first determines 763 which packets (media and FEC) must be combined in order to recover a 764 missing packet. Once this is done, the second step is to actually 765 reconstruct the data. The second step MUST be performed as described 766 below. The first step MAY be based on any algorithm chosen by the 767 implementer. Different algorithms result in a tradeoff between 768 complexity and the ability to recover missing packets, if possible. 770 The lost payload packets may be recovered in full or in parts 771 depending on the data lose situation due to the nature of unequal 772 error protection (when it is used). The partial recovery of the 773 packet can be detected by checking the recovery length of the packet 774 retrieved from the FEC header against the actual length of the 775 recovered payload data. 777 9.1. Reconstruction of the RTP Header 779 Let T be the list of packets (FEC and media) which can be combined 780 to recover some media packet xi at level 0. The procedure is as 781 follows: 783 1. For the media packets in T, compute the first 80 bits of the 784 protected bit string following the procedure as described for 785 generating FEC header in the previous section. 787 2. For the FEC packet in T, the FEC bit string is the 80-bit FEC 788 header. 790 I-Draft RTP Payload Format for Generic FEC August 2, 2007 792 3. Calculate the recovery bit string as the bitwise exclusive OR 793 of the protected bit string generated from all the media 794 packets in T and the FEC bit string generated from all the 795 FEC packets in T. 797 4. Create a new packet with the standard 12 byte RTP header and 798 no payload. 800 5. Set the version of the new packet to 2. Skip the first two 801 bits in the recovery bit string. 803 6. Set the Padding bit in the new packet to the next bit in the 804 recovery bit string. 806 7. Set the Extension bit in the new packet to the next bit in 807 the recovery bit string. 809 8. Set the CC field to the next four bits in the recovery bit 810 string. 812 9. Set the marker bit in the new packet to the next bit in the 813 recovery bit string. 815 10. Set the payload type in the new packet to the next 7 bits in 816 the recovery bit string. 818 11. Set the SN field in the new packet to xi. Skip the next 16 819 bits in the recovery bit string. 821 12. Set the TS field in the new packet to the next 32 bits in the 822 recovery bit string. 824 13. Take the next 16 bits of the recovery bit string. Whatever 825 unsigned integer this represents (assuming network-order), 826 take that many bytes from the recovery bit string and append 827 them to the new packet. This represents the CSRC list, 828 extension, payload, and the padding of the RTP payload. 830 14. Set the SSRC of the new packet to the SSRC of the media 831 stream it's protecting, i.e., the SSRC of the media stream to 832 which the FEC stream is associated with. 834 This procedure will recover the header of an RTP packet up to the 835 SSRC field. 837 9.2. Reconstruction of the RTP Payload 839 Let T be the list of packets (FEC and media) which can be combined 840 to recover some media packet xi at certain protection level. The 841 procedure is as follows: 843 I-Draft RTP Payload Format for Generic FEC August 2, 2007 845 1. Assume that we are reconstructing the data for level n, the 846 first step is to get the Protection Length of Level n (Ln) 847 from the ULP Header of Level n. 849 2. For the FEC packets in T, the FEC bit string of Level n is 850 FEC Level n Payload, i.e., the Ln octets of data following 851 the ULP Header of Level n. 853 3. For the media packets in T, the protected bit string of Level 854 n is Ln octets of data starting with the (Sn + 13)th octet of 855 the packet. Sn is the same as defined previously in this 856 section. Note that the protection of Level 0 starts from the 857 13th octet of the media packet after the SSRC field. The 858 information of the first 12 octets are protected by the FEC 859 header. 861 4. If any of the protected bit strings of Level n generated from 862 the media packets are shorter than the Protection Length of 863 the current level, pad them to that length. The padding of 864 octet 0 MUST be added at the end of the bit string. 866 5. Calculate the recovery bit string as the bitwise exclusive OR 867 of the protected bit string of Level n generated from all the 868 media packets in T and the FEC bit string of Level n 869 generated from all the FEC packets in T. 871 6. The recovery bit string of the current protection level as 872 generated above is combined through concatenation with the 873 recovery bit string of all the other levels to form the 874 (fully or partially) recovered media packet. Note that the 875 recovery bit string of each protection level MUST be placed 876 at the correct location in the recovered media packet for 877 that level based on protection length settings. 879 7. The total length of the recovered media packet is recovered 880 from the recovery operation at protection level 0 of the 881 recovered media packet. This information can be used to check 882 if the complete recovery operation (of all levels) has 883 recovered the packet to its full length. 885 The data protected at lower protection level is recoverable in 886 majority of the cases if the higher level protected data is 887 recoverable. This procedure (together with the procedure for the 888 lower protection levels) will usually recover both the header and 889 payload of an RTP packet up to the Protection Length of the current 890 level. 892 10. Examples 894 In the first two examples considered below (Section 10.1, and 10.2), 895 we assume the FEC streams are sent through a separate RTP session as 897 I-Draft RTP Payload Format for Generic FEC August 2, 2007 899 described in Section 14.1. For these examples we assume that 4 media 900 packets are to be sent, A, B, C and D, from SSRC 2. Their sequence 901 numbers are 8, 9, 10 and 11, respectively, and have timestamps of 3, 902 5, 7 and 9, respectively. Packet A and C uses payload type 11, and 903 packet B and D uses payload type 18. Packet A has 200 bytes of 904 payload, packet B 140, packet C 100 and packet D 340. Packet A and C 905 have their marker bit set. 907 The third example (Section 10.3) is to illustrate when the FEC data 908 is sent as redundant data with the payload packets. 910 10.1. An Example Offers Similar Protection As RFC 2733 912 We can protect the four payload packet to their full length in one 913 single level with one FEC packet. This offers similar protection as 914 RFC 2733. The scheme is as shown in Figure 6. 916 +-------------------+ : 917 Packet A | | : 918 +-------------+-----+ : 919 Packet B | | : 920 +---------+---+ : 921 Packet C | | : 922 +---------+-----------------------+ 923 Packet D | | 924 +---------------------------------+ 925 : 926 +---------------------------------+ 927 Packet FEC | | 928 +---------------------------------+ 929 : : 930 :<------------- L0 -------------->: 932 Figure 6: FEC scheme with single level protection 934 An FEC packet is generated from these four packets. We assume that 935 payload type 127 is used to indicate an FEC packet. The resulting 936 RTP header is shown in Figure 7. 938 The FEC header in the FEC packet is shown in Figure 8. 940 The FEC Level Header for Level 0 is shown in Figure 9. 942 I-Draft RTP Payload Format for Generic FEC August 2, 2007 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 |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| 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 |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| 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 |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| 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Version: 2 955 Padding: 0 956 Extension: 0 957 Marker: 0 958 PT: 127 959 SN: 1 960 TS: 9 961 SSRC: 2 963 Figure 7: RTP Header of FEC Packet 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 |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| 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 |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| 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 |0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0| 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 E: 0 [this specification] 976 L: 0 [short 16-bit mask] 977 P rec.: 0 [0 XOR 0 XOR 0 XOR 0] 978 X rec.: 0 [0 XOR 0 XOR 0 XOR 0] 979 CC rec.: 0 [0 XOR 0 XOR 0 XOR 0] 980 M rec.: 0 [1 XOR 0 XOR 1 XOR 0] 981 PT rec.: 0 [11 XOR 18 XOR 11 XOR 18] 982 SN base: 8 [min(8,9,10,11)] 983 TS rec.: 8 [3 XOR 5 XOR 7 XOR 9] 984 len. rec.: 372 [200 XOR 140 XOR 100 XOR 340] 986 Figure 8: FEC Header of FEC Packet 988 I-Draft RTP Payload Format for Generic FEC August 2, 2007 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 |0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0| 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 L0: 340 [the longest of 200, 140, 100, and 340] 997 mask: 61440 [with Bit 1, 2, 3, and 4 marked accordingly for 998 Packet 8, 9, 10, and 11] 1000 The payload length for level 0 is 340 bytes. 1002 Figure 9: FEC Level Header (Level 0) 1004 10.2. An Example With Two Protection Levels 1006 A more complex example is to use FEC at two levels. The level 0 FEC 1007 will provide greater protection to the beginning part of the payload 1008 packets. The level 1 FEC will apply additional protection to the 1009 rest of the packets. This is illustrated in Figure 10. In this 1010 example, we take L0 = 70 and L1 = 90. 1012 +------:--------:---+ 1013 Packet A | : : | 1014 +------:------+-:---+ 1015 Packet B | : | : 1016 +------:--+---+ : 1017 : : 1018 +------+ : 1019 ULP #1 | | : 1020 +------+ : 1021 : : 1022 +------:--+ : 1023 Packet C | : | : 1024 +------:--+-----:-----------------+ 1025 Packet D | : : | 1026 +------:--------:-----------------+ 1027 : : 1028 +------:--------+ 1029 ULP #2 | : | 1030 +------:--------+ 1031 : : : 1032 :<-L0->:<--L1-->: 1034 Figure 10: ULP FEC scheme with protection level 0 and level 1 1036 This will result in two FEC packets - #1 and #2. 1038 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1040 The resulting ULP FEC packet #1 will have the RTP header as shown in 1041 Figure 11. The FEC header for ULP FEC packet #1 will be as shown in 1042 Figure 12. The level 0 ULP header for #1 will be shown in Figure 13. 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 |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| 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 |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| 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 |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| 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 Version: 2 1055 Padding: 0 1056 Extension: 0 1057 Marker: 1 1058 PT: 127 1059 SN: 1 1060 TS: 5 1061 SSRC: 2 1063 Figure 11: RTP Header of FEC Packet #1 1065 0 1 2 3 1066 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 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 |0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 |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| 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 |0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0| 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 E: 0 [this specification] 1076 L: 0 [short 16-bit mask] 1077 P rec.: 0 [0 XOR 0 XOR 0 XOR 0] 1078 X rec.: 0 [0 XOR 0 XOR 0 XOR 0] 1079 CC rec.: 0 [0 XOR 0 XOR 0 XOR 0] 1080 M rec.: 0 [1 XOR 0 XOR 1 XOR 0] 1081 PT rec.: 25 [11 XOR 18] 1082 SN base: 8 [min(8,9)] 1083 TS rec.: 6 [3 XOR 5] 1084 len. rec.: 68 [200 XOR 140] 1086 Figure 12: FEC Header of ULP FEC Packet #1 1088 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 |0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 L0: 70 1097 mask: 49152 [with Bit 1 and 2 marked accordingly for 1098 Packet 8 and 9] 1100 The payload length for level 0 is 70 bytes. 1102 Figure 13: FEC Level Header (Level 0) for FEC Packet #1 1104 The resulting FEC packet #2 will have the RTP header as shown in 1105 Figure 14. The FEC header for FEC packet #2 will be as shown in 1106 Figure 15. The level 0 ULP header for #2 will be shown in Figure 16. 1107 The level 1 ULP header for #2 will be shown in Figure 17. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 |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| 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 |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| 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 |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| 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 Version: 2 1120 Padding: 0 1121 Extension: 0 1122 Marker: 1 1123 PT: 127 1124 SN: 2 1125 TS: 9 1126 SSRC: 2 1128 Figure 14: RTP Header of FEC Packet #2 1130 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1132 0 1 2 3 1133 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 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 |0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 |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 1 0| 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 |0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0| 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 E: 0 [this specification] 1143 L: 0 [short 16-bit mask] 1144 P rec.: 0 [0 XOR 0 XOR 0 XOR 0] 1145 X rec.: 0 [0 XOR 0 XOR 0 XOR 0] 1146 CC rec.: 0 [0 XOR 0 XOR 0 XOR 0] 1147 M rec.: 0 [1 XOR 0 XOR 1 XOR 0] 1148 PT rec.: 25 [11 XOR 18] 1149 SN base: 8 [min(8,9,10,11)] 1150 TS rec.: 14 [7 XOR 9] 1151 len. rec.: 304 [100 XOR 340] 1153 Figure 15: FEC Header of FEC Packet #2 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 |0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0| 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 L0: 70 1162 mask: 12288 [with Bit 3 and 4 marked accordingly for 1163 Packet 10 and 11] 1165 The payload length for level 0 is 70 bytes. 1167 Figure 16: FEC Level Header (Level 0) for FEC Packet #2 1169 0 1 2 3 1170 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 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 |0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0| 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 L1: 90 1176 mask: 61440 [with Bit 1, 2, 3, and 4 marked accordingly for 1177 Packet 8, 9, 10, and 11] 1179 The payload length for level 1 is 90 bytes. 1181 Figure 17: FEC Level Header (Level 1) for FEC Packet #2 1183 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1185 10.3. An Example With FEC As Redundant Coding 1187 This example illustrates FEC sent as redundant coding in the same 1188 stream as the payload. We assume that five media packets are to be 1189 sent, A, B, C, D, and E, from SSRC 2. Their sequence numbers are 8, 1190 9, 10, 11, and 12, respectively, and with timestamps of 3, 5, 7, 9, 1191 and 11, respectively. All the media data are coded with primary 1192 coding (and FEC as redundant coding only protects the primary 1193 coding) and uses payload type 11. Packet A has 200 bytes of payload, 1194 packet B 140, packet C 100, packet D 340, and packet E 160. Packet A 1195 and C have their marker bit set. 1197 The FEC scheme we use will be with one level as illustrated by 1198 Figure 6 in Section 10.1. The protection length L0 = 340 octets. 1200 A redundant coding packetization is used with payload type 100. The 1201 payload type of the FEC is assumed to be 127. The first four RED 1202 packets, RED #1 through RED #4, each contains an individual media 1203 packet, A, B, C, or D, respectively. The FEC data protecting the 1204 media data in the first four media packets is generated. The fifth 1205 packet, RED #5, contains this FEC data as redundant coding along 1206 with media packet E. 1208 RED Packet #1: Media Packet A 1209 RED Packet #2: Media Packet B 1210 RED Packet #3: Media Packet C 1211 RED Packet #4: Media Packet D 1212 RED Packet #5: FEC Packet, Media Packet E 1214 RED packet #1 through #4 will have the structure as shown in Figure 1215 18. The RTP header of the RED packet #1 is as shown in Figure 19, 1216 with all the other RED packets in similar format with corresponding 1217 sequence numbers and time stamps. The primary encoding block header 1218 of the RED packets is as shown in Figure 20. 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | RTP Header (RED) - 6 octets | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Primary Encoding Block Header (RED) - 1 octet | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Media Packet Data | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 Figure 18: RED Packet Structure - Media Data Only 1230 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 |1 0|0|0|0 0 0 0|0|1 1 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 |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| 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 |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| 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 Version: 2 1243 Padding: 0 1244 Extension: 0 1245 Marker: 0 [Even though media packet A has marker set] 1246 PT: 100 [Payload type for RED] 1247 SN: 1 1248 TS: 5 1249 SSRC: 2 1251 Figure 19: RTP Header of RED Packet #1 1253 0 1 2 3 4 5 6 7 1254 +-+-+-+-+-+-+-+-+ 1255 |0|0 0 0 1 0 1 1| 1256 +-+-+-+-+-+-+-+-+ 1258 F bit: 0 [This is the primary coding data] 1259 Block PT: 11 [The payload type of media] 1261 Figure 20: Primary Encoding Block Header 1263 The FEC data is generated not directly from the RED packets, but 1264 from the virtual RTP packets containing the media packet data. Those 1265 virtual RTP packets can be very easily generated from the RED 1266 packets both with or without redundant coding included. The 1267 conversion from RED packets to virtual RTP packets is simply done by 1268 (1) removing any RED block headers and redundant coding data, and 1269 (2) replace the PT in the RTP header with the PT of the primary 1270 coding. Note: In the payload format for redundant coding as 1271 specified by RFC 2198 the marker bit is lost as soon as the primary 1272 coding is carried in the RED packets. So the marker bit can not be 1273 recovered regardless the FEC is used or not. 1275 As mentioned above, RED packet #5 will contain the FEC data (that 1276 protects media packet A, B, C, and D) as well as the data of media 1277 packet E. The structure of RED packet #5 is as illustrated in Figure 1278 21. 1280 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | RTP Header (RED) - 6 octets | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Redundant Encoding Block Header (RED) - 4 octet | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | FEC Packet Data | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Primary Encoding Block Header (RED) - 1 octet | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Media Packet Data | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 Figure 21: RED Packet Structure - With FEC Data 1296 The RTP header of the RED packets with FEC included is the same as 1297 shown in Figure 19, with their corresponding sequence numbers and 1298 time stamps. 1300 In RED packet #5, the redundant encoding block header for the FEC 1301 packet data block is as shown below in Figure 22. It will be 1302 followed by the FEC packet data which, in this case, includes an FEC 1303 header (10 octets as shown in Figure 8), ULP Level 0 header (4 1304 octets as shown in Figure 9) and the ULP Level 0 data (340 octets as 1305 set for Level 0). These are followed by the primary encoding block 1306 that contains the data of media packet E. 1308 0 1 2 3 1309 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 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 |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 1 1 0 0 0 1 0| 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 F bit: 1 [This is the redundant coding data] 1315 Block PT: 127 [The dynamic payload type for FEC] 1316 TS Offset: 0 [The instance at which the FEC data is 1317 transmitted] 1318 Block Len: 354 [FEC header (10 octets) plus ULP Level 0 header 1319 (4 octets) and ULP Level 0 data (340 octets)] 1321 Figure 22: Redundant Encoding Block Header 1323 11. Security Considerations 1325 There are two ways to use FEC with encryption in secure 1326 communications: one way is to apply the FEC on already encrypted 1327 payloads, and the other way is to apply the FEC before the 1328 encryption. The first case is encountered when FEC is needed by a 1329 not trusted node during transmission after the media data is 1331 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1333 encrypted. The second case is encountered when media data is 1334 protected by FEC before transmitted through a secured transport. 1336 Since the protected payload of this FEC are RTP packets, applying 1337 FEC on encrypted payloads is primarily applicable in the case of 1338 secure RTP (SRTP) [13]. Because the FEC applies XOR across the 1339 payload, the FEC packets should be cryptographically as secure as 1340 the original payload. In such cases, additional encryption of the 1341 FEC packets is not necessary. 1343 In the following discussion, it is assumed that the FEC is applied 1344 to the payload before the encryption. The use of FEC has 1345 implications on the usage and changing of keys for encryption. As 1346 the FEC packets do consist of a separate stream, there are a number 1347 of combinations on the usage of encryption. These include: 1349 o The FEC stream may be encrypted, while the media stream is not. 1351 o The media stream may be encrypted, while the FEC stream is not. 1353 o The media stream and FEC stream are both encrypted, but using 1354 the same key. 1356 o The media stream and FEC stream are both encrypted, but using 1357 different keys. 1359 The first three of these would require all application level 1360 signaling protocols used to be aware of the usage of FEC, and to 1361 thus exchange keys and negotiate encryption usage on the media and 1362 FEC streams separately. In the final case, no such additional 1363 mechanisms are needed. The first two cases present a layering 1364 violation, as ULP FEC packets should be treated no differently than 1365 other RTP packets. Encrypting just one stream may also make certain 1366 known-plaintext attacks possible. For these reasons, applications 1367 utilizing encryption SHOULD encrypt both streams, i.e., the last two 1368 options. 1370 Furthermore, because of the encryption may potentially be weakened 1371 by the known relationship between the media payload and FEC data for 1372 certain ciphers, different encryption keys MUST be used for each 1373 stream when the media payload and the FEC data are sent in separate 1374 streams. Note that when SRTP [13] is used for security of the RTP 1375 sessions, different keys for each RTP session is required by the 1376 SRTP specification. 1378 The changing of encryption keys is another crucial issue needs to be 1379 addressed. Consider the case where two packets a and b are sent 1380 along with the FEC packet that protects them. The keys used to 1381 encrypt a and b are different, so which key should be used to decode 1382 the FEC packet? In general, old keys need to be cached, so that when 1383 the keys change for the media stream, the old key can be used until 1384 it is determined that the key has changed for the ULP FEC packets as 1386 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1388 well. Further more, the new key SHOULD be used to encrypt the FEC 1389 packets that are generated from a combination of payload packets 1390 encrypted by the old and new keys. The sender and the receiver need 1391 to define how the encryption is performed and how the keys are used. 1393 Altering the FEC data and packets can have a big impact on the 1394 reconstruction operation. An attack by changing some bits in the FEC 1395 data can have significant effect on the calculation and the recovery 1396 of the payload packets. For example, changing the length recovery 1397 field can result in the recovery of a packet that is too long. Also, 1398 the computational complexity of the recovery can easily be effected 1399 for up to at least one order of magnitude. Depending on the 1400 application scenario, it may be helpful to perform a sanity check on 1401 the received payload and FEC data before performing the recovery 1402 operation and to determine the validity of the recovered data from 1403 the recovery operation before using them. 1405 12. Congestion Considerations 1407 Another issue with the use of FEC is its impact on network 1408 congestion. In many situations, the packet loss in the network is 1409 induced by congestions. In such scenarios, adding FEC when 1410 encountering increasing network losses should be avoided. If it is 1411 used on a widespread basis, this can result in increased congestion 1412 and eventual congestion collapse. The applications may include 1413 stronger protections while at the same time reduce the bandwidth for 1414 the payload packets. In any event, implementations MUST NOT 1415 substantially increase the total amount of bandwidth in use 1416 (including the payload and the FEC) as network losses increase. 1418 The general congestion control considerations for transporting RTP 1419 data apply, see RTP [1] and any applicable RTP profile like AVP 1420 [14]. An additional requirement if best-effort service is being used 1421 is: users of this payload format MUST monitor packet loss to ensure 1422 that the packet loss rate is within acceptable parameters. Packet 1423 loss is considered acceptable if a TCP flow across the same network 1424 path, and experiencing the same network conditions, would achieve an 1425 average throughput, measured on a reasonable timescale, that is not 1426 less than the RTP flow is achieving. This condition can be 1427 satisfied by implementing congestion control mechanisms to adapt the 1428 transmission rate (or the number of layers subscribed for a layered 1429 multicast session), or by arranging for a receiver to leave the 1430 session if the loss rate is unacceptably high. 1432 13. IANA Considerations 1434 Four new media sub-types as described in this section are to be 1435 registered with IANA. This registration is done using the 1436 registration template [3] and following RFC 3555 [4]. 1438 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1440 13.1. Registration of audio/ulpfec 1442 Type name: audio 1444 Subtype name: ulpfec 1446 Required parameters: 1448 rate: The RTP timestamp rate which is used to mark the time of 1449 transmission of the FEC packet in separate stream. In cases 1450 it is sent as redundant data to another stream the rate SHALL 1451 be the same as the primary encoding it is used to protect. 1452 When used in a separate stream the rate SHALL be larger than 1453 1000 Hz to provide sufficient resolution to RTCP operations. 1454 The selected rate MAY be any value above 1000 Hz but is 1455 RECOMMENDED to match the rate of the media this stream 1456 protects. 1458 Optional parameters: 1460 onelevelonly: This specifies whether only one level of FEC 1461 protection is used. The permissible values are 0 and 1. If 1 1462 is signaled, only one level of FEC protection SHALL be used 1463 in the stream. If 0 is signaled, more than one level of FEC 1464 protection MAY be used. If omitted, it has the default value 1465 of 0. 1467 Encoding considerations: This format is framed (see Section 4.8 in 1468 the template document [3]) and contains binary data. 1470 Security considerations: the same security considerations apply to 1471 these media type registrations as to the payloads for them, as 1472 detailed in RFC xxxx. 1474 Interoperability considerations: none 1476 Published specification: RFC xxxx. 1478 Applications which use this media type: Multimedia applications 1479 which seek to improve resiliency to loss by sending additional data 1480 with the media stream. 1482 Additional information: none 1484 Person & email address to contact for further information: 1485 Adam Li adamli@hyervision.com 1486 IETF Audio/Video Transport Working Group 1488 Intended usage: COMMON 1490 Restrictions on usage: This media type depends on RTP framing, and 1491 hence is only defined for transfer via RTP [1]. Transport within 1493 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1495 other framing protocols SHALL NOT be defined as this is a robustness 1496 mechanism for RTP. 1498 Author: 1499 Adam Li adamli@hyervision.com 1501 Change controller: 1502 IETF Audio/Video Transport Working Group delegated from the 1503 IESG. 1505 13.2. Registration of video/ulpfec 1507 Type name: video 1509 Subtype name: ulpfec 1511 Required parameters: 1513 rate: The RTP timestamp rate which is used to mark the time of 1514 transmission of the FEC packet in separate stream. In cases 1515 it is sent as redundant data to another stream the rate SHALL 1516 be the same as the primary encoding it is used to protect. 1517 When used in a separate stream the rate SHALL be larger than 1518 1000 Hz to provide sufficient resolution to RTCP operations. 1519 The selected rate MAY be any value above 1000 Hz but is 1520 RECOMMENDED to match the rate of the media this stream 1521 protects. 1523 Optional parameters: 1525 onelevelonly: This specifies whether only one level of FEC 1526 protection is used. The permissible values are 0 and 1. If 1 1527 is signaled, only one level of FEC protection SHALL be used 1528 in the stream. If 0 is signaled, more than one level of FEC 1529 protection MAY be used. If omitted, it has the default value 1530 of 0. 1532 Encoding considerations: This format is framed (see Section 4.8 in 1533 the template document [3]) and contains binary data. 1535 Security considerations: the same security considerations apply to 1536 these media type registrations as to the payloads for them, as 1537 detailed in RFC xxxx. 1539 Interoperability considerations: none 1541 Published specification: RFC xxxx. 1543 Applications which use this media type: Multimedia applications 1544 which seek to improve resiliency to loss by sending additional data 1545 with the media stream. 1547 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1549 Additional information: none 1551 Person & email address to contact for further information: 1552 Adam Li adamli@hyervision.com 1553 IETF Audio/Video Transport Working Group 1555 Intended usage: COMMON 1557 Restrictions on usage: This media type depends on RTP framing, and 1558 hence is only defined for transfer via RTP [1]. Transport within 1559 other framing protocols SHALL NOT be defined as this is a robustness 1560 mechanism for RTP. 1562 Author: 1563 Adam Li adamli@hyervision.com 1565 Change controller: 1566 IETF Audio/Video Transport Working Group delegated from the 1567 IESG. 1569 13.3. Registration of text/ulpfec 1571 Type name: text 1573 Subtype name: ulpfec 1575 Required parameters: 1577 rate: The RTP timestamp rate which is used to mark the time of 1578 transmission of the FEC packet in separate stream. In cases 1579 it is sent as redundant data to another stream the rate SHALL 1580 be the same as the primary encoding it is used to protect. 1581 When used in a separate stream the rate SHALL be larger than 1582 1000 Hz to provide sufficient resolution to RTCP operations. 1583 The selected rate MAY be any value above 1000 Hz but is 1584 RECOMMENDED to match the rate of the media this stream 1585 protects. 1587 Optional parameters: 1589 onelevelonly: This specifies whether only one level of FEC 1590 protection is used. The permissible values are 0 and 1. If 1 1591 is signaled, only one level of FEC protection SHALL be used 1592 in the stream. If 0 is signaled, more than one level of FEC 1593 protection MAY be used. If omitted, it has the default value 1594 of 0. 1596 Encoding considerations: This format is framed (see Section 4.8 in 1597 the template document [3]) and contains binary data. 1599 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1601 Security considerations: the same security considerations apply to 1602 these media type registrations as to the payloads for them, as 1603 detailed in RFC xxxx. 1605 Interoperability considerations: none 1607 Published specification: RFC xxxx. 1609 Applications which use this media type: Multimedia applications 1610 which seek to improve resiliency to loss by sending additional data 1611 with the media stream. 1613 Additional information: none 1615 Person & email address to contact for further information: 1616 Adam Li adamli@hyervision.com 1617 IETF Audio/Video Transport Working Group 1619 Intended usage: COMMON 1621 Restrictions on usage: This media type depends on RTP framing, and 1622 hence is only defined for transfer via RTP [1]. Transport within 1623 other framing protocols SHALL NOT be defined as this is a robustness 1624 mechanism for RTP. 1626 Author: 1627 Adam Li adamli@hyervision.com 1629 Change controller: 1630 IETF Audio/Video Transport Working Group delegated from the 1631 IESG. 1633 13.4. Registration of application/ulpfec 1635 Type name: application 1637 Subtype name: ulpfec 1639 Required parameters: 1641 rate: The RTP timestamp rate which is used to mark the time of 1642 transmission of the FEC packet in separate stream. In cases 1643 it is sent as redundant data to another stream the rate SHALL 1644 be the same as the primary encoding it is used to protect. 1645 When used in a separate stream the rate SHALL be larger than 1646 1000 Hz to provide sufficient resolution to RTCP operations. 1647 The selected rate MAY be any value above 1000 Hz but is 1648 RECOMMENDED to match the rate of the media this stream 1649 protects. 1651 Optional parameters: 1653 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1655 onelevelonly: This specifies whether only one level of FEC 1656 protection is used. The permissible values are 0 and 1. If 1 1657 is signaled, only one level of FEC protection SHALL be used 1658 in the stream. If 0 is signaled, more than one level of FEC 1659 protection MAY be used. If omitted, it has the default value 1660 of 0. 1662 Encoding considerations: This format is framed (see Section 4.8 in 1663 the template document [3]) and contains binary data. 1665 Security considerations: the same security considerations apply to 1666 these media type registrations as to the payloads for them, as 1667 detailed in RFC xxxx. 1669 Interoperability considerations: none 1671 Published specification: RFC xxxx. 1673 Applications which use this media type: Multimedia applications 1674 which seek to improve resiliency to loss by sending additional data 1675 with the media stream. 1677 Additional information: none 1679 Person & email address to contact for further information: 1680 Adam Li adamli@hyervision.com 1681 IETF Audio/Video Transport Working Group 1683 Intended usage: COMMON 1685 Restrictions on usage: This media type depends on RTP framing, and 1686 hence is only defined for transfer via RTP [1]. Transport within 1687 other framing protocols SHALL NOT be defined as this is a robustness 1688 mechanism for RTP. 1690 Author: 1691 Adam Li adamli@hyervision.com 1693 Change controller: 1694 IETF Audio/Video Transport Working Group delegated from the 1695 IESG. 1697 14. Multiplexing of FEC 1699 The FEC packets can be sent to the receiver along with the protected 1700 payload primarily in one of the two ways: as a separate stream, or 1701 in the same stream as redundant encoding. The configuration options 1702 MUST be indicated out of band. This section also describes how this 1703 can be accomplished using the Session Description Protocol (SDP), 1704 specified in RFC 2327 [8]. 1706 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1708 14.1. FEC as a Separate Stream 1710 When the FEC packets are sent in a separate stream, several pieces 1711 of information must be conveyed: 1713 o The address and port where the FEC is being sent to 1715 o The payload type number for the FEC 1717 o Which media stream the FEC is protecting 1719 There is no static payload type assignment for FEC, so dynamic 1720 payload type numbers MUST be used. The SSRC of the FEC stream MUST 1721 be set to that of the protected payload stream. The association of 1722 the FEC stream with its corresponding stream is done by line 1723 grouping in SDP [5] with the FEC semantics [6] or other external 1724 means. 1726 Following the principles as discussed in Section 5.2 of RFC 3550 1727 [1], multiplexing of the FEC stream and its associated payload 1728 stream is usually provided by the destination transport address 1729 (network address and port number) which is different for each RTP 1730 session. Sending FEC together with the payload in one single RTP 1731 session and multiplex only by SSRC or payload type precludes: (1) 1732 the use of different network paths or network resource allocations 1733 for the payload and the FEC protection data; (2) reception of a 1734 subset of the media if desired, particularly for the hosts which do 1735 not understand FEC; and (3) receiver implementations that use 1736 separate processes for the different media. In additional, 1737 multiplexing FEC with payload data streams will affect the timing 1738 and sequence number space of the original payload stream, which is 1739 usually undesirable. So the FEC stream and the payload stream SHOULD 1740 be sent through two separate RTP session, and multiplexing them by 1741 payload type into one single RTP session SHOULD be avoided. In 1742 additional, the FEC and the payload MUST NOT be multiplexed by SSRC 1743 into one single RTP session since they always have the same SSRC. 1745 Just like any media stream, the port number and the payload type 1746 number for the FEC stream is conveyed in its m line in the SDP. 1747 There is no static payload type assignment for FEC, so dynamic 1748 payload type numbers MUST be used. The binding to the number is 1749 indicated by an rtpmap attribute. The name used in this binding is 1750 "ulpfec". The address that the FEC stream is on is conveyed in its 1751 corresponding c line. 1753 The association relationship between the FEC stream and the payload 1754 stream it protects is conveyed through media line grouping in SDP 1755 (RFC 3388) [5] using FEC semantics (RFC 4756) [6]. The FEC stream 1756 and the protected payload stream forms an FEC group. 1758 The following is an example SDP for FEC application in a multicast 1759 session: 1761 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1763 v=0 1764 o=adam 289083124 289083124 IN IP4 host.example.com 1765 s=ULP FEC Seminar 1766 t=0 0 1767 c=IN IP4 224.2.17.12/127 1768 a=group:FEC 1 2 1769 a=group:FEC 3 4 1770 m=audio 30000 RTP/AVP 0 1771 a=mid:1 1772 m=application 30002 RTP/AVP 100 1773 a=rtpmap:100 ulpfec/8000 1774 a=mid:2 1775 m=video 30004 RTP/AVP 31 1776 a=mid:3 1777 m=application 30004 RTP/AVP 101 1778 c=IN IP4 224.2.17.13/127 1779 a=rtpmap:101 ulpfec/8000 1780 a=mid:4 1782 The presence of two a=group lines in this SDP indicates that there 1783 are two FEC groups. The first FEC group, as indicated by the 1784 "a=group:FEC 1 2" line, consists of stream 1 (an audio stream using 1785 PCM) and stream 2 (the protecting FEC stream). The FEC stream is 1786 sent to the same multicast group and has the same TTL as the audio, 1787 but on a port number two higher. The second FEC group, as indicated 1788 by the "a=group:FEC 3 4" line, consists of stream 3 (an video 1789 stream) and stream 4 (the protecting FEC stream). The FEC stream is 1790 sent to a different multicast address, but has the same port number 1791 (30004) as the payload video stream. 1793 14.2. FEC as Redundant Encoding 1795 When the FEC stream is being sent as a secondary codec in the 1796 redundant encoding format, this must be signaled through SDP. To do 1797 this, the procedures defined in RFC 2198 [7] are used to signal the 1798 use of redundant encoding. The FEC payload type is indicated in the 1799 same fashion as any other secondary codec. The FEC MUST protect only 1800 the main codec, with the payload of FEC engine coming from virtual 1801 RTP packets created from the main codec data. The virtual RTP 1802 packets can be very easily converted from the RFC 2198 packets by 1803 simply (1) removing all the additional headers and the redundant 1804 coding data, and (2) replacing the payload type in the RTP header 1805 with that of the primary codec. Note: In the payload format for 1806 redundant coding as specified by RFC 2198 the marker bit is lost as 1807 soon as the primary coding is carried in the RED packets. So the 1808 marker bit can not be recovered regardless the FEC is used or not. 1810 Because the FEC data (including the ULP header) is sent in the same 1811 packets as the protected payload. The FEC data is associated with 1812 the protected payload by being bundled in the same stream. 1814 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1816 When the FEC stream is sent as a secondary codec in the redundant 1817 encoding format, this can signaled through SDP. To do this, the 1818 procedures defined in RFC 2198 [7] are used to signal the use of 1819 redundant encoding. The FEC payload type is indicated in the same 1820 fashion as any other secondary codec. An rtpmap attribute MUST be 1821 used to indicate a dynamic payload type number for the FEC packets. 1822 The FEC MUST protect only the main codec. 1824 For example: 1826 m=audio 12345 RTP/AVP 121 0 5 100 1827 a=rtpmap:121 red/8000/1 1828 a=rtpmap:100 ulpfec/8000 1829 a=fmtp:121 0/5/100 1831 This SDP indicates that there is a single audio stream, which can 1832 consist of PCM (media format 0) , DVI (media format 5), the 1833 redundant encodings (indicated by media format 121, which is bound 1834 to red through the rtpmap attribute), or FEC (media format 100, 1835 which is bound to ulpfec through the rtpmap attribute). Although the 1836 FEC format is specified as a possible coding for this stream, the 1837 FEC MUST NOT be sent by itself for this stream. Its presence in the 1838 m line is required only because non-primary codecs must be listed 1839 here according to RFC 2198. The fmtp attribute indicates that the 1840 redundant encodings format can be used, with DVI as a secondary 1841 coding and FEC as a tertiary encoding. 1843 14.3. Offer / Answer Consideration 1845 Some considerations are needed when SDP is used for offer / answer 1846 [15] exchange. 1848 The "onelevelonly" parameter is declarative. For streams declared as 1849 sendonly, the value indicates whether only one level of FEC will be 1850 sent. For streams declared as recvonly or sendrecv, the value 1851 indicates what the receiver accepts to receive. 1853 When the FEC is sent as a separate stream and signaled through media 1854 line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) 1855 [6], the offering side MUST implement both RFC 3388 and RFC 4756. 1856 The rules for offer / answer in RFC 3388 and RFC 4756 SHALL be 1857 followed with the below additional consideration. For all offers 1858 with FEC, the answerer MAY refuse the separate FEC session by 1859 setting the port to 0, and remove the "a=group" attribute that 1860 groups that FEC session with the RTP session being protected. If the 1861 answerer accepts the usage of FEC, the answer simply accepts the FEC 1862 RTP session and the grouping in the offer by including the same 1863 grouping in the answer. Note that the rejection of FEC RTP session 1864 does not prevent the media sessions from being accepted and used 1865 without FEC. 1867 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1869 When the FEC stream is sent as a secondary codec in the redundant 1870 encoding format (RFC 2198) [7], the offering side can indicate the 1871 FEC stream as specified in Section 14.2. The answer MAY reject the 1872 FEC stream by removing the payload type for the FEC stream. To 1873 accept the usage of FEC, the answerer must in the answer include the 1874 FEC payload type. Note that in cases the redundancy payload format 1875 [7] is used with FEC as the only secondary codec, when the FEC 1876 stream is rejected the redundant encoding payload type SHOULD also 1877 be removed. 1879 15. Application Statement 1881 This document describes a generic protocol for Forward Error 1882 Correction supporting a wide range of short block parity FEC 1883 algorithms, such as simple and interleaved parity codes. The scheme 1884 is limited to interleaving parity codes over a distance of 48 1885 packets. This FEC algorithm is fully compatible the hosts that are 1886 not FEC-capable. Since the media payload is not altered and the 1887 protection is sent as additional information, the receivers that are 1888 unaware of the generic FEC as specified in this document can simply 1889 ignore the additional FEC information and process the main media 1890 payload. This interoperability is particularly important for 1891 compatibility with existing hosts, and also in the scenario where 1892 many different hosts need to communicate with each other at the same 1893 time, such as during multicast. 1895 The generic FEC algorithm specified in this document is also a 1896 generic protection algorithm with the following features: (1) it is 1897 independent of the nature of the media being protected, whether that 1898 media is audio, video, or otherwise, (2) it is flexible enough to 1899 support a wide variety of FEC mechanisms and settings, (3) it is 1900 designed for adaptivity, so that the FEC parameters can be modified 1901 easily without resorting to out of band signaling, and (4) it 1902 supports a number of different mechanisms for transporting the FEC 1903 packets. 1905 The FEC specified here also provides user with Unequal Error 1906 Protection capabilities. Some other algorithms may also provide the 1907 Unequal Error Protection capabilities thought other means. For 1908 example, an Unequal Erasure Protection (UXP) scheme has been 1909 proposed in the AVT Working Group in "An RTP Payload Format for 1910 Erasure-Resilient Transmission of Progressive Multimedia Streams". 1911 The UXP scheme applies unequal error protection to the media 1912 payloads by interleaving the payload stream to be protected with the 1913 additional redundancy information obtained using Reed-Solomon 1914 operations. 1916 By altering the structure of the protected media payload, the UXP 1917 scheme sacrifices the backward compatibility with terminals that do 1918 not support UXP. This makes it more difficult to apply UXP when 1919 backward compatibility is desired. In the case of ULP, however, the 1921 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1923 media payload remains un-altered and can always be used by the 1924 terminals. The extra protection can simply be ignored if the 1925 receiving terminals do not support ULP. 1927 At the same time, also because the structure of the media payload is 1928 altered in UXP, UXP offers the unique ability to change packet size 1929 independent of the original media payload structure and protection 1930 applied, and is only subject to the protocol overhead constraint. 1931 This property is useful in scenarios when altering the packet size 1932 of the media at transport level is desired. 1934 Because of the interleaving used in UXP, delays will be introduced 1935 at both the encoding and decoding sides. For UXP, all data within a 1936 transmission block need to arrive before encoding can begin, and a 1937 reasonable number of packets must be received before a transmission 1938 block can be decoded. The ULP scheme introduces little delay at the 1939 encoding side. On the decoding side, correctly received packets can 1940 be delivered immediately. Delay is only introduced in ULP when 1941 packet losses occur. 1943 Because UXP is an interleaved scheme, the un-recoverable errors 1944 occurring in data protected by UXP usually result in a number of 1945 corrupted holes in the payload stream. In ULP, on the other hand, 1946 the unrecoverable errors due to packet loss in the bitstream usually 1947 appear as contiguous missing pieces at the end of the packets. 1948 Depending on the encoding of the media payload stream, many 1949 applications may find it easier to parse and extract data from a 1950 packet with only a contiguous piece missing at the end than a packet 1951 with multiple corrupted holes, especially when the holes are not 1952 coincident with the independently decodable fragment boundaries. 1954 The exclusive-or (XOR) parity check operation used by ULP is simpler 1955 and faster than the more complex operations required by Reed-Solomon 1956 codes. This makes ULP more suitable for applications where 1957 computational cost is a constraint. 1959 As discussed above, both the ULP and the UXP schemes apply unequal 1960 error protection to the RTP media stream, but each uses a different 1961 technique. Both schemes have their own unique characteristics, and 1962 each can be applied to scenarios with different requirements. 1964 16. Acknowledgments 1966 The following authors have made significant contributions to this 1967 document: Adam H. Li, Fang Liu, John D. Villasenor, Dong-Seek Park, 1968 Jeong-Hoon, Yung-Lyul Lee, Jonathan D. Rosenberg, and Henning 1969 Schulzrinne. The authors would also like to acknowledge the 1970 suggestions from many people, particularly Stephen Casner, Jay 1971 Fahlen, Cullen Jennings, Colin Perkins, Tao Tian, Matthieu 1972 Tisserand, Jeffery Tseng, Mark Watson, Stephen Wenger, and Magnus 1973 Westerlund. 1975 I-Draft RTP Payload Format for Generic FEC August 2, 2007 1977 17. Bibliography 1979 17.1. Normative References 1981 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1982 a transport protocol for real-time applications," Request for 1983 Comments 3550, Internet Engineering Task Force, July 2003. 1985 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 1986 levels," Request for Comments 2119, Internet Engineering Task Force, 1987 March 1997. 1989 [3] N. Freed, and J. Klensin, "Media Type Specifications and 1990 Registration Procedures", Request for Comments 4288, Internet 1991 Engineering Task Force, December 2005. 1993 [4] S. Casner, "Media type registration of RTP payload formats", 1994 IETF work in Progress. 1996 [5] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media 1997 Lines in the Session Description Protocol (SDP)", Request for 1998 Comments 3388, December 2002. 2000 [6] A. Li, "Forward Error Correction Grouping Semantics in Session 2001 Description Protocol", Request for Comments 4756, Internet 2002 Engineering Task Force, November 2006. 2004 [7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 2005 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for 2006 Redundant Audio Data", Request for Comments 2198, Internet 2007 Engineering Task Force, September 1997. 2009 [8] M. Handley, and V. Jacobson, "SDP: Session Description 2010 Protocol", Request for Comments 2327, Internet Engineering Task 2011 Force, April 1998. 2013 17.2. Informative References 2015 [9] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for 2016 Generic Forward Error Correction," Request for Comments 2733, 2017 Internet Engineering Task Force, December 1999. 2019 [10] C. Perkins and O. Hodson, "Options for repair of streaming 2020 media", Request for Comments 2354, Internet Engineering Task Force, 2021 June 1998. 2023 [11] J. Rosenberg and H. Schulzrine, "Registration of parityfec MIME 2024 types", Request for Comments 3009, Internet Engineering Task Force, 2025 November 2000. 2027 I-Draft RTP Payload Format for Generic FEC August 2, 2007 2029 [12] M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, and J. 2030 Crowcroft, "Forward Error Correction (FEC) Building Block", Request 2031 for Comments 3452, Internet Engineering Task Force, December 2002. 2033 [13] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, "The 2034 Secure Real-time Transport Protocol (SRTP)", Request for Comments 2035 3711, Internet Engineering Task Force, March 2004. 2037 [14] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 2038 Conferences with Minimal Control", Request for Comments 3551, 2039 Internet Engineering Task Force, July 2003. 2041 [15] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with 2042 the Session Description Protocol (SDP)", Request for Comments 3264, 2043 Internet Engineering Task Force, June 2002. 2045 18. Author's Addresses 2047 Adam H. Li 2048 10194 Wateridge Circle #152 2049 San Diego, CA 92121 2050 USA 2051 Phone: +1 858 622 9038 2052 Email: adamli@hyervision.com 2054 I-Draft RTP Payload Format for Generic FEC August 2, 2007 2056 Copyright Statement 2058 Copyright (C) The IETF Trust (2007). 2060 This document is subject to the rights, licenses and 2061 restrictions contained in BCP 78, and except as set forth 2062 therein, the authors retain all their rights. 2064 Disclaimer of Validity 2066 This document and the information contained herein are provided 2067 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2068 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 2069 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 2070 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2071 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2072 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2073 OR FITNESS FOR A PARTICULAR PURPOSE. 2075 The IETF takes no position regarding the validity or scope of 2076 any Intellectual Property Rights or other rights that might be 2077 claimed to pertain to the implementation or use of the 2078 technology described in this document or the extent to which any 2079 license under such rights might or might not be available; nor 2080 does it represent that it has made any independent effort to 2081 identify any such rights. Information on the procedures with 2082 respect to rights in RFC documents can be found in BCP 78 and 2083 BCP 79. 2085 Copies of IPR disclosures made to the IETF Secretariat and any 2086 assurances of licenses to be made available, or the result of an 2087 attempt made to obtain a general license or permission for the 2088 use of such proprietary rights by implementers or users of this 2089 specification can be obtained from the IETF on-line IPR 2090 repository at http://www.ietf.org/ipr. 2092 The IETF invites any interested party to bring to its attention 2093 any copyrights, patents or patent applications, or other 2094 proprietary rights that may cover technology that may be 2095 required to implement this standard. Please address the 2096 information to the IETF at ietf-ipr@ietf.org. 2098 I-Draft RTP Payload Format for Generic FEC August 2, 2007 2100 RFC Editor Considerations 2102 The RFC editor is kindly requested to perform the following 2103 editing to this draft: 2105 - Replace all occurrences of xxxx with the RFC number this 2106 document receives. 2108 - Remove this and the next section "Changes". 2110 Changes 2112 Compared to the previous version of this document, draft-ietf-avt- 2113 ulp-22.txt, the following changes have been made: 2115 (1) In Section 1, further clarified that there is no backward 2116 compatibility issue. 2117 (2) In Section 11, further required that different keys MUST be 2118 used for separate payload and FEC streams. 2120 This Internet-Draft expires February 2, 2008.