Content for  TS 24.229  Word version:  19.0.0

When acting as a terminating UA the AS shall behave as defined for a UE in subclause 5.1.4, with the exceptions identified in this subclause. The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem. If the AS requires knowledge of the served user it shall determine the served user according to the applicable procedure in subclause 5.7.1.3A. An AS acting as redirect server shall propagate any received IM CN subsystem XML message body in the redirected message. When an AS acting as a terminating UA generates a subsequent request for a dialog, the AS shall insert a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter. When the AS acting as terminating UA receives a request, the AS shall store the value of the "orig-ioi" header field parameters received in the P-Charging-Vector header field if present. When the AS acting as terminating UA generates a response to a request, the AS shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter 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. The AS acting as terminating UA receiving an initial request with a P-Charging-Vector header field shall, based on local policy, store the "fe-identifier" header field parameter of the P-Charging-Vector header field. The AS acting as terminating UA shall, based on local policy, include the stored "fe-identifier" header field parameter in the P-Charging-Vector header field, add its address or identifier and application id to the "as-addr" and "as-id" elements of the "fe-identifier" header field parameter of the P-Charging-Vector header field and send the P-Charging-Vector header field in the related final response. If resource priority in accordance with RFC 4412 is required for a dialog, then the AS shall include the Resource-Priority header field in all requests associated with that dialog. If priority is supported, the AS shall take into account that subsequent received SIP requests or responses within the same dialog or transaction may have added or changed the Resource-Priority header field or backwards indication.

In order to support an AS acting as an originating UA, the AS has to be within the same trust domain as the S-CSCF to which requests will be sent. When acting as an originating UA the AS shall behave as defined for a UE in subclause 5.1.3, with the exceptions identified in this subclause. The AS, although acting as a UA, does not initiate any registration of its associated addresses and does not participate in any authentication procedures defined for a UE. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem. When an AS acting as an originating UA generates an initial request for a dialog or a request for a standalone transaction, the AS shall insert 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 AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter. When the AS acting as an originating UA receives any response to a request, the AS shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field if present. When an AS acting as an originating UA generates a subsequent request for a dialog, the AS shall insert a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter. Based on local policy, the AS acting as an originating UA or application(s) hosted by the AS acting as originating UA shall add an "as-addr" and an "as-id" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier and application identifier to an initial request. The AS shall extract charging function addresses from any P-Charging-Function-Addresses header field that is received in any 1xx or 2xx responses to the requests. The AS may also indicate that the proxies should not fork the request by including a "no-fork" directive within the Request-Disposition header field in the request as described in RFC 3841. When sending any initial request, an identity is needed that will correlate with the service profile to be used at the S-CSCF. If the identity for that service profile corresponds to the value to be used to identify the caller to the destination user, include the identity in the P-Asserted-Identity header field. If the identity for that service profile does not correspond to the value to be used to identify the caller to the destination user, and the P-Served-User header field is supported by the S-CSCF, include the identity in the P-Served-User header field. This leaves the P-Asserted-Identity header field for the identity to be used to identify the caller to the destination user. If the identity for that service profile matches a wildcarded identity and the P-Profile-Key header field is supported by the AS, include the wildcarded identity in the P-Profile-Key header field. When sending an initial request on behalf of a PSI that is hosted by the AS, the AS shall:

• insert a Request-URI as determined by the service logic;
• insert a P-Asserted-Identity header field and possibly a P-Served-User header field containing the PSI as indicated earlier in this subclause;
• if the AS is not able to resolve the next hop address by itself or the operator policy does not allow it, insert a Route header field pointing either to the S-CSCF where the PSI is hosted, or to the entry point of the home network of the PSI or to the transit function. The AS shall append the "orig" parameter to the URI in the topmost Route header field; and
• if the AS is able to resolve the next hop address by itself and the operator policy allows it, forward the originating request directly to the destination without involving any S-CSCF in the originating IM CN subsystem.

When sending an initial request on behalf of a public user identity, the AS shall:

• insert a Request-URI as determined by the service logic;
• insert a P-Asserted-Identity header field and possibly a P-Served-User header field containing the public user identity as indicated earlier in this subclause;
• if the AS intends to send the originating request to the home network of the public user identity or the operator policy requires it, insert a Route header field pointing to the S-CSCF where the public user identity on whose behalf the request is generated is registered or hosted (unregistered case) or to the entry point of the public user identity's network. The AS shall append the "orig" parameter to the URI in the topmost Route header field; and
• if the AS intends to send the originating request directly to the terminating network and the operator policy allows it, forward the originating request directly to the destination without involving any S-CSCF in the originating IM CN subsystem.

When sending an initial request to a served public user identity, the AS shall insert:

• a Request-URI containing the served public user identity;
• a P-Asserted-Identity as determined by the service logic (e.g. the URI of the AS or the URI of the entity that triggered the SIP request, if the sending of the initial request is triggered by a non-SIP request); and
• a Route header field pointing to the S-CSCF where the public user identity to whom the request is generated is registered or hosted (unregistered case) or to the entry point of the public user identity's network. The AS shall not append the "orig" parameter to the URI in the topmost Route header field.

The AS can indicate privacy of the P-Asserted-Identity in accordance with RFC 3323, and the additional requirements contained within RFC 3325. Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the AS shall set a display-name of the From header field to "Anonymous" as specified in RFC 3261 and set an addr-spec of the From header field to Anonymous User Identity as specified in TS 23.003. If resource priority in accordance with RFC 4412 is required for a dialog, then the AS shall include the Resource-Priority header field in all requests associated with that dialog. If priority is supported, the AS shall take into account that subsequent received SIP requests or responses within the same dialog or transaction may have added or changed the Resource-Priority header field or backwards indication.

When the AS acting as a SIP proxy receives a request from the S-CSCF, prior to forwarding the request, the AS shall:

• remove its own URI from the topmost Route header field;
• if the request contains a "logme" header field parameter in the SIP Session-ID header field then log the request if required by local policy; and
• after executing the required services, route the request based on the topmost Route header field.

When the AS acting as a SIP proxy receives any response to the above request, the AS shall:

• if the response contains a "logme" header field parameter in the SIP Session-ID header field then log the request if required by local policy.

The AS may modify the SIP requests based on service logic, prior to forwarding the request back to the S-CSCF. The AS shall not fork the request if the fork-directive in the Request-Disposition header field is set to "no-fork" as described in RFC 3841. If the AS requires knowledge of the served user it shall determine the served user according to the applicable procedure in subclause 5.7.1.3A. An AS acting as a SIP proxy shall propagate any received IM CN subsystem XML message body in the forwarded message. When the AS acting as a SIP proxy receives a request, the AS shall store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present. The AS shall remove the "orig-ioi" header field parameter from the forwarded request and insert a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter. When the AS acting as a SIP proxy forwards a response to a request, the AS shall remove any received "orig-ioi" and "term-ioi" header field parameters, and insert a P-Charging-Vector header field containing the previously stored "orig-ioi" header field parameter, if received in the request and a type 3 "term-ioi" 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 and the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter. Any values of "orig-ioi" or "term-ioi" header field parameters received in any response that is being forwarded are not used. Based on local policy, the AS acting as a SIP proxy shall add an "as-addr" and an "as-id" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier and application identifier.