RTP Payload Format for Flexible Forward Error Correction (FEC)
Extracted elements (28)
1-D non-interleaved (row) FEC performs better against random packet loss, while 1-D interleaved (column) FEC performs better against burst losses. 2-D parity FEC combines both at the cost of higher overhead (1/L + 1/D), providing superior protection against mixed loss patterns.
Source packets are left unmodified (not adding any FEC-specific fields) so that non-FEC-capable receivers in multicast sessions can still receive and decode them without modification, enabling backward compatibility in mixed receiver deployments.
Two FEC header variants (flexible mask vs. fixed L/D) are provided because the mask approach is inefficient or impossible to signal for large numbers of source packets (beyond 110), while the fixed L/D approach supports up to 255 rows and columns but cannot represent arbitrary protection patterns.
FLEX FEC repair packets are not backward compatible with RFC 2733, RFC 5109, or SMPTE 2022-1, but endpoints that do not implement this specification can ignore the FEC repair packets, since the unrecognized payload type causes RTP receivers to discard them per RFC 3550.
The RTP Stream Identifier Source Description SHOULD NOT be used with Flexible FEC, because FLEX FEC already defines a mechanism supporting protection of multiple source streams with a single repair stream.
FEC repair packets MUST use the CSRC list and count in the RTP header to specify the SSRCs of the source RTP stream(s) protected by the repair packet.
If a peer supporting both FLEX FEC and other RTP retransmission methods (RFC 4588) receives an Offer including both, it MUST respond with an Answer containing only FLEX FEC.
If the L and D values in a repair packet result in a repair window exceeding that agreed for the FLEX FEC session, the repair packet MUST be ignored by the receiver.
In bandwidth-limited networks, applications MUST NOT arbitrarily increase the amount of FEC protection, as doing so may lead to congestion collapse. Stronger FEC protection MAY be applied only after reducing the source rate.
Repair packets that include L and D values larger than the repair window MUST NOT be sent.
Repair packets with L=0 and D=0 in the fixed-variant FEC header MUST be ignored by the receiver. Current FLEX FEC implementations MUST NOT send packets with R=1 and F=1 (reserved variant), and receivers MUST ignore them.
The FLEX FEC receiver MUST support all possible L and D combinations and all flexible mask configurations within the agreed repair window, as the FEC configuration can change with each repair packet.
The RTP Marker (M) bit in FEC repair packets SHALL be set to 0 by senders and SHALL be ignored by receivers, as it has no defined use for this payload type.
The RTP timestamp clock rate (rate parameter) SHALL be larger than 1000 Hz; it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
The SSRC of each repair stream SHALL be randomly assigned per RFC 3550 Section 8 guidelines. The repair stream's CNAME SHOULD be identical to the CNAME of the source RTP stream(s) it protects.
When shorter source packets are XOR'd to form a repair packet, each shorter packet MUST be padded to the length of the longest packet by appending zero octets at the end.
FLEX FEC defines three FEC header variants selected by R and F bits: R=0,F=0 uses flexible bitmask fields; R=0,F=1 uses fixed L columns and D rows; R=1,F=0 is a retransmission of a single source packet. R=1,F=1 is reserved and MUST NOT be sent.
Source packets are transmitted unmodified as standard RTP packets; no additional fields are appended. This systematic code approach allows non-FEC-capable receivers to receive and process source packets without any changes, providing backward compatibility.
The bitmask in the flexible mask FEC header can be 15, 46, or 110 bits. The k-bit in each mask word indicates whether another mask word follows (k=1) or if this is the last block (k=0), allowing variable-length coverage of up to 110 source packets.
The repair payload covers everything following the fixed 12-byte RTP header of each source packet, including any CSRC list, header extensions, RTP payload, and padding. The SSRC field of source packets is excluded from the XOR computation.
The repair-window SDP parameter specifies the time spanning source and corresponding repair packets, expressed in microseconds. The repair window size determines maximum buffering requirements at the receiver and constrains valid L and D values.
This document registers four new media subtypes with IANA: audio/flexfec, video/flexfec, text/flexfec, and application/flexfec, each requiring the 'rate' and 'repair-window' parameters and restricted to RTP transport.
An attacker can exploit FLEX FEC's multi-stream support by injecting forged repair packets with large L, D, or repair-window values, or manipulated length recovery fields, causing receivers to allocate excessive memory buffers. Integrity protection (e.g., SRTP) is recommended to mitigate these resource exhaustion attacks.
Confidentiality, integrity, and source authentication for FLEX FEC RTP packets should be provided by SRTP (RFC 3711), IPsec (RFC 4301), or DTLS (RFC 6347). A single mechanism is not sufficient for all deployments; the appropriate choice depends on application, transport, and signaling.
The 2-D iterative decoding algorithm alternates between applying non-interleaved (row) and interleaved (column) FEC repair until either all packets are recovered or no further progress is made. The loop terminates when num_recovered_so_far equals num_recovered_until_this_iteration.
The FEC header for the fixed L/D variant (R=0, F=1) contains a 16-bit length recovery, a 32-bit TS recovery, a 16-bit SN base per SSRC, an 8-bit L (columns) field, and an 8-bit D (rows) field, giving a maximum value of 255 for each.
The FEC header for the flexible mask variant (R=0, F=0) contains a 16-bit length recovery field, a 32-bit TS recovery field, a 16-bit SN base per SSRC, and a variable-length bitmask of 15, 46, or 110 bits (controlled by the k-bit) indicating which source packets are protected.
The retransmission FEC header (R=1, F=0) mirrors the standard RTP header layout: 1-bit R, 1-bit F, P, X, CC, M, Payload Type, 16-bit Sequence Number, 32-bit Timestamp, and 32-bit SSRC. The source SSRC is carried in the FEC header itself, not in the RTP CSRC list.