WebRTC Forward Error Correction Requirements
RFC 8854

Document Type RFC - Proposed Standard (January 2021; No errata)
Author Justin Uberti 
Last updated 2021-01-19
Replaces draft-uberti-rtcweb-fec
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Ted Hardie
Shepherd write-up Show (last changed 2018-01-08)
IESG IESG state RFC 8854 (Proposed Standard)
Action Holders
Consensus Boilerplate Yes
Telechat date
Responsible AD Adam Roach
Send notices to "Ted Hardie" <ted.ietf@gmail.com>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                         J. Uberti
Request for Comments: 8854                                        Google
Category: Standards Track                                   January 2021
ISSN: 2070-1721

              WebRTC Forward Error Correction Requirements


   This document provides information and requirements for the use of
   Forward Error Correction (FEC) by WebRTC implementations.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Types of FEC
     3.1.  Separate FEC Stream
     3.2.  Redundant Encoding
     3.3.  Codec-Specific In-Band FEC
   4.  FEC for Audio Content
     4.1.  Recommended Mechanism
     4.2.  Negotiating Support
   5.  FEC for Video Content
     5.1.  Recommended Mechanism
     5.2.  Negotiating Support
   6.  FEC for Application Content
   7.  Implementation Requirements
   8.  Adaptive Use of FEC
   9.  Security Considerations
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Author's Address

1.  Introduction

   In situations where packet loss is high, or perfect media quality is
   essential, Forward Error Correction (FEC) can be used to proactively
   recover from packet losses.  This specification provides guidance on
   which FEC mechanisms to use, and how to use them, for WebRTC

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Types of FEC

   FEC describes the sending of redundant information in an outgoing
   packet stream so that information can still be recovered even in the
   event of packet loss.  There are multiple ways this can be
   accomplished for RTP media streams [RFC3550]; this section enumerates
   the various mechanisms available and describes their trade-offs.

3.1.  Separate FEC Stream

   This approach, as described in [RFC5956], Section 4.3, sends FEC
   packets as an independent RTP stream with its own synchronization
   source (SSRC) [RFC3550] and payload type, multiplexed with the
   primary encoding.  While this approach can protect multiple packets
   of the primary encoding with a single FEC packet, each FEC packet
   will have its own IP/UDP/RTP/FEC header, and this overhead can be
   excessive in some cases, e.g., when protecting each primary packet
   with a FEC packet.

   This approach allows for recovery of entire RTP packets, including
   the full RTP header.

3.2.  Redundant Encoding

   This approach, as described in [RFC2198], allows for redundant data
   to be piggybacked on an existing primary encoding, all in a single
   packet.  This redundant data may be an exact copy of a previous
   payload, or for codecs that support variable-bitrate encodings, the
   redundant data may possibly be a smaller, lower-quality
   representation.  In certain cases, the redundant data could include
   encodings of multiple prior audio frames.

   Since there is only a single set of packet headers, this approach
   allows for a very efficient representation of primary and redundant
   data.  However, this savings is only realized when the data all fits
   into a single packet (i.e. the size is less than a MTU).  As a
   result, this approach is generally not useful for video content.

   As described in [RFC2198], Section 4, this approach cannot recover
   certain parts of the RTP header, including the marker bit,
   contributing source (CSRC) information, and header extensions.
Show full document text