Content for  TS 24.229  Word version:  19.0.0

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

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 TS 29.228. 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 TS 29.228. 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:
   1. either the received Redirect-Host AVP value; or
   2. 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.

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:
   1. either the received Redirect-Host AVP value; or
   2. 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.

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

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.

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

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. 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. 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: 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. 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 Section 8 of RFC 4028. 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: 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: Upon successful user location query, when the response contains information about the required S-CSCF capabilities, the I-CSCF shall: 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, 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: 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.

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.

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. 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. 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 TS 29.228 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 TS 29.228. 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 Section 8 of RFC 4028. 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 TS 29.228. If the user location query was successful, the I-CSCF shall: 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.

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

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

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.

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.