The ISC interface is between the Serving CSCF and the service platform(s).
An Application Server (AS) offering value added IM services resides either in the user's home network or in a third party location. The third party could be a network or simply a stand-alone AS.
The Serving-CSCF to AS interface is used to provide services residing in an AS. Two cases were identified:
-
Serving-CSCF to an AS in Home Network.
-
Serving-CSCF to an AS in External Network (e.g., Third Party or Visited)
The SIP Application Server may host and execute services. The SIP Application Server can influence and impact the SIP session on behalf of the services and it uses the ISC interface to communicate with the S-CSCF. The S-CSCF shall be able to supply the AS with information to allow it to execute multiple services in order within a single SIP transaction.
The ISC interface shall be able support subscription to event notifications between the Application Server and S-CSCF to allow the Application Server to be notified of the implicit registered Public User Identities, registration state and UE capabilities and characteristics in terms of SIP User Agent capabilities and characteristics.
The S-CSCF shall decide whether an Application Server is required to receive information related to an incoming initial SIP request to ensure appropriate service handling. The decision at the S-CSCF is based on (filter) information received from the HSS. This filter information is stored and conveyed on a per Application Server basis for each user. It shall be possible to include a service indication in the filter information, which is used to identify services and the order that they are executed on an Application Server within a single SIP transaction. The name(s)/address(es) information of the Application Server (s) are received from the HSS.
For an incoming SIP request, the S-CSCF shall perform any filtering for ISC interaction before performing other routing procedures towards the terminating user, e.g. forking, caller preferences etc.
The S-CSCF does not handle service interaction issues.
Once the IM SSF, OSA SCS or SIP Application Server has been informed of a SIP session request by the S-CSCF, the IM SSF, OSA SCS or SIP Application Server shall ensure that the S-CSCF is made aware of any resulting activity by sending messages to the S-CSCF.
From the perspective of the S-CSCF, the "SIP Application server", "OSA service capability server" and "IM-SSF" shall exhibit the same interface behaviour.
When the name/address of more than one Application Server is transferred from the HSS, the S-CSCF shall contact the Application Servers in the order supplied by the HSS. The response from the first Application Server shall be used as the input to the second Application Server. Note that these multiple Application Servers may be any combination of the SIP Application server, OSA service capability server, or IM-SSF types.
The S-CSCF does not provide authentication and security functionality for secure direct third party access to the IM subsystem. The OSA framework provides a standardized way for third party secure access to the IM subsystem.
If a S-CSCF receives a SIP request on the ISC interface that was originated by an Application Server destined to a user served by that S-CSCF, then the S-CSCF shall treat the request as a terminating request to that user and provide the terminating request functionality as described above. Both registered and unregistered terminating requests shall be supported.
It shall be possible for an Application Server to generate SIP requests and dialogs on behalf of users. Requests originating sessions on behalf of a user are forwarded to the S-CSCF serving the user, if the AS has knowledge of the S-CSCF assigned to that user and the S-CSCF shall perform regular originating procedures for these requests.
Originating requests on behalf of registered and unregistered users shall be supported.
More specifically the following requirements apply to the IMS Service control interface:
-
The ISC interface shall be able to convey charging information as per TS 32.240 and TS 32.260.
-
The protocol on the ISC interface shall allow the S-CSCF to differentiate between SIP requests on Mw, Mm and Mg interfaces and SIP Requests on the ISC interface.
Besides the Cx interface the S-CSCF supports only one standardised protocol for service control, which delegates service execution to an Application Server. The protocol to be used on the ISC interface shall be SIP (as defined by
RFC 3261, other relevant IETF RFC's, and additional enhancements introduced to support 3GPP's needs on the Mw, Mm, Mg interfaces).
The notion of a "SIP leg" used throughout this specification is identical to the notion of a call leg which is the same as a SIP dialog defined by
RFC 3261. The same SIP leg that is received by the S-CSCF on the Mw, Mm and Mg interfaces is sent on the ISC interface. The same SIP leg that is received by the S-CSCF on the ISC interface is sent on the Mw, Mm and Mg interfaces.
Concerning the relationship between the SIP legs of the ISC interface and the SIP legs of the Mw, Mm, and Mg interfaces the S-CSCF acts as a SIP proxy, as shown in Figures 4.3a - 4.3e below.
Figures 4.3a-4.3e below depict the possible high-level interactions envisioned between the S-CSCF and the Application Server.