Summary
- RFC 3320 gave a receiver a bounded virtual machine to decompress each signaling message, including messages whose sender supplied the decompression program.
- Successful decoding alone did not authorize durable state: the application had to authenticate the result and return a valid compartment identifier before state creation or compressor feedback.
Compression moved a program as well as a message
In January 2003, RFC 3320 described Signaling Compression, or SigComp, for applications such as SIP and RTSP. Its premise was not simply that a protocol designer could pick a compressor and install it at every endpoint. A sender could choose a compression algorithm and, when needed, include bytecode that the receiver’s Universal Decompressor Virtual Machine (UDVM) would execute. The receiver therefore needed a way to accept useful new decompression behavior without granting it unrestricted control of the host.
That design changes the story from “how many bytes did compression save?” to “what can an incoming message make the receiver do?” The RFC does not establish how widely SigComp was deployed or how much bandwidth it saved in practice. It specifies a protocol boundary: the sender can influence a constrained computation, while the receiver retains authority over resources and over any state that survives the current message.
A fresh execution boundary for every message
Each incoming SigComp message starts a distinct UDVM instance. The machine has a bounded amount of decompression memory, and the endpoint must provide at least 2,048 bytes for that purpose. It also has an instruction budget derived from message length and the configured cycles_per_bit: for an n-byte message the maximum is (8*n + 1000) * cycles_per_bit, with a minimum parameter value of 16. These are per-message limits. They constrain one execution; they are not a promise that the whole endpoint is immune to denial of service or that total host resources are bounded by this formula alone.
The fresh-instance rule is historically important because it localizes failure. If one message is malformed or exhausts its execution allowance, a later message is not automatically trapped behind the same virtual machine state. This is different from assuming that a stream of packets shares one ever-growing decoder. The receiver obtains a deliberate restart boundary, even though the protocol can also make selected state available across messages.
Decoding and remembering are separate permissions
SigComp distinguishes temporary decompression memory from state memory allocated to a compartment. A compartment is an application-defined grouping associated with a peer or communication context; an application can close it when that context ends. An endpoint that chooses not to retain state can set its state budget to zero. The protocol thus allows compression that is deliberately stateless, rather than making persistence a prerequisite for decoding.
The more subtle rule comes after decompression. The application receives the decoded message and can apply the authentication appropriate to its protocol and context. Only when it is willing to associate the message with a valid compartment identifier does the SigComp layer have authorization to create new state for that compartment and to pass feedback to the compressor. If the application cannot establish sufficient confidence, it supplies no valid compartment. The UDVM is then terminated without the requested persistent state being saved and without feedback being forwarded.
This arrangement puts a semantic decision outside the decompressor. The virtual machine can establish that a byte sequence was decoded under the resource rules; it cannot establish that the resulting signaling message is authentic, belongs to the expected dialog, or should influence future compression. The application knows more about those questions and retains the final say. RFC 4896 later clarified the state-creation and authentication boundary, reinforcing that a decoder’s output is not itself a trust decision.
Existing state has a different gate
There is a timing problem: an application may need the decoded message before it can authenticate it, but decompression might already benefit from existing state. SigComp handles access to existing state separately from the application’s post-decompression decision. State identifiers are derived from a hash of the state bytes, so a message that names state must satisfy the protocol’s identifier checks before the receiver exposes that state to the UDVM. Once state has been made available, the post-decompression authorization rule still governs whether new state can be retained.
That distinction avoids collapsing two questions into one. “May this message read a previously established compression state?” and “May this decoded message create or update durable state?” occur at different points and use different evidence. Confusing them can make a secure design look contradictory: pre-decompression access is constrained so decoding can proceed, while post-decompression persistence waits for application-level confidence.
Later documents filled in neighboring gaps
RFC 3321 added extended operations and acknowledgment mechanisms; for unreliable transports, confirmation matters before a sender relies on state at the receiver. RFC 4077 specified negative acknowledgments for reporting decompression failures. RFC 5049 applied SigComp requirements to SIP, including requirements that should not be generalized to every application using the framework. RFC 4464 offered a user’s guide and RFC 4465 a set of torture tests. These documents show that the design needed operational explanation, failure reporting and application-specific profiles; they do not, by themselves, prove adoption or measured benefit.
RFC 3320’s durable contribution is a split in authority. A message can ask a bounded machine to decode it. The application decides whether its meaning is trustworthy enough to become memory that influences future messages. Keeping those stages separate makes the receiver’s resource boundary and its trust boundary visible—and prevents “it decompressed” from silently turning into “we now remember it.”
Sources
- RFC 3320 — Signaling Compression (SigComp) and RFC Editor record
- RFC 4896 — Signaling Compression (SigComp) Corrections and Clarifications and RFC Editor record
- RFC 3321 — SigComp Extended Operations; RFC 4077 — SigComp Negative Acknowledgment Mechanism
- RFC 5049 — Applying SigComp to SIP; RFC 4464 — SigComp User’s Guide; RFC 4465 — SigComp Torture Tests
- RFC 3261 — SIP
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
