B.3 Application usage of SIP

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

B.3.1 Procedures at the UE

B.3.1.0 Registration and authentication

The UE shall perform reregistration of a previously registered public user identity bound to any one of its contact addresses when changing to an IP-CAN for which usage is specified in annex R. The reregistration is performed using the new IP-CAN.

NOTE 1: This document does not specify how the UE detects that the used IP-CAN has changed. The information that is forcing the reregistration is also used to generate the content for the P-Access-Network-Info header field.

NOTE 2: The UE will send the reregistration irrespective of whether it has a SIP dialog or not.

If the UE supports the 3GPP PS data off, then the UE shall in all REGISTER requests include the "+g.3gpp.ps-data-off" header field parameter defined in subclause 7.9.8 set to a value indicating the 3GPP PS data off status.

When the UE sends a REGISTER request, if the 3GPP PS data off status is "active", then the UE shall only include media feature tags associated with services that are 3GPP PS data off exempt services in the g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3840 [62], for the IMS communication services it intends to use.

If the UE is registered, and the 3GPP PS data off status is changed or the UE is provided by the network with a new list of 3GPP PS data off exempt services while the 3GPP PS data off status is "active", then the UE shall perform a reregistration of the previously registered public user identity.

B.3.1.0a IMS_Registration_handling policy

The IMS_Registration_handling policy indicates whether the UE deregisters from IMS after a configured amount of time after receiving an indication that the IMS Voice over PS Session is not supported.

The UE may support the IMS_Registration_handling policy.

If the UE supports the IMS_Registration_handling policy, the UE may support being configured with the IMS_Registration_handling policy using one or more of the following methods:

a) the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C];

b) the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the IMS_Registration_Policy node of 3GPP TS 24.167 [8G].

If the UE is configured with both the IMS_Registration_Policy node of 3GPP TS 24.167 [8G] and the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the IMS_Registration_Policy node of the EF_{IMSConfigData} file shall take precedence.

NOTE 1: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

If the UE is registered with IMS and the IMSVoPS indicator, provided by the lower layers (see 3GPP TS 24.301 [8J]), indicates voice is not supported, the UE shall:

A) if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to stay registered, the UE needs not to deregister and maintains the registration as required for IMS services; or

NOTE 2: The UE will periodically refresh the registration when needed.

B) if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to deregister and the Deregistration_Timer leaf used to configure the NoVoPS-dereg timer defined in table 7.8.1 contains a timer value for the time to wait before deregistrerting from IMS, start a timer with the value indicated in the policy and:

a) if the timer expires before the UE receives an indication from the lower layers that IMS voice is supported:

1) if there is no ongoing IMS session, either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of the IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6; or

2) if there is ongoing IMS session, and

i) if the UE does not receive indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6 as soon as the ongoing IMS based service is terminated ; or

ii) if the UE receives indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, cancel the timer; or

NOTE 3: How the UE selects reregistration or deregistration is implementation dependent (e.g., SMS service)

b) if the UE receives an indication from the lower layers that IMS voice is supported before the timer expires, cancel the timer.

If the IMS_Registration_handling policy is not configured, the UE behaviour is implementation specific.

B.3.1.1 P-Access-Network-Info header field

The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

B.3.1.1A Cellular-Network-Info header field

Not applicable.

B.3.1.2 Availability for calls

The UE indicates to the non-access stratum the status of being available for voice over PS when:

1) the UE is capable of receiving any (but not necessarily all) of the media types which the CS domain supports, such that the media type can also be used when accessing the IM CN subsystem using the current IP-CAN;

2) if the media type of item 1 is an "audio" media type, the UE supports codecs suitable for (conversational) speech, the "audio" media type is not restricted from inclusion in an SDP message according to the media type restriction policy as specified in subclause 6.1.1, and:

a) 3GPP PS data off status is "inactive";

b) 3GPP PS data off status is "active", the UE is in the HPLMN or the EHPLMN, and MMTEL voice is a 3GPP PS data off exempt service; or

c) 3GPP PS data off status is "active", the UE is in the VPLMN, the UE is configured with an indication that MMTEL voice is a 3GPP PS data off exempt service in a VPLMN, and MMTEL voice is a 3GPP PS data off roaming exempt service; and

3) the UE determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media.

The UE indicates to the non-access stratum the status of being not available for voice over PS when these conditions are no longer met.

NOTE: The status of being not available for voice over PS is used for domain selection for UE originating sessions / calls specified in 3GPP TS 23.221 [6] subclause 7.2a.

B.3.1.2A Availability for SMS

The UE determines that the UE is able to use SMS using IMS if the UE:

I) is capable of using the MIME type "application/vnd.3gpp.sms" (see 3GPP TS 24.341 [8L]), such that the MIME type can also be used when accessing the IM CN subsystem using the current IP-CAN;

II) supports the role of an SM-over-IP sender (see 3GPP TS 24.341 [8L]);

IIA) determines the PDP context used for SIP signalling exists;

III) determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media;

IV) the UE does not determine that SMS over IP is restricted in 3GPP TS 24.341 [8L] subclause 5.2.1.3; and

V) the 3GPP PS data off status is:

– "inactive";

– "active", the UE is in the HPLMN or the EHPLMN, and SMS over IMS is a 3GPP PS data off exempt service; or

– "active", the UE is in the VPLMN, the UE is configured with an indication that SMS over IMS is a 3GPP PS data off exempt service in a VPLMN, and SMS over IMS is a 3GPP PS data off roaming exempt service.

When above criteria are not matched, the UE determines that SMS using IMS is unavailable.

NOTE: The status that SMS using IMS is unavailable is used for domain selection for UE originating SMS specified in 3GPP TS 23.221 [6] subclause 7.2c.

B.3.1.3 Authorization header field

Void.

B.3.1.4 SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UE

Upon receiving an INVITE request not including the "precondition" option-tag in the Supported header field and not including the "precondition" option-tag in the Require header field, and the IP-CAN performs network-initiated resource reservation for the UE, the UE:

1) if the INVITE request contains an SDP offer and the local resources required at the terminating UE for the received SDP offer are not available:

a) shall not alert the user; and

b) shall send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. If the INVITE request includes a Supported header field indicating support of reliable provisional responses, the UE shall send the 183 (Session Progress) response reliably. In the 183 (Session Progres) response, the UE shall include an SDP answer; and

2) if the INVITE request does not contain an SDP offer and the INVITE request includes a Supported header field indicating support of reliable provisional responses:

a) shall generate an SDP offer; and

b) if the local resources required at the terminating UE for the generated SDP offer are not available:

A) shall not alert the user; and

B) shall reliably send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. In the 183 (Session Progres) response, the UE shall include the generated SDP offer.

Upon successful reservation of local resources, if the precondition mechanism is not used by the terminating UE, the UE can send 180 (Ringing) response to the INVITE request and can alert the user.

B.3.1.5 3GPP PS data off

If the 3GPP PS data off status is "active" the UE shall only send initial requests that:

1) are associated with a 3GPP IMS service which enforces 3GPP PS data off;

NOTE: These services are specified in 3GPP TS 22.011 [1C], and enforcement of 3GPP PS data off is described in the respective service specifications.

2) are associated with an emergency service; or

3) are associated with 3GPP PS data off exempt services configured in the UE using one or more of the following methods:

– the non_3GPP_ICSIs_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G] is not configured;

– the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the VPLMN;

– the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] is not configured; or

– the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN.

If the UE is configured with both the non_3GPP_ICSIs_exempt node of 3GPP TS 24.167 [8G] and the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], then the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] shall take precedence.

If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of 3GPP TS 24.167 [8G] and the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], then the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] shall take precedence.

If the 3GPP PS data off status changes from "inactive" to "active" the UE shall release all dialogs that

1) are not associated with a 3GPP IMS service which enforces 3GPP PS data off;

NOTE: These services are specified in 3GPP TS 22.011 [1C], and enforcement of 3GPP PS data off is described in the respective service specifications.

2) are not associated with an emergency service; and

3) are not associated with 3GPP data off exempt services configured in the UE using one or more of the following methods:

– the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the VPLMN;- the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] is not configured; or

– the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN.

B.3.1.6 Transport mechanisms

No additional requirements are defined.

B.3.1.7 RLOS

Not applicable.

B.3.2 Procedures at the P-CSCF

B.3.2.0 Registration and authentication

Void.

B.3.2.1 Determining network to which the originating user is attached

In order to determine from which network the request was originated the P-CSCF shall check the MCC and MNC fields received in the P-Access-Network-Info header field.

NOTE: The above check can be against more than one MNC code stored in the P-CSCF.

B.3.2.2 Location information handling

Void.

B.3.2.3 Prohibited usage of PDN connection for emergency bearer services

If the P-CSCF detects that a UE uses a PDN connection for emergency bearer services for a non-emergency REGISTER request, the P-CSCF shall reject that request by a 403 (Forbidden) response.

NOTE: By assigning specific IP address ranges for a PDN connection for emergency bearer services and configuring those ranges in P-CSCF, the P-CSCF can detect based on the registered Contact address if UE uses an emergency PDN connection for initial registration.

B.3.2.5 Void

B.3.2.6 Resource sharing

If P-CSCF supports resource sharing, PCC is supported for this access technology and if according to local policy, the P-CSCF shall apply the procedures in subclause L.3.2.6.

B.3.2.7 Priority sharing

If P-CSCF supports priority sharing, PCC is supported for this access technology and if according to operator policy, the P-CSCF shall apply the procedures in subclause L.3.2.7.

B.3.2.8 RLOS

Not applicable.

B.3.3 Procedures at the S-CSCF

B.3.3.1 Notification of AS about registration status

Not applicable

B.3.3.2 RLOS

Not applicable.