WebRTC Forward Error Correction Requirements
Extracted elements (28)
FEC data is recommended for bandwidth probing because extra data will be sent anyway, and FEC protects the primary payload while allowing modest, controlled bandwidth increases suitable for probing.
No FEC recommendations are made for WebRTC application data (SCTP/data channels) because the application controls what data to send and can implement its own application-level FEC based on packet statistics.
Proactive FEC always consumes bandwidth for redundant data within congestion-control limits, reducing bandwidth available for the primary encoding even when not needed — unlike RTX or Flexible FEC retransmission which only send redundant data on demand at the cost of extra latency.
Opus built-in FEC only carries redundancy for the immediately preceding audio frame; on wireless networks with multiple consecutive losses, multi-packet protection via redundant encoding with reduced-bitrate Opus SHOULD be used instead.
Redundant encoding cannot recover certain RTP header fields including the marker bit, CSRC information, and header extensions (per RFC 2198, Section 4); in-band FEC mechanisms also cannot recover any part of the RTP header.
When BUNDLE (RFC 8843) is used with Flexible FEC, only a single Flexible FEC repair stream will be created for each BUNDLE group, even if Flexible FEC is negotiated for each primary stream.
Answerers SHOULD reject any FEC-only 'm=' lines unless they specifically know how to handle such a thing in a WebRTC context.
For AMR/AMR-WB, receivers MUST include the 'max-red' parameter and set it to an appropriate value as specified in 3GPP TS 26.114, Table 6.3.
For audio, use of a separate FEC stream is NOT RECOMMENDED due to the higher overhead imposed by the lower packet rate of audio encodings.
For audio with variable-bitrate codecs without internal FEC, redundant encoding (RFC 2198) with lower-fidelity versions of previous packets is RECOMMENDED.
For Opus, a receiver MUST indicate readiness to use incoming FEC data with the 'useinbandfec=1' parameter as specified in RFC 7587.
For video content, use of a separate FEC stream with the Flexible FEC RTP payload format (RFC 8627) is RECOMMENDED because it can protect multiple RTP packets and streams with a single FEC stream.
Implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support as described in Section 4.
Implementations SHOULD account for the inability of recommended audio FEC mechanisms to recover RTP header parts (CSRCs, header extensions) and attempt to approximate this information.
Implementations SHOULD only transmit the amount of FEC needed to protect against the observed packet loss (determinable via RTCP receiver reports), unless the application indicates willingness to pay a quality penalty.
Support for an SSRC-multiplexed Flexible FEC stream SHOULD be indicated by including video/flexfec as an additional supported media type in the SDP offer's 'm=' section.
Support for redundant encoding of a given RTP stream SHOULD be indicated by including audio/red (RFC 2198) as an additional supported media type in the SDP offer's 'm=' section.
The general Flexible FEC mechanism (RFC 8627) SHOULD also be supported as mentioned in Section 5; implementations MAY support additional FEC mechanisms such as RFC 5109.
Use of FEC-only 'm=' lines and grouping via the SDP group mechanism (RFC 5956, Section 4.1) is not defined for WebRTC and SHOULD NOT be offered.
WebRTC implementations SHOULD prefer using RTX or Flexible FEC retransmissions instead of proactive FEC when the connection RTT is within the application's latency budget.
When probing bandwidth, FEC data SHOULD be used as the additional probing data, since it protects the primary payload and increases bandwidth only modestly.
When using AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED as it provides slightly more efficient protection than redundant encoding.
When using FEC with layered codecs (e.g., VP8/RFC 6386), implementations SHOULD only apply FEC to base layer frames that are critical to decoding future frames.
When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. If multi-packet protection is needed, redundant encoding with reduced-bitrate Opus encodings SHOULD be used instead.
Codec-specific in-band FEC (Opus, AMR/AMR-WB): redundant data is included within the codec payload with no additional framing. Opus re-encodes important frames at lower bitrate appended to the next payload; AMR/AMR-WB can include copies or lower-quality encodings of multiple prior frames.
Redundant encoding (RFC 2198): redundant data is piggybacked on an existing primary encoding in a single packet. Can be an exact copy or lower-quality representation of prior payload; efficient when data fits within MTU but cannot recover RTP marker bit, CSRC, or header extensions.
Separate FEC stream: FEC packets are sent as an independent RTP stream with its own SSRC and payload type, multiplexed with the primary encoding. Can protect multiple primary packets with a single FEC packet but carries full IP/UDP/RTP/FEC header overhead per packet.
In WebRTC, FEC only recovers data from lost packets; corrupted packets are discarded by SRTP decryption. The required processing order is FEC then SRTP at the sender, and SRTP then FEC at the receiver, as described in RFC 3711, Section 10. This ordering applies to all DTLS-SRTP protection profiles.