idnits 2.17.1 draft-ietf-fecframe-interleaved-fec-scheme-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 2009) is 5470 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: 'RFCXXXX' is mentioned on line 822, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) == Outdated reference: A later version (-04) exists of draft-ietf-fecframe-dvb-al-fec-01 -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3009 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track May 5, 2009 5 Expires: November 6, 2009 7 RTP Payload Format for 1-D Interleaved Parity FEC 8 draft-ietf-fecframe-interleaved-fec-scheme-05 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 6, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines a new RTP payload format for the Forward Error 47 Correction (FEC) that is generated by the 1-D interleaved parity code 48 from a source media encapsulated in RTP. The 1-D interleaved parity 49 code is a systematic code, where a number of repair symbols are 50 generated from a set of source symbols and sent in a repair flow 51 separate from the source flow that carries the source symbols. The 52 1-D interleaved parity code offers a good protection against bursty 53 packet losses at a cost of decent complexity. The new payload format 54 defined in this document is used (with some exceptions) as a part of 55 the DVB Application-layer FEC specification. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.2. Overhead Computation . . . . . . . . . . . . . . . . . . . 8 62 1.3. Relation to Existing Specifications . . . . . . . . . . . 8 63 1.3.1. RFC 2733 and RFC 3009 . . . . . . . . . . . . . . . . 8 64 1.3.2. SMPTE 2022-1 . . . . . . . . . . . . . . . . . . . . . 8 65 1.3.3. ETSI TS 102 034 . . . . . . . . . . . . . . . . . . . 9 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 10 67 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 10 68 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 11 73 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 74 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 15 75 5.1.1. Registration of audio/1d-interleaved-parityfec . . . . 15 76 5.1.2. Registration of video/1d-interleaved-parityfec . . . . 16 77 5.1.3. Registration of text/1d-interleaved-parityfec . . . . 17 78 5.1.4. Registration of 79 application/1d-interleaved-parityfec . . . . . . . . . 18 80 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 20 81 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 20 82 5.2.2. Declarative Considerations . . . . . . . . . . . . . . 21 83 6. Protection and Recovery Procedures . . . . . . . . . . . . . . 21 84 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 22 86 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 24 87 6.3.1. Associating the Source and Repair Packets . . . . . . 24 88 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 25 89 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 26 90 8. Congestion Control Considerations . . . . . . . . . . . . . . 27 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 93 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 94 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 12.1. draft-ietf-fecframe-interleaved-fec-scheme-05 . . . . . . 28 96 12.2. draft-ietf-fecframe-interleaved-fec-scheme-04 . . . . . . 29 97 12.3. draft-ietf-fecframe-interleaved-fec-scheme-03 . . . . . . 29 98 12.4. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 29 99 12.5. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 29 100 12.6. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 29 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 103 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 106 1. Introduction 108 This document extends the Forward Error Correction (FEC) header 109 defined in [RFC2733] and uses this new FEC header for the FEC that is 110 generated by the 1-D interleaved parity code from a source media 111 encapsulated in RTP [RFC3550]. The resulting new RTP payload format 112 is registered by this document. 114 The type of the source media protected by the 1-D interleaved parity 115 code can be audio, video, text or application. The FEC data are 116 generated according to the media type parameters that are 117 communicated through out-of-band means. The associations/ 118 relationships between the source and repair flows are also 119 communicated through out-of-band means. 121 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 122 to generate the repair symbols. In a nutshell, the following steps 123 take place: 125 1. The sender determines a set of source packets to be protected 126 together based on the media type parameters. 128 2. The sender applies the XOR operation on the source symbols to 129 generate the required number of repair symbols. 131 3. The sender packetizes the repair symbols and sends the repair 132 packet(s) along with the source packets to the receiver(s) (in 133 different flows). The repair packets MAY be sent proactively or 134 on-demand. 136 Note that the source and repair packets belong to different source 137 and repair flows, and the sender MUST provide a way for the receivers 138 to demultiplex them, even in the case they are sent in the same 139 transport flow (i.e., same source/destination address/port with UDP). 140 This is required to offer backward compatibility (See Section 4). At 141 the receiver side, if all of the source packets are successfully 142 received, there is no need for FEC recovery and the repair packets 143 are discarded. However, if there are missing source packets, the 144 repair packets can be used to recover the missing information. Block 145 diagrams for the systematic parity FEC encoder and decoder are 146 sketched in Figure 1 and Figure 2, respectively. 148 +------------+ 149 +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 150 +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 151 | Encoder | 152 | (Sender) | --> +==+ +==+ 153 +------------+ +==+ +==+ 155 Source Packet: +--+ Repair Packet: +==+ 156 +--+ +==+ 158 Figure 1: Block diagram for systematic parity FEC encoder 160 +------------+ 161 +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ 162 +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ 163 | Decoder | 164 +==+ +==+ --> | (Receiver) | 165 +==+ +==+ +------------+ 167 Source Packet: +--+ Repair Packet: +==+ Lost Packet: X 168 +--+ +==+ 170 Figure 2: Block diagram for systematic parity FEC decoder 172 Suppose that we have a group of D x L source packets that have 173 sequence numbers starting from 1 running to D x L. If we apply the 174 XOR operation to the group of the source packets whose sequence 175 numbers are L apart from each other as sketched in Figure 3, we 176 generate L repair packets. This process is referred to as 1-D 177 interleaved FEC protection, and the resulting L repair packets are 178 referred to as interleaved (or column) FEC packets. 180 +-------------+ +-------------+ +-------------+ +-------+ 181 | S_1 | | S_2 | | S3 | ... | S_L | 182 | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | 183 | . | | . | | | | | 184 | . | | . | | | | | 185 | . | | . | | | | | 186 | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | 187 +-------------+ +-------------+ +-------------+ +-------+ 188 + + + + 189 ------------- ------------- ------------- ------- 190 | XOR | | XOR | | XOR | ... | XOR | 191 ------------- ------------- ------------- ------- 192 = = = = 193 +===+ +===+ +===+ +===+ 194 |C_1| |C_2| |C_3| ... |C_L| 195 +===+ +===+ +===+ +===+ 197 Figure 3: Generating interleaved (column) FEC packets 199 In Figure 3, S_n and C_m denote the source packet with a sequence 200 number n and the interleaved (column) FEC packet with a sequence 201 number m, respectively. 203 1.1. Use Cases 205 We generate one interleaved FEC packet out of D non-consecutive 206 source packets. This repair packet can provide a full recovery of 207 the missing information if there is only one packet missing among the 208 corresponding source packets. This implies that 1-D interleaved FEC 209 protection performs well under bursty loss conditions provided that L 210 is chosen large enough, i.e., L-packet duration SHOULD NOT be shorter 211 than the duration of the burst that is intended to be repaired. 213 For example, consider the scenario depicted in Figure 4 where the 214 sender generates interleaved FEC packets and a bursty loss hits the 215 source packets. Since the number of columns is larger than the 216 number of packets lost due to the bursty loss, the repair operation 217 succeeds. 219 +---+ 220 | 1 | X X X 221 +---+ 223 +---+ +---+ +---+ +---+ 224 | 5 | | 6 | | 7 | | 8 | 225 +---+ +---+ +---+ +---+ 227 +---+ +---+ +---+ +---+ 228 | 9 | | 10| | 11| | 12| 229 +---+ +---+ +---+ +---+ 231 +===+ +===+ +===+ +===+ 232 |C_1| |C_2| |C_3| |C_4| 233 +===+ +===+ +===+ +===+ 235 Figure 4: Example scenario where 1-D interleaved FEC protection 236 succeeds error recovery 238 The sender may generate interleaved FEC packets to combat with the 239 bursty packet losses. However, two or more random packet losses may 240 hit the source and repair packets in the same column. In that case, 241 the repair operation fails. This is illustrated in Figure 5. Note 242 that it is possible that two or more bursty losses may occur in the 243 same source block, in which case interleaved FEC packets may still 244 fail to recover the lost data. 246 +---+ +---+ +---+ 247 | 1 | X | 3 | | 4 | 248 +---+ +---+ +---+ 250 +---+ +---+ +---+ 251 | 5 | X | 7 | | 8 | 252 +---+ +---+ +---+ 254 +---+ +---+ +---+ +---+ 255 | 9 | | 10| | 11| | 12| 256 +---+ +---+ +---+ +---+ 258 +===+ +===+ +===+ +===+ 259 |C_1| |C_2| |C_3| |C_4| 260 +===+ +===+ +===+ +===+ 262 Figure 5: Example scenario where 1-D interleaved FEC protection fails 263 error recovery 265 1.2. Overhead Computation 267 The overhead is defined as the ratio of the number of bytes belonging 268 to the repair packets to the number of bytes belonging to the 269 protected source packets. 271 Assuming that each repair packet carries an equal number of bytes 272 carried by a source packet, we can compute the overhead as follows: 274 Overhead = 1/D 276 where D is the number of rows in the source block. 278 1.3. Relation to Existing Specifications 280 This section discusses the relation of the current specification to 281 other existing specifications. 283 1.3.1. RFC 2733 and RFC 3009 285 The current specification extends the FEC header defined in [RFC2733] 286 and registers a new RTP payload format. This new payload format is 287 not backward compatible with the payload format that was registered 288 by [RFC3009]. 290 1.3.2. SMPTE 2022-1 292 In 2007, the Society of Motion Picture and Television Engineers 293 (SMPTE) - Technology Committee N26 on File Management and Networking 294 Technology - decided to revise the Pro-MPEG Code of Practice (CoP) #3 295 Release 2 specification, which (was initially produced by the Pro- 296 MPEG Forum in 2004) discussed the several aspects of the transmission 297 of MPEG-2 transport streams over IP networks. The new SMPTE 298 specification is referred to as [SMPTE2022-1]. 300 The Pro-MPEG CoP #3 r2 document was originally based on [RFC2733]. 301 SMPTE revised the document by extending the FEC header (by setting 302 the E bit) proposed in [RFC2733]. This extended header offers some 303 improvements. 305 For example, instead of utilizing the bitmap field used in [RFC2733], 306 [SMPTE2022-1] introduces separate fields to convey the number of rows 307 (D) and columns (L) of the source block as well as the type of the 308 repair packet (i.e., whether the repair packet is an interleaved FEC 309 packet computed over a column or a non-interleaved FEC packet 310 computed over a row). These fields plus the base sequence number 311 allow the receiver side to establish the associations between the 312 source and repair packets. Note that although the bitmap field is 313 not utilized, the FEC header of [SMPTE2022-1] inherently carries over 314 the bitmap field from [RFC2733]. 316 On the other hand, some parts of [SMPTE2022-1] are not in compliant 317 with RTP [RFC3550]. For example, [SMPTE2022-1] sets the SSRC field 318 to zero and does not use the timestamp field in the RTP headers of 319 the repair packets (Receivers ignore the timestamps of the repair 320 packets). Furthermore, [SMPTE2022-1] also sets the CC field in the 321 RTP header to zero and does not allow any Contributing Source (CSRC) 322 entry in the RTP header. 324 The current document adopts the extended FEC header of [SMPTE2022-1] 325 and registers a new RTP payload format. At the same time, this 326 document fixes the parts of [SMPTE2022-1] that are not compliant with 327 RTP [RFC3550], except the one discussed below. 329 The baseline header format first proposed in [RFC2733] does not have 330 fields to protect the P and X bits and the CC fields of the source 331 packets associated with a repair packet. Rather, the P bit, X bit 332 and CC field in the RTP header of the repair packet are used to 333 protect those bits and fields. This, however, may sometimes result 334 in failures when doing the RTP header validity checks as specified in 335 [RFC3550]. While this behavior has been fixed in [RFC5109] that 336 obsoleted [RFC2733], the RTP payload format defined in this document 337 still allows for this behavior for legacy purposes. Implementations 338 following this specification MUST be aware of this potential issue 339 when RTP header validity checks are applied. 341 1.3.3. ETSI TS 102 034 343 In 2007, the Digital Video Broadcasting (DVB) consortium published a 344 technical specification [ETSI-TS-102-034] through European 345 Telecommunications Standards Institute (ETSI). This specification 346 covers several areas related to the transmission of MPEG-2 transport 347 stream-based services over IP networks. 349 The Annex E of [ETSI-TS-102-034] defines an optional protocol for 350 Application-layer FEC (AL-FEC) protection of streaming media for 351 DVB-IP services carried over RTP [RFC3550] transport. AL-FEC 352 protocol uses two layers for protection: a base layer that is 353 produced by a packet-based interleaved parity code, and an 354 enhancement layer that is produced by a Raptor code. While the use 355 of the enhancement layer is optional, the use of the base layer is 356 mandatory wherever AL-FEC is used. The DVB AL-FEC protocol is also 357 described in [I-D.ietf-fecframe-dvb-al-fec]. 359 The interleaved parity code that is used in the base layer is a 360 subset of [SMPTE2022-1]. In particular, AL-FEC base layer uses only 361 the 1-D interleaved FEC protection from [SMPTE2022-1]. The new RTP 362 payload format that is defined and registered in this document (with 363 some exceptions listed in [I-D.ietf-fecframe-dvb-al-fec]) is used as 364 the AL-FEC base layer. 366 2. Requirements Notation 368 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 369 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 370 document are to be interpreted as described in [RFC2119]. 372 3. Definitions, Notations and Abbreviations 374 The definitions and notations commonly used in this document are 375 summarized in this section. 377 3.1. Definitions 379 This document uses the following definitions: 381 Source Flow: The packet flow(s) carrying the source data and to 382 which FEC protection is to be applied. 384 Repair Flow: The packet flow(s) carrying the repair data. 386 Symbol: A unit of data. Its size, in bytes, is referred to as the 387 symbol size. 389 Source Symbol: The smallest unit of data used during the encoding 390 process. 392 Repair Symbol: Repair symbols are generated from the source symbols. 394 Source Packet: Data packets that contain only source symbols. 396 Repair Packet: Data packets that contain only repair symbols. 398 Source Block: A block of source symbols that are considered together 399 in the encoding process. 401 3.2. Notations 403 o L: Number of columns of the source block. 405 o D: Number of rows of the source block. 407 4. Packet Formats 409 This section defines the formats of the source and repair packets. 411 4.1. Source Packets 413 The source packets MUST contain the information that identifies the 414 source block and the position within the source block occupied by the 415 packet. Since the source packets that are carried within an RTP 416 stream already contain unique sequence numbers in their RTP headers 417 [RFC3550], we can identify the source packets in a straightforward 418 manner and there is no need to append additional field(s). The 419 primary advantage of not modifying the source packets in any way is 420 that it provides backward compatibility for the receivers that do not 421 support FEC at all. In multicast scenarios, this backward 422 compatibility becomes quite useful as it allows the non-FEC-capable 423 and FEC-capable receivers to receive and interpret the same source 424 packets sent in the same multicast session. 426 4.2. Repair Packets 428 The repair packets MUST contain information that identifies the 429 source block they pertain to and the relationship between the 430 contained repair symbols and the original source block. For this 431 purpose, we use the RTP header of the repair packets as well as 432 another header within the RTP payload, which we refer to as the FEC 433 header, as shown in Figure 6. 435 +------------------------------+ 436 | IP Header | 437 +------------------------------+ 438 | Transport Header | 439 +------------------------------+ 440 | RTP Header | __ 441 +------------------------------+ | 442 | FEC Header | \ 443 +------------------------------+ > RTP Payload 444 | Repair Symbols | / 445 +------------------------------+ __| 447 Figure 6: Format of repair packets 449 The RTP header is formatted according to [RFC3550] with some further 450 clarifications listed below: 452 o Version: The version field is set to 2. 454 o Padding (P) Bit: This bit is equal to the XOR sum of the 455 corresponding P bits from the RTP headers of the source packets 456 protected by this repair packet. However, padding octets are 457 never present in a repair packet, independent of the value of the 458 P bit. 460 o Extension (X) Bit: This bit is equal to the XOR sum of the 461 corresponding X bits from the RTP headers of the source packets 462 protected by this repair packet. However, an RTP header extension 463 is never present in a repair packet, independent of the value of 464 the X bit. 466 o CSRC Count (CC): This field is equal to the XOR sum of the 467 corresponding CC values from the RTP headers of the source packets 468 protected by this repair packet. However, a CSRC list is never 469 present in a repair packet, independent of the value of the CC 470 field. 472 o Marker (M) Bit: This bit is equal to the XOR sum of the 473 corresponding M bits from the RTP headers of the source packets 474 protected by this repair packet. 476 o Payload Type: The (dynamic) payload type for the repair packets 477 is determined through out-of-band means. Note that this document 478 registers a new payload format for the repair packets (Refer to 479 Section 5 for details). According to [RFC3550], an RTP receiver 480 that cannot recognize a payload type must discard it. This 481 provides backward compatibility. The FEC mechanisms can then be 482 used in a multicast group with mixed FEC-capable and non-FEC- 483 capable receivers. If a non-FEC-capable receiver receives a 484 repair packet, it will not recognize the payload type, and hence, 485 discards the repair packet. 487 o Sequence Number (SN): The sequence number has the standard 488 definition. It MUST be one higher than the sequence number in the 489 previously transmitted repair packet. The initial value of the 490 sequence number SHOULD be random (unpredictable) [RFC3550]. 492 o Timestamp (TS): The timestamp SHALL be set to a time 493 corresponding to the repair packet's transmission time. Note that 494 the timestamp value has no use in the actual FEC protection 495 process and is usually useful for jitter calculations. 497 o Synchronization Source (SSRC): The SSRC value SHALL be randomly 498 assigned as suggested by [RFC3550]. This allows the sender to 499 multiplex the source and repair flows on the same port, or 500 multiplex multiple repair flows on a single port. The repair 501 flows SHOULD use the RTCP CNAME field to associate themselves with 502 the source flow. 504 In some networks, the RTP Source, which produces the source 505 packets and the FEC Source, which generates the repair packets 506 from the source packets may not be the same host. In such 507 scenarios, using the same CNAME for the source and repair flows 508 means that the RTP Source and the FEC Source MUST share the same 509 CNAME (for this specific source-repair flow association). A 510 common CNAME may be produced based on an algorithm that is known 511 both to the RTP and FEC Source. This usage is compliant with 512 [RFC3550]. 514 Note that due to the randomness of the SSRC assignments, there is 515 a possibility of SSRC collision. In such cases, the collisions 516 MUST be resolved as described in [RFC3550]. 518 Note that the P bit, X bit, CC field and M bit of the source packets 519 are protected by the corresponding bits/fields in the RTP header of 520 the repair packet. On the other hand, the payload of a repair packet 521 protects the concatenation of (if present) the CSRC list, RTP 522 extension, payload and padding of the source RTP packets associated 523 with this repair packet. 525 The FEC header is 16 octets. The format of the FEC header is shown 526 in Figure 7. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | SN base low | Length recovery | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |E| PT recovery | Mask | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | TS recovery | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |N|D|Type |Index| Offset | NA | SN base ext | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Figure 7: Format of the FEC header 542 The FEC header consists of the following fields: 544 o The SN base low field is used to indicate the lowest sequence 545 number, taking wrap around into account, of those source packets 546 protected by this repair packet. 548 o The Length recovery field is used to determine the length of any 549 recovered packets. 551 o The E bit is the extension flag introduced in [RFC2733] and used 552 to extend the [RFC2733] FEC header. 554 o The PT recovery field is used to determine the payload type of the 555 recovered packets. 557 o The Mask field is not used. 559 o The TS recovery field is used to determine the timestamp of the 560 recovered packets. 562 o The N bit is the extension flag that is reserved for future uses. 564 o The D bit is not used. 566 o The Type field indicates the type of the error-correcting code 567 used. This document defines only one error-correcting code. 569 o The Index field is not used. 571 o The Offset and NA fields are used to indicate the number of 572 columns (L) and rows (D) of the source block, respectively. 574 o The SN base ext field is not used. 576 The details on setting the fields in the FEC header are provided in 577 Section 6.2. 579 It should be noted that a mask-based approach (similar to the one 580 specified in [RFC2733]) may not be very efficient to indicate which 581 source packets in the current source block are associated with a 582 given repair packet. In particular, for the applications that would 583 like to use large source block sizes, the size of the mask that is 584 required to describe the source-repair packet associations may be 585 prohibitively large. Instead, a systematized approach is inherently 586 more efficient. 588 5. Payload Format Parameters 590 This section provides the media subtype registration for the 1-D 591 interleaved parity FEC. The parameters that are required to 592 configure the FEC encoding and decoding operations are also defined 593 in this section. 595 5.1. Media Type Registration 597 This registration is done using the template defined in [RFC4288] and 598 following the guidance provided in [RFC3555]. 600 Note to the RFC Editor: In the following sections, please replace 601 "XXXX" with the number of this document prior to publication as an 602 RFC. 604 5.1.1. Registration of audio/1d-interleaved-parityfec 606 Type name: audio 608 Subtype name: 1d-interleaved-parityfec 610 Required parameters: 612 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 613 than 1000 Hz to provide sufficient resolution to RTCP operations. 614 However, it is RECOMMENDED to select the rate that matches the 615 rate of the protected source RTP stream. 617 o L: Number of columns of the source block. L is a positive 618 integer that is less than or equal to 255. 620 o D: Number of rows of the source block. D is a positive integer 621 that is less than or equal to 255. 623 o repair-window: The time that spans the source packets and the 624 corresponding repair packets. An FEC encoder processes a block of 625 source packets and generates a number of repair packets, which are 626 then transmitted within a certain duration. At the receiver, the 627 FEC decoder tries to decode all the packets received within the 628 repair window to recover the missing packets. Assuming that there 629 is no issue of delay variation, the FEC decoder SHOULD NOT wait 630 longer than the repair window since additional waiting would not 631 help the recovery process. The size of the repair window is 632 specified in microseconds. 634 Optional parameters: None. 636 Encoding considerations: This media type is framed (See Section 4.8 637 in the template document [RFC4288]) and contains binary data. 639 Security considerations: See Section 9 of [RFCXXXX]. 641 Interoperability considerations: None. 643 Published specification: [RFCXXXX]. 645 Applications that use this media type: Multimedia applications that 646 want to improve resiliency against packet loss by sending redundant 647 data in addition to the source media. 649 Additional information: None. 651 Person & email address to contact for further information: Ali Begen 652 and IETF Audio/Video Transport Working Group. 654 Intended usage: COMMON. 656 Restriction on usage: This media type depends on RTP framing, and 657 hence, is only defined for transport via RTP [RFC3550]. 659 Author: Ali Begen . 661 Change controller: IETF Audio/Video Transport Working Group 662 delegated from the IESG. 664 5.1.2. Registration of video/1d-interleaved-parityfec 666 Type name: video 668 Subtype name: 1d-interleaved-parityfec 670 Required parameters: 672 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 673 than 1000 Hz to provide sufficient resolution to RTCP operations. 674 However, it is RECOMMENDED to select the rate that matches the 675 rate of the protected source RTP stream. 677 o L: Number of columns of the source block. L is a positive 678 integer that is less than or equal to 255. 680 o D: Number of rows of the source block. D is a positive integer 681 that is less than or equal to 255. 683 o repair-window: The time that spans the source packets and the 684 corresponding repair packets. An FEC encoder processes a block of 685 source packets and generates a number of repair packets, which are 686 then transmitted within a certain duration. At the receiver, the 687 FEC decoder tries to decode all the packets received within the 688 repair window to recover the missing packets. Assuming that there 689 is no issue of delay variation, the FEC decoder SHOULD NOT wait 690 longer than the repair window since additional waiting would not 691 help the recovery process. The size of the repair window is 692 specified in microseconds. 694 Optional parameters: None. 696 Encoding considerations: This media type is framed (See Section 4.8 697 in the template document [RFC4288]) and contains binary data. 699 Security considerations: See Section 9 of [RFCXXXX]. 701 Interoperability considerations: None. 703 Published specification: [RFCXXXX]. 705 Applications that use this media type: Multimedia applications that 706 want to improve resiliency against packet loss by sending redundant 707 data in addition to the source media. 709 Additional information: None. 711 Person & email address to contact for further information: Ali Begen 712 and IETF Audio/Video Transport Working Group. 714 Intended usage: COMMON. 716 Restriction on usage: This media type depends on RTP framing, and 717 hence, is only defined for transport via RTP [RFC3550]. 719 Author: Ali Begen . 721 Change controller: IETF Audio/Video Transport Working Group 722 delegated from the IESG. 724 5.1.3. Registration of text/1d-interleaved-parityfec 726 Type name: text 728 Subtype name: 1d-interleaved-parityfec 730 Required parameters: 732 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 733 than 1000 Hz to provide sufficient resolution to RTCP operations. 734 However, it is RECOMMENDED to select the rate that matches the 735 rate of the protected source RTP stream. 737 o L: Number of columns of the source block. L is a positive 738 integer that is less than or equal to 255. 740 o D: Number of rows of the source block. D is a positive integer 741 that is less than or equal to 255. 743 o repair-window: The time that spans the source packets and the 744 corresponding repair packets. An FEC encoder processes a block of 745 source packets and generates a number of repair packets, which are 746 then transmitted within a certain duration. At the receiver, the 747 FEC decoder tries to decode all the packets received within the 748 repair window to recover the missing packets. Assuming that there 749 is no issue of delay variation, the FEC decoder SHOULD NOT wait 750 longer than the repair window since additional waiting would not 751 help the recovery process. The size of the repair window is 752 specified in microseconds. 754 Optional parameters: None. 756 Encoding considerations: This media type is framed (See Section 4.8 757 in the template document [RFC4288]) and contains binary data. 759 Security considerations: See Section 9 of [RFCXXXX]. 761 Interoperability considerations: None. 763 Published specification: [RFCXXXX]. 765 Applications that use this media type: Multimedia applications that 766 want to improve resiliency against packet loss by sending redundant 767 data in addition to the source media. 769 Additional information: None. 771 Person & email address to contact for further information: Ali Begen 772 and IETF Audio/Video Transport Working Group. 774 Intended usage: COMMON. 776 Restriction on usage: This media type depends on RTP framing, and 777 hence, is only defined for transport via RTP [RFC3550]. 779 Author: Ali Begen . 781 Change controller: IETF Audio/Video Transport Working Group 782 delegated from the IESG. 784 5.1.4. Registration of application/1d-interleaved-parityfec 786 Type name: application 787 Subtype name: 1d-interleaved-parityfec 789 Required parameters: 791 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 792 than 1000 Hz to provide sufficient resolution to RTCP operations. 793 However, it is RECOMMENDED to select the rate that matches the 794 rate of the protected source RTP stream. 796 o L: Number of columns of the source block. L is a positive 797 integer that is less than or equal to 255. 799 o D: Number of rows of the source block. D is a positive integer 800 that is less than or equal to 255. 802 o repair-window: The time that spans the source packets and the 803 corresponding repair packets. An FEC encoder processes a block of 804 source packets and generates a number of repair packets, which are 805 then transmitted within a certain duration. At the receiver, the 806 FEC decoder tries to decode all the packets received within the 807 repair window to recover the missing packets. Assuming that there 808 is no issue of delay variation, the FEC decoder SHOULD NOT wait 809 longer than the repair window since additional waiting would not 810 help the recovery process. The size of the repair window is 811 specified in microseconds. 813 Optional parameters: None. 815 Encoding considerations: This media type is framed (See Section 4.8 816 in the template document [RFC4288]) and contains binary data. 818 Security considerations: See Section 9 of [RFCXXXX]. 820 Interoperability considerations: None. 822 Published specification: [RFCXXXX]. 824 Applications that use this media type: Multimedia applications that 825 want to improve resiliency against packet loss by sending redundant 826 data in addition to the source media. 828 Additional information: None. 830 Person & email address to contact for further information: Ali Begen 831 and IETF Audio/Video Transport Working Group. 833 Intended usage: COMMON. 835 Restriction on usage: This media type depends on RTP framing, and 836 hence, is only defined for transport via RTP [RFC3550]. 838 Author: Ali Begen . 840 Change controller: IETF Audio/Video Transport Working Group 841 delegated from the IESG. 843 5.2. Mapping to SDP Parameters 845 Applications that are using RTP transport commonly use Session 846 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 847 The information that is used to specify the media types in an RTP 848 session has specific mappings to the fields in an SDP description. 849 In this section, we provide these mappings for the media subtype 850 registered by this document ("1d-interleaved-parityfec"). Note that 851 if an application does not use SDP to describe the RTP sessions, an 852 appropriate mapping must be defined and used to specify the media 853 types and their parameters for the control/description protocol 854 employed by the application. 856 The mapping of the media type specification for "1d-interleaved- 857 parityfec" and its parameters in SDP is as follows: 859 o The media type (e.g., "application") goes into the "m=" line as 860 the media name. 862 o The media subtype ("1d-interleaved-parityfec") goes into the 863 "a=rtpmap" line as the encoding name. The RTP clock rate 864 parameter ("rate") also goes into the "a=rtpmap" line as the clock 865 rate. 867 o The remaining required payload-format-specific parameters go into 868 the "a=fmtp" line by copying them directly from the media type 869 string as a semicolon-separated list of parameter=value pairs. 871 SDP examples are provided in Section 7. 873 5.2.1. Offer-Answer Model Considerations 875 When offering 1-D interleaved parity FEC over RTP using SDP in an 876 Offer/Answer model [RFC3264], the following considerations apply: 878 o Each combination of the L and D parameters produces a different 879 FEC data and is not compatible with any other combination. A 880 sender application may desire to offer multiple offers with 881 different sets of L and D values as long as the parameter values 882 are valid. The receiver SHOULD normally choose the offer that has 883 a sufficient amount of interleaving. If multiple such offers 884 exist, the receiver may choose the offer that has the lowest 885 overhead or the one that requires the smallest amount of 886 buffering. The selection depends on the application requirements. 888 o The value for the repair-window parameter depends on the L and D 889 values and cannot be chosen arbitrarily. More specifically, L and 890 D values determine the lower limit for the repair-window size. 891 The upper limit of the repair-window size does not depend on the L 892 and D values. 894 o Although combinations with the same L and D values but with 895 different repair-window sizes produce the same FEC data, such 896 combinations are still considered different offers. The size of 897 the repair-window is related to the maximum delay between the 898 transmission of a source packet and the associated repair packet. 899 This directly impacts the buffering requirement on the receiver 900 side and the receiver must consider this when choosing an offer. 902 o There are no optional format parameters defined for this payload. 903 Any unknown option in the offer MUST be ignored and deleted from 904 the answer. If FEC is not desired by the receiver, it can be 905 deleted from the answer. 907 5.2.2. Declarative Considerations 909 In declarative usage, like SDP in the Real-time Streaming Protocol 910 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 911 [RFC2974], the following considerations apply: 913 o The payload format configuration parameters are all declarative 914 and a participant MUST use the configuration that is provided for 915 the session. 917 o More than one configuration may be provided (if desired) by 918 declaring multiple RTP payload types. In that case, the receivers 919 should choose the repair flow that is best for them. 921 6. Protection and Recovery Procedures 923 This section provides a complete specification of the 1-D interleaved 924 parity code and its RTP payload format. 926 6.1. Overview 928 The following sections specify the steps involved in generating the 929 repair packets and reconstructing the missing source packets from the 930 repair packets. 932 6.2. Repair Packet Construction 934 The RTP header of a repair packet is formed based on the guidelines 935 given in Section 4.2. 937 The FEC header includes 16 octets. It is constructed by applying the 938 XOR operation on the bit strings that are generated from the 939 individual source packets protected by this particular repair packet. 940 The set of the source packets that are associated with a given repair 941 packet can be computed by the formula given in Section 6.3.1. 943 The bit string is formed for each source packet by concatenating the 944 following fields together in the order specified: 946 o Padding bit (1 bit) (This is the most significant bit of the bit 947 string) 949 o Extension bit (1 bit) 951 o CC field (4 bits) 953 o Marker bit (1 bit) 955 o PT field (7 bits) 957 o Timestamp (32 bits) 959 o Unsigned network-ordered 16-bit representation of the source 960 packet length in bytes minus 12 (for the fixed RTP header), i.e., 961 the sum of the lengths of all the following if present: the CSRC 962 list, header extension, RTP payload and RTP padding (16 bits) 964 o If CC is nonzero, the CSRC list (variable length) 966 o If X is 1, the header extension (variable length) 968 o Payload (variable length) 970 o Padding, if present (variable length) 972 Note that if the lengths of the source packets are not equal, each 973 shorter packet MUST be padded to the length of the longest packet by 974 adding octet 0's at the end. Due to this possible padding and 975 mandatory FEC header, a repair packet has a larger size than the 976 source packets it protects. This may cause problems if the resulting 977 repair packet size exceeds the Maximum Transmission Unit (MTU) size 978 of the path over which the repair flow is sent. 980 By applying the parity operation on the bit strings produced from the 981 source packets, we generate the FEC bit string. Some parts of the 982 RTP header and the FEC header of the repair packet are generated from 983 the FEC bit string as follows: 985 o The first (most significant) bit in the FEC bit string is written 986 into the Padding bit in the RTP header of the repair packet. 988 o The next bit in the FEC bit string is written into the Extension 989 bit in the RTP header of the repair packet. 991 o The next 4 bits of the FEC bit string are written into the CC 992 field in the RTP header of the repair packet. 994 o The next bit of the FEC bit string is written into the Marker bit 995 in the RTP header of the repair packet. 997 o The next 7 bits of the FEC bit string are written into the PT 998 recovery field in the FEC header. 1000 o The next 32 bits of the FEC bit string are written into the TS 1001 recovery field in the FEC header. 1003 o The next 16 bits are written into the Length recovery field in the 1004 FEC header. This allows the FEC procedure to be applied even when 1005 the lengths of the protected source packets are not identical. 1007 o The remaining bits are set to be the payload of the repair packet. 1009 The remaining parts of the FEC header are set as follows: 1011 o The SN base low field MUST be set to the lowest sequence number, 1012 taking wrap around into account, of those source packets protected 1013 by this repair packet. 1015 o The E bit MUST be set to 1 to extend the [RFC2733] FEC header. 1017 o The Mask field SHALL be set to 0 and ignored by the receiver. 1019 o The N bit SHALL be set to 0 and ignored by the receiver. 1021 o The D bit SHALL be set to 0 and ignored by the receiver. 1023 o The Type field MUST be set to 0. 1025 o The Index field SHALL be set to 0 and ignored by the receiver. 1027 o The Offset field MUST be set to the number of columns of the 1028 source block (L). 1030 o The NA field MUST be set to the number of rows of the source block 1031 (D). 1033 o The SN base ext field SHALL be set to 0 and ignored by the 1034 receiver. 1036 6.3. Source Packet Reconstruction 1038 This section describes the recovery procedures that are required to 1039 reconstruct the missing source packets. The recovery process has two 1040 steps. In the first step, the FEC decoder determines which source 1041 and repair packets should be used in order to recover a missing 1042 packet. In the second step, the decoder recovers the missing packet, 1043 which consists of an RTP header and RTP payload. 1045 In the following, we describe the RECOMMENDED algorithms for the 1046 first and second steps. Based on the implementation, different 1047 algorithms MAY be adopted. However, the end result MUST be identical 1048 to the one produced by the algorithms described below. 1050 6.3.1. Associating the Source and Repair Packets 1052 The first step is to associate the source and repair packets. The SN 1053 base low field in the FEC header shows the lowest sequence number of 1054 the source packets that form the particular column. In addition, the 1055 information of how many source packets are available in each column 1056 and row is available from the media type parameters specified in the 1057 SDP description. This set of information uniquely identifies all of 1058 the source packets associated with a given repair packet. 1060 Mathematically, for any received repair packet, p*, we can determine 1061 the sequence numbers of the source packets that are protected by this 1062 repair packet as follows: 1064 p*_snb + i * L (modulo 65536) 1066 where p*_snb denotes the value in the SN base low field of p*'s FEC 1067 header, L is the number of columns of the source block and 1069 0 <= i < D 1071 where D is the number of rows of the source block. 1073 We denote the set of the source packets associated with repair packet 1074 p* by set T(p*). Note that in a source block whose size is L columns 1075 by D rows, set T includes D source packets. Recall that 1-D 1076 interleaved FEC protection can fully recover the missing information 1077 if there is only one source packet missing in set T. If the repair 1078 packet that protects the source packets in set T is missing, or the 1079 repair packet is available but two or more source packets are 1080 missing, then missing source packets in set T cannot be recovered by 1081 1-D interleaved FEC protection. 1083 6.3.2. Recovering the RTP Header and Payload 1085 For a given set T, the procedure for the recovery of the RTP header 1086 of the missing packet, whose sequence number is denoted by SEQNUM, is 1087 as follows: 1089 1. For each of the source packets that are successfully received in 1090 set T, compute the bit string as described in Section 6.2. 1092 2. For the repair packet associated with set T, compute the bit 1093 string in the same fashion except use the PT recovery field 1094 instead of the PT field and TS recovery field instead of the 1095 Timestamp field, and set the CSRC list, header extension and 1096 padding to null regardless of the values of the CC field, X bit 1097 and P bit. 1099 3. If any of the bit strings generated from the source packets are 1100 shorter than the bit string generated from the repair packet, 1101 pad them to be the same length as the bit string generated from 1102 the repair packet. For padding, the padding of octet 0 MUST be 1103 added at the end of the bit string. 1105 4. Calculate the recovered bit string as the XOR of the bit strings 1106 generated from all source packets in set T and the FEC bit 1107 string generated from the repair packet associated with set T. 1109 5. Create a new packet with the standard 12-byte RTP header and no 1110 payload. 1112 6. Set the version of the new packet to 2. 1114 7. Set the Padding bit in the new packet to the first bit in the 1115 recovered bit string. 1117 8. Set the Extension bit in the new packet to the next bit in the 1118 recovered bit string. 1120 9. Set the CC field to the next 4 bits in the recovered bit string. 1122 10. Set the Marker bit in the new packet to the next bit in the 1123 recovered bit string. 1125 11. Set the Payload type in the new packet to the next 7 bits in the 1126 recovered bit string. 1128 12. Set the SN field in the new packet to SEQNUM. 1130 13. Set the TS field in the new packet to the next 32 bits in the 1131 recovered bit string. 1133 14. Take the next 16 bits of the recovered bit string and set the 1134 new variable Y to whatever unsigned integer this represents 1135 (assuming network order). Convert Y to host order and then take 1136 Y bytes from the recovered bit string and append them to the new 1137 packet. Y represents the length of the new packet in bytes 1138 minus 12 (for the fixed RTP header), i.e., the sum of the 1139 lengths of all the following if present: the CSRC list, header 1140 extension, RTP payload and RTP padding. 1142 15. Set the SSRC of the new packet to the SSRC of the source RTP 1143 stream. 1145 This procedure completely recovers both the header and payload of an 1146 RTP packet. 1148 7. Session Description Protocol (SDP) Signaling 1150 This section provides an SDP [RFC4566] example. The following 1151 example uses the FEC grouping semantics [RFC4756]. 1153 In this example, we have one source video stream (mid:S1) and one FEC 1154 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 1155 S1 R1" line. The source and repair streams are sent to the same port 1156 on different multicast groups. The repair window is set to 200 ms. 1158 v=0 1159 o=ali 1122334455 1122334466 IN IP4 fec.example.com 1160 s=Interleaved Parity FEC Example 1161 t=0 0 1162 a=group:FEC S1 R1 1163 m=video 30000 RTP/AVP 100 1164 c=IN IP4 233.252.0.1/127 1165 a=rtpmap:100 MP2T/90000 1166 a=mid:S1 1167 m=application 30000 RTP/AVP 110 1168 c=IN IP4 233.252.0.2/127 1169 a=rtpmap:110 1d-interleaved-parityfec/90000 1170 a=fmtp:110 L:5; D:10; repair-window:200000 1171 a=mid:R1 1173 8. Congestion Control Considerations 1175 FEC is an effective approach to provide applications resiliency 1176 against packet losses. However, in networks where the congestion is 1177 a major contributor to the packet loss, the potential impacts of 1178 using FEC SHOULD be considered carefully before injecting the repair 1179 flows into the network. In particular, in bandwidth-limited 1180 networks, FEC repair flows may consume most or all of the available 1181 bandwidth and may consequently congest the network. In such cases, 1182 the applications MUST NOT arbitrarily increase the amount of FEC 1183 protection since doing so may lead to a congestion collapse. If 1184 desired, stronger FEC protection MAY be applied only after the source 1185 rate has been reduced. 1187 In a network-friendly implementation, an application SHOULD NOT send/ 1188 receive FEC repair flows if it knows that sending/receiving those FEC 1189 repair flows would not help at all in recovering the missing packets. 1190 Such a practice helps reduce the amount of wasted bandwidth. It is 1191 RECOMMENDED that the amount of FEC protection is adjusted dynamically 1192 based on the packet loss rate observed by the applications. 1194 In multicast scenarios, it may be difficult to optimize the FEC 1195 protection per receiver. If there is a large variation among the 1196 levels of FEC protection needed by different receivers, it is 1197 RECOMMENDED that the sender offers multiple repair flows with 1198 different levels of FEC protection and the receivers join the 1199 corresponding multicast sessions to receive the repair flow(s) that 1200 is best for them. 1202 9. Security Considerations 1204 RTP packets using the payload format defined in this specification 1205 are subject to the security considerations discussed in the RTP 1206 specification [RFC3550] and in any applicable RTP profile. The main 1207 security considerations for the RTP packet carrying the RTP payload 1208 format defined within this memo are confidentiality, integrity and 1209 source authenticity. Confidentiality is achieved by encrypting the 1210 RTP payload. Integrity of the RTP packets is achieved through a 1211 suitable cryptographic integrity protection mechanism. Such a 1212 cryptographic system may also allow the authentication of the source 1213 of the payload. A suitable security mechanism for this RTP payload 1214 format should provide confidentiality, integrity protection, and at 1215 least source authentication capable of determining if an RTP packet 1216 is from a member of the RTP session. 1218 Note that the appropriate mechanism to provide security to RTP and 1219 payloads following this memo may vary. It is dependent on the 1220 application, transport and signaling protocol employed. Therefore, a 1221 single mechanism is not sufficient, although if suitable, using the 1222 Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 1223 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1224 Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may 1225 exist. 1227 10. IANA Considerations 1229 New media subtypes are subject to IANA registration. For the 1230 registration of the payload format and its parameters introduced in 1231 this document, refer to Section 5. 1233 11. Acknowledgments 1235 A major part of this document is borrowed from [RFC2733] and 1236 [SMPTE2022-1]. Thus, the author would like to thank the authors and 1237 editors of these earlier specifications. The author also thanks 1238 Colin Perkins for his constructive suggestions for this document. 1240 12. Change Log 1242 12.1. draft-ietf-fecframe-interleaved-fec-scheme-05 1244 The following are the major changes compared to version 04: 1246 o Comments from Vincent Roca have been addressed. 1248 12.2. draft-ietf-fecframe-interleaved-fec-scheme-04 1250 The following are the major changes compared to version 03: 1252 o Further comments from AVT WG have been addressed. 1254 12.3. draft-ietf-fecframe-interleaved-fec-scheme-03 1256 The following are the major changes compared to version 02: 1258 o Comments from WGLC have been addressed. 1260 12.4. draft-ietf-fecframe-interleaved-fec-scheme-02 1262 The following are the major changes compared to version 01: 1264 o Some details were added regarding the use of CNAME field. 1266 o Offer-Answer and Declarative Considerations sections have been 1267 completed. 1269 o Security Considerations section has been completed. 1271 12.5. draft-ietf-fecframe-interleaved-fec-scheme-01 1273 The following are the major changes compared to version 00: 1275 o The timestamp field definition has changed. 1277 12.6. draft-ietf-fecframe-interleaved-fec-scheme-00 1279 This is the initial version, which is based on an earlier individual 1280 submission. The following are the major changes compared to that 1281 document: 1283 o Per the discussion in the WG, references to the FEC Framework have 1284 been removed and the document has been turned into a pure RTP 1285 payload format specification. 1287 o A new section is added for congestion control considerations. 1289 o Editorial changes to clarify a few points. 1291 13. References 1292 13.1. Normative References 1294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1295 Requirement Levels", BCP 14, RFC 2119, March 1997. 1297 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1298 Jacobson, "RTP: A Transport Protocol for Real-Time 1299 Applications", STD 64, RFC 3550, July 2003. 1301 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1302 Description Protocol", RFC 4566, July 2006. 1304 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 1305 Session Description Protocol", RFC 4756, November 2006. 1307 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1308 Registration Procedures", BCP 13, RFC 4288, December 2005. 1310 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1311 Payload Formats", RFC 3555, July 2003. 1313 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1314 with Session Description Protocol (SDP)", RFC 3264, 1315 June 2002. 1317 13.2. Informative References 1319 [I-D.ietf-fecframe-dvb-al-fec] 1320 Begen, A. and T. Stockhammer, "DVB Application-Layer 1321 Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-01 1322 (work in progress), January 2009. 1324 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1325 for Generic Forward Error Correction", RFC 2733, 1326 December 1999. 1328 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 1329 parityfec MIME types", RFC 3009, November 2000. 1331 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1332 Correction", RFC 5109, December 2007. 1334 [ETSI-TS-102-034] 1335 ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB 1336 Services over IP Based Networks", October 2007. 1338 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1339 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1341 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1342 Announcement Protocol", RFC 2974, October 2000. 1344 [SMPTE2022-1] 1345 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 1346 Video/Audio Transport over IP Networks", 2007. 1348 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1349 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1350 RFC 3711, March 2004. 1352 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1353 Internet Protocol", RFC 4301, December 2005. 1355 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1356 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1358 Author's Address 1360 Ali Begen 1361 Cisco Systems 1362 170 West Tasman Drive 1363 San Jose, CA 95134 1364 USA 1366 Email: abegen@cisco.com