5.1 Procedures at the UE

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

5.1.0 General

The UE procedures for UE detectable emergency calls are defined in subclause 5.1.6. Exceptions to UE procedures for SIP that do not relate to emergency, are documented in subclause 5.1.6 and shall apply. These exceptions include handling of a response to a request not detected by the UE as relating to an emergency.

When sending a failure response to any received request, depending on operator policy, the UE may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "ue" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. A UE when sending a failure response will add in the URN the "side" header field parameter set to:

– "orig" for a UE-originating case; and

– "term" for a UE-terminating case.

5.1.1 Registration and authentication

5.1.1.1 General

The UE shall register public user identities (see table A.4/1 and dependencies on that major capability).

NOTE 1: The UE can use multiple Contact header field values simultaneously containing the same IP address and port number in the contact address.

In case a UE registers several public user identities at different points in time, the procedures to re-register, deregister and subscribe to the registration-state event package for these public user identities can remain uncoordinated in time.

The UE can register any one of its public user identities with any IP address acquired by the UE. The same public user identity can be bound to more than one IP address of the UE. While having valid registrations of previously registered public user identities, the UE can register any additional public user identity with any of its IP addresses. When binding any one of its public user identities to an additional contact address, the UE shall follow the procedures described in RFC 5626 [92].

If SIP digest without TLS is used, the UE shall not include signalling plane security mechanisms in the header fields defined in RFC 3329 [48] in any SIP messages.

NOTE 2: The UE determines if SIP digest is used with or without TLS based on device configuration. If SIP digest with TLS is used, then the UE includes the TLS signalling plane security mechanism in the header fields defined in RFC 3329 [48] as described in subclause 5.1.1.2.4.

SIP requests that indicate security mechanisms for both the signalling plane and the media plane can contain multiple instances or a single instance of the Security-Client, Security-Verify, or Security-Server header fields defined in RFC 3329 [48].

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT, the UE may need to modify the SIP contents according to the procedures described in either annex F or annex K.

NOTE 3: If UE populates the display-name of the Contact header field included in the REGISTER request with UE name, other UEs of the user can discover the UE name of the UE in the reg event package notification. The UE name is a text string chosen by the user allowing the user to distinguish individual UEs of the same user.

5.1.1.1A Parameters contained in the ISIM

This subclause applies when a UE contains either an ISIM or a USIM.

The ISIM shall always be used for authentication to the IM CN subsystem, if it is present, as described in 3GPP TS 33.203 [19].

The ISIM is preconfigured with all the necessary parameters to initiate the registration to the IM CN subsystem. These parameters include:

– the private user identity;

– one or more public user identities; and

– the home network domain name used to address the SIP REGISTER request

The first public user identity in the list stored in the ISIM is used in emergency registration requests.

In case the UE does not contain an ISIM, the UE shall:

– generate a private user identity;

– generate a temporary public user identity; and

– generate a home network domain name to address the SIP REGISTER request to;

in accordance with the procedures in clause C.2.

The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, UE-initiated deregistration.

The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The temporary public user identity is not barred if received by the UE in the P-Associated-URI header field.

If the UE is unable to derive the parameters in this subclause for any reason, then the UE shall not proceed with the request associated with the use of these parameters and will not be able to register to the IM CN subsystem.

5.1.1.1B Parameters provisioned to a UE without ISIM or USIM

5.1.1.1B.1 Parameters provisioned in the IMC

In case the UE contains neither an ISIM nor a USIM, but IMC is present the UE shall use preconfigured parameters in the IMC to initiate the registration to the IM CN subsystem and for authentication.

The following IMS parameters are assumed to be available to the UE:

– a private user identity;

– a public user identity; and

– a home network domain name to address the SIP REGISTER request to.

These parameters may not necessarily reside in a UICC.

The first public user identity in the list stored in the IMC is used in emergency registration requests.

5.1.1.1B.2 Parameters when UE does not contain ISIM, USIM or IMC

If the UE contains neither ISIM, nor USIM nor IMC, the UE shall generate a temporary public user identity, a private user identity and a home network domain name to address the SIP REGISTER request to, according 3GPP TS 23.003 [3].

5.1.1.2 Initial registration

5.1.1.2.1 General

The initial registration procedure consists of the UE sending an unprotected REGISTER request and, if challenged depending on the security mechanism supported for this UE, sending the integrity-protected REGISTER request or other appropriate response to the challenge. The UE can register a public user identity with any of its contact addresses at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer that can be used for SIP signalling. However, the UE shall only initiate a new registration procedure when it has received a final response from the registrar for the ongoing registration, or the previous REGISTER request has timed out.

When registering any public user identity belonging to the UE, the UE shall either use an already active pair of security associations or a TLS session to protect the REGISTER requests, or register the public user identity via a new initial registration procedure.

When binding any one of its public user identities to an additional contact address via a new initial registration procedure, the UE shall follow the procedures described in RFC 5626 [92]. The set of security associations or a TLS session resulting from this initial registration procedure will have no impact on the existing set of security associations or TLS sessions that have been established as a result of previous initial registration procedures. However, if the UE registers any one of its public user identities with a new contact address via a new initial registration procedure and does not employ the procedures described in RFC 5626 [92], then the new set of security associations or TLS session shall replace any existing set of security association or TLS session.

If the UE detects that the existing security associations or TLS sessions associated with a given contact address are no longer active (e.g., after receiving no response to several protected messages), the UE shall:

– consider all previously registered public user identities bound to this security associations or TLS session that are only associated with this contact address as deregistered; and

– stop processing all associated ongoing dialogs and transactions that were using the security associations or TLS session associated with this contact address, if any (i.e. no further SIP signalling will be sent by the UE on behalf of these transactions or dialogs).

The UE shall send the unprotected REGISTER requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, or if the UE was pre-configured with the P-CSCF’s IP address or domain name and was unable to obtain specific port information, the UE shall send the unprotected REGISTER request to the SIP default port values as specified in RFC 3261 [26].

NOTE 1: The UE will only send further registration and subsequent SIP messages towards the same port of the P-CSCF for security mechanisms that do not require to use negotiated ports for exchanging protected messages.

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B. A public user identity may be input by the end user.

On sending an unprotected REGISTER request, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be registered;

b) a To header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be registered;

c) a Contact header field set to include SIP URI(s) containing the IP address or FQDN of the UE in the hostport parameter. If the UE:

1) supports GRUU (see table A.4, item A.4/53);

2) supports multiple registrations;

3) has an IMEI available; or

4) has an MEID available;

the UE shall include a "+sip.instance" header field parameter containing the instance ID. Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks.

NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI or the MEID when the UE does not support GRUU and does not support multiple registrations does not imply any additional requirements on the network.

If the UE supports multiple registrations it shall include a "reg-id" header field parameter as described in RFC 5626 [92].

The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a 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, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].

The UE shall include the media feature tags defined in RFC 3840 [62] and RFC 5688 [120] for all supported streaming media types.

If the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing the "bnc" URI parameter.

If the UE has no specific reason not to include a user part in the URI of the contact address (eg. some UE performing the functions of an external attached network), the UE should include a user part in the URI of the contact address such that the user part is globally unique and does not reveal any private information;

NOTE 3: A time-based UUID (Universal Unique Identifier) generated as per subclause 4.2 of RFC 4122 [154] is globally unique and does not reveal any private information.

d) a Via header field set to include the sent-by field containing the IP address or FQDN of the UE and the port number where the UE expects to receive the response to this request when UDP is used. For TCP, the response is received on the TCP connection on which the request was sent. For the UDP, the UE shall also include a "rport" header field parameter with no value in the Via header field. Unless the UE has been configured to not send keep-alives, and unless the UE is directly connected to an IP-CAN for which usage of NAT is not defined, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of sending keep-alives associated with the registration, as described in RFC 6223 [143];

NOTE 4: When sending the unprotected REGISTER request using UDP, the UE transmit the request from the same IP address and port on which it expects to receive the response to this request.

e) a registration expiration interval value of 600 000 seconds as the value desired for the duration of the registration;

NOTE 5: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) the Supported header field containing the option-tag "path", and

1) if GRUU is supported, the option-tag "gruu"; and

2) if multiple registrations is supported, the option-tag "outbound".

h) if a security association or TLS session exists, and if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);

i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;

NOTE 6: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

j) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin"; and

k) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag "gin".

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall:

a) if available, store the announcement of media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, the UE may initiate that mechanism on a media level when it initiates new media in an existing session.

NOTE 7: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

a) store the expiration time of the registration for the public user identities found in the To header field value and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used);

NOTE 8: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To header field will contain the main URI of the UE.

b) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header field and bind it to the respective contact address of the UE and the associated set of security associations or TLS session;

NOTE 9: When using the respective contact address and associated set of security associations or TLS session, the UE can utilize additional URIs contained in the P-Associated-URI header field and bound it to the respective contact address of the UE and the associated set of security associations or TLS session, e.g. for application purposes.

c) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;

d) store the list of service route values contained in the Service-Route header field and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session over which the REGISTER request was sent;

NOTE 10: When multiple registration mechanism is not used, there will be only one list of service route values bound to a contact address. However, when multiple registration mechanism is used, there will be different list of service route values bound to each registration flow and the associated contact address.

NOTE 11: The UE will use the stored list of service route values to build a proper preloaded Route header field for new dialogs and standalone transactions (other than REGISTER method) when using either the respective contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session.

e) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:

– if the UE did not use the procedures specified in RFC 6140 [191] for registration, find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter or a "temp-gruu" header field parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity and the contact address that was registered; and

– if the UE used the procedures specified in RFC 6140 [191] for registration then find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter then store the value of the "pub-gruu" header field parameter for use for generating public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie" header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];

NOTE 12: When allocating public GRUUs to registering UAs the functionality within the UE that performs the role of registrar will add an "sg" SIP URI parameter that uniquenly identifies that UA to the public GRUU it received in the "pub-gruu" header field parameter. The procedures for generating a temporary GRUU using the "temp-gruu-cookie" header field parameter are specified in subclause 7.1.2.2 of RFC 6140 [191].

f) if the REGISTER request contained the "reg-id" and "+sip.instance" Contact header field parameter and the "outbound" option tag in a Supported header field, the UE shall check whether the option-tag "outbound" is present in the Require header field:

– if no option-tag "outbound" is present, the UE shall conclude that the S-CSCF does not support the registration procedure as described in RFC 5626 [92], and the S-CSCF has followed the registration procedure as described in RFC 5627 [93] or RFC 3261 [26], i.e., if there is a previously registered contact address, the S-CSCF replaced the old contact address and associated information with the new contact address and associated information (see bullet e) above). Upon detecting that the S-CSCF does not support the registration procedure as defined in RFC 5626 [92], the UE shall refrain from registering any additional IMS flows for the same private identity as described in RFC 5626 [92]; or

NOTE 13: Upon replaces the old contact address with the new contact address, the S-CSCF performs the network initiated deregistration procedure for the previously registered public user identities and the associated old contact address as described in subclause 5.4.1.5. Hence, the UE will receive a NOTIFY request informing the UE about the deregistration of the old contact address.

– if an option-tag "outbound" is present, the UE may establish additional IMS flows for the same private identity, as defined in RFC 5626 [92];

g) if available, store the announcement of media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, it may initiate that mechanism on a media level when it initiates new media in an existing session;

NOTE 14: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

h) if the Via header field contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, start to send keep-alives associated with the registration towards the P-CSCF, as described in RFC 6223 [143];

i) if a Feature-Caps header field, as specified in RFC 6809 [190] is received, a UE supporting the Feature-Caps header field shall consider the ICSI values received in the Feature-Caps header field of 200 (OK) response as supported by the IM subsystem for the established registration or registration flow (if the multiple registration mechanism is used);

NOTE 15: The UE and related applications can use the ICSI values received in the Feature-Caps header field of 200 (OK) response to improve the user experience.

j) void; and

k) if the 200 (OK) response includes a Feature-Caps header field, as specified in RFC 6809 [190], with a "+g.3gpp.verstat" header field parameter and if the UE supports calling number verification status determination, determine that the home network supports calling number verification using signature verification and attestation information, as defined in subclause 3.1.

On receiving a 305 (Use Proxy) response to the unprotected REGISTER request, unless otherwise specified in access specific annexes (as described in annex B, annex L or annex U), the UE shall:

a) ignore the contents of the Contact header field if it is included in the received message;

NOTE 16: The 305 response is not expected to contain a Contact header field.

b) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2;

c) initiate either a new P-CSCF discovery procedure as described in subclause 9.2.1, or select a new P-CSCF, if the UE was pre-configured with more than one P-CSCF’s IP addresses or domain names;

d) select a P-CSCF address, which is different from the previously used address, from the address list; and

e) perform the procedures for initial registration as described in subclause 5.1.1.2.

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:

– send another REGISTER request populating the registration expiration interval value with an expiration timer of at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) or 600 (Busy Everywhere) response or 403 (Forbidden) response for an initial registration, the UE may attempt to perform initial registration again.

When the timer F expires at the UE, the UE:

a) shall mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92] plus 5 minutes;

b) if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and

c) if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF-addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2.

NOTE 17: It is an implementation option whether these actions are also triggered by other means than expiration of timer F, e.g. based on ICMP messages.

On receiving a 4xx, 5xx (except 503) or 6xx response to the REGISTER request, whereby the response contains a Retry-After header field, the UE shall not automatically attempt an initial registration via the same IP-CAN and the same P-CSCF for the amount of time indicated in the Retry-After header field. If the UE is power cycled, the UE can attempt an initial registration. If no initial registration occurs within the time period indicated by the Retry-After header field, the counter of unsuccessful initial registration attempts is reset.

On receiving a 503 response with a Retry-After header field to the REGISTER request and the Retry-After header field indicates time bigger than the value for timer F as specified in table 7.7.1, the UE:

a) shall mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field;

c) if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2.

NOTE 18: if the Retry-After header field indicates time smaller than the value for timer F as specified in table 7.7.1, the UE continues using the currently used P-CSCF address.

For each 4xx, 5xx or 6xx response received without a Retry-After header field to the REGISTER request, the UE shall:

a) use the mechanism defined in subclause 4.5 of RFC 5626 [92] for determination of the retry delay time before each new registration attempt;

b) mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92] plus 5 minutes; and

c) initiate an initial registration as specified in subclause 5.1.1.2 after the amount of time of the last retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92]; and

– if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may initiate the initial registration using that P-CSCF; and

– if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U) and initiate the initial registration as specified in subclause 5.1.1.2.

The values of max-time and base-time (if all failed) may be provided by the network to the UE with the management objects specified in 3GPP TS 24.167 [8G]. If no values of the parameters max-time and base-time (if all failed) have been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 [92] shall be used. Other mechanisms may be used as well and are outside the scope of the present document.

NOTE 19: If the UE stops initiating initial registration, the UE can attempt to perform initial registration with the network again based on the local configuration and not wait till power-cycled. The local configuration is outside the scope of this specification.

5.1.1.2.2 Initial registration using IMS AKA

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to an empty value; and

– the "response" header field parameter, set to an empty value;

NOTE 1: If the UE specifies its FQDN in the hostport parameter in the Contact header field and in the sent-by field in the Via header field, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP address that is bound to the security association.

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security association. For details on the selection of the port values see 3GPP TS 33.203 [19].

b) additionally for the Contact header field, if the REGISTER request is protected by a security association, include the protected server port value in the hostport parameter;

c) additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association, include the protected server port value in the sent-by field; and

d) a Security-Client header field set to specify the signalling plane security mechanism the UE supports, the IPsec layer algorithms the UE supports and the parameters needed for the security association setup. The UE shall support the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters needed for the security association setup is specified in annex H of 3GPP TS 33.203 [19]. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19], and shall announce support for them according to the procedures defined in RFC 3329 [48].

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:

1) If the UE supports multiple registrations and the REGISTER request contained the "+sip.instance" header field parameter and the "reg-id" header field parameter in the Contact header field, and the "outbound" option-tag in the Supported header field, the UE shall check whether the option-tag "outbound" is present in the Require header field. If the option-tag "outbound" is present, then the UE shall use the bidirectional flow as defined in RFC 5626 [92] as follows:

a) for UDP, the bidirectional flow consists of two unidirectional flows, i.e. the first unidirectional flow is identified with the UE’s protected client port, the P-CSCF’s protected server port, and the respective IP addresses. The UE uses this flow to send the requests and responses to the P-CSCF. The second unidirectional flow is identified with the P-CSCF’s protected client port, the UE’s protected server port and the IP addresses. The second unidirectional flow is used by the UE to receive the requests and responses from the P-CSCF; or

b) for TCP, the bidirectional flow is the TCP connection between the UE and the P-CSCF. This TCP connection was established by the UE, i.e. from the UE’s protected client port and the UE’s IP address to the P-CSCF’s protected server port and the P-CSCF’s IP address. This TCP connection is used to exchange SIP messages between the UE and the P-CSCF; and

2) set the security association lifetime to the longest of either the previously existing security association lifetime (if available), or the lifetime of the just completed registration plus 30 seconds.

NOTE 3: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used.

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.1.

5.1.1.2.3 Initial registration using SIP digest without TLS

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 7616 [286] and RFC 8760 [287] unless otherwise specified in the access specific annexes, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field directive, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to an empty value; and

– the "response" header field parameter, set to an empty value;

b) the hostport parameter in the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent requests; and

c) the sent-by field in the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

The UE shall use the locally available public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration. The method whereby the public user identity and private user identity are made available to the UE is outside the scope of this document (e.g. a public user identity could be input by the end user).

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.4.

5.1.1.2.4 Initial registration using SIP digest with TLS

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field set in accordance with subclause 5.1.1.2.3 unless otherwise specified in the access specific annexes; and

b) a Security-Client header field set to specify the signalling plane security mechanism the UE supports. The UE shall support the setup of a TLS session as defined in 3GPP TS 33.203 [19]. The UE shall support the "tls" security mechanism, as specified in RFC 3329 [48]. The UE shall support TLS for integrity and confidentiality protection as defined in RFC 3261 [26], and shall announce support for them according to the procedures defined in RFC 3329 [48].

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:

a) set the TLS session lifetime to the longest of either the previously existing TLS session lifetime (if available), or the lifetime of the just completed registration plus 30 seconds.

If a UE supports TLS, then the UE shall support TLS ciphersuites as described in 3GPP TS 33.203 [19]. TLS session lifetime is determined by local configuration of the UE.

For SIP digest with TLS, the UE associates a protected server port with the TLS session port on the UE.

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.6.

5.1.1.2.5 Initial registration using NASS-IMS bundled authentication

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) optionally, an Authorization header field, with the "username" header field parameter, set to the value of the private user identity;

NOTE 1: In case the Authorization header field is absent, the mechanism only supports that one public user identity is associated with only one private user identity. The public user identity is set so that it is possible to derive the private user identity from the public user identity by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.

NOTE 2: When NASS-IMS bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

5.1.1.2.6 Initial registration using GPRS-IMS-Bundled authentication

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 7616 [286] and RFC 8760 [287] shall not be included, in order to indicate support for GPRS-IMS-Bundled authentication.

b) the Security-Client header field as defined in RFC 3329 [48] shall not contain signalling plane security mechanisms;

c) a From header field set to a temporary public user identity as defined in 3GPP TS 23.003 [3], as the public user identity to be registered;

d) a To header field set to a temporary public user identity as defined in 3GPP TS 23.003 [3], as the public user identity to be registered;

e) the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests; and

f) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

NOTE 1: Since the private user identity is not included in the REGISTER requests when GPRS-IMS-Bundled authentication is used for registration, re-registration and de-registration procedures, all REGISTER requests from the UE use the temporary IMPU as the public user identity even when the implicitly registered IMPUs are available at the UE. The UE does not use the temporary public user identity in any non-registration SIP requests.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.

NOTE 2: When GPRS-IMS-Bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

5.1.1.3 Subscription to the registration-state event package

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public user identity registered at the user’s registrar (S-CSCF) as described in RFC 3680 [43] and RFC 6665 [28].

NOTE 1: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the subscription will be directed to the main URI, as described in RFC 6140 [191].

The UE shall subscribe to the reg event package upon registering a new contact address via an initial registration procedure. If the UE receives a NOTIFY request via the newly established subscription dialog and via the previously established subscription dialogs (there will be at least one), the UE may terminate the previously established subscription dialogs and keep only the newly established subscription dialog.

The UE shall use the default public user identity for subscription to the registration-state event package.

NOTE 2: The subscription information stored in the HSS ensures that the default public user identity is a SIP URI.

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows:

a) a Request-URI set to the resource to which the UE wants to be subscribed to, i.e. to the SIP URI that is the default public user identity used for subscription;

b) a From header field set to the SIP URI that is the default public user identity used for subscription;

c) a To header field set to the SIP URI that is the default public user identity used for subscription;

d) an Event header field set to the "reg" event package;

e) an Expires header field set to 600 000 seconds as the value desired for the duration of the subscription;

f) void; and

g) void.

Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665 [28], associated with the SUBSCRIBE request, the UE shall:

1) store the information for the established dialog;

2) store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request; and

3) follow the procedures specified in RFC 6665 [28].

If continued subscription is required, the UE shall automatically refresh the subscription to the reg event package, for a previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to RFC 6665 [28]. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according to RFC 6665 [28].

5.1.1.3A Void

5.1.1.4 User-initiated reregistration and registration of an additional public user identity

5.1.1.4.1 General

The UE can perform the reregistration of a previously registered public user identity bound to any one of its contact addresses and the associated set of security associations or TLS sessions at any time after the initial registration has been completed.

The UE can perform the reregistration of a previously registered public user identity over any existing set of security associations or TLS session that is associated with the related contact address.

The UE can perform the reregistration of a previously registered public user identity via an initial registration as specified in subclause 5.1.1.2, when binding the previously registered public user identity to new contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used).

The UE can perform registration of additional public user identities at any time after the initial registration has been completed. The UE shall perform the registration of additional public user identities either:

– over the existing set of security associations or TLS sessions, if appropriate to the security mechanism in use, that is associated with the related contact address; or

– via an initial registration as specified in subclause 5.1.1.2.

The UE can fetch bindings as defined in RFC 3261 [26] at any time after the initial registration has been completed. The procedure for fetching bindings is the same as for a reregistration except that the REGISTER request does not contain a Contact header field.

Unless either the user or the application within the UE has determined that a continued registration is not required the UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less, or when the UE intends to update its capabilities according to RFC 3840 [62] and RFC 5688 [120] or when the UE needs to modify the ICSI values that the UE intends to use in a g.3gpp.icsi-ref media feature tag or IARI values that the UE intends to use in the g.3gpp.iari-ref media feature tag.

When sending a protected REGISTER request, the UE shall use a security association or TLS session associated either with the contact address or with the registration flow and the associated contact address used to send the request, see 3GPP TS 33.203 [19], established as a result of an earlier initial registration.

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be registered;

b) a To header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be registered;

c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the IP address or FQDN of the UE, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE:

1) supports GRUU (see table A.4, item A.4/53);

2) supports multiple registrations;

3) has an IMEI available; or

4) has an MEID available.

Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks.

NOTE 1: The requirement placed on the UE to include an instance ID based on the IMEI or the MEID when the UE does not support GRUU and does not support multiple registrations does not imply any additional requirements on the network.

If the UE support multiple registrations, it shall include "reg-id" header field as described in RFC 5626 [92]. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].

If a user part has previously been included in an initial REGISTER request, the UE shall use the user part which was previously used to create the binding being refreshed or removed;

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field. For the TCP, the response is received on the TCP connection on which the request was sent. If the UE previously has previously negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate continuous support to send keep-alives, as described in RFC 6223 [143];

e) a registration expiration interval value, set to 600 000 seconds as the value desired for the duration of the registration;

NOTE 2: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) the Supported header field containing the option-tag "path", and:

1) if GRUU is supported, the option-tag "gruu"; and

2) if multiple registrations is supported, the option-tag "outbound";

h) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);

i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;

NOTE 3: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

a) bind the new expiration time of the registration for this public user identity found in the To header field value either to the contact address or to the registration flow and the associated contact address used in this registration;

NOTE 4: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To header field will contain the main URI of the UE.

b) store the list of service route values contained in the Service-Route header field and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used);

NOTE 5: The stored list of service route values will be used to build a proper preloaded Route header field for new dialogs and standalone transactions (other than REGISTER method) when using either the respective contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used).

NOTE 6: If the list of Service-Route headers saved from a previous registration and bound either to this contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session already exist, then the received list of Service-Route headers replaces the old list.

NOTE 7: The UE can utilize additional URIs contained in the P-Associated-URI header field, e.g. for application purposes.

c) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:

– if the UE did not use the procedures specified in RFC 6140 [191] for registration find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter or a "temp-gruu" header field parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity and the contact address that was registered; and

– if the UE used the procedures specified in RFC 6140 [191]for registration then find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter then store the value of the "pub-gruu" header field parameter for use for generating public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie" header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];

NOTE 8: When allocating public GRUUs to registering UAs the functionality within the UE that performs the role of registrar will add an "sg" SIP URI parameter that uniquenly identifies that UA to the public GRUU it received in the "pub-gruu" header field parameter. The procedures for generating a temporary GRUU using the "temp-gruu-cookie" header field parameter are specified in subclause 7.1.2.2 of RFC 6140 [191].

d) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field and labelled with the "mediasec" header field parameter specified in subclause 7.2A.7, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, it may initiate that mechanism on a media level when it initiates new media in an existing session;

NOTE 9: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

e) if the Via header field contains a "keep" header field parameter with a value, continue to send keep-alives as described in RFC 6223 [143], towards the P-CSCF;

f) if the 200 (OK) response contains the Authentication-Info header field including a nextnonce field, store the contained nonce as a nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used); and

NOTE 10: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

g) if a Feature-Caps header field is received, a UE supporting the Feature-Caps header field shall consider the ICSI values received in the Feature-Caps header field of 200 (OK) response as supported for the established registration or registration flow (if the multiple registration mechanism is used) according to RFC 6809 [190]; and

NOTE 11: The UE and related applications can use the ICSI values received in the Feature-Caps header field to improve the user experience.

h) void.

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.1.

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response or 403 (Forbidden) response for a reregistration, the UE shall perform the procedures for initial registration as described in subclause 5.1.1.2.

On receiving a 305 (Use Proxy) response to the REGISTER request, unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U), the UE shall:

a) ignore the contents of the Contact header field if it is included in the received message;

NOTE 12: The 305 response is not expected to contain a Contact header field.

b) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2;

c) initiate either a new P-CSCF discovery procedure as described in subclause 9.2.1, or select a new P-CSCF, if the UE was pre-configured with more than one P-CSCF’s IP addresses or domain names;

d) select a P-CSCF address, which is different from the previously used address, from the address list; and

e) perform the procedures for initial registration as described in subclause 5.1.1.2.

When the timer F expires at the UE:

1) the UE shall stop processing of all ongoing dialogs and transactions associated with that flow, if any (i.e. no further SIP signalling will be sent by the UE on behalf of these transactions or dialogs); and

2) after releasing all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2:

a) the UE may select a different P-CSCF address from the list of P-CSCF addresses discovered during the procedures described in subclause 9.2.1 or from its pre-configured list of P-CSCF’s IP addresses or domain names;

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get a new set of P-CSCF-addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U);

c) the UE may perform the procedures for initial registration as described in subclause 5.1.1.2; and

d) the UE shall perform the procedures in RFC 5626 [92] to form a new flow to replace the failed one if it supports multiple registrations. If failed registration attempts occur in the process of creating a new flow, the UE shall implement the flow recovery procedures defined in subclause 4.5 of RFC 5626 [92] for determination of the retry delay time before each new registration attempt. The UE shall use the values of the parameters max-time and base-time, of the algorithm defined in subclause 4.5 of RFC 5626 [92]. If no values of the parameters max-time and base-time (if all failed) have been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 [92] shall be used.

NOTE 13: It is an implementation option whether these actions are also triggered by other means than expiration of timer F, e.g. based on ICMP messages.

5.1.1.4.2 IMS AKA as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field, with:

– the "username" header field parameter set to the value of the private user identity;

– the "realm" header field parameter directive, set to the value as received in the "realm" WWW-Authenticate header field parameter;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to last received nonce value; and

– the "response" header field parameter, set to the last calculated response value;

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security associations. For details on the selection of the protected port value see 3GPP TS 33.203 [19].

NOTE 3: If the UE is setting up an additional registration using procedures specified in RFC 5626 [92] and the UE accesses the network through 3GPP or 3GPP2 systems without any NAT, the flow is considered to be "logical flow".

b) additionally for the Contact header field, include the protected server port value in the hostport parameter;

c) additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association, include the protected server port value in the sent-by field;

d) a Security-Client header field, set to specify the signalling plane security mechanism it supports, the IPsec layer algorithms for security and confidentiality protection it supports and the new parameter values needed for the setup of two new pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; and

e) a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

On receiving the 200 (OK) response to the REGISTER request, the UE shall additionally:

a) set the security association lifetime associated with either this contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations to the longest of either the previously existing security association lifetime, or the lifetime of the just completed registration plus 30 seconds.

NOTE 4: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used.

5.1.1.4.3 SIP digest without TLS as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 7616 [286] and RFC 8760 [287], including:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to the stored nonce value for authentication for the related registration or registration flow (if the multiple registration mechanism is used); and

NOTE: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

– the "response" header field parameter, set to the challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow ( if the multiple registration mechanism is used), along with "algorithm", "cnonce", "qop", and "nc" header field parameters as specified in RFC 7616 [286] and RFC 8760 [287];

b) the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent requests; and

c) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

5.1.1.4.4 SIP digest with TLS as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field set in accordance with subclause 5.1.1.4.3;

b) the Security-Client header field set to specify the signalling plane security mechanism the UE supports. The UE shall support the setup of a TLS session as defined in 3GPP TS 33.203 [19]. The UE shall support the "tls" security mechanism, as specified in RFC 3329 [48]. The UE shall support TLS for integrity and confidentiality protection as defined in RFC 3261 [26], and shall announce support for them according to the procedures defined in RFC 3329 [48]; and

c) a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:

a) set the lifetime of the respective TLS session to the value configured.

5.1.1.4.5 NASS-IMS bundled authentication as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

a) optionally, an Authorization header field, with the "username" header field parameter, set to the value of the private user identity;

NOTE 1: In case the Authorization header field is absent, the mechanism only supports that one public user identity is associated with only one private user identity.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.

NOTE 2: When NASS-IMS bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

5.1.1.4.6 GPRS-IMS-Bundled authentication as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 7616 [286] and RFC 8760 [287] shall not be included, in order to indicate support GPRS-IMS-Bundled authentication.

b) security agreement header field values as required by RFC 3329 [48] shall not contain signalling plane security mechanisms;

c) a From header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003 [3], as the public user identity to be registered;

d) a To header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003 [3], as the public user identity to be registered;

e) the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests; and

f) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

NOTE 1: Since the private user identity is not included in the REGISTER requests when GPRS-IMS-Bundled authentication is used for registration, re-registration and de-registration procedures, all REGISTER requests from the UE use the IMSI-derived IMPU as the public user identity even when the implicitly registered IMPUs are available at the UE. The UE does not use the temporary public user identity (IMSI-derived IMPU) in any non-registration SIP requests.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.4.1, there are no additional requirements for the UE.

NOTE 2: When GPRS-IMS-Bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

5.1.1.5 Authentication

5.1.1.5.1 IMS AKA – general

Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations, deregistrations or registrations of additional public user identities. When the network requires authentication or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request.

On receiving a 401 (Unauthorized) response to the REGISTER request containing one or more WWW-Authenticate header fields the UE shall select the topmost header field that it supports (i.e. where the "algorithm" WWW-Authenticate header field parameter is "AKAv2-SHA-256" or "AKAv1-MD5"), the UE shall:

NOTE 1: The "AKAv1-MD5" algorithm is only supported for backward compatibility.

1) extract the RAND and AUTN parameters;

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 [19] i.e. the locally calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN parameter derived from the AUTN part of the challenge must be within the correct range; and

3) check the existence of the Security-Server header field as described in RFC 3329 [48]. If the Security-Server header field is not present or it does not contain the parameters required for the setup of the set of security associations (see annex H of 3GPP TS 33.203 [19]), the UE shall abandon the authentication procedure and send a new REGISTER request with a new Call-ID.

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall:

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203 [19];

2) set up a temporary set of security associations for this registration based on the static list and parameters the UE received in the 401 (Unauthorized) response and its capabilities sent in the Security-Client header field in the REGISTER request. The UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned by the P-CSCF and supported by the UE and using IK and CK (only if encryption enabled) as the shared key. The UE shall use the parameters received in the Security-Server header field to setup the temporary set of security associations. The UE shall set a temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer;

3) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field and labelled with the "mediasec" header field parameter specified in subclause 7.2A.7, if any; and

NOTE 2: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

4) send another REGISTER request towards the protected server port indicated in the response using the temporary set of security associations to protect the message. The header fields are populated as defined for the initial REGISTER request that was challenged with the received 401 (Unauthorized) response, with the addition that the UE shall include an Authorization header field containing:

– the "realm" header field parameter set to the value as received in the "realm" WWW-Authenticate header field parameter;

– the "username" header field parameter, set to the value of the private user identity;

– the "response" header field parameter that contains the RES parameter, as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "algorithm" header field parameter, set to the value received in the 401 (Unauthorized) response; and

– the "nonce" header field parameter, set to the value received in the 401 (Unauthorized) response.

The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the security association protected REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge.

NOTE 3: The Security-Client header field contains signalling plane security mechanism and if the UE supports media plane security, then media plane security mechanisms are contained, too.

On receiving the 200 (OK) response for the security association protected REGISTER request registering a public user identity with the associated contact address, the UE shall:

– change the temporary set of security associations to a newly established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 30 seconds; and

– if this is the only set of security associations available toward the P-CSCF, use the newly established set of security associations for further messages sent towards the P-CSCF. If there are additional sets of security associations (e.g. due to registration of multiple contact addresses), the UE can either use them or use the newly established set of security associations for further messages sent towards the P-CSCF as appropriate.

NOTE 4: If the UE has registered multiple contact addresses, the UE can either send requests towards the P-CSCF over the newly established set of security associations, or use different UE’s contact address and associated set of security associations when sending the requests towards the P-CSCF. Responses towards the P-CSCF that are sent via UDP will be sent over the same set of security associations that the related request was received on. Responses towards the P-CSCF that are sent via TCP will be sent over the same set of security associations that the related request was received on.

When the first request or response protected with the newly established set of security associations is received from the P-CSCF or when the lifetime of the old set of security associations expires, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all SIP transactions that use the old set of security associations are completed.

NOTE 5: If the UE has registered multiple contact addresses, the S-CSCF can use different contact address when sending the requests destined for the UE. In this case the UE will not receive the subsequent requests over the newly established set of security associations.

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security associations. The UE should send an unprotected REGISTER request according to the procedure specified in subclause 5.1.1.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF.

In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in subclause 5.1.1.5.3.

5.1.1.5.2 Void

5.1.1.5.3 IMS AKA abnormal cases

If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows:

– in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall contain no "auts" Authorization header field parameter and an empty "response" Authorization header field parameter, i.e. no authentication challenge response;

– in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the "auts" Authorization header field parameter (see 3GPP TS 33.102 [18]).

NOTE: In the case of the SQN being out of range, a "response" Authorization header field parameter can be included by the UE, based on the procedures described in RFC 3310 [49].

Whenever the UE detects any of the above cases, the UE shall:

– send the REGISTER request using an existing set of security associations, if available (see 3GPP TS 33.203 [19]);

– populate a new Security-Client header field within the REGISTER request and associated contact address, set to specify the security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the parameters needed for the new security association setup. These parameters shall contain new values for spi_uc, spi_us and port_uc; and

– not create a temporary set of security associations.

On receiving a 420 (Bad Extension) in which the Unsupported header field contains the value "sec-agree" and if the UE supports GPRS-IMS-Bundled authentication, the UE shall initiate a new authentication attempt with the GPRS-IMS-Bundled authentication procedures as specified in subclause 5.1.1.2.6.

5.1.1.5.4 SIP digest without TLS – general

NOTE 1: The MD5 algorithm is only supported for backward compatibility.

1) extract the digest-challenge parameters as indicated in RFC 7616 [286] and RFC 8760 [287] from the WWW-Authenticate header field;

2) store the contained nonce value as the nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used);

NOTE 2: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

3) calculate digest-response parameters as indicated in RFC 7616 [286] and RFC 8760 [287];

4) send another REGISTER request containing an Authorization header field. The header fields are populated as defined in subclause 5.1.1.2.3, with the addition that the UE shall include an Authorization header field containing a challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow (if the multiple registration mechanism is used) , "algorithm", "cnonce", "qop", and "nc" header field parameters as indicated in RFC 7616 [286] and RFC 8760 [287]. The UE shall set the Call-ID of the REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. If SIP digest without TLS is used, the UE shall not include RFC 3329 [48] header fields with this REGISTER.

On receiving the 200 (OK) response for the REGISTER request, if the "algorithm" Authentication-Info header field parameter is "SHA2-256", "SHA2-512/256" or "MD5", the UE shall authenticate the S-CSCF using the "rspauth" Authentication-Info header field parameter as described in RFC 7616 [286] and RFC 8760 [287]. If the nextnonce field is present in the Authentication-Info header field the UE shall store the contained nonce value as the nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used).

5.1.1.5.5 SIP digest without TLS – abnormal procedures

On receiving a 403 (Forbidden) response, the UE shall consider the registration to have failed.

5.1.1.5.6 SIP digest with TLS – general

On receiving a 401 (Unauthorized) response to the REGISTER request, the procedures in subclause 5.1.1.5.4 apply with the following differences:

– The UE shall check the existence of the Security-Server header field as described in RFC 3329 [48]. If the Security-Server header field is not present or the list of supported security mechanisms does not include "tls", the UE shall abandon the authentication procedure and send a new REGISTER request.

In the case that the 401 (Unauthorized) response to the REGISTER is deemed to be valid the UE shall:

– store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any; and

NOTE 1: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

– send another REGISTER request using the TLS session to protect the message.

The header fields are populated as defined for the initial request, with the addition that the UE shall include an Authorization header field containing a challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow (if the multiple registration mechanism is used), "algorithm", "cnonce", "qop", and "nc" header field parameters as indicated in RFC 7616 [286] and RFC 8760 [287]. The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge.

NOTE 2: The Security-Client header field contains signalling plane security mechanism and if the UE supports media plane security, then media plane security mechanisms are contained, too.

When SIP digest with TLS is used, and for the case where the 401 (Unauthorized) response to the REGISTER request is deemed to be valid, the UE shall establish the TLS session as described in 3GPP TS 33.203 [19]. The UE shall use this TLS session to send all further messages towards the P-CSCF towards the protected server port.

NOTE 3: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

5.1.1.5.7 SIP digest with TLS – abnormal procedures

On receiving a 403 (Forbidden) response, the UE shall consider the registration to have failed. If performing SIP digest with TLS, the UE should send an initial REGISTER according to the procedure specified in subclause 5.1.1.2 if the UE considers the TLS session to be no longer active at the P-CSCF.

5.1.1.5.8 NASS-IMS bundled authentication – general

NASS-IMS bundled authentication is only applicable to UEs that contain neither USIM nor ISIM. Authentication is achieved via the registration and re-registration procedures as defined in subclause 5.1.1.2 and subclause 5.1.1.4. NASS-bundled authentication is granted by the network upon receipt by the UE of a 200 (OK) response to the initial REGISTER request.

There is no separate authentication procedure.

5.1.1.5.9 NASS-IMS bundled authentication – abnormal procedures

There is no separate authentication procedure, and therefore no abnormal procedures.

5.1.1.5.10 GPRS-IMS-Bundled authentication – general

Authentication is achieved via the registration and re-registration procedures as defined in subclause 5.1.1.2 and subclause 5.1.1.4. GPRS-IMS-Bundled authentication is granted by the network upon receipt by the UE of a 200 (OK) response to the initial REGISTER request.

5.1.1.5.11 GPRS-IMS-Bundled authentication – abnormal procedures

There is no separate authentication procedure and therefore no abnormal procedures.

5.1.1.5.12 Abnormal procedures for all security mechanisms

A UE shall only respond to two consecutive invalid challenges. The UE may attempt to register with the network again after an implementation specific time.

5.1.1.5A Network-initiated re-authentication

At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described in subclause 5.1.1.3). If:

– the state attribute in any of the <registration> elements is set to "active";

– the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE registered; and

– the event attribute of that <contact> sub-element(s) is set to "shortened";

the UE shall:

1) use the expires attribute of the <contact> sub-element that the UE registered to adjust the expiration time for that public user identity; and

2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4, if required.

NOTE: When authenticating a given private user identity, the S-CSCF will only shorten the expiry time within the <contact> sub-element that the UE registered using its private user identity. The <contact> elements for the same public user identity, if registered by another UE using different private user identities remain unchanged. The UE will not initiate a reregistration procedure, if none of its <contact> sub-elements was modified.

5.1.1.5B Change of IPv6 address due to privacy

Stateless address autoconfiguration as described in RFC 2462 [20E] defines how an IPv6 prefix and an interface identifier is used by the UE to construct a complete IPv6 address.

If the UE receives an IPv6 prefix, the UE may change the interface identity of the IPv6 address as described in RFC 8981 [293] due to privacy but this can result in service discontinuity for services provided by the IM CN subsystem.

NOTE: When the UE constructs new IPv6 address by changing the interface identity, the UE can either transfer all established dialogs to new IPv6 address as specified in 3GPP TS 24.237 [8M] and subsequently relinquish the old IPv6 address, or terminate all established dialogs and transactions. While transferring the established dialogs to new IPv6 address, the UE will have double registration, i.e. one registration for the old IPv6 address and another for the new IPv6 address.

The procedure described below assumes that the UE will terminate all established dialogs and transactions and temporarily disconnect the UE from the IM CN subsystem until the new registration is performed. If the UE decides to change the IPv6 address due to privacy and terminate all established dialogs and transaction, associated with old IPv6 address, the UE shall:

1) terminate all ongoing dialogs (e.g., sessions) and transactions (e.g., subscription to the reg event) that were using the old IPv6 address;

2) deregister all registered public user identities that were using the old IPv6 address as described in subsclause 5.1.1.4;

3) construct a new IPv6 address according to the procedures specified in RFC 8981 [293];

4) register the public user identities that were deregistered in step 2 above with a new IPv6 address, as follows:

a) by performing an initial registration as described in subsclause 5.1.1.2; and

b) by performing a subscription to the reg event package as described in subsclause 5.1.1.3; and

5) subscribe to other event packages it was subscribed to before the change of IPv6 address procedure started.

To ensure a maximum degree of continuous service to the end user, the UE should transfer all established dialogs to the new IPv6 address as specified in 3GPP TS 24.237 [8M] rather than terminate all established dialogs and transactions and temporarily disconnect the UE from the IM CN subsystem as described above.

5.1.1.6 User-initiated deregistration

5.1.1.6.1 General

For any public user identity that the UE has previously registered, the UE can deregister via a single registration procedure:

– all contact addresses bound to the indicated public user identity;

– some contact addresses bound to the indicated public user identity;

– a particular contact address bound to the indicated public user identity; or

– when the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field) one or more flows bound to the indicated public user identity.

The UE can deregister a public user identity that it has previously registered with its contact address at any time. The UE shall protect the REGISTER request using a security association or TLS session that is associated with contact address, see 3GPP TS 33.203 [19], established as a result of an earlier registration, if one is available.

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs that were using the contact addresses or the flow that is going to be deregistered and related to the public user identity that is going to be deregistered or to one of the implicitly registered public user identities. However:

– if the dialog that was established by the UE subscribing to the reg event package used the public user identity that is going to be deregistered; and

– this dialog is the only remaining dialog used for subscription to reg event package of the user, i.e. there are no other contact addresses registered with associated subscription to the reg event package of the user;

then the UE shall not release this dialog.

On sending a REGISTER request that will remove the binding between the public user identity and one of its contact addresses or one of its flows, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be deregistered;

b) a To header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be deregistered;

c) a Contact header field set to the SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or FQDN, and:

1) if the UE is removing the binding between the public user identity indicated in the To header field, (together with the associated implicitly registered public user identities), and the contact address indicated in the Contact header field; and

– if the UE supports GRUU, or multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), or has an IMEI available, or has an MEID available, the Contact header field also contains the "+sip.instance" header field parameter. Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks;

– if the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), the Contact header field does not contain the "reg-id" header field parameter;

– if the UE does not supports GRUU and does not support multiple registrations (i.e. the "outbound" option tag is not included in the Supported header field), and does not have an IMEI available, and does not have an MEID available, the Contact header field does not contain either the "+sip.instance" header field parameter or the "reg-id" header field parameter;

NOTE 1: Since the contact address is deregistered, if there are any flows that were previously registered with the respective contact address, all flows terminating at the respective contact address are removed.

2) if the UE is removing the binding between the public user identity indicated in the To header field, (together with the associated implicitly registered public user identities) and one of its flows, the Contact header field contains the "+sip.instance" header field parameter and the "reg-id" header field parameter that identifies the flow; and

NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI when the UE does not support GRUU and does not support multiple registrations does not imply any additional requirements on the network.

3) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing the "bnc" URI parameter;

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field;

e) a registration expiration interval value set to the value of zero, appropriate to the deregistration requirements of the user;

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);

h) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any;

NOTE 3: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

i) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin"; and

j) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag "gin".

For a public user identity that the UE has registered with multiple contact addresses or multiple flows (e.g. via different P-CSCFs), the UE shall also be able to deregister multiple contact addresses or multiple flows, bound to its public user identity, via single deregistration proceduere as specified in RFC 3261 [26]. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a list of Contact headers. Each Contact header field is populated as specifed above in bullets a) through i).

The UE can deregister all contact addresses bound to its public user identity and associated with its private user identity. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a public user identity that is being deregistered in the To header field, and a single Contact header field with value of "*" and the Expires header field with a value of "0". The UE shall not include the "instance-id" feature tag and the "reg-id" header field parameter in the Contact header field in the REGISTER request.

NOTE 4: All entities subscribed to the reg event package of the user will be informed via NOTIFY request which contact addresses bound to the public user identity have been deregistered.

When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in subclause 5.1.1.5.1.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

– remove all registration details relating to this public user identity and the associated contact address.

NOTE 5: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

If there are no more public user identities registered with this contact address, the UE shall delete any stored media plane security mechanisms and related keys and any security associations or TLS sessions and related keys it may have towards the IM CN subsystem.

If all public user identities are deregistered and all security association or TLS session is removed, then the UE shall consider subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

5.1.1.6.2 IMS AKA as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the value as received in the "realm" WWW-Authenticate header field parameter;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to last received nonce value; and

– the response directive, set to the last calculated response value;

b) additionally for each Contact header field and associated contact address, include the associated protected server port value in the hostport parameter;

c) additionally for the Via header field, include the protected server port value bound to the security association in the sent-by field;

d) a Security-Client header field, set to specify the signalling plane security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the new parameter values needed for the setup of two new pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; and

e) a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

NOTE 2: When the UE has received the 200 (OK) response for the REGISTER request of the only public user identity currently registered with this contact address and its associated set of implicitly registered public user identities (i.e. no other public user identity is registered), the UE removes the security association (between the P-CSCF and the UE) that were using this contact address. Therefore further SIP signalling using this security association (e.g. the NOTIFY request containing the deregistration event) will not reach the UE.

5.1.1.6.3 SIP digest without TLS as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 7616 [286] and RFC 8760 [287], including:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to an empty value; and

– the "response" header field parameter, set to an empty value;

b) for each Contact header field and associated contact address include the associated unprotected port value (where the UE was expecting to receive mid-dialog requests); and

c) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

5.1.1.6.4 SIP digest with TLS as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field set in accordance with subclause 5.1.1.6.3; and

b) a Security-Client header field, set to specify the signalling plane security mechanism it supports. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; and

c) a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

5.1.1.6.5 NASS-IMS bundled authentication as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) optionally, an Authorization header field, with the "username" header field parameter, set to the value of the private user identity;

NOTE 1: In case the Authorization header field is absent, the mechanism only supports that one public user identity is associated with only one private user identity.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.6.1, there are no additional requirements for the UE.

NOTE 2: When NASS-IMS bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

5.1.1.6.6 GPRS-IMS-Bundled authentication as a security mechanism

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field as defined in RFC 7616 [286] and RFC 8760 [287] shall not be included, in order to indicate support GPRS-IMS-Bundled authentication.

b) the Security-Verify header field and the Security-Client header field values as defined by RFC 3329 [48] shall not contain signalling plane security mechanisms;

c) a From header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003 [3], as the public user identity to be deregistered;

d) a To header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003 [3], as the public user identity to be deregistered;

e) for each Contact header field and associated contact address include the associated unprotected port value (where the UE was expecting to receive mid-dialog requests); and

f) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

NOTE 1: Since the private user identity is not included in the REGISTER requests when GPRS-IMS-Bundled authentication is used for registration, re-registration and de-registration procedures, all REGISTER requests from the UE use the IMSI-derived IMPU as the public user identity even when the implicitly registered IMPUs are available at the UE. The UE does not use the temporary public user identity (IMSI-derived IMPU) in any non-registration SIP requests.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.6.1, there are no additional requirements for the UE.

NOTE 2: When GPRS-IMS-Bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

5.1.1.7 Network-initiated deregistration

Upon receipt of a NOTIFY request, on any dialog which was generated during the subscription to the reg event package as described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE, with:

1) the state attribute within the <registration> element set to "terminated", and within each <contact> element belonging to this UE, the state attribute set to "terminated" and the event attribute set either to "unregistered", or "rejected", or "deactivated", the UE shall remove all registration details relating to the respective public user identity (i.e. consider the public user identity indicated in the aor attribute of the <registration> element as deregistered); or

2) the state attribute within the <registration> element set to "active", and within a given <contact> element belonging to this UE, the state attribute set to "terminated", and the associated event attribute set either to "unregistered", or "rejected" or "deactivated", the UE shall consider the binding between the public user identity and either the contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used) indicated in the respective <contact> element as removed. The UE shall consider its public user identity as deregistered when all bindings between the respective public user identity and all contact addresses and all registration flow and the associated contact address (if the multiple registration mechanism is used) belonging to this UE are removed.

NOTE 1: When multiple registration mechanism is used to register a public user identity and bind it to a registration flow and the associated contact address, there will be one <contact> element for each registration flow and the associated contact address.

NOTE 2: If the state attribute within the <registration> element is set to "active" and the <contact> element belonging to this UE is set to "active", the UE will consider that the binding between the public user identity and either the respective contact address or the registration flow and the associated contact address as left unchanged.

In case of a "deactivated" event attribute, the UE shall start the initial registration procedure as described in subclause 5.1.1.2. In case of a "rejected" event attribute, the UE shall release all dialogs related to those public user identities.

Upon receipt of a NOTIFY request, the UE shall delete all security associations or TLS sessions towards the P-CSCF either:

– if all <registration> element(s) have their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header field contains the value of "terminated"; or

– if each <registration> element that was registered by this UE has either the state attribute set to "terminated", or the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to "terminated".

When all UE’s public user identities are registered via a single P-CSCF and the subscription dialog to the reg event package of the UE is set via the respective P-CSCF, the UE shall delete these security associations or TLS sessions towards the respective P-CSCF when all public user identities have been deregistered and after the server transaction (as defined in RFC 3261 [26]) pertaining to the received NOTIFY request terminates.

NOTE 3: Deleting a security association or TLS session is an internal procedure of the UE and does not involve any SIP procedures.

NOTE 4: If all the public user identities (i.e. <contact> elements) registered by this UE are deregistered and the security associations or TLS sessions have been removed, the UE considers the subscription to the reg event package terminated since the NOTIFY request was received with Subscription-State header field containing the value of "terminated".

5.1.2 Subscription and notification

5.1.2.1 Notification about multiple registered public user identities

Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package the UE shall perform the following actions:

– store the information for the established dialog;

– store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request;

– if a <registration> element with state attribute "active", i.e. registered, is received for one or more public user identities, the UE shall store the indicated public user identities as registered;

– if a <registration> element with state attribute "active" is received, and the UE supports GRUU (see table A.4, item A.4/53), then for each public user identity indicated in the notification that contains a <pub-gruu> element or a <temp-gruu> element or both (as defined in RFC 5628 [94]), the UE shall store the value of those elements in association with the public user identity;

– if a <registration> element with state attribute "terminated", i.e. deregistered, is received for one or more public user identities, the UE shall store the indicated public user identities as deregistered and shall remove any associated GRUUs; and

NOTE 1: There can be public user identities which are automatically registered within the registrar (S-CSCF) of the user upon registration of one public user identity or when S-CSCF receives a Push-Profile-Request (PPR) from the HSS (as described in 3GPP TS 29.228 [14]) changing the status of a public user identity associated with a registered implicit set from barred to non-barred. Usually these automatically or implicitly registered public user identities belong to the same service profile of the user and they might not be available within the UE. The implicitly registered public user identities can also belong to different service profiles. The here-described procedures provide a different mechanism (to the 200 (OK) response to the REGISTER request) to inform the UE about these automatically registered public user identities.

NOTE 2: RFC 5628 [94] provides guidance on the management of temporary GRUUs, utilizing information provided in the reg event notification.

– follow the procedures specified in RFC 6665 [28].

5.1.2.2 General SUBSCRIBE requirements

If the UE receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry-After header field, then the UE shall not automatically reattempt the request until after the period indicated by the Retry-After header field contents.

5.1.2A Generic procedures applicable to all methods excluding the REGISTER method

5.1.2A.1 UE-originating case

5.1.2A.1.1 General

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.

When the UE re-uses a previously registered contact address, the UE shall remove any parameters dedicated to registration from the Contact header field (e.g. "expires").

When the UE sends any request, the UE shall use either a given contact address that has been previously registered or a registration flow and the associated contact address (if the multiple registration mechanism is used) and shall:

– if IMS AKA is in use as a security mechanism:

a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port and the respective contact address; and

b) include the protected server port and the respective contact address in the Via header field entry relating to the UE;

– if SIP digest without TLS is in use as a security mechanism:

a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the port value of an unprotected port and the contact address where the UE expects to receive subsequent mid-dialog requests;

b) populate the Via header field of the request with the port value of an unprotected port and the respective contact address where the UE expects to receive responses to the request; and

c) if a nonce value for proxy authentication is stored for the related registration or registration flow (if the multiple registration mechanism is used), insert a Proxy-Authorization header field containing a challenge response, constructed using the stored nonce value for proxy authentication for the same registration or registration flow (if the multiple registration mechanism is used), "algorithm", "cnonce", "qop", and "nc" header field parameters as specified in RFC 7616 [286] and RFC 8760 [287];

– if SIP digest with TLS is in use as a security mechanism:

a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port;

b) include the protected server port in the Via header field entry relating to the UE; and

– if NASS-IMS bundled authentication is in use as a security mechanism, and therefore no port is provided for subsequent SIP messages by the P-CSCF during registration, the UE shall send any request to the same port used for the initial registration as described in subclause 5.1.1.2;

– if GPRS-IMS-Bundled authentication is in use as a security mechanism, and therefore no port is provided for subsequent SIP messages by the P-CSCF during registration, the UE shall send any request to the same port used for the initial registration as described in subclause 5.1.1.2.

If SIP digest without TLS is used, the UE shall not include RFC 3329 [48] header field s in any SIP messages.

When SIP digest is in use, upon receiving a 407 (Proxy Authentication Required) response to an initial request, the originating UE shall:

– extract the digest-challenge parameters as indicated in RFC 7616 [286] and RFC 8760 [287] from the Proxy-Authenticate header field;

– if the contained nonce value is associated to the realm used for the related REGISTER request authentication, store the contained nonce as a nonce value for proxy authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for proxy authentication for this registration or registration flow;

– calculate the response as described in RFC 7616 [286] and RFC 8760 [287] using the stored nonce value for proxy authentication associated to the same registration or registration flow (if the multiple registration mechanism is used); and

– send a new request containing a Proxy-Authorization header field in which the header field parameters are populated as defined in RFC 7616 [286] and RFC 8760 [287] using the calculated response.

Where a security association or TLS session exists, the UE shall discard any SIP response that is not protected by the security association or TLS session and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause 5.1.1.

For a UE performing the functions of an external attached network operating in static mode, authentication can take place without a registration based on TLS client certificate. Before any originating or terminating procedures can take place between the UE performing the functions of an external attached operating in static mode and the P-CSCF or between the UE performing the functions of an external attached network operating in static mode and the IBCF of the IMS network, for security and authentication between the UE performing the functions of an external attached network operating in static mode and the IMS network, the UE performing the functions of an external attached network operating in static mode shall use the TLS procedures according to 3GPP TS 33.310 [19D] using certificates.

In accordance with RFC 3325 [34] the UE may insert a P-Preferred-Identity header field in any initial request for a dialog or request for a standalone transaction as a hint for creation of an asserted identity (contained in the P-Asserted-Identity header field) within the IM CN subsystem.

NOTE 1: Since the S-CSCF uses the P-Asserted-Identity header field when checking whether the UE originating request matches the initial filter criteria, the P-Preferred-Identity header field inserted by the UE determines which services and applications are invoked.

When sending any initial request for a dialog or request for a standalone transaction using either a given contact address that has been previously registered or a registration flow and the associated contact address (if the multiple registration mechanism is used), the UE may include any of the following in the P-Preferred-Identity header field:

– a public user identity which has been registered by the user with the respective contact address;

– an implicitly registered public user identity returned in a registration-state event package of a NOTIFY request whose <uri> sub-element inside the <contact> sub-element of the <registration> element is the same as the contact address being used for this request and was not subsequently deregistered or that has not expired; or

– any other public user identity which the user has assumed by mechanisms outside the scope of this specification to have a current registration.

NOTE 2: The temporary public user identity specified in subclause 5.1.1.1 is not a public user identity suitable for use in the P-Preferred-Identity header field.

NOTE 3: Procedures in the network require international public telecommunication numbers when telephone numbers are used in P-Preferred-Identity header field.

NOTE 4: A number of header fields can reveal information about the identity of the user. Where privacy is required, implementers should also give consideration to other header fields that can reveal identity information. RFC 3323 [33] subclause 4.1 gives considerations relating to a number of header fields.

Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the UE shall set a display-name of the From header field to "Anonymous" as specified in RFC 3261 [26] and set an addr-spec of the From header field to Anonymous User Identity as specified in 3GPP TS 23.003 [3].

NOTE 5: The contents of the From header field are not necessarily modified by the network based on any privacy specified by the user either within the UE indication of privacy or by network subscription or network policy. Therefore the user should include the value "Anonymous" whenever privacy is explicitly required. As the user can well have privacy requirements, terminal manufacturers should not automatically derive and include values in this header field from the public user identity or other values stored in or derived from the UICC. Where the user has not expressed a preference in the configuration of the terminal implementation, the implementation should assume that privacy is required. Users that require to identify themselves, and are making calls to SIP destinations beyond the IM CN subsystem, where the destination does not implement RFC 3325 [34], will need to include a value in the From header field other than Anonymous.

The UE shall determine the public user identity to be used for this request as follows:

1) if a P-Preferred-Identity was included, then use that as the public user identity for this request; or

2) if no P-Preferred-Identity was included, then use the default public user identity for the security association or TLS session and the associated contact address as the public user identity for this request;

The UE shall not include its "+sip.instance" header field parameter in the Contact header field in its non-register requests and responses except when the request or response is guaranteed to be sent to a trusted intermediary that will remove the "+sip.instance" header field parameter prior to forwarding the request or response to the destination.

NOTE 6: Such trusted intermediaries include an AS that all such requests as part of an application or service traverse. In order to ensure that all requests or responses containing the "+sip.instance" header field parameter are forwarded via the trusted intermediary the UE needs to have first verified that the trusted intermediary is present (e.g. first contacted via a registration or configuration procedure). Including the "+sip.instance" header field parameter containing an IMEI URN does not violate RFC 7254 [153] even when the UE requests privacy using RFC 3323 [33].

If this is a request for a new dialog, the Contact header field is populated as follows:

1) a contact header value which is one of:

– if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then the UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627 [93]; or

– if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert the temporary GRUU ("temp-gruu" header field parameter) value as specified in RFC 5627 [93];

– otherwise, a SIP URI containing the contact address of the UE that has been previously registered without any contact parameters dedicated to registration procedure;

NOTE 7: The above items are mutually exclusive.

2) include an "ob" SIP URI parameter, if the UE supports multiple registrations, and the UE wants all subsequent requests in the dialog to arrive over the same flow identified by the flow token as described in RFC 5626 [92];

3) if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3841 [56B], the ICSI value (coded as specified in subclause 7.2A.8.2) for the IMS communication service. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the terminating UE(s); and

4) if the request is related to an IMS application that is supported by the UE, then the UE may include in a g.3gpp.iari-ref media feature tag, as defined in subclause 7.9.3 and RFC 3841 [56B], the IARI value (coded as specified in subclause 7.2A.9.2) that is related to the IMS application and that applies for the dialog.

If this is a request within an existing dialog, and the request includes a Contact header field, then the UE should insert the previously used Contact header field.

If the UE support multiple registrations as specified in RFC 5626 [92], the UE should include option-tag "outbound" in the Supported header field.

If this is a request for a new dialog or standalone transaction and the request is related to an IMS communication service that requires the use of an ICSI then the UE:

1) shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that is related to the request in a P-Preferred-Service header field according to RFC 6050 [121]. If a list of network supported ICSI values was received as specified in 3GPP TS 24.167 [8G], the UE shall only include an ICSI value that is in the received list;

NOTE 8: The UE only receives those ICSI values corresponding to the IMS communication services that the network provides to the user.

2) may include an Accept-Contact header field containing an ICSI value (coded as specified in subclause 7.2A.8.2) that is related to the request in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 if the ICSI for the IMS communication service is known. The UE may remove one or more subclasses from an ICSI when including it in an Accept-Contact header field provided that the included ICSI corresponds to an IMS communication service.

NOTE 9: If the UE includes the same ICSI values into the Accept-Contact header field and the P-Preferred-Service header field, there is a possibility that one of the involved S-CSCFs or an AS changes the ICSI value in the P-Asserted-Service header field, which results in the message including two different ICSI values (one in the P-Asserted-Service header field, changed in the network and one in the Accept-Contact header field).

If an IMS application indicates that an IARI is to be included in a request for a new dialog or standalone transaction, the UE shall include an Accept-Contact header field containing an IARI value (coded as specified in subclause 7.2A.9.2) that is related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841 [56B].

NOTE 10: RFC 3841 [56B] allows multiple Accept-Contact header fields along with multiple Reject-Contact header fields in a SIP request, and within those header fields, expressions that include one or more logical operations based on combinations of media feature tags. Which registered UE will be contacted depends on the Accept-Contact header field and Reject-Contact header field combinations included that evaluate to a logical expression and the relative qvalues of the registered contacts for the targeted registered public user identity. There is therefore no guarantee that when multiple Accept-Contact header fields or additional Reject-Contact header field(s) along with the Accept-Contact header field containing the ICSI value or IARI value are included in a request that the request will be routed to a contact that registered the same ICSI value or IARI value. Charging and accounting is based upon the contents of the P-Asserted-Service header field and the actual media related contents of the SIP request and not the Accept-Contact header field contents or the contact reached.

NOTE 11: The UE only includes the header field parameters "require" and "explicit" in the Accept-Contact header field containing the ICSI value or IARI value if the IMS communication service absolutely requires that the terminating UE understand the IMS communication service in order to be able to accept the session. Including the header field parameters "require" and "explicit" in Accept-Contact header fields in requests which don’t absolutely require that the terminating UE understand the IMS communication service in order to accept the session creates an interoperability problem for sessions which otherwise would interoperate and violates the interoperability requirements for the ICSI in 3GPP TS 23.228 [7].

After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with RFC 3323 [33], and the additional requirements contained within RFC 3325 [34].

If resource priority in accordance with RFC 4412 [116] is required for a dialog, then the UE shall include the Resource-Priority header field in all requests associated with that dialog.

NOTE 12: The case where the UE is unaware of the requirement for resource priority because the user requested the capability as part of the dialstring falls outside the scope of this requirement. Such cases can exist and will need to be dealt with by an appropriate functional entity (e.g. P-CSCF) to process the dialstring. For certain national implementations, signalling of a Resource-Priority header field to or from a UE is not required.

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall insert a P-Access-Network-Info header field into any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see subclause 7.2A.4). Insertion of the P-Access-Network-Info header field into the ACK request is optional.

NOTE 13: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header field in any request or response within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).

NOTE 14: The value of the P-Access-Network-Info header field could be stale if the point of attachment of the UE with the network changes before the message is received by the network.

The UE shall build a proper preloaded Route header field value for all new dialogs and standalone transactions. The UE shall build a list of Route header field values made out of the following, in this order:

a) the P-CSCF URI containing the IP address acquired at the time of the P-CSCF discovery procedures which was used in registration of the contact address (or registration flow); and

NOTE 15: If the UE is provisioned with or receives a FQDN at the time of the P-CSCF discovery procedures, the FQDN is resolved to an IP address at the time of the P-CSCF discovery procedures.

b) the P-CSCF port based on the security mechanism in use:

– if IMS AKA or SIP digest with TLS is in use as a security mechanism, the protected server port learnt during the registration procedure;

– if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is in use as a security mechanism, the unprotected server port used during the registration procedure;

c) and the values received in the Service-Route header field saved from the 200 (OK) response to the last registration or re-registration of the public user identity with associated contact address.

NOTE 16: When the UE registers multiple contact addresses, there will be a list of Service-Route headers for each contact address. When sending a request using a given contact address and the associated security associations or TLS session, the UE will use the corresponding list of Service-Route headers to construct a list of Route headers.

The UE may indicate that proxies should not fork the request by including a "no-fork" directive within the Request-Disposition header field in the request as described in RFC 3841 [56B].

If a request is for a new dialog or standalone transaction, and the request matches a trigger for starting logging of SIP signalling, as described in RFC 8497 [140] and configured in the trace management object defined in 3GPP TS 24.323 [8K], the UE shall:

– start to log SIP signalling for this dialog; and

– in any requests or responses sent on this dialog, append a "logme" header field parameter to the SIP Session-ID header field.

If a request or response is sent on a dialog for which logging of signalling is in progress, the UE shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 [140] and configured in the trace management object defined in 3GPP TS 24.323 [8K].

a) If a stop trigger event has occurred, the UE shall stop logging of signalling; or

b) if a stop trigger event has not occurred, the UE shall:

– in any requests or responses sent on this dialog, append a "logme" header field parameter to the SIP Session-ID header field; and

– log the request.

If the UE receives a 1xx or 200 (OK) response to an initial request for a dialog, the response containing a P-Asserted-Identity header field set to an emergency number as specified in 3GPP TS 22.101 [1A], the UE procedures in subclause 5.1.6.10 apply.

If the UE receives a 3xx response containing a Contact header field:

1) if the 3xx response is a 380 (Alternative Service) response to an INVITE request the response containing a P-Asserted-Identity header field with a value equal to the value of the last entry of the Path header field value received during registration and the response contains a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2) then the UE shall select a domain in accordance with the conventions and rules specified in 3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B], and:

– if the CS domain is selected, the UE behavior is defined in subclause 7.1.2 of 3GPP TS 23.167 [4B] and, where appropriate, in the access technology specific annex;

– if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt; and

2) if the response is:

– not a 380 (Alternative Service) response; or

– a 380 (Alternative Service) response, and the response:

i. does not contain a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2); or

ii. does contain a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2), and the response;

I) does not contain a P-Asserted-Identity header field; or

II) does contain a P-Asserted-Identity header field with a value not equal to the value of the last entry of the Path header field value received during registration;

the UE should not automatically recurse on the Contact header field without first indicating the identity of the user to which a request will be sent and obtaining authorisation of the served user.

NOTE 17: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

NOTE 18: A UE can still automatically recurse on 3xx responses as part of a service if the nature of the service enables the UE to identify 3xx responses as having originated from the home network and networks trusted by the home network and the nature of the service ensures that the charging for the requests sent as a result of the 3xx response is correlated with the original request.

NOTE 19: Automatically recursing on untrusted 3xx responses opens up the UE to being redirected to premium rate URIs without the user’s consent.

The UE performing the functions of an external attached network operating in static mode shall send all requests using the already established TLS session as described in this subclause.

A UE supporting RFC 4028 [58], when it receives a 422 (Session Interval Too Small) to an INVITE request where the response contains a Min-SE header field, shall retry the request in accordance with RFC 4028 [58] subclause 7.4.

5.1.2A.1.2 Structure of Request-URI

The UE may include a SIP URI complying with RFC 3261 [26], a tel URI complying with RFC 3966 [22], a pres URI complying with RFC 3859 [179], an im URI complying with RFC 3860 [180] or a mailto URI complying with RFC 2368 [181].

NOTE: This version of the document does not specify how the UE determines the host part of the SIP URI.

The UE may use non-international formats of E.164 numbers or non-E.164 numbers, including geo-local numbers and home-local numbers and other local numbers (e.g. private number), in the Request-URI.

The actual value of the URI depends on whether user equipment performs an analysis of the dial string input by the end user or not, see subclauses 5.1.2A.1.3 and 5.1.2A.1.4.

5.1.2A.1.3 UE without dial string processing capabilities

In this case the UE does not perform any analysis of the dial string. This requires that the dialling plan is designed so it enables the network to differentiate local numbers from other numbers.

The dial string is sent to the network, in the Request-URI of a initial request or a stand alone transaction, using one of the following formats:

1) a tel-URI, syntactically complying with RFC 3966 [22], with the dial string encoded as a local number followed by a "phone-context" tel URI parameter value;

EXAMPLE: tel:00447700900123;phone-context=example.com

2) a SIP URI, syntactically complying with RFC 3261 [26], with the user=phone parameter, embedding a tel-URI with a "phone-context" tel URI parameter value;

EXAMPLE: sip:00447700900123;

phone-context=example.com@example.com;user=phone

3) a SIP URI, complying with RFC 3261 [26] and RFC 4967 [103], with the user=dialstring parameter and with a "phone-context" tel-URI parameter value in the user part; or

EXAMPLE: sip:00447700900123;

phone-context=example.com@example.com;user=dialstring

4) a SIP URI syntactically complying with RFC 3261 [26], where the user part contains the dial string and the domain name is specific enough to enable to network to understand that the user part contains a dial string.

EXAMPLE: sip:00447700900123@dialstrings.entreprise.com

For cases 1), 2), and 3) the UE shall set the "phone-context" tel URI parameter in accordance with subclause 5.1.2A.1.5.

5.1.2A.1.4 UE with dial string processing capabilities

In this case the UE performs sufficient dial string analysis (or receives an explicit indication from the user) to identify the type of numbering that is used and processes the dial string accordingly before building the Request-URI.

If the UE detects that a local dialling plan is being used, where the UE is able to identify a global telephone number, the UE shall translate the number into E.164 international format after removing all dial string elements used for local numbering detection purposes (e.g. escape codes).

If the UE detects that a local (private or public) dialling plan is being used and the UE is not able to identify a global number, it may decide to send the dial string unchanged to the network as described in subclause 5.1.2A.1.3 or the UE may decide to alter it to comply with the local numbering plan (e.g. remove all dial string elements used for local numbering detection).

In the latter case the local numbering information is sent using one of the following formats:

1) a tel-URI, complying with RFC 3966 [22], with a local number followed by a "phone-context" tel-URI parameter value;

2) a SIP URI, complying with RFC 3261 [26], with the "user" SIP URI parameter set to "phone" and a user part embedding a local number with a phone-context parameter; and

3) if the UE intends to send information related to supplementary services, a SIP URI, complying with RFC 3261 [26] and RFC 4967 [103], with the "user" SIP URI parameter set to "dialstring" and with a "phone-context" tel URI parameter value in the user part.

The UE shall set the "phone-context" tel URI parameter in accordance with subclause 5.1.2A.1.5.

NOTE: The way how the UE process the dial-string and handles special characters (e.g. pause) in order to produce a conformant SIP URI or tel-URI according to RFC 3966 [22] is implementation specific.

As a general rule, recognition of special service numbers shall take priority over other dialling plan issues. If the dial string equates to a pre-configured service URN as specified in RFC 5031 [69]) then the service-urn should be sent.

5.1.2A.1.5 Setting the "phone-context" tel URI parameter

When the UE uses home-local number, the UE shall include in the "phone-context" tel URI parameter the home network domain name in accordance with RFC 3966 [22].

When the UE uses geo-local number, the UE shall:

– if access technology information available to the UE (i.e., the UE can insert P-Access-Network-Info header field into the request), include the access technology information in the "phone-context" tel URI parameter according to RFC 3966 [22] as defined in subclause 7.2A.10; and

– if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-Info header field into the request), include in the "phone-context" tel URI parameter the home network domain name prefixed by the "geo-local." string according to RFC 3966 [22] as defined in subclause 7.2A.10.

When the UE uses other local numbers, than geo-local number or home local numbers, e.g. private numbers that are different from home-local number or the UE is unable to determine the type of the dialled number, the UE shall include a "phone-context" tel URI parameter set according to RFC 3966 [22], e.g. if private numbers are used a domain name to which the private addressing plan is associated. The "phone-context" value used in the case of other local numbers shall be different from "phone-context" values used with geo-local numbers and home-local numbers.

NOTE 1: The "phone-context" tel URI parameter value can be entered or selected by the subscriber, or can be a "pre-configured" value (e.g. using OMA-DM with the management object specified in 3GPP TS 24.167 [8G]) inserted by the UE.

NOTE 2: The way how the UE determines whether numbers in a non-international format are geo-local, home-local or relating to another network in absence of matching UE configuration in subclause 5.1.2A.1.5A, is implementation specific.

NOTE 3: Home operator’s local policy can define a prefix string(s) to enable subscribers to differentiate dialling a geo-local number and/or a home-local number.

5.1.2A.1.5A Policy on local numbers

Policy on local numbers consists of zero or more parts of policy on local numbers

A part of policy on local numbers indicates an IMS communication service (identified by an ICSI) in which the UE is to use a number in non-international format without associated "phone-context" value as:

1) a geo-local number; or

2) a home-local number.

The UE may support the policy on local numbers.

If the UE supports the policy on local numbers:

1) if:

a) the upper layers provide a number in non-international format to be included in Request-URI of a SIP request;

b) the upper layers do not provide a "phone-context" value associated with the number;

c) the UE is not configured to associate a particular "phone-context" value with the number; and

d) the SIP request is related to an IMS communication service (identified by an ICSI) indicated in a part of the policy on local numbers such that:

i) the part of the policy on local numbers indicates to use the number as a geo-local number, then the UE shall use the number as a geo-local number in subclause 5.1.2A.1.5; and

ii) the part of the policy on local numbers indicates to use the number as a home-local number, then the UE shall use the number as a home-local number in subclause 5.1.2A.1.5; and

2) the UE may support being configured with the policy on local numbers using one or more of the following methods:

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

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

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

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

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

5.1.2A.1.6 Abnormal cases

In the event the UE receives a 504 (Server Time-out) response containing:

1) a P-Asserted-Identity header field set to a value equal to a URI:

a) from the Service-Route header field value received during registration; or

b) from the Path header field value received during registration; and

NOTE 1: If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field and Service-Route header field values. The Path header field value and Service-Route header field value corresponding to the flow on which the 504 (Server Time-out) response was received are checked.

2) a Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field, independent of the value or presence of Content-Disposition parameters,

then the following treatment is applied:

a) if the 504 (Server Time-out) response includes an IM CN subsystem XML body as described in subclause 7.6 with the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element:

A) with the <type> child element set to "restoration" (see table 7.6.2); and

B) with the <action> child element set to "initial-registration" (see table 7.6.3);

then the UE:

– shall initiate S-CSCF restoration procedures by performing an initial registration as specified in subclause 5.1.1.2; and

– may provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element.

NOTE 2: If the UE has discovered multiple P-CSCF addresses and has information that the P-CSCF was unable to forward the request resulting in sending back the 504 (Server Time-out) response, when starting the initial registration it is appropriate for the UE to select a P-CSCF address different from the one used for the registration binding on which the 504 (Server Time-out) response was received.

– if timer F expires in the "Trying" state of non-INVITE client transaction as described in IETF RFC 3261 [26];

– if a fatal transport error is reported by the transport layer in the "Trying" state of non-INVITE client transaction as described in IETF RFC 3261 [26];

– if timer B expires in the "Calling" state of INVITE client transaction as described in IETF RFC 6026 [163]; or

– if a fatal transport error is reported by the transport layer in "Calling" state of INVITE client transaction as described in IETF RFC 6026 [163];

then the UE shall:

1) if the multiple registration mechanism is not used:

A) consider the contact address as not bound to any public user identity;

B) mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable;

C) if there is a locally stored P-CSCF addressas specified in subclause 5.1.9 which is different than thecurrently used P-CSCF address and which is not marked as unavailable, initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and

D) if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, get a new set of P-CSCF addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2; and

2) if the multiple registration mechanism is used, declare the registration flow dead as defined in RFC 5626 [92] and mark the currently used P-CSCF address as unavailable.

NOTE 3: When a fatal transport error occurs, further steps might be necessary to restore the transport layer, possibly including re-establishment of an IP-CAN bearer.

When sending a request from a contact address that has been previously registered (or via a registration flow if the multiple registration mechanism is used) which is bound to a public user identity by registration which used a P-CSCF address, and if a 503 (Service Unavailable) response without a Retry-After header field is received for request as described in IETF RFC 3261 [26], the UE shall:

1) if the multiple registration mechanism is not used:

A) consider the contact address as not bound to any public user identity;

B) mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable;

C) if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and

2) if the multiple registration mechanism is used, declare the registration flow dead as defined in RFC 5626 [92] and mark the currently used P-CSCF address as unavailable.

When sending a request from a contact address that has been previously registered (or via a registration flow if the multiple registration mechanism is used) which is bound to a public user identity by registration which used a P-CSCF address, and if a 503 (Service Unavailable) response with a Retry-After header field is received for request as described in IETF RFC 3261 [26] and :

– if the request was a non-INVITE request, the Retry-After header field indicates a time bigger than value for timer F as specified in table 7.7.1; and

– if the request was an INVITE request, the Retry-After header field indicates a time bigger than value for timer B as specified in table 7.7.1;

the UE shall:

1) if the multiple registration mechanism is not used:

A) consider the contact address as not bound to any public user identity;

B) mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable for the time indicated by the Retry-After header field;

C) if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and

2) if the multiple registration mechanism is used, declare the registration flow dead as defined in RFC 5626 [92] and mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field.

NOTE 4: if the Retry-After header field indicates time smaller than the value for timer F or timer B as specified in table 7.7.1, the UE continues using the currently used P-CSCF address.

5.1.2A.2 UE-terminating case

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.

Where a security association or TLS session exists, the UE shall discard any SIP request that is not protected by the security association or TLS session and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause 5.1.1.

If an initial request contains an Accept-Contact header field containing the g.3gpp.icsi-ref media feature tag with an ICSI value, the UE should invoke the IMS application that is the best match for the ICSI value.

If an initial request contains an Accept-Contact header field containing the g.3gpp.iari-ref media feature tag with an IARI value the UE should invoke the IMS application that is the best match for the IARI value.

The UE can receive multiple ICSI values, IARI values or both in an Accept-Contact header field. In this case it is up to the implementation which of the multiple ICSI values or IARI values the UE takes action on.

NOTE 1: The application verifies that the contents of the request (e.g. SDP media capabilities, Content-Type header field) are consistent with the ICSI value in the g.3gpp.icsi-ref media feature tag and IARI value contained in the g.3gpp.iari-ref media feature tag.

If an initial request does not contain an Accept-Contact header field containing a g.3gpp.icsi-ref media feature tag or a g.3gpp.iari-ref media feature tag the UE shall invoke the application that is the best match based on the contents of the request (e.g. SDP media capabilities, Content-Type header field, media feature tag).

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with RFC 3323 [33], and the additional requirements contained within RFC 3325 [34].

NOTE 2: In the UE-terminating case, this version of the document makes no provision for the UE to provide a P-Preferred-Identity in the form of a hint.

NOTE 3: A number of header fields can reveal information about the identity of the user. Where, privacy is required, implementers should also give consideration to other header fields that can reveal identity information. RFC 3323 [33] subclause 4.1 gives considerations relating to a number of header fields.

NOTE 4: Such trusted intermediaries include an AS that all such requests as part of an application or service traverse. In order to ensure that all requests or responses containing the "+sip.instance" header field parameter are forwarded via the trusted intermediary the UE needs to have first verified that the trusted intermediary is present (e.g first contacted via a registration or configuration procedure). Including the "+sip.instance" header field parameter containing an IMEI URN does not violate RFC 7254 [153] even when the UE requests privacy using RFC 3323 [33].

If the response includes a Contact header field, and the response is sent within an existing dialog, and the Contact address previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact header field as specified in RFC 5627 [93].

If the response includes a Contact header field, and the response is not sent within an existing dialog, the Contact header field is populated as follows:

1) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does not indicate privacy of the contents of the P-Asserted-Identity header field, then the UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627 [93];

2) if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does indicate privacy of the P-Asserted-Identity, then should insert the temporary GRUU ("temp-gruu" header field parameter) value in the Contact header field as specified in RFC 5627 [93];

NOTE 5: The above items 1 and 2 are mutually exclusive.

3) if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3841 [56B] the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service and then the UE may include the IARI value for any IMS application that applies for the dialog, (coded as specified in subclause 7.2A.9.2), that is related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841 [56B]. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the originating UE(s) and other IARI values for the IMS application that is related to the IMS communication service; and

4) if the request is related to an IMS application that is supported by the UE when the use of an ICSI is not needed, then the UE may include the IARI value (coded as specified in subclause 7.2A.9.2), that is related to any IMS application and that applies for the dialog, in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841 [56B].

If the UE did not insert a GRUU in the Contact header field then the UE shall include a contact address that has been previously registered with contact parameters used for registration removed and a port in the address in the Contact header field as follows:

– if IMS AKA or SIP digest with TLS is being used as a security mechanism, the protected server port value as in the initial registration; or

– if SIP digest without TLS is being used as a security mechanism, the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. The UE shall set the unprotected port value to the port value used in the initial registration.

If the UE receives a Resource-Priority header field in accordance with RFC 4412 [16] in an initial request for a dialog, then the UE shall include the Resource-Priority header field in all requests associated with that dialog.

NOTE 6: For certain national implementations, signalling of a Resource-Priority header field to and from a UE is not required.

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall insert a P-Access-Network-Info header field into any response to a request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method (see subclause 7.2A.4).

The terminating UE shall not include the P-Early-Media header field in any SIP messages, unless the terminating UE is a UE performing the functions of an external attached network that is allowed to send early media.

a) If a stop trigger event has occurred, the UE shall stop logging of signalling; or

b) if a stop trigger event has not occurred, the UE shall:

– in any requests or responses sent on this dialog, append a "logme" header field parameter to the SIP Session-ID header field; and

– log the request or response.

The UE shall not support RFC 7090 [209] (see table A.4, item A.4/116) and, in this version of the specification, the UE shall not perform any specific procedures beyond those defined in RFC 3261 [26] for the Priority header field.

NOTE 7: The mechanism specified in RFC 7090 [209] is based on the presence of a trust domain for the Priority header field in the operator’s network. The UE is not aware whether a trust domain for the Priority header field exists in the operator’s network.

If the terminating UE needs to retrieve the last service access number when the AS applies a number translation as described in subclause 5.7.1.22; the terminating UE can find the requested service access number in the hi-entry within the History-Info header field having a hi-index that match the "mp" or "rc" header field parameter value of the last hi-entry containing a "cause" SIP URI parameter, defined in RFC 4458 [68], set to the value "380" defined in RFC 8119 [230]. If no "mp" or "rc" header field parameter is received in the concerned hi-entry, the service access number can be found in the hi-entry preceding the hi-entry with the "cause" SIP URI parameter set to "380".

If the terminating UE

a) supports calling number verification status determination;

b) during registration determined that the home network supports calling number verification using signature verification as and attestation information, as defined in subclause 3.1; and

c) receives initial INVITE request for a dialog or a MESSAGE request containing a P-Asserted-Identity header field or a From header field with a "verstat" tel URI parameter in a tel URI or a SIP URI with a user=phone parameter;

then the terminating UE shall:

a) determine the calling number verification status based on the "verstat" tel URI parameter value; and

b) if unable to determine the calling number verification status based on the "verstat" parameter value, discard the parameter and treat the P-Asserted-Identity header field and the From header field in the same way as if the parameter would not have been included.

5.1.3 Call initiation – UE-originating case

5.1.3.1 Initial INVITE request

Where multiple domains exist for initiating a call/session, before sending an initial INVITE request, the UE shall perform access domain selection in accordance with the appropriate specification for the IP-CAN in use, taking into account the media to be requested. Access domain selection allows the policy of the network operator to be taken into account before the initial INVITE request is sent. Access dependent aspects of access domain selection are defined in the access technology specific annexes for each access technology.

Upon generating an initial INVITE request, the UE shall include the Accept header field with "application/sdp", the MIME type associated with the 3GPP IM CN subsystem XML body (see subclause 7.6.1) and any other MIME type the UE is willing and capable to accept.

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64].

The preconditions mechanism should be supported by the originating UE.

If the precondition mechanism is disabled as specified in subclause 5.1.5A, the UE shall not use the precondition mechanism.

The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource reservation.

NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.

In order to allow the peer entity to reserve its required resources, if the precondition mechanism is enabled as specified in subclause 5.1.5A; the originating UE supporting the precondition mechanism should make use of the precondition mechanism, even if it does not require local resource reservation.

Upon generating an initial INVITE request using the precondition mechanism, the UE shall:

– indicate the support for reliable provisional responses and specify it using the Supported header field; and

– indicate the support for the preconditions mechanism and specify it using the Supported header field.

Upon generating an initial INVITE request using the precondition mechanism, the UE shall not indicate the requirement for the precondition mechanism by using the Require header field.

During the session initiation, if the originating UE indicated the support for the precondition mechanism in the initial INVITE request and:

a) the received response with an SDP body includes a Require header field with "precondition" option-tag, the originating UE shall include a Require header field with the "precondition" option-tag:

– in subsequent requests that include an SDP body, that the originating UE sends in the same dialog as the response is received from; and

– in responses with an SDP body to subsequent requests that include an SDP body and include "precondition" option-tag in Supported header field or Require header field received in-dialog; or

b) the received response with an SDP body does not include the "precondition" option-tag in the Require header field,

– in subsequent requests that include an SDP body, the originating UE shall not include a Require or Supported header field with "precondition" option-tag in the same dialog;

– in responses with an SDP body to subsequent requests with an SDP body but without "precondition" option-tag in the Require or Supported header field, the originating UE shall not include a Require or Supported header field with "precondition" option-tag in the same dialog; and

– in responses with an SDP body to subsequent requests with an SDP body and with "precondition" option-tag in the Require or Supported header field, the originating UE shall include a Require header field with "precondition" option-tag in the same dialog.

NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. The UE can accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited number of simultaneous transactions or early dialogs.

If the precondition mechanism is used, the UE shall, upon successful reservation of local resources, confirm the successful resource reservation (see subclause 6.1.2) within the next SIP request.

NOTE 3: The next SIP request will be either a PRACK request or an UPDATE request.

NOTE 4: The UE can receive a P-Early-Media header field authorizing an early-media flow while the required preconditions, if any, are not met and/or the flow direction is not enabled by the SDP direction parameter. According to RFC 5009 [109], an authorized early-media flow can be established only if the necessary conditions related to the SDP negotiation are met. These conditions can evolve during the session establishment.

NOTE 5: When the UE is confirming the successful resource reservation using an UPDATE request (or a PRACK request) and the UE receives a 180 (Ringing) response or a 200 (OK) response to the initial INVITE request before receiving a 200 (OK) response to the UPDATE request (or a 200 (OK) response to the PRACK request), the UE does not treat this as an error case and does not release the session.

NOTE 6: The UE procedures for rendering of the received early media and of the locally generated communication progress information are specified in 3GPP TS 24.628 [8ZF].

If the UE wishes to receive early media authorization indications, as described in RFC 5009 [109], the UE shall add the P-Early-Media header field with the "supported" parameter to the initial INVITE request.

A UE supporting the Session Timer extension as described in RFC 4028 [58] may support the extension being configured using Session_Timer_Support node specified in 3GPP TS 24.167 [8G].

If the UE supports the Session Timer extension, the UE shall include the option-tag "timer" in the Supported header field and should either insert a Session-Expires header field with the header field value set to the configured session timer interval value, or should not include the Session-Expires header field in the initial INVITE request. The header field value of the Session-Expires header field may be configured using local configuration or using the Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G]. If the UE is configured with both the local configuration and the Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G], then the local configuration shall take precedence.

If the UE inserts the Session-Expires header field in the initial INVITE request, the UE may also include the "refresher" parameter with the "refresher" parameter value set to "uac".

When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall not progress any remaining early dialogs to established dialogs. Therefore, upon the reception of a subsequent final 200 (OK) response for an INVITE request (e.g., due to forking), the UE shall:

1) acknowledge the response with an ACK request; and

2) send a BYE request to this dialog in order to terminate it.

Upon receiving a 488 (Not Acceptable Here) response to an initial INVITE request, the originating UE should send a new INVITE request containing SDP according to the procedures defined in subclause 6.1.

NOTE 7: An example of where a new request would not be sent is where knowledge exists within the UE, or interaction occurs with the user, such that it is known that the resulting SDP would describe a session that did not meet the user requirements.

Upon receiving a 421 (Extension Required) response to an initial INVITE request in which the precondition mechanism was not used, including the "precondition" option-tag in the Require header field, if the UE supports the precondition mechanism and the precondition mechanism is enabled as specified in subclause 5.1.5A, the originating UE shall:

– send a new INVITE request using the precondition mechanism; and

– send an UPDATE request as soon as the necessary resources are available and a 200 (OK) response for the first PRACK request has been received.

Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header field, then the originating UE shall not automatically reattempt the request via the same P-CSCF until after the period indicated by the Retry-After header field contents.

The UE may include a "cic" tel URI parameter in a tel URI, or in the userinfo part of a SIP URI with user=phone, in the Request-URI of an initial INVITE request if the UE wants to identify a user-dialed carrier, as described in RFC 4694 [112].

NOTE 8: The method whereby the UE determines when to include a "cic" tel-URI parameter and what value it should contain is outside the scope of this document (e.g. the UE could use a locally configured digit map to look for special prefix digits that indicate the user has dialled a carrier).

NOTE 9: The value of the "cic" tel-URI parameter reported by the UE is not dependent on UE location (e.g. the reported value is not affected by roaming scenarios).

In the event the UE receives a 380 (Alternative Service) response to an initial INVITE request the response containing a P-Asserted-Identity header field with a value equal to the value of the last entry of the Path header field value received during registration and the response containing a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2), the UE shall select a domain in accordance with the conventions and rules specified in 3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B], and:

– if the CS domain is selected, the UE behavior is defined in subclause 7.1.2 of 3GPP TS 23.167 [4B] and, where appropriate, in the access technology specific annex; and

– if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt.

NOTE 10: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

Upon receiving a 199 (Early Dialog Terminated) provisional response to an established early dialog the UE shall release resources specifically related to that early dialog.

The UE shall include the media feature tags defined in RFC 3840 [62] and RFC 5688 [120] for all supported streaming media types in the initial INVITE request.

If the UE sends a CANCEL request to cancel an initial INVITE request, the UE shall when applicable include in the CANCEL request a Reason header field with a protocol value set to "RELEASE_CAUSE" and a "cause" header field parameter as specified in subclause 7.2A.18.11.2. The UE may also include the "text" header field parameter with reason-text as specified in subclause 7.2A.18.11.2.

Upon receiving a 500 (Server Internal Error) response to an initial INVITE request including a Reason header field with a protocol value set to "FAILURE_CAUSE" and a cause header field parameter value set to "1" as specified in subclause 7.2A.18.12.2 and a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:p-cscf.orig>", the UE can determine that the QoS or bearer resources in the originating IP-CAN is not available.

5.1.4 Call initiation – UE-terminating case

5.1.4.1 Initial INVITE request

The preconditions mechanism should be supported by the terminating UE.

The handling of incoming initial INVITE requests at the terminating UE is mainly dependent on the following conditions:

– the specific service requirements for "integration of resource management and SIP" extension (hereafter in this subclause known as the precondition mechanism and defined in RFC 3312 [30] as updated by RFC 4032 [64], and with the request for such a mechanism known as a precondition);

– the UEs configuration for the case when the specific service does not require the precondition mechanism; and

– the precondition disabling policy specified in subclause 5.1.5A, if supported by the UE.

If an initial INVITE request is received the terminating UE shall check whether the terminating UE requires local resource reservation.

NOTE 1: The terminating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.

During the session initiation, if local resource reservation is required at the terminating UE and the terminating UE supports the precondition mechanism, and:

a) the received INVITE request includes the "precondition" option-tag in the Supported header field or Require header field and the precondition mechanism is enabled as specified in subclause 5.1.5A, the terminating UE shall use the precondition mechanism and shall include a Require header field with the "precondition" option-tag:

– in responses to that INVITE request if those responses include an SDP body;

– in responses to subsequent requests received in-dialog that include an SDP body and include "precondition" option-tag in Supported header field or Require header field; and

– in subsequent requests that include an SDP body, that it sends towards the originating UE during the session initiation;

b) the received INVITE request includes the "precondition" option-tag in the Supported header field, and the precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall not use the precondition mechanism:

c) the received INVITE request includes the "precondition" option-tag in the Require header field, and the precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall reject the INVITE request with a 420 (Bad Extension) response; and

d) the received INVITE request does not include the "precondition" option-tag in the Supported header field or Require header field, the terminating UE shall not use the precondition mechanism.

During the session initiation, if local resource reservation is not required by the terminating UE and the terminating UE supports the precondition mechanism and:

a) the received INVITE request includes the "precondition" option-tag in the Supported header field and:

i) the required resources at the originating UE are not reserved, and the precondition mechanism is enabled as specified in subclause 5.1.5A, the terminating UE shall use the precondition mechanism and shall include a Require header field with the "precondition" option-tag:

– in responses to that INVITE request if those responses include an SDP body;

– in responses with an SDP body to subsequent requests received in-dialog that include an SDP body and include "precondition" option-tag in Supported header field or Require header field; and

– in subsequent requests that include an SDP body, that it sends towards the originating UE during the session initiation;

ii) the required local resources at the originating UE and the terminating UE are available and the precondition mechanism is enabled as specified in subclause 5.1.5A, the terminating UE may use the precondition mechanism; and

iii) the precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall not use the precondition mechanism;

b) the received INVITE request does not include the "precondition" option-tag in the Supported header field or Require header field, the terminating UE shall not use the precondition mechanism;

c) the received INVITE request includes the "precondition" option-tag in the Require header field and the precondition mechanism is enabled as specified in subclause 5.1.5A, the terminating UE shall use the precondition mechanism; and

d) the received INVITE request includes the "precondition" option-tag in the Require header field, and the precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall reject the INVITE request with a 420 (Bad Extension) response.

NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26].

NOTE 3: If the terminating UE does not support the precondition mechanism it will apply regular SIP session initiation procedures.

If the received INVITE request indicated support for reliable provisionable responses, but did not require their use and the terminating UE supports reliable provisional responses, and if:

a) the terminating UE requires a reliable alerting indication at the originating side;

b) the 18x response (other than 183 response) carries SDP or for other application related purposes that requires its reliable transport; or

c) the reliable 18x policy indicates (see subclause 5.1.4.2) the UE to do so;

the terminating UE shall send the 18x response (other than 183 response) reliably.

NOTE 4: If the terminating UE is configured by the home operator to send the 18x response (other than 183 response) reliably and the received INVITE request did not indicate support for reliable provisional responses, then the terminating UE sends the 18x response (other than 183 response) unreliably.

The terminating UE shall send the 18x responses (other than 183 response) unreliably if the reliable 18x policy (see subclause 5.1.4.2) indicates the UE to do so, unless the received INVITE request requires to use reliable provisional responses.

NOTE 5: Certain applications, services and operator policies might mandate the terminating UE to send a 199 (Early Dialog Terminated) provisional response (see RFC 6228 [142]) prior to sending a non-2xx final response to the INVITE request.

If the terminating UE uses the precondition mechanism, upon successful reservation of local resources:

– if the originating side requested confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE, the terminating UE shall confirm the successful resource reservation (see subclause 6.1.3) within an SIP UPDATE request; and

NOTE 6: Originating side requests confirmation for the result of the resource reservation at the terminating UE e.g. when an application server performs 3rd party call control. The request for confirmation for the result of the resource reservation at the terminating UE can be included e.g. in the SDP answer in the PRACK request.

– if the originating side did not request confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE, the terminating UE shall not confirm the successful resource reservation (see subclause 6.1.3) within an UPDATE request.

NOTE 7: The terminating UE can send an UPDATE request for reasons other than confirmation of the successful resource reservation.

NOTE 8: If the terminating UE supports the precondition mechanism and has indicated the resources are not available or sufficient during SDP negotiation, the UE sends 180 (Ringing) response after the resources on the terminating side are successfully reserved.

If the terminating UE included an SDP offer or an SDP answer in a reliable provisional response to the INVITE request and both the terminating UE and the originating UE support UPDATE method, then in order to remove one or more media streams negotiated in the session for which a final response to the INVITE request has not been sent yet, the terminating UE shall send an UPDATE request with a new SDP offer and delays sending of 200 (OK) response to the INVITE request till after reception of 200 (OK) response to the UPDATE request.

If the user does not accept a media stream accepted in the SDP answer and the terminating UE, the originating UE or both do not support the UPDATE method, then after reception of ACK request related to 200 (OK) response to the INVITE request, the UE shall modify the session.

The terminating UE shall include the media feature tags defined in RFC 3840 [62] and RFC 5688 [120] for all supported streaming media types in the SIP response other than the 100 (Trying) response to the SIP INVITE request.

If the received INVITE request was received over a registration for which the 200 (OK) contained a Feature-Caps header field including the "+sip.607" header field parameter the UE may send a 607 (Unwanted) response as specified in RFC 8197 [254].

NOTE 9: 607 (Unwanted) response is normally sent after user interaction.

If the terminating UE supports the Session Timer extension, as described in RFC 4028 [58], and if the received INVITE request includes the "timer" option tag in the Supported header field, then the terminating UE shall behave as described in RFC 4028 [58] with the following clarification:

– If the received INVITE request does not contain the Session-Expires header field, then the terminating UE shall include a Session-Expires header field with the header field value set to the greater of the configured session timer interval value or the value contained in the Min-SE header field (if present, in the received INVITE), and the "refresher" parameter set to the configured "refresher" parameter value in the 200 (OK) response to the INVITE request. The session timer interval value may be configured using local configuration or the Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G]. If the UE is configured with both the local configuration and the Session_Timer_Initial_Interval node, then the local configuration shall take precedence. The"refresher" parameter value may be configured using local configuration or using the Session_Timer_Initial_MT_Refresher node specified in 3GPP 24.167 [8G]. If the UE is configured with both the local configuration and the Session_Timer_Initial_MT_Refresher node, then the local configuration shall take precedence;

– If the received INVITE request includes the "timer" option tag in the Supported header field and contains the Session-Expires header field without "refresher" parameter, then the terminating UE shall include a Session-Expires header field with the "refresher" parameter set to the configured "refresher" parameter value in the 200 (OK) response to the INVITE request, and shall set the header field value of the Session-Expires header field of the 200 (OK) response to the INVITE request to the value received in the INVITE request. The "refresher" parameter value may be configured using local configuration or using the Session_Timer_Initial_MT_Refresher node specified in 3GPP 24.167 [8G]. If the UE is configured with both the local configuration and the Session_Timer_Initial_MT_Refresher node specified in 3GPP 24.167 [8G], then the local configuration shall take precedence; or

– If the received INVITE request contains the Session-Expires header field with "refresher" parameter, then the terminating UE shall include a Session-Expires header field with the "refresher" parameter set to the received "refresher" parameter value in the 200 (OK) response to the INVITE request, and shall set the header field value of the Session-Expires header field of the 200 (OK) response to the INVITE request to the value received in the INVITE request.

5.1.4.2 Reliable 18x Policy

The reliable 18x policy consists of one or more reliable 18x policy parts.

The reliable 18x policy part consists of a mandatory send 18x reliably configuration and an optional ICSI condition.

A 18x response (other than 183 response) to an INVITE request is to be sent reliably according to the reliable 18x policy if:

1) an INVITE request indicates support for reliable provisional responses; and

2) the terminating UE supports reliable provisional responses;

and if the reliable 18x policy contains a reliable 18x policy part such that:

1) the send 18x reliably configuration indicates to send 18x responses reliably; and

2) the following is true:

a) the corresponding INVITE request is subject to an IMS communication service identified in the ICSI condition of the reliable 18x policy part; or

b) the reliable 18x policy part does not have the ICSI condition.

A 18x response (other than 183 response) to an INVITE request is to be sent unreliably according to the reliable 18x policy if the INVITE request does not require use of reliable provisional responses and the reliable 18x policy contains a reliable 18x policy part such that:

1) the send 18x reliably configuration indicates to send 18x responses unreliably; and

2) the following is true:

a) the corresponding INVITE request is subject to an IMS communication service identified in the ICSI condition of the reliable 18x policy part; or

b) the reliable 18x policy part does not have the ICSI condition.

If the INVITE request is subject to an IMS communication service which does not match the ICSI condition in any of the reliable 18x policy parts and if there is no reliable 18x policy part without ICSI, it is IMS communication service and/or implemention dependent whether to send the SIP 18x responses reliably.

NOTE 1: Some IMS communication services require that SIP 18x responses are not sent reliably. Mandating that the UE send all SIP 18x responses reliably could prevent those IMS communication services from operating correctly.

The UE may support the reliable 18x policy.

The UE may support being configured with the reliable 18x policy using one or more of the following methods:

a) the Reliable_18x_policy node of the EF_IMSConfigData file described in 3GPP TS 31.102 [15C];

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

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

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

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

5.1.4A Session modification

5.1.4A.0 General

This subclause applies after the 2xx response to the initial INVITE request has been sent or received.

5.1.4A.1 Generating session modification request

If the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, the UE shall indicate support of the precondition mechanism during a session modification. If the precondition mechanism was not used during the session establishment, the UE shall not indicate support of the precondition mechanism during a session modification.

In order to indicate support of the precondition mechanism during a session modification, upon generating a reINVITE request, an UPDATE request with an SDP body, or a PRACK request with an SDP body, the UE shall:

a) indicate the support for the precondition mechanism using the Supported header field;

b) not indicate the requirement for the precondition mechanism using the Require header field; and

c) if a re-INVITE request is being generated, indicate the support for reliable provisional responses using the Supported header field;

and follow the SDP procedures in clause 6 for the precondition mechanism.

5.1.4A.2 Receiving session modification request

Upon receiving a reINVITE request, an UPDATE request, or a PRACK request that indicates support for the precondition mechanism by using the Supported header field or requires use of the precondition mechanism by using the Require header field, the UE shall:

a) if the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, use the precondition mechanism for the session modification; and

b) if the precondition mechanism was not used during the session establishment, and:

1) if the use of the precondition mechanism is required using the Require header field, reject the request by sending a 420 (Bad Extension) response; and

2) if the support of the precondition mechanism is indicated using the Supported header field, not use the precondition mechanism for the session modification.

If the precondition mechanism is used for the session modification, the UE shall indicate support for the preconditions mechanism, using the Require header field, in responses that include an SDP body, to the session modification request.

5.1.5 Call release

If the UE sends a BYE request, the UE shall when applicable include in the BYE request a Reason header field with a protocol value set to "RELEASE_CAUSE" and a "cause" header field parameter as specified in subclause 7.2A.18.11.2. The UE may also include the "text" header field parameter with reason-text as specified in subclause 7.2A.18.11.2.

If the UE sends a BYE request, due to the call being unwanted, and the received INVITE request was received over a registration for which the 200 (OK) contained a Feature-Caps header field including the "+sip.607" header field parameter, the UE shall include in the BYE request a Reason header field with a protocol value set to "SIP" and a "cause" header field parameter set to "607" as specified in RFC 8197 [254]. The UE may also include the "text" header field parameter with reason-text as specified in RFC 8197 [254].

5.1.5A Precondition disabling policy

The precondition disabling policy indicates whether the UE is allowed to use the precondition mechanism or whether the UE is not allowed to use the precondition mechanism.

If the precondition disabling policy is not configured, the precondition disabling policy is assumed to indicate that the UE is allowed to use the precondition mechanism.

The UE may support the precondition disabling policy.

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

a) the Precondition_disabling_policy node of the EF_IMSConfigData file described in 3GPP TS 31.102 [15C];

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

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

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

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

The precondition mechanims is disabled, if the UE supports the precondition disabling policy and the precondition disabling policy indicates that the UE is not allowed to use the precondition mechanism.

The precondition mechanism is enabled, if:

1) the UE does not support the precondition disabling policy; or

2) the UE supports the precondition disabling policy and the precondition disabling policy indicates that the UE is allowed to use the precondition mechanism.

5.1.6 Emergency service

5.1.6.1 General

A CS and IM CN subsystem capable UE shall follow the conventions and rules specified in 3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B] to select the domain for the emergency call attempt. If the CS domain is selected, the UE shall attempt an emergency call setup using appropriate access technology specific procedures.

NOTE 1: For CS systems based on 3GPP TS 24.008 [8], clause B.5 applies.

The UE shall determine, whether it is currently attached to its home operator’s network (e.g. HPLMN or subscribed SNPN) or to a different network than its home operator’s network (e.g. VPLMN or non-subscribed SNPN) by applying access technology specific procedures described in the access technology specific annexes.

If the IM CN subsystem is selected and the UE is currently attached to its home operator’s network (e.g. HPLMN or subscribed SNPN) and the UE is currently registered and the IP-CAN does not define emergency bearers, the UE shall attempt an emergency call as described in subclause 5.1.6.8.4.

If the IM CN subsystem is selected and the UE is currently attached to its home operator’s network (e.g. HPLMN or subscribed SNPN) and the UE is currently registered and the IP-CAN defines emergency bearers and the core network has indicated that it supports emergency bearers, the UE shall:

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and

2) attempt an emergency call as described in subclause 5.1.6.8.3.

If the IM CN subsystem is selected and the UE is currently attached to its home operator’s network (e.g. HPLMN or subscribed SNPN) and the UE is not currently registered, the UE shall:

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and

2) attempt an emergency call as described in subclause 5.1.6.8.3.

If the IM CN subsystem is selected and the UE is attached to a different network than its home operator’s network (e.g. VPLMN or non-subscribed SNPN), the UE shall:

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and

2) attempt an emergency call as described in subclause 5.1.6.8.3.

If the UE supports the emerg-reg timer defined in table 7.8.1, the UE shall start the emerg-reg timer when the UE decides that an emergency call is to be established via the IM CN subsystem. The UE shall stop the timer when the UE determines that an initial emergency registration, as described in subclause 5.1.6.2, is not required or upon receipt of any final SIP response during the initial emergency registration. When the emerg-reg timer expires, the UE shall:

1) if the initial REGISTER request for the initial emergency registration has been sent, consider that the emergency registration attempt for this P-CSCF has failed. The UE may retry registration on a different P-CSCF and if the UE has no more available P-CSCFs the UE considers the emergency registration to have failed and applies the procedures related to emergency registration failure that are defined in 3GPP TS 23.167 [4B] subclause 6.1; and

2) if the initial REGISTER request for the initial emergency registration has not been sent:

– if the UE has successfully established an IP-CAN bearer for an emergency session, consider that the emergency registration attempt for this P-CSCF has failed. The UE may retry registration on a different P-CSCF and if the UE has no more available P-CSCFs the UE considers the emergency registration to have failed and applies the procedures related to emergency registration failure that are defined in 3GPP TS 23.167 [4B] subclause 6.1; or

– if the UE has not successfully established an IP-CAN bearer for an emergency session, consider that the attempt to set up the emergency call via the IM CN subsystem has failed, abort any ongoing IP-CAN procedures for the emergency registration, and apply the procedures for domain selection as defined in 3GPP TS 23.167 [4B] clause H.5.

The UE may support being pre-configured for the Emerg-reg timer using one or more of the following methods:

a) the Timer_Emerg-reg leaf of the EF_IMSConfigData file described in 3GPP TS 31.102 [15C];

b) the Timer_Emerg-reg leaf of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the Timer_Emerg-reg leaf of 3GPP TS 24.167 [8G].

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

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

If the IM CN subsystem is selected and the UE has no credentials the UE can make an emergency call without being registered. The UE shall attempt an emergency call as described in subclause 5.1.6.8.2.

An IP-CAN can, dependent on the IP-CAN capabilities, provide local emergency numbers (including information about emergency service categories or information about emergency service URNs) to the UE which has that capability, in order for the UE to recognize these numbers as emergency call.

5.1.6.2 Initial emergency registration

When the user initiates an emergency call, if emergency registration is needed (including cases described in subclause 5.1.6.2A), the UE shall perform an emergency registration prior to sending the SIP request related to the emergency call.

The UE shall have only one valid emergency registration at any given time. If the UE initiates a new emergency registration using different contact address, and the previous emergency registration has not expired, the UE shall consider the previous emergency registration as expired.

IP-CAN procedures for emergency registration are defined in 3GPP TS 23.167 [4B] and in each access technology specific annex.

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2 with the following additions and modifications:

a) the UE shall include a "sos" SIP URI parameter in the Contact header field as described in subclause 7.2A.13, indicating that this is an emergency registration and that the associated contact address is allowed only for emergency service; and

b) the UE shall populate the From and To header fields of the REGISTER request with:

– the first entry in the list of public user identities provisioned in the UE;

– the default public user identity obtained during the normal registration, if the UE is not provisioned with a list of public user identites, but the UE is currently registered to the IM CN subsystem; and

– the derived temporary public user identity, in all other cases.

When the UE performs an initial emergency registration and whilst this emergency registration is active, the UE shall:

– handle the emergency registration independently from any other ongoing registration to the IM CN subsystem;

– handle any signalling or media related IP-CAN for the purpose of emergency calls independently from any other established IP-CAN for IM CN subsystem related signalling or media; and

– handle all SIP signalling and all media related to the emergency call independently from any other ongoing IM CN subsystem signalling and media.

If:

1) the UE receives a 420 (Bad Extension) response to the REGISTER request for initial emergency registration containing an "sos" SIP URI parameter in the Contact header field;

2) the UE does not support GPRS-IMS-Bundled authentication; and

3) the response contains a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2) and <action> child element set to "anonymous-emergencycall" (see table 7.6.3);

the UE shall attempt an emergency call as described in subclause 5.1.6.8.2.

If:

1) the UE receives a 403 (Forbidden) response to the REGISTER request for initial emergency registration containing an "sos" SIP URI parameter in the Contact header field; and

2) the response contains a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2) and <action> child element set to "anonymous-emergencycall" (see table 7.6.3);

the UE shall attempt an emergency call as described in subclause 5.1.6.8.2.

5.1.6.2A New initial emergency registration

The UE shall perform a new initial emergency registration, as specified in subclause 5.1.6.2, if the UE determines that:

– it has previously performed an emergency registration which has not yet expired; and

– it has obtained an IP address from the serving IP-CAN, as specified in subclause 9.2.1, different than the IP address used for the emergency registration.

5.1.6.3 Initial subscription to the registration-state event package

Upon receiving the 200 (OK) to the REGISTER request that completes the emergency registration, the UE shall not subscribe to the reg event package of the public user identity specified in the REGISTER request.

5.1.6.4 User-initiated emergency reregistration

The UE shall perform user-initiated emergency reregistration as specified in subclause 5.1.1.4 if half of the time for the emergency registration has expired and:

– the UE has emergency related ongoing dialog;

– standalone transactions exist; or

– the user initiates an emergency call.

The UE shall not perform user-initiated emergency reregistration in any other cases.

5.1.6.5 Authentication

When a UE performs authentication a UE shall perform the procedures as specified in subclause 5.1.1.5.

5.1.6.6 User-initiated emergency deregistration

Once the UE registers a public user identity and an associated contact address via emergency registration, the UE shall not perform user-initiated deregistration of the respective public user identity and the associated contact address.

NOTE: The UE will be deregistered when the emergency registration expires.

5.1.6.7 Network-initiated emergency deregistration

An emergency registration will not be deregistered by the network (see subclause 5.4.8.4).

5.1.6.8 Emergency session setup

5.1.6.8.1 General

The UE shall translate any user indicated emergency number as specified in 3GPP TS 22.101 [1A] to an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69].

When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 is initiated:

– in event other than reception of a 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method as defined in procedures in subclause 5.1.2A.1.1, subclause 5.1.3.1, subclause 5.1.6.8.1, subclause 5.1.6.8.3 and subclause 5.1.6.8.4; or

– upon reception of a 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method as defined in procedures in subclause 5.1.2A.1.1, subclause 5.1.3.1, subclause 5.1.6.8.1, subclause 5.1.6.8.3 and subclause 5.1.6.8.4, and the 380 (Alternative Service) response does not contain a Contact header field containing a service URN with a top-level service type of "sos",

the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 shall include one of the following service URNs:

– "urn:service:sos", "urn:service:sos.ambulance", "urn:service:sos.police", "urn:service:sos.fire", "urn:service:sos.marine", "urn:service:sos.mountain", "urn:service:sos.ecall.manual", "urn:service:sos.ecall.automatic". If the UE can determine the type of emergency service the UE shall use an emergency service URN with a sub-service type corresponding to the type of emergency service.

– as derived from the information about emergency service URNs provided with local emergency numbers (see subclause 5.1.6.1).

NOTE 1: A service URN with a top-level service type of "sos" is used only when the user intends to establish an emergency call.

NOTE 2: In countries where a type of emergency service is required, due to national regulations, an emergency call request with emergency service URN "urn:service:sos" can fail.

When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 is initiated upon reception of 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method as defined in procedures in subclause 5.1.2A.1.1, subclause 5.1.3.1, subclause 5.1.6.8.1, subclause 5.1.6.8.3 and subclause 5.1.6.8.4, and if the 380 (Alternative Service) response contains a Contact header field containing a service URN with a top-level service type of "sos", the UE shall set the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 to the service URN of the Contact header field of the 380 (Alternative Service) response.

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response including a 3GPP IM CN subsystem XML body as described in subclause 7.6 that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2), the UE shall automatically send an ACK request to the P-CSCF as per normal SIP procedures and terminate the session. In addition, if the 380 (Alternative Service) response includes a P-Asserted-Identity header field with a value equal to the value of the last entry on the Path header field value received during registration:

– the UE may also provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element; and

– one of subclause 5.1.6.8.3 or subclause 5.1.6.8.4 applies.

NOTE 3: Emergency numbers which the UE does not detect, will be treated as a normal call.

NOTE 4: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

If the UE supports the emerg-request timer defined in Table 7.8.1, the UE shall start the emerg-request timer when sending the initial INVITE request for emergency service. The UE shall stop the timer upon receipt of any 18x provisional SIP response. When the emerg-request timer expires, the UE shall consider that the emergency service request has failed and apply the procedures related to emergency service request failure that are defined in 3GPP TS 23.167 [4B] subclause 7.3 with clarifications in clause H.5. The UE may support being configured for the emerg-request timer using one or more of the following methods:

a) the Timer_Emerg-request leaf of the EF_IMSConfigData file described in 3GPP TS 31.102 [15C];

b) the Timer_Emerg-request leaf of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the Timer_Emerg-request leaf of 3GPP TS 24.167 [8G].

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

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

5.1.6.8.2 Emergency session set-up in case of no registration

When establishing an emergency session for an unregistered user, the UE is allowed to receive responses to emergency requests and requests inside an established emergency session on the unprotected ports. The UE shall reject or silently discard all other messages not arriving on a protected port. Additionally, the UE shall transmit signalling packets pertaining to the emergency session from the same IP address and unprotected port on which it expects to receive signalling packets containing the responses to emergency requests and the requests inside the established emergency session.

Prior to establishing an emergency session for an unregistered user, the UE shall acquire a local IP address, discover a P-CSCF, and establish an IP-CAN bearer that can be used for SIP signalling. The UE shall send only the initial INVITE requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE shall send the initial INVITE request to the SIP default port values as specified in RFC 3261 [26].

The UE shall apply the procedures as specified in subclause 5.1.2A.1 and subclause 5.1.3 with the following additions:

1) the UE shall set the From header field of the INVITE request to "Anonymous" as specified in RFC 3261 [26];

2) the UE shall include a service URN in the Request-URI of the initial INVITE request in accordance with subclause 5.1.6.8.1;

NOTE 1: Other specifications make provision for emergency service identifiers, which are not specifically the emergency service URN, to be recognised in the UE. Emergency service identifiers which the UE does not detect will be treated as a normal call by the UE.

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

4) if available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request. Insertion of the P-Access-Network-Info header field into the ACK request is optional. The UE shall populate the P-Access-Network-Info header field with the current point of attachment to the IP-CAN as specified for the access network technology (see subclause 7.2A.4). The P-Access-Network-Info header field contains the location identifier such as the cell id, the line id or the identity of the WLAN access node, which is relevant for routeing the emergency call;

5) if defined by the access technology specific annex, the UE shall populate the P-Preferred-Identity header field in the INVITE request with an equipment identifier as a SIP URI. The special details of the equipment identifier to use depend on the IP-CAN;

6) a Contact header field set to include SIP URI that contains in the hostport parameter the IP address of the UE and an unprotected port where the UE will receive incoming requests belonging to this dialog. The UE shall also include a "sip.instance" media feature tag containing Instance ID as described in RFC 5626 [92]. The UE shall not include either the public or temporary GRUU in the Contact header field;

7) a Via header field set to include the IP address of the UE in the sent-by field and for the UDP the unprotected server port value where the UE will receive response to the emergency request, while for the TCP, the response is received on the TCP connection on which the emergency request was sent. For the UDP, the UE shall also include "rport" header field parameter with no value in the top Via header field. Unless the UE has been configured to not send keep-alives, and unless the UE is directly connected to an IP-CAN for which usage of NAT is not defined, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of sending keep-alives associated with, and during the lifetime of, the emergency session, as described in RFC 6223 [143];

NOTE 2: The UE inserts the same IP address and port number into the Contact header field and the Via header field, and sends all IP packets to the P-CSCF from this IP address and port number.

8) if the UE has its location information available, or a URI that points to the location information, the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

– if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119 [90] and RFC 5491 [267], include the location object in a message body with the content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation header field value, as described RFC 6442 [89], and include a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

NOTE 3: If the location information is old or inaccurate, the UE does not consider location information to be available.

9) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

10) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

NOTE 4: It is suggested that UE’s only use the option of providing a URI when the domain part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is inapplicable in this area.

11) if support of the current location discovery during an emergency call is allowed in the IP-CAN specific annex and the UE supports the current location discovery during an emergency call, the UE shall include a Recv-Info header field as described in RFC 6086 [25], indicating the g.3gpp.current-location-discovery info package name and shall include an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type.

NOTE 5: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header field in any request or response within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).

The UE shall build a proper preloaded Route header field value for all new dialogs. The UE shall build a Route header field value containing only the P-CSCF URI (containing the unprotected port number and the IP address acquired at the time of the P-CSCF discovery procedures which was used in registration of the contact address (or registration flow).

NOTE 6: If the UE is provisioned with or receives a FQDN at the time of the P-CSCF discovery procedures, the FQDN is resolved to an IP address at the time of the P-CSCF discovery procedures.

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F expired, as described in subclause 5.1.1.4.

NOTE 7: It is an implementation option whether these actions are also triggered by other means.

NOTE 8: A number of header fields can reveal information about the identity of the user. Where privacy is required, implementers should also give consideration to other header fields that can reveal identity information. RFC 3323 [33] subclause 4.1 gives considerations relating to a number of header fields.

NOTE 9: RFC 3261 [26] provides for the use of the Priority header field with a suggested value of "emergency". It is not precluded that emergency sessions contain this value, but such usage will have no impact on the processing within the IM CN subsystem.

If the response for the initial INVITE request indicates that the UE is behind NAT, and the INVITE request was sent over TCP connection, the UE shall keep the TCP connection during the entire duration of the emergency session. In this case the UE will receive all responses to the emergency requests and the requests inside the established emergency session over this TCP connection.

If the Via header field of any provisional response, or of the final 200 (OK) response, for the initial INVITE request contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, the UE shall start to send keep-alives associated with the session towards the P-CSCF, as described in RFC 6223 [143].

5.1.6.8.3 Emergency session set-up within an emergency registration

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A and 5.1.3 with the following additions:

1) the UE shall insert in the INVITE request, a From header field that includes the public user identity registered via emergency registration or the tel URI associated with the public user identity registered via emergency registration, as described in subclause 4.2;

2) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with subclause 5.1.6.8.1;

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

4) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the P-Access-Network-Info header field shall contain a location identifier such as the cell id, line id or the identity of the WLAN access node, which is relevant for routeing the IMS emergency call;

NOTE 1: The IMS emergency specification in 3GPP TS 23.167 [4B] describes several methods how the UE can get its location information from the access network or from a server. Such methods are not in the scope of this specification.

5) the UE shall insert in the INVITE request, one or two P-Preferred-Identity header field(s) that include the public user identity registered via emergency registration or the tel URI associated with the public user identity registered via emergency registration as described in subclause 4.2;

NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.

6) void;

7) if the UE has its location information available, or a URI that points to the location information, then the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

NOTE 3: If the location information is old or inaccurate, the UE does not consider location information to be available.

8) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

9) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

10) if support of the current location discovery during an emergency call is allowed in the IP-CAN specific annex and the UE supports the current location discovery during an emergency call, the UE shall include a Recv-Info header field as described in RFC 6086 [25], indicating the g.3gpp.current-location-discovery info package name and shall include an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type.

NOTE 5: RFC 3261 [26] provides for the use of the Priority header field with a suggested value of "emergency". It is not precluded that emergency sessions contain this value, but such usage will have no impact on the processing within the IM CN subsystem.

In the event the UE receives a 380 (Alternative Service) response with a P-Asserted-Identity header field with a value equal to the value of the last entry on the Path header field value received during registration, and the Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field, independent of the value or presence of Content-Disposition parameters, then the following treatment is applied:

1) if the 380 (Alternative Service) response includes a 3GPP IM CN subsystem XML body as described in subclause 7.6 the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2), then the UE shall:

a) if the CS domain is available to the UE, and no prior attempt using the CS domain for the current emergency call attempt has been made, attempt emergency call via CS domain using appropriate access technology specific procedures;

b) if the CS domain is not available to the UE or the emergency call has already been attempted using the CS domain, then perform one of the following actions:

– if the <action> child element of the <alternative-service> child element of the <ims-3gpp> element in the IM CN subsystem XML body as described in subclause 7.6 is set to "emergency-registration" (see table 7.6.3), perform an initial emergency registration using a different VPLMN or non-subscribed SNPN, if available, as described in subclause 5.1.6.2 and if the new emergency registration succeeded, attempt an emergency call as described in this subclause; or

– perform implementation specific actions to establish the emergency call; and

2) if the 380 (Alternative Service) response includes a 3GPP IM CN subsystem XML body as described in subclause 7.6 with the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2) then the UE may also provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element.

NOTE 6: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

5.1.6.8.4 Emergency session setup within a non-emergency registration

The UE shall apply the procedures as specified in subclauses 5.1.2A and 5.1.3 with the following additions:

1) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with subclause 5.1.6.8.1;

2) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

3) the UE shall insert in the INVITE request, a From header field that includes the public user identity or the tel URI associated with the public user identity, as described in subclause 4.2;

4) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the UE shall insert in the P-Access-Network-Info header field a location identifier such as the cell id, line id or the identity of the WLAN access node, which is relevant for routeing the IMS emergency call;

NOTE 1: 3GPP TS 23.167 [4B] describes several methods how the UE can get its location information from the access network or from a server. Such methods are not in the scope of this specification.

5) the UE shall insert in the INVITE request one or two P-Preferred-Identity header field(s) that include the public user identity or the tel URI associated with the public user identity as described in subclause 4.2;

NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.

6) if the UE has its location information available, or a URI that points to the location information, then the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

NOTE 3: If the location information is old or inaccurate, the UE does not consider location information to be available.

7) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

8) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request;

9) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, then insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field as specified in RFC 5627 [93]. Otherwise the UE shall include the address in the Contact header field set to contain the IP address or FQDN of the UE, and the UE shall also include:

– if IMS AKA or SIP digest with TLS is being used as a security mechanism, the protected server port value as in the initial registration; or

– if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled Authentication is being used as a security mechanism, the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. The UE shall set the unprotected port value to the port value used in the initial registration; and

In the event the UE receives a 380 (Alternative Service) response with a P-Asserted-Identity header field with a value equal to the value of the SIP URI of the P-CSCF received in the Path header field during registration, and the Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field, independent of the value or presence of Content-Disposition parameters, then the following treatment is applied:

a) if the 380 (Alternative Service) response includes a 3GPP IM CN subsystem XML body as described in subclause 7.6 with an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2), then the UE shall:

– if the <action> child element of the <alternative-service> child element of the <ims-3gpp> element in the IM CN subsystem XML body as described in subclause 7.6 is set to "emergency-registration" (see table 7.6.3), perform an initial emergency registration, as described in subclause 5.1.6.2 and attempt an emergency call as described in subclause 5.1.6.8.3;

– attempt emergency call via CS domain using appropriate access technology specific procedures, if available and not already tried; or

– perform implementation specific actions to establish the emergency call; and

b) if the 380 (Alternative Service) response includes a 3GPP IM CN subsystem XML body as described in subclause 7.6 with an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2) then the UE may also provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element.

5.1.6.9 Emergency session release

Normal call release procedure shall apply, as specified in the subclause 5.1.5.

5.1.6.10 Successful or provisional response to a request not detected by the UE as relating to an emergency session

– if a public GRUU value (pub-gruu) has been saved associated with the public user identity, the public GRUU value has not been included in the Contact header field of the initial request for a dialog as specified in RFC 5627 [93];

– if a public GRUU value (pub-gruu) has not been saved and a protected server port was not included in the address in the Contact header field of the initial request for a dialog; or

– if the UE has its geographical location information available, or a URI that points to the location information, and the geographical location information or URI has not been included in the initial request for a dialog;

then the UE shall send an UPDATE request according to RFC 3311 [29]; and:

1) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the UE shall include in the UPDATE request a P-Access-Network-Info header field and it shall contain a location identifier such as the cell id or the identity of the WLAN access node;

2) if the UE has its geographical location information available, or a URI that points to the location information, then the UE shall include it in the UPDATE request in the following way:

I) if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

II) if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119 [90] and RFC 5491 [267], include the location object in a message body with the content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation header field value, as described RFC 6442 [89], and include a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

NOTE 1: If the location information is old or inaccurate, the UE does not consider location information to be available.

3) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

4) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the UPDATE request; and

5) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity, then the UE shall insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field of the UPDATE request as specified in RFC 5627 [93]; otherwise the UE shall include the address in the Contact header field set in accordance with subclause 5.1.6.8.4, item 8.

NOTE 2: The IMS emergency specification in 3GPP TS 23.167 [4B] describes several methods how the UE can get its location information from the access network or from a server. Such methods are not in the scope of this specification.

NOTE 3: It is suggested that UEs only use the option of providing a URI when the domain part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is not desirable.

NOTE 4: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header field in any request (except CANCEL requests) or response (except CANCEL responses) within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).

NOTE 5: In this version of the specification, only requests creating a dialog can request emergency services.

If the UE receives a 1xx or 200 (OK) response to an initial request for a dialog the response containing a P-Asserted-Identity header field set to an emergency number as specified in 3GPP TS 22.101 [1A], then the UE may indicate the nature of the session to the user.

5.1.6.11 eCall type of emergency service

5.1.6.11.1 General

If the upper layers request establishment of an IMS emergency call of the manually initiated eCall type of emergency service, the service URN shall be "urn:service:sos.ecall.manual" as specified in RFC 8147 [244].

If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of emergency service, the service URN shall be "urn:service:sos.ecall.automatic" as specified in RFC 8147 [244].

NOTE 1: The manually initiated eCall type of emergency service is used when the eCall IMS emergency session is invoked with user input. The automatically initiated eCall type of emergency service is used if the eCall IMS emergency session is invoked without user input.

NOTE 2: To ensure the identification and the related routing (e.g. to a test centre) of non-emergency calls initiated for eCall testing or eCall terminal reconfiguration purposes, "urn:service:sos.ecall.automatic" or "urn:service:sos.ecall.manual" are not used for such calls. Additionally the usage of any other service URN to establish non-emergency calls initiated for eCall testing or eCall terminal reconfiguration purposes needs to be in accordance with local operator policy.

5.1.6.11.2 Initial INVITE request

If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of emergency service or of the manually initiated eCall type of emergency service and if allowed by IP-CAN specific annex, the UE shall send an INVITE request as specified in the procedures in subclause 5.1.6.8 with the following additions:

1) the UE shall set the Request-URI to "urn:service:sos.ecall.automatic" or "urn:service:sos.ecall.manual"; and

2) if the IP-CAN indicates the eCall support indication, the UE shall:

a) insert a multipart/mixed body containing an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147 [244], containing the MSD not exceeding 140 bytes and encoded in binary ASN.1 PER as specified in CEN EN 15722:2015 [245] and include a Content-Disposition header field with a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

b) insert an Accept header field indicating the UE is willing to accept an "application/EmergencyCallData.Control+xml" MIME type as defined in RFC 8147 [244]; and

c) insert a Recv-Info header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244].

NOTE: Further content for the INVITE is as defined in RFC 8147 [244].

Then the UE shall proceed as follows:

1) if the UE receives a 200 (OK) response to the INVITE request not containing:

a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

i) a "received" attribute set to "true"; and

ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

then the UE shall send the MSD using audio media stream encoded as described in 3GPP TS 26.267 [9C];

2) if the UE receives a 200 (OK) response to the INVITE request containing:

a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

i) a "received" attribute set to "true"; and

ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

then the UE shall consider the initial MSD transmission as successful;

3) if the UE receives a 486 (Busy Here), 600 (Busy Everywhere) or 603 (Decline) response to the INVITE request containing:

a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

i) a "received" attribute set to "true"; and

ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

then the UE shall consider the initial MSD transmission as successful and shall perform domain selection to re-attempt the eCall as specified in 3GPP TS 23.167 [4B]; and

4) in all other cases, the UE shall perform domain selection to re-attempt the eCall as specified in 3GPP TS 23.167 [4B].

5.1.6.11.3 Transfer of an updated MSD

During an emergency session established for eCall type of emergency service as described in subclause 5.1.6.11.2, if the UE receives an INFO request with:

1) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

2) a multipart/mixed body including:

a) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] containing a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to "eCall.MSD"; and

b) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

3) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body;

the UE shall proceed as follows:

1) if the UE is able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

i) an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147 [244] containing the MSD not exceeding 140 bytes and encoded in binary ASN.1 as specified in CEN EN 15722:2015 [245]; and

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.eCall.MSD" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body; and

2) if the UE is not able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

i) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

– a "ref" attribute set to the Content-ID of the "application/EmergencyCallData.Control+xml" MIME body part in the INFO request received by the UE; and

– an "actionResult" child element containing:

A) an "action" attribute set to "send-data";

B) a "success" attribute set to "false"; and

C) a "reason" attribute set to an appropriate value as defined in RFC 8147 [244]; and

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body.

NOTE: Further content for the INFO request is as defined in RFC 8147 [244].

5.1.6.12 Current location discovery during an emergency call

5.1.6.12.1 General

The UE can be requested to provide the current location information during an established emergency call.

5.1.6.12.2 Current location information requested

If:

1) the UE indicated a Recv-Info header field with the g.3gpp.current-location-discovery info package name in the dialog of the emergency call;

2) the UE indicated an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type in the dialog of the emergency call; and

3) the dialog of the emergency call is a confirmed dialog;

then upon receiving an INFO request as described in RFC 6086 [25] as in-dialog request of the dialog of the emergency call:

1) with Info-Package header field as described in RFC 6086 [25], containing the g.3gpp.current-location-discovery info package name; and

2) with a request-for-current-location body as specified in subclause 7.12.2.2 in the MIME body of "application/vnd.3gpp.current-location-discovery+xml" MIME type;

the UE shall send a response to the INFO request according to RFC 6086 [25]. If a 200 (OK) response is sent to the INFO request, the UE shall perform the procedure in subclause 5.1.6.12.3.

5.1.6.12.3 Providing current location information

If the UE has its location information available, the UE shall provide the location information.

If the UE does not have its location information available, the UE may attempt to obtain the location information. If the location information becomes available at a subsequent time, the UE shall provide the location information. If the UE does not attempt to obtain its location information or when the UE stops attempting to obtain the location information, the UE shall inform the network about the location information not being available.

In order to provide the location information or to inform the network about the location information not being available, the UE shall apply the procedures as specified in subclauses 5.1.2A with the following additions.

The UE shall send a PUBLISH request as described in RFC 3903 [70] and RFC 3856 [74], as an in-dialog request of the dialog of the emergency call. In the PUBLISH request, the UE shall include an application/pidf+xml MIME body. If the UE has its location information available, the UE shall include the location information in a PIDF location object, in accordance with RFC 4119 [90] and RFC 5491 [267] in the application/pidf+xml MIME body.

NOTE: If the UE does not have its location information available, a PUBLISH request with an application/pidf+xml MIME body not containing a PIDF location object is sent.

5.1.7 Void

5.1.8 Void

5.1.9 P-CSCF addresses management

The UE shall locally store the P-CSCF addresses discovered during the procedures described in subclause 9.2.1.

Based on conditions identified in subclause 5.1.1.2.1 and subclause 5.1.2A.1.6, the UE marks the locally stored P-CSCF addresses as unavailable.

The UE shall not use a locally stored P-CSCF address which is marked as unavailable when performing initial registration.

After:

– a computed retry delay time determined by the algorithm defined in subclause 4.5 of RFC 5626 [92] plus 5 minutes (if no expiration time was identified in subclause 5.1.1.2.1 or subclause 5.1.2A.1.6); or

– a time indicated by the network for this P-CSCF (if expiration time was identified in in subclause 5.1.1.2.1 or subclause 5.1.2A.1.6)

after marking of a locally stored P-CSCF address as unavailable elapses, the UE clears the mark on the locally stored P-CSCF address.

If the UE performs a new P-CSCF discovery or is power-cycled, the UE shall clear all the availability marks on the locally stored P-CSCF addresses.