Every time you make a WhatsApp call, join a Google Meet, or use a modern WebRTC application, RFC 2198 is quietly protecting your audio from the ravages of the public internet. It's a two-page marvel of pragmatism that solves one of real-time media's oldest problems: UDP packet loss without added latency.

The problem context: TCP-style retransmission is useless for live audio — by the time a lost packet arrives, the conversation has moved on. Traditional forward error correction (FEC) works but requires buffering multiple packets to compute parity, which adds delay. In the mid-1990s, the MBone (Multicast Backbone) community — building tools like vat and rat for academic conferencing — needed something better. They had a clever insight: packet loss is usually bursty and short, so if each packet carried a low-bitrate copy of the previous packet's audio, a single lost packet could be reconstructed from the next one that arrived.

The design. RFC 2198 defines a new RTP payload format (informally called "RED" for REDundant) that bundles a primary encoding with one or more secondary encodings inside a single RTP packet. Each block header contains:

• A payload type identifier (which codec)
• A timestamp offset (how far back this redundant copy refers to)
• A block length

Typically the primary might be full-rate G.711 or Opus, while the redundant copies use a lower-bitrate codec like GSM or LPC — trading a modest bandwidth increase for dramatic loss resilience. The receiver plays the primary when it arrives; if a packet is lost, it decodes the redundant copy from the next packet at the correct timestamp offset. Latency added: exactly one packet time (usually 20 ms). Bandwidth added: often just 15–30%.

Why the design is elegant. There is no signaling protocol, no negotiation of FEC parameters, no matrix math. The sender simply prepends old frames to new ones. A receiver that doesn't understand the RED payload type can still fall back to interpreting the primary block (it's just RTP-in-RTP). It composes cleanly with any codec because the redundancy is codec-agnostic — the RED wrapper doesn't know or care what's inside.

Modern relevance. WebRTC uses RFC 2198 heavily. Chrome enables Opus RED by default for audio when it detects lossy paths. The IETF later extended the pattern for video in RFC 6015 and adjacent specs. Even proprietary systems like Zoom and Teams use conceptually identical approaches — often calling it "in-band FEC" — because after 28 years, nobody has found a fundamentally better tradeoff for interactive voice.

The backstory. The author list is a who's-who of 1990s multimedia networking: Colin Perkins, Mark Handley (later of TCP fame), and Jean-Chrysostome Bolot all built the MBone toolchain at UCL and INRIA. Their tools were used to broadcast IETF meetings themselves over multicast, which meant the protocol got dogfooded by its own designers weekly. That's why it's terse and practical — it was written by people who had already shipped the idea and were merely documenting reality.

One quirk: despite the "audio" in the title, nothing in the format is audio-specific. Text conversation over RTP (RFC 4103, T.140) also uses RED for the same reason. The RFC's narrow title undersells its generality.