FEC Framework O. Peck Internet-Draft RADVISION Intended status: Standards Track October 17, 2009 Expires: April 20, 2010 RTP Payload Format for Multi-Flow FEC draft-peck-fecframe-rtp-mf-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a new RTP payload format for the Forward Error Correction (FEC) that is used to protect multiple source flows. The format defined by this document enables the protection of multiple Peck Expires April 20, 2010 [Page 1] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 media sources encapsulated in RTP with one or more repair flows and is based on the FEC framework (described in [I-D.ietf-fecframe- framework]) and the SDP Elements for FEC Framework (described in [I-D.ietf-fecframe-sdp-elements]). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 3 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Source Correlation . . . . . . . . . . . . . . . . . . . . . . 4 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 5 5.2.1. RTP header format . . . . . . . . . . . . . . . . . . 6 5.2.2. FEC-MF header format . . . . . . . . . . . . . . . . . 7 5.2.3. FEC Headers Format . . . . . . . . . . . . . . . . . . 8 5.2.4. Repair Data Format . . . . . . . . . . . . . . . . . . 8 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 9 6.1. Registration of application/mf-fec . . . . . . . . . . . . 9 7. Mapping of SDP Parameters . . . . . . . . . . . . . . . . . . 10 8. FEC Packet Example . . . . . . . . . . . . . . . . . . . . . . 10 8.1. MF-FEC Header Example . . . . . . . . . . . . . . . . . . 11 8.2. FEC Headers Example . . . . . . . . . . . . . . . . . . . 12 8.3. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 12 9. Offer/Answer considerations . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Peck Expires April 20, 2010 [Page 2] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 1. Introduction This document defines a new RTP payload format for the Forward Error Correction (FEC) protecting multiple source flows. [I-D.ietf-fecframe-framework] allows multiple source flows to be protected by the same FEC repair flow. Multiple source flows are transmitted either as Multi-Session or as Multi-source (see definition below). The format defined by this document enables the protection of multiple media source flows (Multi-Session or Multi-Source transmission) with one or more repair flows without adding additional information to the source packets. The method described in this document is generic to all FEC schemes. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definitions, Notations and Abbreviations This document uses the following definitions and notations. For further definitions that apply to FEC Framework in general, see [I-D.ietf-fecframe-framework]. 3.1. Definitions FEC: Forward Error Correction. Source Flow: The packet flow to which FEC protection is to be applied. Repair Flow: The packet flow carrying FEC data. Source Block: The group of source data packets which are to be FEC protected as a single block. Source Packets: Packets that are transmitted over a source flow Repair/FEC Packets: Packets that are transmitted over a repair flow Peck Expires April 20, 2010 [Page 3] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 FEC header: A FEC-scheme specific header as defined by different I-Ds, usually follows the RTP header. FEC-MF header: The FEC Multi-flow header. Contains information about the different source-flows and their order in the FEC block. multi-session transmission: In multi-session transmission, media data from a single media source is split over multiple RTP sessions. The term "layered multicast" is equivalent to multi-session transmission for sessions using multicast addresses. multi-source transmission: In multi-source transmission, data from a single media source is sent as several RTP streams in the same RTP session. The sources contained in an RTP session are identified by their synchronization source identifiers (SSRCs) or, if combined by a RTP mixer, by their contributing source identifiers (CSRCs), as defined in RTP [RFC3550]. Source Correlation: The logical association of RTP streams transferred as multiple separate sessions or as multiple sources in the same session to one layered media. 3.2. Notations 4. Source Correlation When a FEC packet protects multiple source-flows (multi-session or multi-source transmission), the receiver must correlate between a received FEC packet and the RTP source-packets protected by it. For correlating between FEC packets and source flow packets sent as multi-sessions, this draft uses the 'fec-source-flow' (see section 6.2) parameter sent in SDP as defined in SDP Elements for FEC Framework. The list of different 'fec-source-flow' identifiers are used in a newly defined FEC-MF-Header. For correlating FEC packets and source flows sent as multi-source, the 'fec-source-flow' parameter is used as well. However, as stated in RFC 3550 (section 5.2) 'multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions'. When different SSRCs are used on the same RTP session, the encoder is receiving RTP packets that use multiple sequence-number spaces. Since a FEC encoder is not always aware of other source-flows transmitted on the same RTP session in multicast transmission, the SSRC should be used for source correlation in order to uniquely identify the protected source-flow. Peck Expires April 20, 2010 [Page 4] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 The coupling of the fec-source-flow and the source flow SSRC identifier creates a unique identifier for a source-flow, and therefore enables the FEC decoding procedure for multiple source flows. 5. Packet Formats This section defines the formats of the source and repair packets 5.1. Source Packets The FEC Framework requires that source packets will contain information identifying the source block and the position within the source block occupied by the packet. However, in order to maintain backwards compatibility, this document enables the receiver to get this information without appending additional information to the source packet. Specifically this information is obtained using the combination of sequence number and SSRC identifier found in the RTP header, and information provided in the FEC header and FEC-MF header of each repair packet. Such behavior enables both non-FEC-capable and FEC-capable receivers to receive and interpret the same source packets sent in a multicast session. 5.2. Repair Packets The FEC repair packets contain information that enables the receiver to reconstruct the source block in the remote end. This is done by using the RTP header of the repair packets as well as other headers placed within the RTP payload. The additional headers, referred to as the FEC headers as shown in Figure 1 from the [FECFRAME-FRAMEWORK] (section 6.4.1), are the FEC-MF header and the additional FEC headers for each source-flow, as shown in Figure 2. The FEC repair packets MUST be sent in a separate RTP session from the protected source-flows. Peck Expires April 20, 2010 [Page 5] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 +------------------------------+ | IP Header | +------------------------------+ | Transport Header | +------------------------------+ | RTP Header | +------------------------------+ --_ | FEC Headers | \ +------------------------------+ > RTP Payload | Repair Data | _/ +------------------------------+ -- Figure 1: Format of repair packets +------------------------------+ | RTP Header | +------------------------------+ --_ | FEC-MF Header | \ +------------------------------+ \ | FEC Headers | \ | .... | > RTP Payload +------------------------------+ / | Repair Data | _/ +------------------------------+ -- Figure 2: Format of the FEC Headers 5.2.1. RTP header format The RTP header is formatted according to [RFC3550] with some further clarifications listed below: o Marker (M) Bit: For this payload type, the Marker Bit is used for indicating if SSRC identifiers are appended in the FEC-MF header. If set to 0, no SSRC identifiers are sent in the FEC-MF header. o Payload Type: The (dynamic) payload type for the repair packets is determined through out-of-band means. Note that this document registers new payload formats for the repair packets (Refer to Section 6 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides for backward compatibility. The FEC mechanisms can then be used in a multicast group with mixed FEC-capable and non-FEC- capable receivers. If a non-FEC-capable receiver receives a Peck Expires April 20, 2010 [Page 6] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 repair packet, it will not recognize the payload type, and hence, will discard the repair packet. o Sequence Number (SN): The sequence number maintains the standard definition. It is one higher than the sequence number in the previously transmitted repair packet. The initial value of the sequence number is random (unpredictable) [RFC3550]. o Timestamp (TS): The timestamp is set to a time corresponding to the repair packet's transmission time. Note that the timestamp value has no use in the actual FEC protection process and is usually useful for jitter calculations. o Synchronization Source (SSRC): The SSRC value is randomly assigned as suggested by [RFC3550]. 5.2.2. FEC-MF header format The FEC-MF header includes information that enables the receiver to correlate a received FEC packet with the protected source-flows. The FEC-MF header includes a list of source-flow identifiers (FID list), and a list of SSRC identifiers (SSRC list) for uniquely identifying the protected source flows. The SSRC list is appended to the FEC-MF header if the Marker Bit in the RTP header is set to 1. Specific FEC-scheme information for every source-flow is provided by the FEC headers appended to the MF-FEC header. The FEC headers are ordered by the FID in the FID list. The order of the FIDs (and the matching FEC headers) should be the same as the order of the source flows as they were arranged in the FEC source block before encoding. This is required to ensure the correct construction of the FEC block in the decoding process. The format of the FEC-MF header is shown in figure 3. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Flows | FID | FID | FID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | FID | padding | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC identifiers | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peck Expires April 20, 2010 [Page 7] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 Figure 3: FEC-MF (Multi-Flow) Header Format The FEC-MF header consists of the following general fields: o Num Flows - The number of source flows protected by this FEC packet. o FID - Source flow Identifier. The FEC-MF includes a list of FID identifying each source flow. The FID value is as specified in the id parameter in the "fec-source-flow" field in SDP. See example in section 6.3.3. The number of FID fields is 'Num Flows' which represents the FID list size . The FEC-MF header will be padded with zeros to 4-bytes alignment, if needed, after the last FID field (calculation for number of padded bytes is: 4-((2+Num Flows)%4)). Each FID is correlated with a FEC header appended to the FEC-MF header by the order of the FID in the FID list. The number of appended FEC headers MUST equal the value of 'Num Flows'. o SSRC identifiers - list of SSRC identifiers (optional). If Marker Bit in RTP header is 0, the list length is 0. If set to 1, the list is at the length of Num Flows. Each SSRC is taken from the protected source-flow SSRC field in the RTP header, and is represented by 4 bytes. Editor's Note: in order to avoid sending unnecessary SSRC identifiers, it should be defined when the SSRC is redundant information. SSRC is redundant when Multi-Source is not used, or when there is only one sender for the RTP session. In this case the 'fec-source-flow' is a unique idetifier for a source flow. 5.2.3. FEC Headers Format The FEC-MF header is followed by a list of FEC headers, according to the FEC scheme signalled by SDP (See Section 6). Each FEC header in the list represents the matching source-flow in the FID list by order. 5.2.4. Repair Data Format The repair data is added after the last FEC header in the RTP repair packet. It includes the result of FEC scheme code over the source block constructed from the different source-flows. The repair data format is defined by the FEC scheme used for this repair packet as signalled by SDP. Peck Expires April 20, 2010 [Page 8] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 6. Payload Format Parameters According to the FEC framework, when RTP is used as a transport for repair packet flows, the scheme must define an RTP Payload Format for the repair data. This section provides the media subtype registration for the Multi-Flow FEC. The parameters that are required to configure the FEC encoding and decoding operations are also defined in this section. 6.1. Registration of application/mf-fec Type name: application Subtype name: mf-fec Required parameters: o FEC-scheme - the FEC scheme used for encoding. The value used here should be the FEC payload type as it was registered in the relevant RFC/draft. Optional parameters: None. Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288] Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework] Interoperability considerations: None. Published specification: TBD Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data for multiple source media flows. Additional information: None. Magic number(s): none defined File extension(s): none defined Macintosh file type code(s): none defined Person & email address to contact for further information: Orly Peck, orlyp@radvision.com Peck Expires April 20, 2010 [Page 9] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. 7. Mapping of SDP Parameters For a proper operation details of the FEC operation have to be communicated between the sender and the receiver. The receiver must be notified that the FEC operation was used for multiple source flows. Specifically, the receiver has to know the FEC scheme that was used by the sender to encode the source flows. In addition, different FEC scheme-specific parameters should be communicated. One way to provide this information is to use the Session Description Protocol (SDP) [RFC4566]. The mapping of the media type specification for "mf-fec" and their parameters in SDP is as follows: o The media type (e.g., "application") goes into the "m=" line as the media name. o The media subtype ("mf-fec") goes into the "a=rtpmap" line as the encoding name. o The 'FEC-scheme' goes into the "a=rtpmap" line as the encoding parameters. o Additional scheme-specific parameters go into the "a=fmtp" line as a semicolon-separated list of parameter=value pairs. o The "group" and "fec-source-flow" attributes should be used according to [I-D.ietf-fecframe-sdp-elements]. See section 9 for SDP examples. 8. FEC Packet Example This section demonstrates the structure and data in a FEC packet protecting multiple source flows. In this example, the following FEC packet is the result of Reed- Solomon encoding for 3 different source flows. Two of the source flows (1 and 2) share the same RTP session and same payload type, and are differentiated by different SSRC identifiers (Multi-Source Peck Expires April 20, 2010 [Page 10] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 Transmission). The other source flow (3) is transmitted through a different RTP session but share the same SSRC identifier as the one used by source-flow 2 (Mutliple-Session Transmission). The FEC payload represents the Reed-Solomon scheme over RTP as defined in draft-galanos-fecframe-rtp-reedsolomon-00. This draft is general for all FEC schemes transmitted through RTP, and the use of Reed-Solomon is only for illustration purposes. The source-flows protected by this FEC packet are defined as follows: o source-flow-1: identified as fec-source-flow: id=0 in SDP, with SSRC=10. o source-flow-2: identified as fec-source-flow: id=0 in SDP, with SSRC=11. o source-flow-3: identified as fec-source-flow: id=1 in SDP, with SSRC=11. 8.1. MF-FEC Header Example 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | num FID=3 | FID=0 | FID=0 | FID=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: FEC-MF Header Example Peck Expires April 20, 2010 [Page 11] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 8.2. FEC Headers Example 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | N-K | i | SN Base=1000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Packets=5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | N-K | i | SN Base=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Packets=6 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | N-K | i | SN Base=500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Packets=6 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: FEC Headers Example 8.3. SDP Example The following example demonstrates the SDP for the above FEC packet example. v=0 o=orly 1122334455 1122334466 IN IP4 fec.example.com s= MF FEC Example t=0 0 a=group:FEC S1 S2 R1 m=video 30000 RTP/AVP 100 c=IN IP4 224.1.1.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0 a=mid:S1 m=video 30000 RTP/AVP 100 c=IN IP4 224.1.1.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=1 a=mid:S2 m=application 30000 RTP/AVP 110 c=IN IP4 224.1.2.1/127 a=rtpmap:110 fec-mf/90000/reed-solomon-fec a=fmtp:110 max_N:5; repair-window:200000; symbol-size:8 a=mid:R1 Peck Expires April 20, 2010 [Page 12] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 Figure 6 9. Offer/Answer considerations TBD 10. Security Considerations TBD 11. IANA Considerations New media subtypes are subject to IANA registration. For the registration of the payload formats and their parameters introduced in this document, refer to Section 7. 12. Acknowledgments Some parts of this document are borrowed from the following documents: [RFC5109], [draft-ietf-fecframe-1d2d-parity-scheme-01], [draft-galanos-fecframe-rtp-reedsolomon-mf-00]. The author would like to thank the editors of these documents. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. Peck Expires April 20, 2010 [Page 13] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006. 13.2. Informative References [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007. [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, April 2009. [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-05 (work in progress), July 2009. [I-D.ietf-fecframe-sdp-elements] Begen, A., "SDP Elements for FEC Framework", draft-ietf-fecframe-sdp-elements-04 (work in progress), August 2009. [I-D.galanos-fecframe-rtp-reedsolomon-mf] Galanos, S., "RTP Payload Format for Reed Solomon FEC of Multiple Flows", draft-galanos-fecframe-rtp-reedsolomon-mf-00 (work in progress), July 2009. [I-D.galanos-fecframe-rtp-reedsolomon] Galanos, S. and O. Peck, "RTP Payload Format for Reed Solomon FEC", draft-galanos-fecframe-rtp-reedsolomon-00 (work in progress), October 2009. [I-D.ietf-fecframe-pseudo-cdp] Kozat, U. and A. Begen, "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", draft-ietf-fecframe-pseudo-cdp-01 (work in progress), March 2009. [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007. Peck Expires April 20, 2010 [Page 14] Internet-Draft RTP Payload Format for Multi-Flow FEC October 2009 Author's Address Orly Peck RADVISION 24 Raul Wallenberg St. Tel Aviv 69719 Israel Email: orlyp@radvision.com Peck Expires April 20, 2010 [Page 15]