Compressing the Session Initiation Protocol (SIP)
updated by
- rfc-5049 — Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
Extracted elements (24)
The comp=sigcomp parameter is designed to mean both 'support' and 'willingness' to receive compressed messages. This dual meaning allows the receiver of a SIP message to influence the decision of whether or not to use SigComp at a given time.
Using DNS to discover support for additional protocol layers (security, compression) does not scale. A server supporting TCP+SCTP transports, TLS, and SigComp would require 8 DNS entries. An application-layer mechanism is therefore needed to signal compression support.
A client MUST NOT send a compressed request to a server if it does not know whether or not the server supports SigComp.
A client that does not know if the server supports SigComp but wishes to receive compressed responses SHOULD add comp=sigcomp to the topmost Via header field, even though the request itself will not be compressed.
A user agent server SHOULD add comp=sigcomp to the Contact header field of the response if the URI of the next upstream hop in the route set contained the parameter comp=sigcomp.
Every SIP implementation that supports SigComp MUST implement the procedures described in this document.
If a client sends a compressed request and the transaction times out without a response, the client SHOULD retry the same request without compression. If the request was sent over TCP, the client SHOULD close that connection and open a new one.
If a client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field.
If a client wants to receive subsequent requests in the UAS->UAC direction compressed, it SHOULD add comp=sigcomp to the URI in the Contact header field (if UAC) or to the Record-Route header field URI (if proxy).
If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp.
If the next-hop URI is a SIPS URI, the request SHOULD be compressed before it is passed to the TLS layer.
If the topmost Via header field contains comp=sigcomp, the response SHOULD be compressed. Otherwise, the response MUST NOT be compressed.
To avoid asymmetric compression, a Record-Routing proxy SHOULD add comp=sigcomp to its Record-Route entry if the next upstream hop URI contains comp=sigcomp, and SHOULD remove it otherwise.
A SIP element supporting compression demultiplexes compressed and uncompressed messages on the same port based on a cookie in the topmost bits of every compressed message.
If a proxy detects that the next-hop proxy for a request is itself and the request will not be sent through the network, the proxy MAY choose not to compress the request even if the URI contains comp=sigcomp.
Proxies that receive compressed messages from one side and uncompressed from the other MAY use double Record-Routing (one entry per network interface) to avoid having to rewrite Record-Route entries on responses.
To obtain a comp=sigcomp URI before dialog establishment, a client SHOULD send an uncompressed OPTIONS request to its outbound proxy. The proxy MAY respond with a Contact header field in a 200 OK containing an alternative SIP URI with comp=sigcomp.
Two parameters are defined: a URI parameter ('comp=sigcomp') and a Via header field parameter ('comp=sigcomp'). Their presence indicates that the identified SIP entity supports SigComp and is willing to receive compressed messages.
When a compressed SIP request arrives at a server that does not understand SigComp, the server has no means to indicate the error: the message cannot be parsed and there is no Via header to send an error response to.
This document defines the 'comp' uri-parameter and via-extension. New values are registered by IANA when new signalling compression schemes are published in standards track RFCs. Each registration must include the scheme name and a token (SHOULD be no more than ten characters). The initial entry is 'sigcomp' for Signaling Compression.
A SIP entity receiving a compressed message must decompress and parse it, requiring slightly more processing than uncompressed messages. This makes denial-of-service attacks using compressed messages marginally worse than those using uncompressed messages.
An attacker inserting comp=sigcomp into a SIP message could cause a SIP entity to send compressed messages to another entity that does not support SigComp. Appropriate integrity mechanisms should be used to prevent this attack.
The compression URI parameter is defined as: compression-param = "comp=" ("sigcomp" / other-compression); other-compression = token. It is a uri-parameter as defined in SIP ABNF Section 25.1 of RFC 3261.
The Via compression parameter is defined as: via-compression = "comp" EQUAL ("sigcomp" / other-compression); other-compression = token. It is a via-extension as defined in SIP ABNF Section 25.1 of RFC 3261.