Forward error correction (FEC), in-band FEC, and RED redundancy

Why this matters

If you build video calling, telemedicine, contact-centre, or live-classroom software, packet loss decides whether your audio sounds clear or turns into a robotic stutter — and FEC is the main lever you have to fix it before the listener ever hears a gap. The choice between Opus in-band FEC and RED, and the bitrate you are willing to spend on either, is a product decision with real cost and real quality consequences, not a detail to leave on defaults. This article is for the product manager, founder, or operations lead who needs to understand what FEC buys, what it costs, and when it backfires — so they can read a quality complaint correctly and brief their engineers with the right vocabulary. A senior engineer will also find every claim traced to the controlling RFCs, the Opus specification, and the WebRTC engineering record.

The problem: you cannot ask for the packet again

Start with the constraint that rules out the obvious fix. When a packet goes missing on a network, the simplest idea is to ask the sender to send it again. That technique is called retransmission, abbreviated RTX, and it is defined for RTP media in the IETF's RFC 4588 (July 2006). For downloading a file or loading a web page, retransmission is exactly right: you wait a moment, the missing piece arrives, and nothing is lost.

For a live conversation, retransmission usually arrives too late to use. Here is why, with the numbers shown out loud. Asking for a packet again costs one network round trip — the time for your request to reach the sender plus the time for the resent packet to come back:

round trip time (RTT)   = time to sender + time back
example transcontinental RTT = 150 ms
jitter buffer hold time      = 60 ms
verdict: 150 ms > 60 ms  →  the resent packet arrives after its slot has played

The receiver cannot pause the conversation while it waits. In WebRTC the audio device demands a fresh slice of sound — exactly 10 milliseconds of it — on time, 100 times a second, forever (we walk through that clock in our article on the WebRTC audio pipeline). If the resent packet does not come back before its moment to play, it is useless. Retransmission only helps when the round trip is short relative to how long the receiver's jitter buffer is willing to hold audio, which we cover in detail in the NetEQ jitter buffer. On a high-latency mobile or transcontinental link, that condition often fails.

So we need a way to recover a lost packet without a round trip. That is forward error correction.

What "forward" means: pay in advance

Forward error correction is the family of techniques that send redundant information ahead of time, mixed into the normal packet stream, so a lost packet can be reconstructed at the receiver the moment the loss is noticed — with no request back to the sender and no added delay. The word "forward" is the key: you pay the cost up front, on every packet, before you know whether any given packet will be lost. RFC 8854, the WebRTC FEC specification (January 2021), states the purpose plainly: FEC is "the sending of redundant information in an outgoing packet stream so that information can still be recovered even in the event of packet loss."

Think of it like mailing someone an important document and including a photocopy in the same envelope, and another photocopy in tomorrow's envelope. If one envelope is lost in the post, the recipient still has a copy from the other. You spend extra paper on every envelope, every day, even though most envelopes arrive fine. That spending — bandwidth, in the network case — is the price of not having to write back and ask for a re-send.

This pay-in-advance nature is the single most important thing to understand about FEC, because it is also its main downside. RFC 8854 spells out the cost: "use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits … this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used." In other words, on a clean network FEC is pure overhead that can actually lower your audio quality, because the bitrate it consumes is taken away from the main audio.

Figure 1. Retransmission asks for the packet again and waits a round trip; forward error correction sends the redundancy ahead of time so recovery is instant.

The three shapes FEC can take

RFC 8854 sorts the ways to do FEC for RTP media into three mechanisms, and the differences matter because they have very different overheads. Understanding the three is enough to follow every audio-resilience conversation you will have with an engineer.

The first is a separate FEC stream (RFC 5956). Here the redundancy travels as its own independent RTP stream, with its own headers. One repair packet can protect several media packets at once, which is efficient for video — but for audio, where there is usually just one small packet per frame, each FEC packet carries its own full set of IP, UDP, and RTP headers, and that header overhead is large relative to the tiny audio payload. RFC 8854 is blunt about this: a separate FEC stream for audio "comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED."

The second is redundant encoding (RFC 2198, the RED format), where the redundant data is piggybacked into the same packet as the primary audio, sharing one set of headers. This is efficient precisely because there is only one packet header, and it is the right shape for audio. We unpack RED in detail below.

The third is codec-specific in-band FEC, where the codec itself builds the redundancy into its own bitstream. Opus does this, and so does the AMR speech codec used in mobile telephony (which you can read about in our article on speech codecs). Because the redundancy lives inside the codec payload and "adds no additional framing", RFC 8854 notes it "can be slightly more efficient" than RED. This is the mechanism most WebRTC calls use by default.

Opus in-band FEC: a cheap copy of the last frame

Opus is the codec WebRTC uses for nearly all voice (we cover it fully in the Opus codec explained). Its built-in FEC works through a mechanism that the Opus specification, RFC 6716 (September 2012), calls LBRR — Low Bit-Rate Redundancy (RFC 6716, §4.2.5). The idea is simple: when FEC is on, the encoder takes the audio frame it just sent, re-encodes it at a much lower quality, and tucks that small copy inside the next packet. RFC 8854 describes it cleanly: for Opus, "audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery of a lost packet."

So packet N carries two things: a full-quality copy of frame N, and a low-quality copy of frame N−1. If packet N−1 is lost but packet N arrives, the decoder pulls the backup copy of frame N−1 out of packet N and plays it — degraded, but far better than a guessed continuation. This is the difference between FEC and packet loss concealment: concealment invents a plausible substitute for the lost sound, while FEC recovers what was actually said, because a real copy was sent. We compare those tools side by side in packet loss concealment (PLC).

Opus in-band FEC has one hard limitation that shapes everything about how you use it. RFC 8854 states it directly: "this mechanism can only carry redundancy information for the immediately preceding audio frame; thus the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks." In plain terms: Opus FEC protects against losing one packet at a time. Lose two in a row — a burst, which is exactly what bad Wi-Fi and cellular links produce — and the backup copy of the first lost frame was riding inside the second lost packet, so it is gone too.

Turning it on, and the bitrate it eats

To receive Opus FEC, a receiver signals readiness with the parameter useinbandfec=1, defined in the Opus RTP payload format RFC 7587 (June 2015). On the sending side, the encoder must be told FEC is wanted and told how much loss to expect, so it knows how much to protect. Two practical facts from the WebRTC engineering record govern whether it actually does anything.

First, Opus only starts producing LBRR when it believes loss is happening. Mozilla's WebRTC team, when they enabled audio FEC in Firefox, found that "the threshold for enabling LBRR within Opus is around 1%" packet loss (Mozilla, "Audio FEC Experimentation", November 2016). Below that, FEC sends nothing — which means it cannot protect you against the first burst of a sudden loss event, only against ongoing loss.

Second, the redundancy is not free bitrate added on top; it is carved out of your existing bitrate budget. The WebRTC implementation subtracts the FEC bitrate from the target bitrate, and the protection is capped — engineering analysis of the WebRTC stack found Opus FEC's correction "is capped to 25%" and that "the bitrate for FEC is subtracted from the target max bitrate" (webrtcHacks, "RED: Improving Audio Quality with Redundancy", August 2020). And Opus needs enough total bitrate to have room for the copy at all. Mozilla found that at Firefox's default 40 kbps for two channels, FEC would not turn on — the bitrate "would have to be increased to 58000" bits per second (58 kbps) before stereo Opus starts producing LBRR packets (Mozilla, November 2016). The lesson: if you want Opus FEC to work, raise the audio bitrate so there is headroom for the redundancy, or it silently does nothing.

Figure 2. Opus in-band FEC packs a low-bitrate copy of frame N−1 into packet N; one isolated loss is recoverable, a burst of two is not.

RED: wrap whole packets for stronger protection

When one frame of protection is not enough, the older and more flexible answer is RED — RTP Payload for Redundant Audio Data, defined in RFC 2198 all the way back in September 1997. RED was built for the early internet's audio conferencing tools, and its core idea has aged well: take one or more whole previous audio payloads and pack them into the current RTP packet, behind a small header, all under a single RTP header.

RFC 2198 lays out the format precisely. A RED packet is a container: a normal RTP header (whose fields describe the primary, newest audio), then a short header block for each redundant payload, then the payload data. Each redundant block's header is four bytes and carries a flag bit (F) that says whether another block follows, a 7-bit payload type identifying the codec of that block, a 14-bit timestamp offset saying how far in the past that block's audio is, and a 10-bit block length. The primary block's header is just one byte, because its timestamp and length are already known from the RTP header and total packet size. The specification is strict that "the redundant encoding MUST NOT be higher bandwidth than the primary" — the backups are meant to be small.

In WebRTC, RED is negotiated in the session description as a codec named red, and to use it you place it ahead of Opus in the list of codecs. The negotiated line looks like a=rtpmap:111 red/48000/2 — RED at 48 kHz, 2 channels — and the application reorders codecs so RED wraps the Opus payload (webrtcHacks, August 2020). The number of redundant copies RED carries is called the distance: distance 1 means each packet also carries the previous packet, distance 2 means it carries the previous two.

Distance 2 is the sweet spot, and it roughly doubles your bitrate

The most useful production result on RED comes from the engineering work that brought it back into WebRTC. Testing at a brutal 60% random packet loss, the team measured audio quality by the share of samples the receiver had to conceal — the ratio of concealedSamples to totalSamplesReceived from the WebRTC statistics API. The numbers tell the whole story:

network loss = 60%
no RED:               60% of samples concealed   → words hard to understand
RED, distance 1:      32% concealed               → audible artifacts
RED, distance 2:      18% concealed               → almost perfect audio

Distance 2 cut concealment from 60% to 18% at 60% loss, and "distance 2 ... is the amount of redundancy that is now used" in WebRTC (webrtcHacks, August 2020). The cost is bandwidth: RED with one redundant copy roughly doubles the audio bitrate — from about 30 kbps to about 60 kbps in the published test, "with an additional 10 kbps for the header" — and distance 2 pushes it higher still (webrtcHacks, August 2020). Two refinements keep that cost in check. Voice activity detection means redundant copies are only sent when someone is actually speaking, and discontinuous transmission (DTX) stops sending during silence — both covered in VAD and DTX — so the doubled bitrate only applies to the parts of the call that carry speech.

The reason distance 2 matters so much over distance 1 is the burst problem again: if losses come two in a row, distance 1's single backup may itself be in a lost packet, while distance 2 spreads two backups across two later packets, so it survives a two-packet burst. As the WebRTC engineer who did the work put it, "the human brain can tolerate a certain level of intermittent silence" — distance 2 keeps the gaps short enough to stay below that threshold.

The frontier: Deep REDundancy (DRED)

Both Opus in-band FEC and RED hit the same wall on long bursts. Opus FEC protects one frame; RED at a practical distance protects two or three. On a network that drops a dozen packets in a row — a quarter-second of speech gone — neither can help, because they simply do not carry that much history without an unacceptable bitrate cost.

The emerging answer is DRED — Deep Audio Redundancy — a neural extension to Opus being standardised through the IETF's mlcodec working group (draft-ietf-mlcodec-opus-dred-05, expires July 2026; authors from Google and Meta). DRED replaces the "re-encode the last frame at lower quality" idea with a neural compressor — a rate-distortion-optimised variational autoencoder — that squeezes a much longer slice of recent audio into a tiny amount of data. The draft states the gain directly: where Opus's existing LBRR "is limited to a single frame of redundancy, and typically uses about 2/3 of the bitrate of the regular Opus packet," DRED "allows up to one second or more redundancy to be included in each packet, using a bitrate about 1/50 of the regular Opus bitrate" (draft-ietf-mlcodec-opus-dred-05, §2). The redundancy is carried inside the Opus packet's padding, so older decoders that do not understand DRED simply ignore it.

The practical effect is that every frame is effectively transmitted many times across many later packets, so even a long burst can be filled with audio that was actually spoken rather than guessed. DRED shipped in experimental form with Opus 1.5 (March 2024), the same release that added neural packet loss concealment. Because it is still a draft, treat the exact numbers as a moving target — but the direction is clear: the line between "redundancy" and "concealment" is blurring, and the next generation of resilient audio lives on it.

A worked example: does FEC help, or just cost?

The decision to enable FEC comes down to whether the bandwidth it spends buys back more quality than it costs. Work through a concrete case. Suppose a one-on-one call uses Opus at 40 kbps, and you are deciding whether to add RED at distance 1, which roughly doubles the audio bitrate.

primary audio bitrate        = 40 kbps
RED distance 1 adds           ≈ 40 kbps + ~10 kbps header
total audio bitrate with RED  ≈ 90 kbps

Now weigh that 50 kbps of extra spend against the situation:

On a clean office connection with near-zero loss, that 50 kbps buys nothing — there are no lost packets to recover — and it competes with everything else on the link. RFC 8854's guidance is to prefer retransmission when the round trip fits the latency budget and "otherwise SHOULD only transmit the amount of FEC needed to protect against the observed packet loss." So on a clean link, the right answer is little or no FEC.

On a lossy mobile connection running 8% bursty loss, the same 50 kbps is the difference between a clear call and a robotic one — and against a video stream that might be sending 1.5 Mbps, an extra 50 kbps of audio protection is a rounding error. As the webrtcHacks analysis noted, the bandwidth cost of RED "compared to more than one megabit per second of video data … does not seem so bad."

And there is a case where FEC actively hurts: when the loss is caused by congestion — the link is already full — adding redundant data sends more data into a saturated pipe, increasing loss. RFC 8854 warns that "if the loss is caused by network congestion, the additional bandwidth used by the redundant data may actually make the situation worse." RFC 2198 makes the same point about RED: too much redundancy "will increase network congestion, and hence packet loss, leading to a worsening of the problem which the use of redundancy was intended to solve." This is why production stacks turn FEC up and down based on measured loss rather than leaving it on at full strength.

A common pitfall: leaving FEC on at full strength on a clean network

The most common mistake is treating FEC as a free quality upgrade and maxing it out everywhere. It is not free: every redundant copy is bitrate taken from the primary audio or added to the link, and on a clean connection that is pure waste that can lower quality, not raise it. Worse, if the loss you are seeing is congestion-driven, full-strength FEC pours fuel on the fire. The fix is adaptive FEC: monitor the actual loss rate from RTCP receiver reports and send only as much redundancy as the observed loss warrants, as RFC 8854 recommends. Set it and forget it is the wrong instinct here.

A second trap is confusing FEC with retransmission and reaching for the wrong one. They are not interchangeable. RTX recovers the exact packet but costs a round trip, so it is right when latency is low; FEC costs steady bandwidth but adds no delay, so it is right when latency is high. RFC 8854's rule is explicit: prefer RTX or retransmission-style recovery "when the connection RTT is within the application's latency budget", and use FEC otherwise. Picking FEC on a low-latency LAN wastes bandwidth; picking RTX on a high-latency mobile link recovers packets too late to play.

A third trap is expecting Opus in-band FEC to survive bursts. Because it only protects the single previous frame, it shines on isolated random loss and collapses on the consecutive losses that real wireless networks produce. If your traffic is bursty, RED at distance 2 — or, in time, DRED — is the tool that matches the loss pattern; turning the Opus FEC dial higher will not close a multi-packet gap.

Where Fora Soft fits in

Fora Soft has built real-time audio into video conferencing, telemedicine, e-learning, and live-shopping products since 2005, and choosing the right loss-resilience mix is a routine part of how we tune those systems. When a customer reports robotic or dropping audio, we read the loss rate and burst pattern from the WebRTC statistics, then decide deliberately: leave Opus in-band FEC on for ordinary random loss, switch to RED at distance 2 when the link is bursty, raise the audio bitrate so the redundancy has room to work, and keep all of it adaptive so a clean connection is not taxed. A telemedicine call on hospital Wi-Fi and a large webinar on mixed consumer links lose packets in different patterns, and the right answer is read from the measured loss profile, not set by default. We instrument those statistics from the start so "the audio breaks up" becomes a number we can act on.

What to read next

• Packet Loss Concealment (PLC): Hiding The Missing Frames
• Jitter Buffer: NetEQ, The Brain Of WebRTC Audio
• The WebRTC Audio Pipeline End-to-End

Call to action

• Talk to a audio engineer — book a 30-minute scoping call to talk through your forward error correction audio plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the FEC & RED decision cheat sheet — One-page reference: retransmission (RTX) vs FEC, the three FEC mechanisms from RFC 8854, Opus in-band FEC (LBRR) vs RED (RFC 2198) vs DRED, the bitrate costs and key numbers (1% LBRR threshold, 25% cap, ~58 kbps stereo minimum, 60%->18%….

References

1. IETF RFC 8854, WebRTC Forward Error Correction Requirements (J. Uberti), January 2021 — the controlling WebRTC FEC specification: the three FEC mechanisms (separate FEC stream, redundant encoding / RED, codec-specific in-band FEC), the recommendation of Opus in-band FEC and RED for audio, the explicit statement that separate FEC streams are NOT RECOMMENDED for audio, the single-frame limit of Opus FEC, the adaptive-FEC guidance (prefer RTX when RTT fits the budget; send only as much FEC as observed loss warrants), and the congestion warning. Standards-track. Tier 1 (official IETF standard). https://www.rfc-editor.org/rfc/rfc8854.html
2. IETF RFC 2198, RTP Payload for Redundant Audio Data (C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis), September 1997 — the RED format: container packet with one RTP header, per-block 4-byte headers (F bit, 7-bit block PT, 14-bit timestamp offset, 10-bit block length), 1-byte primary block header, the rule that redundant data MUST NOT exceed the primary's bandwidth, the SDP red/8000/1 binding, and the congestion warning. Standards-track; updated by RFC 6354. Tier 1. https://www.rfc-editor.org/rfc/rfc2198.html
3. IETF RFC 6716, Definition of the Opus Audio Codec (JM. Valin, K. Vos, T. Terriberry), September 2012 — §2.1.7 and §4.2.5 define Opus's in-band FEC and the LBRR (Low Bit-Rate Redundancy) frames it uses; the codec whose built-in FEC most WebRTC calls rely on. Standards-track; updated by RFC 8251. Tier 1. https://www.rfc-editor.org/rfc/rfc6716
4. IETF RFC 7587, RTP Payload Format for the Opus Speech and Audio Codec (J. Spittka, K. Vos, JM. Valin), June 2015 — defines the useinbandfec media-type parameter by which a receiver signals it can use incoming Opus FEC data; the negotiation contract for Opus in-band FEC in WebRTC. Standards-track. Tier 1. https://www.rfc-editor.org/rfc/rfc7587
5. IETF RFC 4588, RTP Retransmission Payload Format (J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg), July 2006 — defines RTX retransmission, used here to establish why a round-trip-based recovery fails for live audio and why forward error correction is needed instead. Standards-track. Tier 1. https://www.rfc-editor.org/rfc/rfc4588
6. IETF, Deep Audio Redundancy (DRED) Extension for the Opus Codec (draft-ietf-mlcodec-opus-dred-05; JM. Valin, Google, and J. Buethe, Meta), expires 23 July 2026 — the neural redundancy extension: LBRR is limited to one frame at ~2/3 of the packet bitrate, while DRED carries up to one second or more of redundancy at ~1/50 of the regular Opus bitrate, transmitted inside the Opus padding so older decoders ignore it. Internet-Draft — work in progress, subject to change; cited as such per our drafts-handling rule. Tier 3 (standards-body draft from the maintainers). https://datatracker.ietf.org/doc/draft-ietf-mlcodec-opus-dred/
7. Mozilla, Audio FEC Experimentation (Advancing WebRTC blog, D. Minor), November 2016 — first-party WebRTC engineering record: the ~1% packet-loss threshold below which Opus does not produce LBRR, the finding that stereo Opus needs the bitrate raised to ~58 kbps before LBRR is produced, and listening comparisons showing FEC's effect is subtle at low loss and very noticeable at ~19% loss. Tier 4 (engineering blog from a browser implementer). https://blog.mozilla.org/webrtc/audio-fec-experiments/
8. webrtcHacks, RED: Improving Audio Quality with Redundancy (P. Hancke), August 2020 — the engineering work that returned RED to WebRTC: the SDP red/48000/2 negotiation and codec-reorder method, the RED "distance" concept, the 60%-loss test (no RED 60% concealed → distance 1 32% → distance 2 18%), distance 2 as the chosen amount, the ~30→~60 kbps + ~10 kbps header bitrate cost, VAD/DTX mitigation, the Opus FEC 25% cap, and the FEC-bitrate-subtracted-from-target behaviour. Tier 4 (deep first-party engineering analysis). https://webrtchacks.com/red-improving-audio-quality-with-redundancy/
9. Xiph.Org Foundation, Opus 1.5 Released (Opus development team), March 2024 — the release that shipped experimental DRED alongside neural PLC; orientation source for DRED's production availability and its relationship to the existing LBRR mechanism. Tier 3 (first-party maintainer publication). https://opus-codec.org/demo/opus-1.5/

Source-conflict note (per our standards-first rule): popular articles often use "FEC" loosely to mean any packet-loss fix and conflate it with retransmission and concealment. The controlling specs draw the precise boundaries this article uses — RFC 8854 defines the three FEC mechanisms and the RTX-vs-FEC choice, RFC 2198 defines RED, RFC 4588 defines RTX — so the article follows the specs and treats the looser usage as imprecise. Where the WebRTC implementation's behaviour (FEC capped at 25%, bitrate subtracted from target, RED distance 2 default) is not in the RFCs, it is attributed to the engineering record (refs 7–8) and flagged as implementation detail, not normative requirement.