Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering
Extracted elements (25)
Context corruption occurs not when a packet is lost, but when the next compressed packet arrives with stale context. Absolute value updates (e.g., full RTP timestamp) can be repeated independently in successive packets, whereas delta value updates cannot compensate for a lost predecessor packet.
CRTP was designed for reliable point-to-point links with short delays and does not perform well over links with high packet loss, reordering, and long delays (e.g., L2TP tunnels, ATM/Frame Relay virtual circuits). Enhanced CRTP addresses this by repeating updates and sending absolute values in addition to delta values, minimizing context corruption.
ROHC (RFC 3095) was considered as an alternative but also assumes no misordering of compressed packets between compressor and decompressor. Enhanced CRTP is preferred for environments where CRTP is already implemented, or where implementation simplicity outweighs ROHC's performance advantages.
The T bit in COMPRESSED_UDP is changed to MAY be nonzero to indicate that the delta RTP timestamp is included explicitly rather than being reset to zero, removing the RFC 2508 limitation that prevented COMPRESSED_UDP from communicating both absolute and delta RTP timestamp in the same packet.
For link layers that already have defined negotiation for CRTP per RFC 2508, an extension to that negotiation will be required to indicate use of enhanced CRTP since the packet format syntax has been extended and is not backward-compatible.
CONTEXT_STATE packets SHOULD be repeated N+1 times (using the same sequence number for each context) to provide robustness against packet loss, where N can be the largest N of all contexts included in the packet.
For IPv4, if more than N packets were lost, the decompressor SHOULD NOT try to recover using the 'twice' algorithm and instead SHOULD invalidate the context and send a CONTEXT_STATE packet. For IPv6, the decompressor MAY always try to recover using 'twice' since there is no unvalidated IPv4 ID field.
If a change to a constant context field (e.g., IP TOS) occurs while sending N+1 FULL_HEADER packets, the compressor MUST change the 'generation' number in the context and in the FULL_HEADER packet when beginning the new sequence of N+1 FULL_HEADER packets so the decompressor can detect the new sequence.
If the C flag is set in the FULL_HEADER packet indicating HDRCKSUM, then the FULL_HEADER packet itself MUST also have the HDRCKSUM inserted. If a subsequent packet arrives with a UDP checksum present, a new FULL_HEADER packet MUST be sent with the C flag cleared.
Over links configured to deliver packets without checking for errors, the compressor SHOULD add HDRCKSUM if a UDP checksum is not present, and the decompressor SHOULD validate each reconstructed packet to ensure at least the headers are correct.
The bits marked '0' in the second flag byte and the CC byte SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
The decompressor MUST zero out the UDP checksum field in the reconstructed packets when HDRCKSUM is used. Note that HDRCKSUM is never used with IPv6 since a null UDP checksum is not allowed in IPv6.
When compressing a new stream, the compressor sets a value of N for that context and sends N+1 FULL_HEADER packets. The compressor MUST also repeat each subsequent COMPRESSED_UDP update N+1 times.
When compression is done over a lossy link with long round trip delay, the compressor MAY choose to always send absolute values and never delta values using COMPRESSED_UDP packets with F=1 and any of S, T, I as necessary.
When F=0 and dT=0, the decompressor sets deltaT to 0. When F=1 and dT=0, the decompressor KEEPS THE CURRENT deltaT in the context (does NOT reset deltaT to 0), which is a key behavioral difference from RFC 2508.
A new CRTP Headers Checksum (HDRCKSUM) option allows the compressor to replace a null UDP checksum with a 16-bit checksum covering the pseudo-IP header, UDP header, first 12 bytes of UDP data (fixed RTP header), and CSRC list. This enables header validation even when UDP checksum is absent.
Enhanced CRTP introduces an extended COMPRESSED_UDP packet with a new F flag indicating an additional flags byte. When F=1, selected individual RTP header fields (M, S, T, P, C) can be included as absolute values rather than carrying the full RTP header.
Enhanced CRTP robust operation uses a parameter N representing link quality: the probability of more than N adjacent packet losses is small. For each context change, the compressor includes the update in N+1 consecutive packets, ensuring the decompressor stays synchronized as long as no more than N adjacent packets are lost.
A malfunctioning or malicious compressor could cause the decompressor to reconstitute packets that do not match originals but have valid IP/UDP/RTP headers and possibly valid UDP checksums. End-to-end authentication and integrity mechanisms are needed to detect such corruption.
A potential denial-of-service threat exists when compression techniques have non-uniform receiver-end computational load, allowing an attacker to inject pathological datagrams that are complex to decompress. However, enhanced CRTP does not exhibit significant non-uniformity in decompression complexity.
Encryption eliminates the redundancy that header compression exploits, creating inducement to forego encryption on low-bandwidth links. RTP provides an alternative where only the RTP payload is encrypted and headers are left in the clear (SRTP), allowing compression to still be applied.
No authentication is performed on CONTEXT_STATE control packets. An attacker with link access could inject false CONTEXT_STATE packets, reducing compression efficiency and potentially causing congestion, though an attacker with such access could disrupt traffic in many other ways.
The extended COMPRESSED_UDP flags/sequence byte layout is: F(1 bit)|I(1 bit)|dT(1 bit)|dI(4 bits link sequence). When F=1, an extension flags byte follows: M|S|T|P|C|0|0|0. When C=1, an additional byte with CC in the lower 4 bits is appended after the two flag bytes.
The FULL_HEADER packet length fields are extended with a C flag. For 8-bit CID, the second length field carries C in bit 2 of the upper byte. For 16-bit CID, the C flag is in the first length field. C=1 indicates HDRCKSUM will be added to subsequent COMPRESSED_UDP and COMPRESSED_RTP packets.
When F=1 in COMPRESSED_UDP, the packet includes selected RTP fields: delta IPv4 ID (if dI=1, variable), delta RTP timestamp (if dT=1, variable), absolute IPv4 ID (if I=1, 2 bytes), RTP sequence number (if S=1, 2 bytes), RTP timestamp (if T=1, 4 bytes), RTP payload type (if P=1, 1 byte), and CSRC list (if CC>0).