Content for  TS 23.218  Word version:  18.0.0

The functional mode of application server is shown in Figure 9.1.1. For an UE-originating request, the AS-ILCM may interact with the application logic reporting call state information. Depending on the service that is being provided, the application logic may instruct the AS-OLCM to modify the request if needed (e g. by inserting itself in the Record-Route etc). After processing the request the AS-OLCM may send this request back to the S-CSCF. When the AS acts as a B2BUA, the application server shall maintain and correlate the multiple dialogues that it creates. It shall be responsible for correlating the dialogue identifiers and shall decide when to translate a message from one dialog to the other, or when to perform other functions based on the instruction from the application logic. If an AS that supports a IMS communication service is acting as an initiating B2BUA and and it receives an initial request or standalone transaction without an ICSI, it can insert an ICSI appropriate to the service it is performing on other legs and can also insert an ICSI appropriate to the service it is performing on the originating leg in appropriate SIP response messages on the originating leg. An AS that supports a IMS communication service that is acting as an originating UA can insert an ICSI appropriate to the service in the request and can also insert an ICSI appropriate to the service it is performing in appropriate SIP response messages. An AS that acts as a SIP proxy or routeing B2BUA can include in the SIP request and response an indication that it is on the route of the SIP signalling and indicate the capabilities that it supports (including the ICSI) and if required can also indicate the associated address that can be used to send related requests.

The handling of UE-terminating requests is similar with the handling of UE-originating requests as defined in subclause 9.4.1.

When the user is registered with the network and has been assigned a S-CSCF, the application servers, which are interested to know about the user registration events, should get a third party registration request generated by the S-CSCF. When the application server receives the request, the Application Server may perform a service triggered by a REGISTER. If the application server doesn't support this mechanism, it shall send back an error response to the S-CSCF. If the application server supports this mechanism, it shall treat this request as a notification from the network about the user's registration event and extract the important information from this request. The application server may, depending on the Filter Criteria receive REGISTER requests indicating reregistration or deregistration events from the S-CSCF, so that the application server can update or release user's registration information. The important information carried in the third party registration request are, the public user identity, the S-CSCF address, and the expiration time. The application server can also extract user specific data from the REGISTER request, e.g. the IMSI for an Application Server that supports CAMEL services and information from the original REGISTER request included in the body. Application Servers can also subscribe to the S-CSCF Registration Event Package after receiving the third party registration request. After subscribing to the event package with the S-CSCF, the application will expect to receive the notifications from the S-CSCF, which may carry the user's implicitly registered public user identities, the user's terminal current capabilities and the user's registration event information. The application server can also obtain the user's implicitly registered public identities by accessing the HSS via Sh or Si interface. An application server will require knowledge of a user's IMS subscription information if they are to correctly apply services. This information can be provided to the application server in two ways, either:

1. Manually by provisioning. This is outside of the scope of this specification.
2. Automatically from the HSS via the Sh and Si interfaces.

More information on these procedures is contained in TS 24.229.

If an application server receives a third party REGISTER from the S-CSCF carrying the ICID, IOI and charging function addresses, the application server may store these parameters for charging purposes. In an originating case, when processing an incoming initial request carrying the ICID, IOI, access network (IP-CAN) charging information and charging function addresses for this session, the application server shall pass these parameters in the outgoing message and may store the parameters for charging purposes. In a terminating case, when processing an incoming initial request carrying the ICID, IOI, access network (IP-CAN) charging information and charging function addresses for this session, the application server shall pass these parameters in the outgoing message and may store the parameters for charging purposes. When the application server is acting as an originating user agent as described in subclause 9.1.1.2 and initiates a session or a standalone transaction, it shall generate ICID itself. Charging function addresses may be allocated as locally preconfigured addresses. The application server may retrieve the charging addresses on Sh interface. When the conflict occurs between the charging function address(es) received over the ISC interface and those received over the Sh interface, the address(es) received over the ISC interface should take precedence. For detailed information on transporting charging parameters between IMS entities using SIP, see TS 24.229.