RED stands for REDundant coding and it is a RTP payload format defined in RFC 2198 for encoding redundant audio or video data.
The primary motivation of sending redundant data is to be able to recover packets lost under lossy network conditions. If a packet is lost then the missing information may be reconstructed at the receiver from the redundant data that arrives in the following packet(s).
The use of RED is negotiated in the SDP as an additional payload type and when used the audio/video RTP packets are packaged using RED format with a 6 bytes header, before the primary and secondary payloads conveying the actual audio/video packet and the redundant information.
An example of a redundant information schema is ULPFEC.
See also FEC.
The Role of RED in WebRTC
In the context of WebRTC, RED can be used to increase audio resiliency to packet loss. For many years, WebRTC relied on the internal forward error correction built into Opus to supply its packet loss resiliency. While the results were fine, they weren’t great. To improve on this, developers have sought out to use RED as a secondary mechanism, beefing up resiliency.
There are two opposing opinions here:
- FEC needs to be done in an intelligent way, using as little extra bitrate as possible
- “Brute force” solutions such as RED are useful even of expensive in bitrate
Due to this, WebRTC doesn’t really support RED “out of the box”, but rather enables implementers to add it through the use of media servers and Insertable Streams. Those adopting RED do so with an understanding that it doubles or triples the bitrate the audio bitrate – which is still quite low compared to the bitrate requirements of the video stream in a video call.
