Rtcweb Working Group G. Mandyam Internet-Draft Qualcomm Innovation Center Intended status: Informational M. Luby Expires: December 18, 2015 Qualcomm Technologies Inc. T. Stockhammer Qualcomm CDMA Technologies GMBH June 16, 2015 FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources draft-mandyam-rtcweb-fecframebundledssrc-00 Abstract The FEC FRAME Raptor code options do not currently address the case of bundled protection of multiple media types over multiple real-time transport protocol (RTP) synchronization sources (SSRC's). This document provides the FEC source and repair payload definitions that enable a single repair flow to be defined for multiple RTP flows Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 18, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Mandyam, et al. Expires December 18, 2015 [Page 1] Internet-Draft FECFRAME4MultipleSSRCs June 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Multi-sequenced Flows with Explicit Source FEC Payload ID . . 2 2.1. RTP Header Extension for Source FEC Payload ID . . . . . 3 2.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 3 2.3. New RTP Header Extension URI's . . . . . . . . . . . . . 3 3. Multi-sequenced Flows without Source FEC Payload ID . . . . . 3 3.1. Source FEC Payload ID . . . . . . . . . . . . . . . . . . 4 3.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 4 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Source Symbol Contruction . . . . . . . . . . . . . . 5 3.3.2. Derivations of Source FEC Packet Identification Information . . . . . . . . . . . . . . . . . . . . . 5 3.3.3. Procedures for RTP Source Flows . . . . . . . . . . . 6 4. Registration of the 'bundled/raptorfec' Media Type . . . . . 6 5. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. With RTP Extensions . . . . . . . . . . . . . . . . . . . 7 5.2. Without RTP Extensions . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction [RFC6681] provides the specification of the fully formed Forward Error Correction (FEC) scheme for Raptor/RaptorQ codes in the context of the FEC Framework (FEC Frame - see [RFC6363]). This document provides extensions that allow for protection of multiple RTP flows where each flow has its own unique sequence number space. There are two approaches described: one using explicit source FEC payload ID's, and one that does not. 2. Multi-sequenced Flows with Explicit Source FEC Payload ID As per Section 6 of [RFC6681], arbitrary flows (including RTP flows) can be protected if the source is identified explicitly using a Source FEC Payload ID. However, the Source FEC Payload ID must be sent along with the source payload to the receiver. Mandyam, et al. Expires December 18, 2015 [Page 2] Internet-Draft FECFRAME4MultipleSSRCs June 2015 2.1. RTP Header Extension for Source FEC Payload ID It is recommended that the Source FEC Payload ID as defined in Section 6.2.2 of [RFC6681] be used in an RTP header extension for each RTP source stream packet. Since the Source FEC Payload ID is 32 bits long (4 bytes), the 1-byte header extension solution in Section 4.2 of [RFC5285] is sufficient for identifying the Source FEC Payload ID. Note however that there may be reasons to use the 2-byte header extension solution provided in Section 4.3 of [RFC5285] (e.g. due to the need for 8-bit extension ID encoding). 2.2. Repair FEC Payload ID The Repair FEC Payload ID is used as defined in Section 6.2.3 of [RFC6681]. This will be sent along with the associated repair payload in a repair FEC stream (i.e. RTP flow). This can also be sent as a RTP header extension (although it can be included in the RTP payload of the repair FEC stream). As with the Source FEC Payload ID, the 1-byte header extension method is preferred. 2.3. New RTP Header Extension URI's [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document defines two new extension URI's in the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:FEC-FR:SourceID Description: Source FEC Payload ID Contact: mandyam@quicinc.com Reference: RFCXXXX Extension URI: urn:ietf:params:rtp-hdrext:FEC-FR:RepairID Description: Repair FEC Payload ID Contact: mandyam@quicinc.com Reference: RFCXXXX 3. Multi-sequenced Flows without Source FEC Payload ID Section 8 of [RFC6681] describes the necessary procedures for single- sequenced flows. This section extends this method for multi- sequenced flows, in particular multiple RTP flows corresponding to different SSRC's. The FEC Scheme ID's used are 5 and 6. Mandyam, et al. Expires December 18, 2015 [Page 3] Internet-Draft FECFRAME4MultipleSSRCs June 2015 3.1. Source FEC Payload ID As with the approach provided in [RFC6681] for single-sequenced flows, a source FEC Payload ID is not used as the source packets are not modified. 3.2. Repair FEC Payload ID In contrast to Section 8.1.3 of [RFC6681], only one format for the Repair FEC Payload is provided (based on Format A), but with necessary extensions for multi-sequenced flows. The number of flows in a repair packet and the order in which the flows appear in the repair packet are determined using out-of-band signalling (for an SDP example, see Section 5.2). 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial Sequence Number | Source Sub-Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial Sequence Number | Source Sub-Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Encoding Symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Repair FEC Payload ID (multisequence) Figure 1 Initial Sequence Number (Flow i ISN), (16 bits): This field specifies the lowest 16 bits of the sequence number of the first packet to be included in this sub-block. If the sequence numbers are shorter than 16 bits, then the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length, respectively. The field type is unsigned integer. Source Sub-Block Length (SSBL), (16 bits): This field specifies the length of the source sub-block in symbols. The field type is unsigned integer. Encoding Symbol ID (ESI), (16 bits): This field indicates which repair symbols are contained within this repair packet. The ESI provided is the ESI of the first repair symbol in the packet. The field type is unsigned integer. Mandyam, et al. Expires December 18, 2015 [Page 4] Internet-Draft FECFRAME4MultipleSSRCs June 2015 3.3. Procedures There are slight changes necessary to the procedures outlined in Section 8.2 of [RFC6681] in order to accomodate multiple sequenced flows. 3.3.1. Source Symbol Contruction FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5 of [RFC6681] to construct a set of source symbols to which the FEC code can be applied. During the construction of the source block: o the flow identifier, f[i], for each flow included in the source packet information. o the length indication, l[i], included in the Source Packet Information for each packet shall be dependent on the protocol carried within the transport payload. Rules for RTP are specified below. o the value of s[i] in the construction of the Source Packet Information for each packet shall be the smallest integer such that s[i]*T >= (l[i]+3). 3.3.2. Derivations of Source FEC Packet Identification Information The Source FEC Packet Identification Information for a source packet is derived from the flows in each packet, sequence number of each individual flow of the packet, and information received in any repair FEC packet belonging to this source block. The application data units (ADU's) that constitute the source block are identified by the associated flow identifier and sequence number of the first source packet in the block. This information is signaled in all repair FEC packets associated with the source block in the Initial Sequence Number field. The length of the Source Packet Information (in octets) for source packets within a source block is equal to the length of the payload containing encoding symbols of the repair packets (i.e., not including the Repair FEC Payload ID) for that block, which MUST be the same for all repair packets. The Application Data Unit Information Length (ADUIL) in symbols is equal to this length divided by the encoding symbol size (which is signaled in the FEC Framework Configuration Information). The set of source packets included in the source block is determined by the Initial Sequence Number (ISN) and Source Sub-Block Length (SSBL) as follows: Mandyam, et al. Expires December 18, 2015 [Page 5] Internet-Draft FECFRAME4MultipleSSRCs June 2015 Let, o f be the index of the flow, i.e. if f refers to the first flow in the source block then f=1. o I(f) be the Initial Sequence Number of the source sub-block from flow f o LP(f) be the Source Sub-Block Information Length in symbols for flow f o LB(f) be the Source Sub-Block Length in symbols for flow f Then, source packets with sequence numbers from I(f) to I(f) +(LB(f)/LP(f))-1 for flow f inclusive are included in the source block. The Source Sub-Block Length, LB(f), MUST be chosen such that it is at least as large as the largest Source Packet Information Length LP(f). Note that if no FEC repair packets are received, then no FEC decoding is possible, and it is unnecessary for the receiver to identify the Source FEC Packet Identification Information for the source packets. For FEC Scheme 1, the ESI value placed into a repair packet is calculated as specified in Section 5.3.2 of [RFC5053]. For FEC Scheme 2, the ESI value placed into a repair packet is calculated as specified in Section 4.4.2 of [RFC6330]. In both cases, K is identical to the sum of all the SSBL's indicated in the repair packet. 3.3.3. Procedures for RTP Source Flows In the specific case of RTP source packet flows, the RTP Sequence Number field SHALL be used as the sequence number in the procedures described above. The length indication included in the Application Data Unit Information SHALL be the sum over all flows of the RTP payload length plus the length of the contributing sources (CSRCs), if any, the RTP Header Extension, if present, and the RTP padding octets, if any. Note that this length is always equal to the UDP payload length of the packet minus 12. 4. Registration of the 'bundled/raptorfec' Media Type This RTP payload format is identified using the 'bundled/raptorfec' media type that is registered in accordance with [RFC4855] and uses Mandyam, et al. Expires December 18, 2015 [Page 6] Internet-Draft FECFRAME4MultipleSSRCs June 2015 the template of [RFC4288]. The Media Type Definition is identical to 'video/raptorfec' and can be found in Section 6.2.1 of [RFC6682]. 5. SDP Example 5.1. With RTP Extensions An SDP example employing bundled protection of a video and audio stream (derived from Section 10 of [RFC6681]) is shown below. In this example, the SDP guidance provided in Section 5 of [RFC5285] is also used. v=0 o=ali 1122334455 1122334466 IN IP4 fec.example.com s=Raptor FEC Example t=0 0 a=group:FEC-FR S1 S2 R1 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0 a=mid:S1 a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID m=audio 10000 RTP/AVP 0 8 97 c=IN IP4 233.252.0.2/127 b=AS:200 a=rtpmap:0 PCMU/8000 a=mid:S2 a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID a=fec-source-flow: id=1 m=application 30000 UDP/FEC c=IN IP4 233.252.0.3/127 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A a=repair-window:200ms a=mid:R1 a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:RepairID 5.2. Without RTP Extensions An SDP example employing bundled protection of a video and audio stream (derived from Section 10 of [RFC6681]) is shown below. In this example, source flows (S1 and S2) identified in the 'a=group' attirbute appear in this order in the Repair FEC Payload ID (see Figure 1). Mandyam, et al. Expires December 18, 2015 [Page 7] Internet-Draft FECFRAME4MultipleSSRCs June 2015 v=0 o=ali 1122334455 1122334466 IN IP4 fec.example.com s=Raptor FEC Example t=0 0 a=group:FEC-FR S1 S2 R1 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0 a=mid:S1 m=audio 10000 RTP/AVP 0 8 97 c=IN IP4 233.252.0.2/127 b=AS:200 a=rtpmap:0 PCMU/8000 a=mid:S2 a=fec-source-flow: id=1 m=application 30000 UDP/FEC c=IN IP4 233.252.0.3/127 a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A a=repair-window:200ms a=mid:R1 6. IANA Considerations This memo includes no request to IANA. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007. [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007. [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. Mandyam, et al. Expires December 18, 2015 [Page 8] Internet-Draft FECFRAME4MultipleSSRCs June 2015 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, August 2011. [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011. [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011. [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, August 2012. [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload Format for Raptor Forward Error Correction (FEC)", RFC 6682, August 2012. Authors' Addresses Giridhar Mandyam Qualcomm Innovation Center 5775 Morehouse Drive San Diego, California 92121 USA Phone: +1 858 651 7200 Email: mandyam@quicinc.com Mike Luby Qualcomm Technologies Inc. 2030 Addison Street Berkeley, California 94704 USA Phone: +1 510 725 3502 Email: luby@qti.qualcomm.com Mandyam, et al. Expires December 18, 2015 [Page 9] Internet-Draft FECFRAME4MultipleSSRCs June 2015 Thomas Stockhammer Qualcomm CDMA Technologies GMBH Franziskanerstrasse 14 Munich 81669 Germany Phone: +49 86190959757 Email: tsto@qti.qualcomm.com Mandyam, et al. Expires December 18, 2015 [Page 10]