SIS 3.1.0 :: SIS Overview and Concepts

For compositions in the SIS, you can configure:

fine-grained tracing
call audit logging
extension options
event-processing optimisations (with IN)
managing FCI requests from multiple services (with IN)
managing online charging requests from multiple services (with IN).

Composition debugging

You can assign a fine-grained tracing level to an individual composition in the SIS, to generate extra debugging information for that composition when it is triggered.

To specify the debug level for a composition, use the <debug-level> element. For example:

<composition ...>
    ...
    <debug-level>1</debug-level>
    ...
<composition>

For details on the fine-grained tracing debug levels that the SIS supports, and the output that each level produces, see the SIS Administration Guide.
If a composition does not specify a debug level, the SIS uses the default level of 0.
You can change the debug level for a composition at runtime, after composition installation, using the Composition Management MBean.

Composition auditing

The SIS provides different modes of call audit logging, as described in the SIS Administration Guide. When per-component audit logging is enabled, the SIS includes the audit setting of a triggered composition in its decision whether or not to enable audit logging for each call.

To specify per-component auditing for a composition, use the <audit> element. For example:

<composition ...>
    ...
    <audit>true</audit>
    ...
</composition>

If a composition does not specifically enable auditing, the SIS uses a default value of false. The SIS will still generate an audit log for the composition, however, if the audit level has been set to audit all calls.
You can change the audit setting for a composition at runtime, after composition installation, using the Composition Management MBean.

Extension options

Specifies arbitrary extension options supported by the SIS for the composition. This is a collection of extension-option elements each with a name and optional value. The extension options currently supported for compositions are:

Option	Description	Required Value
IN:proxied-invoke-timer-long	When an operation invoke is sent by an external IN service to the SIS, the timeout period specified for the invoke is not included in the wire protocol message that the SIS receives. When the SIS forwards an operation invoke from an external service to the network, it needs to specify its own invoke timeout period for that operation. The default invoke timeout configured for the SIS or service is adequate for most operations, however operations with "long" timers (Play Announcement, Prompt and Collect User Information) may need longer timeout periods for correct operation. This extension option allows a longer default timeout period to be specified for all services in the composition for these long timer operations.	A long integer value greater than or equal to zero specified in millisecond units.
ECS1:allow-camel-style-apply-charging	The Ericsson INAP CS1 specification states that an Apply Charging request may only be sent by a service if the BCSM is suspended at a detection point. However an operator customisation exists that allows Apply Charging requests to be sent while the BCSM is in any valid state, the same as in CAMEL protocols. This extension option allows the CAMEL behaviour for Apply Charging to be supported for Ericsson INAP protocol dialogs (both CS1 and CS1+).
ECS1p:allow-busy-after-alerting	The Ericsson INAP CS1+ specification states that the BCSM event detection point (EDP) indicating the caller is busy is implicitly disarmed if the EDP for alerting is encountered. However some mobile networks use the busy EDP to report a user call rejection, which naturally occurs after the alerting phase of the call has begun. This extension option allows this case to be supported without a service having to explicitly rearm the busy EDP. It suppresses the implicit disarm of the busy EDP in the SIS when the alerting EDP is reported from the MSC. WARNING: This option is only meaningful if the MSC applies the same rules to the BCSM.	n/a
NCS1:enable-implicit-disarming	By default, the implicit disarming of EDP events is disabled in the SIS for calls received on Nokia INAP CS1 dialogs. This extension option allows the implicit EDP disarming rules to be enabled for Nokia INAP CS1. WARNING: This option is only meaningful if the MSC applies the same rules to the BCSM.	n/a

Option

Description

Required Value

 IN:proxied-invoke-timer-long

When an operation invoke is sent by an external IN service to the SIS, the timeout period specified for the invoke is not included in the wire protocol message that the SIS receives. When the SIS forwards an operation invoke from an external service to the network, it needs to specify its own invoke timeout period for that operation. The default invoke timeout configured for the SIS or service is adequate for most operations, however operations with "long" timers (Play Announcement, Prompt and Collect User Information) may need longer timeout periods for correct operation. This extension option allows a longer default timeout period to be specified for all services in the composition for these long timer operations.

A long integer value greater than or equal to zero specified in millisecond units.

 ECS1:allow-camel-style-apply-charging

The Ericsson INAP CS1 specification states that an Apply Charging request may only be sent by a service if the BCSM is suspended at a detection point. However an operator customisation exists that allows Apply Charging requests to be sent while the BCSM is in any valid state, the same as in CAMEL protocols. This extension option allows the CAMEL behaviour for Apply Charging to be supported for Ericsson INAP protocol dialogs (both CS1 and CS1+).

 ECS1p:allow-busy-after-alerting

The Ericsson INAP CS1+ specification states that the BCSM event detection point (EDP) indicating the caller is busy is implicitly disarmed if the EDP for alerting is encountered. However some mobile networks use the busy EDP to report a user call rejection, which naturally occurs after the alerting phase of the call has begun. This extension option allows this case to be supported without a service having to explicitly rearm the busy EDP. It suppresses the implicit disarm of the busy EDP in the SIS when the alerting EDP is reported from the MSC. WARNING: This option is only meaningful if the MSC applies the same rules to the BCSM.

n/a

 NCS1:enable-implicit-disarming

By default, the implicit disarming of EDP events is disabled in the SIS for calls received on Nokia INAP CS1 dialogs. This extension option allows the implicit EDP disarming rules to be enabled for Nokia INAP CS1. WARNING: This option is only meaningful if the MSC applies the same rules to the BCSM.

n/a

Event processing optimisations

With IN, the SIS supports optional optimisations that can reduce the overall event processing latency in some cases when using local services.

To specify the optimisations setting in a composition, use the <optimisations-enabled> element. For example:

<composition ...>
    ...
    <in:optimisations-enabled>true</in:optimisations-enabled>
    ...
</composition>

Optimisations are typically safe to enable, but should not be used where the local services in a composition share information using transactional state in the SLEE (such as public activity context interface attributes or the activity context naming facility).
If a composition does not specifically enable optimisations, they are disabled by default.
You can change the optimisations setting for a composition at runtime, after composition installation, using the Composition Management MBean.

Managing FCI requests from multiple services

IN protocols allow services to send charging-related messages to the network. With IN, a composition can specify how the SIS should manage Furnish Charging Information (FCI) requests sent by multiple services in the same composition. The following interaction modes are available:

static-service-priorities — Each service in the composition is assigned a static charging priority, using the Service Reference Management MBean. If multiple services send FCI requests while the call state model is suspended, the FCI request sent by the highest priority service "wins" — the SIS sends that FCI request to the network and discards other FCI requests (sent by lower priority services).
concatenation — In this mode, the SIS appends the charging characteristics data, that each service sends in an FCI request, to a buffer. The SIS determines the buffer’s size by the maximum data size the FCI request permits for the protocol in use. The SIS can only append charging data while space in the buffer remains. The SIS discards an FCI request if the buffer cannot fit the data it contains. The SIS also appends the charging delimiter specified in the SIS configuration, between each set of charging-characteristics data. The final charging-characteristics data included in the FCI request the SIS sends to the network looks like this:
```
<fci#1-data> <delim> <fci#2-data> <delim> ... <fci#n-data>
```
nominated-service — The SIS only sends FCI requests to the network if from the nominated service, as indicated by the associated service reference. The SIS rejects FCI requests sent by any other composition service.
pass-through — FCI requests from all services are passed through to the network. No filtering or manipulation of the FCI content is performed by the SIS.

The SIS applies FCI handling anew each time the call state model is suspended at a detection point. While the call state model is suspended, the SIS handles any FCI requests it receives from composition services according to the composition’s FCI interaction mode rules. The SIS determines what FCI request to send to the network when the call state model resumes. As CAPv2 FCI requests include a leg type that identifies which party to charge, the SIS treats FCIs it receives for different call legs separately. In other words, an FCI for the calling party leg will only interact with other FCIs for the same leg. If the SIS receives FCIs for both the calling party and called party legs during processing of a particular initial request, it sends the two FCIs to the network when the call state model resumes.

To specify the FCI interaction mode setting is specified in a composition, use the <fci-interaction> element. For example:

<composition ...>
    ...
    <in:fci-interaction mode="concatenation"/>
    ...
</composition>

If a composition does not specify an FCI interaction mode, the SIS uses a default mode of static-service-priorities for that composition.
You can change the FCI interaction mode setting for a composition at runtime, after composition installation, using the Composition Management MBean.

Managing online charging requests from multiple services

IN protocols allow services to send charging-related messages to the network. With IN, a composition can specify how the SIS should manage the Apply Charging, Send Charging Information, and Call Information Request online-charging requests sent by multiple services in the same composition.

The following interaction modes are available:

static-service-priorities — Each service in the composition is assigned a static charging priority, using the Service Reference Management MBean. If multiple services send any online charging requests while the call state model is suspended, the charging requests sent by the highest priority service "wins" — the SIS sends those charging requests to the network and discards all other online charging requests (sent by lower priority services). If the call state model is not suspended, and the SIS has not yet selected a service for which to send online charging requests to the network, it sends the first service’s online charging requests it receives and discards any subsequent online charging requests from other services (even if they come from a service with a higher priority than the selected service).
nominated-service — the SIS only sends online charging requests to the network if from the nominated service, as indicated by the associated service reference. The SIS rejects online charging requests sent by any other service.

To specify the online charging interaction mode setting in a composition, use the <online-charging-interaction> element. For example:

<composition ...>
    ...
    <in:online-charging-interaction mode="nominated-service" service="HomeZone"/>
    ...
</composition>

You cannot use this mode to manage FurnishChargingInformation (FCI) requests — instead, manage them separately using the FCI Interaction configuration option.
If a composition does not specify an online charging interaction mode, the SIS uses a default mode of static-service-priorities for that composition.
You can change the online charging interaction mode setting for a composition at runtime, after composition installation, using the Composition Management MBean.

Previous page Next page