Content for  TS 24.229  Word version:  19.0.0

When sending a failure response to any received request, depending on operator policy, the AS 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 "as" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. An AS when sending a failure response will add in the URN the "role" header field parameter set to the corresponding AS role listed in subclause 7.2.17.

The AS may support the REGISTER method in order to discover the registration status of the user. If a REGISTER request arrives and the AS supports the REGISTER method, the AS shall store the registration expiration interval value from the request and generate a 200 (OK) response or an appropriate failure response. For the success case, the 200 (OK) response shall contain a registration expiration interval value equal to the value received in the REGISTER request. The AS shall store the values received in P-Charging-Function-Addresses header field. Also, the AS shall store the values of the "icid-value" header field parameter and "orig-ioi" header field parameter if present in the P-Charging-Vector header field from the REGISTER request. If a Contact header field is included in the REGISTER request including a "+g.3gpp.registration-token" header field parameter as defined in subclause 7.9.7, the AS supporting this feature shall store the value of the "+g.3gpp.registration-token" header field parameter. The AS shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the REGISTER request, a type 3 "term-ioi" header field parameter in the response to REGISTER and the "icid-value" header field parameter. The AS shall set the type 3 "term-ioi" header field parameter to a value that identifies the service provider from which the response is sent, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request. Upon receipt of a third-party REGISTER request, with the Content-Type header field or with a MIME body part's 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 or a MIME body part's Content-Type header field, independent of the value or presence of Content-Disposition parameters or MIME body part's Content-Disposition parameters, then the following treatment is applied:

• if the third-party REGISTER request includes an IM CN subsystem XML body with an <ims-3gpp> element, including a version attribute, with the <service-info> child element or a MIME body part containing an <ims-3gpp> element with a <service-info> XML child element as described in subclause 7.6, then the AS may retrieve the service information within the <service-info> XML child element of the <ims-3gpp> element.

Upon receipt of a third-party REGISTER request, with the Content-Type header field or with a body part's Content-Type header field set to "message/sip" and including a "message/sip" MIME body of the incoming REGISTER request, or the 200 (OK) response to the incoming REGISTER request then the AS may retrieve information from the "message/sip" MIME body or body part. Upon receipt of a third-party REGISTER request, the AS may subscribe to the reg event package for the public user identity registered at the user's registrar (S-CSCF) as described in RFC 3680 and RFC 6665. On sending a SUBSCRIBE request, the AS shall populate the header fields as follows:

1. a Request-URI set to the resource to which the AS wants to be subscribed to, i.e. to a SIP URI that contains the public user identity of the user that was received in the To header field of the third-party REGISTER request;
2. a From header field set to the AS's SIP URI;
3. a To header field, set to a SIP URI that contains the public user identity of the user that was received in the To header field of the third-party REGISTER request;
4. an Event header field set to the "reg" event package;
5. a P-Asserted-Identity header field set to the SIP URI of the AS; and
6. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter.

Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665, associated with the SUBSCRIBE request, the AS shall:

1. store the information for the so established dialog;
2. store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request; and
3. follow the procedures specified in RFC 6665.

Upon receipt of any response, the AS shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field if present. Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package, the AS shall:

• store the information for the established dialog;
• store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request;
• store the value of the "orig-ioi" header field parameters if present in the P-Charging-Vector header field. The AS shall insert a P-Charging-Vector header field in the response to the NOTIFY request containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 3 "term-ioi" header field and the "icid-value" header field parameter;
• set the type 3 "term-ioi" header field parameter to a value that identifies the service provider from which the response is sent, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request; and
• follow the procedures specified in RFC 6665.

When an AS receives an initial request for a dialog or a request for a standalone transaction, the AS shall store the values received in the P-Charging-Vector header field, e.g. "orig-ioi" header field parameter, if present, and "icid-value" header field parameter, and retain the P-Charging-Vector header field in the message. The AS shall store the values received in the P-Charging-Function-Addresses header field and retain the P-Charging-Function-Addresses header field in the message. When an AS sends any request or response related to a dialog or standalone transaction, the AS shall insert previously saved values into the P-Charging-Vector header field and may insert previously saved values into the P-Charging-Function-Addresses header field before sending the message.

The AS may receive information about the served user core network in REGISTER requests from S-CSCF. This information can be obtained either from the P-Access-Network-Info header field and P-Visited-Network-ID header field in the REGISTER request or can be obtained from those header fields in the body of the REGISTER request. The AS may also receive information about the served user access network in other requests (excluding CANCEL requests and responses). This information can be obtained from the P-Access-Network-Info header field. The AS can use the P-Access-Network-Info and P-Visited-Network-ID header fields to provide an appropriate service to the user.

A prerequisite for the procedure in this subclause is that a REGISTER request has been received including a Contact header field with a "+g.3gpp.registration-token" header field parameter and that the AS supports using this token to identify the registration. When receiving an initial request for a dialog or a request for a standalone transaction, or a response to such request the AS shall if a "+g.3gpp.registration-token" header field parameter as defined in subclause 7.9A.8 is included in a Feature-Caps header field use this value to identify the registration used for this initial request for a dialog or this request for a standalone transaction or a response to such request by comparing it to the value of the "+g.3gpp.registration-token" Contact header field parameter stored when the user registered. If the AS routes the originating request to another entity than the S-CSCF, the AS shall remove the "+g.3gpp.registration-token" header field parameter from the Feature-Caps header field before forwarding the request.

The procedures at the AS to accomplish user identity verification are described with the help of Figure 5-1. Procedures for user identity verification using the Identity header field are specified in subclause 5.7.1.25. When the AS receives a SIP initial or standalone request, excluding REGISTER request, that does not contain credentials, the AS shall:

1. if a Privacy header field is present in the initial or standalone request and the Privacy header field value is set to "id" or "user", then the user and the request are considered as anonymous, and no further actions are required. The AS shall consider the request as authenticated;
2. if there is no Privacy header field present in the initial or standalone request, or if the Privacy header field contains a value other than "id" or "user", then the AS shall check for the presence of a P-Asserted-Identity header field in the initial or standalone request. Two cases exist:
   1. the initial or standalone request contains a P-Asserted-Identity header field. This is typically the case when the user is located inside a trusted domain as defined by subclause 4.4. In this case, the AS is aware of the identity of the user and no extra actions are needed. The AS shall consider the request as authenticated; and
   2. the initial or standalone request does not contain a P-Asserted-Identity header field. This is typically the case when the user is located outside a trusted domain as defined by subclause 4.4. In this case, the AS does not have a verified identity of the user. The AS shall check the From header field of the initial or standalone request. If the From header field value in the initial or standalone request is set to "Anonymous" as specified in RFC 3261, then the user and the request are considered as anonymous and no further actions are required. If the From header field value does not indicate anonymity, then the AS shall challenge the user by issuing a 401 (Unauthorized) response including a challenge as per procedures described in RFC 3261.

When the AS receives a SIP initial or standalone request that contains credentials but it does not contain a P-Asserted-Identity header field the AS shall check the correctness of the credentials as follows:

1. If the credentials are correct, then the AS shall consider the identity of the user verified, and the AS shall consider the request as authenticated;
2. If the credentials are not correct, the AS may either rechallenge the user by issuing a 401 (Unauthorized) response including a challenge as per procedures described in RFC 3261 (up to a predetermined maximum number of times predefined in the AS configuration data), or consider the user as anonymous. If the user is considered anonymous, the AS shall consider the request as authenticated.

Once the AS have tried to verify the identity of the user, the AS either has a verified identity of the user or it considers the user as anonymous. If the user is considered anonymous, the AS shall check whether the authorization policy defined for this request allows anonymous requests. If anonymous requests are allowed, then the AS can proceed with the requested functionality, otherwise, the AS shall not proceed with the requested functionality. If the user is identified by an identity, the AS shall apply the authorization policy related to the requested functionality to detect whether the particular user is allowed to request the functionality. The authorization policy may require a verified identity of a user. If the request is authorized then the AS shall continue with the procedures as defined for that request. If the request is not authorized, the AS shall either:

• reject the request according to the procedures defined for that request e.g., by issuing a 403 (Forbidden) response; or
• send a 2xx final response if the authorization policy requires to deny the requested functionality, whilst appearing to the user as if the request has been granted.

If the AS has a local configuration information limiting the rate at which notification generation is allowed, then the AS shall take that information into account. Such local configuration information could be e.g. the shortest time period between issuing consecutive NOTIFY requests.

It is possible for an AS to use a GRUU referring to itself when inserting a contact address in a dialog establishing or target refreshing SIP message. This specification does not define how GRUUs are created by the AS; they can be provisioned by the operator or obtained by any other mechanism. The GRUU shall remain valid for the time period in which features addressed to it remain meaningful. The AS shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which the GRUU was provided. When an AS is acting as a routeing B2BUA (as defined in subclause 5.7.5) it may provide a contact address that is not a GRUU when the contact address in the incoming message that is being replaced is not a GRUU. When an AS is acting as a routeing B2BUA forwards a SIP request it shall transparently forward a received Contact header field when the Contact header field contains a GRUU. When transparently forwarding a received Contact header field of a dialog-forming request, the AS shall include its own URI in a Record-Route header field in order to ensure that it is included on the route of subsequent requests. When an AS acts as UA or Initiating B2BUA it shall use a GRUU as the contact address if the AS acts as a notifier per RFC 6665 and RFC 7647, otherwise the AS may provide a contact address that is not a GRUU in cases where it can ascertain that valid requests that could result from the use of that contact and follow the usage rules of RFC 5627 will reach the element. In all other cases the AS shall use a GRUU. An AS acting as a UA or an initiating B2BUA on behalf of a public user identity can provide a GRUU in the contact address referring to itself as described above. When the AS provides a GRUU on behalf of a user, subsequent dialog-initiating requests sent to that GRUU will be routed directly to the AS, thus bypassing terminating services assigned to the user. If the AS wishes to have terminating services applied for the user, the AS may generate a new terminating request addressed to a public GRUU associated with the public user identity of the user. When an AS acts as a UA or an initiating B2BUA, and is originating or terminating a request on behalf of a public user identity, and privacy is required, the AS shall ensure that any GRUU provided in the contact address in the request does not reveal the public user identity of the user.

Based on service logic, an AS can validate an ICSI value received in an Accept-Contact header field or received in a P-Asserted-Service header field and reject the request if necessary. A trusted AS may insert a P-Asserted-Service header field in a request for a new dialog or standalone transaction. An untrusted AS may insert a P-Preferred-Service header field in a request for a new dialog or standalone transaction. If the request is related to an IMS communication service that requires the use of an ICSI then the AS:

• shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that is related to the request in either a P-Asserted-Service header field or a P-Preferred-Service header field depending whether the AS is trusted or not according to RFC 6050.

When an AS that is acting as a UA or initiating B2BUA or routeing B2BUA sends an initial request for a dialog or a request for a standalone transaction, the AS may include an Accept-Contact header field containing:

• an ICSI value (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3841; and
• one or more IARI values (coded as specified in subclause 7.2A.9.2) that are related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841;

if the ICSI or IARIs for the IMS communication service and IMS application are known. The AS may:

• include the received ICSI and IARI values;
• replace or remove received ICSI and IARI values; or
• include new ICSI and IARI values.

When the AS acting as a UA or initiating B2BUA or routeing B2BUA sends a SIP request or a SIP response related to an IMS communication service, the AS may include in the Contact header field:

• in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 one or more ICSI values (coded as specified in subclause 7.2A.8.2); and
• one or more IARI values (coded as specified in subclause 7.2A.9.2) in a g.3gpp.iari-ref media feature tag, for the IMS applications, that are related to the request as defined in subclause 7.9.2 and RFC 3840;

if the ICSI or IARIs for the IMS communication service and IMS application are known. The AS may:

• include the received ICSI and IARI values;
• replace or remove received ICSI values; or
• include new ICSI and IARI values.

When sending a 18x or 2xx response to a request on behalf of an originating user, then the AS may insert a Feature-Caps header field with the "+g.3gpp.icsi-ref" header field parameter into the response, as specified in RFC 6809. The parameter value is set according to subclause 7.9A.2. When sending a request on behalf of a terminating user, then the AS may insert a Feature-Caps header field with the "+g.3gpp.icsi-ref" header field parameter. The parameter value is set according to subclause 7.9A.2. If the AS inserted the header field parameters in the Feature-Caps header field in the request or in 18x or 2xx response to request then the AS shall include the header field parameters with the same parameter values into the Feature-Caps header field in any target refresh request, and in each 1xx or 2xx response to target refresh request sent in the same direction.

An AS may play a role in support of carrier selection as defined in RFC 4694. When an AS that supports carrier selection receives an initial request with a Request-URI in the form of a tel-URI that contains a "cic" tel-URI parameter inserted by the UE and if configured per operator policy, the AS may validate the value of the "cic" parameter. If an AS that supports carrier selection determines the "cic" parameter received in the initial request to be valid, as configured per operator policy, the AS shall process the request accordingly. If an AS supports carrier selecton and determines the "cic" parameter received in the initial request to be invalid, then the AS shall remove the "cic" parameter and process the request as if no "cic" had been received from the UE. When an AS that support carrier selection receives an initial request with a Request-URI in the form of a tel-URI, the AS may, based on operator policy, insert an appropriate value for the "cic" tel-URI parameter as defined in RFC 4694. When an AS that support carrier selection receives an initial request with a Request-URI in the form of a SIP URI user=dialstring (see RFC 4967), the AS may translate the SIP URI to a valid tel-URI or a valid SIP URI user=phone comprising a userinfo part containing the tel-URI and a domain matching the domain of the original SIP URI user=dialstring. If the received SIP URI user=dialstring is successfully converted, then the AS shall replace the Request-URI with the newly created tel-URI or SIP URI user=phone. The AS shall then process the request as if it had arrived from the UE containing this tel-URI or SIP URI user=phone in the Request-URI. The AS carrier selection procedures also apply when the request contains a Request-URI in the form of a SIP URI user=phone, where the "cic" tel-URI parameter is contained in the userinfo part of the SIP URI.

An AS can retrieve tracing configuration information from the HSS via the Sh reference point. The AS tracing configuration can use the parameters specified in TS 24.323 but need not structure them as a management object.

If the service the AS provides needs to deliver the original destination identity to the UE, the AS shall insert a new hi-entry to the last hi-entry of History-Info header field including "mp" header field parameter as specified in RFC 7044.

The AS may populate the "cpc" and "oli" URI parameters in each initial request for a dialog or a request for a standalone transaction in the tel URI or SIP URI representation of telephone numbers in the P-Asserted-Identity header field based on their origin source.

Identification of emergency transactions for termination in the public network by an AS are outside the scope of this document, and are dependent on many application specific considerations. Where an AS decides to generate an emergency request on behalf of its served user, the AS shall meet the following conditions:

1. the UE is in the same network as the S-CSCF (i.e. that the UE is not roaming).

The AS generate the request with the following contents:

1. include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031. An additional sub-service type can be added if information on the type of emergency service is known;
2. a Route header field with the topmost Route header field set to the URI associated with an E-CSCF;
3. if the AS is part of the trust domain of the network, a P-Asserted-Identity header field containing the identity of the UE served by the AS;
4. if the AS is not part of the trust domain of the network, a P-Preferred-Identity header field containing the identity of the UE served by the AS;
5. if a GRUU is available for the UE served by the AS, provide the GRUU as part of a Contact header field;
6. if a location is available at the AS in any form, include a Geolocation header field with that location;
7. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260;
8. if the AS supports calling number verification using signature verification and attestation information as specified in subclause 3.1 and if required by operator policy, the AS shall perform attestation of the user identity by inserting:
   • a "verstat" tel URI parameter, specified in subclause 7.2A.20, to the tel URI or SIP URI with a user=phone parameter in the From header field or the P-Asserted-Identity header field;
   • an Attestation-Info header field, specified in subclause 7.2.18; and
     an Origination-Id header field, specified in subclause 7.2.19, set to a UUID identifying the AS which is configured based on local policy and requirements from national regulation; and
9. if the AS supports priority verification using assertion of priority information as specified in subclause 3.1 and if required by operator policy, the AS shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197].

If the AS does not receive any response to the INVITE request (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an INVITE request, the AS shall select a new E-CSCF and forward the INVITE request.

The AS upon receiving a 3xx response to a request from the served UE that contains a Contact header field may remove the Contact header field or modify the response code from 3xx to an appropriate non 2xx response code (e.g. 5xx response code) based on operator policy before sending the response towards the UE.

If the AS supports delivery of network provided location information, and the AS performs the retrieval of cell id and/or UE time zone via Sh interface, the AS shall insert the P-Access-Network-Info header field with the cell id, local-time-zone parameter and/or the "daylight-saving-time" parameter, including a "network-provided" parameter in the incoming request or response. Additionally, if required by local operator policy and the AS is able to deduce a Geographical Identifier from the Cell Global Identity (CGI) or form the Service Area Identifier (SAI), the AS shall include an operator-specific-GI header field parameter. The P-Access-Network-Info header field shall only be inserted if there is not already a network provided information. When the AS receives, in a SIP request or response, a P-Access-Network-Info header field which does not contain the operator-specific-GI header field parameter, contains a Cell Global Identity (CGI) or a Service Area Identifier (SAI) information and contains the "network provided" header field parameter, if required by local operator policy and if the AS is able to deduce a Geographical Identifier from the contained Cell Global Identity (CGI) or form the contained Service Area Identifier (SAI), the AS shall instert an operator-specific-GI header field parameter in that received network provided P-Access-Network-Info header field. The AS can obtain a Geographical Identifier from the CLF by using the e2 interface (see ETSI ES 283 035 [98]).

A visited MRB address can be received during session establishment. If an AS receives the URI of an MRB in a "+g.3gpp.mrb" header field parameter included in a Feature-Caps header field of an INVITE request, it shall store this URI. If the AS requests allocation of MRF resources from an MRB in its own network, either in in-line or query mode, the AS shall forward the visited network MRB URI in the request.

If an AS supports dynamic service interaction, the AS should insert the Service-Interact-Info header field into the SIP messages before those messages are sent out. The Service-Interact-Info field is filled with the service identities of the services which have been executed. Additionally, the AS may insert into the Service-Interact-Info header field with the identities of the services which may have confliction with the executed services according to local policy. If the AS supports dynamic service interaction, it should take the information contained in any received Service-Interact-Info header field into account when executing service logic. If the AS does not recognize the service identities contained in the Service-Interact-Info header field, they should be ignored.

When the AS is accessed by a service access number (e.g. toll free, premium service) and performes a translation of this number into a routeable number, the AS shall include in the outgoing request:

1. the Request-URI set to the targeted SIP URI containing the "cause" SIP URI parameter, defined in RFC 4458, set to the value "380" defined in RFC 8119; and
2. the History-Info header field constructed according to RFC 7044 in which the hi-targeted-to-uri of the last hi-entry is set to the new Request-URI with the "cause" SIP URI parameter, defined in RFC 4458, set to the value "380" defined in RFC 8119.

A service access number does not constrain the number format. A local service number as defined in TS 23.228 and described in subclause 5.7.1.7 can be a service access number.

An AS shall handle re-INVITE request collisions as specified in RFC 3261 with the clarification in this subclause. When the AS receives a SIP 491 (Request Pending) response to a re-INVITE request initiated by the AS and sent towards the remote user, the AS shall:

1. if the AS is serving the user at the originating side of the call, act as the the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 2.1 and 4 seconds in units of 10 ms; and
2. if the AS is serving the user at the terminating side of the call, act as not being the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 0 and 2 seconds in units of 10 ms.
   When the AS receives a SIP 491 (Request Pending) response to a re-INVITE request initiated by the AS and sent towards the served user, the AS shall:
   1. if the AS is serving the user at the originating side of the call, act as not being the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 0 and 2 seconds in units of 10 ms; and
   2. if the AS is serving the user at the terminating side of the call, act as the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 2.1 and 4 seconds in units of 10 ms.

An AS that supports 3GPP PS data off can receive in the message/SIP MIME body in a third party REGISTER request the REGISTER request sent by the UE. If this REGISTER request contains a "+g.3gpp.ps-data-off" Contact header field parameter the AS can determine that the UE supports 3GPP PS data off, and the value of the parameter indicates the 3GPP PS data off status. When the AS receives an initial request for a dialog or a standalone transaction destined to the served user, if:

• the latest "+g.3gpp.ps-data-off" Contact header field parameter, specified in subclauce 7.9.8, that was received in a third party REGISTER request, as specified above, was set to "active" in the UE; and
• the service the AS supports is not configured as a 3GPP PS data off exempt service to be used in the HPLMN,the EHPLMN or the subscribed SNPN, or the service the AS support is not configured as a 3GPP PS data off exempt service to be used in the VPLMN or the non-subscribed SNPN;

the AS shall not send the request to the UE via GPRS IP-CAN, EPS IP-CAN or 5GS IP-CAN.