Below are details of the role the SIS plays in the network and a high level and more detailed view of the SIS internal architecture.
Role of the SIS in the network architecture
Current networks can be seen as having two layers:
-
The control layer, which includes signaling elements, such as service switching points (SSP) in SS7 networks and CSCF in IMS networks
-
The services layer, which includes signaling control elements triggered by the network on behalf of subscribers, such as service control points (SCP) in SS7 networks and SIP Application Servers in IMS networks.
![SIS layers](../images/about-the-sis/SIS-layers.png)
The Metaswitch SIS interposes a service-interaction layer between the service and control layers. The Metaswitch SIS controls the sequence of services that it invokes, managing and coordinating the interaction between each service. The output from a service may influence the choice of which service the SIS invokes next.
From the perspective of:
-
the control layer — the SIS looks like one service that is interacting with the network
-
each service — the SIS looks like the control layer
-
the service interaction layer — multiple services are being triggered on one session.
![]() |
Services may be in external network elements such as an SCP or SIP AS, or be deployed with the Metaswitch SIS (as a JAIN SLEE service). |
High level SIS architecture
Below is a diagram followed by descriptions of the SIS subsystems.
![sis arch option 4a](../images/about-the-sis/sis-arch-option-4a.png)
Scripting |
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). |
---|---|
Service-interaction engine |
The service-interaction engine is responsible for:
|
Services |
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. |
Management |
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. |
SIS internal architecture in more detail
Below is a diagram followed by descriptions of the SIS internal architecture in more detail.
![sis arch option 5](../images/about-the-sis/sis-arch-option-5.png)
SIS management |
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. |
||
---|---|---|---|
SIS monitoring |
To support the critical need to monitor SIS behaviour in real time, administrators can:
|
||
Rhino SLEE |
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).
|
||
Service-interaction customisation |
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. Service-composition selection Java API
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. Service-composition extension Java API
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.
|
||
Service-interaction engine |
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. Service composition selection
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. Protocol state machines
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. Composition executors
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).
|