Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
updates
- rfc-3486 — Compressing the Session Initiation Protocol (SIP)
Extracted elements (28)
Compartment lifetime was simplified to be linked only to REGISTER transactions (not to SIP dialogs or transactions) because the complexity introduced by dialog/transaction-scoped compartments (e.g., requiring edge proxies to keep dialog state) outweighed the benefits in most deployment scenarios.
Continuous Mode is not used with SIP/SigComp because continuous mode requires the transport to provide protection against denial-of-service attacks, and TCP alone is not considered to provide enough protection.
SIP retransmissions must be re-compressed because it is impossible to know whether the failure occurred on the message or its response; if the response was lost, state changes from the first transmission may have removed state the compressed message relied upon, leading to decompression failure on retransmission.
The minimum DMS for SIP/SigComp is set to 8192 bytes because the SigComp over UDP condition (C + 2*B + R + 2*S + 128 < DMS) makes a 2048-byte DMS prohibitively restrictive for SIP message compression, while 8 KB is easily supportable by any SIP-capable endpoint.
Legacy SIP/SigComp implementations may not conform to RFC 5049, exhibiting smaller DMS than mandated, lack of NACK support, or different compartment mapping. The rules in this document were designed to maximize interoperability with such legacy deployments.
When SIP/SigComp is used over a TLS connection that also provides compression, SIP messages are first compressed by SigComp then by TLS. It is NOT RECOMMENDED to use TLS compression when SigComp is in use, as the additional compression gain is minimal once SigComp has already compressed the message.
A SIP/SigComp application placing its URI with 'comp=sigcomp' in a header field MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that URI. Similarly, when generating its own Via entry with 'comp=sigcomp', it MUST add a 'sigcomp-id' parameter to that Via entry.
A SIP/SigComp application SHOULD use a UUID URN (RFC 4122) as its SIP/SigComp identifier due to difficulties in equality comparisons for other URN kinds. If another URN scheme is used, it MUST be selected so that no other SIP/SigComp application would choose the same URN value.
Any SigComp implementation used for compression of SIP messages MUST conform to RFC 5049 and RFC 3320, and must support the SIP/SDP static dictionary (RFC 3485) and the mechanism for discovering SigComp support at the SIP layer (RFC 3486).
Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the connection carries SigComp messages, all messages MUST have a SigComp header and be delimited by 0xFFFF. SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages.
Each SIP/SigComp application MUST have a SIP/SigComp identifier URN that uniquely and persistently identifies the application. This URN MUST be persistent as long as the application stores compartment state related to other SIP/SigComp applications.
Equality comparisons between SIP/SigComp identifiers use URN-scheme-specific equality rules. If the URN scheme is unknown, lexical equality per RFC 2141 is used. Applications SHOULD provide lexically equivalent URNs in each registration to avoid false inequality.
If a SIP application already has a compartment for a given remote application identifier (e.g., when registering towards a second registrar via the same proxy), it MUST use the existing compartment and MUST NOT open a new one.
If a SIP application does not have a compartment for a message it needs to send, it MAY choose not to compress it even when 'comp=sigcomp' is present, because stateless compression is not typically worthwhile and may result in message expansion.
If a SIP application needs to send a message larger than 64k over a compressed connection, it MUST NOT send the message over the same TCP connection, and SHOULD send it over a different transport connection, since SigComp does not support compression of messages larger than 64k.
Server farms that share SIP/SigComp state across servers MUST use the same SIP/SigComp identifier for all their servers.
The minimum decompression_memory_size (DMS) for SIP/SigComp is 8192 bytes, increased from the ANY/SigComp minimum of 2048 bytes, because 2048 bytes is too small for SIP message compression and severely limits compression ratio.
The minimum locally available state (LAS) for SIP/SigComp is the SIP/SDP static dictionary defined in RFC 3485. Since support for this dictionary is mandatory, it does not need to be advertised.
The minimum state_memory_size (SMS) for SIP/SigComp is 2048 bytes per compartment, increased from the ANY/SigComp minimum of 0 bytes. An endpoint MAY offer different SMS values for different compartments as long as the value is not less than 2048 bytes.
The SigComp_version (SV) for SIP/SigComp MUST be >= 0x02 (SigComp + NACK), implying that RFC 4077 (SigComp NACK mechanism) applies and decompression failures result in NACK messages sent to the originating compressor.
When SIP messages are retransmitted, they MUST be re-compressed taking into account any SigComp states created or invalidated since the previous transmission. Implementations MUST NOT cache and retransmit a previously compressed result.
Outgoing requests use the SIP/SigComp identifier of the destination URI as the remote application identifier; incoming requests use the SIP/SigComp identifier from the top-most Via entry. For legacy apps without identifiers, IP address plus port (or connection ID for TCP) is used as fallback.
SigComp and uncompressed SIP messages can coexist on the same port. For UDP/SCTP, detection is per-message by checking whether the first octet's MSBs are '11111' (SigComp) or otherwise (plain SIP). For TCP, detection is per-connection based on the first octet of the stream.
IANA registered the 'sigcomp-id' SIP URI parameter under the SIP/SIPS URI Parameters subregistry within the SIP Parameters registry, with no predefined values, referencing RFC 5049.
IANA registered the 'sigcomp-id' Via header field parameter under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry, with no predefined values, referencing RFC 5049.
The same security considerations as RFC 3320 apply. Keeping SigComp states longer than the duration of a SIP dialog does not pose new security risks because the state was permitted to be created in the first place.
SIP/SigComp compartment lifetime is linked to SIP registration state: a compartment is opened when a REGISTER transaction is initiated/received, and is closed when the registration expires or is canceled (or on a non-2xx final response). Applications SHOULD NOT close compartments until registration is over.
SIP/SigComp identifiers are carried in the 'sigcomp-id' SIP URI parameter (defined as 'uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar') and as a Via header field parameter (defined as 'via-sip-sigcomp-id = "sigcomp-id" EQUAL LDQUOT *( qdtext / quoted-pair ) RDQUOT'). Both MUST contain a URN per RFC 2141.