idnits 2.17.1 draft-ietf-payload-flexible-fec-scheme-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2015) is 3349 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) == Missing Reference: '16-47' is mentioned on line 505, but not defined == Missing Reference: '48-111' is mentioned on line 508, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1065, but not defined ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) == Outdated reference: A later version (-03) exists of draft-singh-rmcat-adaptive-fec-01 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAYLOAD V. Singh 3 Internet-Draft Aalto University 4 Intended status: Standards Track A. Begen 5 Expires: August 18, 2015 Cisco Systems 6 M. Zanaty 7 Cisco 8 February 14, 2015 10 RTP Payload Format for Non-Interleaved and Interleaved Parity Forward 11 Error Correction (FEC) 12 draft-ietf-payload-flexible-fec-scheme-00 14 Abstract 16 This document defines new RTP payload formats for the Forward Error 17 Correction (FEC) packets that are generated by the non-interleaved 18 and interleaved parity codes from a source media encapsulated in RTP. 19 These parity codes are systematic codes, where a number of repair 20 symbols are generated from a set of source symbols. These repair 21 symbols are sent in a repair flow separate from the source flow that 22 carries the source symbols. The non-interleaved and interleaved 23 parity codes offer a good protection against random and bursty packet 24 losses, respectively, at a cost of decent complexity. The RTP 25 payload formats that are defined in this document address the 26 scalability issues experienced with the earlier specifications 27 including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several 28 improvements. Due to these changes, the new payload formats are not 29 backward compatible with the earlier specifications, but endpoints 30 that do not implement the scheme can still work by simply ignoring 31 the FEC packets. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 18, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Use Cases for 1-D FEC Protection . . . . . . . . . . . . 6 69 1.2. Use Cases for 2-D Parity FEC Protection . . . . . . . . . 7 70 1.3. Overhead Computation . . . . . . . . . . . . . . . . . . 9 71 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 9 72 3. Definitions and Notations . . . . . . . . . . . . . . . . . . 10 73 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 10 77 4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . 10 78 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 79 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 80 5.1.1. Registration of audio/non-interleaved-parityfec . . . 14 81 5.1.2. Registration of video/non-interleaved-parityfec . . . 15 82 5.1.3. Registration of text/non-interleaved-parityfec . . . 17 83 5.1.4. Registration of application/non-interleaved-parityfec 18 84 5.1.5. Registration of audio/interleaved-parityfec . . . . . 19 85 5.1.6. Registration of video/interleaved-parityfec . . . . . 21 86 5.1.7. Registration of text/interleaved-parityfec . . . . . 22 87 5.1.8. Registration of application/interleaved-parityfec . . 23 88 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 25 89 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 25 90 5.2.2. Declarative Considerations . . . . . . . . . . . . . 26 91 6. Protection and Recovery Procedures . . . . . . . . . . . . . 26 92 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26 93 6.2. Repair Packet Construction . . . . . . . . . . . . . . . 26 94 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 28 95 6.3.1. Associating the Source and Repair Packets . . . . . . 28 96 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 30 97 6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 31 98 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC 99 Protection . . . . . . . . . . . . . . . . . . . . . 32 100 7. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 101 7.1. Example SDP for 1-D Parity FEC Protection . . . . . . . . 34 102 7.2. Example SDP for 2-D Parity FEC Protection . . . . . . . . 35 103 8. Congestion Control Considerations . . . . . . . . . . . . . . 35 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 106 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 107 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 108 12.1. draft-ietf-payload-flexible-fec-scheme-00 . . . . . . . 37 109 12.2. draft-singh-payload-1d2d-parity-scheme-00 . . . . . . . 37 110 12.3. draft-ietf-fecframe-1d2d-parity-scheme-00 . . . . . . . 37 111 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 112 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 113 13.2. Informative References . . . . . . . . . . . . . . . . . 38 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 116 1. Introduction 118 This document defines new RTP payload formats for the Forward Error 119 Correction (FEC) that is generated by the non-interleaved and 120 interleaved parity codes from a source media encapsulated in RTP 121 [RFC3550]. The type of the source media protected by these parity 122 codes can be audio, video, text or application. The FEC data are 123 generated according to the media type parameters, which are 124 communicated out-of-band (e.g., in SDP). Furthermore, the 125 associations or relationships between the source and repair flows may 126 be communicated in-band or out-of-band. Situtations where 127 adaptivitiy of FEC parameters is desired, the endpoint can use the 128 in-band mechanism, whereas when the FEC parameters are fixed, the 129 endpoint may prefer to negotiate them out-of-band. 131 Both the non-interleaved and interleaved parity codes use the 132 eXclusive OR (XOR) operation to generate the repair symbols. In a 133 nutshell, the following steps take place: 135 1. The sender determines a set of source packets to be protected by 136 FEC based on the media type parameters. 138 2. The sender applies the XOR operation on the source symbols to 139 generate the required number of repair symbols. 141 3. The sender packetizes the repair symbols and sends the repair 142 packet(s) along with the source packets to the receiver(s) (in 143 different flows). The repair packets may be sent proactively or 144 on-demand. 146 Note that the source and repair packets belong to different source 147 and repair flows, and the sender must provide a way for the receivers 148 to demultiplex them, even in the case they are sent in the same 149 5-tuple (i.e., same source/destination address/port with UDP). This 150 is required to offer backward compatibility for endpoints that do not 151 understand the FEC packets (See Section 4). At the receiver side, if 152 all of the source packets are successfully received, there is no need 153 for FEC recovery and the repair packets are discarded. However, if 154 there are missing source packets, the repair packets can be used to 155 recover the missing information. Figure 1 and Figure 2 describe 156 example block diagrams for the systematic parity FEC encoder and 157 decoder, respectively. 159 +------------+ 160 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 161 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 162 | Encoder | 163 | (Sender) | --> +==+ +==+ 164 +------------+ +==+ +==+ 166 Source Packet: +--+ Repair Packet: +==+ 167 +--+ +==+ 169 Figure 1: Block diagram for systematic parity FEC encoder 171 +------------+ 172 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 173 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 174 | Decoder | 175 +==+ +==+ --> | (Receiver) | 176 +==+ +==+ +------------+ 178 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 179 +--+ +==+ 181 Figure 2: Block diagram for systematic parity FEC decoder 183 In Figure 2, it is clear that the FEC packets have to be received by 184 the endpoint within a certain amount of time for the FEC recovery 185 process to be useful. In this document, we refer to the time that 186 spans a FEC block, which consists of the source packets and the 187 corresponding repair packets, as the repair window. At the receiver 188 side, the FEC decoder should wait at least for the duration of the 189 repair window after getting the first packet in a FEC block, to allow 190 all the repair packets to arrive. (The waiting time can be adjusted 191 if there are missing packets at the beginning of the FEC block.) The 192 FEC decoder can start decoding the already received packets sooner; 193 however, it should not register a FEC decoding failure until it waits 194 at least for the duration of the repair window. 196 Suppose that we have a group of D x L source packets that have 197 sequence numbers starting from 1 running to D x L, and a repair 198 packet is generated by applying the XOR operation to every L 199 consecutive packets as sketched in Figure 3. This process is 200 referred to as 1-D non-interleaved FEC protection. As a result of 201 this process, D repair packets are generated, which we refer to as 202 non-interleaved (or row) FEC packets. 204 +--------------------------------------------------+ --- +===+ 205 | S_1 S_2 S3 ... S_L | + |XOR| = |R_1| 206 +--------------------------------------------------+ --- +===+ 207 +--------------------------------------------------+ --- +===+ 208 | S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2| 209 +--------------------------------------------------+ --- +===+ 210 . . . . . . 211 . . . . . . 212 . . . . . . 213 +--------------------------------------------------+ --- +===+ 214 | S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D| 215 +--------------------------------------------------+ --- +===+ 217 Figure 3: Generating non-interleaved (row) FEC packets 219 If we apply the XOR operation to the group of the source packets 220 whose sequence numbers are L apart from each other, as sketched in 221 Figure 4. In this case the endpoint generates L repair packets. 222 This process is referred to as 1-D interleaved FEC protection, and 223 the resulting L repair packets are referred to as interleaved (or 224 column) FEC packets. 226 +-------------+ +-------------+ +-------------+ +-------+ 227 | S_1 | | S_2 | | S3 | ... | S_L | 228 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 229 | . | | . | | | | | 230 | . | | . | | | | | 231 | . | | . | | | | | 232 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 233 +-------------+ +-------------+ +-------------+ +-------+ 234 + + + + 235 ------------- ------------- ------------- ------- 236 | XOR | | XOR | | XOR | ... | XOR | 237 ------------- ------------- ------------- ------- 238 = = = = 239 +===+ +===+ +===+ +===+ 240 |C_1| |C_2| |C_3| ... |C_L| 241 +===+ +===+ +===+ +===+ 243 Figure 4: Generating interleaved (column) FEC packets 245 1.1. Use Cases for 1-D FEC Protection 247 We generate one non-interleaved repair packet out of L consecutive 248 source packets or one interleaved repair packet out of D non- 249 consecutive source packets. Regardless of whether the repair packet 250 is a non-interleaved or an interleaved one, it can provide a full 251 recovery of the missing information if there is only one packet 252 missing among the corresponding source packets. This implies that 253 1-D non-interleaved FEC protection performs better when the source 254 packets are randomly lost. However, if the packet losses occur in 255 bursts, 1-D interleaved FEC protection performs better provided that 256 L is chosen large enough, i.e., L-packet duration is not shorter than 257 the observed burst duration. If the sender generates non-interleaved 258 FEC packets and a burst loss hits the source packets, the repair 259 operation fails. This is illustrated in Figure 5. 261 +---+ +---+ +===+ 262 | 1 | X X | 4 | |R_1| 263 +---+ +---+ +===+ 265 +---+ +---+ +---+ +---+ +===+ 266 | 5 | | 6 | | 7 | | 8 | |R_2| 267 +---+ +---+ +---+ +---+ +===+ 269 +---+ +---+ +---+ +---+ +===+ 270 | 9 | | 10| | 11| | 12| |R_3| 271 +---+ +---+ +---+ +---+ +===+ 273 Figure 5: Example scenario where 1-D non-interleaved FEC protection 274 fails error recovery (Burst Loss) 276 The sender may generate interleaved FEC packets to combat with the 277 bursty packet losses. However, two or more random packet losses may 278 hit the source and repair packets in the same column. In that case, 279 the repair operation fails as well. This is illustrated in Figure 6. 280 Note that it is possible that two burst losses may occur back-to- 281 back, in which case interleaved FEC packets may still fail to recover 282 the lost data. 284 +---+ +---+ +---+ 285 | 1 | X | 3 | | 4 | 286 +---+ +---+ +---+ 288 +---+ +---+ +---+ 289 | 5 | X | 7 | | 8 | 290 +---+ +---+ +---+ 292 +---+ +---+ +---+ +---+ 293 | 9 | | 10| | 11| | 12| 294 +---+ +---+ +---+ +---+ 296 +===+ +===+ +===+ +===+ 297 |C_1| |C_2| |C_3| |C_4| 298 +===+ +===+ +===+ +===+ 300 Figure 6: Example scenario where 1-D interleaved FEC protection fails 301 error recovery (Periodic Loss) 303 1.2. Use Cases for 2-D Parity FEC Protection 305 In networks where the source packets are lost both randomly and in 306 bursts, the sender ought to generate both non-interleaved and 307 interleaved FEC packets. This type of FEC protection is known as 2-D 308 parity FEC protection. At the expense of generating more FEC 309 packets, thus increasing the FEC overhead, 2-D FEC provides superior 310 protection against mixed loss patterns. However, it is still 311 possible for 2-D parity FEC protection to fail to recover all of the 312 lost source packets if a particular loss pattern occurs. An example 313 scenario is illustrated in Figure 7. 315 +---+ +---+ +===+ 316 | 1 | X X | 4 | |R_1| 317 +---+ +---+ +===+ 319 +---+ +---+ +---+ +---+ +===+ 320 | 5 | | 6 | | 7 | | 8 | |R_2| 321 +---+ +---+ +---+ +---+ +===+ 323 +---+ +---+ +===+ 324 | 9 | X X | 12| |R_3| 325 +---+ +---+ +===+ 327 +===+ +===+ +===+ +===+ 328 |C_1| |C_2| |C_3| |C_4| 329 +===+ +===+ +===+ +===+ 331 Figure 7: Example scenario #1 where 2-D parity FEC protection fails 332 error recovery 334 2-D parity FEC protection also fails when at least two rows are 335 missing a source and the FEC packet and the missing source packets 336 (in at least two rows) are aligned in the same column. An example 337 loss pattern is sketched in Figure 8. Similarly, 2-D parity FEC 338 protection cannot repair all missing source packets when at least two 339 columns are missing a source and the FEC packet and the missing 340 source packets (in at least two columns) are aligned in the same row. 342 +---+ +---+ +---+ 343 | 1 | | 2 | X | 4 | X 344 +---+ +---+ +---+ 346 +---+ +---+ +---+ +---+ +===+ 347 | 5 | | 6 | | 7 | | 8 | |R_2| 348 +---+ +---+ +---+ +---+ +===+ 350 +---+ +---+ +---+ 351 | 9 | | 10| X | 12| X 352 +---+ +---+ +---+ 354 +===+ +===+ +===+ +===+ 355 |C_1| |C_2| |C_3| |C_4| 356 +===+ +===+ +===+ +===+ 358 Figure 8: Example scenario #2 where 2-D parity FEC protection fails 359 error recovery 361 1.3. Overhead Computation 363 The overhead is defined as the ratio of the number of bytes belonging 364 to the repair packets to the number of bytes belonging to the 365 protected source packets. 367 Generally, repair packets are larger in size compared to the source 368 packets. Also, not all the source packets are necessarily equal in 369 size. However, if we assume that each repair packet carries an equal 370 number of bytes carried by a source packet, we can compute the 371 overhead for different FEC protection methods as follows: 373 o 1-D Non-interleaved FEC Protection: Overhead = 1/L 375 o 1-D Interleaved FEC Protection: Overhead = 1/D 377 o 2-D Parity FEC Protection: Overhead = 1/L + 1/D 379 where L and D are the number of columns and rows in the source block, 380 respectively. 382 2. Requirements Notation 384 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 385 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 386 document are to be interpreted as described in [RFC2119]. 388 3. Definitions and Notations 390 3.1. Definitions 392 This document uses a number of definitions from [RFC6363]. 394 3.2. Notations 396 o L: Number of columns of the source block. 398 o D: Number of rows of the source block. 400 o bitmask: Run-length encoding of packets protected by a FEC packet. 401 If the bit i in the mask is set to 1, the source packet number N + 402 i is protected by this FEC packet. Here, N is the sequence number 403 base, which is indicated in the FEC packet as well. 405 4. Packet Formats 407 This section defines the formats of the source and repair packets. 409 4.1. Source Packets 411 The source packets MUST contain the information that identifies the 412 source block and the position within the source block occupied by the 413 packet. Since the source packets that are carried within an RTP 414 stream already contain unique sequence numbers in their RTP headers 415 [RFC3550], we can identify the source packets in a straightforward 416 manner and there is no need to append additional field(s). The 417 primary advantage of not modifying the source packets in any way is 418 that it provides backward compatibility for the receivers that do not 419 support FEC at all. In multicast scenarios, this backward 420 compatibility becomes quite useful as it allows the non-FEC-capable 421 and FEC-capable receivers to receive and interpret the same source 422 packets sent in the same multicast session. 424 4.2. Repair Packets 426 The repair packets MUST contain information that identifies the 427 source block they pertain to and the relationship between the 428 contained repair symbols and the original source block. For this 429 purpose, we use the RTP header of the repair packets as well as 430 another header within the RTP payload, which we refer to as the FEC 431 header, as shown in Figure 9. 433 +------------------------------+ 434 | IP Header | 435 +------------------------------+ 436 | Transport Header | 437 +------------------------------+ 438 | RTP Header | __ 439 +------------------------------+ | 440 | FEC Header | \ 441 +------------------------------+ > RTP Payload 442 | Repair Symbols | / 443 +------------------------------+ __| 445 Figure 9: Format of repair packets 447 The RTP header is formatted according to [RFC3550] with some further 448 clarifications listed below: 450 o Marker (M) Bit: This bit is not used for this payload type, and 451 SHALL be set to 0. 453 o Payload Type: The (dynamic) payload type for the repair packets is 454 determined through out-of-band means. Note that this document 455 registers new payload formats for the repair packets (Refer to 456 Section 5 for details). According to [RFC3550], an RTP receiver 457 that cannot recognize a payload type must discard it. This 458 provides backward compatibility. If a non-FEC-capable receiver 459 receives a repair packet, it will not recognize the payload type, 460 and hence, will discard the repair packet. 462 o Sequence Number (SN): The sequence number has the standard 463 definition. It MUST be one higher than the sequence number in the 464 previously transmitted repair packet. The initial value of the 465 sequence number SHOULD be random (unpredictable, based on 466 [RFC3550]). 468 o Timestamp (TS): The timestamp SHALL be set to a time corresponding 469 to the repair packet's transmission time. Note that the timestamp 470 value has no use in the actual FEC protection process and is 471 usually useful for jitter calculations. 473 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 474 assigned as suggested by [RFC3550]. This allows the sender to 475 multiplex the source and repair flows on the same port, or 476 multiplex multiple repair flows on a single port. The repair 477 flows SHOULD use the RTCP CNAME field to associate themselves with 478 the source flow. 480 In some networks, the RTP Source, which produces the source 481 packets and the FEC Source, which generates the repair packets 482 from the source packets may not be the same host. In such 483 scenarios, using the same CNAME for the source and repair flows 484 means that the RTP Source and the FEC Source MUST share the same 485 CNAME (for this specific source-repair flow association). A 486 common CNAME may be produced based on an algorithm that is known 487 both to the RTP and FEC Source [RFC7022]. This usage is compliant 488 with [RFC3550]. 490 Note that due to the randomness of the SSRC assignments, there is 491 a possibility of SSRC collision. In such cases, the collisions 492 MUST be resolved as described in [RFC3550]. 494 The format of the FEC header is shown in Figure 10. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |MSK|P|X| CC |M| PT recovery | SN base | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | TS recovery | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | length recovery |M or Mask[8-15]| N or Mask[0-7]| 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Mask [16-47] (optional) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 + Mask [48-111] (optional) + 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Figure 10: Format of the FEC header 514 The FEC header consists of the following fields: 516 o The MSK field (2 bits) indicates the type of the mask. Namely: 518 +---------------+-------------------------------------+ 519 | MSK bits | Use | 520 +---------------+-------------------------------------+ 521 | 00 | 16-bit mask | 522 | 01 | 48-bit mask | 523 | 10 | 112-bit mask | 524 | 11 | packets indicated by offset M and N | 525 +---------------+-------------------------------------+ 527 Figure 11: MSK bit values 529 o The P, X, CC, M and PT recovery fields are used to determine the 530 corresponding fields of the recovered packets. 532 o The SN base field is used to indicate the lowest sequence number, 533 taking wrap around into account, of those source packets protected 534 by this repair packet. 536 o The TS recovery field is used to determine the timestamp of the 537 recovered packets. 539 o The Length recovery field is used to determine the length of the 540 recovered packets. 542 o Mask is a run-length encoding of packets protected by the FEC 543 packet. Where a bit i set to 1 indicates that the source packet 544 with sequence number (SN base + i) is protected by this FEC 545 packet. 547 o If the the MSK field is set to 11, it indicates the offset of 548 packets protected by this FEC packet. Consequently, the following 549 conditions may occur: 551 If M=0, N=0, regular protection pattern code with the values of 552 L and D are indicared in the SDP description. 553 If M>0, N=0, indicates a non-interleaved (row) FEC of M packets 554 starting at SN base. 555 Hence, FEC = SN, SN+1, SN+2, ... , SN+(M-1), SN+M. 556 If M>0, N>0, indicates interleaved (column) FEC of every M packet 557 in a group of N packets starting at SN base. 558 Hence, FEC = SN+(Mx0), SN+(Mx1), ... , SN+(MxN). 560 Figure 12: Interpreting the M and N field values 562 The details on setting the fields in the FEC header are provided in 563 Section 6.2. 565 It should be noted that a mask-based approach (similar to the ones 566 specified in [RFC2733] and [RFC5109]) may not be very efficient to 567 indicate which source packets in the current source block are 568 associated with a given repair packet. In particular, for the 569 applications that would like to use large source block sizes, the 570 size of the mask that is required to describe the source-repair 571 packet associations may be prohibitively large. The 8-bit fields 572 proposed in [SMPTE2022-1] indicate a systematized approach. Instead 573 the approach in this document uses the 8-bit fields to indicate 574 packet offsets protected by the FEC packet. The approach in 575 [SMPTE2022-1] is inherently more efficient for regular patterns, it 576 does not provide flexibility to represent other protection patterns 577 (e.g., staircase). 579 5. Payload Format Parameters 581 This section provides the media subtype registration for the non- 582 interleaved and interleaved parity FEC. The parameters that are 583 required to configure the FEC encoding and decoding operations are 584 also defined in this section. 586 5.1. Media Type Registration 588 This registration is done using the template defined in [RFC6838] and 589 following the guidance provided in [RFC3555]. 591 Note to the RFC Editor: In the following sections, please replace 592 "XXXX" with the number of this document prior to publication as an 593 RFC. 595 5.1.1. Registration of audio/non-interleaved-parityfec 597 Type name: audio 599 Subtype name: non-interleaved-parityfec 601 Required parameters: 603 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 604 than 1000 Hz to provide sufficient resolution to RTCP operations. 605 However, it is RECOMMENDED to select the rate that matches the 606 rate of the protected source RTP stream. 608 o L: Number of columns of the source block. L is a positive 609 integer. 611 o D: Number of rows of the source block. D is a positive integer. 613 o ToP: Type of the protection applied by the sender: 0 for 1-D 614 interleaved FEC protection, 1 for 1-D non-interleaved FEC 615 protection, and 2 for 2-D parity FEC protection. The ToP value of 616 3 is reserved for future uses. 618 o repair-window: The time that spans the source packets and the 619 corresponding repair packets. The size of the repair window is 620 specified in microseconds. 622 Optional parameters: None. 624 Encoding considerations: This media type is framed (See Section 4.8 625 in the template document [RFC6838]) and contains binary data. 627 Security considerations: See Section 9 of [RFCXXXX]. 629 Interoperability considerations: None. 631 Published specification: [RFCXXXX]. 633 Applications that use this media type: Multimedia applications that 634 want to improve resiliency against packet loss by sending redundant 635 data in addition to the source media. 637 Fragment identifier considerations: None. 639 Additional information: None. 641 Person & email address to contact for further information: Varun 642 Singh and IETF Audio/Video Transport Payloads 643 Working Group. 645 Intended usage: COMMON. 647 Restriction on usage: This media type depends on RTP framing, and 648 hence, is only defined for transport via RTP [RFC3550]. 650 Author: Varun Singh . 652 Change controller: IETF Audio/Video Transport Working Group delegated 653 from the IESG. 655 Provisional registration? (standards tree only): Yes. 657 5.1.2. Registration of video/non-interleaved-parityfec 659 Type name: video 661 Subtype name: non-interleaved-parityfec 663 Required parameters: 665 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 666 than 1000 Hz to provide sufficient resolution to RTCP operations. 667 However, it is RECOMMENDED to select the rate that matches the 668 rate of the protected source RTP stream. 670 o L: Number of columns of the source block. L is a positive 671 integer. 673 o D: Number of rows of the source block. D is a positive integer. 675 o ToP: Type of the protection applied by the sender: 0 for 1-D 676 interleaved FEC protection, 1 for 1-D non-interleaved FEC 677 protection, and 2 for 2-D parity FEC protection. The ToP value of 678 3 is reserved for future uses. 680 o repair-window: The time that spans the source packets and the 681 corresponding repair packets. The size of the repair window is 682 specified in microseconds. 684 Optional parameters: None. 686 Encoding considerations: This media type is framed (See Section 4.8 687 in the template document [RFC6838]) and contains binary data. 689 Security considerations: See Section 9 of [RFCXXXX]. 691 Interoperability considerations: None. 693 Published specification: [RFCXXXX]. 695 Applications that use this media type: Multimedia applications that 696 want to improve resiliency against packet loss by sending redundant 697 data in addition to the source media. 699 Fragment identifier considerations: None. 701 Additional information: None. 703 Person & email address to contact for further information: Varun 704 Singh and IETF Audio/Video Transport Payloads 705 Working Group. 707 Intended usage: COMMON. 709 Restriction on usage: This media type depends on RTP framing, and 710 hence, is only defined for transport via RTP [RFC3550]. 712 Author: Varun Singh . 714 Change controller: IETF Audio/Video Transport Working Group delegated 715 from the IESG. 717 Provisional registration? (standards tree only): Yes. 719 5.1.3. Registration of text/non-interleaved-parityfec 721 Type name: text 723 Subtype name: non-interleaved-parityfec 725 Required parameters: 727 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 728 than 1000 Hz to provide sufficient resolution to RTCP operations. 729 However, it is RECOMMENDED to select the rate that matches the 730 rate of the protected source RTP stream. 732 o L: Number of columns of the source block. L is a positive 733 integer. 735 o D: Number of rows of the source block. D is a positive integer. 737 o ToP: Type of the protection applied by the sender: 0 for 1-D 738 interleaved FEC protection, 1 for 1-D non-interleaved FEC 739 protection, and 2 for 2-D parity FEC protection. The ToP value of 740 3 is reserved for future uses. 742 o repair-window: The time that spans the source packets and the 743 corresponding repair packets. The size of the repair window is 744 specified in microseconds. 746 Optional parameters: None. 748 Encoding considerations: This media type is framed (See Section 4.8 749 in the template document [RFC6838]) and contains binary data. 751 Security considerations: See Section 9 of [RFCXXXX]. 753 Interoperability considerations: None. 755 Published specification: [RFCXXXX]. 757 Applications that use this media type: Multimedia applications that 758 want to improve resiliency against packet loss by sending redundant 759 data in addition to the source media. 761 Fragment identifier considerations: None. 763 Additional information: None. 765 Person & email address to contact for further information: Varun 766 Singh and IETF Audio/Video Transport Payloads 767 Working Group. 769 Intended usage: COMMON. 771 Restriction on usage: This media type depends on RTP framing, and 772 hence, is only defined for transport via RTP [RFC3550]. 774 Author: Varun Singh . 776 Change controller: IETF Audio/Video Transport Working Group delegated 777 from the IESG. 779 Provisional registration? (standards tree only): Yes. 781 5.1.4. Registration of application/non-interleaved-parityfec 783 Type name: application 785 Subtype name: non-interleaved-parityfec 787 Required parameters: 789 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 790 than 1000 Hz to provide sufficient resolution to RTCP operations. 791 However, it is RECOMMENDED to select the rate that matches the 792 rate of the protected source RTP stream. 794 o L: Number of columns of the source block. L is a positive 795 integer. 797 o D: Number of rows of the source block. D is a positive integer. 799 o ToP: Type of the protection applied by the sender: 0 for 1-D 800 interleaved FEC protection, 1 for 1-D non-interleaved FEC 801 protection, and 2 for 2-D parity FEC protection. The ToP value of 802 3 is reserved for future uses. 804 o repair-window: The time that spans the source packets and the 805 corresponding repair packets. The size of the repair window is 806 specified in microseconds. 808 Optional parameters: None. 810 Encoding considerations: This media type is framed (See Section 4.8 811 in the template document [RFC6838]) and contains binary data. 813 Security considerations: See Section 9 of [RFCXXXX]. 815 Interoperability considerations: None. 817 Published specification: [RFCXXXX]. 819 Applications that use this media type: Multimedia applications that 820 want to improve resiliency against packet loss by sending redundant 821 data in addition to the source media. 823 Fragment identifier considerations: None. 825 Additional information: None. 827 Person & email address to contact for further information: Varun 828 Singh and IETF Audio/Video Transport Payloads 829 Working Group. 831 Intended usage: COMMON. 833 Restriction on usage: This media type depends on RTP framing, and 834 hence, is only defined for transport via RTP [RFC3550]. 836 Author: Varun Singh . 838 Change controller: IETF Audio/Video Transport Working Group delegated 839 from the IESG. 841 Provisional registration? (standards tree only): Yes. 843 5.1.5. Registration of audio/interleaved-parityfec 845 Type name: audio 847 Subtype name: interleaved-parityfec 849 Required parameters: 851 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 852 than 1000 Hz to provide sufficient resolution to RTCP operations. 853 However, it is RECOMMENDED to select the rate that matches the 854 rate of the protected source RTP stream. 856 o L: Number of columns of the source block. L is a positive 857 integer. 859 o D: Number of rows of the source block. D is a positive integer. 861 o ToP: Type of the protection applied by the sender: 0 for 1-D 862 interleaved FEC protection, 1 for 1-D non-interleaved FEC 863 protection, and 2 for 2-D parity FEC protection. The ToP value of 864 3 is reserved for future uses. 866 o repair-window: The time that spans the source packets and the 867 corresponding repair packets. The size of the repair window is 868 specified in microseconds. 870 Optional parameters: None. 872 Encoding considerations: This media type is framed (See Section 4.8 873 in the template document [RFC6838]) and contains binary data. 875 Security considerations: See Section 9 of [RFCXXXX]. 877 Interoperability considerations: None. 879 Published specification: [RFCXXXX]. 881 Applications that use this media type: Multimedia applications that 882 want to improve resiliency against packet loss by sending redundant 883 data in addition to the source media. 885 Fragment identifier considerations: None. 887 Additional information: None. 889 Person & email address to contact for further information: Varun 890 Singh and IETF Audio/Video Transport Payloads 891 Working Group. 893 Intended usage: COMMON. 895 Restriction on usage: This media type depends on RTP framing, and 896 hence, is only defined for transport via RTP [RFC3550]. 898 Author: Varun Singh . 900 Change controller: IETF Audio/Video Transport Working Group delegated 901 from the IESG. 903 Provisional registration? (standards tree only): Yes. 905 5.1.6. Registration of video/interleaved-parityfec 907 Type name: video 909 Subtype name: interleaved-parityfec 911 Required parameters: 913 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 914 than 1000 Hz to provide sufficient resolution to RTCP operations. 915 However, it is RECOMMENDED to select the rate that matches the 916 rate of the protected source RTP stream. 918 o L: Number of columns of the source block. L is a positive 919 integer. 921 o D: Number of rows of the source block. D is a positive integer. 923 o ToP: Type of the protection applied by the sender: 0 for 1-D 924 interleaved FEC protection, 1 for 1-D non-interleaved FEC 925 protection, and 2 for 2-D parity FEC protection. The ToP value of 926 3 is reserved for future uses. 928 o repair-window: The time that spans the source packets and the 929 corresponding repair packets. The size of the repair window is 930 specified in microseconds. 932 Optional parameters: None. 934 Encoding considerations: This media type is framed (See Section 4.8 935 in the template document [RFC6838]) and contains binary data. 937 Security considerations: See Section 9 of [RFCXXXX]. 939 Interoperability considerations: None. 941 Published specification: [RFCXXXX]. 943 Applications that use this media type: Multimedia applications that 944 want to improve resiliency against packet loss by sending redundant 945 data in addition to the source media. 947 Fragment identifier considerations: None. 949 Additional information: None. 951 Person & email address to contact for further information: Varun 952 Singh and IETF Audio/Video Transport Payloads 953 Working Group. 955 Intended usage: COMMON. 957 Restriction on usage: This media type depends on RTP framing, and 958 hence, is only defined for transport via RTP [RFC3550]. 960 Author: Varun Singh . 962 Change controller: IETF Audio/Video Transport Working Group delegated 963 from the IESG. 965 Provisional registration? (standards tree only): Yes. 967 5.1.7. Registration of text/interleaved-parityfec 969 Type name: text 971 Subtype name: interleaved-parityfec 973 Required parameters: 975 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 976 than 1000 Hz to provide sufficient resolution to RTCP operations. 977 However, it is RECOMMENDED to select the rate that matches the 978 rate of the protected source RTP stream. 980 o L: Number of columns of the source block. L is a positive 981 integer. 983 o D: Number of rows of the source block. D is a positive integer. 985 o ToP: Type of the protection applied by the sender: 0 for 1-D 986 interleaved FEC protection, 1 for 1-D non-interleaved FEC 987 protection, and 2 for 2-D parity FEC protection. The ToP value of 988 3 is reserved for future uses. 990 o repair-window: The time that spans the source packets and the 991 corresponding repair packets. The size of the repair window is 992 specified in microseconds. 994 Optional parameters: None. 996 Encoding considerations: This media type is framed (See Section 4.8 997 in the template document [RFC6838]) and contains binary data. 999 Security considerations: See Section 9 of [RFCXXXX]. 1001 Interoperability considerations: None. 1003 Published specification: [RFCXXXX]. 1005 Applications that use this media type: Multimedia applications that 1006 want to improve resiliency against packet loss by sending redundant 1007 data in addition to the source media. 1009 Fragment identifier considerations: None. 1011 Additional information: None. 1013 Person & email address to contact for further information: Varun 1014 Singh and IETF Audio/Video Transport Payloads 1015 Working Group. 1017 Intended usage: COMMON. 1019 Restriction on usage: This media type depends on RTP framing, and 1020 hence, is only defined for transport via RTP [RFC3550]. 1022 Author: Varun Singh . 1024 Change controller: IETF Audio/Video Transport Working Group delegated 1025 from the IESG. 1027 Provisional registration? (standards tree only): Yes. 1029 5.1.8. Registration of application/interleaved-parityfec 1031 Type name: application 1033 Subtype name: interleaved-parityfec 1035 Required parameters: 1037 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 1038 than 1000 Hz to provide sufficient resolution to RTCP operations. 1039 However, it is RECOMMENDED to select the rate that matches the 1040 rate of the protected source RTP stream. 1042 o L: Number of columns of the source block. L is a positive 1043 integer. 1045 o D: Number of rows of the source block. D is a positive integer. 1047 o ToP: Type of the protection applied by the sender: 0 for 1-D 1048 interleaved FEC protection, 1 for 1-D non-interleaved FEC 1049 protection, and 2 for 2-D parity FEC protection. The ToP value of 1050 3 is reserved for future uses. 1052 o repair-window: The time that spans the source packets and the 1053 corresponding repair packets. The size of the repair window is 1054 specified in microseconds. 1056 Optional parameters: None. 1058 Encoding considerations: This media type is framed (See Section 4.8 1059 in the template document [RFC6838]) and contains binary data. 1061 Security considerations: See Section 9 of [RFCXXXX]. 1063 Interoperability considerations: None. 1065 Published specification: [RFCXXXX]. 1067 Applications that use this media type: Multimedia applications that 1068 want to improve resiliency against packet loss by sending redundant 1069 data in addition to the source media. 1071 Fragment identifier considerations: None. 1073 Additional information: None. 1075 Person & email address to contact for further information: Varun 1076 Singh and IETF Audio/Video Transport Payloads 1077 Working Group. 1079 Intended usage: COMMON. 1081 Restriction on usage: This media type depends on RTP framing, and 1082 hence, is only defined for transport via RTP [RFC3550]. 1084 Author: Varun Singh . 1086 Change controller: IETF Audio/Video Transport Working Group delegated 1087 from the IESG. 1089 Provisional registration? (standards tree only): Yes. 1091 5.2. Mapping to SDP Parameters 1093 Applications that are using RTP transport commonly use Session 1094 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 1095 The information that is used to specify the media types in an RTP 1096 session has specific mappings to the fields in an SDP description. 1097 In this section, we provide these mappings for the media subtypes 1098 registered by this document. Note that if an application does not 1099 use SDP to describe the RTP sessions, an appropriate mapping must be 1100 defined and used to specify the media types and their parameters for 1101 the control/description protocol employed by the application. 1103 The mapping of the media type specification for "non-interleaved- 1104 parityfec" and "interleaved-parityfec" and their parameters in SDP is 1105 as follows: 1107 o The media type (e.g., "application") goes into the "m=" line as 1108 the media name. 1110 o The media subtype goes into the "a=rtpmap" line as the encoding 1111 name. The RTP clock rate parameter ("rate") also goes into the 1112 "a=rtpmap" line as the clock rate. 1114 o The remaining required payload-format-specific parameters go into 1115 the "a=fmtp" line by copying them directly from the media type 1116 string as a semicolon-separated list of parameter=value pairs. 1118 SDP examples are provided in Section 7. 1120 5.2.1. Offer-Answer Model Considerations 1122 When offering 1-D interleaved parity FEC over RTP using SDP in an 1123 Offer/Answer model [RFC3264], the following considerations apply: 1125 o Each combination of the L and D parameters produces a different 1126 FEC data and is not compatible with any other combination. A 1127 sender application may desire to offer multiple offers with 1128 different sets of L and D values as long as the parameter values 1129 are valid. The receiver SHOULD normally choose the offer that has 1130 a sufficient amount of interleaving. If multiple such offers 1131 exist, the receiver may choose the offer that has the lowest 1132 overhead or the one that requires the smallest amount of 1133 buffering. The selection depends on the application requirements. 1135 o The value for the repair-window parameter depends on the L and D 1136 values and cannot be chosen arbitrarily. More specifically, L and 1137 D values determine the lower limit for the repair-window size. 1139 The upper limit of the repair-window size does not depend on the L 1140 and D values. 1142 o Although combinations with the same L and D values but with 1143 different repair-window sizes produce the same FEC data, such 1144 combinations are still considered different offers. The size of 1145 the repair-window is related to the maximum delay between the 1146 transmission of a source packet and the associated repair packet. 1147 This directly impacts the buffering requirement on the receiver 1148 side and the receiver must consider this when choosing an offer. 1150 o There are no optional format parameters defined for this payload. 1151 Any unknown option in the offer MUST be ignored and deleted from 1152 the answer. If FEC is not desired by the receiver, it can be 1153 deleted from the answer. 1155 5.2.2. Declarative Considerations 1157 In declarative usage, like SDP in the Real-time Streaming Protocol 1158 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 1159 [RFC2974], the following considerations apply: 1161 o The payload format configuration parameters are all declarative 1162 and a participant MUST use the configuration that is provided for 1163 the session. 1165 o More than one configuration may be provided (if desired) by 1166 declaring multiple RTP payload types. In that case, the receivers 1167 should choose the repair flow that is best for them. 1169 6. Protection and Recovery Procedures 1171 This section provides a complete specification of the 1-D and 2-D 1172 parity codes and their RTP payload formats. 1174 6.1. Overview 1176 The following sections specify the steps involved in generating the 1177 repair packets and reconstructing the missing source packets from the 1178 repair packets. 1180 6.2. Repair Packet Construction 1182 The RTP header of a repair packet is formed based on the guidelines 1183 given in Section 4.2. 1185 The FEC header includes 12 octets (or upto 28 octets when the longer 1186 optional masks are used). It is constructed by applying the XOR 1187 operation on the bit strings that are generated from the individual 1188 source packets protected by this particular repair packet. The set 1189 of the source packets that are associated with a given repair packet 1190 can be computed by the formula given in Section 6.3.1. 1192 The bit string is formed for each source packet by concatenating the 1193 following fields together in the order specified: 1195 o The first 64 bits of the RTP header (64 bits). 1197 o Unsigned network-ordered 16-bit representation of the source 1198 packet length in bytes minus 12 (for the fixed RTP header), i.e., 1199 the sum of the lengths of all the following if present: the CSRC 1200 list, extension header, RTP payload and RTP padding (16 bits). 1202 By applying the parity operation on the bit strings produced from the 1203 source packets, we generate the FEC bit string. The FEC header is 1204 generated from the FEC bit string as follows: 1206 o The first (most significant) 2 bits in the FEC bit string are 1207 skipped. The MSK bits in the FEC header are set to the 1208 appropriate value, i.e., it depends on the chosen bitmask length. 1210 o The next bit in the FEC bit string is written into the P recovery 1211 bit in the FEC header. 1213 o The next bit in the FEC bit string is written into the X recovery 1214 bit in the FEC header. 1216 o The next 4 bits of the FEC bit string are written into the CC 1217 recovery field in the FEC header. 1219 o The next bit is written into the M recovery bit in the FEC header. 1221 o The next 7 bits of the FEC bit string are written into the PT 1222 recovery field in the FEC header. 1224 o The next 16 bits are skipped. 1226 o The next 32 bits of the FEC bit string are written into the TS 1227 recovery field in the FEC header. 1229 o The next 16 bits are written into the length recovery field in the 1230 FEC header. 1232 o Depending on the chosen MSK value, the bit mask of appropriate 1233 length will be set to the appropriate values. 1235 As described in Section 4.2, the SN base field of the FEC header MUST 1236 be set to the lowest sequence number of the source packets protected 1237 by this repair packet. When MSK represents a bitmask (MSK=00,01,10), 1238 the SN base field corresponds to the lowest sequence number indicated 1239 in the bitmask. When MSK=11, the following considerations apply: 1) 1240 for the interleaved FEC packets, this corresponds to the lowest 1241 sequence number of the source packets that forms the column, 2) for 1242 the non-interleaved FEC packets, the SN base field MUST be set to the 1243 lowest sequence number of the source packets that forms the row. 1245 The repair packet payload consists of the bits that are generated by 1246 applying the XOR operation on the payloads of the source RTP packets. 1247 If the payload lengths of the source packets are not equal, each 1248 shorter packet MUST be padded to the length of the longest packet by 1249 adding octet 0's at the end. 1251 Due to this possible padding and mandatory FEC header, a repair 1252 packet has a larger size than the source packets it protects. This 1253 may cause problems if the resulting repair packet size exceeds the 1254 Maximum Transmission Unit (MTU) size of the path over which the 1255 repair flow is sent. 1257 6.3. Source Packet Reconstruction 1259 This section describes the recovery procedures that are required to 1260 reconstruct the missing source packets. The recovery process has two 1261 steps. In the first step, the FEC decoder determines which source 1262 and repair packets should be used in order to recover a missing 1263 packet. In the second step, the decoder recovers the missing packet, 1264 which consists of an RTP header and RTP payload. 1266 In the following, we describe the RECOMMENDED algorithms for the 1267 first and second steps. Based on the implementation, different 1268 algorithms MAY be adopted. However, the end result MUST be identical 1269 to the one produced by the algorithms described below. 1271 Note that the same algorithms are used by the 1-D parity codes, 1272 regardless of whether the FEC protection is applied over a column or 1273 a row. The 2-D parity codes, on the other hand, usually require 1274 multiple iterations of the procedures described here. This iterative 1275 decoding algorithm is further explained in Section 6.3.4. 1277 6.3.1. Associating the Source and Repair Packets 1279 We denote the set of the source packets associated with repair packet 1280 p* by set T(p*). Note that in a source block whose size is L columns 1281 by D rows, set T includes D source packets plus one repair packet for 1282 the FEC protection applied over a column, and L source packets plus 1283 one repair packet for the FEC protection applied over a row. Recall 1284 that 1-D interleaved and non-interleaved FEC protection can fully 1285 recover the missing information if there is only one source packet 1286 missing in set T. If there are more than one source packets missing 1287 in set T, 1-D FEC protection will not work. 1289 6.3.1.1. Signaled in SDP 1291 The first step is associating the source and repair packets. If the 1292 endpoint relies entirely on out-of-band signaling (MSK=11, and 1293 M=N=0), then this information may be inferred from the media type 1294 parameters specified in the SDP description. Furtheremore, the 1295 payload type field in the RTP header, assists the receiver 1296 distinguish an interleaved or non-interleaved FEC packet. 1298 Mathematically, for any received repair packet, p*, we can determine 1299 the sequence numbers of the source packets that are protected by this 1300 repair packet as follows: 1302 p*_snb + i * X_1 (modulo 65536) 1304 where p*_snb denotes the value in the SN base field of p*'s FEC 1305 header, X_1 is set to L and 1 for the interleaved and non-interleaved 1306 FEC packets, respectively, and 1308 0 <= i < X_2 1310 where X_2 is set to D and L for the interleaved and non-interleaved 1311 FEC packets, respectively. 1313 6.3.1.2. Using bitmasks 1315 When using fixed size bitmasks (16-, 48-, 112-bits), the SN base 1316 field in the FEC header indicates the lowest sequence number of the 1317 source packets that forms the FEC packet. Finally, the bits maked by 1318 "1" in the bitmask are offsets from the SN base and make up the rest 1319 of the packets protected by the FEC packet. The bitmasks are able to 1320 represent arbitrary protection patterns, for example, 1-D 1321 interleaved, 1-D non-interleaved, 2-D, staircase. 1323 6.3.1.3. Using M and N Offsets 1325 When value of M is non-zero, the 8-bit fields indicate the offset of 1326 packets protected by an interleaved (N>0) or non-interleaved (N=0) 1327 FEC packet. Using a combination of interleaved and non-interleaved 1328 FEC packets can form 2-D protection patterns. 1330 Mathematically, for any received repair packet, p*, we can determine 1331 the sequence numbers of the source packets that are protected by this 1332 repair packet are as follows: 1334 When N = 0: 1335 p*_snb, p*_snb+1,..., p*_snb+(M-1), p*_snb+M 1336 When N > 0: 1337 p*_snb, p*_snb+(Mx1), p*_snb+(Mx2),..., p*_snb+(Mx(N-1)), p*_snb+(MxN) 1339 6.3.2. Recovering the RTP Header 1341 For a given set T, the procedure for the recovery of the RTP header 1342 of the missing packet, whose sequence number is denoted by SEQNUM, is 1343 as follows: 1345 1. For each of the source packets that are successfully received in 1346 T, compute the 80-bit string by concatenating the first 64 bits 1347 of their RTP header and the unsigned network-ordered 16-bit 1348 representation of their length in bytes minus 12. 1350 2. For the repair packet in T, compute the FEC bit string from the 1351 first 80 bits of the FEC header. 1353 3. Calculate the recovered bit string as the XOR of the bit strings 1354 generated from all source packets in T and the FEC bit string 1355 generated from the repair packet in T. 1357 4. Create a new packet with the standard 12-byte RTP header and no 1358 payload. 1360 5. Set the version of the new packet to 2. Skip the first 2 bits 1361 in the recovered bit string. 1363 6. Set the Padding bit in the new packet to the next bit in the 1364 recovered bit string. 1366 7. Set the Extension bit in the new packet to the next bit in the 1367 recovered bit string. 1369 8. Set the CC field to the next 4 bits in the recovered bit string. 1371 9. Set the Marker bit in the new packet to the next bit in the 1372 recovered bit string. 1374 10. Set the Payload type in the new packet to the next 7 bits in the 1375 recovered bit string. 1377 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 1378 bits in the recovered bit string. 1380 12. Set the TS field in the new packet to the next 32 bits in the 1381 recovered bit string. 1383 13. Take the next 16 bits of the recovered bit string and set the 1384 new variable Y to whatever unsigned integer this represents 1385 (assuming network order). Convert Y to host order. Y 1386 represents the length of the new packet in bytes minus 12 (for 1387 the fixed RTP header), i.e., the sum of the lengths of all the 1388 following if present: the CSRC list, header extension, RTP 1389 payload and RTP padding. 1391 14. Set the SSRC of the new packet to the SSRC of the source RTP 1392 stream. 1394 This procedure recovers the header of an RTP packet up to (and 1395 including) the SSRC field. 1397 6.3.3. Recovering the RTP Payload 1399 Following the recovery of the RTP header, the procedure for the 1400 recovery of the RTP payload is as follows: 1402 1. Append Y bytes to the new packet. 1404 2. For each of the source packets that are successfully received in 1405 T, compute the bit string from the Y octets of data starting with 1406 the 13th octet of the packet. If any of the bit strings 1407 generated from the source packets has a length shorter than Y, 1408 pad them to that length. The padding of octet 0 MUST be added at 1409 the end of the bit string. Note that the information of the 1410 first 8 octets are protected by the FEC header. 1412 3. For the repair packet in T, compute the FEC bit string from the 1413 repair packet payload, i.e., the Y octets of data following the 1414 FEC header. Note that the FEC header may be 12, 16, 32 octets 1415 depending on the length of the bitmask. 1417 4. Calculate the recovered bit string as the XOR of the bit strings 1418 generated from all source packets in T and the FEC bit string 1419 generated from the repair packet in T. 1421 5. Append the recovered bit string (Y octets) to the new packet 1422 generated in Section 6.3.2. 1424 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection 1426 In 2-D parity FEC protection, the sender generates both non- 1427 interleaved and interleaved FEC packets to combat with the mixed loss 1428 patterns (random and bursty). At the receiver side, these FEC 1429 packets are used iteratively to overcome the shortcomings of the 1-D 1430 non-interleaved/interleaved FEC protection and improve the chances of 1431 full error recovery. 1433 The iterative decoding algorithm runs as follows: 1435 1. Set num_recovered_until_this_iteration to zero 1437 2. Set num_recovered_so_far to zero 1439 3. Recover as many source packets as possible by using the non- 1440 interleaved FEC packets as outlined in Section 6.3.2 and 1441 Section 6.3.3, and increase the value of num_recovered_so_far by 1442 the number of recovered source packets. 1444 4. Recover as many source packets as possible by using the 1445 interleaved FEC packets as outlined in Section 6.3.2 and 1446 Section 6.3.3, and increase the value of num_recovered_so_far by 1447 the number of recovered source packets. 1449 5. If num_recovered_so_far > num_recovered_until_this_iteration 1450 ---num_recovered_until_this_iteration = num_recovered_so_far 1451 ---Go to step 3 1452 Else 1453 ---Terminate 1455 The algorithm terminates either when all missing source packets are 1456 fully recovered or when there are still remaining missing source 1457 packets but the FEC packets are not able to recover any more source 1458 packets. For the example scenarios when the 2-D parity FEC 1459 protection fails full recovery, refer to Section 1.2. Upon 1460 termination, variable num_recovered_so_far has a value equal to the 1461 total number of recovered source packets. 1463 Example: 1465 Suppose that the receiver experienced the loss pattern sketched in 1466 Figure 13. 1468 +---+ +---+ +===+ 1469 X X | 3 | | 4 | |R_1| 1470 +---+ +---+ +===+ 1472 +---+ +---+ +---+ +---+ +===+ 1473 | 5 | | 6 | | 7 | | 8 | |R_2| 1474 +---+ +---+ +---+ +---+ +===+ 1476 +---+ +---+ +===+ 1477 | 9 | X X | 12| |R_3| 1478 +---+ +---+ +===+ 1480 +===+ +===+ +===+ +===+ 1481 |C_1| |C_2| |C_3| |C_4| 1482 +===+ +===+ +===+ +===+ 1484 Figure 13: Example loss pattern for the iterative decoding algorithm 1486 The receiver executes the iterative decoding algorithm and recovers 1487 source packets #1 and #11 in the first iteration. The resulting 1488 pattern is sketched in Figure 14. 1490 +---+ +---+ +---+ +===+ 1491 | 1 | X | 3 | | 4 | |R_1| 1492 +---+ +---+ +---+ +===+ 1494 +---+ +---+ +---+ +---+ +===+ 1495 | 5 | | 6 | | 7 | | 8 | |R_2| 1496 +---+ +---+ +---+ +---+ +===+ 1498 +---+ +---+ +---+ +===+ 1499 | 9 | X | 11| | 12| |R_3| 1500 +---+ +---+ +---+ +===+ 1502 +===+ +===+ +===+ +===+ 1503 |C_1| |C_2| |C_3| |C_4| 1504 +===+ +===+ +===+ +===+ 1506 Figure 14: The resulting pattern after the first iteration 1508 Since the if condition holds true, the receiver runs a new iteration. 1509 In the second iteration, source packets #2 and #10 are recovered, 1510 resulting in a full recovery as sketched in Figure 15. 1512 +---+ +---+ +---+ +---+ +===+ 1513 | 1 | | 2 | | 3 | | 4 | |R_1| 1514 +---+ +---+ +---+ +---+ +===+ 1516 +---+ +---+ +---+ +---+ +===+ 1517 | 5 | | 6 | | 7 | | 8 | |R_2| 1518 +---+ +---+ +---+ +---+ +===+ 1520 +---+ +---+ +---+ +---+ +===+ 1521 | 9 | | 10| | 11| | 12| |R_3| 1522 +---+ +---+ +---+ +---+ +===+ 1524 +===+ +===+ +===+ +===+ 1525 |C_1| |C_2| |C_3| |C_4| 1526 +===+ +===+ +===+ +===+ 1528 Figure 15: The resulting pattern after the second iteration 1530 7. SDP Examples 1532 This section provides two SDP [RFC4566] examples. The examples use 1533 the FEC grouping semantics defined in [RFC4756]. 1535 7.1. Example SDP for 1-D Parity FEC Protection 1537 In this example, we have one source video stream (ssrc:1234) and one 1538 FEC repair stream (ssrc:2345). We form one FEC group with the 1539 "a=ssrc-group:FEC-FR 1234 2345" line. The source and repair streams 1540 are multiplexed on different SSRCs. The repair window is set to 200 1541 ms. 1543 v=0 1544 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1545 s=1-D Interleaved Parity FEC Example 1546 t=0 0 1547 m=video 30000 RTP/AVP 100 110 1548 c=IN IP4 233.252.0.1/127 1549 a=rtpmap:100 MP2T/90000 1550 a=rtpmap:110 interleaved-parityfec/90000 1551 a=fmtp:110 L:5; D:10; ToP:0; repair-window:200000 1552 a=ssrc:1234 1553 a=ssrc:2345 1554 a=ssrc-group:FEC-FR 1234 2345 1556 7.2. Example SDP for 2-D Parity FEC Protection 1558 In this example, we have one source video stream (ssrc:1234) and two 1559 FEC repair streams (ssrc:2345 and ssrc:3456). We form one FEC group 1560 with the "a=ssrc-group:FEC-FR 1234 2345 3456" line. The source and 1561 repair streams are multiplexed on different SSRCs. The repair window 1562 is set to 200 ms. 1564 v=0 1565 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1566 s=2-D Parity FEC Example 1567 t=0 0 1568 m=video 30000 RTP/AVP 100 110 111 1569 c=IN IP4 233.252.0.1/127 1570 a=rtpmap:100 MP2T/90000 1571 a=rtpmap:110 interleaved-parityfec/90000 1572 a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 1573 a=rtpmap:111 non-interleaved-parityfec/90000 1574 a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 1575 a=ssrc:1234 1576 a=ssrc:2345 1577 a=ssrc:3456 1578 a=ssrc-group:FEC-FR 1234 2345 3456 1580 Note that the sender might be generating two repair flows carrying 1581 non-interleaved and interleaved FEC packets, however the receiver 1582 might be interested only in the interleaved FEC packets. The 1583 receiver can identify the repair flow carrying the desired repair 1584 data by checking the payload types associated with each repair flow 1585 described in the SDP description. 1587 8. Congestion Control Considerations 1589 FEC is an effective approach to provide applications resiliency 1590 against packet losses. However, in networks where the congestion is 1591 a major contributor to the packet loss, the potential impacts of 1592 using FEC SHOULD be considered carefully before injecting the repair 1593 flows into the network. In particular, in bandwidth-limited 1594 networks, FEC repair flows may consume most or all of the available 1595 bandwidth and consequently may congest the network. In such cases, 1596 the applications MUST NOT arbitrarily increase the amount of FEC 1597 protection since doing so may lead to a congestion collapse. If 1598 desired, stronger FEC protection MAY be applied only after the source 1599 rate has been reduced [I-D.singh-rmcat-adaptive-fec]. 1601 In a network-friendly implementation, an application SHOULD NOT send/ 1602 receive FEC repair flows if it knows that sending/receiving those FEC 1603 repair flows would not help at all in recovering the missing packets. 1605 However, it MAY still continue to use FEC if considered for bandwidth 1606 estimation instead of speculatively probe for additional capacity 1607 [Holmer13][Nagy14]. It is RECOMMENDED that the amount of FEC 1608 protection is adjusted dynamically based on the packet loss rate 1609 observed by the applications. 1611 In multicast scenarios, it may be difficult to optimize the FEC 1612 protection per receiver. If there is a large variation among the 1613 levels of FEC protection needed by different receivers, it is 1614 RECOMMENDED that the sender offers multiple repair flows with 1615 different levels of FEC protection and the receivers join the 1616 corresponding multicast sessions to receive the repair flow(s) that 1617 is best for them. 1619 Editor's note: Additional congestion control considerations regarding 1620 the use of 2-D parity codes should be added here. 1622 9. Security Considerations 1624 RTP packets using the payload format defined in this specification 1625 are subject to the security considerations discussed in the RTP 1626 specification [RFC3550] and in any applicable RTP profile. The main 1627 security considerations for the RTP packet carrying the RTP payload 1628 format defined within this memo are confidentiality, integrity and 1629 source authenticity. Confidentiality is achieved by encrypting the 1630 RTP payload. Integrity of the RTP packets is achieved through a 1631 suitable cryptographic integrity protection mechanism. Such a 1632 cryptographic system may also allow the authentication of the source 1633 of the payload. A suitable security mechanism for this RTP payload 1634 format should provide confidentiality, integrity protection, and at 1635 least source authentication capable of determining if an RTP packet 1636 is from a member of the RTP session. 1638 Note that the appropriate mechanism to provide security to RTP and 1639 payloads following this memo may vary. It is dependent on the 1640 application, transport and signaling protocol employed. Therefore, a 1641 single mechanism is not sufficient, although if suitable, using the 1642 Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 1643 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1644 Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may 1645 exist. 1647 10. IANA Considerations 1649 New media subtypes are subject to IANA registration. For the 1650 registration of the payload formats and their parameters introduced 1651 in this document, refer to Section 5. 1653 11. Acknowledgments 1655 Some parts of this document are borrowed from [RFC5109]. Thus, the 1656 author would like to thank the editor of [RFC5109] and those who 1657 contributed to [RFC5109]. 1659 12. Change Log 1661 Note to the RFC-Editor: please remove this section prior to 1662 publication as an RFC. 1664 12.1. draft-ietf-payload-flexible-fec-scheme-00 1666 Initial WG version, based on draft-singh-payload-1d2d-parity-scheme- 1667 00. 1669 12.2. draft-singh-payload-1d2d-parity-scheme-00 1671 This is the initial version, which is based on draft-ietf-fecframe- 1672 1d2d-parity-scheme-00. The following are the major changes compared 1673 to that document: 1675 o Updated packet format with 16-, 48-, 112- bitmask. 1677 o Updated the sections on: repair packet construction, source packet 1678 construction. 1680 o Updated the media type registration and aligned to RFC6838. 1682 12.3. draft-ietf-fecframe-1d2d-parity-scheme-00 1684 o Some details were added regarding the use of CNAME field. 1686 o Offer-Answer and Declarative Considerations sections have been 1687 completed. 1689 o Security Considerations section has been completed. 1691 o The timestamp field definition has changed. 1693 13. References 1695 13.1. Normative References 1697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1698 Requirement Levels", BCP 14, RFC 2119, March 1997. 1700 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1701 with Session Description Protocol (SDP)", RFC 3264, June 1702 2002. 1704 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1705 Jacobson, "RTP: A Transport Protocol for Real-Time 1706 Applications", STD 64, RFC 3550, July 2003. 1708 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1709 Payload Formats", RFC 3555, July 2003. 1711 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1712 Description Protocol", RFC 4566, July 2006. 1714 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 1715 Session Description Protocol", RFC 4756, November 2006. 1717 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 1718 Correction (FEC) Framework", RFC 6363, October 2011. 1720 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1721 Specifications and Registration Procedures", BCP 13, RFC 1722 6838, January 2013. 1724 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1725 "Guidelines for Choosing RTP Control Protocol (RTCP) 1726 Canonical Names (CNAMEs)", RFC 7022, September 2013. 1728 13.2. Informative References 1730 [Holmer13] 1731 Holmer, S., Shemer, M., and M. Paniconi, "Handling Packet 1732 Loss in WebRTC", Proc. of IEEE International Conference on 1733 Image Processing (ICIP 2013) , 9 2013. 1735 [I-D.singh-rmcat-adaptive-fec] 1736 Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion 1737 Control Using FEC for Conversational Media", draft-singh- 1738 rmcat-adaptive-fec-01 (work in progress), October 2014. 1740 [Nagy14] Nagy, M., Singh, V., Ott, J., and L. Eggert, "Congestion 1741 Control using FEC for Conversational Multimedia 1742 Communication", Proc. of 5th ACM Internation Conference on 1743 Multimedia Systems (MMSys 2014) , 3 2014. 1745 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1746 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1748 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1749 for Generic Forward Error Correction", RFC 2733, December 1750 1999. 1752 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1753 Announcement Protocol", RFC 2974, October 2000. 1755 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1756 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1757 RFC 3711, March 2004. 1759 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1760 Internet Protocol", RFC 4301, December 2005. 1762 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1763 Correction", RFC 5109, December 2007. 1765 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1766 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1768 [SMPTE2022-1] 1769 SMPTE 2022-1-2007, , "Forward Error Correction for Real- 1770 Time Video/Audio Transport over IP Networks", 2007. 1772 Authors' Addresses 1774 Varun Singh 1775 Aalto University 1776 Espoo, FIN 1777 Finland 1779 Email: varun@comnet.tkk.fi 1781 Ali Begen 1782 Cisco Systems 1783 181 Bay Street 1784 Toronto, ON M5J 2T3 1785 Canada 1787 Email: abegen@cisco.com 1788 Mo Zanaty 1789 Cisco 1790 Raleigh, NC 1791 USA 1793 Email: mzanaty@cisco.com