Signaling Compression (SigComp) - Extended Operations

Dynamic compression reuses information from previously sent messages. For reliable transports (TCP), reception is guaranteed; for unreliable transports, SigComp's explicit acknowledgement mechanism is needed to confirm state establishment before a compressor can safely reference a state.

realtime, sip

Implicit dictionary deletion avoids per-message explicit deletion signaling by agreeing on a well-defined deletion algorithm (e.g., part of predefined UDVM bytecode) applied identically at both endpoints. This reduces signaling overhead and increases robustness by eliminating bits on the wire subject to transmission errors.

The acknowledgement identifier must be large enough to avoid false acknowledgements of the wrong state. A minimum of 1 octet is recommended for simplicity and to avoid padding of feedback items.

The implicit acknowledgement optimization relies on the SigComp state handler guarantee that announcement information is discarded if a state save request is denied; therefore reception of a shared state(M) announcement implies state(S) was successfully saved. However, subsequent eviction due to memory pressure remains possible and must be tracked using the state_memory_size parameter.

When the requested feedback length is non-zero, endpoint-initiated acknowledgements should not be used due to possible bandwidth waste. Since all SigComp implementations support the feedback mechanism, implementing remote-compressor-initiated acknowledgements (Section 5.1.1) is generally preferred.

A basic SigComp implementation (RFC 3320 only) that receives a message containing shared_state_id or acked_state_id identifiers in the returned SigComp parameters will silently ignore these identifiers. Implementations using extended features are therefore backward-compatible with non-extended endpoints.

An endpoint wishing to receive shared_state_id from its peer must not set the I-bit (which suppresses the list of locally available states) to 1, since shared state availability is communicated via this list.

For a shared state, the state_address and state_instruction parameters must be set to zero, state_retention_priority must be set to 65535, and other parameters follow RFC 3320. This ensures the shared state is independent of the compression algorithm used in each direction.

New shared state items must not be created unless the compressor has made sufficient state memory available at the remote end, because creating a shared state that evicts existing states could cause decompression failure.

A saved state is one expected to be used for compression/decompression of later messages. An acked state is a saved state for which the compressor has received an explicit acknowledgement confirming the state exists at the remote decompressor; a compressor must only use acked states to avoid decompression failure.

A user-specific dictionary is a state item capturing user-invariant fields (e.g., URL, name, email, SIP capabilities). It can be preloaded before time-critical signaling begins and benefits from cross-session state persistence described in Section 5.3.

sip

Acknowledgement optimization: when shared compression is active and endpoint 1 sets the 'r' bit indicating it saved a shared state(M), endpoint 1 can implicitly infer that state(S) was created at endpoint 2 when it observes that shared state(M) is requested by decompressor 1—making an explicit acked_state_id unnecessary for that state. The state handler must maintain a mapping between state(M) and state(S) for this optimization.

Checkpoint state: a compressor designates a state as a checkpoint by setting its state_retention_priority to the highest value it has sent. A checkpoint state must be explicitly acknowledged by the decompressor, providing a reliable fallback to prevent decompression failures when states are lost or evicted due to memory pressure.

Local endpoint initiated acknowledgements: the receiving endpoint places the acked_state_id directly into outgoing SigComp messages at the location of the 'returned SigComp parameters', indicated to the state handler via the END-MESSAGE instruction.

Maintaining state across application sessions is achieved by extending the SigComp compartment lifetime beyond a single application session. Messages from the same source contain redundancies across session boundaries, and amortizing state overhead over multiple sessions improves long-term compression efficiency.

sip

Remote compressor initiated acknowledgements: the compressor uploads UDVM bytecode that places an arbitrary identifier in the requested_feedback_item field via the END-MESSAGE instruction; the decompressor returns this as returned feedback data in the reverse SigComp message, confirming state establishment.

Shared compression: a compressing endpoint saves the uncompressed version of the message it is about to send as a shared state, then indicates this state's availability to the remote compressor. The remote uses the SHA-1 instruction to calculate the shared_state_id and matches it against the decompressed message to enable compression using the shared state.

The returned_SigComp_parameters partial_state_identifiers serve dual purpose: they acknowledge states established at the remote endpoint upon receipt of SigComp messages, and may also announce globally available states not tied to any compartment.

Two state identifier types are defined: shared_state_id (reference to a shared state built from an uncompressed received message) and acked_state_id (reference to a state explicitly acknowledged as successfully saved by the remote decompressor).

The extended mechanisms described in RFC 3321 (explicit acknowledgement and shared compression) are believed not to introduce any security risks beyond those already identified in the base SigComp specification (RFC 3320). Acknowledgements should be piggybacked onto existing SigComp messages rather than sent standalone to avoid creating additional security risks.

security

In the example format (Figure 5), the shared_state_id and acked_state_id fields are each the same length as the partial state identifier defined in RFC 3320. The fields are present only when the corresponding 's' or 'a' flag bits are set in the flags byte.

The 'remaining SigComp message' field format is an implementation decision by the compressor supplying the UDVM bytecode. RFC 3321 provides only a non-normative example (Figure 5) showing a flags byte with 's' (shared state present), 'a' (acked state present), and 'r' (shared state of this message saved) bits, followed by optional shared_state_id and acked_state_id fields.