Signaling Compression (SigComp) Corrections and Clarifications
updates
Extracted elements (26)
Multiple minimum-priority (65535) state items in a decompressor compartment cause synchronization loss because the compressor has no visibility into state the decompressor creates autonomously. A second minimum-priority state can evict the first earlier than the compressor expects, producing decompression failure on subsequent messages that reference the evicted state.
The default 2K DMS is too small for practical use, severely restricting the circular buffer and compressed message size. Applications mandating SigComp must also mandate an appropriately sized DMS accounting for bytecode size, auxiliary data structures, maximum message size, and average message entropy.
The RFC 3485 SIP/SDP Static Dictionary offset table bugs are documented rather than corrected because any correction would be non-backwards-compatible, requiring all implementations to maintain two dictionary copies. The cost is judged too high relative to a bug that is trivial to work around and has negligible effect on compression ratios.
The UDVM memory size is (DMS - n) for UDP or (DMS / 2) for TCP, where n is the SigComp message size. When the message contains bytecode, two copies of the bytecode exist within the DMS: one in the SigComp message and one in UDVM memory. This is correct and expected behavior.
Five entries in the RFC 3485 SIP/SDP Static Dictionary have offset table pointers that reference strings in a different priority section than declared: 'application' (0x0334, listed priority 2, actual priority 4), 'sdp' (0x064b), 'send' (0x089d), 'recv' (0x0553), and 'phone' (0x00f2). Bytecode that loads only a sub-portion of the dictionary must not reference these offsets unless the corresponding string portion is also loaded.
SigComp Extended shared-mode (RFC 3321 Section 5.2) state items mapped to a compartment must have minimum retention priority (65535) and persist only until deleted by new non-minimum-priority state or STATE-FREE. Endpoint-initiated acknowledgments (RFC 3321 Section 5.1.2) allow an endpoint to advertise a created state's hash back to the requester, confirming creation and availability for at least its normally defined lifetime.
State is accessed using only the first n bytes (minimum 6) of the 20-byte SHA-1 state identifier. Birthday-paradox analysis shows a 6-octet identifier yields a 16.28% collision probability at 10 million state items, while the full 20-octet identifier yields approximately 3.42E-33%. At high-scale server deployments, implementers must carefully choose how many octets of state identifier to use for STATE-ACCESS.
A compressor MUST NOT use more than the most recently advertised resources. Reducing advertised resources SHOULD NOT be done unless absolutely necessary; if reduced, memory MUST NOT be reclaimed until the remote endpoint acknowledges the advertisement. Both endpoints MUST delete state according to retention priority to accommodate an SMS reduction.
An endpoint SHOULD transmit requested feedback repeatedly until it receives another valid message that updates the feedback data, rather than sending it only once. This handles cases such as retransmitted SIP 200 OK responses where the original feedback-carrying message may not have been received.
Even when a compressor sets the I-bit to indicate it will not access local state items, the remote endpoint SHOULD still advertise its DMS and SMS parameters. Without this advertisement, the sender must assume default parameters, which degrades compression efficiency.
If a piece of state is created in a compartment where it already exists, the time of creation SHOULD be updated as if it had just been created, irrespective of whether a new retention priority is specified.
If an endpoint receives a request for feedback, it SHOULD return the feedback even if its SMS is zero. The storage overhead of requested feedback is explicitly not part of the SMS.
If requested_feedback_location equals zero, the existing feedback data SHOULD be left untouched and returned in subsequent messages. If requested_feedback_location is non-zero but the Q flag is zero (no feedback item present), the existing feedback data SHOULD be overwritten to 'no feedback data'.
Retention priority MUST be associated with the compartment, not the piece of state. If the same state is created within a compartment with a different priority, the priority is updated rather than a new state created, and it MUST count only once against SMS.
STATE-CREATE and CRC obey byte copying rules as per RFC 3320 Section 8.4 (amending the original list which omitted STATE-CREATE). When reading the partial state identifier for STATE-FREE within END-MESSAGE execution, byte copying rules also apply. Byte copying rules do NOT apply when reading feedback items.
The compressor MUST ensure that all data needed to decompress a SigComp message is available at the receiving endpoint. Whether message misordering can occur and its impact depends on the compartment definition and transport protocol, so the compressor implementer must account for these factors.
The MULTILOAD instruction must not write into memory positions occupied by its own opcode or parameters, and indirection MUST be resolved at execution time. Any non-step-by-step implementation technique MUST yield the same result as a step-by-step implementation.
When INPUT-BYTES or INPUT-BITS requests more data than remains in the SigComp message, the decompression dispatcher MUST NOT return any bytes/bits to the UDVM; the partial remaining bytes MUST remain in the message unchanged and program execution jumps to the address operand.
When stack_fill equals 0xFFFF and a value is pushed onto the stack, stack_fill MUST be incremented to 0x0000 and written back to stack_location, overwriting the pushed value. The pushed value cannot be preserved in this overflow condition.
Where NACK is not supported or for NACK-averse compressors, only one piece of minimum-priority state (65535) SHOULD be present in a compartment at any one time. If both endpoints support NACK, this restriction MAY be relaxed but implementers must consider the consequences carefully.
Without further definition in an external specification, locally available state items SHOULD NOT be used. Any definition of locally available state item use MUST NOT conflict with other uses. If mapped to a compartment, such state items MUST have retention priority 65535.
A well-known uncompressed bytecode pattern allows SigComp messages to be sent effectively uncompressed. The 13-byte bytecode (0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16, 0xf9, 0x23) loops reading one byte at a time with INPUT-BYTES and outputting it with OUTPUT until exhausted, then calls END-MESSAGE.
Byte copying rules govern a circular buffer defined by byte_copy_left (BCL) and byte_copy_right (BCR). Rightward movement wraps from (BCR-1) mod 2^16 back to BCL; leftward movement (used only by COPY_OFFSET) wraps from BCL to (BCR-1) mod 2^16. Copying outside the BCL/BCR bounds is valid; when BCR < BCL, reads and writes skip the memory between the two pointers.
STATE-FREE does not check minimum_access_length because the application must authenticate the message before state can be freed. STATE-FREE can only free state in the compartment corresponding to the message being decompressed; attempting to free state from another compartment or unassociated state has no effect.
State retention priority ordering is 65535 < 0 < 1 < ... < 65534, which is counterintuitive but correct. Priority 65535 (equivalent to -1) is the minimum retention priority, meaning such state is the first candidate for eviction.
This document does not change SigComp's security profile. Key mitigations from RFC 3320 remain: state snooping is mitigated by requiring at least 48 bits of the state hash (this document recommends more bits at high-scale servers); unauthorized state manipulation is mitigated by application-layer authentication; DoS via SigComp is mitigated by the one-decompressed-output-per-compressed-input rule; UDVM loop attacks are mitigated by the UDVM cycles upper limit.