5.3 Procedures at the I-CSCF

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.3.0 General

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

5.3.1 Registration procedure

5.3.1.1 General

During the registration procedure the I-CSCF shall behave as a stateful proxy.

5.3.1.2 Normal procedures

When the I-CSCF receives a REGISTER request, the I-CSCF shall verify whether or not it has arrived from a trusted domain. If the request has not arrived from a trusted domain, the I-CSCF shall complete the processing of the request by responding with 403 (Forbidden) response. Otherwise, the I-CSCF starts the user registration status query procedure to the HSS as specified in 3GPP TS 29.228 [14].

NOTE 1: The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures described in 3GPP TS 33.210 [19A].

NOTE 2: Different UEs, each with its own private user identity, can register the same shared public user identity. Registrations of all public user identities belonging to these UEs are directed to the same S-CSCF as described in 3GPP TS 29.228 [14].

If the REGISTER request does not include an Authorization header field and private user identity, the I-CSCF shall derive the private user identity from the public user identity being registered, contained in the To header field, by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters.

Prior to performing the user registration query procedure to the HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14]. As a result of the query the I-CSCF gets the Redirect-Host AVP.

If the user registration status query response from the HSS includes a valid SIP URI, the I-CSCF shall:

1) replace the Request-URI of the received REGISTER request with the SIP URI received from the HSS in the Server-Name AVP;

2) optionally include in the P-User-Database header field defined in RFC 4457 [82]:

a) either the received Redirect-Host AVP value; or

b) the HSS Group ID using the form "aaa://hss.5gc.gid.<GID>.invalid", if the HSS Group ID is received following procedures in clause X.3; and

3) forward the REGISTER request to the indicated S-CSCF.

NOTE 3: The P-User-Database header field can be included only if the I-CSCF can assume (e.g. based on local configuration) that the receiving S-CSCF will be able to process the header field.

If the user registration status query response from the HSS includes a list of capabilities, the I-CSCF shall:

1) select a S-CSCF that fulfils the indicated mandatory capabilities – if more than one S-CSCFs fulfils the indicated mandatory capabilities the S-CSCF which fulfils most of the possibly additionally indicated optional capabilities;

2) replace the Request-URI of the received REGISTER request with the URI of the S-CSCF;

3) optionally, include in the P-User-Database header field defined in RFC 4457 [82]:

a) either the received Redirect-Host AVP value; or

b) the HSS Group ID using the form "aaa://hss.5gc.gid.<GID>.invalid", if the HSS Group ID is received following procedures in clause X.3; and

4) forward the REGISTER request to the selected S-CSCF.

NOTE 4: The P-User-Database header field can be included only if the I-CSCF can assume (e.g. based on local configuration) that the receiving S-CSCF will be able to process the header field.

NOTE 5: It is important that the I-CSCF does not alter the Via header field for requests and responses sent in the direction from the UE to the S-CSCF in the case of GPRS-IMS-Bundled authentication

When the I-CSCF receives a 2xx response to a REGISTER request, the I-CSCF shall forward the 2xx response to the P-CSCF.

5.3.1.3 Abnormal cases

In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 403 (Forbidden) response to the UE.

If the HSS sends a negative response to the user registration status query request, the I-CSCF shall send back a 403 (Forbidden) response.

If the user registration status query procedure cannot be completed, e.g. due to time-out or incorrect information from the HSS, the I-CSCF shall send back a 480 (Temporarily Unavailable) response to the UE.

If a selected S-CSCF:

– does not respond to the REGISTER request and its retransmissions by the I-CSCF; or

– sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request;

and:

– the REGISTER request did not include an "integrity-protected" header field parameter in the Authorization header field;

– the REGISTER request did include an "integrity-protected" header field parameter in the Authorization header field with a value set to "no" in the Authorization header field;

– the REGISTER request did include an "integrity-protected" header field parameter in the Authorization header field with a value set to other than "no" and the I-CSCF supports S-CSCF restoration procedures; or

– the REGISTER request did not include an Authorization header field and the I-CSCF supports S-CSCF restoration procedures;

then:

– if the I-CSCF has received the list of capabilities from the HSS, the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same registration procedure; or

– if the I-CSCF has received a valid SIP URI from the HSS because the S-CSCF is already assigned to other UEs sharing the same public user identity, it will request the list of capabilities from the HSS and, on receiving these capabilities, the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same registration procedure.

NOTE 1: Checking for the inclusion of the Authorization header field is necessary to prevent S-CSCF reselection in the case of GPRS-IMS-Bundled authentication or NASS-IMS bundled authentication when no Authorization header field is present in case I-CSCF does not support S-CSCF restoration procedures.

NOTE 2: In case the S-CSCF does not respond, the I-CSCF can apply a pre-configured timer based on local policy before re-selecting a new S-CSCF.

When forwarding the REGISTER request to the new S-CSCF, the I-CSCF includes the SIP URI parameter "scscf-reselection" to the Request-URI of the REGISTER request.

If a selected S-CSCF does not respond to a REGISTER request and its retransmissions by the I-CSCF and none of the conditions specified above in this case are fulfilled, the I-CSCF shall send back a or 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26].

If the I-CSCF cannot select a S-CSCF which fulfils the mandatory capabilities indicated by the HSS, the I-CSCF shall send back a 600 (Busy Everywhere) response to the user.

5.3.2 Initial requests

5.3.2.1 Normal procedures

The I-CSCF may behave as a stateful proxy for initial requests.

Upon receipt of a request, the I-CSCF shall perform the originating procedures as described in subclause 5.3.2.1A if the topmost Route header field of the request contains the "orig" parameter. Otherwise, the I-CSCF shall continue with the rest of the procedures of this subclause.

When the I-CSCF receives a request, the I-CSCF shall verify whether it has arrived from a trusted domain or not. If the request has arrived from a non trusted domain, then the I-CSCF shall remove all P-Charging-Vector header fields and all P-Charging-Function-Addresses header fields the request may contain.

NOTE 1: The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures described in 3GPP TS 33.210 [19A].

For all SIP transactions identified:

– if priority is supported, as containing an authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;

the I-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the I-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.

NOTE 2: The special treatment can included filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

The I-CSCF shall discard the P-Profile-Key header field, if the I-CSCF receives the P-Profile-Key header field in a SIP request or response.

When the I-CSCF receives, destined for a served user or a PSI, an initial request for a dialog or standalone transaction the I-CSCF shall:

1) if the Request-URI includes:

a) a pres: or an im: URI, then translate the pres: or im: URI to a public user identity and replace the Request-URI of the incoming request with that public user identity; or

b) a SIP-URI that is not a GRUU and with the user part starting with a + and the "user" SIP URI parameter equals "phone" then replace the Request-URI with a tel-URI with the user part of the SIP-URI in the telephone-subscriber element in the tel-URI, and carry forward the tel-URI parameters that may be present in the Request-URI; or

c) a SIP URI that is a GRUU, then obtain the public user identity or an identity of the UE that represents the functionality within the UE that performs the role of registrar from the Request-URI and use it for location query procedure to the HSS. When forwarding the request, the I-CSCF shall not modify the Request-URI of the incoming request;

NOTE 3: SRV records have to be advertised in DNS pointing to the I-CSCF for pres: and im: queries.

2) remove its own SIP URI from the topmost Route header field, if present; and

3) check if the domain name of the Request-URI matches with one of the PSI subdomains configured in the I-CSCF. If the match is successful, the I-CSCF resolves the Request-URI by an internal DNS mechanism into the IP address of the AS hosting the PSI and does not start the user location query procedure. Otherwise, the I-CSCF will start the user location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the called PSI or user, indicated in or derived from the Request-URI. Prior to performing the user location query procedure to the HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14].

When the I-CSCF receives any response to such a request, the I-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.

NOTE 4: A received "term-ioi" header field parameter will be a type 3 IOI if received from an AS hosting a PSI or a type 2 IOI if received from the S-CSCF of the served user. The type 3 IOI identifies the service provider from which the response was sent and the type 2 IOI identifies the network from which the response was sent.

When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, then the I-CSCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE 5: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

In case the I-CSCF is able to resolve the Request-URI into the IP address of the AS hosting the PSI, then the I-CSCF shall:

1) store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field. If no P-Charging-Vector header field was found, then insert the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17]. The I-CSCF shall insert a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi" header field parameter. The I-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The I-CSCF shall not include the type 3 "term-ioi" header field parameter. Based on local policy, the I-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier; and

2) forward the request directly to the AS hosting the PSI.

Upon successful user location query, when the response contains the URI of the assigned S-CSCF, or the URI of an AS hosting the PSI, the I-CSCF shall:

1) insert the URI received from the HSS as the topmost Route header field;

2) store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the P-Charging-Vector header field in the P-Charging-Vector header field. If no "icid-value" header field parameter was found, then insert the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17];

2A) based on local policy, add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;

3) optionally, include in the P-User-Database header field defined in RFC 4457 [82]:

a) either the received Redirect-Host AVP value; or

b) the HSS Group ID using the form "aaa://hss.5gc.gid.<GID>.invalid", if the HSS Group ID is received following procedures in clause X.3;

3A) if the Wildcarded Identity value is received from the HSS in the Wildcarded-Identity AVP and the I-CSCF supports the SIP P-Profile-Key private header extension, include the wildcarded identity value in the P-Profile-Key header field defined in RFC 5002 [97]; and

4) forward the request based on the topmost Route header field.

NOTE 6: The P-User-Database header field can be included only if the I-CSCF can assume (e.g. based on local configuration) that the receiving S-CSCF will be able to process the header field.

Upon successful user location query, when the response contains information about the required S-CSCF capabilities, the I-CSCF shall:

1) if overlap signalling using the multiple-INVITEs method is supported as a network option, and if the I-CSCF receives an INVITE request outside an existing dialog with the same Call ID and From header as a previous INVITE request during a certain period of time, route the new INVITE to the same next hop as the previous INVITE request; otherwise

2) select a S-CSCF according to the method described in 3GPP TS 29.228 [14];

3) insert the URI of the selected S-CSCF as the topmost Route header field value;

4) execute the procedure described in step 2 and 3 in the above paragraph (upon successful user location query, when the response contains the URI of the assigned S-CSCF);

5) optionally, include in the P-User-Database header field defined in RFC 4457 [82]:

a) either the received Redirect-Host AVP value; or

b) the HSS Group ID using the form "aaa://hss.5gc.gid.<GID>.invalid", if the HSS Group ID is received following procedures in clause X.3;

6) if the Wildcarded Identity value is received from the HSS in the Wildcarded-Identity AVP and the I-CSCF supports the SIP P-Profile-Key private header extension, include the wildcarded identity value in the P-Profile-Key header field as defined in RFC 5002 [97]; and

NOTE 7: A Wildcarded Identity can be either a PSI or a public user identity.

7) forward the request to the selected S-CSCF.

NOTE 8: The P-User-Database header field can be included only if the I-CSCF can assume (e.g. based on local configuration) that the receiving S-CSCF will be able to process the header field.

Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if the Request-URI is a tel URI containing a public telecommunications number as specified in RFC 3966 [22], the I-CSCF may support a local configuration option that indicates whether or not request routeing is to be attempted. If the local configuration option indicates that request routeing is to be attempted, then the I-CSCF shall perform one of the following procedures based on local operator policy:

1) forward the request to the transit functionality for subsequent routeing; or

2) invoke the portion of the transit functionality that translates the public telecommunications number contained in the Request-URI to a routeable SIP URI, and process the request based on the result, as follows:

a) if the translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in the home network, or the I-CSCF may send an appropriate SIP response to the originator, such as 404 (Not Found) or 604 (Does not exist anywhere). When forwarding the request to a BGCF or any other appropriate entity, the I-CSCF shall leave the original Request-URI containing the tel URI unmodified:

i) if overlap signalling using the multiple-INVITEs method is supported as a network option, and if the I-CSCF receives an INVITE request outside an existing dialog with the same Call ID and From header as a previous INVITE request during a certain period of time, the I-CSCF shall route the new INVITE to the same next hop as the previous INVITE request; and

ii) additional procedures apply if the I-CSCF supports NP capabilities and these capabilities are enabled by local policy, and the database used for translation from an international public telecommunications number to a SIP URI also provides NP data (for example, based on the PSTN Enumservice as defined by RFC 4769 [114] or other appropriate data bases). If the above translation from an international public telecommunications number to a SIP URI failed, but NP data was obtained from the database, then the I-CSCF shall replace the tel-URI in the Request-URI with the obtained NP data, prior to forwarding the request to the BGCF or other appropriate entity. The URI is updated by the I-CSCF by adding the NP parameters defined by RFC 4694 [112] to the tel-URI in the Request-URI: an "npdi" tel-URI parameter is added to indicate that NP data retrieval has been performed, and if the number is ported, an "rn" tel-URI parameter is added to identify the ported-to routeing number. The I-CSCF shall perform these procedures if the tel-URI in the received Request-URI does not contain an "npdi" tel-URI parameter. In addition, the I-CSCF may, based on local policy, perform these procedures when the tel-URI in the received Request-URI contains an "npdi" tel-URI parameter indicating that the NP data has been previously obtained; or

NOTE 9: The I-CSCF might need to replace NP data added by a previous network if the previous network’s NP database did not contain the local ported data for the called number. When the I-CSCF replaces the tel URI in the Request-URI with the obtained NP data, all tel URI parameters in the received Request-URI will be replaced by the obtained NP data.

b) if this translation succeeds, then replace the Request-URI with the routeable SIP URI and process the request as follows:

– determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header field if present, otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. the destination address is of an IP address type other than the IP address type used in the IM CN subsystem), the I-CSCF shall:

i) if the I-CSCF supports indicating the traffic leg as specified in RFC 7549 [225] and required by local policy, append the "iotl" SIP URI parameter set to "homeA-homeB" to the Request-URI; and

ii) forward the request to the destination address via an IBCF in the same network;

– if network hiding is needed due to local policy, put the address of the IBCF to the topmost Route header field;

– route the request based on SIP routeing procedures; and

– if overlap signalling using the multiple-INVITE method is supported as a network option, and if the I-CSCF receives an INVITE request outside an existing dialog with the same Call ID and From header as a previous INVITE request during a certain period of time, route the new INVITE to the same next hop as the previous INVITE request.

Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if local operator policy does not indicate that request routeing is to be attempted, then, the I-CSCF shall return an appropriate unsuccessful SIP response. Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if if the Request-URI is a SIP URI, the I-CSCF shall also return an appropriate unsuccessful SIP response. This response may be a 404 (Not found) or 604 (Does not exist anywhere) in the case the user is not a user of the home network.

Upon an unsuccessful user location query when the response from the HSS indicates that the user is not registered and no services are provided for such a user, the I-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 480 (Temporarily unavailable) response if the user is recognized as a valid user, but is not registered at the moment and it does not have services for unregistered users.

When the I-CSCF receives an initial request for a dialog or standalone transaction, that contains a single Route header field pointing to itself, the I-CSCF shall determine from the entry in the Route header field whether it needs to do HSS query. In case HSS query not is needed, then the I-CSCF shall:

1) remove its own SIP URI from the topmost Route header field; and

2) route the request based on the Request-URI.

When the I-CSCF receives an initial request for a dialog or standalone transaction containing more than one Route header field, the I-CSCF shall:

1) remove its own SIP URI from the topmost Route header field; and

2) forward the request based on the topmost Route header field.

NOTE 10: In accordance with SIP the I-CSCF can add its own routeable SIP URI to the top of the Record-Route header field to any request, independently of whether it is an initial request. The P-CSCF will ignore any Record-Route header field that is not in the initial request of a dialog.

When the I-CSCF receives a response to an initial request (e.g. 183 (Session Progress) response or 2xx response), the I-CSCF shall store the values from the P-Charging-Function-Addresses header field, if present. If the next hop is outside of the current network, then the I-CSCF shall remove the P-Charging-Function-Addresses header field prior to forwarding the message.

When the I-CSCF receives any response to the initial request for a dialog or standalone transaction containing a "term-ioi" header field parameter in the P-Charging-Vector header field from the AS hosting the PSI, the I-CSCF shall:

1) remove all received "orig-ioi" and "term-ioi" header field parameters from the forwarded response;

2) insert the stored "orig-ioi" header field parameter if received in the request; and

3) insert a type 2 "term-ioi" header field parameter. The "term-ioi" header field parameter is set to a value that identifies the sending network of the response.

When the I-CSCF, upon sending an initial INVITE request to the S-CSCF, receives a 305 (Use Proxy) response from the S-CSCF, the I-CSCF shall forward the initial INVITE request to the SIP URI indicated in the Contact field of the 305 (Use Proxy) response, as specified in RFC 3261 [26].

5.3.2.1A Originating procedures for requests containing the "orig" parameter

The procedures of this subclause apply for requests received at the I-CSCF when the topmost Route header field of the request contains the "orig" parameter.

The I-CSCF shall verify for all requests whether they arrived from a trusted domain or not. If the request arrived from a non trusted domain, then the I-CSCF shall respond with 403 (Forbidden) response.

If the request arrived from a trusted domain, the I-CSCF shall perform the procedures below.

NOTE 1: The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures described in 3GPP TS 33.210 [19A].

For all SIP transactions identified:

NOTE 2 The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

If the I-CSCF receives the P-Profile-Key header field in a SIP request or response the I-CSCF shall discard the P-Profile-Key header field.

When the I-CSCF receives an initial request for a dialog or standalone transaction the I-CSCF will start the user location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the calling user, indicated in either:

1) the P-Served-User header field, if included in the request; or

2) the P-Asserted-Identity header field, if the P-Served-User header field is not included in the request.

Prior to performing the user location query procedure to the HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14].

When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, the I-CSCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE 3: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

When the response for user location query contains information about the required S-CSCF capabilities, the I-CSCF shall select a S-CSCF according to the method described in 3GPP TS 29.228 [14].

If the user location query was successful, the I-CSCF shall:

1) insert the URI of an AS hosting the PSI, or the URI of the S-CSCF – either received from the HSS, or selected by the I-CSCF based on capabilities – as the topmost Route header field appending the "orig" parameter to the URI of the S-CSCF;

2) store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field. If no P-Charging-Vector header field was found, then insert the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17];

2A) based on local policy, add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;

3) optionally, include in the P-User-Database header field defined in RFC 4457 [82]:

a) either the received Redirect-Host AVP value; or

b) the HSS Group ID using the form "aaa://hss.5gc.gid.<GID>.invalid", if the HSS Group ID is received following procedures in clause X.3;

4) if a wildcarded identity value is received from the HSS in the Wildcarded-Identity AVP and the I-CSCF supports the SIP P-Profile-Key private header extension, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002 [97]; and

5) forward the request based on the topmost Route header field.

NOTE 4: The P-User-Database header field can be included only if the I-CSCF can assume (e.g. based on local configuration) that the receiving S-CSCF will be able to process the header field.

Upon an unsuccessful user location query, the I-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 404 (Not found) response or 604 (Does not exist anywhere) response in the case the user is not a user of the home network.

When the I-CSCF receives any response to the above request, and forwards it to AS, the I-CSCF shall:

– store the values from the P-Charging-Function-Addresses header field, if present. If the next hop is outside of the current network, then the I-CSCF shall remove the P-Charging-Function-Addresses header field prior to forwarding the message; and

– insert a P-Charging-Vector header field containing the type 3 "orig-ioi" header field parameter, if received in the request, and a type 3 "term-ioi" header field parameter in the response. The I-CSCF shall set the type 3 "term-ioi" header field parameter to a value that identifies the sending network of the response and the type 3 "orig-ioi" header field parameter is set to the previously received value of type 3 "orig-ioi" header field parameter.

5.3.2.2 Abnormal cases

In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 404 (Not Found) response to the UE.

Upon successful user location query, when the response contains the URI of the assigned S-CSCF, if the I‑CSCF is unable to contact the assigned S-CSCF, as determined by one of the following:

– the S-CSCF does not respond to the service request and its retransmissions by the I-CSCF; or

– by unspecified means available to the I-CSCF;

and:

– the I-CSCF supports S-CSCF restoration procedures;

then:

– the I-CSCF shall explicitly request the list of capabilities from the HSS and, on receiving these capabilities, the I-CSCF shall select a new S-CSCF, based on the capabilities indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same terminating procedure. Re-selection shall be performed until SIP transaction timer expires as specified in RFC 3261 [26]. When forwarding the request to the new S-CSCF, the I-CSCF includes the SIP URI parameter "scscf-reselection" to the Request-URI of the request.

NOTE 1: These procedures do not prevent the usage of unspecified reliability or recovery techniques above and beyond those specified in this subclause.

Upon successful user location query, when the response contains information about the required S-CSCF capabilities, if the I-CSCF is unable to contact a selected S-CSCF, as determined by one of the following:

– the S-CSCF does not respond to the service request and its retransmissions by the I-CSCF; or

– by unspecified means available to the I-CSCF;

then:

– the I-CSCF shall select a new S-CSCF, based on the capabilities indicated from the HSS. The newly selected S‑CSCF shall not be one of any S-CSCFs selected previously during this same terminating procedure. Re-selection shall be performed until SIP transaction timer expires as specified in RFC 3261 [26]. When forwarding the request to the new S-CSCF, the I-CSCF includes the SIP URI parameter "scscf-reselection" to the Request-URI of the request.

NOTE 2: These procedures do not prevent the usage of unspecified reliability or recovery techniques above and beyond those specified in this subclause.

If the I-CSCF receives a negative response to the user location query, the I-CSCF shall send back a 404 (Not Found) response.

If the I-CSCF receives a CANCEL request and if the I-CSCF finds an internal state indicating a pending Cx transaction with the HSS, the I-CSCF:

– shall answer the CANCEL request with a 200 (OK) response; and

– shall answer the original request with a 487 (Request Terminated) response.

NOTE 3: The I-CSCF will discard any later arriving (pending) Cx answer message from the HSS.

With the exception of 305 (Use Proxy) response, the I-CSCF may recurse on a 3xx response only when the domain part of the URI contained in the 3xx response is in the same domain as the I-CSCF. For the same cases, if the URI is an IP address, the I-CSCF shall only recurse if the IP address is known locally to be a address that represents the same domain as the I-CSCF.

5.3.3 Void

5.3.3.1 Void

5.3.3.2 Void

5.3.3.3 Void

5.3.4 Void

5.3.5 Subsequent requests

When the I-CSCF receives a subsequent request, the I-CSCF shall verify whether it has arrived from an entity within the trust domain or not. If the request has not arrived from an entity within the trust domain, then the I-CSCF shall remove all P-Charging-Vector header fields, if present.

If no P-Charging-Vector header field was found in the received subsequent request, then insert the P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog.

When the I-CSCF receives any response to the subsequent request, the I-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.

When the I-CSCF receives a subsequent request directly forwarded to the AS hosting the PSI, the I-CSCF shall insert a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi" header field parameter, if the received request including a P-Charging-Vector header field. The I-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The I-CSCF shall not include the type 3 "term-ioi" header field parameter.

When the I-CSCF receives any response to the subsequent request from the AS hosting the PSI, if the received response containing a "term-ioi" header field parameter in the P-Charging-Vector header field, the I-CSCF shall:

1) remove all received "orig-ioi" and "term-ioi" header field parameters from the forwarded response;

2) insert the stored "orig-ioi" header field parameter if received in the request; and

3) insert a type 2 "term-ioi" header field parameter. The "term-ioi" header field parameter is set to a value that identifies the sending network of the response.