FEC Framework S. Galanos Internet-Draft RADVISION Intended status: Standards Track July 1, 2009 Expires: January 2, 2010 RTP Payload Format for Reed Solomon FEC of Multiple Flows draft-galanos-fecframe-rtp-reedsolomon-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 January 2, 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 uses Reed-Solomon codes. The format defined by this document enables the protection of multiple source flows with Galanos Expires January 2, 2010 [Page 1] Internet-Draft RTP Payload Format for RS FEC July 2009 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]). The Reed- Solomon codes used in this document belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against random and bursty packet losses. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 3 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Reed Solomon Codes . . . . . . . . . . . . . . . . . . . . . . 4 5. Source Block Creation . . . . . . . . . . . . . . . . . . . . 4 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 7 6.2.1. RTP header format . . . . . . . . . . . . . . . . . . 7 6.2.2. FEC header format . . . . . . . . . . . . . . . . . . 8 6.2.3. Repair Data Format . . . . . . . . . . . . . . . . . . 9 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 9 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 9 7.1.1. Registration of audio/reed-solomon-mf-fec . . . . . . 9 7.1.2. Registration of video/reed-solomon-mf-fec . . . . . . 10 7.1.3. Registration of text/reed-solomon-mf-fec . . . . . . . 11 7.1.4. Registration of application/reed-solomon-mf-fec . . . 13 7.2. Mapping of SDP Parameters . . . . . . . . . . . . . . . . 14 8. Protection and Recovery Procedures . . . . . . . . . . . . . . 14 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Repair Packet Construction . . . . . . . . . . . . . . . . 14 8.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 15 8.3.1. Associating the Source and Repair Packets . . . . . . 15 8.3.2. Recovering the source packet . . . . . . . . . . . . . 16 9. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Offer/Answer considerations . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Galanos Expires January 2, 2010 [Page 2] Internet-Draft RTP Payload Format for RS FEC July 2009 1. Introduction This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the Reed-Solomon code calculated over multiple RTP flows. By nature, Real-time applications are extremely sensitive to delay and require very low latency. As a result, retransmission of lost packets or using other closed-loop schemes are not valid options and the use of Forward Error Correction (FEC) is an effective approach. A primary requirement from FEC for real time applications is the ability to perfectly recover from both random and bursty packet losses. The Reed-Solomon FEC codes used in this document belong to the class of Maximum Distance Separable (MDS) codes that are optimal in terms of erasure recovery capability for both situations. The format defined by this document enables the protection of multiple source flows with one or more repair flows without adding additional information to the source packets. Such behavior reduces the delay presented by any FEC scheme and maintains backwards compatibility with non-FEC enabled receivers. Number of previous drafts were composed to draw different FEC schemes suitable for different applications. The scheme defined in this draft is designed to compensate a burst of packet loss over RTP networks with minimum delay, which is needed in interactive IP-based applications such as video conferencing. The Read-Solomon codes used in this document have already been specified by Luigi Rizzo (see [Rizzo97]). The document is compliant with the Forward Error Correction (FEC) Framework (described in [I-D.ietf-fecframe-framework]) and SDP Elements for FEC Framework (described in [I-D.ietf-fecframe-sdp-elements]). 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]. Galanos Expires January 2, 2010 [Page 3] Internet-Draft RTP Payload Format for RS FEC July 2009 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 FEC header: The header information contained in an FEC packet 3.2. Notations K: The number of packets in a source block N-K: The number of repair FEC packets generated from a single source block L: Source packet size 4. Reed Solomon Codes The detailed operation and theory behind Reed Solomon codes is out of the scope of this document. In general a Reed Solomon code takes a group of K data blocks and generates N - K FEC block. A receiver needs to receive any K of the N data or FEC blocks in order to recover the remaining N-K data block. The algorithm operates over multiple symbols each taken from a single data block. The symbol size can be different in different implementations. Any symbol size can be used in the format offered by this document. However, it is recommended for simplicity to use symbol size of 8 bits (byte). For more information of Reed Solomon codes, the reader is referred to [Rizzo97]. 5. Source Block Creation Using this framework the application can protect multiple RTP source flows using one or more FEC repair flows. Therefore, the source block contains RTP packets taken from different flows (See Figure 1). Galanos Expires January 2, 2010 [Page 4] Internet-Draft RTP Payload Format for RS FEC July 2009 Moreover, a single source block MAY contain different number of packets from the different flows. +------------+ s_1 --------> | | . Source | Source | +--------+ +--------+ +--------+ . Flows | Block |=> ..|SB_(j+1)| | SB_j | |SB_(j-1)| s_n --------> | Generation | +--------+ +--------+ +--------+ +------------+ Figure 1: Source Block generation A source block for the Reed-Solomon code contains K data blocks. In the scheme presented by this document, each data block contains a single RTP packet and therefore a source block contains exactly K RTP packets. The Reed-Solomon codes generates N-K repair blocks that are transmitted using N-K repair packets. Each repair packet contains a single repair block. Such behavior is most suitable for packet- switched networks where errors are on packet boundaries To create a source block the steps outlined below should be followed. 1. For each packet protected in this source block create a byte array as follows: A. In the first two bytes place the unsigned network-ordered 16- bit representation of the RTP packet size (including RTP header +and payload) B. Append the entire RTP packet including its RTP header C. Add padding (bytes containing binary zeroes) so that the byte array is in the size of the largest packet protected by this source block including the two bytes from section a. (The largest packet does not contain zero padding). 2. Append all the byte arrays one after the other in the following way: A. Packets from the same flow are consecutive in the source block. B. The packets of the same flow are in an increasing order of the sequence number as it appears in the RTP packet header taking wraparound into account Galanos Expires January 2, 2010 [Page 5] Internet-Draft RTP Payload Format for RS FEC July 2009 C. The sequence number of packets belonging to the same flow must be consecutive in a single source block. Figure 2 demonstrates how a source block is created from packets taken from different flows. In this example three flows marked with FID1, FID2 and FID3. The source block is constructed from one packet (P1) taken from FID1, one packet (P2) taken from FID2 and two packets (P3, P4) taken from FID3. The largest packet protected in this source block has the size of 5 (L=5) and therefore P1 and P3 are both padded with zeros to this size. The source block contains the RTP packet size before each packet. (Note that this example is not a binary representation of the source block. The Packet size spans over two bytes as stated above) FID1 P1 FID2 P2 FID3 P3 FID3 P4 L=3 L=5 L=4 L=5 +---+ +-----+ +----+ +-----+ |xxx| |xxxxx| |xxxx| |xxxxx| +---+ +-----+ +----+ +-----+ |--- Source Block (K=4)-----| +------+------+------+------+ |3xxx00|5xxxxx|4xxxx0|5xxxxx| +------+------+------+------+ Figure 2: Structure of a Source Block The FEC Reed-Solomon Scheme gets a source block created from K packets and generates N-K FEC repair packets that protect the entire source block. These packets are then transmitted in the repair flow. Padding is done only for FEC packet calculation and the original payloads are transmitted without extra padding. 6. Packet Formats This section defines the formats of the source and repair packets 6.1. Source Packets The FEC Framework requires that source packets contain information identifying the source block and the position within the source block occupied by the packet. However, in order to maintain backwards compatibility, the scheme defined by this document enables the receiver to get this information without appending additional Galanos Expires January 2, 2010 [Page 6] Internet-Draft RTP Payload Format for RS FEC July 2009 information to the source packet. Specifically this information is obtained using the combination of sequence number found in the RTP header and information provided in the FEC header of each repair packet. Such behavior enables both non-FEC-capable and FEC-capable receivers to receive and interpret the same source packets. 6.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 another header that is placed within the RTP payload. This header, referred to as the FEC header, is shown in Figure 3. +------------------------------+ | IP Header | +------------------------------+ | Transport Header | +------------------------------+ | RTP Header | +------------------------------+ --_ | FEC Header | \ +------------------------------+ > RTP Payload | Repair Data | _/ +------------------------------+ -- Figure 3: Format of repair packets 6.2.1. RTP header format The RTP header is formatted according to [RFC3550] with some further clarifications listed below: o Marker (M) Bit: This bit is not used for this payload type, and is set to 0. 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 5 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides 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 repair packet, it will not recognize the payload type, and hence, will discard the repair packet. Galanos Expires January 2, 2010 [Page 7] Internet-Draft RTP Payload Format for RS FEC July 2009 o Sequence Number (SN): The sequence number has 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]. 6.2.2. FEC header format The FEC header includes information that enables the receiver to reconstruct the source block and to identify the repair packets associated with each source block in their correct order. The format of the FEC header is shown in figure 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FEC Header Len | N-K | i | Num flows | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | Num Packets | SN Base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | Num Packets | SN Base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | Num Packets | SN Base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: FEC Header Format The FEC header consists of the general information fields and the per-flow fields. The FEC header consists of the following general fields: o FEC Header Len - The length of this FEC header. The FEC header does not have a fixed length and the length is varied according to the number of protected flows. o N-K - The number of FEC packets used to protect this source block Galanos Expires January 2, 2010 [Page 8] Internet-Draft RTP Payload Format for RS FEC July 2009 o i - 0 based packet index in the N-K FEC packets sequence. o Num flows - The numbers of flows protected by this FEC packet. Following the general fields, the FEC header consists of the per-flow fields that include: o FID - flow ID. the same value as specified in the "id" SDP parameter. See example in section 9. o Num Packets - The number of packets taken from this Flow. o SN Base - the sequence number of the first source packet in the source block taken from this flow. 6.2.3. Repair Data Format The repair data follows the FEC header in the RTP repair packet. It includes the result of the Reed-Solomon code over the source block. Note that the first two bytes of the repair data contain the result of the Reed-Solomon code over the packet sizes in the source block and that the size of the repair data equals the size of the largest packet protected by this source block plus 2. Therefore, the size of a FEC packet (FEC header and data) is larger than the longest source packet. 7. 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 Reed-Solomon FEC of Multiple Flows. The parameters that are required to configure the FEC encoding and decoding operations are also defined in this section. 7.1. Media Type Registration This registration is done using the template defined in [RFC4288] and following the guidance provided in [RFC3555]. 7.1.1. Registration of audio/reed-solomon-mf-fec Type name: audio Subtype name: reed-solomon-mf-fec Required parameters: Galanos Expires January 2, 2010 [Page 9] Internet-Draft RTP Payload Format for RS FEC July 2009 o max_N: The maximum number of source packets and FEC packets used to protect the K source packets. max_N is a positive integer. The application can change both K and N-K. max_N is the upper limit for N. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. 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 in addition to the source media. 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: Sarit Galanos, sarit@radvision.com 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.1.2. Registration of video/reed-solomon-mf-fec Type name: video Subtype name: reed-solomon-mf-fec Galanos Expires January 2, 2010 [Page 10] Internet-Draft RTP Payload Format for RS FEC July 2009 Required parameters: o max_N: The maximum number of source packets and FEC packets used to protect the K source packets. max_N is a positive integer. The application can change both K and N-K. max_N is the upper limit for N. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. 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 in addition to the source media. 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: Sarit Galanos, sarit@radvision.com 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.1.3. Registration of text/reed-solomon-mf-fec Type name: text Galanos Expires January 2, 2010 [Page 11] Internet-Draft RTP Payload Format for RS FEC July 2009 Subtype name: reed-solomon-mf-fec Required parameters: o max_N: The maximum number of source packets and FEC packets used to protect the K source packets. max_N is a positive integer. The application can change both K and N-K. max_N is the upper limit for N. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. 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 in addition to the source media. 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: Sarit Galanos, sarit@radvision.com 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. Galanos Expires January 2, 2010 [Page 12] Internet-Draft RTP Payload Format for RS FEC July 2009 7.1.4. Registration of application/reed-solomon-mf-fec Type name: application Subtype name: reed-solomon-mf-fec Required parameters: o max_N: The maximum number of source packets and FEC packets used to protect the K source packets. max_N is a positive integer. The application can change both K and N-K. max_N is the upper limit for N. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. 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 in addition to the source media. 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: Sarit Galanos, sarit@radvision.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport Galanos Expires January 2, 2010 [Page 13] Internet-Draft RTP Payload Format for RS FEC July 2009 within other framing protocols is not defined at this time. 7.2. Mapping of SDP Parameters For a proper operation details of the FEC scheme have to be communicated between the sender and the receiver. Specifically, the receiver has to know the relationship between the source and the repair flows, how the sender applied protection to the source flows and how the repair flows can be used to recover the lost data. One way to provide this information is to use the Session Description Protocol (SDP) [RFC4566]. The mapping of the media type specification for "reed-solomon-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 goes into the "a=rtpmap" line as the encoding name. o The remaining required payload-format-specific parameters go into the "a=fmtp" line by copying them directly from the media type string as a semicolon-separated list of parameter=value pairs. See section 9 for SDP examples. 8. Protection and Recovery Procedures This section provides a complete specification of the protection and recovery procedures. 8.1. Overview The FEC packets allow end systems to recover from the loss of media packets. The following sections specify the steps involved in generating the repair packets and reconstructing the missing source packets from the repair packets. 8.2. Repair Packet Construction The RTP header of a repair packet is formed based on the guidelines given in Section 6.2.1. The FEC header is formed based on the guidelines given in Section 6.2.2. The repair data is then appended to the FEC header. The repair data is the result of the protection operation calculated on the source block. This is the direct output of the Reed-Solomon code. Note that the repair data will span over Galanos Expires January 2, 2010 [Page 14] Internet-Draft RTP Payload Format for RS FEC July 2009 N-K packets. 8.3. Source Packet Reconstruction Recovery requires two distinct operations. The first determines which packets (media and FEC) must be combined in order to recover the missing packets. Once this is done, the second step is the reconstruction of the missing data. 8.3.1. Associating the Source and Repair Packets Association of the Source and Repair packets is done using a combination of the Source packet sequence number and the information found in the RTP header and the FEC header of the repair packets. The first step is to accumulate the N-K repair packets that were generated in the protection operation. For that the application has to follow the steps listed below: o For each received packet, retrieve the payload type parameter from the RTP header to identify the packet as a repair packet of the reed-solomon-mf scheme. o Once a repair packet has been identified, retrieve the sequence number from the RTP header and the N-K and i parameters from the FEC header. o With these three parameters, identify the collection of FEC packets generated for the source block. For example, if N-K=4, i=2 and the sequence number is 1003, it means that 4 packets with sequence numbers 1001,1002,1003 and 1004 were generated for a specific source block. The application should then use the FEC header to identify the packets that constructed the source block. For that the application has to follow the steps listed bellow: o Retrieve the Num flows parameter from the FEC header. This parameter specifies the number of rows in the per-flow information table. o For each flow retrieve the FID, Num Packets and SN base parameters. The order of packets in the source block is identified by the order of the rows in the per-flow table. Galanos Expires January 2, 2010 [Page 15] Internet-Draft RTP Payload Format for RS FEC July 2009 8.3.2. Recovering the source packet In order to recover the lost packets the application has to rebuild the source block according to the guidelines given in section 5 and append the repair data to it in the correct order. The order of the packets in the source block is specified by the order of the flow IDs in the FEC header. In place of the lost packets the application should place blocks with zero padding. The size of these blocks in bytes is the size of the repair data found in the repair packets. The repair data is the RTP payload without the FEC header information (see figure 3). The application then appends the repair data taken from each repair packet. This new block is provided to the Reed- Solomon code. The Reed-Solomon code will reconstruct the lost data into the provided source block overriding the zero padded blocks. The application can then recover the lost packets as follows: o The first two bytes include the RTP packet size. o According to the packet size the application can retrieve the entire RTP packet (RTP header and payload). o The extra padding bytes if exist are ignored. 9. SDP Examples The following example demonstrates two source flows with flow IDs of 0 and 1 that are protected by a single repair flow. Galanos Expires January 2, 2010 [Page 16] Internet-Draft RTP Payload Format for RS FEC July 2009 v=0 o=sarit 1122334455 1122334466 IN IP4 fec.example.com s= Reed Solomon FEC for multiple flows 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 101 c=IN IP4 224.1.1.2/127 a=rtpmap:101 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 reed-solomon-mf-fec /90000 a=fmtp:110 max_N:5; repair-window: 200000 a=mid:R1 Figure 5 10. Offer/Answer considerations None. 11. Security Considerations See [I-D.ietf-fecframe-framework] 12. 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 5. 13. Acknowledgments Some parts of this document are borrowed from the following documents: [RFC5109], [draft-ietf-fecframe-1d2d-parity-scheme-01], [draft-roca-fecframe-rs-00], [draft-ietf-avt-reedsolomon-00]. Thus, the author would like to thank the editors of these documents. Galanos Expires January 2, 2010 [Page 17] Internet-Draft RTP Payload Format for RS FEC July 2009 14. References 14.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. [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006. 14.2. Informative References [I-D.ietf-fecframe-1d2d-parity-scheme] Begen, A., "RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", draft-ietf-fecframe-1d2d-parity-scheme-01 (work in progress), May 2009. [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007. [I-D.ietf-avt-reedsolomon] Rosenberg, J., "An RTP Payload Format for Reed Solomon Codes", May 1999. [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", April 1997. [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, April 2009. [I-D.roca-fecframe-rs] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. Matsuzono, "Reed-Solomon Forward Error Correction (FEC) Galanos Expires January 2, 2010 [Page 18] Internet-Draft RTP Payload Format for RS FEC July 2009 Schemes for FECFRAME", draft-roca-fecframe-rs-00 (work in progress), March 2009. [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-03 (work in progress), October 2008. [I-D.ietf-fecframe-sdp-elements] Begen, A., "SDP Elements for FEC Framework", draft-ietf-fecframe-sdp-elements-03 (work in progress), June 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. [I-D.ietf-fecframe-rtp-raptor] Watson, M., "RTP Payload Format for Raptor FEC", draft-ietf-fecframe-rtp-raptor-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. Author's Address Sarit Galanos RADVISION 24 Raul Wallenberg St. Tel Aviv 69719 Israel Email: sarit@radvision.com Galanos Expires January 2, 2010 [Page 19]