The ability to compress SIP messages over the air interface is essential for IMS. How Signalling Compression (SigComp) works is described in Section 3.17. This section shows how the UE and the P-CSCF indicate that they support SigComp and are both willing to use it.
The P-CSCF and an IMS UE must support SIP SigComp, but they are not mandated to use it. Therefore, they need a mechanism to express whether they are willing to apply SigComp.
[RFC3486] defines a new URI parameter "comp", which can be set to "comp = SigComp" by either the UE or a SIP proxy (in the case of IMS this applies only to the P-CSCF) in order to express its willingness to send or receive certain SIP messages compressed.
Tobias's UE will express its willingness to use SigComp with the P-CSCF that is already in the initial REGISTER request. The P-CSCF will give a similar indication in the 401 (Unauthorized) response. As these two SIP messages are sent without any protection, the P-CSCF and the UE will not create states (compartments) for SigComp at this point in time; this is to ensure that a malicious user–who wants, say, to start a Denial Of Service (DOS) attack against the P-CSCF – cannot overload the P-CSCF by forcing it to reserve memory for a huge number of unnecessary SigComp compartments.
State creation will only be done after an IPsec SA (see Section 10.7) between the UE and the P-CSCF has been established.