Guidelines for Combining Opus In-Band Forward Error Correction with the RTP Generic FEC (ULPFEC) Payload Format

Internet-Draft	Opus In-Band FEC with ULPFEC	October 2026
Oancea	Expires 28 April 2027	[Page]

Abstract

The Opus codec can carry low-bitrate redundancy for the preceding frame inside each packet ("in-band FEC"). The RTP payload format for generic Forward Error Correction (RFC 5109, commonly called ULPFEC) protects groups of RTP packets with XOR parity packets. The two mechanisms recover different loss patterns, have different delay and overhead characteristics, and interact in ways that are not described in either specification.¶

This document gives informational guidance on when the combination is worthwhile, how a sender should configure each mechanism, how a receiver should order recovery, how to signal the combination in SDP, how middleboxes affect it, and how to keep the combined redundancy consistent with congestion control. It complements, and does not change, the WebRTC FEC requirements in RFC 8854. It defines no new protocol elements.¶

1. Introduction

Packet loss on the path between an audio sender and receiver can be repaired in several ways: retransmission [RFC4588], redundant encoding [RFC2198], codec-internal redundancy, and separate parity-based FEC streams such as [RFC5109] and [RFC8627]. For Opus [RFC6716], the codec-internal mechanism is the Low-Bit-Rate Redundancy (LBRR) of the SILK layer, which RTP usage [RFC7587] refers to as "in-band FEC".¶

In-band FEC and ULPFEC are complementary. In-band FEC adds at most one packet of delay and can be decoded from a single received packet, but it can only repair the frame immediately preceding a received packet, it is not available in every Opus mode, and it yields a lower-fidelity reconstruction. ULPFEC reconstructs lost RTP packets bit-exactly, independent of the codec and mode, and can be arranged to cover bursts, but it adds delay proportional to the size of the protected group, and its overhead does not shrink with the codec's own bitrate decisions.¶

Neither [RFC7587] nor [RFC5109] discusses using the two together, and [RFC8854] (which targets WebRTC) recommends Opus in-band FEC for audio and does not recommend a separate FEC stream for audio because of its overhead. That recommendation remains appropriate for typical interactive WebRTC calls. There are, however, deployments where the assumptions behind it do not hold: music or other content coded in Opus modes without LBRR, links with frequent burst loss, one-way or latency-tolerant distribution, multicast without a feedback path, and systems that must recover RTP header extensions or contributing-source lists along with the payload. This document describes how to combine the mechanisms well in those deployments.¶

1.1. Scope

This document is informational. It does not update [RFC5109], [RFC7587], or [RFC8854], and it defines no new RTP payload formats, SDP attributes, or media type parameters. Where this document uses requirement language, it describes good practice for implementations that choose to combine the two mechanisms; it does not impose requirements on implementations that do not.¶

Flexible FEC [RFC8627] provides a superset of ULPFEC's capabilities and most of the guidance here applies to it equally. This document concentrates on ULPFEC because it is widely implemented and because [RFC5109] is the format named in many existing deployments. The Opus Deep Redundancy (DRED) extension under development in the MLCODEC Working Group [I-D.ietf-mlcodec-opus-dred] is discussed in Section 11.¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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.¶

In-band FEC:: The Opus LBRR mechanism [RFC6716], in which an Opus packet carries a lower-bitrate re-encoding of the audio of the previous packet, as signalled by the "useinbandfec" media type parameter [RFC7587].¶
ULPFEC:: The RTP payload format for generic forward error correction [RFC5109], including its uneven level protection (ULP) extension.¶
Media packet:: An RTP packet carrying an Opus payload.¶
FEC packet:: An RTP packet, or a RED block [RFC2198], carrying ULPFEC data.¶
Protection group:: The set of media packets covered by one ULPFEC level of one FEC packet, as identified by its mask. The group size is denoted k.¶
Pre-repair loss:: The fraction of media packets not received from the network.¶
Residual (post-repair) loss:: The fraction of media packets that could not be reconstructed by either mechanism and therefore required packet loss concealment.¶

3. Background

3.1. Opus In-Band FEC

Opus operates in SILK-only, Hybrid, and CELT-only modes [RFC6716]. LBRR frames are a SILK-layer feature, so in-band FEC is only available in SILK-only and Hybrid modes. Audio coded in CELT-only mode, which encoders commonly select for music and for high bitrates, carries no in-band redundancy.¶

When enabled, an Opus packet can carry an LBRR re-encoding of the SILK frames of the previous packet. A decoder that has lost packet N but received packet N+1 can decode the LBRR data in packet N+1 instead of concealing the loss. The decision to include LBRR data is made entirely by the encoder [RFC7587]; in the reference implementation it depends on the application enabling in-band FEC and on the expected packet loss rate configured by the application. A receiver indicates that it can make use of in-band FEC with "useinbandfec=1" [RFC7587]; the default is 0, and [RFC8854] requires WebRTC receivers that can use incoming FEC to signal it.¶

Two properties matter for the combination:¶

In-band FEC can only repair a loss whose following packet arrives. Two consecutive losses leave the first one unrepairable by LBRR. [RFC8854] notes this limitation and reports an overhead of roughly 20-30% when it is active.¶
Because LBRR data is inside the Opus payload, it travels with the payload through any RTP element that forwards the payload unchanged, including encryption with SRTP [RFC3711] or end-to-end encryption with SFrame [RFC9605].¶

3.2. ULPFEC

An ULPFEC packet carries a 10-octet FEC header and one or more level headers, each with a protection length and a 16- or 48-bit mask selecting the protected media packets relative to a base sequence number [RFC5109]. The FEC data is the XOR of the protected packets' RTP header fields and of the octets following the fixed 12-octet RTP header, which include any CSRC list, header extension, and payload. If exactly one packet of a protection group is missing, it can be reconstructed exactly, including its marker bit, timestamp, CSRCs, and header extensions. RED-based redundancy [RFC2198] cannot recover these header elements [RFC8854].¶

[RFC5109] allows FEC to be sent either as a separate stream with the same SSRC as the protected stream, in which case it recommends a separate RTP session, or as a secondary encoding inside RED. The registered media type audio/ulpfec has a required "rate" parameter; matching the protected media's clock rate, 48000 for Opus [RFC7587], is recommended.¶

3.3. Comparison

Table 1: Properties of the Two Mechanisms for Opus Audio
Property	Opus in-band FEC	ULPFEC
Losses repaired	Single loss followed by a received packet	One loss per protection group per level; bursts if interleaved
Added receiver delay	One packet duration	Up to the time span of the protection group
Fidelity of repair	Lower-bitrate approximation	Bit-exact packet, including header extensions
Opus modes	SILK-only and Hybrid	All
Overhead	Chosen per packet by the encoder	About 1/k of the largest protected packet, plus headers
Survives payload-preserving forwarding	Yes	Only if sequence numbers and headers are preserved (Section 8)
Signalling	"useinbandfec" parameter	Separate payload type, and session or RED configuration

4. When the Combination Is Worthwhile

For interactive, unicast calls with isolated losses, Opus in-band FEC alone (optionally supplemented with RED as recommended by [RFC8854]) is usually the better trade-off, and senders SHOULD NOT add ULPFEC for audio in that case. The combination is worth considering when one or more of the following holds:¶

Content without LBRR. The encoder is expected to use CELT-only mode for significant periods (for example, music or high-bitrate full-band audio), so in-band FEC provides no protection. ULPFEC then protects those periods, and in-band FEC continues to protect speech periods at lower cost.¶
Burst loss. Measured losses often occur in runs of two or more packets (for example, on wireless or satellite links). LBRR alone cannot repair the first loss of a run; ULPFEC with an interleaved mask can, and a packet recovered by ULPFEC can in turn supply LBRR data for its predecessor (Appendix B).¶
Latency tolerance. The application's delay budget can absorb the span of a protection group, as in one-way distribution, broadcast contribution, or announcements. Larger groups lower the overhead.¶
No feedback path. Multicast or unidirectional delivery rules out retransmission [RFC4588].¶
Header recovery. The receiver depends on information carried in RTP header extensions or CSRC lists, such as audio level indications [RFC6464], which in-band FEC and RED cannot restore.¶

If none of these holds, the added overhead and delay of ULPFEC are unlikely to be justified for Opus audio.¶

5. Sender Guidance

5.1. Enabling and Adapting Each Mechanism

As [RFC8854] recommends, FEC should only be activated when network conditions warrant it. A sender combining the mechanisms SHOULD adapt them independently:¶

In-band FEC is cheap to adapt because the encoder decides per packet. The sender typically provides the encoder with an expected loss rate. When ULPFEC is active, the loss that the Opus decoder experiences is the residual loss after ULPFEC recovery, not the network loss. Configuring the encoder with the pre-repair loss rate will over-provision LBRR. Where a post-repair loss estimate is available (Section 10), the sender SHOULD base the encoder's expected loss rate on it.¶
ULPFEC should be enabled only when the observed loss pattern matches one of the conditions in Section 4, and disabled when loss subsides. Its group size and mask are the main levers (Section 5.2).¶

A sender SHOULD NOT send ULPFEC to a receiver that has not accepted the ULPFEC payload type in the offer/answer exchange [RFC3264], and SHOULD NOT include in-band FEC data for a receiver that signalled "useinbandfec=0" unless it has other reasons to do so. Any compliant Opus decoder ignores in-band FEC data it does not need [RFC7587], so this is an efficiency concern, not an interoperability one.¶

5.2. ULPFEC Parameters for Opus

The following considerations apply when choosing ULPFEC parameters for an Opus stream:¶

Use a single, full-length level. ULP allows lower levels to protect only the first octets of each packet. An Opus packet is entropy-coded, and a partially recovered Opus packet is generally not decodable, so protecting only a prefix of the payload gives little benefit. The protection length SHOULD cover the longest protected packet, and a single level is usually sufficient (see the "onelevelonly" parameter in [RFC5109]).¶
Size the group to the delay budget. A missing packet can only be reconstructed after the last packet of its group and the FEC packet have arrived. With 20 ms packets and consecutive masks, a group of k=4 spans about 80 ms, and an interleaved arrangement that covers every second packet across eight packets spans about 160 ms. For two-way conversation, the total one-way delay should stay within the guidance of [G.114]; a small k (2 to 4) with consecutive masks is typically the limit. Latency-tolerant applications can use larger k and interleaving.¶
Interleave for bursts. If losses commonly come in pairs, masks that protect alternate packets (two FEC packets per eight media packets, each covering every second packet) let each FEC packet repair one loss of a pair at the same overhead as consecutive groups of four.¶
Account for variable packet size. Opus is usually used in variable-bitrate mode, and LBRR data increases the size of the packets that carry it. An FEC packet must be as long as the longest packet it protects, so the actual overhead exceeds 1/k of the average media bitrate. Grouping packets of similar size, or using smaller groups when sizes vary widely, reduces this effect.¶
Avoid protecting redundancy twice without reason. ULPFEC protects the whole payload, including any LBRR data it contains. When ULPFEC is active and the loss pattern is mostly isolated losses, in-band FEC adds little and can be reduced; when the pattern is bursty, keeping both gives the largest benefit (Appendix B).¶

5.3. Bitrate Budget

The sender MUST keep the total of primary Opus bitrate, in-band FEC, ULPFEC, and packet headers within the rate allowed by its congestion controller (Section 9). When FEC is enabled or increased, the primary Opus bitrate should be reduced to make room for it, rather than adding FEC on top of a rate that already fills the allowed budget. The worked example in Appendix A shows that ULPFEC with k=4 adds about 27% to the on-the-wire rate of a 32 kbit/s Opus stream with in-band FEC, under the stated assumptions.¶

6. Receiver Guidance

6.1. Recovery Order

When media packet N is missing at its playout deadline, a receiver supporting both mechanisms SHOULD attempt recovery in the following order:¶

ULPFEC: if an FEC packet covering N and all other packets of its protection group have arrived (or been recovered), reconstruct N exactly and decode it normally.¶
In-band FEC: otherwise, if packet N+1 is available, whether received or reconstructed by ULPFEC, and contains LBRR data, decode the in-band FEC data from N+1 to produce audio for N.¶
Concealment: otherwise, apply the Opus decoder's packet loss concealment.¶

ULPFEC recovery comes first because it produces the original packet and restores its header information. Receivers SHOULD run ULPFEC recovery iteratively: a packet recovered from one FEC packet can complete another protection group or provide the N+1 packet needed for in-band FEC.¶

6.2. Jitter Buffer Interaction

ULPFEC only helps if the jitter buffer holds missing packets' slots long enough for the FEC packet to arrive. An adaptive jitter buffer that targets a delay shorter than the protection group's span will rarely benefit from ULPFEC and still pays its overhead. Receivers SHOULD take the signalled or observed protection span into account when choosing a target delay, or report to the application that ULPFEC is ineffective at the current delay so that the sender can be asked to reduce k. In-band FEC needs only one packet duration of additional delay.¶

A packet that is reconstructed by ULPFEC and later arrives late from the network is a duplicate. Receivers MUST discard such duplicates and MUST NOT decode the same audio twice from LBRR data and from a recovered or late packet.¶

6.3. Loss Accounting

Receivers should keep separate counts of packets lost before repair, packets recovered by ULPFEC, losses covered by in-band FEC, and losses concealed. Pre-repair counts are the input to congestion control (Section 9); post-repair counts are the input to FEC adaptation (Section 5.1). RTCP receiver reports [RFC3550] are conventionally computed from packets received from the network, before repair.¶

7. Signalling

The combination needs no new signalling. Opus in-band FEC is indicated with "useinbandfec" [RFC7587]; ULPFEC is negotiated as its own payload type [RFC5109]. Two configurations are possible.¶

7.1. ULPFEC Inside RED

When media is multiplexed with BUNDLE [RFC9143], a separate RTP session for FEC is not available. ULPFEC can instead be carried as a secondary encoding inside RED [RFC2198], as allowed by [RFC5109]. The RED encapsulation then carries the Opus primary block in every packet and an ULPFEC block in the packets the sender chooses. The following SDP fragment offers this configuration:¶

m=audio 9 UDP/TLS/RTP/SAVPF 111 63 100
c=IN IP4 0.0.0.0
a=mid:a0
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/100
a=rtpmap:100 ulpfec/48000

In this configuration, implementers should be aware that RED adds a per-block header, and that peers which support RED for audio do not necessarily support ULPFEC as a RED secondary encoding for audio. An answerer that does not support it removes payload type 100 from its answer, and the sender then uses in-band FEC (and RED redundancy, if negotiated) alone.¶

7.2. ULPFEC as a Separate Session

Outside WebRTC, ULPFEC can be sent in its own RTP session, as recommended by [RFC5109], and associated with the media session using the FEC-FR grouping semantics of [RFC5956]. The FEC stream uses the same SSRC as the media stream. [RFC8854] advises against offering FEC-only "m=" lines in WebRTC; the example below is intended for other environments such as SIP-based or broadcast systems.¶

v=0
o=- 4858251974351650128 1 IN IP4 192.0.2.10
s=-
c=IN IP4 192.0.2.10
t=0 0
a=group:FEC-FR m1 m2
m=audio 49170 RTP/AVP 111
a=mid:m1
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1;maxaveragebitrate=32000
m=audio 49172 RTP/AVP 100
a=mid:m2
a=rtpmap:100 ulpfec/48000

The "maxaveragebitrate" parameter limits the average bitrate of the Opus stream [RFC7587]. It does not cover the separate FEC stream, so the sender must still account for ULPFEC in its overall budget (Section 5.3).¶

8. Middleboxes

RTP topologies [RFC7667] affect the two mechanisms differently:¶

Selective forwarding units (SFUs). An SFU that forwards Opus payloads unchanged preserves in-band FEC. ULPFEC, however, protects the RTP sequence number, timestamp, marker bit, and header extensions, and its base sequence number refers to the original numbering. An SFU that rewrites sequence numbers or SSRCs, drops packets for a given receiver, or adds or removes header extensions MUST NOT forward the original ULPFEC packets unchanged, because receivers would reconstruct incorrect packets. Such an SFU should terminate ULPFEC from the sender (using it to repair losses on the uplink) and, if useful, generate new ULPFEC per downstream receiver based on that receiver's loss conditions.¶
Mixers. A mixer that decodes, mixes, and re-encodes terminates both mechanisms. It should apply recovery on each input as in Section 6.1 before mixing, and choose redundancy for each output independently.¶
End-to-end encryption. With SFrame [RFC9605], the Opus payload, including LBRR data, is opaque to the SFU. Because ULPFEC is an XOR over octets, an SFU can still generate and apply ULPFEC over the encrypted payloads on each hop without access to the media keys.¶

9. Congestion Control Considerations

FEC must not hide congestion. [RFC9265] recommends that, from a congestion control standpoint, a packet recovered by FEC be treated as lost. [RFC5109] requires that implementations not substantially increase total bandwidth as losses increase, and [RFC8854] notes that redundancy sent during congestion reduces the bandwidth available for the primary encoding and can make losses worse. For the combination, this means:¶

Congestion control MUST be driven by pre-repair loss and delay signals, not by residual loss after ULPFEC and in-band FEC.¶
The combined rate of Opus (including LBRR), ULPFEC, and headers MUST stay within the allowed sending rate. Under congestion, the sender should reduce the total rate first and then divide what remains between primary coding and redundancy; increasing redundancy in response to congestion-induced loss is counter-productive.¶
Applications using RTP over UDP remain subject to the congestion control expectations of [RFC7587] and [RFC8085], and to RTP circuit breakers [RFC8083], which apply to the combined media and FEC traffic.¶

Using [RFC9265]'s classification, both mechanisms as described here operate above the transport, within the rate given to the application by its congestion controller.¶

13. Security Considerations

Neither in-band FEC nor ULPFEC provides any security. The security considerations of [RFC6716], [RFC7587], and [RFC5109] apply. In particular:¶

When SRTP [RFC3711] is used, FEC packets SHOULD receive the same confidentiality and integrity protection as the media packets. An attacker able to inject or modify unauthenticated FEC packets can cause a receiver to reconstruct incorrect packets. Receivers should apply sanity checks, such as length and timestamp plausibility, to recovered packets, as [RFC5109] advises.¶
FEC recovery consumes receiver processing. Large or numerous FEC packets, including ones that can never complete a group, can be used to increase receiver load; receivers should bound the processing and memory devoted to pending protection groups.¶
Variable bitrate audio can leak information about the content of encrypted speech through packet sizes [RFC6562]. Whether the encoder includes LBRR data in a packet is itself signal-dependent and so affects packet size. ULPFEC packet sizes follow the largest packet of each group. Deployments concerned with this leakage should follow the guidance of [RFC6562], for example by using constant bitrate coding, and should not assume that FEC traffic hides the pattern.¶

14. References

14.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2198]: Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, <https://www.rfc-editor.org/info/rfc2198>.
[RFC3550]: Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC5109]: Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC6716]: Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <https://www.rfc-editor.org/info/rfc6716>.
[RFC7587]: Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, <https://www.rfc-editor.org/info/rfc7587>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

14.2. Informative References

[G.114]: ITU-T, "One-way transmission time", ITU-T Recommendation G.114, May 2003.
[I-D.ietf-mlcodec-opus-dred]: Valin, J. and J. Buethe, "Deep Audio Redundancy (DRED) Extension for the Opus Codec", Work in Progress, Internet-Draft, draft-ietf-mlcodec-opus-dred-07, 4 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-mlcodec-opus-dred-07>. Work in Progress.
[RFC3264]: Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3711]: Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC4588]: Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC5725]: Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 2010, <https://www.rfc-editor.org/info/rfc5725>.
[RFC5956]: Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, <https://www.rfc-editor.org/info/rfc5956>.
[RFC6464]: Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, <https://www.rfc-editor.org/info/rfc6464>.
[RFC6562]: Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, <https://www.rfc-editor.org/info/rfc6562>.
[RFC7509]: Huang, R. and V. Singh, "RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics", RFC 7509, DOI 10.17487/RFC7509, May 2015, <https://www.rfc-editor.org/info/rfc7509>.
[RFC7667]: Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC8083]: Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8085]: Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8627]: Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, <https://www.rfc-editor.org/info/rfc8627>.
[RFC8854]: Uberti, J., "WebRTC Forward Error Correction Requirements", RFC 8854, DOI 10.17487/RFC8854, January 2021, <https://www.rfc-editor.org/info/rfc8854>.
[RFC9143]: Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, February 2022, <https://www.rfc-editor.org/info/rfc9143>.
[RFC9265]: Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward Erasure Correction (FEC) Coding and Congestion Control in Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022, <https://www.rfc-editor.org/info/rfc9265>.
[RFC9605]: Omara, E., Uberti, J., Murillo, S. G., Barnes, R., Ed., and Y. Fablet, "Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media", RFC 9605, DOI 10.17487/RFC9605, August 2024, <https://www.rfc-editor.org/info/rfc9605>.

Appendix A. Worked Overhead Example

This example illustrates the bitrate cost of each mechanism for a single stream. Assumptions: Opus at 32 kbit/s with 20 ms packets (80 octets of payload per packet, 50 packets per second); in-band FEC adding 25% to the payload when active (20 octets), the midpoint of the range reported in [RFC8854]; IPv4 and UDP headers (28 octets), RTP fixed header (12 octets), and a 10-octet SRTP authentication tag; ULPFEC sent as a separate stream with one FEC packet per four media packets (k=4), one 4-octet level header, and a protection length equal to the 100-octet media payload.¶

Table 2: Illustrative On-the-Wire Bitrates
Configuration	Packet size (octets)	Packets/s	Rate (kbit/s)
Opus only	130	50	52.0
Opus with in-band FEC	150	50	60.0
ULPFEC stream, k=4	164	12.5	16.4
Opus with in-band FEC and ULPFEC, k=4	-	62.5	76.4

With k=2 the ULPFEC stream would cost 32.8 kbit/s, bringing the total to 92.8 kbit/s. Real overhead depends on Opus packet-size variation (Section 5.2), on IPv6 (20 additional octets per packet), and on RED encapsulation if used.¶

Appendix B. Illustrative Residual Loss

The following table gives residual loss from a simple simulation, to show the qualitative behaviour of each mechanism. It is not a performance claim. Assumptions: 20 ms packets; in-band FEC present in every media packet and able to repair packet N whenever packet N+1 is available; ULPFEC with one FEC packet per four media packets, either consecutive (k=4) or interleaved (two FEC packets per eight media packets, each covering every second packet); FEC packets subject to the same loss process as media packets; losses generated by a two-state Gilbert model with the stated average loss and mean burst length, where a mean burst length of 1 means independent losses; 400,000 media packets per run. Receivers apply ULPFEC first and then in-band FEC, as in Section 6.1. Values are residual loss in percent.¶

Table 3: Simulated Residual Loss (%)
Mean burst	Network loss	None	In-band FEC	ULPFEC k=4	Both, k=4	ULPFEC interleaved	Both, interleaved
1	2%	1.99	0.04	0.15	0.03	0.15	0.00
1	5%	4.97	0.24	0.92	0.18	0.93	0.01
1	10%	9.98	0.99	3.39	0.77	3.43	0.12
1	20%	20.04	4.02	11.81	3.35	11.90	1.38
2	2%	1.96	0.97	1.35	0.78	0.81	0.33
2	5%	5.02	2.49	3.53	2.03	2.27	0.89
2	10%	9.92	4.93	7.22	4.07	5.16	1.99
2	20%	19.91	9.92	15.33	8.37	12.96	5.08

Under these assumptions, in-band FEC alone is very effective against independent losses, and adding consecutive ULPFEC improves on it only modestly; interleaving helps even here, because two adjacent losses then fall into different protection groups. With bursts, in-band FEC alone halves the loss at best, while interleaved ULPFEC combined with in-band FEC reduces it several-fold, because ULPFEC breaks up bursts and the packets it recovers then supply LBRR data for their predecessors. The interleaved arrangement doubles the recovery delay (Section 5.2). Real in-band FEC is not present in every packet, is absent in CELT-only mode, and repairs at lower fidelity, so measurements with real encoders and loss traces are needed before drawing quantitative conclusions.¶