FEC Framework O. Peck Internet-Draft RADVISION Intended status: Standards Track March 07, 2010 Expires: September 8, 2010 RTP Payload Format for Multi-Flow FEC draft-peck-fecframe-rtp-mf-01 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 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]). 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 September 8, 2010. Copyright Notice Copyright (c) 2010 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 Peck Expires September 8, 2010 [Page 1] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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 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 BSD License. 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 . . . . . . . . . . . . . . . . . . 9 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 9 6.1. Registration of application/mf-fec . . . . . . . . . . . . 9 7. Mapping of SDP Parameters . . . . . . . . . . . . . . . . . . 10 8. FEC Packet Example . . . . . . . . . . . . . . . . . . . . . . 11 8.1. MF-FEC Header Example . . . . . . . . . . . . . . . . . . 11 8.2. FEC Headers Example . . . . . . . . . . . . . . . . . . . 12 8.3. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 12 9. Application considerations . . . . . . . . . . . . . . . . . . 13 10. Offer/Answer considerations . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Peck Expires September 8, 2010 [Page 2] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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 September 8, 2010 [Page 3] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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 September 8, 2010 [Page 4] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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. If the FEC encoding is done in a "middle-box" that receives the different source flows to be protected, the FEC encoder should validate the fec-source-flow idnetifiers for collisions. When a collision is detected, the FEC encoder should answer with a different fec-source-flow than the one offered. The fec-source-flow MUST not be changed during the session. 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 September 8, 2010 [Page 5] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 +------------------------------+ | 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 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 repair packet, it will not recognize the payload type, and hence, will discard the repair packet. Peck Expires September 8, 2010 [Page 6] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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 optionaly, a list of SSRC identifiers (SSRC list) for uniquely identifying the protected source flows. The optional SSRC list is appended to the FEC-MF header. 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 for 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Num Flows | FID | FID | FID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | FID | padding | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC identifiers (Optional) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FEC-MF (Multi-Flow) Header Format Peck Expires September 8, 2010 [Page 7] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 The FEC-MF header consists of the following general fields: o L-Bit- A bit indicating whether the optional list of SSRC identifiers is appended to the FEC-MF header. When set to 0, no SSRC identifiers are specified (for cases where the FID is sufficient as a unique identifier). When set to 1, a list of SSRC identifiers is appended to the FEC-MF header. The length of this list is (4 bytes * Num Flows). Each 4 bytes represent the SSRC of the flow specified by the order of the FID list in the FEC-MF header. o Num Flows - The number of source flows protected by this FEC packet. Maximum number of protected source flows is 128. 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'. Since FID field is 8 bits, the "fec-source-flow" field in SDP should be between 0 and 255. This limits the number of source-flows protected by FEC to 256 flows. o SSRC identifiers - list of SSRC identifiers (optional). If the L-Bit is 0, the list length is 0. If set to 1, the list length is (4*Num Flows), where 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 fec-source-flow in the FID list by order. Peck Expires September 8, 2010 [Page 8] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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. 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. Peck Expires September 8, 2010 [Page 9] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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 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=fmtp" line, followed by a semicolon-separated list of parameter that are required for the specific used FEC-scheme. 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. Peck Expires September 8, 2010 [Page 10] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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 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-01. 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 September 8, 2010 [Page 11] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 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_r | i | SN_base=1000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BML | Num Packets=5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_r | i | SN_base=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BML | Num Packets=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_r | i | SN_base=500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BML | Num Packets=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 30002 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 a=fmtp:110 FEC-scheme=reed-solomon-fec; max_N:5; repair-window:200000; symbol-size:8 a=mid:R1 Peck Expires September 8, 2010 [Page 12] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 Figure 6 9. Application considerations Protecting multiple flows with the same repair flow might be more efficient in terms of bandwidth overhead and FEC strength. An appropriate example for bandwidth efficiency would be a 3D interactive video application (2D plus depth) where a FEC protection must be applied to a single frame only, due to latency considerations. If, for example, each frame (2D or depth) is transmitted by 4 RTP packets, the miniumum bandwidth overheader for protecting each source flow separately is 25%, with a single repair packet for each frame (one for 2D frame, and one for depth frame). By protecting both frames together (2D and depth) with the same repair flow, the bandwidth overhead can be reduced to 12.5% (A single repair packet for all 8 RTP source packets). This, ofcourse, reduces the FEC strength to the level chosen be the application. Protecting multiple source flows can increase FEC strength as described in the following example: When protecting each frame separately with a single repair packet, if two packets are lost from a the same frame, they cannot be repaired. However, if we protect both flows (8 RTP packets) with a scheme such as Reed-Solomon, with 2 repair packets (without actually increasing the bandwidth overhead), any two lost packets from both frames (total of 8 RTP packets) may be repaired. However, an example for an application that is not suitable for multiple source flows protection, would be an application that protects two flows where one of the flows is prone to high packet loss rates, and the other source flow is prone to low packet loss rates. Protecting both flows with one repair flow, will damage the rate of successful repairing of packets of the flow that is prone to low packet loss rate. 10. Offer/Answer considerations When offering multiple source flows FEC protection over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations apply: o When protecting multiple sources, the sender may suggest various FEC-schemes to be used for the FEC protection. Each FEC-scheme should be indicated as a separate offer. The receiver may choose the supported/preferred FEC-scheme to be used. Peck Expires September 8, 2010 [Page 13] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 o The specific FEC-scheme parameters can also be indicated as separated offers. For example, using the same FEC-scheme but with two differnt repair-window size parameters should be indicated in separated offers. Once the receiver decides the FEC-scheme to be used, it should choose the specific offer among the different offers for the chosen scheme based on the FEC-scheme parameters. o When a receiver does not support the fec-mf scheme, these offers MUST be ignored and deleted from the answer. The sender may add other single source flow FEC protection offers for receivers that do not support multiple source flows protection. o If multiple source flow FEC protection is not desired by the receiver, it can be deleted from the answer. 11. Security Considerations Multiple flow FEC protection is FEC-scheme independent. Any FEC scheme can be used for protection. Therefore, the security considerations for using multiple flow FEC protection are dependent on the actual used FEC-scheme, and should be taken under considerations when using it. Other security considerations are implied by using RTP for multiple flow protection: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, transport and signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, using the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may Peck Expires September 8, 2010 [Page 14] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 exist. 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 7. 13. 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. 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 [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", Peck Expires September 8, 2010 [Page 15] Internet-Draft RTP Payload Format for Multi-Flow FEC March 2010 RFC 5510, April 2009. [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-06 (work in progress), March 2010. [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. Author's Address Orly Peck RADVISION 24 Raul Wallenberg St. Tel Aviv 69719 Israel Email: orlyp@radvision.com Peck Expires September 8, 2010 [Page 16]