8 SIP compression

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 SIP compression procedures at the UE

8.1.1 SIP compression

If in normal operation the UE generates requests or responses containing a P-Access-Network-Info header field which included a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD", "3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP-NR-SAT", "3GPP-NR-ProSe-L2UNR", "3GPP-NR-ProSe-L3UNR", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", or "DVB-RCS2", then the UE shall support:

– SigComp as specified in RFC 3320 [32] and as updated by RFC 4896 [118]; and

– the additional requirements specified in RFC 5049 [79], with the exception that the UE shall take a State Memory Size of at least 4096 bytes as a minimum value.

– the negative acknowledgement mechanism specified in RFC 4077 [65A].

When using SigComp the UE shall send compressed SIP messages in accordance with RFC 3486 [55]. When the UE will create the compartment is implementation specific, but the compartment shall not be created until a set of security associations or a TLS session is set up if signalling security is in use. The UE shall finish the compartment when the UE is deregistered. The UE shall alow state creations and announcements only for messages received in a security association.

NOTE: Exchange of bytecodes during registration will prevent unnecessary delays during session setup.

If the UE supports SigComp:

– the UE shall support the SIP dictionary specified in RFC 3485 [42] and as updated by RFC 4896 [118]. If compression is enabled, the UE shall use the dictionary to compress the first message; and

– if the UE supports the presence user agent or watcher roles as specified in table A.3A/2 and table A.3A/4, the UE may support the presence specific dictionary specified in RFC 5112 [119].

The use of SigComp is not re-negotiated between initial registration and deregistration.

8.1.2 Compression of SIP requests and responses transmitted to the P-CSCF

In normal operation the UE should send the generated requests and responses transmitted to the P-CSCF:

– compressed according to subclause 8.1.1, if the P-Access-Network-Info header field of the initial registration message includes a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", or "DVB-RCS2";

– uncompressed, if the P-Access-Network-Info header field of the initial registration message includes a value of "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD","3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP-NR-SAT", "3GPP-NR-ProSe-L2UNR", "3GPP-NR-ProSe-L3UNR".

In other cases where SigComp is supported, the UE need not compress the requests and responses.

NOTE 1: Compression of SIP messages is an implementation option. However, compression is strongly recommended.

NOTE 2: In an IP-CAN where compression support is mandatory the UE can send even the first message compressed. Sigcomp provides mechanisms to allow the UE to know if state has been created in the P-CSCF or not.

8.1.3 Decompression of SIP requests and responses received from the P-CSCF

If the UE supports SigComp, then the UE shall decompress the compressed requests and responses received from the P-CSCF according to subclause 8.1.1.

NOTE: According to RFC 3486 [55], the UE not supporting SigComp or not indicating willingness to receive compressed messages never receives compressed SIP messages.

If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific.

8.2 SIP compression procedures at the P-CSCF

8.2.1 SIP compression

The P-CSCF shall support:

– SigComp as specified in RFC 3320 [32] and as updated by RFC 4896 [118]; and

– the additional requirements specified in RFC 5049 [79], with the exception that the P-CSCF shall take a State Memory Size of at least 4096 bytes as a minimum value.

The P-CSCF may support:

– the negative acknowledgement mechanism specified in RFC 4077 [65A].

When using SigComp the P-CSCF shall send compressed SIP messages in accordance with RFC 3486 [55]. When the P-CSCF will create the compartment is implementation specific, but the compartment shall not be created until a set of security associations are set up. The P-CSCF shall finish the compartment when the UE is deregistered. The P-CSCF shall allow state creations and announcements only for messages received in a security association.

The P-CSCF:

– shall support the SIP dictionary specified in RFC 3485 [42] and as updated by RFC 4896 [118]. If compression is enabled, the P-CSCF shall use the dictionary to compress the first message; and

– may support the presence specific dictionary specified in RFC 5112 [119].

NOTE: Exchange of bytecodes during registration will prevent unnecessary delays during session setup.

8.2.2 Compression of SIP requests and responses transmitted to the UE

For all SIP transactions on a specific security association where the security association was established using a REGISTER request from the UE containing a P-Access-Network-Info header field which included a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD","3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP-NR-SAT", "3GPP-NR-ProSe-L2UNR", "3GPP-NR-ProSe-L3UNR", "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", or "DVB-RCS2", and the UE has indicated that it supports SigComp and is willing to receive compressed messages in accordance with RFC 3486 [55], then the P-CSCF should compress the requests and responses transmitted to the UE according to subclause 8.2.1. In other cases where SigComp is supported, it need not.

NOTE: Compression of SIP messages is an implementation option. However, compression is strongly recommended.

8.2.3 Decompression of SIP requests and responses received from the UE

The P-CSCF shall decompress the compressed requests and responses received from the UE according to subclause 8.2.1.

If the P-CSCF detects a decompression failure at the UE, the recovery mechanism is implementation specific.