idnits 2.17.1 draft-ietf-fecframe-rtp-raptor-07.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 is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2012) is 4417 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) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-raptor-06 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-config-signaling-06 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework Working Group M. Watson 3 Internet-Draft Netflix 4 Intended status: Standards Track T. Stockhammer 5 Expires: August 27, 2012 Nomor Research 6 M. Luby 7 Qualcomm Incorporated 8 February 24, 2012 10 RTP Payload Format for Raptor FEC 11 draft-ietf-fecframe-rtp-raptor-07 13 Abstract 15 This document specifies an RTP Payload Format for Forward Error 16 Correction repair data produced by the Raptor FEC Schemes. Raptor 17 FEC Schemes are specified for use with the IETF FEC Framework which 18 supports transport of repair data over both UDP and RTP. This 19 document specifies the Payload Format which is required for the use 20 of RTP to carry Raptor repair flows. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 27, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 58 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 59 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Congestion Control Considerations . . . . . . . . . . . . . . 7 64 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Registration of the application/raptorfec media type . . . 8 66 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 67 6.2. Registration of the video/raptorfec media type . . . . . . 9 68 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 69 6.3. Registration of the audio/raptorfec media type . . . . . . 11 70 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 11 71 6.4. Registration of the text/raptorfec media type . . . . . . 13 72 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 13 73 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 16 75 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 17 76 10. Repair Flow Generation and Recovery Procedures . . . . . . . . 18 77 10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 10.2. Repair Packet Construction . . . . . . . . . . . . . . . . 18 79 10.3. Usage of RTCP . . . . . . . . . . . . . . . . . . . . . . 18 80 10.4. Source Packet Reconstruction . . . . . . . . . . . . . . . 19 81 11. Session Description Protocol (SDP) Example . . . . . . . . . . 20 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 86 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 The FEC Framework [RFC6363] defines a general framework for the use 92 of Forward Error Correction in association with arbitrary packet 93 flows, including flows over UDP and RTP [RFC3550]. Forward Error 94 Correction operates by generating redundant data packets ("repair 95 data") which can be sent independently from the original flow. At a 96 receiver the original flow can be reconstructed provided a sufficient 97 set of redundant data packets and possibly original data packets are 98 received. 100 The FEC Framework provides for independence between application 101 protocols and FEC codes. The use of a particular FEC code within the 102 framework is defined by means of a FEC Scheme which may then be used 103 with any application protocol compliant to the framework. 105 Repair data flows may be sent directly over a transport protocol such 106 as UDP, or they may be encapsulated within specialized transports for 107 multimedia, such as RTP. 109 This document defines the RTP Payload Format for the Raptor FEC 110 Schemes defined in [I-D.ietf-fecframe-raptor]. 112 2. Conventions, Definitions and Acronyms 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Media Format Background 120 The Raptor and RaptorQ codes are efficient block-based fountain 121 codes, meaning that from any group of source packets (or 'source 122 block') one can generate an arbitrary number of repair packets. The 123 Raptor and RaptorQ codes have the property that the original group of 124 source symbols can be recovered with very high probability from any 125 set of symbols (source and repair) only slightly greater in number 126 than the original number of source symbols. The RaptorQ code 127 additionally has the property that the probability that the original 128 group of source symbols can be recovered from a set of symbols 129 (source and repair) equal in number to the original number of source 130 symbols is in many cases also very high. 132 [I-D.ietf-fecframe-raptor] defines six FEC Schemes for the use of the 133 Raptor and RaptorQ codes with arbitrary packet flows: the first two 134 schemes are fully applicable to arbitrary packet flows (using Raptor 135 and RaptorQ respectively). The third and fourth schemes are slightly 136 optimised versions of the first two schemes which are applicable in 137 applications with relatively small block sizes. The fifth and sixth 138 schemes are variants of the third and fourth schemes which are 139 applicable to a single source flow which already has some kind of 140 identifiable sequence number. The presence of a sequence number in 141 the source flow allows for backwards-compatible operation (the source 142 flows do not need to be modified in order to apply FEC). In this 143 case, in the language of the FEC Framework, there is no need for an 144 explicit FEC Source Payload Id and it is therefore not included in 145 the packets. 147 This document specifies the payload format for RTP repair flows and 148 can be used with any of the FEC Schemes defined in 149 [I-D.ietf-fecframe-raptor]. 151 4. Payload Format 153 4.1. RTP Header Usage 155 Header fields SHALL be set according to the rules of [RFC3550]. In 156 addition, the following rules and definitions apply for the RTP 157 header used with FEC repair packets: 159 o Marker bit: The marker bit SHALL be set to 1 for the last 160 protection RTP packet sent for each source block, and otherwise 161 set to 0. 163 o Payload Type (PT): The payload type codes SHALL be assigned 164 dynamically through non-RTP means. If SDP is used for signaling, 165 the the rules in Section 7 apply. 167 o Timestamp: This field contains the time at which the packet is 168 transmitted. The time SHOULD be as close as possible to the 169 packet's actual time of transmission. The timestamp value has no 170 use in the actual FEC protection process. However, 171 implementations SHOULD supply a value that can be used for packet 172 arrival timing or jitter calculations. The timestamp rate is 173 specified using the "rate" media type parameter defined in 174 Section 6. The operator SHALL select a 'rate' larger than 1000 Hz 175 to provide sufficient resolution to RTCP operations and the 176 operator SHOULD select the rate that matches the rate of the 177 protected source RTP stream. 179 o SSRC: The SSRC values MUST be set according to [RFC3550]. The 180 SSRC value of the RTP repair flow MUST be different from the SSRC 181 value of the protected source flow. 183 4.2. Payload Header 185 There is no Payload Header in this Payload Format. 187 4.3. Payload Data 189 Procedures and data formats for the use of Raptor Forward Error 190 Correction in a FECFRAME context are fully defined in [RFC6363] and 191 [I-D.ietf-fecframe-raptor] and are not duplicated here. The 192 procedures of those documents apply in order to generate repair data 193 streams to be carried by the payload formats defined in this 194 document. 196 The RTP Payload SHALL contain a FEC Repair Payload as defined in 197 [RFC6363] and [I-D.ietf-fecframe-raptor]. 199 5. Congestion Control Considerations 201 See [RFC6363]. 203 6. Media Types 205 6.1. Registration of the application/raptorfec media type 207 This RTP payload format is identified using the application/raptorfec 208 media type which is registered in accordance with [RFC4855] and using 209 the template of [RFC4288]. 211 6.1.1. Media Type Definition 213 Type name: application 215 Subtype name: raptorfec 217 Required parameters: 219 o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) 220 rate is specified in Hz and the format is unsigned integer. 222 o raptor-scheme-id: The value of this parameter is the FEC Scheme Id 223 for the specific Raptor FEC Scheme that will be used as defined in 224 [I-D.ietf-fecframe-raptor]. 226 o Kmax: The value of this parameter is the FEC Framework 227 Configuration Information element "Maximum Source Block Length" as 228 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 229 integer. For specific requirements for this value refer to 230 [I-D.ietf-fecframe-raptor]. 232 o T: The value of this parameter is the FEC Framework Configuration 233 Information element "Encoding Symbol Size" as defined in 234 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For 235 specific requirements for this value refer to 236 [I-D.ietf-fecframe-raptor]. 238 o repair-window: The maximum time that spans the source packets and 239 the corresponding repair packets. The size of the repair window 240 is specified in microseconds and the format is unsigned integer. 242 Optional parameters: 244 o P: The value of this parameter is the FEC Framework Configuration 245 Information element "Payload ID Format" as defined in 246 [I-D.ietf-fecframe-raptor]. The default value of this parameter 247 (when it does not appear explicitly) is 'A'. 249 Encoding considerations: This media type is framed and binary, see 250 section 4.8 in [RFC4288] 251 Security considerations: Please see security consideration in 252 [RFC6363] 254 Interoperability considerations: 256 Published specification: [I-D.ietf-fecframe-raptor] 258 Applications that use this media type: Real-time multimedia 259 applications like video streaming, audio streaming, and video 260 conferencing. 262 Additional information: 264 Magic number(s): 266 File extension(s): 268 Macintosh file type code(s): 270 Person & email address to contact for further information: Thomas 271 Stockhammer, stockhammer@nomor.de 273 Intended usage: COMMON 275 Restrictions on usage: This media type depends on RTP framing, and 276 hence is only defined for transfer via RTP [[RFC3550]]. Transport 277 within other framing protocols is not defined at this time. 279 Author: Thomas Stockhammer, Nomor Research 281 Change controller: IETF Audio/Video Transport working group delegated 282 from the IESG. 284 6.2. Registration of the video/raptorfec media type 286 This RTP payload format is identified using the video/raptorfec media 287 type which is registered in accordance with [RFC4855] and using the 288 template of [RFC4288]. 290 6.2.1. Media Type Definition 292 Type name: video 294 Subtype name: raptorfec 296 Required parameters: 298 o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) 299 rate is specified in Hz and the format is unsigned integer. 301 o raptor-scheme-id: The value of this parameter is the FEC Scheme Id 302 for the specific Raptor FEC Scheme that will be used as defined in 303 [I-D.ietf-fecframe-raptor]. 305 o Kmax: The value of this parameter is the FEC Framework 306 Configuration Information element "Maximum Source Block Length" as 307 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 308 integer. For specific requirements for this value refer to 309 [I-D.ietf-fecframe-raptor]. 311 o T: The value of this parameter is the FEC Framework Configuration 312 Information element "Encoding Symbol Size" as defined in 313 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For 314 specific requirements for this value refer to 315 [I-D.ietf-fecframe-raptor]. 317 o repair-window: The maximum time that spans the source packets and 318 the corresponding repair packets. The size of the repair window 319 is specified in microseconds and the format is unsigned integer. 321 Optional parameters: 323 o P: The value of this parameter is the FEC Framework Configuration 324 Information element "Payload ID Format" as defined in 325 [I-D.ietf-fecframe-raptor]. The default value of this parameter 326 (when it does not appear explicitly) is 'A'. 328 Encoding considerations: This media type is framed and binary, see 329 section 4.8 in [RFC4288] 331 Security considerations: Please see security consideration in 332 [RFC6363] 334 Interoperability considerations: 336 Published specification: [I-D.ietf-fecframe-raptor] 338 Applications that use this media type: Real-time multimedia 339 applications like video streaming, audio streaming, and video 340 conferencing. 342 Additional information: 344 Magic number(s): 345 File extension(s): 347 Macintosh file type code(s): 349 Person & email address to contact for further information: Thomas 350 Stockhammer, stockhammer@nomor.de 352 Intended usage: COMMON 354 Restrictions on usage: This media type depends on RTP framing, and 355 hence is only defined for transfer via RTP [[RFC3550]]. Transport 356 within other framing protocols is not defined at this time. 358 Author: Thomas Stockhammer, Nomor Research. 360 Change controller: IETF Audio/Video Transport working group delegated 361 from the IESG. 363 6.3. Registration of the audio/raptorfec media type 365 This RTP payload format is identified using the audio/raptorfec media 366 type which is registered in accordance with [RFC4855] and using the 367 template of [RFC4288]. 369 6.3.1. Media Type Definition 371 Type name: audio 373 Subtype name: raptorfec 375 Required parameters: 377 o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) 378 rate is specified in Hz and the format is unsigned integer. 380 o raptor-scheme-id: The value of this parameter is the FEC Scheme Id 381 for the specific Raptor FEC Scheme that will be used as defined in 382 [I-D.ietf-fecframe-raptor]. 384 o Kmax: The value of this parameter is the FEC Framework 385 Configuration Information element "Maximum Source Block Length" as 386 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 387 integer. For specific requirements for this value refer to 388 [I-D.ietf-fecframe-raptor]. 390 o T: The value of this parameter is the FEC Framework Configuration 391 Information element "Encoding Symbol Size" as defined in 392 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For 393 specific requirements for this value refer to 394 [I-D.ietf-fecframe-raptor]. 396 o repair-window: The maximum time that spans the source packets and 397 the corresponding repair packets. The size of the repair window 398 is specified in microseconds and the format is unsigned integer. 400 Optional parameters: 402 o P: The value of this parameter is the FEC Framework Configuration 403 Information element "Payload ID Format" as defined in 404 [I-D.ietf-fecframe-raptor]. The default value of this parameter 405 (when it does not appear explicitly) is 'A'. 407 Encoding considerations: This media type is framed and binary, see 408 section 4.8 in [RFC4288] 410 Security considerations: Please see security consideration in 411 [RFC6363] 413 Interoperability considerations: 415 Published specification: [I-D.ietf-fecframe-raptor] 417 Applications that use this media type: Real-time multimedia 418 applications like video streaming, audio streaming, and video 419 conferencing. 421 Additional information: 423 Magic number(s): 425 File extension(s): 427 Macintosh file type code(s): 429 Person & email address to contact for further information: Thomas 430 Stockhammer, stockhammer@nomor.de 432 Intended usage: COMMON 434 Restrictions on usage: This media type depends on RTP framing, and 435 hence is only defined for transfer via RTP [[RFC3550]]. Transport 436 within other framing protocols is not defined at this time. 438 Author: Thomas Stockhammer, Nomor Research. 440 Change controller: IETF Audio/Video Transport working group delegated 441 from the IESG. 443 6.4. Registration of the text/raptorfec media type 445 This RTP payload format is identified using the text/raptorfec media 446 type which is registered in accordance with [RFC4855] and using the 447 template of [RFC4288]. 449 6.4.1. Media Type Definition 451 Type name: text 453 Subtype name: raptorfec 455 Required parameters: 457 o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) 458 rate is specified in Hz and the format is unsigned integer. 460 o raptor-scheme-id: The value of this parameter is the FEC Scheme Id 461 for the specific Raptor FEC Scheme that will be used as defined in 462 [I-D.ietf-fecframe-raptor]. 464 o Kmax: The value of this parameter is the FEC Framework 465 Configuration Information element "Maximum Source Block Length" as 466 defined in [I-D.ietf-fecframe-raptor] encoded as a decimal 467 integer. For specific requirements for this value refer to 468 [I-D.ietf-fecframe-raptor]. 470 o T: The value of this parameter is the FEC Framework Configuration 471 Information element "Encoding Symbol Size" as defined in 472 [I-D.ietf-fecframe-raptor] encoded as a decimal integer. For 473 specific requirements for this value refer to 474 [I-D.ietf-fecframe-raptor]. 476 o repair-window: The maximum time that spans the source packets and 477 the corresponding repair packets. The size of the repair window 478 is specified in microseconds and the format is unsigned integer. 480 Optional parameters: 482 o P: The value of this parameter is the FEC Framework Configuration 483 Information element "Payload ID Format" as defined in 484 [I-D.ietf-fecframe-raptor]. The default value of this parameter 485 (when it does not appear explicitly) is 'A'. 487 Encoding considerations: This media type is framed and binary, see 488 section 4.8 in [RFC4288] 489 Security considerations: Please see security consideration in 490 [RFC6363] 492 Interoperability considerations: 494 Published specification: [I-D.ietf-fecframe-raptor] 496 Applications that use this media type: Real-time multimedia 497 applications like video streaming, audio streaming, and video 498 conferencing. 500 Additional information: 502 Magic number(s): 504 File extension(s): 506 Macintosh file type code(s): 508 Person & email address to contact for further information: Thomas 509 Stockhammer, stockhammer@nomor.de 511 Intended usage: COMMON 513 Restrictions on usage: This media type depends on RTP framing, and 514 hence is only defined for transfer via RTP [[RFC3550]]. Transport 515 within other framing protocols is not defined at this time. 517 Author: Thomas Stockhammer, Nomor Research. 519 Change controller: IETF Audio/Video Transport working group delegated 520 from the IESG. 522 7. Mapping to SDP 524 Applications that are using RTP transport commonly use Session 525 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 526 The information that is used to specify the media types in an RTP 527 session has specific mappings to the fields in an SDP description. 528 Note that if an application does not use SDP to describe the RTP 529 sessions, an appropriate mapping must be defined and used to specify 530 the media types and their parameters for the control/description 531 protocol employed by the application. 533 The mapping of the above defined payload format media type and its 534 parameters SHALL be done according to Section 3 of [RFC4855] 535 following the suggestion therein regarding the mapping of payload- 536 format-specific parameters into the "'"a=fmtp"' field. 538 When the RTP Payload Formats defined in this document are used, the 539 Media Type Parameters defined above MUST use the media types in this 540 document and MUST NOT use those specified in [RFC6364]. 542 8. Offer/Answer considerations 544 When offering Raptor FEC over RTP using SDP in an Offer/Answer model 545 [RFC3264], the following considerations apply: 547 o Each combination of the Kmax and T parameters produces different 548 FEC data and is not compatible with any other combination. A 549 sender application MAY desire to offer multiple offers with 550 different sets of Kmax and T values as long as the parameter 551 values are valid. The receiver SHOULD normally choose the offer 552 with the largest value of the product of Kmax and T that it 553 supports. 555 o The size of the repair-window is related to the maximum delay 556 between the transmission of a source packet and the associated 557 repair packet. This directly impacts the buffering requirement on 558 the receiver side and the receiver must consider this when 559 choosing an offer. 561 o When the P parameter is not present, the receiver MUST use FEC 562 Payload ID Format A. In an answer which selects an offer in which 563 the P parameter was omitted, the P parameter MUST either be 564 omitted, or included with value "A". 566 9. Declarative SDP Considerations 568 In declarative usage, like SDP in the Real-time Streaming Protocol 569 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 570 [RFC2974], the following considerations apply: 572 o The payload format configuration parameters are all declarative 573 and a participant MUST use the configuration that is provided for 574 the session. 576 o More than one configuration MAY be provided (if desired) by 577 declaring multiple RTP payload types. In that case, the receivers 578 should choose the repair session that is best for them. 580 10. Repair Flow Generation and Recovery Procedures 582 10.1. Overview 584 This document only specifies the repair flow construction when the 585 repair packets are delivered with RTP. Source packet construction is 586 covered in [I-D.ietf-fecframe-raptor]. This section provides an 587 overview on how to generate a repair flow including the repair 588 packets and on how to reconstruct missing source packets from a set 589 of available source and repair packets. Detailed algorithms for the 590 generation of Raptor and RaptorQ symbols are provided in [RFC5053] 591 and [RFC6330], respectively. 593 As per the FEC Framework document [RFC6363] the FEC Framework 594 Configuration Information includes among others the identification of 595 the repair flow(s) and the source flow(s). Methods to convey FEC 596 Framework Configuration Information are provided in 597 [I-D.ietf-fecframe-config-signaling]. Specifically, the reader is 598 referred to the SDP elements document [RFC6364], which describes the 599 usage of 'SDP' encoding format as an example encoding format for FEC 600 Framework Configuration Information. 602 For the generation of a repair flow 604 o repair packets SHALL be constructed according to Section 10.2, and 606 o RTCP SHALL be used according to Section 10.3. 608 For the reconstruction of a source packets of a source RTP session at 609 the receiver based on the availability of a source RTP session and an 610 repair RTP session the procedures in Section 10.4 may be used. 612 10.2. Repair Packet Construction 614 The construction of the repair packet is fully specified in 615 Section 4. A repair packet is constructed by the concatenation of 617 o an RTP header as specified in Section 4.1, and 619 o payload data as defined in Section 4.3. 621 Repair Packet Construction may make use of the Sender Operation for 622 RTP repair flows as specified in see [RFC6363], section 4.2. 624 10.3. Usage of RTCP 626 RTCP SHALL be used according to [RFC3550]. If the repair RTP session 627 is sent in a separate RTP session the two sessions MUST be associated 628 using RTCP CNAME. 630 10.4. Source Packet Reconstruction 632 Source Packet Reconstruction may make use of the Receiver Operation 633 for the case of RTP repair flows as specified in [RFC6363], section 634 4.3. Depending on the FEC scheme in use of the ones defined in 635 [I-D.ietf-fecframe-raptor], the appropriate source blocks are formed. 636 If enough data for decoding of any or all of the missing source 637 payloads in the source block has been received, the respective FEC 638 decoding procedures are applied. 640 In case the FEC scheme uses Raptor codes as defined in [RFC5053], 641 then the Example FEC decoder as specifed in [RFC5053], section 5.5, 642 may be used. 644 In case the FEC scheme uses RaptorQ codes as defined in [RFC6330], 645 then the Example FEC decoder as specified in [RFC6330], section 5.4, 646 may be used. 648 11. Session Description Protocol (SDP) Example 650 This section provides an SDP [RFC4566] example. Assume we have one 651 source video stream (mid:S1) and one FEC repair stream (mid:R1). The 652 'group' attribute and the FEC grouping semantics defined in [RFC5888] 653 and [RFC5956], respectively, are used to associate source and repair 654 flows. We form one FEC group with the "a=group:FEC S1 R1" line. The 655 source and repair streams are sent to the same port on different 656 multicast groups. The repair window is set to 200 ms. 658 v=0 659 o=ali 1122334455 1122334466 IN IP4 fec.example.com 660 s=Raptor RTP FEC Example 661 t=0 0 662 a=group:FEC-FR S1 R1 663 m=video 30000 RTP/AVP 100 664 c=IN IP4 233.252.0.1/127 665 a=rtpmap:100 MP2T/90000 666 a=fec-source-flow: id=0 667 a=mid:S1 668 m=application 30000 RTP/AVP 110 669 c=IN IP4 233.252.0.2/127 670 a=rtpmap:110 raptorfec/90000 671 a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128; P=A; repair-window=200000 672 a=mid:R1 674 12. IANA Considerations 676 This memo requests that IANA registers application/raptorfec as 677 specified in Section 6.1.1, video/raptorfec as specified in 678 Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and 679 text/raptorfec as specified in Section 6.4.1. The media type is also 680 requested to be added to the IANA registry for "RTP Payload Format 681 MIME types" (http://www.iana.org/assignments/rtp-parameters). 683 13. Security Considerations 685 Security Considerations related to the use of the FEC Framework are 686 addressed in [RFC6363]. These consideration apply in full to users 687 of the RTP Payload Formats defined in this document, since these are 688 defined in terms of the FEC Framework. 690 No further security considerations related specifically to the Raptor 691 FEC Schemes defined in [I-D.ietf-fecframe-raptor] have been 692 identified. 694 RTP packets using the payload format defined in this specification 695 are subject to the security considerations discussed in the RTP 696 specification [RFC3550] and in any applicable RTP profile. The main 697 security considerations for the RTP packet carrying the RTP payload 698 format defined within this memo are confidentiality, integrity and 699 source authenticity. Confidentiality is achieved by encrypting the 700 RTP payload. Integrity of the RTP packets is achieved through a 701 suitable cryptographic integrity protection mechanism. Such a 702 cryptographic system can also allow the authentication of the source 703 of the payload. A suitable security mechanism for this RTP payload 704 format should provide confidentiality, integrity protection, and at 705 least source authentication capable of determining if an RTP packet 706 is from a member of the RTP session. Note that the appropriate 707 mechanism to provide security to RTP and payloads following this memo 708 MAY vary. It is dependent on the application, transport and 709 signaling protocol employed. Therefore, a single mechanism is not 710 sufficient, although if suitable, using the Secure Real-time 711 Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms 712 that may be used are IPsec [RFC4301] and Transport Layer Security 713 (TLS) [RFC5246] (RTP over TCP); other alternatives exist. 715 14. References 717 14.1. Normative References 719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 720 Requirement Levels", BCP 14, RFC 2119, March 1997. 722 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 723 Jacobson, "RTP: A Transport Protocol for Real-Time 724 Applications", STD 64, RFC 3550, July 2003. 726 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 727 Registration Procedures", BCP 13, RFC 4288, December 2005. 729 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 730 Formats", RFC 4855, February 2007. 732 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 733 Correction (FEC) Framework", RFC 6363, October 2011. 735 [RFC6364] Begen, A., "Session Description Protocol Elements for the 736 Forward Error Correction (FEC) Framework", RFC 6364, 737 October 2011. 739 [I-D.ietf-fecframe-raptor] 740 Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC 741 Schemes for FECFRAME", draft-ietf-fecframe-raptor-06 (work 742 in progress), November 2011. 744 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 745 Description Protocol", RFC 4566, July 2006. 747 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 748 with Session Description Protocol (SDP)", RFC 3264, 749 June 2002. 751 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 752 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 753 RFC 3711, March 2004. 755 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 756 Internet Protocol", RFC 4301, December 2005. 758 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 759 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 761 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 762 "Raptor Forward Error Correction Scheme for Object 763 Delivery", RFC 5053, October 2007. 765 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 766 and L. Minder, "RaptorQ Forward Error Correction Scheme 767 for Object Delivery", RFC 6330, August 2011. 769 14.2. Informative References 771 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 772 Streaming Protocol (RTSP)", RFC 2326, April 1998. 774 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 775 Announcement Protocol", RFC 2974, October 2000. 777 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 778 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 780 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 781 the Session Description Protocol", RFC 5956, 782 September 2010. 784 [I-D.ietf-fecframe-config-signaling] 785 Asati, R., "Methods to convey FEC Framework Configuration 786 Information", draft-ietf-fecframe-config-signaling-06 787 (work in progress), September 2011. 789 Authors' Addresses 791 Mark Watson 792 Netflix 793 100 Winchester Circle 794 Los Gatos, CA 95032 795 U.S.A. 797 Email: watsonm@netflix.com 799 Thomas Stockhammer 800 Nomor Research 801 Brecherspitzstrasse 8 802 Munich 81541 803 Germany. 805 Email: stockhammer@nomor.de 807 Michael Luby 808 Qualcomm Incorporated 809 3165 Kifer Road 810 Santa Clara, CA 95051 811 U.S.A. 813 Email: luby@qualcomm.com