Audio/Video Transport Core Maintenance D. Oancea Internet-Draft 25 October 2026 Intended status: Informational Expires: 28 April 2027 Guidelines for Combining Opus In-Band Forward Error Correction with the RTP Generic FEC (ULPFEC) Payload Format draft-oancea-avtcore-opus-ulpfec-00 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. About This Document This note is to be removed before publishing as an RFC. Discussion of this document is expected to take place on the AVTCORE Working Group mailing list (avt@ietf.org). This is an individual submission and has not been adopted by any working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Oancea Expires 28 April 2027 [Page 1] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 April 2027. Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Opus In-Band FEC . . . . . . . . . . . . . . . . . . . . 5 3.2. ULPFEC . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 6 4. When the Combination Is Worthwhile . . . . . . . . . . . . . 7 5. Sender Guidance . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Enabling and Adapting Each Mechanism . . . . . . . . . . 7 5.2. ULPFEC Parameters for Opus . . . . . . . . . . . . . . . 8 5.3. Bitrate Budget . . . . . . . . . . . . . . . . . . . . . 9 6. Receiver Guidance . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Recovery Order . . . . . . . . . . . . . . . . . . . . . 9 6.2. Jitter Buffer Interaction . . . . . . . . . . . . . . . . 10 6.3. Loss Accounting . . . . . . . . . . . . . . . . . . . . . 10 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. ULPFEC Inside RED . . . . . . . . . . . . . . . . . . . . 10 7.2. ULPFEC as a Separate Session . . . . . . . . . . . . . . 11 8. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Congestion Control Considerations . . . . . . . . . . . . . . 12 10. Feedback and Measurement . . . . . . . . . . . . . . . . . . 13 11. Relationship to Opus Deep Redundancy (DRED) . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Oancea Expires 28 April 2027 [Page 2] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Worked Overhead Example . . . . . . . . . . . . . . 17 Appendix B. Illustrative Residual Loss . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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. Oancea Expires 28 April 2027 [Page 3] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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 Oancea Expires 28 April 2027 [Page 4] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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]. Oancea Expires 28 April 2027 [Page 5] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 [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 +====================+=================+=========================+ | Property | Opus in-band | ULPFEC | | | FEC | | +====================+=================+=========================+ | Losses repaired | Single loss | One loss per protection | | | followed by a | group per level; bursts | | | received packet | if interleaved | +--------------------+-----------------+-------------------------+ | Added receiver | One packet | Up to the time span of | | delay | duration | the protection group | +--------------------+-----------------+-------------------------+ | Fidelity of repair | Lower-bitrate | Bit-exact packet, | | | approximation | including header | | | | extensions | +--------------------+-----------------+-------------------------+ | Opus modes | SILK-only and | All | | | Hybrid | | +--------------------+-----------------+-------------------------+ | Overhead | Chosen per | About 1/k of the | | | packet by the | largest protected | | | encoder | packet, plus headers | +--------------------+-----------------+-------------------------+ | Survives payload- | Yes | Only if sequence | | preserving | | numbers and headers are | | forwarding | | preserved (Section 8) | +--------------------+-----------------+-------------------------+ | Signalling | "useinbandfec" | Separate payload type, | | | parameter | and session or RED | | | | configuration | +--------------------+-----------------+-------------------------+ Table 1: Properties of the Two Mechanisms for Opus Audio Oancea Expires 28 April 2027 [Page 6] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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: 1. *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. 2. *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). 3. *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. 4. *No feedback path.* Multicast or unidirectional delivery rules out retransmission [RFC4588]. 5. *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 Oancea Expires 28 April 2027 [Page 7] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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 Oancea Expires 28 April 2027 [Page 8] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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: 1. 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. 2. 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. 3. 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. Oancea Expires 28 April 2027 [Page 9] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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: Oancea Expires 28 April 2027 [Page 10] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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: Oancea Expires 28 April 2027 [Page 11] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 * *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. Oancea Expires 28 April 2027 [Page 12] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 Using [RFC9265]'s classification, both mechanisms as described here operate above the transport, within the rate given to the application by its congestion controller. 10. Feedback and Measurement Adapting the combination requires both pre-repair and post-repair loss information. Standard RTCP receiver reports provide the former. The latter can be conveyed with the RTCP Extended Report blocks for post-repair loss run-length encoding [RFC5725] or for post-repair loss counts [RFC7509]. A sender that receives these can tell whether ULPFEC is effective at the receiver's jitter buffer depth (Section 6.2) and can set the Opus encoder's expected loss rate from the residual loss (Section 5.1). Without post-repair feedback, the sender has to rely on models such as the one in Appendix B, which can be substantially wrong for real loss patterns. 11. Relationship to Opus Deep Redundancy (DRED) The MLCODEC Working Group is specifying a Deep Redundancy (DRED) extension for Opus [I-D.ietf-mlcodec-opus-dred]. DRED carries very low bitrate redundancy, covering up to a second or more of past audio, inside the Opus padding. When both peers support it, DRED addresses much of the burst-loss case for which this document suggests ULPFEC, at lower overhead. ULPFEC would remain relevant where bit-exact recovery, recovery of RTP header information, codec independence, or support for peers without DRED is needed. Guidance on combining DRED with ULPFEC, and with in-band FEC, is left for a future revision once the DRED specification is stable. 12. IANA Considerations This document has no IANA actions. 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. Oancea Expires 28 April 2027 [Page 13] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 * 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, . [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, . [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, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [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, . Oancea Expires 28 April 2027 [Page 14] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . 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, . [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, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [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, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . [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, . Oancea Expires 28 April 2027 [Page 15] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 [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, . [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, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [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, . [RFC8854] Uberti, J., "WebRTC Forward Error Correction Requirements", RFC 8854, DOI 10.17487/RFC8854, January 2021, . [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, . [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, . [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, . Oancea Expires 28 April 2027 [Page 16] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 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. +=====================+======================+===========+==========+ | Configuration | Packet size (octets) | Packets/ | Rate | | | | s | (kbit/s) | +=====================+======================+===========+==========+ | Opus only | 130 | 50 | 52.0 | +---------------------+----------------------+-----------+----------+ | Opus with in-band | 150 | 50 | 60.0 | | FEC | | | | +---------------------+----------------------+-----------+----------+ | ULPFEC stream, k=4 | 164 | 12.5 | 16.4 | +---------------------+----------------------+-----------+----------+ | Opus with in-band | - | 62.5 | 76.4 | | FEC and ULPFEC, k=4 | | | | +---------------------+----------------------+-----------+----------+ Table 2: Illustrative On-the-Wire Bitrates 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 Oancea Expires 28 April 2027 [Page 17] Internet-Draft Opus In-Band FEC with ULPFEC October 2026 percent. +=====+=======+=====+=======+======+=====+===========+=============+ |Mean |Network|None |In-band|ULPFEC|Both,|ULPFEC | Both, | |burst|loss | |FEC |k=4 |k=4 |interleaved| 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 | +-----+-------+-----+-------+------+-----+-----------+-------------+ Table 3: Simulated Residual Loss (%) 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. Acknowledgments This document builds on the analysis of FEC for WebRTC in [RFC8854] and on the FEC and congestion control guidance of [RFC9265]. Author's Address Dragos Oancea Email: dragos.oancea.3.141592@gmail.com Oancea Expires 28 April 2027 [Page 18]