Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.1.4  Call initiation - UE-terminating caseWord‑p. 141

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

5.1.4.2  Reliable 18x Policy |R14|Word‑p. 144

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

5.1.4A  Session modification |R13|Word‑p. 145

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

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

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. The UE may also include the "text" header field parameter with reason-text as specified in RFC 8197.
Up

5.1.5A  Precondition disabling policy |R14|Word‑p. 146

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:
  1. the Precondition_disabling_policy node of the EF IMSConfigData file described in TS 31.102;
  2. the Precondition_disabling_policy node of the EF IMSConfigData file described in TS 31.103; and
  3. the Precondition_disabling_policy node of TS 24.167.
If the UE is configured with both the Precondition_disabling_policy node of TS 24.167 and the Precondition_disabling_policy node of the EF IMSConfigData file described in TS 31.102 or TS 31.103, then the Precondition_disabling_policy node of the EF IMSConfigData file shall take precedence.
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.
Up

5.1.6  Emergency service

5.1.6.1  General |R7|

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 to a different network than its home operator's network (e.g. VPLMN) 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) 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) 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) 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), 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 has failed and apply the procedures related to emergency registration failure that are defined in TS 23.167 subclause 4.1; and
  2. if the initial REGISTER request for the initial emergency registration has not been sent, consider that the attempt to set up the emergency call via the 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 TS 23.167 annex H.5.
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.
Up

5.1.6.2  Initial emergency registration |R7|Word‑p. 147

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

5.1.6.2A  New initial emergency registration |R7|Word‑p. 148

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 |R7|

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 |R7|

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 |R7|Word‑p. 149

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 |R7|

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.

5.1.6.7  Network-initiated emergency deregistration |R7|

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

5.1.6.8  Emergency session setup |R7|

5.1.6.8.1  General
The UE shall translate any user indicated emergency number as specified in TS 22.101 to an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031.
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:
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).
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.
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 TS 23.167 subclause 7.3. The UE may support being configured for the emerg-request timer using one or more of the following methods:
  1. the Timer_Emerg-request leaf of the EFIMSConfigData file described in TS 31.102;
  2. the Timer_Emerg-request leaf of the EFIMSConfigData file described in TS 31.103; and
  3. the Timer_Emerg-request leaf of TS 24.167.
If the UE is configured with both the Timer_Emerg-request leaf of TS 24.167 and the Timer_Emerg-request leaf of the EFIMSConfigData file described in TS 31.102 or TS 31.103, then the Timer_Emerg-request leaf of the EFIMSConfigData file shall take precedence.
Up
5.1.6.8.2  Emergency session set-up in case of no registrationWord‑p. 150
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.
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;
  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;
  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. 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;
  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; or
    • 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;
  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;
  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
  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, 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.
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).
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.
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.
Up
5.1.6.8.3  Emergency session set-up within an emergency registrationWord‑p. 152
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;
  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;
  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; or
    • 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;
  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;
  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, 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.
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:
    1. 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;
    2. 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 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.
Up
5.1.6.8.4  Emergency session setup within a non-emergency registrationWord‑p. 154
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;
  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;
  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; or
    • 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;
  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;
  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. 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
  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, 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.
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:
  1. 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
  2. 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.
Up

5.1.6.9  Emergency session release |R7|Word‑p. 155

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 |R8|

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

5.1.6.11  eCall type of emergency service |R14|Word‑p. 156

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.
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.
Up
5.1.6.11.2  Initial INVITE requestWord‑p. 157
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:
    1. insert a multipart/mixed body containing an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147, 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;
    2. insert an Accept header field indicating the UE is willing to accept an "application/EmergencyCallData.Control+xml" MIME type as defined in RFC 8147; and
    3. insert a Recv-Info header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147.
Then the UE shall proceed as follows:
  1. if the UE receives a 200 (OK) response to the INVITE request not containing:
    1. a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 with an "ack" element containing:
      1. a "received" attribute set to "true"; and
      2. 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 TS 26.267;
  2. if the UE receives a 200 (OK) response to the INVITE request containing:
    1. a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 with an "ack" element containing:
      1. a "received" attribute set to "true"; and
      2. 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:
    1. a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 with an "ack" element containing:
      1. a "received" attribute set to "true"; and
      2. 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 TS 23.167; and
  4. in all other cases, the UE shall perform domain selection to re-attempt the eCall as specified in TS 23.167.
Up
5.1.6.11.3  Transfer of an updated MSDWord‑p. 158
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;
  2. a multipart/mixed body including:
    1. an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 containing a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to "eCall.MSD"; and
    2. 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:
    1. an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147;
    2. a multipart/mixed body including:
      1. an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147 containing the MSD not exceeding 140 bytes and encoded in binary ASN.1 as specified in CEN EN 15722:2015 [245]; and
      2. a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.eCall.MSD" MIME body part; and
    3. 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:
    1. an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147;
    2. a multipart/mixed body including:
      1. an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 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:
          1. an "action" attribute set to "send-data";
          2. a "success" attribute set to "false"; and
          3. a "reason" attribute set to an appropriate value as defined in RFC 8147; and
      2. 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.
Up

5.1.6.12  Current location discovery during an emergency call |R14|Word‑p. 159

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 as in-dialog request of the dialog of the emergency call:
  1. with Info-Package header field as described in RFC 6086, 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. If a 200 (OK) response is sent to the INFO request, the UE shall perform the procedure in subclause 5.1.6.12.3.
Up
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 and RFC 3856, 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 and RFC 5491 in the application/pidf+xml MIME body.
Up

5.1.7Void

5.1.8Void

5.1.9  P-CSCF addresses management |R14|

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 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.
  • Up

    Up   Top   ToC