RTP Payload Format for Raptor FEC

The FEC Framework defines a general framework for the use of Forward Error Correction in association with arbitrary packet flows, including flows over UDP and RTP. Forward Error Corrections operates by generating redundant data packets ("repair data") which can be sent independently from the original flow. At a receiver the original flow can be reconstructed provided a sufficient set of redundant data packets and possibly original data packets are received. The FEC Framework provides for independence between application protocols and FEC codes. The use of a particular FEC code within the framework is defined by means of an FEC Scheme which may then be used with any application protocol compliant to the framework. Repair data flows may be sent directly over a transport protocol such as UDP, or they may be encapsulated within RTP. In the latter case, an RTP Payload Format must be defined for each FEC Scheme. This document defines the RTP Payload Format for the Raptor FEC Schemes defined in .

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 .

The Raptor code is an efficient XOR-based block-based fountain code, meaning that from any group of source packets an arbitrary number of repair packets may be generated. The Raptor code has the property that the original group of source packets can be recovered with very high probability from any set of packets (source and repair) only slightly greater in number than the original number of source packets. defines three FEC Schemes for the use of the Raptor code with arbitary packet flows: the first scheme is fully applicable to arbitary packet flows. The second scheme is a slightly optimised version of the first scheme which is applicable in applications with relatively small block sizes. The third scheme is a variant of the second scheme which is applicable to a single source flow which already has some kind of identifiable sequence number. The presence of a sequence number in the source flow allows for backwards compatible operation (the source flows do not need to be modified in order to apply FEC). In this case in the language of the FEC Framework, there is no explicit FEC Source Payload Id.

The RTP Payload contains a FEC Repair Payload as defined in .

The rules SHALL be followed for the RTP header used with FEC repair packets: Marker bit: The marker bit shall be set 1 for the last protection RTP packet sent for each source block, and otherwise set to 0 Timestamp: The timestamp SHALL be set to a time corresponding to the packet's transmission time. The timestamp value has no use in the actual FEC protection process. It may be used for packet arrival timing and jitter calculations.

There is no Payload Header in this Payload Format

The RTP Payload contains a FEC Repair Payload as defined in and .

See .

This RTP payload format is identified using the application/raptorfec media type which is registered in accordance with and using the template of .

Type name: application Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in Security considerations: Please see security consideration in Interoperability considerations: Published specification: Applications that use this media type: Additional information: 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: Mark Watson, mark@digitalfountain.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP []. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Digital Fountain Change controller: IETF Audio/Video Transport working group delegated from the IESG.

This RTP payload format is identified using the video/raptorfec media type which is registered in accordance with and using the template of .

Type name: video Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in Security considerations: Please see security consideration in Interoperability considerations: Published specification: Applications that use this media type: Additional information: 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: Mark Watson, mark@digitalfountain.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP []. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Digital Fountain Change controller: IETF Audio/Video Transport working group delegated from the IESG.

This RTP payload format is identified using the audio/raptorfec media type which is registered in accordance with and using the template of .

Type name: audio Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in Security considerations: Please see security consideration in Interoperability considerations: Published specification: Applications that use this media type: Additional information: 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: Mark Watson, mark@digitalfountain.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP []. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Digital Fountain Change controller: IETF Audio/Video Transport working group delegated from the IESG.

This RTP payload format is identified using the text/raptorfec media type which is registered in accordance with and using the template of .

Type name: text Subtype name: raptorfec Required parameters: raptor-scheme-id: The value of this parameter is the FEC Scheme Id for the specific Raptor FEC Scheme that will be used as defined in Optional parameters: none Encoding considerations: This media type is framed and binary, see section 4.8 in Security considerations: Please see security consideration in Interoperability considerations: Published specification: Applications that use this media type: Additional information: 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: Mark Watson, mark@digitalfountain.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP []. Transport within other framing protocols is not defined at this time. Author: Mark Watson, Digital Fountain Change controller: IETF Audio/Video Transport working group delegated from the IESG.

The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of

None.

This memo requests that IANA registers application/raptorfec as specified in , video/raptorfec as specified in , audio/raptorfec as specified in and text/raptorfec as specified in . The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" (http://www.iana.org/assignments/rtp-parameters).

See