Summary

  • RFC 3545 repeated changing context values across N+1 packets so that a decompressor could recover when a loss burst stayed within the assumed link bound.
  • Its optional HDRCKSUM helped check rebuilt headers when IPv4's UDP checksum was zero, but the checksum excluded IPv4 Identification; beyond N losses, the safer IPv4 action was to invalidate context and request state.

The check arrived with a blind spot. RFC 3545 let a compressor replace a zero IPv4 UDP checksum with a 16-bit header checksum, giving the decompressor a way to check a reconstructed header. But IPv4 Identification was not among the fields that checksum validated. In an ordinary good path, that omission could sit quietly inside a larger recovery design. After too many adjacent packet losses, it changed what “recovered” could honestly mean.

CRTP, defined in RFC 2508, compresses the IP, UDP and RTP headers by keeping shared context at both ends. A full header establishes the context; later packets can carry changes or deltas. If a packet holding an update disappears, the compressor advances and the decompressor does not. The mismatch may remain invisible until another compressed packet arrives. On a long-delay link, asking for context repair costs a round trip, and the decompressor may discard many packets while waiting.

RFC 3545's answer was repetition with a stated boundary. It describes a parameter N based on the link's loss behavior: the probability of losing more than N adjacent packets is meant to be small. When an update is carried in N+1 consecutive packets, at least one copy should arrive if no more than N adjacent packets are lost. The decompressor can use the “twice” reconstruction procedure to account for a bounded gap and verify the result with the UDP checksum or, when applicable, HDRCKSUM. The protocol makes recovery more tolerant; it does not promise that every burst fits the model.

The link sequence is only four bits and cycles every 16 packets. A visible difference between two sequence values therefore cannot always say whether many packets were lost or a later packet was reordered and then an earlier one arrived. If a plausible reading involves fewer than N+1 losses, the decompressor may try the corresponding reconstruction and verify it. If the plausible loss count exceeds N, IPv4 follows a sharper rule: do not keep guessing with “twice”; invalidate the context and send CONTEXT_STATE so the compressor can restore shared state.

That stop rule is where the checksum's coverage matters. HDRCKSUM is available when the original IPv4 UDP checksum is zero; it is inserted for checking and removed by the decompressor. A zero UDP checksum is not allowed for IPv6, so the option is not used there. Yet the header checksum does not validate IPv4 ID. For IPv4 after more than N packet losses, a checksum pass cannot close that missing field. RFC 3545 instead tells the decompressor to abandon the uncertain context. IPv6 has no IPv4 ID field and may use a different recovery rule.

The update burst has its own identity safeguard. If a constant context field changes while N+1 FULL_HEADER packets are being sent, the compressor starts a new burst and changes the generation number. Otherwise, the decompressor could mistake overlapping bursts for a larger loss allowance and miss a context mismatch. CONTEXT_STATE responses should also be repeated. These are protocol mechanisms, not evidence that a particular device enabled the extension or that an RTP application played the payload.

The historical distinction is small but operationally important: a checksum proves only the fields it covers, a bounded reconstruction is not delivery, and context repair is not media acknowledgment. A valid local header check can coexist with an unverified IPv4 ID. When the loss pattern exceeds the stated bound, invalidation is not a failure to recover; it is the point at which the decompressor refuses to turn an ambiguous sequence into false certainty.

Sources