Network Working Group Michael Luby INTERNET-DRAFT Digital Fountain Category: Standards Track Ross Finlayson Expires: January 2005 LIVE.COM Hiroaki Nishimoto Sumitomo Electric Networks July 9, 2004 RTP Payload Format for Generic FEC-Encoded Time-Sensitive Media Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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 Abstract This document describes a RTP payload format for streams that have been encoded using Forward Error Correction (FEC), for enhanced reliability. The FEC encoding scheme is assumed to be an instantiation of the "FEC Building Block" defined in RFC 3452, and packets and parameters defined for the encoding scheme are used directly as corresponding RTP payloads and parameters. 1. Terminology 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 RFC 2119 [REQMNT]. 2. Introduction Forward Error Correction (FEC) is a technique [REPAIR] that can help a media stream recover from packet loss. Depending on the particular encoding scheme that is used, FEC often makes it possible to recover completely from significant packet loss. FEC is particularly useful for multicast streams [FECINTRO], because it - unlike other repair schemes - does not rely upon the presence of a back channel from receivers back to the sender. However, FEC is also applicable to many unicast streams, especially those for which latency or server scalability requirements make other reliability techniques - such as selective retransmission - impractical. RFC 2733 [PARITYFEC] describes a RTP [RTP] payload format for media that is encoded with a simple exclusive-or (i.e., parity) FEC scheme. Many other, considerably more powerful, FEC schemes exist, however. Since RFC 2733, the IETF has standardized a "FEC Building Block" [FECBB], which allows an arbitrary FEC scheme to be specified for use within a transport protocol. While this work was originally aimed at reliable transport of bulk data, such as files, it can also be used for packet loss protection in streaming data [FEC2], including time-sensitive data such as media streams. This document adapts the "FEC Building Block" for use within RTP. The parameters - FEC Encoding ID, FEC Instance ID, FEC Payload ID, and FEC Object Transmission Information - that define an instantiation of this building block (i.e., a particular FEC scheme), are mapped directly to RTP, as described in section 3 below. This RTP payload format is applicable for the streaming of any FEC-encoded time-sensitive media. (It is not, however, appropriate for reliable transport of entire objects, such as files. For this, a protocol such as FLUTE [FLUTE] should be used instead.) 3. RTP Payload Format Definition 3.1. RTP Payload Each RTP payload (i.e., following the standard RTP header) consists of exactly one "data packet" as defined by the FEC scheme (i.e., instantiation of the "FEC Building Block") that is being used. In particular, each RTP payload includes the data packet's "FEC Payload ID" (see [FECBB], section 3). Note that each RTP packet includes a complete FEC "data packet"; there is no RTP-level fragmentation. 3.2. RTP Header Fields Payload Type: A dynamic payload type - i.e., one in the range [96,127] - MUST be used. M bit: This payload format defines no use for this bit. Senders SHOULD set this bit to zero in each outgoing packet. Timestamp: This (32-bit) value represents an appropriate presentation time of the "source block" (see [FECINTRO]) of original source data from which this FEC "data packet" was derived. If, however, more than one FEC "data packet" (and thus, RTP packet) was derived from the same "source block", then the timestamp in each RTP packet SHOULD be pro-rated accordingly. Suppose, for example, that successive "source blocks" have presentation times t1, t2, t3, etc., and that each such "source block" generates two corresponding FEC "data packets" (and thus RTP packets). Then, the RTP timestamps for each resulting RTP packet will correspond to the presentation times: t1, (t1+t2)/2, t2, (t2+t3)/2, t3, etc. The RTP timestamp frequency should be chosen to correspond to the presentation time granularity of the original data. If no such frequency is obvious, the a RTP timestamp frequency of 90000 Hz SHOULD be used instead. 3.3. Payload Format Parameters As noted above, the "FEC Payload ID" parameter is always carried within each RTP packet. Depending on the particular FEC scheme, the other FEC parameters - the "FEC Object Transmission Information" (which includes the "FEC Encoding ID" and "FEC Instance ID", if used) - are indicated 'out of band'. If so, these parameters will also be 'out of band' parameters to the RTP payload format, as noted in the MIME type registration below. 4. IANA Considerations This RTP payload format defines a new MIME registration: MIME media type name: application MIME subtype: generic-fec Required parameters: none Optional parameters: encoding-id: The "FEC Encoding ID", as defined in the IANA registry "ietf:rmt:fec:encoding" for instantiations of the "FEC Building Block" specification (RFC 3452). instance-id: The "FEC Instance ID", as defined in the IANA registry "ietf:rmt:fec:encoding:instance" for instantiations of the "FEC Building Block" specification (RFC 3452). source-block-length: The length (in bytes) of each source block, as defined by instantiations of the "FEC Building Block" specification (RFC 3452). max-encoding-symbols: The maximum number of encoding symbols that can be generated for any source block, as defined by instantiations of the "FEC Building Block" specification (RFC 3452). Particular instantiations of the "FEC Building Block" specification may define additional parameters, as appropriate. Encoding considerations: This type is defined only for transfer via RTP as specified in . Security considerations: See the "Security Considerations" section of . Interoperability considerations: none Published specification: Applications which use this media type: Media streaming tools (transmitting and receiving) Additional information: none Person & email address to contact for further information: Michael Luby luby (at) digitalfountain.com Intended usage: COMMON Author/Change controller: Authors: Michael Luby, Ross Finlayson, Hiroaki Nishimoto Change controller: IETF AVT Working Group 5. SDP Usage Example Suppose, for example, that a (hypothetical) FEC scheme is being used that has been defined to use "FEC Encoding ID" 142, and (because it is 'under-specified' [FECBB]), "FEC Instance ID" 3. Suppose also that the "FEC Object Transmission Information" parameters include the source block length, and that the source block length is 16384 bytes. In this case, an example of the media representation in SDP [SDP] would be: m=application 49000 RTP/AVP 96 a=rtpmap:96 generic-fec/90000 a=fmtp:96 encoding-id=142; instance-id=3; source-block-length=16384 6. Security Considerations The security considerations noted in [FECINTRO] and [FECBB] are also relevant to the streaming of FEC-encoded data using RTP. 7. Normative References [FECBB] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and Crowcroft, J., "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002. [FEC2] Luby, M., Vicisano, L., "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004. [REQMNT] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RTP] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July, 2003. [SDP] Handley, M., Jacobson, V., Perkins, C., "SDP: Session Description Protocol," Work in Progress, draft-ietf-mmusic-sdp-new-18.txt, June 2004. 8. Informative References [FECINTRO] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and Crowcroft, J., "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002. [FLUTE] Paila, T., Luby, M., Lehtonen, R., Roca, V., Walsh, R., "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, draft-ietf-rmt-flute-08.txt, June 2004. [PARITYFEC] Rosenberg, J., Schulzrinne, H., "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999. [REPAIR] Perkins, C. and Hodson, O., "Options for Repair of Streaming media", RFC 2354, June 1998. 9. Authors' Addresses Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive, suite 300 Fremont, CA 94538, USA email: luby (at) digitalfountain.com Ross Finlayson Live Networks, Inc. (LIVE.COM) 650 Castro St., suite 120-196 Mountain View, CA 94041, USA email: finlayson (at) live.com Hiroaki Nishimoto Sumitomo Electric Networks, Inc. 1-3-12 Motoakasaka, Minato-ku Tokyo 107-0051, Japan email: nishimoto (at) sei-networks.com 10. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 11. Copyright Notice Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires: January 2005 July 9, 2004