Content for  TS 24.229  Word version:  19.0.0

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:
  1. 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
  2. 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:
  1. 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;
  2. 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
  3. 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 and RFC 8760;
• if SIP digest with TLS is in use as a security mechanism:
  1. if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port;
  2. include the protected server port in the Via header field entry relating to the UE; and
  3. 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 and RFC 8760;
• 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 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 and RFC 8760 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 and RFC 8760 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 and RFC 8760 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 TS 33.310 using certificates. In accordance with RFC 3325 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. 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.

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 and set an addr-spec of the From header field to Anonymous User Identity as specified in TS 23.003. 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. 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; 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;
   • otherwise, a SIP URI containing the contact address of the UE that has been previously registered without any contact parameters dedicated to registration procedure;
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;
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, 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, 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, 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. If a list of network supported ICSI values was received as specified in TS 24.167, the UE shall only include an ICSI value that is in the received list;
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.

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. 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, and the additional requirements contained within RFC 3325. If resource priority in accordance with RFC 4412 is required for a dialog, then the UE shall include the Resource-Priority header field in all requests associated with that dialog. 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. 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:

1. 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
2. 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;
3. and the values received in the Service-Route header field saved from the 200 (OK) response to the last registration or reregistration of the public user identity with associated contact address.

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. 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 and configured in the trace management object defined in TS 24.323, 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 and configured in the trace management object defined in TS 24.323.

1. If a stop trigger event has occurred, the UE shall stop logging of signalling; or
2. 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 TS 22.101, 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 TS 22.101 and TS 23.167, and:
   • if the CS domain is selected, the UE behavior is defined in subclause 7.1.2 of TS 23.167 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:
     1. 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
     2. 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;
        1. does not contain a P-Asserted-Identity header field; or
        2. 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.

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, 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 Section 7.4 of RFC 4028.

The UE may include a SIP URI complying with RFC 3261, a tel URI complying with RFC 3966, a pres URI complying with RFC 3859, an im URI complying with RFC 3860 or a mailto URI complying with RFC 2368. 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.

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, 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, 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 and RFC 4967, 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, 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.

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, with a local number followed by a "phone-context" tel-URI parameter value;
2. a SIP URI, complying with RFC 3261, 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 and RFC 4967, 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. 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) then the service-urn should be sent.

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

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:
   1. the upper layers provide a number in non-international format to be included in Request-URI of a SIP request;
   2. the upper layers do not provide a "phone-context" value associated with the number;
   3. the UE is not configured to associate a particular "phone-context" value with the number; and
   4. 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:
      1. 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
      2. 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:
   1. the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.102;
   2. the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.103; and
   3. the Policy_on_local_numbers node of TS 24.167.
   If the UE is configured with both the Policy_on_local_numbers node of TS 24.167 and the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.102 or the Policy_on_local_numbers node of the EF IMSConfigData file described in TS 31.103, then the Policy_on_local_numbers node of the EF IMSConfigData file shall take precedence.

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:
   1. from the Service-Route header field value received during registration; or
   2. from the Path header field value received during registration; and
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:

1. 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:
   1. with the <type> child element set to "restoration" (see Table 7.6.2); and
   2. 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.

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 timer F expires in the "Trying" state of non-INVITE client transaction as described in RFC 3261;
• if a fatal transport error is reported by the transport layer in the "Trying" state of non-INVITE client transaction as described in RFC 3261;
• if timer B expires in the "Calling" state of INVITE client transaction as described in RFC 6026; or
• if a fatal transport error is reported by the transport layer in "Calling" state of INVITE client transaction as described in RFC 6026;

then the UE shall:

1. if the multiple registration mechanism is not used:
   1. consider the contact address as not bound to any public user identity;
   2. mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable;
   3. 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
   4. 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 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 without a Retry-After header field is received for request as described in RFC 3261, the UE shall:

1. if the multiple registration mechanism is not used:
   1. consider the contact address as not bound to any public user identity;
   2. mark the currently used P-CSCF address (i.e. P-CSCF address using which the contact address was registered) as unavailable;
   3. 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
   4. 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 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 RFC 3261 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:
   1. consider the contact address as not bound to any public user identity;
   2. 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;
   3. 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
   4. 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 and mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field.