Summary

  • RFC 3322 calculated 4,131 ms for a sample SIP/SDP exchange by assuming a 9.6 kbit/s link and 140 ms round trip; it explicitly called the approximation crude and omitted retransmission delay.
  • The value of the document lies in how it turned a bounded problem model into transparent, generic and robust design requirements—not in proving a deployed SigComp performance result.

A precise answer to a deliberately narrow question

The arithmetic in RFC 3322 is simple enough to fit on one line. For each signaling message, divide its bits by a 9,600-bit-per-second link and add half of a 140 ms round trip. Apply that rule to the illustrated SIP/SDP sequence—from INVITE through provisional responses, PRACKs and the final ACK—and the total becomes 4,131 ms. Add the document’s rough allowances for RSVP, session management and radio-bearer setup, and the reader can see why early cellular Internet telephony made signaling size an engineering concern.

The apparent precision is useful only if its provenance stays attached. RFC 3322 says the WCDMA approximation is “rather crude.” It ignores delays from possible retransmissions after errors. It assumes one cellular link. It absorbs an eventual intermediate IP network into a simplified delay picture. The selected message sizes are described as typical, not universal. A nearby comparison—about 3.6 seconds for a typical GSM call setup and 7.9 seconds for a SIP case—belongs to the motivating context, not to a SigComp deployment census.

This is a strong piece of engineering precisely because it marks those limits. The calculation answers: under these assumptions, how much serialization and propagation delay can a plausible signaling exchange accumulate? It does not answer: how long did a particular user wait, how much did a deployed compressor save, or which component caused an observed delay.

Requirements came after the model, not out of the measurement

Published as Informational in January 2003, RFC 3322 did not define the SigComp protocol. It organized the reasons for developing one. Text-heavy SIP, SDP and RTSP messages arrived over radio systems where capacity per user mattered, error protection could increase delay, and request/response sequences repeatedly left a sender waiting. The document then compared possible responses.

Increasing the user bit rate could consume capacity needed by other users and would not be available everywhere, especially near cell borders. Reducing radio RTT required deeper system change. Sending more requests without waiting would alter application protocols. Stripping fields would shrink messages by changing their meaning and violating transparency. Compression looked attractive because it could preserve the application’s bytes while changing how they crossed the constrained hop.

That ordering matters. The delay model did not certify compression. It helped decide what properties a compression scheme would need if engineers chose that path. Publication was not adoption; a “must” was not conformance evidence; a modeled baseline was not an achieved improvement.

Transparency protected the end-to-end message

The first general requirement was uncompromising: compressing and then decompressing a message must produce a bitwise-identical result. That requirement kept the common layer thin. The compression system could optimize representation, but it could not quietly become an editor of SIP or SDP semantics.

Other requirements widened the compatibility surface. SigComp had to coexist with header compression, permit application protocols to negotiate whether compression would be used, remain backward compatible, support arbitrary message streams rather than one fixed conversation pattern, function on unidirectional routes without explicit decompressor feedback, and operate over both reliable and unreliable transports.

Negotiation itself was explicitly outside the compression solution. That boundary prevented the mechanism from claiming authority it did not possess. SigComp could provide machinery; the protocol carrying the messages had to determine whether peers would invoke it. A capture containing SigComp-capable software therefore cannot prove that a given session negotiated or used compression.

Robustness requirements described tests still to be passed

The performance section likewise speaks in prospective terms. Implementations should scale across terminals with different memory and processor capacities. Compression must not noticeably add user delay; queuing several messages merely to obtain a better ratio would defeat the original purpose. Residual errors must rarely produce an incorrect decompression. Damage to one message should not poison all later messages. Moderate reordering should remain recoverable, and later messages should still be usable after earlier loss.

Those requirements became part of the lineage that includes the RFC 3320 architecture, the RFC 3485 SIP/SDP static dictionary, RFC 3486’s SIP use, and later guidance in RFC 4077 and RFC 5049. The lineage shows sustained design work. It does not by itself disclose deployment share, interoperability quality or latency gain. Each of those claims would need its own evidence: negotiated session traces, implementation versions, test conditions and observed outcomes.

RFC 3322 therefore offers a durable lesson about technical numbers. Assumptions can make a comparison reproducible without making it universal. Requirements can constrain a design without proving it exists. A standardization history remains honest when it preserves the boundary between the model that motivated work, the specification that followed, the code that implemented it and the measurements that might eventually judge it.

Sources