Summary

  • RFC 5109's Uneven Level Protection gives every level its own packet mask and protection length. One level can be solvable while another remains incomplete.
  • “FEC packet received”, “critical prefix reconstructed”, “whole packet recovered”, “decoder accepted” and “played on time” are five different receipts.

The green counter that was too broad

Suppose an RTP receiver is missing one video packet. It has a ULPFEC packet whose level 0 covers the missing packet and several neighbours. All other operands needed for that level are present. XOR reconstruction restores the RTP recovery fields and a protected prefix. The receiver can now know the packet's total length, because length recovery belongs to the level-0 operation. It can also compare that length with the bytes it has actually reconstructed.

That comparison may show a gap. A higher level may cover the packet's later bytes across a larger group, and two media packets in that group may be missing. The level-0 equation is solvable; the higher-level equation is not. The beginning exists, the tail does not. Calling the event “packet recovered” removes the most decision-relevant fact: recovery stopped at a level boundary.

RFC 5109 does not hide this state. It says lost payload packets may be recovered in full or in part and tells the receiver to detect partial recovery by comparing the recovered total length with the amount of payload data actually rebuilt. That is not a minor implementation note. It is the accounting boundary of the protocol.

Protection is geometry, not a switch

Uneven Level Protection starts from a media property: different portions of a packet can have different importance. The sender divides protected data into levels. Each level is an independent parity operation, even when several levels travel in one FEC packet. Stronger protection can be placed near the beginning of a packet, where headers or more consequential codec material often reside, while later bytes receive weaker protection.

Each FEC level header carries two decisive values. Protection Length says how many octets the level covers. A 16-bit or 48-bit mask says which media sequence numbers enter that level's equation, relative to the FEC header's sequence-number base. A set bit at position i associates media packet N+i with that level. The mask names operands; the length names the byte surface. Neither promises that the receiver possesses the remaining operands.

The levels are nested by rule. If a media packet is protected at level p, it must also be protected at level p-1. A FEC packet carrying level p must carry the preceding level too. Yet the packet groups may differ by level, and a packet's level p may appear in a different FEC packet from its level p-1. There is no single “FEC coverage” bit that faithfully describes this arrangement.

The lower level can use a smaller packet group and therefore survive a loss pattern that defeats the larger higher-level group. This is how a critical prefix can be available while a less-protected suffix remains unknown. It is also why dashboards that count FEC packets or recovered sequence numbers without recording level and byte coverage cannot distinguish a useful partial recovery from a complete one.

Packet selection comes before byte reconstruction

RFC 5109 separates recovery into two operations. First, the implementation decides which media and FEC packets can be combined to recover a missing packet. The RFC permits different algorithms for this choice because complexity and recovery opportunity trade against each other. Second, once the set is chosen, the implementation follows the specified XOR reconstruction procedure.

This division creates two independent failure surfaces. A receiver can have enough information in principle but fail to discover a useful combination within its compute or timing budget. Or it can choose a candidate set whose level still contains more than one unknown. Conversely, a successful selection for level 0 says nothing about the solvability of level 1.

For header reconstruction, recovery fields rebuild the RTP header through the SSRC boundary; the media-stream association supplies SSRC. For payload level n, the receiver reads that level's protection length, constructs the protected bit strings at the level's offset, pads short operands with zero octets, XORs the strings, and places the result at the correct position. Results from multiple levels are concatenated. The length recovered at level 0 is then the test for whether all reconstructed levels reach the full packet length.

An evidence system should therefore retain the selected operands, the level, the mask, the protection length, the number of unknowns before and after reconstruction, the recovered-byte interval and the full-length comparison. A single integer called fec_recovered_packets cannot answer what was actually recovered.

Compatible media can conceal unused protection

RFC 5109 leaves the original media packet format unchanged when FEC is sent as a separate stream. A receiver that does not understand the protection can ignore it and continue to consume ordinary media. In offer/answer, an answerer may reject the separate FEC session while accepting the media session. This is useful interoperability, but it defeats a common inference: successful playback by a receiver does not demonstrate ULPFEC capability or use.

The protection can travel in a separate RTP session or as a secondary codec in RFC 2198 redundant encoding. For a separate stream, out-of-band configuration must state the address and port, dynamic payload type and protected media stream. The FEC and media association is not recoverable from a payload-type number alone. Their sequence spaces, transport fate and resource treatment may differ.

Evidence must record what was offered, what was answered, which association generation was active, which stream actually arrived and which repair data the receiver used. “Media was visible” is consistent with four very different situations: no loss occurred; loss occurred but did not matter; FEC recovered useful bytes; or concealment hid an unrecovered gap.

Reconstructed bytes still require distrust

Parity is not authentication. RFC 5109 warns that changing FEC bits can change the reconstructed result, make the recovered length implausibly large or increase recovery work by at least an order of magnitude. It recommends sanity checking received media and FEC before reconstruction and validating recovered data before use.

The security receipt therefore cannot stop at a successful XOR. The implementation needs integrity and policy context for the media and FEC streams, especially when they are separate. It must know which key generation applies, whether a stream association is current, whether recovered lengths and offsets stay within bounds, and whether the output satisfies codec and application validation. A malicious or merely corrupted equation can be perfectly solvable and still yield data that should never enter a decoder.

The same restraint applies to service evidence. ULP tends to leave a contiguous missing tail rather than scattered holes, and some codecs may extract useful data from such a prefix. “May” is doing real work. The RFC does not establish that every protected media format treats the prefix as independently decodeable, that concealment is acceptable, or that the result arrives before playout.

Repair bandwidth can join the loss

FEC converts bandwidth into loss tolerance. More FEC packets relative to media generally strengthen protection and also consume more capacity. If rising loss reflects congestion, blindly adding redundancy can worsen the bottleneck. RFC 5109 therefore says implementations must not substantially increase total media-plus-FEC bandwidth as network loss rises, and best-effort users must monitor loss.

This prevents a protection metric from standing alone. A change from one level to several, from a short group to repeated level-0 protection, or from lower to higher redundancy should be correlated with total rate, payload-rate reduction, queue loss, delay and receiver outcomes. A higher protection ratio that coincides with later playout or more congestion is not automatically an improvement.

What the standard does and does not establish

RFC 5109 was published on the Standards Track in December 2007. It obsoleted RFC 2733 and RFC 3009, repaired RTP-header inconsistencies and added unequal protection. Its protection payload is not backward compatible with those earlier formats, although unchanged media can still cross a mixed-capability population. That status defines a protocol contract; it does not prove adoption, deployment quality or current prevalence.

The scheme is bounded. Its mask covers up to 48 packet offsets. It uses XOR parity. It can adapt parameters in-band and can carry several protection levels. None of those facts supplies a named encoder, receiver population, real loss trace, recovery percentage, decoder result or audience experience. Those require separate sources.

The disciplined claim is narrower and more useful: RFC 5109 gives operators enough structure to say which bytes were intended to be protected at which level, and enough procedure to decide whether reconstructed coverage reached the original packet length. It does not authorize the system to promote an equation receipt into a service result.

Sources