Figure 5.1.1 illustrates the architecture with the S-CSCF communicating to Application Servers via the IP multimedia service control (ISC) interface. The Application Servers can be:

• SIP Application Servers - which may host and execute services. It is intended to allow the SIP Application Server to influence and impact the SIP session on behalf of the services;
• the IM-SSF - which is a particular type of application server the purpose of which is to host the CAMEL network features (i.e. trigger detection points, CAMEL Service Switching Finite State Machine, etc) and to interface to CAP as specified in TS 29.078;
• the OSA service capability server (OSA SCS) which interfaces to the OSA framework Application Server and which provides a standardized way for third party secure access to the IM subsystem. The OSA reference architecture defines an OSA Application Server as an entity that provides the service logic execution environment for client applications using the OSA API as specified in TS 29.198. This definition of Application Server differs from the definition of Application Server in the context of service provisioning for the IM subsystem, i.e. the entity communicating to the S-CSCF via the ISC interface;
• in addition a specialized type of SIP Application Server, the service capability interaction manager (SCIM) which performs the role of interaction management between other application servers.

All the Application Servers, (including the IM-SSF and the OSA SCS) behave as SIP application servers on the ISC interface.

In addition the Application Servers can also interact with the MRFC via the S-CSCF (ISC, Mr), directly via the Mr' interface and via the Cr interface in order to control Multimedia Resource Function processing and can interact with the MRB (Rc interface, or Mr, and Mr' interfaces) in order for appropriate media resources to be assigned to calls (see clause 8 and clause 13). This is shown in Figure 5.1.2. The AS can request MRF resources directly based on preconfigured addresses and DNS lookup, or indirectly using an MRB function, which will determine the most suitable resource (see clause 13). An application server can provide the MRB with information to assist the MRB in determining the most appropriate resource. Aside from information on type of resource required, this can include information on other supporting MRBs in other networks, e.g. the visited network of a roaming user, or more information on the location of the endpoint to which the media is to be delivered, such that this may assist in determining the best location for proving the MRF.

Subclause 4.14 of TS 23.228 identifies the possibility of border control functions between two IM CN subsystems or between an IM CN subsystem and other SIP based multimedia network. Additional functionality may also be required on the ISC interface where an application server provided by a third-party service provider is supported. An additional functionality called an ISC gateway function is defined as shown in Figure 5.1.2A.

The functions of the ISC gateway function are as follows:

• network configuration hiding (as for the IBCF);
• application level gateway (transcoding is not applicable for ISC gateway function);
• transport plane control, i.e. QoS control (as for the IBCF); and
• screening of SIP signalling (as for the IBCF).

While the ISC gateway function can alter the contents of the protocol on the ISC interface, the information carried should still conform to that required for the ISC interface.

Subclause 4.14 of TS 23.228 identifies the possibility of border control functions between two IM CN subsystems or between an IM CN subsystem and other SIP based multimedia network. A number of the interfaces identified in the architecture in subclause 5.1.1 and subclause 5.1.2 can be between the networks controlled by different operators, specifically the Mr, Mr' and Cr interfaces (for example between a third-party service provider and the visited network, or between the home network and the visited network. When used on the Mr, and Mr' interfaces, the IBCF should not be used to duplicate the functions normally performed by the MRF, even if the MRF is being accessed for another unrelated function. Rather, an MRF should be used for supporting those functions. Both the SIP control package on the Cr interface, and the Mr interface when used in in-line aware MRB mode, can contain information that an operator, for example, would prefer not to exchange with another network operator. For this information, it may be appropriate to use the MRB either in the network of the application server, or the MRB in the network where the MRF is sought, to operate in in-line aware MRB mode and to remove such information. The IBCF is not used on the Cr interface. In normal operation, the communication between the application server and the MRF is a communication where those functional entities form the endpoint of the communication. Therefore any information included in the signalling is deemed by one endpoint to be essential to the functionality performed by the other. As such, configuration hiding, screening and privacy functions are not expected to be critical functions on any of these interfaces. If the network is supporting optimisation of media paths, then the IBCF could well be required on the Mr and Mr' interfaces to support optimal media routeing. For the Mr and Mr' interfaces, the IBCF may be used to support communication between the AS and the MRB, between the AS and the MRFC, between the S-CSCF and the MRB, between the S-CSCF and the MRFC. Where this occurs, requests to the IBCF are sent over the Mx interface and requests from the IBCF are sent over the Mm interface (see subclause I.2 of TS 23.228). Two IBCFs on either side of an interoperator boundary use the Ici interface (see subclause K.2 of TS 23.228). The IBCF providing IMS-ALG functions would be supported by TrGW functions using the Ix interface (see subclause I.2 of TS 23.228), so the media from an MRFP may pass through the Izi interface where two TrGWs exist on either side of an interoperator boundary. For the Rc interface, border control functionality can exist, but the mechanism are not specified. The IBCF is not used. Many techniques exist and are deployed for supporting border functions in HTTP, and any of these can be used on the Rc interface if they meet the needs of the deployer.

Service Point Triggers (SPTs) are those points in the SIP signalling on which Filter Criteria can be set. The following SPTs are defined:

• any initial known or unknown SIP method;
• registration type - indicates if the REGISTER request is initial registration, re-registration, or de-registration;
• presence or absence of any known or unknown header field;
• content of any known or unknown header field or of the Request-URI;
• direction of the request with respect to the served user - either UE-originating or UE-terminating to registered user; UE-terminating to unregistered user or UE-originating for unregistered user; see TS 29.228 for the details of the direction information in service point trigger;
• session description information.

A Filter Criteria triggers one or more SPTs in order to send the related request to one specific application server. The set of Filter Criteria that is stored for a service profile of a specific user is called "Application Server Subscription Information". In order to allow the S-CSCF to handle the different Filter Criteria in the right sequence, a priority shall be assigned to each of them. If the S-CSCF can not reach the specified Application Server, the S-CSCF shall apply the default handling associated with the trigger. This default handling shall be :

• to continue verifying if the triggers of lower priority in the list match; or
• to abandon verification of matching of the triggers of lower priority in the list; and to release the dialogue.

Therefore a Filter Criteria shall contain the following information:

• address of the Application Server to be contacted;
• priority of the Filter Criteria providing the sequence in which the criteria shall be applied;
• Trigger Point composed by 1 to n instances of the Service Point Triggers (SPTs). The SPTs may be linked by means of logical expressions (AND, OR, NOT, etc.);
• default handling ( as described above);
• optional Service Information that shall be added to the message body before it is sent to the Application Server (as an example this may include the IMSI for the IM-SSF).
• optionally an indication to include the incoming REGISTER request in the third party REGISTER request.
• optionally an indication to include the final response to the incoming REGISTER request in the third party REGISTER request.

The same priority shall not be assigned to more than one initial Filter Criteria for a given served user.

The S-CSCF shall request from the HSS the relevant set of iFCs that applies to the served user (i.e., registered, unregistered, or both). If the S-CSCF has a set of iFCs that is deemed valid (e.g., from a previous request), the S-CSCF need not request a new set. In the case that multiple Filter Criteria are sent from the HSS to the S-CSCF, the S-CSCF shall check the filter criteria one by one according to their indicated priority when the S-CSCF receives a message via the Mw interface. On reception of a REGISTER request, the S-CSCF shall send a third-party REGISTER request to each Application Server that matches the Filter Criteria sent from the HSS for the REGISTER request. The S-CSCF shall include in the third-party REGISTER request the incoming REGISTER request if indicated by the Filter Criteria. The S-CSCF shall include in the third-party REGISTER request the final response to the incoming REGISTER request if indicated by the Filter Criteria. On an event that causes network-initiated deregistration, the S-CSCF shall send a third-party REGISTER request to each Application Server that matches the Filter Criteria sent from the HSS as if a equivalent REGISTER request had been received from the user deregistering that public user identity, or combination of public user identities. On reception of any other request the S-CSCF shall:

1. set up the list of filter criteria for that request according to their priority - the sequence of the filter criteria shall not be changed until the request finally leaves the S-CSCF via the Mw interface again;
2. parse the received request in order to find out the Service Point Triggers (SPTs) that are included in it;
3. check whether the trigger points of the filter criteria with the next highest priority are matched by the SPTs of the request and
   1. if it does not match the S-CSCF shall immediately proceed with step 4;
   2. if it matches the S-CSCF shall:
      1. add an Original Dialog Identifier (ODI) to the request which will allow the S-CSCF to identify the message on the incoming side, even if its dialog identification has been changed e.g. due to the Application Server performing third party call control;
      2. forward the request via the ISC interface to the Application Server indicated in the current filter criteria. The Application Server then performs the service logic, may modify the request and may send the request back to the S-CSCF via the ISC interface;
      3. proceed with step 4 if a request with the same ODI is received from the Application Server via the ISC interface;
4. repeat the above steps 2 and 3 for every filter criteria which was initially set up (in step 1) until the last filter criteria has been checked;
5. route the request based on normal SIP routing behaviour.

If an Application Server decides to locally terminate a request and sends back a final response for that request via the ISC interface to the S-CSCF, the S-CSCF shall abandon verification of the matching of the triggers of lower priority in the list.

Each invoked Application Server/service logic may decide not to be engaged with the invoked session by indicating that during the very first SIP transaction when the Record-Route/Route is generated for subsequent SIP requests. The denial shall mean that subsequent requests shall not be routed to such Application Servers/service logic any more during the lifetime of that session. Any Application Server, which has determined that it will not receive subsequent requests for a session cannot revoke this determination by means of Initial Filter Criteria (iFC).

A Transit Invocation Criteria triggers one or more SPTs in order to send the related request to one specific application server. The set of Transit Invocation Criteria is not user specific, but instead is based on e.g. the originating and terminating networks. The handling of Transit Invocation Criteria is identical to the handling of Filter Criteria, as defined in subclase 5.2.2.

The Transit Invocation Criteria are locally configured. In case that multiple Transit Invocation Criteria is configured, the Transit Function shall check the criteria one by one according to their indicated priority when the Transit Function receives a message. On reception of an initial request, or a standalone request, the Transit Function shall:

1. set up the list of Transit Invocation Criteria for that request according to their priority - the sequence of the criteria shall not be changed until the request finally leaves the Transit Function towards the terminating network;
2. parse the received request in order to find out the Service Point Triggers (SPTs) that are included in it, and in priority order for each Transit Invocation Criteria:
   1. check whether the trigger points of the Transit Invocation Criteria are matched by the SPTs of the request;
   2. if it matches the Transit Function shall:
      1. add an Original Dialog Identifier (ODI) to the request which will allow the Transit Function to identify the message on the incoming side, even if its dialog identification has been changed e.g. due to the Application Server performing third party call control;
      2. forward the request via the ISC interface to the Application Server indicated in the current filter criteria. The Application Server then performs the service logic, may modify the request and may send the request back to the Transit Function via the ISC interface;
      3. proceed with next Transit Invocation Criteria in a) if a request with the same ODI is received from the Application Server via the ISC interface;
   3. if it does not match, proceed with next Transit Invocation Criteria in a) for every Transit Invocation Criteria which was initially set up (in step 1) until the last criteria has been checked;
3. route the request based on normal SIP routing behaviour.

If an Application Server decides to locally terminate a request and sends back a final response for that request via the ISC interface to Transit Function, the Transit Function shall abandon verification of the matching of the triggers of lower priority in the list. Each invoked Application Server/service logic may decide not to be engaged with the invoked session by indicating that during the very first SIP transaction when the Record-Route/Route is generated for subsequent SIP requests. The denial shall mean that subsequent requests shall not be routed to such Application Servers/service logic any more during the lifetime of that session. Any Application Server, which has determined that it will not receive subsequent requests for a session cannot revoke this determination by means of Transit Invocation Criteria.