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", "3GPP-NR-REDCAP", "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 and as updated by RFC 4896; and
• the additional requirements specified in RFC 5049, with the exception that the UE shall take a State Memory Size of at least 4096 bytes as a minimum value.

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", "3GPP-NR-REDCAP", "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 may support:

• the negative acknowledgement mechanism specified in RFC 4077.

When using SigComp the UE shall send compressed SIP messages in accordance with RFC 3486. 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. If the UE supports SigComp:

• the UE shall support the SIP dictionary specified in RFC 3485 and as updated by RFC 4896. 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.

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

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", "3GPP-NR-REDCAP".

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

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. If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific.

The P-CSCF shall support:

• SigComp as specified in RFC 3320 and as updated by RFC 4896; and
• the additional requirements specified in RFC 5049, 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.

When using SigComp the P-CSCF shall send compressed SIP messages in accordance with RFC 3486. 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 and as updated by RFC 4896. 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.

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, 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.

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.

Prior to communication with the IM CN subsystem, the UE shall:

1. establish a connection with the IP-CAN;
2. obtain an IP address using either the standard IETF protocols (e.g., DHCP or IPCP) or a protocol that is particular to the IP-CAN technology that the UE is utilising. The UE shall fix the obtained IP address throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the last deregistration; and
3. acquire a P-CSCF address(es).
   The UE may acquire an IP address via means other than the DHCP. In this case, upon acquiring an IP address, the UE shall request the configuration information (that includes the DNS and P-CSCF addresses) from the DHCP server.
   The methods for acquiring a P-CSCF address(es) are:
   1. Employ Dynamic Host Configuration Protocol for IPv4 RFC 2131 or for IPv6 (DHCPv6) RFC 3315. Employ the DHCP options for SIP servers RFC 3319 or, for IPv6, RFC 3361. Employ the DHCP options for Domain Name Servers (DNS) RFC 3646.
      The UE shall either:
      • in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name Servers (DNS); or
      • request a list of SIP server IP addresses of P-CSCF(s).
   2. Obtain the P-CSCF address(es) by employing a procedure that the IP-CAN technology supports. (e.g. GPRS).
   3. The UE may use pre-configured P-CSCF address(es) (IP address or domain name). For example:
      1. The UE selects a P-CSCF from the list stored in ISIM or IMC;
      2. The UE selects a P-CSCF from the list in IMS management object.
      When acquiring a P-CSCF address(es), the UE can freely select either method I or II or III.
   The UE may also request a DNS Server IP address(es) as specified in RFC 3315 and RFC 3646 or RFC 2131.

When:

• the UE obtains a connection with the IP-CAN by performing handover of the connection from another IP-CAN;
• IP address of the UE is not changed during the handover; and
• the UE already communicates with the IM CN subsystem via the connection with the other IP-CAN, e.g. the UE determines that its contact with host portion set to the UE IP address (or FQDN of the UE) associated with the connection with the other IP-CAN has been bound to a public user identity;

the UE shall continue using the P-CSCF address(es) acquired in the other IP-CAN.

The means to ensure that appropriate resources are available for the media flow(s) on the IP-CAN(s) related to a SIP session is dependant on the characteristics for each IP-CAN, and is described separately for each IP-CAN in question. GPRS is described in Annex B. xDSL is described in Annex E. DOCSIS is described in Annex H. EPS is described in Annex L. cdma2000® packet data subsystem is described in Annex M. EPC via cdma2000® HRPD is described in Annex O. cdma2000® Femtocell network is described in Annex Q. Evolved Packet Core (EPC) via WLAN is described in Annex R. DVB-RCS2 is described in Annex S. 5GS is described in Annex U. If a particular handling of the IP-CAN is needed for emergency calls, this is described in the annex for each access technology.

The UE may support P-CSCF restoration procedures. An IP-CAN may provide means for detecting a P-CSCF failure. An UE supporting the P-CSCF restoration procedure should either use the keep-alive procedures described in RFC 6223 or the procedure provided by a IP-CAN for monitoring the P-CSCF status.

Since the UE does not know that forking has occurred until a second provisional response arrives, the UE will request the radio/bearer resources as required by the first provisional response. For each subsequent provisional response that may be received, different alternative actions may be performed depending on the requirements in the SDP answer:

• the UE has sufficient radio/bearer resources to handle the media specified in the SDP of the subsequent provisional response, or
• the UE must request additional radio/bearer resources to accommodate the media specified in the SDP of the subsequent provisional response.

When an 199 (Early Dialog Terminated) response for the INVITE request is received for an early dialogue, the UE shall release reserved radio/bearer resources associated with that early dialogue. When the first final 200 (OK) response for the INVITE request is received for one of the early dialogs, the UE proceeds to set up the SIP session using the radio/bearer resources required for this session. Upon the reception of the first final 200 (OK) response for the INVITE request, the UE shall release all unneeded radio/bearer resources.

An AS requesting charging information and authorisation for specific media operations and media usage controlled by the MRFC shall use RFC 6230 together with appropriate packages. An AS may support delegation of an XML (such as CCXML or SCXML) script execution to an MRFC. An AS supporting delegation of XML script execution shall use RFC 6230 together with appropriate packages. The packages, or extensions to existing packages using RFC 6230 framework are not specified in this release. The AS may support the media server resource consumer interface as defined by RFC 6917. If supported the AS can support either the in-line mode or the query mode or both.

An MRFC required to generate charging information and authorize requests from an AS for specific media operations and media usage shall support RFC 6230 together with appropriate packages. An MRFC may support delegated XML (such as CCXML or SCXML) script execution from an AS. An MRFC supporting delegation of XML script execution shall use RFC 6230 together with appropriate packages. The packages, or extensions to existing packages using RFC 6230 framework above are not specified in this release. The MRFC may support the media server resource publish interface as defined by RFC 6917.