Summary

  • RFC 3486 attached comp=sigcomp to the URI or header that governed the next request, response or later route, so compression could differ by hop and direction inside one SIP dialog.
  • The marker meant support and present willingness to receive compressed messages. Actual wire compression, successful parsing, delivery, authentication and call establishment remained separate evidence.

The tempting picture is a switch at the edge of a call: turn SigComp on, and the SIP conversation becomes compressed from one user agent to the other. RFC 3486 described a less theatrical system. Its unit of control was not the whole call. It was the next message decision, made from the URI or header that addressed the next receiver.

That design began with a scaling problem. SIP already used DNS NAPTR and SRV records to discover transports such as UDP, TCP and SCTP. If operators also multiplied records for security and compression combinations, two transports, TLS and SigComp could create eight variants. RFC 3486 moved the compression choice into SIP instead. Compressed and ordinary SIP could arrive on the same port, and a receiver could distinguish SigComp by the cookie bits at the start of the message.

The new signal was compact: comp=sigcomp. In a SIP or SIPS URI, it told the sender that the request should be compressed for the next hop. In the topmost Via entry, it told the server that the response should be compressed on its return leg. The same spelling appeared in both places, but the controlling object and direction differed.

The RFC gave the token two meanings together. It indicated that the named SIP entity supported SigComp and that it was willing to receive compressed messages. Willingness mattered because a capable receiver might not want compression at every moment. A registry entry or implementation capability was therefore not enough; the current routing material carried a scoped preference.

That scope created a hard safety rule. A client that did not know whether the next-hop server supported SigComp must not send it a compressed request. The client could nevertheless send an ordinary request with comp=sigcomp in its own topmost Via. That request asked for a compressed response if the server understood the mechanism. Support for one direction did not have to be inferred from compression in the other.

Initial discovery exposed the bootstrap problem. A client wanted to compress the first INVITE, before a dialog had produced a Route set. Manual configuration was one answer. Another was an uncompressed OPTIONS request to the outbound proxy. The proxy could return an alternative Contact URI carrying comp=sigcomp, which the client could use for later requests. The discovery exchange was evidence of an offered route, not proof that a later request actually used compressed bytes.

Contact and Record-Route then carried the preference forward. A user agent that wanted later requests compressed placed the parameter in Contact. A proxy that remained in the path could place it in Record-Route. On the response, a Record-Routing proxy inspected the upstream route material and could add or remove the parameter from its own entry. The route set was being edited so future traffic would make a new hop-specific decision.

The RFC's example makes the boundary visible. Four SIP elements participate, and several support compression, but only messages 1, 6 and 7 are compressed. One proxy accepts a compressed INVITE and forwards an uncompressed one. A response is uncompressed on one leg and compressed on another because the topmost Via differs. The ACK is compressed to one proxy and ordinary from that proxy to the user agent server. One dialog therefore contains multiple compression realities.

Double Record-Routing did not erase the distinction. A firewall-like proxy with interfaces on two networks could insert two route entries and avoid rewriting. It could still receive compressed traffic from one side and uncompressed traffic from the other. If its own next hop was itself and no network transmission occurred, it could decline to compress even when the URI carried the parameter.

Failure produced a particularly important evidentiary gap. A server without SigComp might be unable to parse a compressed request at all. It could not reach the Via header and therefore could not send a normal SIP error. Silence at the client was not a diagnostic verdict. RFC 3486 prescribed an operational response: after transaction timeout, retry the same request uncompressed.

TCP made the fallback stricter. The client should close the connection used for the compressed request and open a new one for the ordinary retry. Otherwise, the unsupported server might not locate the start of the new SIP message in the existing byte stream. A timeout, an uncompressed retry and a new connection were three events, not one collapsed “compression failed” status.

The security section also treated the marker as consequential rather than self-authenticating. An attacker who inserted comp=sigcomp could induce traffic toward an entity that did not support it, so integrity protection mattered. Decompression also required more processing than parsing ordinary SIP and could slightly worsen denial-of-service pressure. The token carried instruction, not identity.

IANA registered comp and the sigcomp value, but registration only stabilized vocabulary. RFC 3320 defined the decompression architecture. RFC 3485 supplied the immutable SIP/SDP dictionary. RFC 5049 later updated the SIP/SigComp binding with resource minima, compartments and state management while retaining RFC 3486 discovery. RFC 4077, RFC 4896 and RFC 5112 added other SigComp details; RFC 5626 later addressed SIP outbound flows. None converts one parameter into a deployment census.

The evidence reconstruction should therefore begin at the message edge. Preserve the exact next-hop URI, topmost Via, Contact, Route and Record-Route values, their integrity protection, message direction, actual wire form and transport connection. Record discovery and later use separately. If timeout occurs, preserve the retry and whether TCP was reopened. Only then join decompression, SIP parsing, authentication, dialog and user outcome.

Heng Lu's distinction between declared capability and observed outcome fits RFC 3486 unusually well. The marker created a local permission to try compression. It did not make a path homogeneous. The historical achievement was more modest and more precise: SIP gained a way to negotiate compression without exploding DNS combinations, while keeping the choice attached to the hop that could actually honor it.

Sources