Redundant Audio Data (RED)

Real-time communication applications powered by WebRTC must often contend with unpredictable network conditions that can lead to packet loss, jitter, and degraded audio quality. To mitigate these issues, WebRTC implementations can utilize a technique called Redundant Audio Data (RED). This approach enhances audio reliability by providing backup data that can be used when primary packets are lost during transmission. In this lesson, you'll explore how RED works within the WebRTC ecosystem, its implementation, benefits, drawbacks, and when it's most appropriate to use this technology.

Before we dive into RED specifically, let's understand the underlying protocol which is modified to add RED: the Real-time Transport Protocol or RTP.

What is RTP?

The Real-time Transport Protocol (RTP) is a network protocol specifically designed for the real-time transmission of audio and video over IP networks. It operates at the transport layer and is commonly used in applications such as voice-over IP (VoIP), video conferencing, and streaming media.

RTP provides a framework for the delivery of real-time data, with mechanisms for:

• Time-stamping (for synchronization)
• Sequence numbering (for packet ordering)
• Payload identification (to specify media types)

It works in conjunction with the RTP Control Protocol (RTCP) to monitor the quality of the data delivery and provide feedback on network conditions. While RTP doesn't guarantee real-time delivery or quality of service, it offers essential features that help in the reconstruction of real-time media at the receiver.

RTP Packet Structure

The RTP packet structure plays a crucial role in delivering real-time media data efficiently and reliably. It consists of three main components:

1. Fixed Header (12 bytes minimum)

• Version (2 bits): Identifies the RTP version (currently 2)
• Padding (1 bit): Indicates if additional bytes are added at the end to reach a certain payload size
• Extension (1 bit): Signals if optional header extensions are present
• CSRC count (4 bits): Defines the number of contributing sources for the data
• Marker (1 bit): For audio, typically indicates the start of a talk-spurt (while for video, it often marks the end of a frame)
• Payload Type (7 bits): Identifies the type of media data encoded in the payload
• Sequence Number (16 bits): Uniquely identifies a packet within a media stream
• Timestamp (32 bits): Provides the temporal location of the media data
• SSRC (32 bits): Synchronization Source identifier uniquely identifies the source of the media stream

2. Optional Header Extensions (variable size)

RTP allows extensions to the header for functionalities like jitter compensation, encryption, and header authentication.

3. Payload (variable size)

This section carries the actual media data encoded in the format indicated by the payload type.

Understanding RED (Redundant Audio Data)

The idea behind RED (REDundant audio data) is to transmit the same audio information in multiple payloads within the RTP stream. If the primary audio data payload is lost or corrupted during transmission, the receiver can use the lower-quality redundant information instead to replace the missing or damaged portion, improving the overall quality and completeness of the audio stream.

RED is not a core feature of RTP but rather an optional add-on to improve audio quality, particularly in unreliable network conditions. RED was first proposed through RFC 2198 in 1997 and is not enabled by default in RTP, as it consumes extra bandwidth (approximately 15-35 kbps extra for 20ms / 48 kHz Opus with one redundant copy). It's typically used when high audio quality is crucial or when network conditions are unpredictable.

How RED Works

The RED mechanism follows these key steps:

1. Encoding:

   • The original audio packet is encoded using a codec like Opus
   • One or more redundant copies are created. In Chrome's implementation, rather than a full secondary encode, RED wraps the previous frame's Opus-LBRR (Forward Error Correction) inside the RED header, which is more efficient than a complete redundant encode, resulting in a bandwidth increase of approximately 1.7x rather than a full 2x.
   • Chrome inserts LBRR only for 20 ms Opus frames; if you force 10 ms ptime, RED will carry a full secondary frame instead.

2. Packaging:

   • The original packet and its redundant data are bundled into a single RTP packet using the RED format
   • The RED header within the packet indicates the properties of the redundant data

3. Transmission:

   • The RTP packet with the RED payload is sent over the network

4. Reception:

   • The receiver first attempts to decode the original packet
   • If the original packet is lost or corrupted, the receiver tries to decode the redundant data
   • The receiver uses the first successfully decoded packet, discarding the others

RED Packet Structure

When RED is implemented, the RTP packet structure is modified to include redundant data:

According to RFC 2198, RED adds 4 bytes per redundant block (1-byte primary block header is implicit). With a single redundant copy, the overhead is therefore 4 bytes, not 6 as sometimes incorrectly stated.

Since RED is not defined by default in RTP, there needs to be a way to communicate that the dynamic payload in the RTP packet contains redundant data. The SDP (Session Description Protocol) contains information about using RED and is added as an additional payload type.

The rtpmap attribute in the SDP can define a particular codec, sample rate, and the number of channels. An example of its use is:

m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 red/8000/1

For more information on the Session Description Protocol, check out our previous lesson on SDP.

Browser Support Matrix

The support for RED varies across different browsers and platforms. Here's the current status as of 2025:

RED vs. Opus In-band FEC vs. PLC

When dealing with packet loss in WebRTC audio, it's important to understand the differences between these three approaches:

1. RED (Redundant Audio Data)

• Automatic Invocation in Chrome: Enabled when Opus FEC is enabled
• Performance Characteristics: Most effective for burst packet losses (multiple consecutive packets)
• Best Use Cases: High-value communication where bandwidth constraints are secondary to audio quality

2. Opus In-band FEC (Forward Error Correction)

• Automatic Invocation in Chrome: Enabled by default for voice modes, can be disabled manually
• Performance Characteristics: Good for scattered packet loss up to ~5-8%
• Best Use Cases: Moderate packet loss environments with bandwidth constraints

3. PLC (Packet Loss Concealment)

• Automatic Invocation in Chrome: Always active as a last resort when other methods fail
• Performance Characteristics: Works well for up to about 5% random loss; at 1-2% it's often imperceptible
• Best Use Cases: Minimal packet loss environments or as fallback when RED/FEC fails

Typical Loss Regimes for Optimal Performance

• < 2% loss: PLC alone often sufficient
• 2-8% loss: Opus FEC typically provides the best quality/bandwidth tradeoff
• > 8% loss or bursty loss: RED offers superior quality but at higher bandwidth cost

Implementing RED with SFUs

In general, if all clients connected to an SFU with or without cascading support RED, there is no need to do anything special - streams can be forwarded from one client to another without changing any characteristics. However, if SFUs can be connected to RED and non-RED clients, several cases need to be handled:

1. RED sender to RED receiver

• Straightforward case: streams can be forwarded without modification.

2. Non-RED sender to Non-RED receiver

• Simple case: no special handling needed.

3. Non-RED sender to RED receiver

• SFU can buffer audio packets from the sender and combine them to create RED packets for the receiver.
• When implementing this conversion, the SFU must shift the timestamp in the RED block header (sequence number remains unchanged).

4. RED sender to non-RED receiver

• SFU must remove redundant payloads to create standard RTP packets.
• This can be challenging if RED usage is dynamic (only applied to voice sections).

Configuring RED in SDP

RED implementation is configured through SDP using the fmtp attribute. According to RFC 2198, the correct syntax is a slash-separated list of payload types, ordered from oldest (largest "distance") to the primary payload:

a=rtpmap:121 red/48000/2
a=fmtp:121 111/111

In this example:

• 121 is the payload type for RED
• 48000 is the clock rate in Hz (use the clock rate that matches your primary codec, e.g., 48000 Hz with Opus)
• 111/111 indicates two Opus frames (PT 111), with the newest one last
• The first 111 is the redundant frame, and the second 111 is the primary frame

There is no standards-track syntax to explicitly advertise the distance in packets or packetization time; implementations infer distance from the number of encoded blocks in the parameter list. Chrome typically hard-wires distance = 1 for its implementation.

Effects on Redundancy Configuration

• Single redundant frame (e.g., 111/111): Lower latency, better for interactive calls, modest bandwidth increase
• Multiple redundant frames (e.g., 111/111/111): Better resilience against burst losses, higher bandwidth overhead
• Lower bitrate redundancy: Some implementations allow configuring lower bitrate LBRR for redundant frames, saving bandwidth at some quality cost

Recommendations:

• Start with a single redundant frame for most applications
• Use multiple redundant frames only when experiencing frequent burst losses
• Monitor MOS (Mean Opinion Score) and adjust based on quality/bandwidth measurements

JavaScript Implementation Example

Here's how you might configure RED support in a WebRTC application with proper capability checks:

            // Create an RTCPeerConnection
const pc = new RTCPeerConnection();

// Check if RED is supported before configuring
const audioCapabilities = RTCRtpSender.getCapabilities('audio');
if (!audioCapabilities) {
  console.log('RTCRtpSender.getCapabilities not available in this browser');
  // Proceed without RED
  return;
}

// Check for RED codec support
const codecs = audioCapabilities.codecs;
const redCodec = codecs.find(codec => codec.mimeType.toLowerCase() === 'audio/red');
const opusCodec = codecs.find(codec => codec.mimeType.toLowerCase() === 'audio/opus');

if (redCodec && opusCodec) {
  // Create a transceiver for audio with RED preference
  const transceiver = pc.addTransceiver('audio', {
    direction: 'sendrecv'
  });

  // Check if setCodecPreferences is supported (older Safari versions may not have it)
  if (transceiver.setCodecPreferences) {
    try {
      transceiver.setCodecPreferences([redCodec, opusCodec, ...codecs]);
      console.log('RED codec configuration successful');
    } catch (error) {
      console.error('Failed to set codec preferences:', error);
      // Fallback to default codec order
    }
  } else {
    console.log('setCodecPreferences not supported in this browser');
    // Proceed with default codec order
  }
} else {
  console.log('RED codec not supported in this browser');
  // Proceed without RED
}

// Continue with connection setup...
        

WebRTC-Stats Fields to Track RED

Modern WebRTC includes several statistics to track RED usage and effectiveness. These were added to the WebRTC-Stats draft in 2024 and can help monitor RED performance:

            // Example of monitoring RED stats
async function monitorRedStats(rtcPeerConnection) {
  const stats = await rtcPeerConnection.getStats();

  stats.forEach(report => {
    if (report.type === 'inbound-rtp' && report.kind === 'audio') {
      // Check for RED-specific stats
      if ('totalAudioRedundancy' in report) {
        console.log(`Total RED packets received: ${report.totalAudioRedundancy}`);
      }
      if ('packetsDiscardedRedundancy' in report) {
        console.log(`Redundant packets discarded (primary arrived): ${report.packetsDiscardedRedundancy}`);
      }
      if ('packetsRepairedRedundancy' in report) {
        console.log(`Packets repaired using redundancy: ${report.packetsRepairedRedundancy}`);
      }

      // Calculate RED effectiveness if possible
      if ('packetsLost' in report && 'packetsRepairedRedundancy' in report) {
        const lostPackets = report.packetsLost;
        const repairedPackets = report.packetsRepairedRedundancy;
        const recoveryRate = lostPackets > 0 ? (repairedPackets / lostPackets) * 100 : 0;
        console.log(`Packet recovery rate: ${recoveryRate.toFixed(2)}%`);
      }
    }
  });
}
        

Battery & CPU Impact on Mobile

Implementing RED comes with resource costs that can be particularly significant on mobile devices:

• CPU Impact: Duplicate encode + extra decode operations can increase CPU usage by approximately 8-12% on mid-tier phones
• Battery Drain: The additional processing and increased bandwidth consumption contribute to faster battery depletion
• Memory Usage: Buffering additional audio frames increases memory requirements slightly

Strategies for Constrained Devices

For mobile applications or other resource-constrained environments, consider:

1. Conditional Enabling: Enable RED only when on Wi-Fi or when network conditions deteriorate
2. User Control: Provide power-saving options that disable RED
3. Device-based Heuristics: Automatically disable RED on lower-end devices
4. Battery-level Awareness: Consider disabling RED when battery is low

Recording & Archiving Considerations

When recording WebRTC sessions with RED-enabled audio, special handling may be required:

• Popular media servers (Janus, Ion-SFU, mediasoup-recorder) typically strip RED before writing Opus to disk
• This is generally desirable as redundancy is unnecessary for recordings and would waste storage space
• If you need to preserve raw packets with RED for analysis:
  • Configure your media server to pass through RED packets unchanged
  • Use specialized recording solutions that can preserve the complete RTP structure
  • Consider implementing a custom recorder using the WebRTC Insertable Streams API

Security & E2EE Considerations

RED has minimal security implications beyond the standard WebRTC security model:

• RED frames travel inside the same SRTP protection as regular audio frames
• No additional configuration is required for end-to-end encryption when using insertable streams
• The redundant data receives the same encryption protection as primary data
• There are no known security vulnerabilities specific to RED implementation

This means that when implementing E2EE (End-to-End Encryption) in WebRTC applications with RED enabled, you can follow the standard E2EE approaches without special considerations for RED.

Advantages of RED

• Improved audio quality: Redundancy helps mitigate the effects of packet loss, leading to clearer and more consistent audio.
• Reduced artifacts: Audio artifacts like clicks, pops, and distortions are less noticeable when RED is used.
• Enhanced user experience: Listeners experience smoother and more reliable audio, even in challenging network conditions.
• Graceful degradation: Audio quality degrades more gracefully under network stress.

Disadvantages of RED

• Increased Bandwidth Consumption: Sending redundant copies of audio data consumes extra bandwidth. For 20ms / 48 kHz Opus with one redundant copy, this is typically 44 bytes extra per packet (4-byte RED header + 40-byte Opus-LBRR) which equals approximately 17.6 kbps. When accounting for header compression (including SRTP + uncompressed RTP/UDP/IP headers), the total overhead adds about 21-22 kbps on 50 packets-per-second links.
• Potential Latency Impact: Processing and transmitting additional audio data adds to the overall processing load, potentially increasing latency.
• Implementation complexity: Requires special handling in mixing and forwarding scenarios.
• Codec compatibility: Not all codecs support RED equally well, requiring careful consideration during implementation.

Best Practices for Using RED

• Selective application: Use RED only when network conditions warrant it
• Adaptive redundancy: Adjust redundancy levels based on observed packet loss
• Bandwidth awareness: Consider available bandwidth before enabling RED
• Fallback strategies: Have alternatives ready for clients that don't support RED
• Monitoring: Track RED usage impact on bandwidth and quality metrics

Alternative Approaches to Audio Reliability

While RED offers significant benefits for audio quality, it's not the only approach to improving audio reliability in WebRTC. Other complementary or alternative techniques include:

Forward Error Correction (FEC)

Many modern audio codecs like Opus include their own form of error correction. For instance, Opus includes in-band FEC that can recover from packet loss without requiring a complete redundant packet. This approach is more bandwidth-efficient than RED but may not be as effective in cases of severe packet loss.

Packet Loss Concealment (PLC)

Advanced PLC algorithms can synthesize audio to fill gaps caused by lost packets. These techniques work well for short gaps and can complement RED by handling cases where even the redundant data is lost.

Jitter Buffering

Jitter buffers help smooth out the variability in packet arrival times, reducing the impact of network jitter on audio quality. Adaptive jitter buffers can dynamically adjust their size based on network conditions.

Edge Cases and Special Considerations

Stereo Music Mode and RED

When using Opus in stereo music mode, there's an important implementation detail to be aware of:

• Stereo music mode in Opus disables LBRR (in-band Forward Error Correction)
• As a result, when RED is used with stereo music mode, it carries a full secondary frame instead of just the LBRR data
• This causes a more significant bitrate increase (closer to 2x) compared to the mono speech mode
• Consider this bandwidth impact when implementing high-quality stereo audio with RED protection

RED and AV1-LC Audio

As audio codecs continue to evolve, it's worth noting the relationship between RED and newer codecs:

• Emerging low-complexity AV1 audio doesn't yet define a built-in FEC mechanism
• RED becomes the primary loss-protection tool when experimenting with AV1-LC audio
• This makes RED particularly important for ensuring quality with next-generation audio codecs
• Keep an eye on standardization efforts, as this landscape is evolving rapidly

Testing and Debugging RED

Wireshark Analysis

When implementing RED, it's often useful to verify the actual packets being sent. Wireshark provides excellent tools for this:

1. Filtering RED packets: Use rtp.p_type == <RED_PT> where <RED_PT> is your RED payload type (e.g., 121)
2. Examining redundancy: Check the "Contributing Source" column to verify distance = 1 in the decode
3. Validating timestamps: Confirm timestamp offsets between primary and redundant data match expectations

Network Condition Testing

To properly test RED effectiveness, you need to simulate various network conditions:

1. On Linux: Use Traffic Control (tc) to simulate packet loss

   tc qdisc add dev eth0 root netem loss 10%

2. On macOS: Use the "Network Link Conditioner" tool to create packet loss profiles

3. A/B Testing: Compare call quality with and without RED under identical network conditions to hear the difference

This testing is essential to validate that your RED implementation is actually providing the expected benefits in degraded network conditions.

Conclusion

In this lesson, you learned about RTP, a real-time transport protocol for video and audio, and RED, an addition to RTP that allows for redundancy and more reliable data in bad network conditions. While RED increases bandwidth usage, it significantly improves audio quality in challenging network environments by providing fallback data when primary packets are lost.

Understanding when and how to implement RED is an important skill for WebRTC developers working on applications where audio quality is paramount. By carefully balancing the trade-offs between bandwidth usage and improved reliability, you can create real-time communication experiences that remain robust even in less-than-ideal network conditions.

Additional Resources

• RFC 2198: RTP Payload for Redundant Audio Data
• WebRTC Glossary: Jitter Buffer
• Understanding WebRTC Codecs
• SFU Architecture in WebRTC
• WebRTC Insertable Streams API
• WebRTC Statistics API