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.

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 TS 23.003.

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

1. a From header field set to the SIP URI that contains:
   1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
   2. the public user identity to be registered;
2. a To header field set to the SIP URI that contains:
   1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
   2. the public user identity to be registered;
3. 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.
      If the UE supports multiple registrations it shall include a "reg-id" header field parameter as described in RFC 5626.
      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 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.
      The UE shall include the media feature tags defined in RFC 3840 and RFC 5688 for all supported streaming media types.
      If the UE supports RFC 6140 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;
4. 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;
5. a registration expiration interval value of 600 000 seconds as the value desired for the duration of the registration;
6. a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;
7. 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".
8. 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);
9. 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;
10. if the UE supports RFC 6140 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
11. if the UE supports RFC 6140 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:

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

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

1. 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);
2. 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;
3. treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;
4. 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;
5. 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 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 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. 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;
6. 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, and the S-CSCF has followed the registration procedure as described in RFC 5627 or RFC 3261, 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, the UE shall refrain from registering any additional IMS flows for the same private identity as described in RFC 5626; or
   • if an option-tag "outbound" is present, the UE may establish additional IMS flows for the same private identity, as defined in RFC 5626;
7. 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;
8. 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;
9. if a Feature-Caps header field, as specified in RFC 6809 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);
10. void; and
11. if the 200 (OK) response includes a Feature-Caps header field, as specified in RFC 6809, 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:

1. ignore the contents of the Contact header field if it is included in the received message;
2. release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2;
3. 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;
4. select a P-CSCF address, which is different from the previously used address, from the address list; and
5. 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:

1. 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 Section 4.5 of RFC 5626 plus 5 minutes;
2. 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
3. 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.

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:

1. shall mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field;
2. 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
3. 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.

After a first unsuccessful initial registration attempt, if the Retry-After header field was not present and the initial registration was not performed as a consequence of a failed reregistration, the UE shall not wait more than 5 minutes before attempting a new registration. For each 4xx, 5xx or 6xx response received without a Retry-After header field to the REGISTER request, the UE shall:

1. use the mechanism defined in Section 4.5 of RFC 5626 for determination of the retry delay time before each new registration attempt;
2. mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in Section 4.5 of RFC 5626 plus 5 minutes; and
3. 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 Section 4.5 of RFC 5626; 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 TS 24.167. 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 Section 4.5 of RFC 5626 shall be used. Other mechanisms may be used as well and are outside the scope of the present document.

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

1. 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;
2. 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;
3. 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
4. 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 TS 33.203. The syntax of the parameters needed for the security association setup is specified in Annex H of TS 33.203. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329. The UE shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in TS 33.203, and shall announce support for them according to the procedures defined in RFC 3329.

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 as follows:
   1. 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
   2. 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.

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

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

1. an Authorization header field as defined in RFC 7616 and RFC 8760 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;
2. 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
3. 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.

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

1. an Authorization header field set in accordance with subclause 5.1.1.2.3 unless otherwise specified in the access specific annexes; and
2. 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 TS 33.203. The UE shall support the "tls" security mechanism, as specified in RFC 3329. The UE shall support TLS for integrity and confidentiality protection as defined in RFC 3261, and shall announce support for them according to the procedures defined in RFC 3329.

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

1. 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 TS 33.203. 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.

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

1. optionally, an Authorization header field, with the "username" header field parameter, set to the value of the 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.

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

1. an Authorization header field as defined in RFC 7616 and RFC 8760 shall not be included, in order to indicate support for GPRS-IMS-Bundled authentication.
2. the Security-Client header field as defined in RFC 3329 shall not contain signalling plane security mechanisms;
3. a From header field set to a temporary public user identity as defined in TS 23.003, as the public user identity to be registered;
4. a To header field set to a temporary public user identity as defined in TS 23.003, as the public user identity to be registered;
5. the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests; and
6. the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

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.