idnits 2.17.1 draft-singh-payload-rtp-1d2d-parity-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 (October 1, 2014) is 3495 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 504, but not defined == Missing Reference: '48-111' is mentioned on line 507, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1064, 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-00 -- 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: April 4, 2015 Cisco Systems 6 M. Zanaty 7 Cisco 8 October 1, 2014 10 RTP Payload Format for Non-Interleaved and Interleaved Parity Forward 11 Error Correction (FEC) 12 draft-singh-payload-rtp-1d2d-parity-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 April 4, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . 37 106 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 107 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 108 12.1. draft-singh-payload-1d2d-parity-scheme-00 . . . . . . . 37 109 12.2. draft-ietf-fecframe-1d2d-parity-scheme-00 . . . . . . . 37 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 111 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 112 13.2. Informative References . . . . . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 115 1. Introduction 117 This document defines new RTP payload formats for the Forward Error 118 Correction (FEC) that is generated by the non-interleaved and 119 interleaved parity codes from a source media encapsulated in RTP 120 [RFC3550]. The type of the source media protected by these parity 121 codes can be audio, video, text or application. The FEC data are 122 generated according to the media type parameters, which are 123 communicated out-of-band (e.g., in SDP). Furthermore, the 124 associations or relationships between the source and repair flows may 125 be communicated in-band or out-of-band. Situtations where 126 adaptivitiy of FEC parameters is desired, the endpoint can use the 127 in-band mechanism, whereas when the FEC parameters are fixed, the 128 endpoint may prefer to negotiate them out-of-band. 130 Both the non-interleaved and interleaved parity codes use the 131 eXclusive OR (XOR) operation to generate the repair symbols. In a 132 nutshell, the following steps take place: 134 1. The sender determines a set of source packets to be protected by 135 FEC based on the media type parameters. 137 2. The sender applies the XOR operation on the source symbols to 138 generate the required number of repair symbols. 140 3. The sender packetizes the repair symbols and sends the repair 141 packet(s) along with the source packets to the receiver(s) (in 142 different flows). The repair packets may be sent proactively or 143 on-demand. 145 Note that the source and repair packets belong to different source 146 and repair flows, and the sender must provide a way for the receivers 147 to demultiplex them, even in the case they are sent in the same 148 5-tuple (i.e., same source/destination address/port with UDP). This 149 is required to offer backward compatibility for endpoints that do not 150 understand the FEC packets (See Section 4). At the receiver side, if 151 all of the source packets are successfully received, there is no need 152 for FEC recovery and the repair packets are discarded. However, if 153 there are missing source packets, the repair packets can be used to 154 recover the missing information. Figure 1 and Figure 2 describe 155 example block diagrams for the systematic parity FEC encoder and 156 decoder, respectively. 158 +------------+ 159 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 160 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 161 | Encoder | 162 | (Sender) | --> +==+ +==+ 163 +------------+ +==+ +==+ 165 Source Packet: +--+ Repair Packet: +==+ 166 +--+ +==+ 168 Figure 1: Block diagram for systematic parity FEC encoder 170 +------------+ 171 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 172 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 173 | Decoder | 174 +==+ +==+ --> | (Receiver) | 175 +==+ +==+ +------------+ 177 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 178 +--+ +==+ 180 Figure 2: Block diagram for systematic parity FEC decoder 182 In Figure 2, it is clear that the FEC packets have to be received by 183 the endpoint within a certain amount of time for the FEC recovery 184 process to be useful. In this document, we refer to the time that 185 spans a FEC block, which consists of the source packets and the 186 corresponding repair packets, as the repair window. At the receiver 187 side, the FEC decoder should wait at least for the duration of the 188 repair window after getting the first packet in a FEC block, to allow 189 all the repair packets to arrive. (The waiting time can be adjusted 190 if there are missing packets at the beginning of the FEC block.) The 191 FEC decoder can start decoding the already received packets sooner; 192 however, it should not register a FEC decoding failure until it waits 193 at least for the duration of the repair window. 195 Suppose that we have a group of D x L source packets that have 196 sequence numbers starting from 1 running to D x L, and a repair 197 packet is generated by applying the XOR operation to every L 198 consecutive packets as sketched in Figure 3. This process is 199 referred to as 1-D non-interleaved FEC protection. As a result of 200 this process, D repair packets are generated, which we refer to as 201 non-interleaved (or row) FEC packets. 203 +--------------------------------------------------+ --- +===+ 204 | S_1 S_2 S3 ... S_L | + |XOR| = |R_1| 205 +--------------------------------------------------+ --- +===+ 206 +--------------------------------------------------+ --- +===+ 207 | S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2| 208 +--------------------------------------------------+ --- +===+ 209 . . . . . . 210 . . . . . . 211 . . . . . . 212 +--------------------------------------------------+ --- +===+ 213 | S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D| 214 +--------------------------------------------------+ --- +===+ 216 Figure 3: Generating non-interleaved (row) FEC packets 218 If we apply the XOR operation to the group of the source packets 219 whose sequence numbers are L apart from each other, as sketched in 220 Figure 4. In this case the endpoint generates L repair packets. 221 This process is referred to as 1-D interleaved FEC protection, and 222 the resulting L repair packets are referred to as interleaved (or 223 column) FEC packets. 225 +-------------+ +-------------+ +-------------+ +-------+ 226 | S_1 | | S_2 | | S3 | ... | S_L | 227 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 228 | . | | . | | | | | 229 | . | | . | | | | | 230 | . | | . | | | | | 231 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 232 +-------------+ +-------------+ +-------------+ +-------+ 233 + + + + 234 ------------- ------------- ------------- ------- 235 | XOR | | XOR | | XOR | ... | XOR | 236 ------------- ------------- ------------- ------- 237 = = = = 238 +===+ +===+ +===+ +===+ 239 |C_1| |C_2| |C_3| ... |C_L| 240 +===+ +===+ +===+ +===+ 242 Figure 4: Generating interleaved (column) FEC packets 244 1.1. Use Cases for 1-D FEC Protection 246 We generate one non-interleaved repair packet out of L consecutive 247 source packets or one interleaved repair packet out of D non- 248 consecutive source packets. Regardless of whether the repair packet 249 is a non-interleaved or an interleaved one, it can provide a full 250 recovery of the missing information if there is only one packet 251 missing among the corresponding source packets. This implies that 252 1-D non-interleaved FEC protection performs better when the source 253 packets are randomly lost. However, if the packet losses occur in 254 bursts, 1-D interleaved FEC protection performs better provided that 255 L is chosen large enough, i.e., L-packet duration is not shorter than 256 the observed burst duration. If the sender generates non-interleaved 257 FEC packets and a burst loss hits the source packets, the repair 258 operation fails. This is illustrated in Figure 5. 260 +---+ +---+ +===+ 261 | 1 | X X | 4 | |R_1| 262 +---+ +---+ +===+ 264 +---+ +---+ +---+ +---+ +===+ 265 | 5 | | 6 | | 7 | | 8 | |R_2| 266 +---+ +---+ +---+ +---+ +===+ 268 +---+ +---+ +---+ +---+ +===+ 269 | 9 | | 10| | 11| | 12| |R_3| 270 +---+ +---+ +---+ +---+ +===+ 272 Figure 5: Example scenario where 1-D non-interleaved FEC protection 273 fails error recovery (Burst Loss) 275 The sender may generate interleaved FEC packets to combat with the 276 bursty packet losses. However, two or more random packet losses may 277 hit the source and repair packets in the same column. In that case, 278 the repair operation fails as well. This is illustrated in Figure 6. 279 Note that it is possible that two burst losses may occur back-to- 280 back, in which case interleaved FEC packets may still fail to recover 281 the lost data. 283 +---+ +---+ +---+ 284 | 1 | X | 3 | | 4 | 285 +---+ +---+ +---+ 287 +---+ +---+ +---+ 288 | 5 | X | 7 | | 8 | 289 +---+ +---+ +---+ 291 +---+ +---+ +---+ +---+ 292 | 9 | | 10| | 11| | 12| 293 +---+ +---+ +---+ +---+ 295 +===+ +===+ +===+ +===+ 296 |C_1| |C_2| |C_3| |C_4| 297 +===+ +===+ +===+ +===+ 299 Figure 6: Example scenario where 1-D interleaved FEC protection fails 300 error recovery (Periodic Loss) 302 1.2. Use Cases for 2-D Parity FEC Protection 304 In networks where the source packets are lost both randomly and in 305 bursts, the sender ought to generate both non-interleaved and 306 interleaved FEC packets. This type of FEC protection is known as 2-D 307 parity FEC protection. At the expense of generating more FEC 308 packets, thus increasing the FEC overhead, 2-D FEC provides superior 309 protection against mixed loss patterns. However, it is still 310 possible for 2-D parity FEC protection to fail to recover all of the 311 lost source packets if a particular loss pattern occurs. An example 312 scenario is illustrated in Figure 7. 314 +---+ +---+ +===+ 315 | 1 | X X | 4 | |R_1| 316 +---+ +---+ +===+ 318 +---+ +---+ +---+ +---+ +===+ 319 | 5 | | 6 | | 7 | | 8 | |R_2| 320 +---+ +---+ +---+ +---+ +===+ 322 +---+ +---+ +===+ 323 | 9 | X X | 12| |R_3| 324 +---+ +---+ +===+ 326 +===+ +===+ +===+ +===+ 327 |C_1| |C_2| |C_3| |C_4| 328 +===+ +===+ +===+ +===+ 330 Figure 7: Example scenario #1 where 2-D parity FEC protection fails 331 error recovery 333 2-D parity FEC protection also fails when at least two rows are 334 missing a source and the FEC packet and the missing source packets 335 (in at least two rows) are aligned in the same column. An example 336 loss pattern is sketched in Figure 8. Similarly, 2-D parity FEC 337 protection cannot repair all missing source packets when at least two 338 columns are missing a source and the FEC packet and the missing 339 source packets (in at least two columns) are aligned in the same row. 341 +---+ +---+ +---+ 342 | 1 | | 2 | X | 4 | X 343 +---+ +---+ +---+ 345 +---+ +---+ +---+ +---+ +===+ 346 | 5 | | 6 | | 7 | | 8 | |R_2| 347 +---+ +---+ +---+ +---+ +===+ 349 +---+ +---+ +---+ 350 | 9 | | 10| X | 12| X 351 +---+ +---+ +---+ 353 +===+ +===+ +===+ +===+ 354 |C_1| |C_2| |C_3| |C_4| 355 +===+ +===+ +===+ +===+ 357 Figure 8: Example scenario #2 where 2-D parity FEC protection fails 358 error recovery 360 1.3. Overhead Computation 362 The overhead is defined as the ratio of the number of bytes belonging 363 to the repair packets to the number of bytes belonging to the 364 protected source packets. 366 Generally, repair packets are larger in size compared to the source 367 packets. Also, not all the source packets are necessarily equal in 368 size. However, if we assume that each repair packet carries an equal 369 number of bytes carried by a source packet, we can compute the 370 overhead for different FEC protection methods as follows: 372 o 1-D Non-interleaved FEC Protection: Overhead = 1/L 374 o 1-D Interleaved FEC Protection: Overhead = 1/D 376 o 2-D Parity FEC Protection: Overhead = 1/L + 1/D 378 where L and D are the number of columns and rows in the source block, 379 respectively. 381 2. Requirements Notation 383 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 384 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 385 document are to be interpreted as described in [RFC2119]. 387 3. Definitions and Notations 389 3.1. Definitions 391 This document uses a number of definitions from [RFC6363]. 393 3.2. Notations 395 o L: Number of columns of the source block. 397 o D: Number of rows of the source block. 399 o bitmask: Run-length encoding of packets protected by a FEC packet. 400 If the bit i in the mask is set to 1, the source packet number N + 401 i is protected by this FEC packet. Here, N is the sequence number 402 base, which is indicated in the FEC packet as well. 404 4. Packet Formats 406 This section defines the formats of the source and repair packets. 408 4.1. Source Packets 410 The source packets MUST contain the information that identifies the 411 source block and the position within the source block occupied by the 412 packet. Since the source packets that are carried within an RTP 413 stream already contain unique sequence numbers in their RTP headers 414 [RFC3550], we can identify the source packets in a straightforward 415 manner and there is no need to append additional field(s). The 416 primary advantage of not modifying the source packets in any way is 417 that it provides backward compatibility for the receivers that do not 418 support FEC at all. In multicast scenarios, this backward 419 compatibility becomes quite useful as it allows the non-FEC-capable 420 and FEC-capable receivers to receive and interpret the same source 421 packets sent in the same multicast session. 423 4.2. Repair Packets 425 The repair packets MUST contain information that identifies the 426 source block they pertain to and the relationship between the 427 contained repair symbols and the original source block. For this 428 purpose, we use the RTP header of the repair packets as well as 429 another header within the RTP payload, which we refer to as the FEC 430 header, as shown in Figure 9. 432 +------------------------------+ 433 | IP Header | 434 +------------------------------+ 435 | Transport Header | 436 +------------------------------+ 437 | RTP Header | __ 438 +------------------------------+ | 439 | FEC Header | \ 440 +------------------------------+ > RTP Payload 441 | Repair Symbols | / 442 +------------------------------+ __| 444 Figure 9: Format of repair packets 446 The RTP header is formatted according to [RFC3550] with some further 447 clarifications listed below: 449 o Marker (M) Bit: This bit is not used for this payload type, and 450 SHALL be set to 0. 452 o Payload Type: The (dynamic) payload type for the repair packets is 453 determined through out-of-band means. Note that this document 454 registers new payload formats for the repair packets (Refer to 455 Section 5 for details). According to [RFC3550], an RTP receiver 456 that cannot recognize a payload type must discard it. This 457 provides backward compatibility. If a non-FEC-capable receiver 458 receives a repair packet, it will not recognize the payload type, 459 and hence, will discard the repair packet. 461 o Sequence Number (SN): The sequence number has the standard 462 definition. It MUST be one higher than the sequence number in the 463 previously transmitted repair packet. The initial value of the 464 sequence number SHOULD be random (unpredictable, based on 465 [RFC3550]). 467 o Timestamp (TS): The timestamp SHALL be set to a time corresponding 468 to the repair packet's transmission time. Note that the timestamp 469 value has no use in the actual FEC protection process and is 470 usually useful for jitter calculations. 472 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 473 assigned as suggested by [RFC3550]. This allows the sender to 474 multiplex the source and repair flows on the same port, or 475 multiplex multiple repair flows on a single port. The repair 476 flows SHOULD use the RTCP CNAME field to associate themselves with 477 the source flow. 479 In some networks, the RTP Source, which produces the source 480 packets and the FEC Source, which generates the repair packets 481 from the source packets may not be the same host. In such 482 scenarios, using the same CNAME for the source and repair flows 483 means that the RTP Source and the FEC Source MUST share the same 484 CNAME (for this specific source-repair flow association). A 485 common CNAME may be produced based on an algorithm that is known 486 both to the RTP and FEC Source [RFC7022]. This usage is compliant 487 with [RFC3550]. 489 Note that due to the randomness of the SSRC assignments, there is 490 a possibility of SSRC collision. In such cases, the collisions 491 MUST be resolved as described in [RFC3550]. 493 The format of the FEC header is shown in Figure 10. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |MSK|P|X| CC |M| PT recovery | SN base | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | TS recovery | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | length recovery |M or Mask[8-15]| N or Mask[0-7]| 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Mask [16-47] (optional) | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | | 507 + Mask [48-111] (optional) + 508 | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 10: Format of the FEC header 513 The FEC header consists of the following fields: 515 o The MSK field (2 bits) indicates the type of the mask. Namely: 517 +---------------+-------------------------------------+ 518 | MSK bits | Use | 519 +---------------+-------------------------------------+ 520 | 00 | 16-bit mask | 521 | 01 | 48-bit mask | 522 | 10 | 112-bit mask | 523 | 11 | packets indicated by offset M and N | 524 +---------------+-------------------------------------+ 526 Figure 11: MSK bit values 528 o The P, X, CC, M and PT recovery fields are used to determine the 529 corresponding fields of the recovered packets. 531 o The SN base field is used to indicate the lowest sequence number, 532 taking wrap around into account, of those source packets protected 533 by this repair packet. 535 o The TS recovery field is used to determine the timestamp of the 536 recovered packets. 538 o The Length recovery field is used to determine the length of the 539 recovered packets. 541 o Mask is a run-length encoding of packets protected by the FEC 542 packet. Where a bit i set to 1 indicates that the source packet 543 with sequence number (SN base + i) is protected by this FEC 544 packet. 546 o If the the MSK field is set to 11, it indicates the offset of 547 packets protected by this FEC packet. Consequently, the following 548 conditions may occur: 550 If M=0, N=0, regular protection pattern code with the values of 551 L and D are indicared in the SDP description. 552 If M>0, N=0, indicates a non-interleaved (row) FEC of M packets 553 starting at SN base. 554 Hence, FEC = SN, SN+1, SN+2, ... , SN+(M-1), SN+M. 555 If M>0, N>0, indicates interleaved (column) FEC of every M packet 556 in a group of N packets starting at SN base. 557 Hence, FEC = SN+(Mx0), SN+(Mx1), ... , SN+(MxN). 559 Figure 12: Interpreting the M and N field values 561 The details on setting the fields in the FEC header are provided in 562 Section 6.2. 564 It should be noted that a mask-based approach (similar to the ones 565 specified in [RFC2733] and [RFC5109]) may not be very efficient to 566 indicate which source packets in the current source block are 567 associated with a given repair packet. In particular, for the 568 applications that would like to use large source block sizes, the 569 size of the mask that is required to describe the source-repair 570 packet associations may be prohibitively large. The 8-bit fields 571 proposed in [SMPTE2022-1] indicate a systematized approach. Instead 572 the approach in this document uses the 8-bit fields to indicate 573 packet offsets protected by the FEC packet. The approach in 574 [SMPTE2022-1] is inherently more efficient for regular patterns, it 575 does not provide flexibility to represent other protection patterns 576 (e.g., staircase). 578 5. Payload Format Parameters 580 This section provides the media subtype registration for the non- 581 interleaved and interleaved parity FEC. The parameters that are 582 required to configure the FEC encoding and decoding operations are 583 also defined in this section. 585 5.1. Media Type Registration 587 This registration is done using the template defined in [RFC6838] and 588 following the guidance provided in [RFC3555]. 590 Note to the RFC Editor: In the following sections, please replace 591 "XXXX" with the number of this document prior to publication as an 592 RFC. 594 5.1.1. Registration of audio/non-interleaved-parityfec 596 Type name: audio 598 Subtype name: non-interleaved-parityfec 600 Required parameters: 602 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 603 than 1000 Hz to provide sufficient resolution to RTCP operations. 604 However, it is RECOMMENDED to select the rate that matches the 605 rate of the protected source RTP stream. 607 o L: Number of columns of the source block. L is a positive 608 integer. 610 o D: Number of rows of the source block. D is a positive integer. 612 o ToP: Type of the protection applied by the sender: 0 for 1-D 613 interleaved FEC protection, 1 for 1-D non-interleaved FEC 614 protection, and 2 for 2-D parity FEC protection. The ToP value of 615 3 is reserved for future uses. 617 o repair-window: The time that spans the source packets and the 618 corresponding repair packets. The size of the repair window is 619 specified in microseconds. 621 Optional parameters: None. 623 Encoding considerations: This media type is framed (See Section 4.8 624 in the template document [RFC6838]) and contains binary data. 626 Security considerations: See Section 9 of [RFCXXXX]. 628 Interoperability considerations: None. 630 Published specification: [RFCXXXX]. 632 Applications that use this media type: Multimedia applications that 633 want to improve resiliency against packet loss by sending redundant 634 data in addition to the source media. 636 Fragment identifier considerations: None. 638 Additional information: None. 640 Person & email address to contact for further information: Varun 641 Singh and IETF Audio/Video Transport Payloads 642 Working Group. 644 Intended usage: COMMON. 646 Restriction on usage: This media type depends on RTP framing, and 647 hence, is only defined for transport via RTP [RFC3550]. 649 Author: Varun Singh . 651 Change controller: IETF Audio/Video Transport Working Group delegated 652 from the IESG. 654 Provisional registration? (standards tree only): Yes. 656 5.1.2. Registration of video/non-interleaved-parityfec 658 Type name: video 660 Subtype name: non-interleaved-parityfec 662 Required parameters: 664 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 665 than 1000 Hz to provide sufficient resolution to RTCP operations. 666 However, it is RECOMMENDED to select the rate that matches the 667 rate of the protected source RTP stream. 669 o L: Number of columns of the source block. L is a positive 670 integer. 672 o D: Number of rows of the source block. D is a positive integer. 674 o ToP: Type of the protection applied by the sender: 0 for 1-D 675 interleaved FEC protection, 1 for 1-D non-interleaved FEC 676 protection, and 2 for 2-D parity FEC protection. The ToP value of 677 3 is reserved for future uses. 679 o repair-window: The time that spans the source packets and the 680 corresponding repair packets. The size of the repair window is 681 specified in microseconds. 683 Optional parameters: None. 685 Encoding considerations: This media type is framed (See Section 4.8 686 in the template document [RFC6838]) and contains binary data. 688 Security considerations: See Section 9 of [RFCXXXX]. 690 Interoperability considerations: None. 692 Published specification: [RFCXXXX]. 694 Applications that use this media type: Multimedia applications that 695 want to improve resiliency against packet loss by sending redundant 696 data in addition to the source media. 698 Fragment identifier considerations: None. 700 Additional information: None. 702 Person & email address to contact for further information: Varun 703 Singh and IETF Audio/Video Transport Payloads 704 Working Group. 706 Intended usage: COMMON. 708 Restriction on usage: This media type depends on RTP framing, and 709 hence, is only defined for transport via RTP [RFC3550]. 711 Author: Varun Singh . 713 Change controller: IETF Audio/Video Transport Working Group delegated 714 from the IESG. 716 Provisional registration? (standards tree only): Yes. 718 5.1.3. Registration of text/non-interleaved-parityfec 720 Type name: text 722 Subtype name: non-interleaved-parityfec 724 Required parameters: 726 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 727 than 1000 Hz to provide sufficient resolution to RTCP operations. 728 However, it is RECOMMENDED to select the rate that matches the 729 rate of the protected source RTP stream. 731 o L: Number of columns of the source block. L is a positive 732 integer. 734 o D: Number of rows of the source block. D is a positive integer. 736 o ToP: Type of the protection applied by the sender: 0 for 1-D 737 interleaved FEC protection, 1 for 1-D non-interleaved FEC 738 protection, and 2 for 2-D parity FEC protection. The ToP value of 739 3 is reserved for future uses. 741 o repair-window: The time that spans the source packets and the 742 corresponding repair packets. The size of the repair window is 743 specified in microseconds. 745 Optional parameters: None. 747 Encoding considerations: This media type is framed (See Section 4.8 748 in the template document [RFC6838]) and contains binary data. 750 Security considerations: See Section 9 of [RFCXXXX]. 752 Interoperability considerations: None. 754 Published specification: [RFCXXXX]. 756 Applications that use this media type: Multimedia applications that 757 want to improve resiliency against packet loss by sending redundant 758 data in addition to the source media. 760 Fragment identifier considerations: None. 762 Additional information: None. 764 Person & email address to contact for further information: Varun 765 Singh and IETF Audio/Video Transport Payloads 766 Working Group. 768 Intended usage: COMMON. 770 Restriction on usage: This media type depends on RTP framing, and 771 hence, is only defined for transport via RTP [RFC3550]. 773 Author: Varun Singh . 775 Change controller: IETF Audio/Video Transport Working Group delegated 776 from the IESG. 778 Provisional registration? (standards tree only): Yes. 780 5.1.4. Registration of application/non-interleaved-parityfec 782 Type name: application 784 Subtype name: non-interleaved-parityfec 786 Required parameters: 788 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 789 than 1000 Hz to provide sufficient resolution to RTCP operations. 790 However, it is RECOMMENDED to select the rate that matches the 791 rate of the protected source RTP stream. 793 o L: Number of columns of the source block. L is a positive 794 integer. 796 o D: Number of rows of the source block. D is a positive integer. 798 o ToP: Type of the protection applied by the sender: 0 for 1-D 799 interleaved FEC protection, 1 for 1-D non-interleaved FEC 800 protection, and 2 for 2-D parity FEC protection. The ToP value of 801 3 is reserved for future uses. 803 o repair-window: The time that spans the source packets and the 804 corresponding repair packets. The size of the repair window is 805 specified in microseconds. 807 Optional parameters: None. 809 Encoding considerations: This media type is framed (See Section 4.8 810 in the template document [RFC6838]) and contains binary data. 812 Security considerations: See Section 9 of [RFCXXXX]. 814 Interoperability considerations: None. 816 Published specification: [RFCXXXX]. 818 Applications that use this media type: Multimedia applications that 819 want to improve resiliency against packet loss by sending redundant 820 data in addition to the source media. 822 Fragment identifier considerations: None. 824 Additional information: None. 826 Person & email address to contact for further information: Varun 827 Singh and IETF Audio/Video Transport Payloads 828 Working Group. 830 Intended usage: COMMON. 832 Restriction on usage: This media type depends on RTP framing, and 833 hence, is only defined for transport via RTP [RFC3550]. 835 Author: Varun Singh . 837 Change controller: IETF Audio/Video Transport Working Group delegated 838 from the IESG. 840 Provisional registration? (standards tree only): Yes. 842 5.1.5. Registration of audio/interleaved-parityfec 844 Type name: audio 846 Subtype name: interleaved-parityfec 848 Required parameters: 850 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 851 than 1000 Hz to provide sufficient resolution to RTCP operations. 852 However, it is RECOMMENDED to select the rate that matches the 853 rate of the protected source RTP stream. 855 o L: Number of columns of the source block. L is a positive 856 integer. 858 o D: Number of rows of the source block. D is a positive integer. 860 o ToP: Type of the protection applied by the sender: 0 for 1-D 861 interleaved FEC protection, 1 for 1-D non-interleaved FEC 862 protection, and 2 for 2-D parity FEC protection. The ToP value of 863 3 is reserved for future uses. 865 o repair-window: The time that spans the source packets and the 866 corresponding repair packets. The size of the repair window is 867 specified in microseconds. 869 Optional parameters: None. 871 Encoding considerations: This media type is framed (See Section 4.8 872 in the template document [RFC6838]) and contains binary data. 874 Security considerations: See Section 9 of [RFCXXXX]. 876 Interoperability considerations: None. 878 Published specification: [RFCXXXX]. 880 Applications that use this media type: Multimedia applications that 881 want to improve resiliency against packet loss by sending redundant 882 data in addition to the source media. 884 Fragment identifier considerations: None. 886 Additional information: None. 888 Person & email address to contact for further information: Varun 889 Singh and IETF Audio/Video Transport Payloads 890 Working Group. 892 Intended usage: COMMON. 894 Restriction on usage: This media type depends on RTP framing, and 895 hence, is only defined for transport via RTP [RFC3550]. 897 Author: Varun Singh . 899 Change controller: IETF Audio/Video Transport Working Group delegated 900 from the IESG. 902 Provisional registration? (standards tree only): Yes. 904 5.1.6. Registration of video/interleaved-parityfec 906 Type name: video 908 Subtype name: interleaved-parityfec 910 Required parameters: 912 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 913 than 1000 Hz to provide sufficient resolution to RTCP operations. 914 However, it is RECOMMENDED to select the rate that matches the 915 rate of the protected source RTP stream. 917 o L: Number of columns of the source block. L is a positive 918 integer. 920 o D: Number of rows of the source block. D is a positive integer. 922 o ToP: Type of the protection applied by the sender: 0 for 1-D 923 interleaved FEC protection, 1 for 1-D non-interleaved FEC 924 protection, and 2 for 2-D parity FEC protection. The ToP value of 925 3 is reserved for future uses. 927 o repair-window: The time that spans the source packets and the 928 corresponding repair packets. The size of the repair window is 929 specified in microseconds. 931 Optional parameters: None. 933 Encoding considerations: This media type is framed (See Section 4.8 934 in the template document [RFC6838]) and contains binary data. 936 Security considerations: See Section 9 of [RFCXXXX]. 938 Interoperability considerations: None. 940 Published specification: [RFCXXXX]. 942 Applications that use this media type: Multimedia applications that 943 want to improve resiliency against packet loss by sending redundant 944 data in addition to the source media. 946 Fragment identifier considerations: None. 948 Additional information: None. 950 Person & email address to contact for further information: Varun 951 Singh and IETF Audio/Video Transport Payloads 952 Working Group. 954 Intended usage: COMMON. 956 Restriction on usage: This media type depends on RTP framing, and 957 hence, is only defined for transport via RTP [RFC3550]. 959 Author: Varun Singh . 961 Change controller: IETF Audio/Video Transport Working Group delegated 962 from the IESG. 964 Provisional registration? (standards tree only): Yes. 966 5.1.7. Registration of text/interleaved-parityfec 968 Type name: text 970 Subtype name: interleaved-parityfec 972 Required parameters: 974 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 975 than 1000 Hz to provide sufficient resolution to RTCP operations. 976 However, it is RECOMMENDED to select the rate that matches the 977 rate of the protected source RTP stream. 979 o L: Number of columns of the source block. L is a positive 980 integer. 982 o D: Number of rows of the source block. D is a positive integer. 984 o ToP: Type of the protection applied by the sender: 0 for 1-D 985 interleaved FEC protection, 1 for 1-D non-interleaved FEC 986 protection, and 2 for 2-D parity FEC protection. The ToP value of 987 3 is reserved for future uses. 989 o repair-window: The time that spans the source packets and the 990 corresponding repair packets. The size of the repair window is 991 specified in microseconds. 993 Optional parameters: None. 995 Encoding considerations: This media type is framed (See Section 4.8 996 in the template document [RFC6838]) and contains binary data. 998 Security considerations: See Section 9 of [RFCXXXX]. 1000 Interoperability considerations: None. 1002 Published specification: [RFCXXXX]. 1004 Applications that use this media type: Multimedia applications that 1005 want to improve resiliency against packet loss by sending redundant 1006 data in addition to the source media. 1008 Fragment identifier considerations: None. 1010 Additional information: None. 1012 Person & email address to contact for further information: Varun 1013 Singh and IETF Audio/Video Transport Payloads 1014 Working Group. 1016 Intended usage: COMMON. 1018 Restriction on usage: This media type depends on RTP framing, and 1019 hence, is only defined for transport via RTP [RFC3550]. 1021 Author: Varun Singh . 1023 Change controller: IETF Audio/Video Transport Working Group delegated 1024 from the IESG. 1026 Provisional registration? (standards tree only): Yes. 1028 5.1.8. Registration of application/interleaved-parityfec 1030 Type name: application 1032 Subtype name: interleaved-parityfec 1034 Required parameters: 1036 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 1037 than 1000 Hz to provide sufficient resolution to RTCP operations. 1038 However, it is RECOMMENDED to select the rate that matches the 1039 rate of the protected source RTP stream. 1041 o L: Number of columns of the source block. L is a positive 1042 integer. 1044 o D: Number of rows of the source block. D is a positive integer. 1046 o ToP: Type of the protection applied by the sender: 0 for 1-D 1047 interleaved FEC protection, 1 for 1-D non-interleaved FEC 1048 protection, and 2 for 2-D parity FEC protection. The ToP value of 1049 3 is reserved for future uses. 1051 o repair-window: The time that spans the source packets and the 1052 corresponding repair packets. The size of the repair window is 1053 specified in microseconds. 1055 Optional parameters: None. 1057 Encoding considerations: This media type is framed (See Section 4.8 1058 in the template document [RFC6838]) and contains binary data. 1060 Security considerations: See Section 9 of [RFCXXXX]. 1062 Interoperability considerations: None. 1064 Published specification: [RFCXXXX]. 1066 Applications that use this media type: Multimedia applications that 1067 want to improve resiliency against packet loss by sending redundant 1068 data in addition to the source media. 1070 Fragment identifier considerations: None. 1072 Additional information: None. 1074 Person & email address to contact for further information: Varun 1075 Singh and IETF Audio/Video Transport Payloads 1076 Working Group. 1078 Intended usage: COMMON. 1080 Restriction on usage: This media type depends on RTP framing, and 1081 hence, is only defined for transport via RTP [RFC3550]. 1083 Author: Varun Singh . 1085 Change controller: IETF Audio/Video Transport Working Group delegated 1086 from the IESG. 1088 Provisional registration? (standards tree only): Yes. 1090 5.2. Mapping to SDP Parameters 1092 Applications that are using RTP transport commonly use Session 1093 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 1094 The information that is used to specify the media types in an RTP 1095 session has specific mappings to the fields in an SDP description. 1096 In this section, we provide these mappings for the media subtypes 1097 registered by this document. Note that if an application does not 1098 use SDP to describe the RTP sessions, an appropriate mapping must be 1099 defined and used to specify the media types and their parameters for 1100 the control/description protocol employed by the application. 1102 The mapping of the media type specification for "non-interleaved- 1103 parityfec" and "interleaved-parityfec" and their parameters in SDP is 1104 as follows: 1106 o The media type (e.g., "application") goes into the "m=" line as 1107 the media name. 1109 o The media subtype goes into the "a=rtpmap" line as the encoding 1110 name. The RTP clock rate parameter ("rate") also goes into the 1111 "a=rtpmap" line as the clock rate. 1113 o The remaining required payload-format-specific parameters go into 1114 the "a=fmtp" line by copying them directly from the media type 1115 string as a semicolon-separated list of parameter=value pairs. 1117 SDP examples are provided in Section 7. 1119 5.2.1. Offer-Answer Model Considerations 1121 When offering 1-D interleaved parity FEC over RTP using SDP in an 1122 Offer/Answer model [RFC3264], the following considerations apply: 1124 o Each combination of the L and D parameters produces a different 1125 FEC data and is not compatible with any other combination. A 1126 sender application may desire to offer multiple offers with 1127 different sets of L and D values as long as the parameter values 1128 are valid. The receiver SHOULD normally choose the offer that has 1129 a sufficient amount of interleaving. If multiple such offers 1130 exist, the receiver may choose the offer that has the lowest 1131 overhead or the one that requires the smallest amount of 1132 buffering. The selection depends on the application requirements. 1134 o The value for the repair-window parameter depends on the L and D 1135 values and cannot be chosen arbitrarily. More specifically, L and 1136 D values determine the lower limit for the repair-window size. 1138 The upper limit of the repair-window size does not depend on the L 1139 and D values. 1141 o Although combinations with the same L and D values but with 1142 different repair-window sizes produce the same FEC data, such 1143 combinations are still considered different offers. The size of 1144 the repair-window is related to the maximum delay between the 1145 transmission of a source packet and the associated repair packet. 1146 This directly impacts the buffering requirement on the receiver 1147 side and the receiver must consider this when choosing an offer. 1149 o There are no optional format parameters defined for this payload. 1150 Any unknown option in the offer MUST be ignored and deleted from 1151 the answer. If FEC is not desired by the receiver, it can be 1152 deleted from the answer. 1154 5.2.2. Declarative Considerations 1156 In declarative usage, like SDP in the Real-time Streaming Protocol 1157 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 1158 [RFC2974], the following considerations apply: 1160 o The payload format configuration parameters are all declarative 1161 and a participant MUST use the configuration that is provided for 1162 the session. 1164 o More than one configuration may be provided (if desired) by 1165 declaring multiple RTP payload types. In that case, the receivers 1166 should choose the repair flow that is best for them. 1168 6. Protection and Recovery Procedures 1170 This section provides a complete specification of the 1-D and 2-D 1171 parity codes and their RTP payload formats. 1173 6.1. Overview 1175 The following sections specify the steps involved in generating the 1176 repair packets and reconstructing the missing source packets from the 1177 repair packets. 1179 6.2. Repair Packet Construction 1181 The RTP header of a repair packet is formed based on the guidelines 1182 given in Section 4.2. 1184 The FEC header includes 12 octets (or upto 28 octets when the longer 1185 optional masks are used). It is constructed by applying the XOR 1186 operation on the bit strings that are generated from the individual 1187 source packets protected by this particular repair packet. The set 1188 of the source packets that are associated with a given repair packet 1189 can be computed by the formula given in Section 6.3.1. 1191 The bit string is formed for each source packet by concatenating the 1192 following fields together in the order specified: 1194 o The first 64 bits of the RTP header (64 bits). 1196 o Unsigned network-ordered 16-bit representation of the source 1197 packet length in bytes minus 12 (for the fixed RTP header), i.e., 1198 the sum of the lengths of all the following if present: the CSRC 1199 list, extension header, RTP payload and RTP padding (16 bits). 1201 By applying the parity operation on the bit strings produced from the 1202 source packets, we generate the FEC bit string. The FEC header is 1203 generated from the FEC bit string as follows: 1205 o The first (most significant) 2 bits in the FEC bit string are 1206 skipped. The MSK bits in the FEC header are set to the 1207 appropriate value, i.e., it depends on the chosen bitmask length. 1209 o The next bit in the FEC bit string is written into the P recovery 1210 bit in the FEC header. 1212 o The next bit in the FEC bit string is written into the X recovery 1213 bit in the FEC header. 1215 o The next 4 bits of the FEC bit string are written into the CC 1216 recovery field in the FEC header. 1218 o The next bit is written into the M recovery bit in the FEC header. 1220 o The next 7 bits of the FEC bit string are written into the PT 1221 recovery field in the FEC header. 1223 o The next 16 bits are skipped. 1225 o The next 32 bits of the FEC bit string are written into the TS 1226 recovery field in the FEC header. 1228 o The next 16 bits are written into the length recovery field in the 1229 FEC header. 1231 o Depending on the chosen MSK value, the bit mask of appropriate 1232 length will be set to the appropriate values. 1234 As described in Section 4.2, the SN base field of the FEC header MUST 1235 be set to the lowest sequence number of the source packets protected 1236 by this repair packet. When MSK represents a bitmask (MSK=00,01,10), 1237 the SN base field corresponds to the lowest sequence number indicated 1238 in the bitmask. When MSK=11, the following considerations apply: 1) 1239 for the interleaved FEC packets, this corresponds to the lowest 1240 sequence number of the source packets that forms the column, 2) for 1241 the non-interleaved FEC packets, the SN base field MUST be set to the 1242 lowest sequence number of the source packets that forms the row. 1244 The repair packet payload consists of the bits that are generated by 1245 applying the XOR operation on the payloads of the source RTP packets. 1246 If the payload lengths of the source packets are not equal, each 1247 shorter packet MUST be padded to the length of the longest packet by 1248 adding octet 0's at the end. 1250 Due to this possible padding and mandatory FEC header, a repair 1251 packet has a larger size than the source packets it protects. This 1252 may cause problems if the resulting repair packet size exceeds the 1253 Maximum Transmission Unit (MTU) size of the path over which the 1254 repair flow is sent. 1256 6.3. Source Packet Reconstruction 1258 This section describes the recovery procedures that are required to 1259 reconstruct the missing source packets. The recovery process has two 1260 steps. In the first step, the FEC decoder determines which source 1261 and repair packets should be used in order to recover a missing 1262 packet. In the second step, the decoder recovers the missing packet, 1263 which consists of an RTP header and RTP payload. 1265 In the following, we describe the RECOMMENDED algorithms for the 1266 first and second steps. Based on the implementation, different 1267 algorithms MAY be adopted. However, the end result MUST be identical 1268 to the one produced by the algorithms described below. 1270 Note that the same algorithms are used by the 1-D parity codes, 1271 regardless of whether the FEC protection is applied over a column or 1272 a row. The 2-D parity codes, on the other hand, usually require 1273 multiple iterations of the procedures described here. This iterative 1274 decoding algorithm is further explained in Section 6.3.4. 1276 6.3.1. Associating the Source and Repair Packets 1278 We denote the set of the source packets associated with repair packet 1279 p* by set T(p*). Note that in a source block whose size is L columns 1280 by D rows, set T includes D source packets plus one repair packet for 1281 the FEC protection applied over a column, and L source packets plus 1282 one repair packet for the FEC protection applied over a row. Recall 1283 that 1-D interleaved and non-interleaved FEC protection can fully 1284 recover the missing information if there is only one source packet 1285 missing in set T. If there are more than one source packets missing 1286 in set T, 1-D FEC protection will not work. 1288 6.3.1.1. Signaled in SDP 1290 The first step is associating the source and repair packets. If the 1291 endpoint relies entirely on out-of-band signaling (MSK=11, and 1292 M=N=0), then this information may be inferred from the media type 1293 parameters specified in the SDP description. Furtheremore, the 1294 payload type field in the RTP header, assists the receiver 1295 distinguish an interleaved or non-interleaved FEC packet. 1297 Mathematically, for any received repair packet, p*, we can determine 1298 the sequence numbers of the source packets that are protected by this 1299 repair packet as follows: 1301 p*_snb + i * X_1 (modulo 65536) 1303 where p*_snb denotes the value in the SN base field of p*'s FEC 1304 header, X_1 is set to L and 1 for the interleaved and non-interleaved 1305 FEC packets, respectively, and 1307 0 <= i < X_2 1309 where X_2 is set to D and L for the interleaved and non-interleaved 1310 FEC packets, respectively. 1312 6.3.1.2. Using bitmasks 1314 When using fixed size bitmasks (16-, 48-, 112-bits), the SN base 1315 field in the FEC header indicates the lowest sequence number of the 1316 source packets that forms the FEC packet. Finally, the bits maked by 1317 "1" in the bitmask are offsets from the SN base and make up the rest 1318 of the packets protected by the FEC packet. The bitmasks are able to 1319 represent arbitrary protection patterns, for example, 1-D 1320 interleaved, 1-D non-interleaved, 2-D, staircase. 1322 6.3.1.3. Using M and N Offsets 1324 When value of M is non-zero, the 8-bit fields indicate the offset of 1325 packets protected by an interleaved (N>0) or non-interleaved (N=0) 1326 FEC packet. Using a combination of interleaved and non-interleaved 1327 FEC packets can form 2-D protection patterns. 1329 Mathematically, for any received repair packet, p*, we can determine 1330 the sequence numbers of the source packets that are protected by this 1331 repair packet are as follows: 1333 When N = 0: 1334 p*_snb, p*_snb+1,..., p*_snb+(M-1), p*_snb+M 1335 When N > 0: 1336 p*_snb, p*_snb+(Mx1), p*_snb+(Mx2),..., p*_snb+(Mx(N-1)), p*_snb+(MxN) 1338 6.3.2. Recovering the RTP Header 1340 For a given set T, the procedure for the recovery of the RTP header 1341 of the missing packet, whose sequence number is denoted by SEQNUM, is 1342 as follows: 1344 1. For each of the source packets that are successfully received in 1345 T, compute the 80-bit string by concatenating the first 64 bits 1346 of their RTP header and the unsigned network-ordered 16-bit 1347 representation of their length in bytes minus 12. 1349 2. For the repair packet in T, compute the FEC bit string from the 1350 first 80 bits of the FEC header. 1352 3. Calculate the recovered bit string as the XOR of the bit strings 1353 generated from all source packets in T and the FEC bit string 1354 generated from the repair packet in T. 1356 4. Create a new packet with the standard 12-byte RTP header and no 1357 payload. 1359 5. Set the version of the new packet to 2. Skip the first 2 bits 1360 in the recovered bit string. 1362 6. Set the Padding bit in the new packet to the next bit in the 1363 recovered bit string. 1365 7. Set the Extension bit in the new packet to the next bit in the 1366 recovered bit string. 1368 8. Set the CC field to the next 4 bits in the recovered bit string. 1370 9. Set the Marker bit in the new packet to the next bit in the 1371 recovered bit string. 1373 10. Set the Payload type in the new packet to the next 7 bits in the 1374 recovered bit string. 1376 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 1377 bits in the recovered bit string. 1379 12. Set the TS field in the new packet to the next 32 bits in the 1380 recovered bit string. 1382 13. Take the next 16 bits of the recovered bit string and set the 1383 new variable Y to whatever unsigned integer this represents 1384 (assuming network order). Convert Y to host order. Y 1385 represents the length of the new packet in bytes minus 12 (for 1386 the fixed RTP header), i.e., the sum of the lengths of all the 1387 following if present: the CSRC list, header extension, RTP 1388 payload and RTP padding. 1390 14. Set the SSRC of the new packet to the SSRC of the source RTP 1391 stream. 1393 This procedure recovers the header of an RTP packet up to (and 1394 including) the SSRC field. 1396 6.3.3. Recovering the RTP Payload 1398 Following the recovery of the RTP header, the procedure for the 1399 recovery of the RTP payload is as follows: 1401 1. Append Y bytes to the new packet. 1403 2. For each of the source packets that are successfully received in 1404 T, compute the bit string from the Y octets of data starting with 1405 the 13th octet of the packet. If any of the bit strings 1406 generated from the source packets has a length shorter than Y, 1407 pad them to that length. The padding of octet 0 MUST be added at 1408 the end of the bit string. Note that the information of the 1409 first 8 octets are protected by the FEC header. 1411 3. For the repair packet in T, compute the FEC bit string from the 1412 repair packet payload, i.e., the Y octets of data following the 1413 FEC header. Note that the FEC header may be 12, 16, 32 octets 1414 depending on the length of the bitmask. 1416 4. Calculate the recovered bit string as the XOR of the bit strings 1417 generated from all source packets in T and the FEC bit string 1418 generated from the repair packet in T. 1420 5. Append the recovered bit string (Y octets) to the new packet 1421 generated in Section 6.3.2. 1423 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection 1425 In 2-D parity FEC protection, the sender generates both non- 1426 interleaved and interleaved FEC packets to combat with the mixed loss 1427 patterns (random and bursty). At the receiver side, these FEC 1428 packets are used iteratively to overcome the shortcomings of the 1-D 1429 non-interleaved/interleaved FEC protection and improve the chances of 1430 full error recovery. 1432 The iterative decoding algorithm runs as follows: 1434 1. Set num_recovered_until_this_iteration to zero 1436 2. Set num_recovered_so_far to zero 1438 3. Recover as many source packets as possible by using the non- 1439 interleaved FEC packets as outlined in Section 6.3.2 and 1440 Section 6.3.3, and increase the value of num_recovered_so_far by 1441 the number of recovered source packets. 1443 4. Recover as many source packets as possible by using the 1444 interleaved FEC packets as outlined in Section 6.3.2 and 1445 Section 6.3.3, and increase the value of num_recovered_so_far by 1446 the number of recovered source packets. 1448 5. If num_recovered_so_far > num_recovered_until_this_iteration 1449 ---num_recovered_until_this_iteration = num_recovered_so_far 1450 ---Go to step 3 1451 Else 1452 ---Terminate 1454 The algorithm terminates either when all missing source packets are 1455 fully recovered or when there are still remaining missing source 1456 packets but the FEC packets are not able to recover any more source 1457 packets. For the example scenarios when the 2-D parity FEC 1458 protection fails full recovery, refer to Section 1.2. Upon 1459 termination, variable num_recovered_so_far has a value equal to the 1460 total number of recovered source packets. 1462 Example: 1464 Suppose that the receiver experienced the loss pattern sketched in 1465 Figure 13. 1467 +---+ +---+ +===+ 1468 X X | 3 | | 4 | |R_1| 1469 +---+ +---+ +===+ 1471 +---+ +---+ +---+ +---+ +===+ 1472 | 5 | | 6 | | 7 | | 8 | |R_2| 1473 +---+ +---+ +---+ +---+ +===+ 1475 +---+ +---+ +===+ 1476 | 9 | X X | 12| |R_3| 1477 +---+ +---+ +===+ 1479 +===+ +===+ +===+ +===+ 1480 |C_1| |C_2| |C_3| |C_4| 1481 +===+ +===+ +===+ +===+ 1483 Figure 13: Example loss pattern for the iterative decoding algorithm 1485 The receiver executes the iterative decoding algorithm and recovers 1486 source packets #1 and #11 in the first iteration. The resulting 1487 pattern is sketched in Figure 14. 1489 +---+ +---+ +---+ +===+ 1490 | 1 | X | 3 | | 4 | |R_1| 1491 +---+ +---+ +---+ +===+ 1493 +---+ +---+ +---+ +---+ +===+ 1494 | 5 | | 6 | | 7 | | 8 | |R_2| 1495 +---+ +---+ +---+ +---+ +===+ 1497 +---+ +---+ +---+ +===+ 1498 | 9 | X | 11| | 12| |R_3| 1499 +---+ +---+ +---+ +===+ 1501 +===+ +===+ +===+ +===+ 1502 |C_1| |C_2| |C_3| |C_4| 1503 +===+ +===+ +===+ +===+ 1505 Figure 14: The resulting pattern after the first iteration 1507 Since the if condition holds true, the receiver runs a new iteration. 1508 In the second iteration, source packets #2 and #10 are recovered, 1509 resulting in a full recovery as sketched in Figure 15. 1511 +---+ +---+ +---+ +---+ +===+ 1512 | 1 | | 2 | | 3 | | 4 | |R_1| 1513 +---+ +---+ +---+ +---+ +===+ 1515 +---+ +---+ +---+ +---+ +===+ 1516 | 5 | | 6 | | 7 | | 8 | |R_2| 1517 +---+ +---+ +---+ +---+ +===+ 1519 +---+ +---+ +---+ +---+ +===+ 1520 | 9 | | 10| | 11| | 12| |R_3| 1521 +---+ +---+ +---+ +---+ +===+ 1523 +===+ +===+ +===+ +===+ 1524 |C_1| |C_2| |C_3| |C_4| 1525 +===+ +===+ +===+ +===+ 1527 Figure 15: The resulting pattern after the second iteration 1529 7. SDP Examples 1531 This section provides two SDP [RFC4566] examples. The examples use 1532 the FEC grouping semantics defined in [RFC4756]. 1534 7.1. Example SDP for 1-D Parity FEC Protection 1536 In this example, we have one source video stream (mid:S1) and one FEC 1537 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 1538 S1 R1" line. The source and repair streams are sent to the same port 1539 on different multicast groups. The repair window is set to 200 ms. 1541 v=0 1542 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1543 s=1-D Interleaved Parity FEC Example 1544 t=0 0 1545 a=group:FEC S1 R1 1546 m=video 30000 RTP/AVP 100 1547 c=IN IP4 233.252.0.1/127 1548 a=rtpmap:100 MP2T/90000 1549 a=mid:S1 1550 m=application 30000 RTP/AVP 110 1551 c=IN IP4 233.252.0.2/127 1552 a=rtpmap:110 interleaved-parityfec/90000 1553 a=fmtp:110 L:5; D:10; ToP:0; repair-window:200000 1554 a=mid:R1 1556 7.2. Example SDP for 2-D Parity FEC Protection 1558 In this example, we have one source video stream (mid:S1) and two FEC 1559 repair streams (mid:R1 and mid:R2). We form one FEC group with the 1560 "a=group:FEC S1 R1 R2" line. The source and repair streams are sent 1561 to the same port on different multicast groups. The repair window is 1562 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 a=group:FEC S1 R1 R2 1569 m=video 30000 RTP/AVP 100 1570 c=IN IP4 233.252.0.1/127 1571 a=rtpmap:100 MP2T/90000 1572 a=mid:S1 1573 m=application 30000 RTP/AVP 110 1574 c=IN IP4 233.252.0.2/127 1575 a=rtpmap:110 interleaved-parityfec/90000 1576 a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 1577 a=mid:R1 1578 m=application 30000 RTP/AVP 111 1579 c=IN IP4 233.252.0.3/127 1580 a=rtpmap:111 non-interleaved-parityfec/90000 1581 a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 1582 a=mid:R2 1584 Note that the sender might be generating two repair flows carrying 1585 non-interleaved and interleaved FEC packets, however the receiver 1586 might be interested only in the interleaved FEC packets. The 1587 receiver can identify the repair flow carrying the desired repair 1588 data by checking the payload types associated with each repair flow 1589 described in the SDP description. 1591 8. Congestion Control Considerations 1593 FEC is an effective approach to provide applications resiliency 1594 against packet losses. However, in networks where the congestion is 1595 a major contributor to the packet loss, the potential impacts of 1596 using FEC SHOULD be considered carefully before injecting the repair 1597 flows into the network. In particular, in bandwidth-limited 1598 networks, FEC repair flows may consume most or all of the available 1599 bandwidth and consequently may congest the network. In such cases, 1600 the applications MUST NOT arbitrarily increase the amount of FEC 1601 protection since doing so may lead to a congestion collapse. If 1602 desired, stronger FEC protection MAY be applied only after the source 1603 rate has been reduced [I-D.singh-rmcat-adaptive-fec]. 1605 In a network-friendly implementation, an application SHOULD NOT send/ 1606 receive FEC repair flows if it knows that sending/receiving those FEC 1607 repair flows would not help at all in recovering the missing packets. 1608 However, it MAY still continue to use FEC if considered for bandwidth 1609 estimation instead of speculatively probe for additional capacity 1610 [Holmer13][Nagy14]. It is RECOMMENDED that the amount of FEC 1611 protection is adjusted dynamically based on the packet loss rate 1612 observed by the applications. 1614 In multicast scenarios, it may be difficult to optimize the FEC 1615 protection per receiver. If there is a large variation among the 1616 levels of FEC protection needed by different receivers, it is 1617 RECOMMENDED that the sender offers multiple repair flows with 1618 different levels of FEC protection and the receivers join the 1619 corresponding multicast sessions to receive the repair flow(s) that 1620 is best for them. 1622 Editor's note: Additional congestion control considerations regarding 1623 the use of 2-D parity codes should be added here. 1625 9. Security Considerations 1627 RTP packets using the payload format defined in this specification 1628 are subject to the security considerations discussed in the RTP 1629 specification [RFC3550] and in any applicable RTP profile. The main 1630 security considerations for the RTP packet carrying the RTP payload 1631 format defined within this memo are confidentiality, integrity and 1632 source authenticity. Confidentiality is achieved by encrypting the 1633 RTP payload. Integrity of the RTP packets is achieved through a 1634 suitable cryptographic integrity protection mechanism. Such a 1635 cryptographic system may also allow the authentication of the source 1636 of the payload. A suitable security mechanism for this RTP payload 1637 format should provide confidentiality, integrity protection, and at 1638 least source authentication capable of determining if an RTP packet 1639 is from a member of the RTP session. 1641 Note that the appropriate mechanism to provide security to RTP and 1642 payloads following this memo may vary. It is dependent on the 1643 application, transport and signaling protocol employed. Therefore, a 1644 single mechanism is not sufficient, although if suitable, using the 1645 Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 1646 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1647 Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may 1648 exist. 1650 10. IANA Considerations 1652 New media subtypes are subject to IANA registration. For the 1653 registration of the payload formats and their parameters introduced 1654 in this document, refer to Section 5. 1656 11. Acknowledgments 1658 Some parts of this document are borrowed from [RFC5109]. Thus, the 1659 author would like to thank the editor of [RFC5109] and those who 1660 contributed to [RFC5109]. 1662 12. Change Log 1664 12.1. draft-singh-payload-1d2d-parity-scheme-00 1666 This is the initial version, which is based on draft-ietf-fecframe- 1667 1d2d-parity-scheme-00. The following are the major changes compared 1668 to that document: 1670 o Updated packet format with 16-, 48-, 112- bitmask. 1672 o Updated the sections on: repair packet construction, source packet 1673 construction. 1675 o Updated the media type registration and aligned to RFC6838. 1677 12.2. draft-ietf-fecframe-1d2d-parity-scheme-00 1679 o Some details were added regarding the use of CNAME field. 1681 o Offer-Answer and Declarative Considerations sections have been 1682 completed. 1684 o Security Considerations section has been completed. 1686 o The timestamp field definition has changed. 1688 13. References 1690 13.1. Normative References 1692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1693 Requirement Levels", BCP 14, RFC 2119, March 1997. 1695 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1696 with Session Description Protocol (SDP)", RFC 3264, June 1697 2002. 1699 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1700 Jacobson, "RTP: A Transport Protocol for Real-Time 1701 Applications", STD 64, RFC 3550, July 2003. 1703 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1704 Payload Formats", RFC 3555, July 2003. 1706 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1707 Description Protocol", RFC 4566, July 2006. 1709 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 1710 Session Description Protocol", RFC 4756, November 2006. 1712 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 1713 Correction (FEC) Framework", RFC 6363, October 2011. 1715 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1716 Specifications and Registration Procedures", BCP 13, RFC 1717 6838, January 2013. 1719 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1720 "Guidelines for Choosing RTP Control Protocol (RTCP) 1721 Canonical Names (CNAMEs)", RFC 7022, September 2013. 1723 13.2. Informative References 1725 [Holmer13] 1726 Holmer, S., Shemer, M., and M. Paniconi, "Handling Packet 1727 Loss in WebRTC", Proc. of IEEE International Conference on 1728 Image Processing (ICIP 2013) , 9 2013. 1730 [I-D.singh-rmcat-adaptive-fec] 1731 Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion 1732 Control Using FEC for Conversational Media", draft-singh- 1733 rmcat-adaptive-fec-00 (work in progress), July 2014. 1735 [Nagy14] Nagy, M., Singh, V., Ott, J., and L. Eggert, "Congestion 1736 Control using FEC for Conversational Multimedia 1737 Communication", Proc. of 5th ACM Internation Conference on 1738 Multimedia Systems (MMSys 2014) , 3 2014. 1740 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1741 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1743 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1744 for Generic Forward Error Correction", RFC 2733, December 1745 1999. 1747 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1748 Announcement Protocol", RFC 2974, October 2000. 1750 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1751 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1752 RFC 3711, March 2004. 1754 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1755 Internet Protocol", RFC 4301, December 2005. 1757 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1758 Correction", RFC 5109, December 2007. 1760 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1761 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1763 [SMPTE2022-1] 1764 SMPTE 2022-1-2007, , "Forward Error Correction for Real- 1765 Time Video/Audio Transport over IP Networks", 2007. 1767 Authors' Addresses 1769 Varun Singh 1770 Aalto University 1771 Espoo, FIN 1772 Finland 1774 Email: varun@comnet.tkk.fi 1776 Ali Begen 1777 Cisco Systems 1778 181 Bay Street 1779 Toronto, ON M5J 2T3 1780 Canada 1782 Email: abegen@cisco.com 1784 Mo Zanaty 1785 Cisco 1786 Raleigh, NC 1787 USA 1789 Email: mzanaty@cisco.com