idnits 2.17.1 draft-mandyam-rtcweb-fecframebundledssrc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 16, 2015) is 3237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC5052' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC6364' is defined on line 380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Rtcweb Working Group G. Mandyam 3 Internet-Draft Qualcomm Innovation Center 4 Intended status: Informational M. Luby 5 Expires: December 18, 2015 Qualcomm Technologies Inc. 6 T. Stockhammer 7 Qualcomm CDMA Technologies GMBH 8 June 16, 2015 10 FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources 11 draft-mandyam-rtcweb-fecframebundledssrc-00 13 Abstract 15 The FEC FRAME Raptor code options do not currently address the case 16 of bundled protection of multiple media types over multiple real-time 17 transport protocol (RTP) synchronization sources (SSRC's). This 18 document provides the FEC source and repair payload definitions that 19 enable a single repair flow to be defined for multiple RTP flows 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 18, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Multi-sequenced Flows with Explicit Source FEC Payload ID . . 2 57 2.1. RTP Header Extension for Source FEC Payload ID . . . . . 3 58 2.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 3 59 2.3. New RTP Header Extension URI's . . . . . . . . . . . . . 3 60 3. Multi-sequenced Flows without Source FEC Payload ID . . . . . 3 61 3.1. Source FEC Payload ID . . . . . . . . . . . . . . . . . . 4 62 3.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 4 63 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. Source Symbol Contruction . . . . . . . . . . . . . . 5 65 3.3.2. Derivations of Source FEC Packet Identification 66 Information . . . . . . . . . . . . . . . . . . . . . 5 67 3.3.3. Procedures for RTP Source Flows . . . . . . . . . . . 6 68 4. Registration of the 'bundled/raptorfec' Media Type . . . . . 6 69 5. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.1. With RTP Extensions . . . . . . . . . . . . . . . . . . . 7 71 5.2. Without RTP Extensions . . . . . . . . . . . . . . . . . 7 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 [RFC6681] provides the specification of the fully formed Forward 79 Error Correction (FEC) scheme for Raptor/RaptorQ codes in the context 80 of the FEC Framework (FEC Frame - see [RFC6363]). This document 81 provides extensions that allow for protection of multiple RTP flows 82 where each flow has its own unique sequence number space. There are 83 two approaches described: one using explicit source FEC payload ID's, 84 and one that does not. 86 2. Multi-sequenced Flows with Explicit Source FEC Payload ID 88 As per Section 6 of [RFC6681], arbitrary flows (including RTP flows) 89 can be protected if the source is identified explicitly using a 90 Source FEC Payload ID. However, the Source FEC Payload ID must be 91 sent along with the source payload to the receiver. 93 2.1. RTP Header Extension for Source FEC Payload ID 95 It is recommended that the Source FEC Payload ID as defined in 96 Section 6.2.2 of [RFC6681] be used in an RTP header extension for 97 each RTP source stream packet. Since the Source FEC Payload ID is 32 98 bits long (4 bytes), the 1-byte header extension solution in 99 Section 4.2 of [RFC5285] is sufficient for identifying the Source FEC 100 Payload ID. Note however that there may be reasons to use the 2-byte 101 header extension solution provided in Section 4.3 of [RFC5285] (e.g. 102 due to the need for 8-bit extension ID encoding). 104 2.2. Repair FEC Payload ID 106 The Repair FEC Payload ID is used as defined in Section 6.2.3 of 107 [RFC6681]. This will be sent along with the associated repair 108 payload in a repair FEC stream (i.e. RTP flow). This can also be 109 sent as a RTP header extension (although it can be included in the 110 RTP payload of the repair FEC stream). As with the Source FEC 111 Payload ID, the 1-byte header extension method is preferred. 113 2.3. New RTP Header Extension URI's 115 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 116 document.] 118 This document defines two new extension URI's in the RTP Compact 119 Header Extensions subregistry of the Real-Time Transport Protocol 120 (RTP) Parameters registry, according to the following data: 122 Extension URI: urn:ietf:params:rtp-hdrext:FEC-FR:SourceID 123 Description: Source FEC Payload ID 124 Contact: mandyam@quicinc.com 125 Reference: RFCXXXX 127 Extension URI: urn:ietf:params:rtp-hdrext:FEC-FR:RepairID 128 Description: Repair FEC Payload ID 129 Contact: mandyam@quicinc.com 130 Reference: RFCXXXX 132 3. Multi-sequenced Flows without Source FEC Payload ID 134 Section 8 of [RFC6681] describes the necessary procedures for single- 135 sequenced flows. This section extends this method for multi- 136 sequenced flows, in particular multiple RTP flows corresponding to 137 different SSRC's. The FEC Scheme ID's used are 5 and 6. 139 3.1. Source FEC Payload ID 141 As with the approach provided in [RFC6681] for single-sequenced 142 flows, a source FEC Payload ID is not used as the source packets are 143 not modified. 145 3.2. Repair FEC Payload ID 147 In contrast to Section 8.1.3 of [RFC6681], only one format for the 148 Repair FEC Payload is provided (based on Format A), but with 149 necessary extensions for multi-sequenced flows. The number of flows 150 in a repair packet and the order in which the flows appear in the 151 repair packet are determined using out-of-band signalling (for an SDP 152 example, see Section 5.2). 154 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Initial Sequence Number | Source Sub-Block Length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Initial Sequence Number | Source Sub-Block Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | ... | Encoding Symbol ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Repair FEC Payload ID (multisequence) 166 Figure 1 168 Initial Sequence Number (Flow i ISN), (16 bits): This field 169 specifies the lowest 16 bits of the sequence number of the 170 first packet to be included in this sub-block. If the sequence 171 numbers are shorter than 16 bits, then the received Sequence 172 Number SHALL be logically padded with zero bits to become 16 173 bits in length, respectively. The field type is unsigned 174 integer. 176 Source Sub-Block Length (SSBL), (16 bits): This field specifies the 177 length of the source sub-block in symbols. The field type is 178 unsigned integer. 180 Encoding Symbol ID (ESI), (16 bits): This field indicates which 181 repair symbols are contained within this repair packet. The 182 ESI provided is the ESI of the first repair symbol in the 183 packet. The field type is unsigned integer. 185 3.3. Procedures 187 There are slight changes necessary to the procedures outlined in 188 Section 8.2 of [RFC6681] in order to accomodate multiple sequenced 189 flows. 191 3.3.1. Source Symbol Contruction 193 FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5 194 of [RFC6681] to construct a set of source symbols to which the FEC 195 code can be applied. 197 During the construction of the source block: 199 o the flow identifier, f[i], for each flow included in the source 200 packet information. 202 o the length indication, l[i], included in the Source Packet 203 Information for each packet shall be dependent on the protocol 204 carried within the transport payload. Rules for RTP are specified 205 below. 207 o the value of s[i] in the construction of the Source Packet 208 Information for each packet shall be the smallest integer such 209 that s[i]*T >= (l[i]+3). 211 3.3.2. Derivations of Source FEC Packet Identification Information 213 The Source FEC Packet Identification Information for a source packet 214 is derived from the flows in each packet, sequence number of each 215 individual flow of the packet, and information received in any repair 216 FEC packet belonging to this source block. The application data 217 units (ADU's) that constitute the source block are identified by the 218 associated flow identifier and sequence number of the first source 219 packet in the block. This information is signaled in all repair FEC 220 packets associated with the source block in the Initial Sequence 221 Number field. 223 The length of the Source Packet Information (in octets) for source 224 packets within a source block is equal to the length of the payload 225 containing encoding symbols of the repair packets (i.e., not 226 including the Repair FEC Payload ID) for that block, which MUST be 227 the same for all repair packets. The Application Data Unit 228 Information Length (ADUIL) in symbols is equal to this length divided 229 by the encoding symbol size (which is signaled in the FEC Framework 230 Configuration Information). The set of source packets included in 231 the source block is determined by the Initial Sequence Number (ISN) 232 and Source Sub-Block Length (SSBL) as follows: 234 Let, 236 o f be the index of the flow, i.e. if f refers to the first flow in 237 the source block then f=1. 239 o I(f) be the Initial Sequence Number of the source sub-block from 240 flow f 242 o LP(f) be the Source Sub-Block Information Length in symbols for 243 flow f 245 o LB(f) be the Source Sub-Block Length in symbols for flow f 247 Then, source packets with sequence numbers from I(f) to I(f) 248 +(LB(f)/LP(f))-1 for flow f inclusive are included in the source 249 block. The Source Sub-Block Length, LB(f), MUST be chosen such that 250 it is at least as large as the largest Source Packet Information 251 Length LP(f). 253 Note that if no FEC repair packets are received, then no FEC decoding 254 is possible, and it is unnecessary for the receiver to identify the 255 Source FEC Packet Identification Information for the source packets. 257 For FEC Scheme 1, the ESI value placed into a repair packet is 258 calculated as specified in Section 5.3.2 of [RFC5053]. 260 For FEC Scheme 2, the ESI value placed into a repair packet is 261 calculated as specified in Section 4.4.2 of [RFC6330]. 263 In both cases, K is identical to the sum of all the SSBL's indicated 264 in the repair packet. 266 3.3.3. Procedures for RTP Source Flows 268 In the specific case of RTP source packet flows, the RTP Sequence 269 Number field SHALL be used as the sequence number in the procedures 270 described above. The length indication included in the Application 271 Data Unit Information SHALL be the sum over all flows of the RTP 272 payload length plus the length of the contributing sources (CSRCs), 273 if any, the RTP Header Extension, if present, and the RTP padding 274 octets, if any. Note that this length is always equal to the UDP 275 payload length of the packet minus 12. 277 4. Registration of the 'bundled/raptorfec' Media Type 279 This RTP payload format is identified using the 'bundled/raptorfec' 280 media type that is registered in accordance with [RFC4855] and uses 281 the template of [RFC4288]. The Media Type Definition is identical to 282 'video/raptorfec' and can be found in Section 6.2.1 of [RFC6682]. 284 5. SDP Example 286 5.1. With RTP Extensions 288 An SDP example employing bundled protection of a video and audio 289 stream (derived from Section 10 of [RFC6681]) is shown below. In 290 this example, the SDP guidance provided in Section 5 of [RFC5285] is 291 also used. 293 v=0 294 o=ali 1122334455 1122334466 IN IP4 fec.example.com 295 s=Raptor FEC Example 296 t=0 0 297 a=group:FEC-FR S1 S2 R1 298 m=video 30000 RTP/AVP 100 299 c=IN IP4 233.252.0.1/127 300 a=rtpmap:100 MP2T/90000 301 a=fec-source-flow: id=0 302 a=mid:S1 303 a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID 304 m=audio 10000 RTP/AVP 0 8 97 305 c=IN IP4 233.252.0.2/127 306 b=AS:200 307 a=rtpmap:0 PCMU/8000 308 a=mid:S2 309 a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID 310 a=fec-source-flow: id=1 311 m=application 30000 UDP/FEC 312 c=IN IP4 233.252.0.3/127 313 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 314 a=repair-window:200ms 315 a=mid:R1 316 a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:RepairID 318 5.2. Without RTP Extensions 320 An SDP example employing bundled protection of a video and audio 321 stream (derived from Section 10 of [RFC6681]) is shown below. In 322 this example, source flows (S1 and S2) identified in the 'a=group' 323 attirbute appear in this order in the Repair FEC Payload ID (see 324 Figure 1). 326 v=0 327 o=ali 1122334455 1122334466 IN IP4 fec.example.com 328 s=Raptor FEC Example 329 t=0 0 330 a=group:FEC-FR S1 S2 R1 331 m=video 30000 RTP/AVP 100 332 c=IN IP4 233.252.0.1/127 333 a=rtpmap:100 MP2T/90000 334 a=fec-source-flow: id=0 335 a=mid:S1 336 m=audio 10000 RTP/AVP 0 8 97 337 c=IN IP4 233.252.0.2/127 338 b=AS:200 339 a=rtpmap:0 PCMU/8000 340 a=mid:S2 341 a=fec-source-flow: id=1 342 m=application 30000 UDP/FEC 343 c=IN IP4 233.252.0.3/127 344 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 345 a=repair-window:200ms 346 a=mid:R1 348 6. IANA Considerations 350 This memo includes no request to IANA. 352 7. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 358 Registration Procedures", RFC 4288, December 2005. 360 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 361 Formats", RFC 4855, February 2007. 363 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 364 Correction (FEC) Building Block", RFC 5052, August 2007. 366 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 367 "Raptor Forward Error Correction Scheme for Object 368 Delivery", RFC 5053, October 2007. 370 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 371 Header Extensions", RFC 5285, July 2008. 373 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 374 and L. Minder, "RaptorQ Forward Error Correction Scheme 375 for Object Delivery", RFC 6330, August 2011. 377 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 378 Correction (FEC) Framework", RFC 6363, October 2011. 380 [RFC6364] Begen, A., "Session Description Protocol Elements for the 381 Forward Error Correction (FEC) Framework", RFC 6364, 382 October 2011. 384 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 385 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 386 August 2012. 388 [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload 389 Format for Raptor Forward Error Correction (FEC)", RFC 390 6682, August 2012. 392 Authors' Addresses 394 Giridhar Mandyam 395 Qualcomm Innovation Center 396 5775 Morehouse Drive 397 San Diego, California 92121 398 USA 400 Phone: +1 858 651 7200 401 Email: mandyam@quicinc.com 403 Mike Luby 404 Qualcomm Technologies Inc. 405 2030 Addison Street 406 Berkeley, California 94704 407 USA 409 Phone: +1 510 725 3502 410 Email: luby@qti.qualcomm.com 411 Thomas Stockhammer 412 Qualcomm CDMA Technologies GMBH 413 Franziskanerstrasse 14 414 Munich 81669 415 Germany 417 Phone: +49 86190959757 418 Email: tsto@qti.qualcomm.com