SIS Architecture

User-provided scripts control the services that the SIS invokes for each call. The SIS defines a script syntax for compositions, which specify a collection of services and the order in which the SIS should invoke them; and triggers, which specify the service compositions the SIS should select in response to individual network triggers.

The SIS also includes a number of pre-defined service-interaction rules, which dictate how the SIS should handle the different outcomes that a service can generate. Composition scripts can influence the behaviour of many pre-defined rules. TIP: Metaswitch’s Visual Interaction Architect (VIA) is a visual design environment with a graphical interface you can use for building and scripting SIS components (triggers, compositions, and macros).

The service-interaction engine is responsible for:

Without services to invoke, the SIS would have an easy life indeed! Local services, implemented as JAIN SLEE services, reside within the local Rhino SLEE. The SIS uses a virtual view of the call, so it receives outcomes for consideration without directly affecting the actual call in the network. The SIS can also invoke services residing in external SIP ASs or IN SCPs by using new network triggers.

You can manage all facets of the SIS (such as trigger and composition deployment, user subscription provisioning, and other administration tasks) using a standard management interface. You can also monitor the SIS through various statistics that it records and reports using Rhino’s statistics monitoring subsystem. And the SIS includes several pre-defined alarm conditions, such as raising an alarm whenever a connection to the network is lost.

You can manage all facets of the SIS (such as trigger and composition deployment, user subscription provisioning, and other administration tasks) using a standard management interface. This interface consists of a collection of JMX MBeans and a command-line tool (sis-console). A SIS extension module for the Rhino Element Manager is also available.

To support the critical need to monitor SIS behaviour in real time, administrators can:

The SIS is built on the Rhino SLEE platform. As such it includes all the capabilities of Rhino — all JAIN SLEE features (for example, the JAIN SLEE resource adaptor architecture) and all Rhino features (such as the statistics client, threshold-based alarms, clustering, and so on). The SIS can run JAIN SLEE services, which can any of the resource adaptors in the Metaswitch portfolio (such as SMPP, HTTP, MAP, SOAP, and so on).

While the SIS scripting language is very flexible, some service-interaction scenarios may require further customisation. For those situations, the SIS provides very powerful Java-based extension capabilities.

You can use a service-composition selector extension Java component as part of the service-composition selection process. These components can use all capabilities of the Rhino platform (such as any resource adaptor, JDBC, and so on).

A common use case is to query an operator-specific platform, such as a subscriber database, as a part of the service-composition selection process.

The SIS service-composition scripts are very powerful, with features such as conditional branching and the ability to adjust signaling parameters. For maximum flexibility and power, you can use a service composition extension Java component as a part of the execution of a service composition. These components can use all the capabilities of the Rhino platform.

A common use-case is to query to an operator specific platform, such as a subscriber database, and adjust signaling parameters based on the query result.

The service-interaction engine is the core of the SIS, that responds to incoming requests, assigns them to a service composition for processing, and then manages and runs the service composition to completion.

The service-composition selection function evaluates trigger scripts for each new session that reaches the SIS, and determines which service composition should be run. See The SIS Service-Interaction Model for more detail on this process.

The SIS service-interaction engine understands the protocol state machines of a number of protocols. It ensures that the signaling between the SIS and the network, and between the SIS and each triggered service, follows these protocol rules. It also ensures that the results of the services that are triggered will result in appropriate interaction with any other service that is part of the service composition. For example, if a service decides to release a call, the SIS will ensure that the other services that were due to be invoked as a part of the service composition will not be invoked.

The scripting language and the extension capabilities can be used to affect, or override, the protocol rules.

The composition executors are the part of the service interaction engine that runs service compositions. The composition executors run the service-composition scripts, invoke extension Java components, and apply the rules of the protocol state machines. The composition executors also include protocol-specific features for invoking services in external platforms (such as a SIP proxy).