RTP Payload Format for Raptor Forward Error Correction (FEC)
Extracted elements (19)
For FEC Schemes based on source flows with identifiable sequence numbers (schemes 5 and 6 of RFC 6681), no explicit FEC Source Payload ID is required in packets, enabling backwards-compatible operation where source flows need not be modified.
Raptor and RaptorQ are block-based fountain codes that can generate an arbitrary number of repair packets from any source block. The original source symbols can be recovered with very high probability from any set of symbols only slightly greater in number than the original, making them efficient for real-time multimedia FEC.
The FEC Framework (RFC 6363) provides independence between application protocols and FEC codes via FEC Schemes. This allows the Raptor RTP payload format to work with any of the six FEC Schemes defined in RFC 6681 without modification.
All four raptorfec media types (application, video, audio, text) are only defined for transfer via RTP (RFC 3550). Transport within other framing protocols is not defined at this time.
Each combination of Kmax and T parameters produces different FEC data and is not compatible with any other combination. A sender MAY offer multiple Kmax/T combinations; the receiver SHOULD choose the offer with the largest product of Kmax and T that it supports.
In declarative SDP usage (e.g., RTSP, SAP), the payload format configuration parameters are all declarative and a participant MUST use the configuration provided for the session.
RTCP SHALL be used according to RFC 3550. If the repair RTP session is sent in a separate RTP session, the two sessions MUST be associated using RTCP CNAME.
RTP header fields SHALL be set according to RFC 3550 rules. The marker bit SHALL be set to 1 for the last protection RTP packet sent for each source block, and otherwise set to 0.
The mapping of payload format media type and parameters to SDP SHALL be done according to Section 3 of RFC 4855, mapping payload-format-specific parameters into the 'a=fmtp' field. Media type parameters MUST use the media types in this document and MUST NOT use those specified in RFC 6364.
The RTP Payload SHALL contain a Repair FEC Payload ID as defined in RFC 6363 and RFC 6681.
The RTP payload type codes SHALL be assigned dynamically through non-RTP means. If SDP is used for signaling, the rules in Section 7 apply.
The RTP timestamp SHOULD be as close as possible to the packet's actual time of transmission. Implementations SHOULD supply a value usable for packet-arrival timing or jitter calculations. The operator SHALL select a 'rate' larger than 1000 Hz and SHOULD select the rate matching the protected source RTP stream.
The SSRC values MUST be set according to RFC 3550. The SSRC value of the RTP repair flow MUST be different from the SSRC value of the protected source flow.
When the P parameter is not present in an offer/answer exchange, the receiver MUST use FEC Payload ID Format A. In an answer that selects an offer where P was omitted, P MUST either be omitted or included with value 'A'.
A repair packet is constructed by concatenation of an RTP header (Section 4.1) and payload data (Section 4.3). No additional payload header is present.
The 'raptorfec' media type requires five parameters: 'rate' (RTP clock rate in Hz), 'raptor-scheme-id' (FEC Scheme ID from RFC 6681), 'Kmax' (Maximum Source Block Length), 'T' (encoding symbol size in bytes), and 'repair-window' (maximum time spanning source and repair packets, in microseconds). The optional 'P' parameter specifies Payload ID Format, defaulting to 'A'.
There is no payload header in this RTP payload format. The RTP payload consists solely of the Repair FEC Payload ID and repair data as defined in RFC 6363 and RFC 6681.
IANA registered four new media types: 'application/raptorfec', 'video/raptorfec', 'audio/raptorfec', and 'text/raptorfec'. Each was also added to the IANA registry for 'RTP Payload Format media types'.
Security considerations from RFC 6363 (FEC Framework) apply in full. RTP packets are subject to confidentiality, integrity, and source authenticity requirements; SRTP (RFC 3711) is RECOMMENDED, with IPsec and TLS as alternatives. The appropriate mechanism depends on the application, transport, and signaling protocol.