The following section provides guidance on how to best use FEC for transmitting audio data. As indicated in Section 8
below, FEC should only be activated if network conditions warrant it, or upon explicit application request.
When using variable-bitrate codecs without an internal FEC, redundant encoding (as described in Section 3.2
) with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED
. This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding.
When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED
. This provides reasonable protection of the audio stream against individual losses, with minimal overhead. Note that, as indicated above, the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned redundant encoding with reduced-bitrate Opus encodings SHOULD
be used instead.
When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED
. This provides slightly more efficient protection of the audio stream than redundant encoding does.
When using constant-bitrate codecs, e.g., PCMU [RFC 5391
], redundant encoding MAY
be used, but this will result in a potentially significant bitrate increase, and suddenly increasing bitrate to deal with losses from congestion may actually make things worse.
Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED
As mentioned above, the recommended mechanisms do not allow recovery of parts of the RTP header that may be important in certain audio applications, e.g., CSRCs and RTP header extensions like those specified in [RFC 6464
] and [RFC 6465
]. Implementations SHOULD
account for this and attempt to approximate this information, using an approach similar to those described in RFC 2198
, Section 4
, and RFC 6464
, Section 5
Support for redundant encoding of a given RTP stream SHOULD
be indicated by including audio/red [RFC 2198
] as an additional supported media type for the associated "m=" section in the SDP offer [RFC 3264
]. Answerers can reject the use of redundant encoding by not including the audio/red media type in the corresponding "m=" section in the SDP answer.
Support for codec-specific FEC mechanisms are typically indicated via "a=fmtp" parameters.
For Opus, a receiver MUST
indicate that it is prepared to use incoming FEC data with the "useinbandfec=1" parameter, as specified in [RFC 7587
]. This parameter is declarative and can be negotiated separately for either media direction.
For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the "max-red" parameter, as specified in RFC 4867
, Section 8.1
. Receivers MUST
include this parameter, and set it to an appropriate value, as specified in [TS.26114
], Table 6.3.