idnits 2.17.1 draft-ietf-payload-flexible-fec-scheme-08.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2018) is 2111 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: '0-14' is mentioned on line 639, but not defined == Missing Reference: '15-45' is mentioned on line 641, but not defined == Missing Reference: '46-109' is mentioned on line 643, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1017, but not defined == Unused Reference: 'RFC6709' is defined on line 1647, but no explicit reference was found in the text == Unused Reference: 'RFC2733' is defined on line 1669, but no explicit reference was found in the text == Unused Reference: 'SMPTE2022-1' is defined on line 1708, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 6709 -- 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 (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAYLOAD M. Zanaty 3 Internet-Draft Cisco 4 Intended status: Standards Track V. Singh 5 Expires: January 17, 2019 callstats.io 6 A. Begen 7 Networked Media 8 G. Mandyam 9 Qualcomm Innovation Center 10 July 16, 2018 12 RTP Payload Format for Flexible Forward Error Correction (FEC) 13 draft-ietf-payload-flexible-fec-scheme-08 15 Abstract 17 This document defines new RTP payload formats for the Forward Error 18 Correction (FEC) packets that are generated by the non-interleaved 19 and interleaved parity codes from source media encapsulated in RTP. 20 These parity codes are systematic codes, where a number of FEC repair 21 packets are generated from a set of source packets from one or more 22 source RTP streams. These FEC repair packets are sent in a 23 redundancy RTP stream separate from the source RTP stream(s) that 24 carries the source packets. RTP source packets that were lost in 25 transmission can be reconstructed using the source and repair packets 26 that were received. The non-interleaved and interleaved parity codes 27 which are defined in this specification offer a good protection 28 against random and bursty packet losses, respectively, at a cost of 29 decent complexity. The RTP payload formats that are defined in this 30 document address the scalability issues experienced with the earlier 31 specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and 32 offer several improvements. Due to these changes, the new payload 33 formats are not backward compatible with the earlier specifications, 34 but endpoints that do not implement this specification can still work 35 by simply ignoring the FEC repair packets. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 17, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1.1. 1-D Non-interleaved (Row) FEC Protection . . . . . . 5 74 1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 5 75 1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 6 76 1.1.4. 2-D (Row and Column) FEC Protection . . . . . . . . . 8 77 1.1.5. FEC Overhead Considerations . . . . . . . . . . . . . 9 78 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 9 79 3. Definitions and Notations . . . . . . . . . . . . . . . . . . 10 80 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 81 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10 82 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 11 84 4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 11 85 4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 12 86 4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 13 87 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18 88 5.1. Media Type Registration - Parity Codes . . . . . . . . . 18 89 5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 18 90 5.1.2. Registration of video/flexfec . . . . . . . . . . . . 20 91 5.1.3. Registration of text/flexfec . . . . . . . . . . . . 21 92 5.1.4. Registration of application/flexfec . . . . . . . . . 22 93 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 24 94 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 24 95 5.2.2. Declarative Considerations . . . . . . . . . . . . . 25 96 6. Protection and Recovery Procedures - Parity Codes . . . . . . 25 97 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26 98 6.2. Repair Packet Construction . . . . . . . . . . . . . . . 26 99 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 27 100 6.3.1. Associating the Source and Repair Packets . . . . . . 28 101 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 29 102 6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 31 103 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC 104 Protection . . . . . . . . . . . . . . . . . . . . . 31 105 7. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 106 7.1. Example SDP for Flexible FEC Protection with in-band SSRC 107 mapping . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 7.2. Example SDP for Flex FEC Protection with explicit 109 signalling in the SDP . . . . . . . . . . . . . . . . . . 34 110 8. Congestion Control Considerations . . . . . . . . . . . . . . 35 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 113 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 116 12.2. Informative References . . . . . . . . . . . . . . . . . 37 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 119 1. Introduction 121 This document defines new RTP payload formats for the Forward Error 122 Correction (FEC) that is generated by the non-interleaved and 123 interleaved parity codes from a source media encapsulated in RTP 124 [RFC3550]. The type of the source media protected by these parity 125 codes can be audio, video, text or application. The FEC data are 126 generated according to the media type parameters, which are 127 communicated out-of-band (e.g., in SDP). Furthermore, the 128 associations or relationships between the source and repair RTP 129 streams may be communicated in-band or out-of-band. The in-band 130 mechanism is advantageous when the endpoint is adapting the FEC 131 parameters. The out-of-band mechanism may be preferable when the FEC 132 parameters are fixed. 134 The Redunadncy RTP Stream [RFC7656] repair packets proposed in this 135 document protect the Source RTP Stream packets that belong to the 136 same RTP session. 138 1.1. Parity Codes 140 Both the non-interleaved and interleaved parity codes use the 141 eXclusive OR (XOR) operation to generate the repair packets. The 142 following steps take place: 144 1. The sender determines a set of source packets to be protected by 145 FEC based on the media type parameters. 147 2. The sender applies the XOR operation on the source packets to 148 generate the required number of repair packets. 150 3. The sender sends the repair packet(s) along with the source 151 packets, in different RTP streams, to the receiver(s). The 152 repair packets may be sent proactively or on-demand based on RTCP 153 feedback messages such as NACK [RFC4585]. 155 At the receiver side, if all of the source packets are successfully 156 received, there is no need for FEC recovery and the repair packets 157 are discarded. However, if there are missing source packets, the 158 repair packets can be used to recover the missing information. 159 Figure 1 and Figure 2 describe example block diagrams for the 160 systematic parity FEC encoder and decoder, respectively. 162 +------------+ 163 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 164 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 165 | Encoder | 166 | (Sender) | --> +==+ +==+ 167 +------------+ +==+ +==+ 169 Source Packet: +--+ Repair Packet: +==+ 170 +--+ +==+ 172 Figure 1: Block diagram for systematic parity FEC encoder 174 +------------+ 175 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 176 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 177 | Decoder | 178 +==+ +==+ --> | (Receiver) | 179 +==+ +==+ +------------+ 181 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 182 +--+ +==+ 184 Figure 2: Block diagram for systematic parity FEC decoder 186 In Figure 2, it is clear that the FEC repair packets have to be 187 received by the endpoint within a certain amount of time for the FEC 188 recovery process to be useful. The repair window is defined as the 189 time that spans a FEC block, which consists of the source packets and 190 the corresponding repair packets. At the receiver side, the FEC 191 decoder SHOULD buffer source and repair packets at least for the 192 duration of the repair window, to allow all the repair packets to 193 arrive. The FEC decoder can start decoding the already received 194 packets sooner; however, it should not register a FEC decoding 195 failure until it waits at least for the duration of the repair 196 window. 198 1.1.1. 1-D Non-interleaved (Row) FEC Protection 200 Consider a group of D x L source packets that have sequence numbers 201 starting from 1 running to D x L, and a repair packet is generated by 202 applying the XOR operation to every L consecutive packets as sketched 203 in Figure 3. This process is referred to as 1-D non-interleaved FEC 204 protection. As a result of this process, D repair packets are 205 generated, which are referred to as non-interleaved (or row) FEC 206 repair packets. 208 +--------------------------------------------------+ --- +===+ 209 | S_1 S_2 S3 ... S_L | + |XOR| = |R_1| 210 +--------------------------------------------------+ --- +===+ 211 +--------------------------------------------------+ --- +===+ 212 | S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2| 213 +--------------------------------------------------+ --- +===+ 214 . . . . . . 215 . . . . . . 216 . . . . . . 217 +--------------------------------------------------+ --- +===+ 218 | S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D| 219 +--------------------------------------------------+ --- +===+ 221 Figure 3: Generating non-interleaved (row) FEC repair packets 223 1.1.2. 1-D Interleaved (Column) FEC Protection 225 If the XOR operation is applied to the group of the source packets 226 whose sequence numbers are L apart from each other, as sketched in 227 Figure 4. In this case the endpoint generates L repair packets. 228 This process is referred to as 1-D interleaved FEC protection, and 229 the resulting L repair packets are referred to as interleaved (or 230 column) FEC repair packets. 232 +-------------+ +-------------+ +-------------+ +-------+ 233 | S_1 | | S_2 | | S3 | ... | S_L | 234 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 235 | . | | . | | | | | 236 | . | | . | | | | | 237 | . | | . | | | | | 238 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 239 +-------------+ +-------------+ +-------------+ +-------+ 240 + + + + 241 ------------- ------------- ------------- ------- 242 | XOR | | XOR | | XOR | ... | XOR | 243 ------------- ------------- ------------- ------- 244 = = = = 245 +===+ +===+ +===+ +===+ 246 |C_1| |C_2| |C_3| ... |C_L| 247 +===+ +===+ +===+ +===+ 249 Figure 4: Generating interleaved (column) FEC repair packets 251 1.1.3. Use Cases for 1-D FEC Protection 253 A sender may generate one non-interleaved repair packet out of L 254 consecutive source packets or one interleaved repair packet out of D 255 non-consecutive source packets. Regardless of whether the repair 256 packet is a non-interleaved or an interleaved one, it can provide a 257 full recovery of the missing information if there is only one packet 258 missing among the corresponding source packets. This implies that 259 1-D non-interleaved FEC protection performs better when the source 260 packets are randomly lost. However, if the packet losses occur in 261 bursts, 1-D interleaved FEC protection performs better provided that 262 L is chosen large enough, i.e., L-packet duration is not shorter than 263 the observed burst duration. If the sender generates non-interleaved 264 FEC repair packets and a burst loss hits the source packets, the 265 repair operation fails. This is illustrated in Figure 5. 267 +---+ +---+ +===+ 268 | 1 | X X | 4 | |R_1| 269 +---+ +---+ +===+ 271 +---+ +---+ +---+ +---+ +===+ 272 | 5 | | 6 | | 7 | | 8 | |R_2| 273 +---+ +---+ +---+ +---+ +===+ 275 +---+ +---+ +---+ +---+ +===+ 276 | 9 | | 10| | 11| | 12| |R_3| 277 +---+ +---+ +---+ +---+ +===+ 279 Figure 5: Example scenario where 1-D non-interleaved FEC protection 280 fails error recovery (Burst Loss) 282 The sender may generate interleaved FEC repair packets to combat with 283 the bursty packet losses. However, two or more random packet losses 284 may hit the source and repair packets in the same column. In that 285 case, the repair operation fails as well. This is illustrated in 286 Figure 6. Note that it is possible that two burst losses may occur 287 back-to-back, in which case interleaved FEC repair packets may still 288 fail to recover the lost data. 290 +---+ +---+ +---+ 291 | 1 | X | 3 | | 4 | 292 +---+ +---+ +---+ 294 +---+ +---+ +---+ 295 | 5 | X | 7 | | 8 | 296 +---+ +---+ +---+ 298 +---+ +---+ +---+ +---+ 299 | 9 | | 10| | 11| | 12| 300 +---+ +---+ +---+ +---+ 302 +===+ +===+ +===+ +===+ 303 |C_1| |C_2| |C_3| |C_4| 304 +===+ +===+ +===+ +===+ 306 Figure 6: Example scenario where 1-D interleaved FEC protection fails 307 error recovery (Periodic Loss) 309 1.1.4. 2-D (Row and Column) FEC Protection 311 In networks where the source packets are lost both randomly and in 312 bursts, the sender ought to generate both non-interleaved and 313 interleaved FEC repair packets. This type of FEC protection is known 314 as 2-D parity FEC protection. At the expense of generating more FEC 315 repair packets, thus increasing the FEC overhead, 2-D FEC provides 316 superior protection against mixed loss patterns. However, it is 317 still possible for 2-D parity FEC protection to fail to recover all 318 of the lost source packets if a particular loss pattern occurs. An 319 example scenario is illustrated in Figure 7. 321 +---+ +---+ +===+ 322 | 1 | X X | 4 | |R_1| 323 +---+ +---+ +===+ 325 +---+ +---+ +---+ +---+ +===+ 326 | 5 | | 6 | | 7 | | 8 | |R_2| 327 +---+ +---+ +---+ +---+ +===+ 329 +---+ +---+ +===+ 330 | 9 | X X | 12| |R_3| 331 +---+ +---+ +===+ 333 +===+ +===+ +===+ +===+ 334 |C_1| |C_2| |C_3| |C_4| 335 +===+ +===+ +===+ +===+ 337 Figure 7: Example scenario #1 where 2-D parity FEC protection fails 338 error recovery 340 2-D parity FEC protection also fails when at least two rows are 341 missing a source and the FEC packet and the missing source packets 342 (in at least two rows) are aligned in the same column. An example 343 loss pattern is sketched in Figure 8. Similarly, 2-D parity FEC 344 protection cannot repair all missing source packets when at least two 345 columns are missing a source and the FEC packet and the missing 346 source packets (in at least two columns) are aligned in the same row. 348 +---+ +---+ +---+ 349 | 1 | | 2 | X | 4 | X 350 +---+ +---+ +---+ 352 +---+ +---+ +---+ +---+ +===+ 353 | 5 | | 6 | | 7 | | 8 | |R_2| 354 +---+ +---+ +---+ +---+ +===+ 356 +---+ +---+ +---+ 357 | 9 | | 10| X | 12| X 358 +---+ +---+ +---+ 360 +===+ +===+ +===+ +===+ 361 |C_1| |C_2| |C_3| |C_4| 362 +===+ +===+ +===+ +===+ 364 Figure 8: Example scenario #2 where 2-D parity FEC protection fails 365 error recovery 367 1.1.5. FEC Overhead Considerations 369 The overhead is defined as the ratio of the number of bytes belonging 370 to the repair packets to the number of bytes belonging to the 371 protected source packets. 373 Generally, repair packets are larger in size compared to the source 374 packets. Also, not all the source packets are necessarily equal in 375 size. However, assuming that each repair packet carries an equal 376 number of bytes carried by a source packet, the overhead for 377 different FEC protection methods can be computed as follows: 379 o 1-D Non-interleaved FEC Protection: Overhead = 1/L 381 o 1-D Interleaved FEC Protection: Overhead = 1/D 383 o 2-D Parity FEC Protection: Overhead = 1/L + 1/D 385 where L and D are the number of columns and rows in the source block, 386 respectively. 388 2. Requirements Notation 390 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 391 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 392 document are to be interpreted as described in [RFC2119]. 394 3. Definitions and Notations 396 3.1. Definitions 398 This document uses a number of definitions from [RFC6363]. 400 1-D Non-interleaved Row FEC: A protection scheme that operates on 401 consecutive source packets in the source block, able to recover a 402 single lost source packet per row of the source block. 404 1-D Interleaved Column FEC: A protection scheme that operates on 405 interleaved source packets in the source block, able to recover a 406 single lost source packet per column of the source block. 408 2-D FEC: A protection scheme that combines row and column FEC. 410 Source Block: A set of source packets that are protected by a set 411 of 1-D or 2-D FEC repair packets. 413 FEC Block: A source block and its corresponding FEC repair 414 packets. 416 Repair Window: The time that spans a FEC block, which consists of 417 the source packets and the corresponding FEC repair packets. 419 XOR Parity Codes: A FEC code which uses the eXclusive OR (XOR) 420 parity operation to encode a set of source packets to form a FEC 421 repair packet. 423 3.2. Notations 425 L: Number of columns of the source block (length of each row). 427 D: Number of rows of the source block (depth of each column). 429 bitmask: A 15-bit, 46-bit, or 110-bit mask indicating which source 430 packets are protected by a FEC repair packet. If the bit i in the 431 mask is set to 1, the source packet number N + i is protected by 432 this FEC repair packet, where N is the sequence number base 433 indicated in the FEC repair packet. The most significant bit of 434 the mask corresponds to i=0. The least signficant bit of the mask 435 corresponds to i=14 in the 15-bit mask, i=45 in the 46-bit mask, 436 or i=109 in the 110-bit mask. 438 4. Packet Formats 440 This section describes the formats of the source packets and defines 441 the formats of the FEC repair packets. 443 4.1. Source Packets 445 The source packets contain the information that identifies the source 446 block and the position within the source block occupied by the 447 packet. Since the source packets that are carried within an RTP 448 stream already contain unique sequence numbers in their RTP headers 449 [RFC3550], the source packets can be identified in a straightforward 450 manner and there is no need to append additional field(s). The 451 primary advantage of not modifying the source packets in any way is 452 that it provides backward compatibility for the receivers that do not 453 support FEC at all. In multicast scenarios, this backward 454 compatibility becomes quite useful as it allows the non-FEC-capable 455 and FEC-capable receivers to receive and interpret the same source 456 packets sent in the same multicast session. 458 The source packets are transmitted as usual without altering them. 459 They are used along with the FEC repair packets to recover any 460 missing source packets, making this scheme a systematic code. 462 The source packets are full RTP packets with optional CSRC list, RTP 463 header extension, and padding. If any of these optional elements are 464 present in the source RTP packet, and that source packet is lost, 465 they are recovered by the FEC repair operation, which recovers the 466 full source RTP packet including these optional elements. 468 4.2. FEC Repair Packets 470 The FEC repair packets MUST contain information that identifies the 471 source block they pertain to and the relationship between the 472 contained repair packets and the original source block. For this 473 purpose, the RTP header of the repair packets is used, as well as 474 another header within the RTP payload, called the FEC header, as 475 shown in Figure 9. 477 Note that all the source stream packets that are protected by a 478 particular FEC packet need to be in the same RTP session. 480 +------------------------------+ 481 | IP Header | 482 +------------------------------+ 483 | Transport Header | 484 +------------------------------+ 485 | RTP Header | 486 +------------------------------+ ---+ 487 | FEC Header | | 488 +------------------------------+ | RTP Payload 489 | Repair "Payload" | | 490 +------------------------------+ ---+ 492 Figure 9: Format of FEC repair packets 494 Repair "Payload", which follows the FEC Header, includes repair of 495 everything following the fixed 12-byte RTP header of the source 496 packet, including any CSRC list and header extensions if present. 498 4.2.1. RTP Header of FEC Repair Packets 500 The RTP header is formatted according to [RFC3550] with some further 501 clarifications listed below: 503 Version (V) 2 bits: This MUST be set to 2 (binary 10), as this 504 specification requires all source RTP packets and all FEC repair 505 packets to use RTP version 2. The reason for this restriction is 506 the first 2 bits of the FEC header contain other information (R 507 and F bits) rather than recovering the RTP version field. 509 Padding (P) bit: Source packets can have optional RTP padding, 510 which can be recovered. FEC repaire packets can have optional RTP 511 padding, which is independent of the RTP padding of the source 512 pakcets. 514 Extension (X) bit: Source packets can have optional RTP header 515 extensions, which can be recovered. FEC repair packets can have 516 optional RTP header extensions, which are independent of the RTP 517 header extensions of the source packets. 519 CSRC Count (CC) 4 bits, and CSRC List (CSRC_i) 32 bits each: 520 Source packets can have an optional CSRC list and count, which can 521 be recovered. FEC repair packets MUST use the CSRC list and count 522 to specify the SSRC(s) of the source RTP stream(s) protected by 523 this FEC repair packet. 525 Marker (M) bit: This bit is not used for this payload type, and 526 SHALL be set to 0 by senders, and SHALL be ignored by receivers. 528 Payload Type: The (dynamic) payload type for the FEC repair 529 packets is determined through out-of-band means. Note that this 530 document registers new payload formats for the repair packets 531 (Refer to Section 5 for details). According to [RFC3550], an RTP 532 receiver that cannot recognize a payload type must discard it. 533 This provides backward compatibility. If a non-FEC-capable 534 receiver receives a repair packet, it will not recognize the 535 payload type, and hence, will discard the repair packet. 537 Sequence Number (SN): The sequence number has the standard 538 definition. It MUST be one higher than the sequence number in the 539 previously transmitted repair packet. The initial value of the 540 sequence number SHOULD be random (unpredictable, based on 541 [RFC3550]). 543 Timestamp (TS): The timestamp SHALL be set to a time corresponding 544 to the repair packet's transmission time. Note that the timestamp 545 value has no use in the actual FEC protection process and is 546 usually useful for jitter calculations. 548 Synchronization Source (SSRC): The SSRC value for each repair 549 stream SHALL be randomly assigned as suggested by [RFC3550]. This 550 allows the sender to multiplex the source and repair RTP streams 551 on the same port, or multiplex multiple repair streams on a single 552 port. The repair streams SHOULD use the RTCP CNAME field to 553 associate themselves with the source stream. 555 In some networks, the RTP Source, which produces the source 556 packets and the FEC Source, which generates the repair packets 557 from the source packets may not be the same host. In such 558 scenarios, using the same CNAME for the source and repair RTP 559 streams means that the RTP Source and the FEC Source MUST share 560 the same CNAME (for this specific source-repair stream 561 association). A common CNAME may be produced based on an 562 algorithm that is known both to the RTP and FEC Source [RFC7022]. 563 This usage is compliant with [RFC3550]. 565 Note that due to the randomness of the SSRC assignments, there is 566 a possibility of SSRC collision. In such cases, the collisions 567 MUST be resolved as described in [RFC3550]. 569 4.2.2. FEC Header of FEC Repair Packets 571 The format of the FEC header has 3 variants, depending on the values 572 in the first 2 bits (R and F bits) as shown in Figure 10. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |R|F|P|X| CC |M| PT recovery | ...varies depending on R/F... | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 | ...varies depending on R/F... | 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 : Repair "Payload" follows FEC Header : 584 : : 586 Figure 10: FEC Header 588 Repair "Payload", which follows the FEC Header, includes repair of 589 everything following the fixed 12-byte RTP header of the source 590 packet, including any CSRC list and header extensions if present. 592 +---+---+----------------------------------------------------------+ 593 | R | F | FEC Header variant | 594 +---+---+----------------------------------------------------------+ 595 | 0 | 0 | Flexible FEC Mask fields indicate source packets | 596 | 0 | 1 | Fixed FEC M/N (cols/rows) fields indicate source packets | 597 | 1 | 0 | Retransmission of a single source packet | 598 | 1 | 1 | Invalid, MUST NOT send, MUST ignore if received | 599 +---+---+----------------------------------------------------------+ 601 Figure 11: R and F bit values for FEC Header variants 603 The first variant, when R=0 and F=0, has a mask to signal protected 604 source packets, as shown in Figure 12. 606 The second variant, when R=0 and F=1, has a number of columns (M) and 607 rows (N) to signal protected source packets, as shown in Figure 13. 609 The final variant, when R=1 and F=0, is a retransmission format as 610 shown in Figure 15. 612 No variant uses R=1 and F=1, which is invalid, and MUST NOT be sent 613 by senders, and MUST be ignored by receivers. 615 The FEC header for all variants consists of the following common 616 fields: 618 o The R bit MUST be set to 1 to indicate a retransmission packet, 619 and MUST be set to 0 for FEC repair packets. 621 o The F bit indicates the type of FEC repair packets, as shown in 622 Figure 11, when the R bit is 0. The F bit MUST be set to 0 when 623 the R bit is 1 for retransmission packets. 625 o The P, X, CC, M and PT recovery fields are used to determine the 626 corresponding fields of the recovered packets. 628 4.2.2.1. FEC Header with Flexible Mask 630 When R=0 and F=0, the FEC Header includes flexible mask fields. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 |0|0|P|X| CC |M| PT recovery | length recovery | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | TS recovery | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | SN base_i |k| Mask [0-14] | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |k| Mask [15-45] (optional) | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Mask [46-109] (optional) | 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | ... next SN base and Mask for CSRC_i in CSRC list ... | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 : Repair "Payload" follows FEC Header : 649 : : 651 Figure 12: FEC Header for F=0 653 o The Length recovery (16 bits) field is used to determine the 654 length of the recovered packets. This length includes all octets 655 following the fixed 12-byte RTP header of source packets, 656 including CSRC list and options if present. It excludes the fixed 657 12-byte RTP header of source packets. 659 o The TS recovery (32 bits) field is used to determine the timestamp 660 of the recovered packets. 662 o The CSRC_i (32 bits) field in the RTP Header (not FEC Header) 663 describes the SSRC of the source packets protected by this 664 particular FEC packet. If a FEC packet protects multiple SSRCs 665 (indicated by the CSRC Count > 1 in the RTP Header), there will be 666 multiple blocks of data containing the SN base and Mask fields. 668 o The SN base_i (16 bits) field indicates the lowest sequence 669 number, taking wrap around into account, of the source packets for 670 a particular SSRC (indicated in CSRC_i) protected by this repair 671 packet. 673 o The Mask fields indicate a bitmask of which source packets are 674 protected by this FEC repair packet, where bit j of the mask set 675 to 1 indicates that the source packet with sequence number (SN 676 base_i + j) is protected by this FEC repair packet, where j=0 is 677 the most significant bit in the mask. 679 o The k-bit in the bitmasks indicates if the mask is 15, 46, or 110 680 bits. k=1 denotes that another mask follows, and k=0 denotes that 681 it is the last block of mask. 683 o Repair "Payload", which follows the FEC Header, includes repair of 684 everything following the fixed 12-byte RTP header of the source 685 packet, including any CSRC list and header extensions if present. 687 4.2.2.2. FEC Header with Fixed L Columns and D Rows 689 When R=0 and F=1, the FEC Header includes L and D fields for fixed 690 columns and rows. The other fields are the same as the prior 691 section. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |0|1|P|X| CC |M| PT recovery | length recovery | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | TS recovery | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | SN base_i | L (columns) | D (rows) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | ... next SN base and M/N for CSRC_i in CSRC list ... | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 : Repair "Payload" follows FEC Header : 705 : : 707 Figure 13: FEC Header for F=1 709 Consequently, the following conditions occur for L and D values: 711 If L=0, D=0, use the optional payload format parameters for L and D. 713 If L>0, D=0, indicates Row FEC, and no column FEC will follow. 714 Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L. 716 If L>0, D=1, indicates Row FEC, and column FEC will follow. 717 Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L. 718 And more FEC to come. 720 If L>0, D>1, indicates column FEC of every L packet 721 in a group of D packets starting at SN base. 722 Hence, FEC = SN+(Lx0), SN+(Lx1), ... , SN+(LxD). 724 Figure 14: Interpreting the L and D field values 726 It should be noted that the flexible mask-based approach may be 727 inefficient for protecting a large number of source packets, or 728 impossible to signal if larger than the largest mask size. In such 729 cases, the fixed columns and rows variant may be more useful. 731 4.2.2.3. FEC Header for Retransmissions 733 When R=1 and F=0, the FEC packet is a retransmission of a single 734 source packet. 736 Note that the layout of this retransmission packet is different from 737 other FEC repair packets. The sequence number (SN base_i) replaces 738 the length recovery in the FEC header, since the length is already 739 known for a single packet. There are no L, D or Mask fields, since 740 only a single packet is retransmitted, identified by the sequence 741 number in the FEC header. The source packet SSRC is included in the 742 FEC header for retransmissions, not in the RTP header CSRC list as in 743 the FEC header variants with R=0. 745 This FEC header layout is identical to the source RTP (version 2) 746 packet, starting with its RTP header, where the retransmission 747 "payload" is everything following the fixed 12-byte RTP header of the 748 source packet, including CSRC list and extensions if present. 749 Therefore, the only operation needed for sending retransmissions is 750 to prepend a new RTP header to the source packet. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 |1|0| P|X| CC |M| Payload Type| Sequence Number | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Timestamp | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | SSRC | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 : Retransmission "Payload" follows FEC Header : 762 : : 764 Figure 15: FEC Header for Retransmission 766 5. Payload Format Parameters 768 This section provides the media subtype registration for the non- 769 interleaved and interleaved parity FEC. The parameters that are 770 required to configure the FEC encoding and decoding operations are 771 also defined in this section. If no specific FEC code is specified 772 in the subtype, then the FEC code defaults to the parity code defined 773 in this specification. 775 5.1. Media Type Registration - Parity Codes 777 This registration is done using the template defined in [RFC6838] and 778 following the guidance provided in [RFC3555]. 780 Note to the RFC Editor: In the following sections, please replace 781 "XXXX" with the number of this document prior to publication as an 782 RFC. 784 5.1.1. Registration of audio/flexfec 786 Type name: audio 788 Subtype name: flexfec 790 Required parameters: 792 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 793 than 1000 Hz to provide sufficient resolution to RTCP operations. 794 However, it is RECOMMENDED to select the rate that matches the 795 rate of the protected source RTP stream. 797 o repair-window: The time that spans the source packets and the 798 corresponding repair packets. The size of the repair window is 799 specified in microseconds. 801 Optional parameters: 803 o L: indicates the number of columns of the source block that are 804 protected by this FEC block and it applies to all the source 805 SSRCs. L is a positive integer. 807 o D: indicates the number of rows of the source block that are 808 protected by this FEC block and it applies to all the source 809 SSRCs. D is a positive integer. 811 o ToP: indicates the type of protection applied by the sender: 0 for 812 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC 813 protection, and 2 for 2-D parity FEC protection. The ToP value of 814 3 is reserved for future uses. 816 Encoding considerations: This media type is framed (See Section 4.8 817 in the template document [RFC6838]) and contains binary data. 819 Security considerations: See Section 9 of [RFCXXXX]. 821 Interoperability considerations: None. 823 Published specification: [RFCXXXX]. 825 Applications that use this media type: Multimedia applications that 826 want to improve resiliency against packet loss by sending redundant 827 data in addition to the source media. 829 Fragment identifier considerations: None. 831 Additional information: None. 833 Person & email address to contact for further information: Varun 834 Singh and IETF Audio/Video Transport Payloads 835 Working Group. 837 Intended usage: COMMON. 839 Restriction on usage: This media type depends on RTP framing, and 840 hence, is only defined for transport via RTP [RFC3550]. 842 Author: Varun Singh . 844 Change controller: IETF Audio/Video Transport Working Group delegated 845 from the IESG. 847 Provisional registration? (standards tree only): Yes. 849 5.1.2. Registration of video/flexfec 851 Type name: video 853 Subtype name: flexfec 855 Required parameters: 857 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 858 than 1000 Hz to provide sufficient resolution to RTCP operations. 859 However, it is RECOMMENDED to select the rate that matches the 860 rate of the protected source RTP stream. 862 o repair-window: The time that spans the source packets and the 863 corresponding repair packets. The size of the repair window is 864 specified in microseconds. 866 Optional parameters: 868 o L: indicates the number of columns of the source block that are 869 protected by this FEC block and it applies to all the source 870 SSRCs. L is a positive integer. 872 o D: indicates the number of rows of the source block that are 873 protected by this FEC block and it applies to all the source 874 SSRCs. D is a positive integer. 876 o ToP: indicates the type of protection applied by the sender: 0 for 877 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC 878 protection, and 2 for 2-D parity FEC protection. The ToP value of 879 3 is reserved for future uses. 881 Encoding considerations: This media type is framed (See Section 4.8 882 in the template document [RFC6838]) and contains binary data. 884 Security considerations: See Section 9 of [RFCXXXX]. 886 Interoperability considerations: None. 888 Published specification: [RFCXXXX]. 890 Applications that use this media type: Multimedia applications that 891 want to improve resiliency against packet loss by sending redundant 892 data in addition to the source media. 894 Fragment identifier considerations: None. 896 Additional information: None. 898 Person & email address to contact for further information: Varun 899 Singh and IETF Audio/Video Transport Payloads 900 Working Group. 902 Intended usage: COMMON. 904 Restriction on usage: This media type depends on RTP framing, and 905 hence, is only defined for transport via RTP [RFC3550]. 907 Author: Varun Singh . 909 Change controller: IETF Audio/Video Transport Working Group delegated 910 from the IESG. 912 Provisional registration? (standards tree only): Yes. 914 5.1.3. Registration of text/flexfec 916 Type name: text 918 Subtype name: flexfec 920 Required parameters: 922 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 923 than 1000 Hz to provide sufficient resolution to RTCP operations. 924 However, it is RECOMMENDED to select the rate that matches the 925 rate of the protected source RTP stream. 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: 933 o L: indicates the number of columns of the source block that are 934 protected by this FEC block and it applies to all the source 935 SSRCs. L is a positive integer. 937 o D: indicates the number of rows of the source block that are 938 protected by this FEC block and it applies to all the source 939 SSRCs. D is a positive integer. 941 o ToP: indicates the type of protection applied by the sender: 0 for 942 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC 943 protection, and 2 for 2-D parity FEC protection. The ToP value of 944 3 is reserved for future uses. 946 Encoding considerations: This media type is framed (See Section 4.8 947 in the template document [RFC6838]) and contains binary data. 949 Security considerations: See Section 9 of [RFCXXXX]. 951 Interoperability considerations: None. 953 Published specification: [RFCXXXX]. 955 Applications that use this media type: Multimedia applications that 956 want to improve resiliency against packet loss by sending redundant 957 data in addition to the source media. 959 Fragment identifier considerations: None. 961 Additional information: None. 963 Person & email address to contact for further information: Varun 964 Singh and IETF Audio/Video Transport Payloads 965 Working Group. 967 Intended usage: COMMON. 969 Restriction on usage: This media type depends on RTP framing, and 970 hence, is only defined for transport via RTP [RFC3550]. 972 Author: Varun Singh . 974 Change controller: IETF Audio/Video Transport Working Group delegated 975 from the IESG. 977 Provisional registration? (standards tree only): Yes. 979 5.1.4. Registration of application/flexfec 981 Type name: application 983 Subtype name: flexfec 984 Required parameters: 986 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 987 than 1000 Hz to provide sufficient resolution to RTCP operations. 988 However, it is RECOMMENDED to select the rate that matches the 989 rate of the protected source RTP stream. 991 o repair-window: The time that spans the source packets and the 992 corresponding repair packets. The size of the repair window is 993 specified in microseconds. 995 Optional parameters: 997 o L: indicates the number of columns of the source block that are 998 protected by this FEC block and it applies to all the source 999 SSRCs. L is a positive integer. 1001 o D: indicates the number of rows of the source block that are 1002 protected by this FEC block and it applies to all the source 1003 SSRCs. D is a positive integer. 1005 o ToP: indicates the type of protection applied by the sender: 0 for 1006 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC 1007 protection, and 2 for 2-D parity FEC protection. The ToP value of 1008 3 is reserved for future uses. 1010 Encoding considerations: This media type is framed (See Section 4.8 1011 in the template document [RFC6838]) and contains binary data. 1013 Security considerations: See Section 9 of [RFCXXXX]. 1015 Interoperability considerations: None. 1017 Published specification: [RFCXXXX]. 1019 Applications that use this media type: Multimedia applications that 1020 want to improve resiliency against packet loss by sending redundant 1021 data in addition to the source media. 1023 Fragment identifier considerations: None. 1025 Additional information: None. 1027 Person & email address to contact for further information: Varun 1028 Singh and IETF Audio/Video Transport Payloads 1029 Working Group. 1031 Intended usage: COMMON. 1033 Restriction on usage: This media type depends on RTP framing, and 1034 hence, is only defined for transport via RTP [RFC3550]. 1036 Author: Varun Singh . 1038 Change controller: IETF Audio/Video Transport Working Group delegated 1039 from the IESG. 1041 Provisional registration? (standards tree only): Yes. 1043 5.2. Mapping to SDP Parameters 1045 Applications that are using RTP transport commonly use Session 1046 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 1047 The information that is used to specify the media types in an RTP 1048 session has specific mappings to the fields in an SDP description. 1049 This section provides these mappings for the media subtypes 1050 registered by this document. Note that if an application does not 1051 use SDP to describe the RTP sessions, an appropriate mapping must be 1052 defined and used to specify the media types and their parameters for 1053 the control/description protocol employed by the application. 1055 The mapping of the media type specification for "non-interleaved- 1056 parityfec" and "interleaved-parityfec" and their parameters in SDP is 1057 as follows: 1059 o The media type (e.g., "application") goes into the "m=" line as 1060 the media name. 1062 o The media subtype goes into the "a=rtpmap" line as the encoding 1063 name. The RTP clock rate parameter ("rate") also goes into the 1064 "a=rtpmap" line as the clock rate. 1066 o The remaining required payload-format-specific parameters go into 1067 the "a=fmtp" line by copying them directly from the media type 1068 string as a semicolon-separated list of parameter=value pairs. 1070 SDP examples are provided in Section 7. 1072 5.2.1. Offer-Answer Model Considerations 1074 When offering 1-D interleaved parity FEC over RTP using SDP in an 1075 Offer/Answer model [RFC3264], the following considerations apply: 1077 o Each combination of the L and D parameters produces a different 1078 FEC data and is not compatible with any other combination. A 1079 sender application may desire to offer multiple offers with 1080 different sets of L and D values as long as the parameter values 1081 are valid. The receiver SHOULD normally choose the offer that has 1082 a sufficient amount of interleaving. If multiple such offers 1083 exist, the receiver may choose the offer that has the lowest 1084 overhead or the one that requires the smallest amount of 1085 buffering. The selection depends on the application requirements. 1087 o The value for the repair-window parameter depends on the L and D 1088 values and cannot be chosen arbitrarily. More specifically, L and 1089 D values determine the lower limit for the repair-window size. 1090 The upper limit of the repair-window size does not depend on the L 1091 and D values. 1093 o Although combinations with the same L and D values but with 1094 different repair-window sizes produce the same FEC data, such 1095 combinations are still considered different offers. The size of 1096 the repair-window is related to the maximum delay between the 1097 transmission of a source packet and the associated repair packet. 1098 This directly impacts the buffering requirement on the receiver 1099 side and the receiver must consider this when choosing an offer. 1101 o There are no optional format parameters defined for this payload. 1102 Any unknown option in the offer MUST be ignored and deleted from 1103 the answer. If FEC is not desired by the receiver, it can be 1104 deleted from the answer. 1106 5.2.2. Declarative Considerations 1108 In declarative usage, like SDP in the Real-time Streaming Protocol 1109 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 1110 [RFC2974], the following considerations apply: 1112 o The payload format configuration parameters are all declarative 1113 and a participant MUST use the configuration that is provided for 1114 the session. 1116 o More than one configuration may be provided (if desired) by 1117 declaring multiple RTP payload types. In that case, the receivers 1118 should choose the repair stream that is best for them. 1120 6. Protection and Recovery Procedures - Parity Codes 1122 This section provides a complete specification of the 1-D and 2-D 1123 parity codes and their RTP payload formats. It does not apply to the 1124 single packet retransmission format (R=1 in the FEC Header). 1126 6.1. Overview 1128 The following sections specify the steps involved in generating the 1129 repair packets and reconstructing the missing source packets from the 1130 repair packets. 1132 6.2. Repair Packet Construction 1134 The RTP Header of a repair packet is formed based on the guidelines 1135 given in Section 4.2. 1137 The FEC Header and Repair "Payload" of repair packets are formed by 1138 applying the XOR operation on the bit strings that are generated from 1139 the individual source packets protected by this particular repair 1140 packet. The set of the source packets that are associated with a 1141 given repair packet can be computed by the formula given in 1142 Section 6.3.1. 1144 The bit string is formed for each source packet by concatenating the 1145 following fields together in the order specified: 1147 o The first 16 bits of the RTP header (16 bits). 1149 o Unsigned network-ordered 16-bit representation of the source 1150 packet length in bytes minus 12 (for the fixed RTP header), i.e., 1151 the sum of the lengths of all the following if present: the CSRC 1152 list, extension header, RTP payload and RTP padding (16 bits). 1154 o The timestamp of the RTP header (32 bits). 1156 o All octets after the fixed 12-byte RTP header. (Note the SSRC 1157 field is skipped.) 1159 The FEC bit string is generated by applying the parity operation on 1160 the bit strings produced from the source packets. The FEC header is 1161 generated from the FEC bit string as follows: 1163 o The first (most significant) 2 bits in the FEC bit string, which 1164 contain the RTP version field, are skipped. The R and F bits in 1165 the FEC header are set to the appropriate value, i.e., it depends 1166 on the chosen format variant. As a consequence of overwriting the 1167 RTP version field with the R and F bits, this payload format only 1168 supports RTP version 2. 1170 o The next bit in the FEC bit string is written into the P recovery 1171 bit in the FEC header. 1173 o The next bit in the FEC bit string is written into the X recovery 1174 bit in the FEC header. 1176 o The next 4 bits of the FEC bit string are written into the CC 1177 recovery field in the FEC header. 1179 o The next bit is written into the M recovery bit in the FEC header. 1181 o The next 7 bits of the FEC bit string are written into the PT 1182 recovery field in the FEC header. 1184 o The next 16 bits are written into the length recovery field in the 1185 FEC header. 1187 o The next 32 bits of the FEC bit string are written into the TS 1188 recovery field in the FEC header. 1190 o The lowest Sequence Number of the source packets protected by this 1191 repair packet is written into the Sequence Number Base field in 1192 the FEC header. 1194 o Depending on the chosen FEC header variant, the mask(s) are set 1195 when F=0, or the L and D values are set when F=1. 1197 o The rest of the FEC bit string, which contains everything after 1198 the fixed 12-byte RTP header of the source packet, is written into 1199 the Repair "Payload" following the FEC header, where "Payload" 1200 refers to everything after the fixed 12-byte RTP header, including 1201 extensions, CSRC list, true payloads, and padding. 1203 If the lengths of the source packets are not equal, each shorter 1204 packet MUST be padded to the length of the longest packet by adding 1205 octet 0's at the end. 1207 Due to this possible padding and mandatory FEC header, a repair 1208 packet has a larger size than the source packets it protects. This 1209 may cause problems if the resulting repair packet size exceeds the 1210 Maximum Transmission Unit (MTU) size of the path over which the 1211 repair stream is sent. 1213 6.3. Source Packet Reconstruction 1215 This section describes the recovery procedures that are required to 1216 reconstruct the missing source packets. The recovery process has two 1217 steps. In the first step, the FEC decoder determines which source 1218 and repair packets should be used in order to recover a missing 1219 packet. In the second step, the decoder recovers the missing packet, 1220 which consists of an RTP header and RTP payload. 1222 The following describes the RECOMMENDED algorithms for the first and 1223 second steps. Based on the implementation, different algorithms MAY 1224 be adopted. However, the end result MUST be identical to the one 1225 produced by the algorithms described below. 1227 Note that the same algorithms are used by the 1-D parity codes, 1228 regardless of whether the FEC protection is applied over a column or 1229 a row. The 2-D parity codes, on the other hand, usually require 1230 multiple iterations of the procedures described here. This iterative 1231 decoding algorithm is further explained in Section 6.3.4. 1233 6.3.1. Associating the Source and Repair Packets 1235 The first step is associating the source and repair packets. This 1236 association can be via flexible bitmasks, or fixed L and D offsets 1237 which can be in the FEC header or signaled in SDP in optional payload 1238 format parameters when L=D=0 in the FEC header. 1240 6.3.1.1. Using Bitmasks 1242 To use flexible bitmasks, the first two FEC header bits MUST have R=0 1243 and F=0. A 15-bit, 46-bit, or 110-bit mask indicates which source 1244 packets are protected by a FEC repair packet. If the bit i in the 1245 mask is set to 1, the source packet number N + i is protected by this 1246 FEC repair packet, where N is the sequence number base indicated in 1247 the FEC header. The most significant bit of the mask corresponds to 1248 i=0. The least signficant bit of the mask corresponds to i=14 in the 1249 15-bit mask, i=45 in the 46-bit mask, or i=109 in the 110-bit mask. 1251 The bitmasks are able to represent arbitrary protection patterns, for 1252 example, 1-D interleaved, 1-D non-interleaved, 2-D, staircase. 1254 6.3.1.2. Using L and D Offsets 1256 Denote the set of the source packets associated with repair packet p* 1257 by set T(p*). Note that in a source block whose size is L columns by 1258 D rows, set T includes D source packets plus one repair packet for 1259 the FEC protection applied over a column, and L source packets plus 1260 one repair packet for the FEC protection applied over a row. Recall 1261 that 1-D interleaved and non-interleaved FEC protection can fully 1262 recover the missing information if there is only one source packet 1263 missing per column or row in set T. If there are more than one 1264 source packets missing per column or row in set T, 1-D FEC protection 1265 may fail to recover all the missing information. 1267 When value of L is non-zero, the 8-bit fields indicate the offset of 1268 packets protected by an interleaved (D>0) or non-interleaved (D=0) 1269 FEC packet. Using a combination of interleaved and non-interleaved 1270 FEC repair packets can form 2-D protection patterns. 1272 Mathematically, for any received repair packet, p*, the sequence 1273 numbers of the source packets that are protected by this repair 1274 packet are determined as follows, where p*_snb is the sequence number 1275 base in the FEC header: 1277 When D = 0: 1278 p*_snb, p*_snb+1,..., p*_snb+L 1279 When D > 0: 1280 p*_snb, p*_snb+(Lx1), p*_snb+(Lx2),..., p*_snb+(LxD) 1282 6.3.1.3. Signaled in SDP 1284 If the endpoint relies entirely on out-of-band signaling (R=0, F=1, 1285 L=0, D=0 in the FEC header), then this information may be inferred 1286 from the media type parameters specified in the SDP description. 1287 Furthermore, the payload type field in the RTP header assists the 1288 receiver to distinguish an interleaved or non-interleaved FEC packet. 1290 Mathematically, for any received repair packet, p*, the sequence 1291 numbers of the source packets that are protected by this repair 1292 packet are determined as follows: 1294 p*_snb + i * X_1 (modulo 65536) 1296 where p*_snb denotes the value in the SN base field of p*'s FEC 1297 header, X_1 is set to L and 1 for the interleaved and non-interleaved 1298 FEC repair packets, respectively, and 1300 0 <= i < X_2 1302 where X_2 is set to D and L for the interleaved and non-interleaved 1303 FEC repair packets, respectively. 1305 6.3.2. Recovering the RTP Header 1307 For a given set T, the procedure for the recovery of the RTP header 1308 of the missing packet, whose sequence number is denoted by SEQNUM, is 1309 as follows: 1311 1. For each of the source packets that are successfully received in 1312 T, compute the 80-bit string by concatenating the first 64 bits 1313 of their RTP header and the unsigned network-ordered 16-bit 1314 representation of their length in bytes minus 12. 1316 2. For the repair packet in T, compute the FEC bit string from the 1317 first 80 bits of the FEC header. 1319 3. Calculate the recovered bit string as the XOR of the bit strings 1320 generated from all source packets in T and the FEC bit string 1321 generated from the repair packet in T. 1323 4. Create a new packet with the standard 12-byte RTP header and no 1324 payload. 1326 5. Set the version of the new packet to 2. Skip the first 2 bits 1327 in the recovered bit string. 1329 6. Set the Padding bit in the new packet to the next bit in the 1330 recovered bit string. 1332 7. Set the Extension bit in the new packet to the next bit in the 1333 recovered bit string. 1335 8. Set the CC field to the next 4 bits in the recovered bit string. 1337 9. Set the Marker bit in the new packet to the next bit in the 1338 recovered bit string. 1340 10. Set the Payload type in the new packet to the next 7 bits in the 1341 recovered bit string. 1343 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 1344 bits in the recovered bit string. 1346 12. Set the TS field in the new packet to the next 32 bits in the 1347 recovered bit string. 1349 13. Take the next 16 bits of the recovered bit string and set the 1350 new variable Y to whatever unsigned integer this represents 1351 (assuming network order). Convert Y to host order. Y 1352 represents the length of the new packet in bytes minus 12 (for 1353 the fixed RTP header), i.e., the sum of the lengths of all the 1354 following if present: the CSRC list, header extension, RTP 1355 payload and RTP padding. 1357 14. Set the SSRC of the new packet to the SSRC of the source RTP 1358 stream. 1360 This procedure recovers the header of an RTP packet up to (and 1361 including) the SSRC field. 1363 6.3.3. Recovering the RTP Payload 1365 Following the recovery of the RTP header, the procedure for the 1366 recovery of the RTP "payload" is as follows, where "payload" refers 1367 to everything following the fixed 12-byte RTP header, including 1368 extensions, CSRC list, true payload and padding. 1370 1. Append Y bytes to the new packet. 1372 2. For each of the source packets that are successfully received in 1373 T, compute the bit string from the Y octets of data starting with 1374 the 13th octet of the packet. If any of the bit strings 1375 generated from the source packets has a length shorter than Y, 1376 pad them to that length. The padding of octet 0 MUST be added at 1377 the end of the bit string. Note that the information of the 1378 first 8 octets are protected by the FEC header. 1380 3. For the repair packet in T, compute the FEC bit string from the 1381 repair packet payload, i.e., the Y octets of data following the 1382 FEC header. Note that the FEC header may be different sizes 1383 depending on the variant and bitmask size. 1385 4. Calculate the recovered bit string as the XOR of the bit strings 1386 generated from all source packets in T and the FEC bit string 1387 generated from the repair packet in T. 1389 5. Append the recovered bit string (Y octets) to the new packet 1390 generated in Section 6.3.2. 1392 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection 1394 In 2-D parity FEC protection, the sender generates both non- 1395 interleaved and interleaved FEC repair packets to combat with the 1396 mixed loss patterns (random and bursty). At the receiver side, these 1397 FEC packets are used iteratively to overcome the shortcomings of the 1398 1-D non-interleaved/interleaved FEC protection and improve the 1399 chances of full error recovery. 1401 The iterative decoding algorithm runs as follows: 1403 1. Set num_recovered_until_this_iteration to zero 1405 2. Set num_recovered_so_far to zero 1406 3. Recover as many source packets as possible by using the non- 1407 interleaved FEC repair packets as outlined in Section 6.3.2 and 1408 Section 6.3.3, and increase the value of num_recovered_so_far by 1409 the number of recovered source packets. 1411 4. Recover as many source packets as possible by using the 1412 interleaved FEC repair packets as outlined in Section 6.3.2 and 1413 Section 6.3.3, and increase the value of num_recovered_so_far by 1414 the number of recovered source packets. 1416 5. If num_recovered_so_far > num_recovered_until_this_iteration 1417 ---num_recovered_until_this_iteration = num_recovered_so_far 1418 ---Go to step 3 1419 Else 1420 ---Terminate 1422 The algorithm terminates either when all missing source packets are 1423 fully recovered or when there are still remaining missing source 1424 packets but the FEC repair packets are not able to recover any more 1425 source packets. For the example scenarios when the 2-D parity FEC 1426 protection fails full recovery, refer to Section 1.1.4. Upon 1427 termination, variable num_recovered_so_far has a value equal to the 1428 total number of recovered source packets. 1430 Example: 1432 Suppose that the receiver experienced the loss pattern sketched in 1433 Figure 16. 1435 +---+ +---+ +===+ 1436 X X | 3 | | 4 | |R_1| 1437 +---+ +---+ +===+ 1439 +---+ +---+ +---+ +---+ +===+ 1440 | 5 | | 6 | | 7 | | 8 | |R_2| 1441 +---+ +---+ +---+ +---+ +===+ 1443 +---+ +---+ +===+ 1444 | 9 | X X | 12| |R_3| 1445 +---+ +---+ +===+ 1447 +===+ +===+ +===+ +===+ 1448 |C_1| |C_2| |C_3| |C_4| 1449 +===+ +===+ +===+ +===+ 1451 Figure 16: Example loss pattern for the iterative decoding algorithm 1452 The receiver executes the iterative decoding algorithm and recovers 1453 source packets #1 and #11 in the first iteration. The resulting 1454 pattern is sketched in Figure 17. 1456 +---+ +---+ +---+ +===+ 1457 | 1 | X | 3 | | 4 | |R_1| 1458 +---+ +---+ +---+ +===+ 1460 +---+ +---+ +---+ +---+ +===+ 1461 | 5 | | 6 | | 7 | | 8 | |R_2| 1462 +---+ +---+ +---+ +---+ +===+ 1464 +---+ +---+ +---+ +===+ 1465 | 9 | X | 11| | 12| |R_3| 1466 +---+ +---+ +---+ +===+ 1468 +===+ +===+ +===+ +===+ 1469 |C_1| |C_2| |C_3| |C_4| 1470 +===+ +===+ +===+ +===+ 1472 Figure 17: The resulting pattern after the first iteration 1474 Since the if condition holds true, the receiver runs a new iteration. 1475 In the second iteration, source packets #2 and #10 are recovered, 1476 resulting in a full recovery as sketched in Figure 18. 1478 +---+ +---+ +---+ +---+ +===+ 1479 | 1 | | 2 | | 3 | | 4 | |R_1| 1480 +---+ +---+ +---+ +---+ +===+ 1482 +---+ +---+ +---+ +---+ +===+ 1483 | 5 | | 6 | | 7 | | 8 | |R_2| 1484 +---+ +---+ +---+ +---+ +===+ 1486 +---+ +---+ +---+ +---+ +===+ 1487 | 9 | | 10| | 11| | 12| |R_3| 1488 +---+ +---+ +---+ +---+ +===+ 1490 +===+ +===+ +===+ +===+ 1491 |C_1| |C_2| |C_3| |C_4| 1492 +===+ +===+ +===+ +===+ 1494 Figure 18: The resulting pattern after the second iteration 1496 7. SDP Examples 1498 This section provides two SDP [RFC4566] examples. The examples use 1499 the FEC grouping semantics defined in [RFC5956]. 1501 7.1. Example SDP for Flexible FEC Protection with in-band SSRC mapping 1503 In this example, we have one source video stream and one FEC repair 1504 stream. The source and repair streams are multiplexed on different 1505 SSRCs. The repair window is set to 200 ms. 1507 v=0 1508 o=mo 1122334455 1122334466 IN IP4 fec.example.com 1509 s=FlexFEC minimal SDP signalling Example 1510 t=0 0 1511 m=video 30000 RTP/AVP 96 98 1512 c=IN IP4 143.163.151.157 1513 a=rtpmap:96 VP8/90000 1514 a=rtpmap:98 flexfec/90000 1515 a=fmtp:98; repair-window=200ms 1517 7.2. Example SDP for Flex FEC Protection with explicit signalling in 1518 the SDP 1520 This example shows one source video stream (ssrc:1234) and one FEC 1521 repair streams (ssrc:2345). One FEC group is formed with the 1522 "a=ssrc-group:FEC-FR 1234 2345" line. The source and repair streams 1523 are multiplexed on different SSRCs. The repair window is set to 200 1524 ms. 1526 v=0 1527 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1528 s=2-D Parity FEC with no in band signalling Example 1529 t=0 0 1530 m=video 30000 RTP/AVP 100 110 1531 c=IN IP4 233.252.0.1/127 1532 a=rtpmap:100 MP2T/90000 1533 a=rtpmap:110 flexfec/90000 1534 a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 1535 a=ssrc:1234 1536 a=ssrc:2345 1537 a=ssrc-group:FEC-FR 1234 2345 1539 8. Congestion Control Considerations 1541 FEC is an effective approach to provide applications resiliency 1542 against packet losses. However, in networks where the congestion is 1543 a major contributor to the packet loss, the potential impacts of 1544 using FEC MUST be considered carefully before injecting the repair 1545 streams into the network. In particular, in bandwidth-limited 1546 networks, FEC repair streams may consume a significant part of the 1547 available bandwidth and consequently may congest the network. In 1548 such cases, the applications MUST NOT arbitrarily increase the amount 1549 of FEC protection since doing so may lead to a congestion collapse. 1550 If desired, stronger FEC protection MAY be applied only after the 1551 source rate has been reduced. 1553 In a network-friendly implementation, an application SHOULD NOT send/ 1554 receive FEC repair streams if it knows that sending/receiving those 1555 FEC repair streams would not help at all in recovering the missing 1556 packets. It is RECOMMENDED that the amount and type (row, column, or 1557 both) of FEC protection is adjusted dynamically based on the packet 1558 loss rate and burst loss length observed by the applications. 1560 In multicast scenarios, it may be difficult to optimize the FEC 1561 protection per receiver. If there is a large variation among the 1562 levels of FEC protection needed by different receivers, it is 1563 RECOMMENDED that the sender offers multiple repair streams with 1564 different levels of FEC protection and the receivers join the 1565 corresponding multicast sessions to receive the repair stream(s) that 1566 is best for them. 1568 9. Security Considerations 1570 RTP packets using the payload format defined in this specification 1571 are subject to the security considerations discussed in the RTP 1572 specification [RFC3550] and in any applicable RTP profile. The main 1573 security considerations for the RTP packet carrying the RTP payload 1574 format defined within this memo are confidentiality, integrity and 1575 source authenticity. Confidentiality is achieved by encrypting the 1576 RTP payload. Integrity of the RTP packets is achieved through a 1577 suitable cryptographic integrity protection mechanism. Such a 1578 cryptographic system may also allow the authentication of the source 1579 of the payload. A suitable security mechanism for this RTP payload 1580 format should provide confidentiality, integrity protection, and at 1581 least source authentication capable of determining if an RTP packet 1582 is from a member of the RTP session. 1584 Note that the appropriate mechanism to provide security to RTP and 1585 payloads following this memo may vary. It is dependent on the 1586 application, transport and signaling protocol employed. Therefore, a 1587 single mechanism is not sufficient, although if suitable, using the 1588 Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 1589 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1590 Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may 1591 exist. 1593 10. IANA Considerations 1595 New media subtypes are subject to IANA registration. For the 1596 registration of the payload formats and their parameters introduced 1597 in this document, refer to Section 5. 1599 11. Acknowledgments 1601 Some parts of this document are borrowed from [RFC5109]. Thus, the 1602 author would like to thank the editor of [RFC5109] and those who 1603 contributed to [RFC5109]. 1605 Thanks to Stephen Botzko , Bernard Aboba , Rasmus Brandt , Brian 1606 Baldino , Roni Even , Stefan Holmer , Jonathan Lennox , and Magnus 1607 Westerlund for providing valuable feedback on earlier versions of 1608 this draft. 1610 12. References 1612 12.1. Normative References 1614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1615 Requirement Levels", BCP 14, RFC 2119, 1616 DOI 10.17487/RFC2119, March 1997, 1617 . 1619 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1620 with Session Description Protocol (SDP)", RFC 3264, 1621 DOI 10.17487/RFC3264, June 2002, 1622 . 1624 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1625 Jacobson, "RTP: A Transport Protocol for Real-Time 1626 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1627 July 2003, . 1629 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1630 Payload Formats", RFC 3555, DOI 10.17487/RFC3555, July 1631 2003, . 1633 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1634 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1635 July 2006, . 1637 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 1638 the Session Description Protocol", RFC 5956, 1639 DOI 10.17487/RFC5956, September 2010, 1640 . 1642 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 1643 Correction (FEC) Framework", RFC 6363, 1644 DOI 10.17487/RFC6363, October 2011, 1645 . 1647 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 1648 Considerations for Protocol Extensions", RFC 6709, 1649 DOI 10.17487/RFC6709, September 2012, 1650 . 1652 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1653 Specifications and Registration Procedures", BCP 13, 1654 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1655 . 1657 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1658 "Guidelines for Choosing RTP Control Protocol (RTCP) 1659 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 1660 September 2013, . 1662 12.2. Informative References 1664 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1665 Streaming Protocol (RTSP)", RFC 2326, 1666 DOI 10.17487/RFC2326, April 1998, 1667 . 1669 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1670 for Generic Forward Error Correction", RFC 2733, 1671 DOI 10.17487/RFC2733, December 1999, 1672 . 1674 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1675 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1676 October 2000, . 1678 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1679 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1680 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1681 . 1683 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1684 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1685 December 2005, . 1687 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1688 "Extended RTP Profile for Real-time Transport Control 1689 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1690 DOI 10.17487/RFC4585, July 2006, 1691 . 1693 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 1694 Correction", RFC 5109, DOI 10.17487/RFC5109, December 1695 2007, . 1697 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1698 (TLS) Protocol Version 1.2", RFC 5246, 1699 DOI 10.17487/RFC5246, August 2008, 1700 . 1702 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1703 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1704 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1705 DOI 10.17487/RFC7656, November 2015, 1706 . 1708 [SMPTE2022-1] 1709 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 1710 Video/Audio Transport over IP Networks", 2007. 1712 Authors' Addresses 1714 Mo Zanaty 1715 Cisco 1716 Raleigh, NC 1717 USA 1719 Email: mzanaty@cisco.com 1720 Varun Singh 1721 CALLSTATS I/O Oy 1722 Runeberginkatu 4c A 4 1723 Helsinki 00100 1724 Finland 1726 Email: varun.singh@iki.fi 1727 URI: http://www.callstats.io/ 1729 Ali Begen 1730 Networked Media 1731 Konya 1732 Turkey 1734 Email: ali.begen@networked.media 1736 Giridhar Mandyam 1737 Qualcomm Innovation Center 1738 5775 Morehouse Drive 1739 San Diego, CA 92121 1740 USA 1742 Phone: +1 858 651 7200 1743 Email: mandyam@qti.qualcomm.com