Content for  TS 24.229  Word version:  18.4.0

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 as updated by RFC 4032, 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. During the session initiation, if local resource reservation is required at the terminating UE and the terminating UE supports the precondition mechanism, and:

1. 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;
2. 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:
3. 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
4. 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:

1. the received INVITE request includes the "precondition" option-tag in the Supported header field and:
2. 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;
3. 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
4. the precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall not use the precondition mechanism;
5. 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;
6. 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
7. 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.

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:

1. the terminating UE requires a reliable alerting indication at the originating side;
2. the 18x response (other than 183 response) carries SDP or for other application related purposes that requires its reliable transport; or
3. 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. 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. 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) at the terminating UE, the terminating UE shall confirm the successful resource reservation (see subclause 6.1.3) within an SIP UPDATE request; and
• if the originating side did not request confirmation for the result of the resource reservation (as defined in RFC 3312) at the terminating UE, the terminating UE shall not confirm the successful resource reservation (see subclause 6.1.3) within an UPDATE request.

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 and RFC 5688 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]. If the terminating UE supports the Session Timer extension, as described in RFC 4028, 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 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 TS 24.167. 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 TS 24.167. 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 TS 24.167. If the UE is configured with both the local configuration and the Session_Timer_Initial_MT_Refresher node specified in TS 24.167, 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.

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:
   1. the corresponding INVITE request is subject to an IMS communication service identified in the ICSI condition of the reliable 18x policy part; or
   2. 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:
   1. the corresponding INVITE request is subject to an IMS communication service identified in the ICSI condition of the reliable 18x policy part; or
   2. 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. 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:

1. the Reliable_18x_policy node of the EF IMSConfigData file described in TS 31.102;
2. the Reliable_18x_policy node of the EF IMSConfigData file described in TS 31.103; and
3. the Reliable_18x_policy node of TS 24.167.

If the UE is configured with both the Reliable_18x_policy node of TS 24.167 and the Reliable_18x_policy node of the EF IMSConfigData file described in TS 31.102 or TS 31.103, then the Reliable_18x_policy node of the EF IMSConfigData file shall take precedence.

This subclause applies after the 2xx response to the initial INVITE request has been sent or received.

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:

1. indicate the support for the precondition mechanism using the Supported header field;
2. not indicate the requirement for the precondition mechanism using the Require header field; and
3. 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.

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:

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

A CS and IM CN subsystem capable UE shall follow the conventions and rules specified in TS 22.101 and TS 23.167 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. 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. If the UE supports emerg-reg-retry timer defined in Table 7.8.1, the UE shall start the timer when sending an emergency REGISTER. The UE shall stop the emerg-reg-retry timer when the UE receives any final response from this P-CSCF or when the emerg-reg timer has been stopped or expired. On expiry of emerg-reg-retry timer, the UE shall:

1. if the emerg-reg timer has not expired and the initial REGISTER request for the initial emergency registration has not received any response, consider that the emergency registration attempt for this P-CSCF has failed. The UE may retry registration on a different P-CSCF and restart the emerg-reg-retry timer. If the UE has no more available P-CSCFs, the UE shall stop the emerg-reg timer by considering the emergency registration has failed and follow the procedures related to emergency registration failure that are defined in subclause 6.1 of TS 23.167; and
2. if the initial REGISTER request for the initial emergency registration has not been sent:
   • if the emerg-reg timer has not expired and 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 if available and restart the emerg-reg-retry timer. If the UE has no more available P-CSCFs the UE shall stop the emerg-reg timer by considering the emergency registration has failed and follow the procedures related to emergency registration failure that are defined in subclause 6.1 of TS 23.167; or

On expiry of emerg-reg timer, the UE shall:

• if the UE has 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 and follow the procedures related to emergency registration failure that are defined in subclause 6.1 of TS 23.167; 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 follow the procedures for domain selection as defined in clause H.5 of TS 23.167.
  stop the emerg-reg-retry timer, if running.

The UE may support being pre-configured for the Emerg-reg timer using one or more of the following methods:

1. the Timer_Emerg-reg leaf of the EF IMSConfigData file described in TS 31.102;
2. the Timer_Emerg-reg leaf of the EF IMSConfigData file described in TS 31.103; and
3. the Timer_Emerg-reg leaf of TS 24.167.

If the UE is configured with both the Timer_Emerg-reg leaf of TS 24.167 and the Timer_Emerg-reg leaf of the EF IMSConfigData file described in TS 31.102 or TS 31.103, then the Timer_Emerg-reg leaf of the EF IMSConfigData file shall take precedence. 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.

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 TS 23.167 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:

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

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.

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.

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.

When a UE performs authentication a UE shall perform the procedures as specified in subclause 5.1.1.5.

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.

An emergency registration will not be deregistered by the network (see subclause 5.4.8.4).

Normal call release procedure shall apply, as specified in the subclause 5.1.5.

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

• 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;
• 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; 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:
   1. 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; or
   2. if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119 and RFC 5491, 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, 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;
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;
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; otherwise the UE shall include the address in the Contact header field set in accordance with subclause 5.1.6.8.4, item 8.

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, then the UE may indicate the nature of the session to the user.