The SIS has certain default behaviours that it performs when handling messages received from a composition service. Message handling options can be used to alter the default behaviours for specific message types.
How messaged handling options work
Below is an example of how you might use message handling options:
<invoke service="...">
<message-handling-options>
<message-handling-option .../>
<message-handling-option .../>
<message-handling-option .../>
</message-handling-options>
</invoke>
Any number of valid message handling options can be specified for a service or parallel block. The base XML schema for message handling options defines the simplest option, the empty <message-failure-option>
element. This option by itself has no effect on the SIS.
For IN, message handling options specify up to three attributes:
Attribute Name | Required? | Description |
---|---|---|
on-message |
✔ |
A message type. |
action |
✔ |
The action to perform if a message of the given type is encountered. |
is-failure |
✘ |
Relevant only for message types that could be considered a service error or failure. |
For certain actions, a <terminate>
child element may also be included with the <message-handling-option>
element. It specifies a terminate clause that the SIS will use to send a response for the current event.
Open Refuse
This option specifies the behaviour of the SIS when it receives an Open Refuse response from a service. The default behaviour, if this option is undeclared, is equivalent to:
<in:message-handling-option on-message="open-refuse" action="ignore-service-and-continue" is-failure="true"/>
Action | Failure? | Description and example |
---|---|---|
ignore-service-and-continue |
true |
Initial request service failure handling behaviour is first invoked. For external services this may mean a standby external address is contacted. Assuming a local service, no standby, or the standby also refuses the dialog, service failure statistics are recorded, the service is removed from the composition, and composition evaluation continues for the initial request.
|
false |
No initial request service failure handling behaviour is invoked, and no service failure statistics are recorded. The service is simply removed from the composition, and composition evaluation continues for the initial request.
|
|
terminate-processing |
true |
Processing of the initial request is terminated and service failure statistics are recorded. If no
|
false |
Processing of the initial request is terminated. No service failure statistics are recorded. If no
|
User Abort
This option specifies the behaviour of the SIS when it receives a User Abort from a service. The default behaviour, if this option is undeclared, is equivalent to:
<in:message-handling-option on-message="user-abort" action="propagate" is-failure="true"/>
![]() |
If a service receives an Open Request and responds with a User Abort on that dialog before sending any Delimiter, that User Abort will be handled according to the behaviour defined for Open Refuse. |
Action | Failure? | Description and example |
---|---|---|
ignore-service-and-continue |
true |
Service failure handling behaviour is first invoked. For external services this may mean a standby external address is contacted if the initial request is still being processed. Assuming a local service, no standby, the standby also aborts the dialog, or the standby cannot be invoked given the current call state, service failure statistics are recorded, the service is removed from the composition, and processing of any current event continues.
|
false |
No service failure handling behaviour is invoked, and no service failure statistics are recorded. The service is simply removed from the composition, and processing of any current event continues.
|
|
terminate-processing |
true |
Processing of any current event is terminated and service failure statistics are recorded. If no
|
false |
Processing of any current event is terminated. No service failure statistics are recorded. If no
|
|
propagate |
true |
The user abort is propagated towards the network dialog. Handling of the user abort moves to the next outer level in the SIS; for example, a user abort propagated from an
|
false |
The user abort is propagated towards the network dialog. Handling of the user abort moves to the next outer level in the SIS; for example, a user abort propagated from an
|
Interrupted Event Error
This option specifies the behaviour of the SIS when it receives a User Error response from a service for an event delivered to the service in Interrupted mode — that is, an event such as the initial request, that suspends further call state processing until the service provides a suitable response. The default behaviour, if this option is undeclared, is equivalent to:
<in:message-handling-option on-message="interrupted-event-error" action="propagate" is-failure="true"/>
Action | Failure? | Description and Example |
---|---|---|
ignore-service-and-continue |
true |
Service failure handling behaviour is first invoked. For external services this may mean a standby external address is contacted if the initial request is still being processed. Assuming a local service, no standby, the standby also aborts the dialog, or the standby cannot be invoked given the current call state, service failure statistics are recorded, the service is removed from the composition, and processing of any current event continues.
|
false |
No service failure handling behaviour is invoked, and no service failure statistics are recorded. The service is simply removed from the composition, and processing of any current event continues.
|
|
terminate-processing |
true |
Processing of any current event is terminated and service failure statistics are recorded. If no
|
false |
Processing of any current event is terminated. No service failure statistics are recorded. If no
|
|
propagate |
true |
The user error is propagated towards the network dialog. Handling of the user error moves to the next outer level in the SIS; for example, a user error propagated from an
|
false |
The user error is propagated towards the network dialog. Handling of the user error moves to the next outer level in the SIS; for example, a user error propagated from an
|
O-Trigger Connect
This option specifies the behaviour of the SIS when it receives a valid Connect response from a service while executing the originating call state model for the call. The default behaviour, if this option is undeclared, is equivalent to:
<in:message-handling-option on-message="o-trigger-connect" action="continue"/>
The is-failure
attribute cannot be specified for this option.
Action | Description and example |
---|---|
continue |
The Connect updates any appropriate parameters of the event it is a response to, and processing of that event continues to the next service in the composition.
|
propagate |
The Connect is propagated towards the network dialog. Processing of any current event is terminated and no more services will be invoked at the current level in the SIS.
|
propagate-on-destination-change |
This option provides a conditional response depending on the content of the Connect operation sent by the service. If the Connect received by the SIS contains a Destination Routing Address parameter with an address string that is the same as the address string contained in the Called Party Number that was included in the initial request delivered to the service, this option will behave the same as the
|
rebranch |
If processing the initial request, this option behaves the same as the
|
T-Trigger Connect
This option specifies the behaviour of the SIS when it receives a valid Connect response from a service while executing the terminating call state model for the call. The default behaviour, if this option is undeclared, is equivalent to:
<in:message-handling-option on-message="t-trigger-connect" action="propagate-on-destination-change"/>
The is-failure
attribute cannot be specified for this option.
The actions that can be specified for this option are identical in name and behaviour to those defined for o-trigger-connect option.