An RTP Payload Format for Generic Forward Error Correction
obsoleted by
- rfc-5109 — RTP Payload Format for Generic Forward Error Correction
Extracted elements (29)
FEC is based exclusively on XOR (parity) operations because this enables a format that is independent of the media type, supports arbitrary block lengths and parity schemes, and allows the sender to adapt the FEC code without out-of-band signaling — the receiver can perform recovery without knowing the specific code in use.
FEC packets are sent as a separate stream (rather than in-band) to maintain backwards compatibility with non-FEC receivers and to allow the media stream to function independently. The payload format does not mandate the definition of 'separate streams', leaving that to applications and higher-level protocols.
The format does not mandate a particular parity code, allowing senders to use any linearly independent combinations of media packets (simple parity, interleaved parity, schemes without original media transmission, multi-packet burst recovery), trading overhead, delay, and recoverability.
The timestamp offset in the RFC 2198 redundant encodings header for FEC SHOULD be set to zero because FEC timestamps are already set to the transmission instant of the FEC packet and do not represent a fixed offset from the primary encoding timestamp.
FEC packets use dynamic RTP payload types. Per RFC 1889, RTP participants that cannot recognize a payload type must discard it, providing backwards compatibility with non-FEC-capable receivers in mixed multicast groups.
The CSRC list is never present in FEC packets regardless of the CC field value, and the header extension is never present regardless of the X bit value.
Implementers MUST NOT substantially increase the amount of FEC in use as network losses increase, because doing so can lead to increased congestion and eventual congestion collapse.
Shorter bit strings in the protection operation MUST be padded to the length of the longest bit string, with padding added at the end; any pad value MAY be used.
The E bit in the FEC header indicates a header extension. Implementations conforming to this version of the specification MUST set this bit to zero.
The FEC packet sequence number MUST be one higher than the sequence number in the previously transmitted FEC packet, giving FEC packets their own monotonically incrementing sequence number space.
The FEC packet timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted, resulting in monotonically increasing timestamps independent of the FEC scheme.
The <number of addresses> parameter MUST NOT appear in the fmtp connection address for FEC, since FEC cannot be hierarchically encoded.
The SN base field MUST be set to the minimum sequence number of those media packets protected by the FEC packet, allowing the FEC operation to extend over any string of at most 24 packets.
There is no static payload type for FEC; dynamic payload type numbers MUST be used for FEC packets. The binding is indicated by an rtpmap attribute using the name 'parityfec'.
When applying the protection operation to RFC 2198-encapsulated streams, RTP extension, padding, and CSRC list MUST be removed from the protected packets (with CC, Padding, Extension fields set to zero) before the FEC operation; the sender MUST still transmit the original unmodified packets as the primary encoding.
When FEC is carried in the RFC 2198 redundant encodings format, an rtpmap attribute MUST be used for the dynamic FEC payload type, and the FEC MUST protect only the main codec; the fmtp attribute for the FEC MUST NOT be present in this case.
When using redundant encodings (RFC 2198) with FEC, applications MUST set the marker bit to zero in media packets reconstructed using FEC, because the marker bit may not be correctly recovered in this mode.
An FEC packet consists of a standard RTP header, followed by a 12-byte FEC header, followed by the FEC payload. The FEC header and payload are placed in the RTP payload field.
FEC packets may be sent as a separate RTP stream (with its own sequence number space) or as a secondary codec using the RFC 2198 redundant encodings payload format. When sent as a separate stream, FEC timestamps are derived from the media but increment monotonically, which is compatible with header compression requiring fixed deltas.
Recovery of a missing media packet xi requires XOR-ing the bit strings of all other associated media packets with the FEC packet's bit string (using PT recovery, TS recovery fields in place of PT and TS; CSRC, extension, and padding always set to null for the FEC bit string). The result reconstructs the full RTP header and payload of xi.
The 24-bit mask field identifies associated media packets: if bit i is set, the media packet with sequence number N+i (where N is the SN base) was used to generate the FEC packet. The least significant bit corresponds to i=0, the most significant to i=23.
The length recovery field in the FEC header is computed by XOR-ing the unsigned network-ordered 16-bit representation of the sum of lengths (in bytes) of the media payload, CSRC list, extension, and padding of each associated media packet. This allows recovery even when media packet lengths differ.
The SDP fmtp line for FEC as a separate stream has the format: 'a=fmtp:<number> <port> <network type> <address type> <connection address>', where the connection address syntax mirrors SDP 'c' lines. For RTSP non-aggregate control, the format is 'a=fmtp:<number> <control URL>'.
Increasing FEC in response to rising network loss is explicitly prohibited because it can exacerbate congestion and contribute to congestion collapse on a widespread basis.
Key rotation is complicated by FEC: if packets a and b use different keys and FEC packet f(a,b) spans the key change, the old key must be cached and used until it is determined that the key has changed on the FEC stream as well.
When FEC and media streams use different encryption keys, or only one stream is encrypted, additional application-level signaling is required to exchange and negotiate keys separately. Encrypting only one stream may enable known-plaintext attacks. Applications utilizing encryption SHOULD encrypt both the media and FEC streams with the same key.
Recovery algorithm: on receiving an FEC packet, attempt recovery; if insufficient data, add to a pending list. On receiving a media packet, mark it present, then iterate the pending list to attempt recovery. Successfully recovered packets are treated as received and trigger further recovery attempts. One FEC packet can only be used once for recovery, after which it is removed from the pending list.
The FEC header is 12 bytes and contains: SN base (16 bits), length recovery (16 bits), E bit (1 bit), PT recovery (7 bits), mask (24 bits), and TS recovery (32 bits).
The protection operation constructs a bit string per media packet by concatenating: Padding bit (1), Extension bit (1), CC (4), Marker (1), Payload Type (7), Timestamp (32), payload+extension+CSRC+padding length (16), then the CSRC list (if CC nonzero), header extension (if X=1), payload, and padding. Shorter bit strings MUST be zero-padded at the end to the length of the longest.