For SIP and IN, the SIS lets you define complex interactions between services, by applying a composition to each call attempt that it processes.
|A composition is a pre-tested sequence of services or features that produce added value to a subscriber.|
The SIS intelligently manages the interactions between each service and the network dialog.
Below is a high-level view of the SIS finite state machine (FSM), followed by descriptions of its three states.
Service Composition Discovery is the state the SIS FSM enters upon receipt of an initial event. The SIS applies trigger rules that analyse and examine the parameters of the initial event, to select a service composition to run.
If the SIS finds a composition, the SIS FSM transitions to the Monitoring and Event Delivery state. If not, the SIS:
sends a configurable "trigger failure" response to the network
terminates the network dialog
returns the SIS FSM to the Inactive state.
The Monitoring and Event Delivery state is divided into the following three substates:
Event Delivery is the state the SIS FSM enters whenever one or more events are available for potential delivery to one or more services. Typically, the network generates events, but the SIS may also synthesise them as a result of a particular service’s interaction with the network dialog.
Events are delivered to the services in a composition in the forward or reverse direction — forward from events associated with the call’s originating party, reverse from events associated with the call’s terminating party. If an event is not associated with either the originating or terminating party, delivery is by default in the forward direction.
Each service may have one of three dispositions towards the receipt of each event:
Transparent— The service does not care about the event (will not receive notification).
Notify & Continue— The service wants to know but not do anything about the event (will receive notification, but not respond with any specific call-processing functions).
Interrupted— The service wants to know about and respond to the event before it goes to another service (will receive notification and may perform some call-processing functions). In this case, the SIS waits for the service to generate a response to the event before continuing with delivery of the event to any other service.
The SIS determines the disposition of a service by considering whether it can receive the event (the event-handler methods defined by the service), and whether it has asked to receive such events in the past (for example, for an IN
EventReportBCSM indication event, whether the service has requested interest in its BCSM event type).
The SIS fires an event to the service if the event disposition is not
Transparent. If the event disposition was
Interrupted, the SIS FSM enters the Waiting for Instructions state.
After all events have been delivered by the SIS to the services in the service composition (according to the service dispositions) and the SIS has received all required responses from the services (according to the service dispositions), the SIS sends any required response to the network. If the network dialog remains open after this time, the SIS FSM transitions to the Monitoring state. Otherwise, it transitions to the Inactive state.
Waiting for Instructions is the state when the SIS has delivered one or more events to a service with Interrupted event disposition, and it’s waiting for that service to return a response. There are two exit paths from this state: the SIS either receives a response from the service appropriate for the event, or times out.
With a response, the SIS determines whether to continue delivering the event to any remaining services, or abort delivery and send an immediate response to the network. For example, if a service releases the call, the SIS will abort delivery and send the appropriate message to the network. With a timeout, the SIS excludes the non-responding service from further interaction with the network dialog and continues delivering the events to any remaining services.