RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)
Extracted elements (30)
Repair packet overhead equals 1/D (ratio of repair bytes to protected source bytes, ignoring FEC header size). A larger D reduces bandwidth overhead at the cost of a larger source block and increased latency before recovery is possible.
Source packets are left unmodified to provide backward compatibility for non-FEC-capable receivers. In multicast sessions this allows FEC-capable and non-FEC-capable receivers to share the same source stream without requiring separate multicast groups.
The Mask-based approach from RFC 2733 was rejected because for large source blocks the required Mask size becomes prohibitively large. The systematized approach (Offset = L, NA = D, SN base low) is inherently more efficient for signaling source-repair packet associations.
This document adopts the extended FEC header from SMPTE 2022-1 (which built on RFC 2733) but corrects its RFC 3550 non-compliance issues — specifically SSRC, timestamp, and CSRC handling — except for the P/X/CC bit legacy behavior retained for backward compatibility with deployed SMPTE 2022-1 systems.
The P bit, X bit, and CC field in the repair packet RTP header carry XOR-derived values and may cause failures during RTP header validity checks as specified in RFC 3550. RFC 5109 fixed this behavior; this document retains it for legacy compatibility, and implementations must be aware of this potential issue.
The RTP payload format defined in this document is NOT backward compatible with the parityfec payload format registered by RFC 3009; the two formats cannot be used interchangeably.
Applications SHOULD NOT send or receive FEC repair flows if doing so would not help recover missing packets. It is RECOMMENDED that FEC protection levels are adjusted dynamically based on observed packet loss rates.
In an SDP Offer/Answer exchange, any unknown format parameter in the offer MUST be ignored and deleted from the answer. If FEC is not desired by the receiver, the FEC stream can be deleted from the answer.
In congestion-prone 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 the source rate has been reduced.
In declarative SDP usage (e.g., RTSP or SAP), a participant MUST use the payload format configuration provided for the session. If multiple configurations are declared, receivers should choose the repair flow best suited to them.
Repair packets MUST contain information that identifies the source block to which they pertain and the relationship between the contained repair symbols and the original source block.
The FEC decoder SHOULD NOT register a decoding failure until it has waited at least for the repair-window duration after receiving the first packet in an FEC block; repair-window is specified in microseconds.
The Offset field MUST be set to the number of columns L, and the NA field MUST be set to the number of rows D. These two fields, together with SN base low, uniquely identify the source packets associated with a repair packet.
The rate parameter for all four registered media types SHALL be larger than 1000 Hz to provide sufficient resolution for RTCP; it is RECOMMENDED to match the clock rate of the protected source RTP stream.
The recovery algorithms in Section 6.3 are RECOMMENDED; implementations MAY adopt different algorithms, but the end result MUST be identical to what the specified algorithms would produce.
The repair flow SSRC SHALL be randomly assigned to enable multiplexing with source flows. SSRC collisions MUST be resolved per RFC 3550. When RTP Source and FEC Source are different hosts, they MUST share the same CNAME for source-repair flow association.
The repair packet sequence number MUST be one higher than the sequence number in the previously transmitted repair packet; the initial value SHOULD be random (unpredictable) as specified in RFC 3550.
The SN base low field MUST be set to the lowest sequence number (accounting for wraparound) of the source packets protected by this repair packet. The E bit MUST be set to 1 to signal the RFC 2733 header extension.
The Type field MUST be set to 0. The Mask, N bit, D bit, Index, and SN base ext fields SHALL be set to 0 and MUST be ignored by the receiver.
This payload format MUST only be used in legacy applications where the RFC 3550 compliance limitations (inherited from SMPTE 2022-1) are known not to impact any system components or other RTP elements. Whenever possible, RFC 5109 or newer fully compliant formats MUST be used.
When source packets being XOR'd have unequal lengths, each shorter packet MUST be padded to the length of the longest packet by appending zero octets at the end before computing the FEC bit string.
For any received repair packet p*, the sequence numbers of its associated source packets are computed as: p*_snb + i × L (modulo 65536), for 0 ≤ i < D, where p*_snb is the SN base low field value. Recovery succeeds only when exactly one source packet in the resulting set T(p*) is missing.
Repair packets consist of an IP header, transport header, RTP header, 16-octet FEC header, and repair symbols. The P bit, X bit, CC field, and M bit of the repair RTP header each equal the XOR of the corresponding fields from the protected source packets, but no actual padding, extension, or CSRC list is ever present in a repair packet.
Source packets are transmitted without any modification; their existing RTP sequence numbers serve as source block identifiers. This preserves full backward compatibility for non-FEC-capable receivers in multicast sessions.
The 1-D interleaved parity FEC code arranges source packets in a D×L matrix and XORs packets in each column (L apart in sequence number) to produce L repair packets. Each repair packet can recover exactly one missing source packet from its column; protection against bursty losses improves as L increases.
This document registers four new IANA media subtypes: audio/1d-interleaved-parityfec, video/1d-interleaved-parityfec, text/1d-interleaved-parityfec, and application/1d-interleaved-parityfec. All four require parameters rate (Hz), L (columns, 1–255), D (rows, 1–255), and repair-window (microseconds); all are restricted to RTP transport.
Altering FEC packets can critically impact source packet reconstruction; for example, changing the Length recovery field can produce a recovered packet that is excessively long. Implementations should perform sanity checks on received source and FEC packets before recovery and validate recovered packets before use.
If source packets are encrypted after FEC protection is applied, repair packets must receive equal levels of confidentiality, integrity, and authentication. Failure to do so compromises source packet security because FEC repair is generated by XOR-ing across source packets.
SRTP is RECOMMENDED as the security mechanism for this payload format. IPsec and TLS are viable alternatives; selection depends on the application, transport, and signaling protocol in use.
The FEC header is 16 octets: SN base low (16 bits), Length recovery (16 bits), E bit (1 bit), PT recovery (7 bits), Mask (24 bits), TS recovery (32 bits), N bit (1 bit), D bit (1 bit), Type (3 bits), Index (4 bits), Offset (8 bits), NA (8 bits), SN base ext (8 bits). Offset carries L (columns) and NA carries D (rows).