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>
Note

  • 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>
Note

  • 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:accept-non-continuing-close

Typically, if the SIS is expecting a response from an IN service and that service just closes the dialog to the SIS without first providing a response, the SIS will regard this as an error condition. However if this extension option is specified, the SIS will instead behave as if the service provided a Continue response before the dialog was closed.

n/a

 
 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+).

n/a

 
 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

 
 SIP:traffic-reduce

This option can be used if you want to invoke a SIP service, but want to reduce the amount of SIP traffic to that service by only passing it the initial request, then excluding it from the call.

When this option is present, the SIS invokes the service by sending it the initial request. When the service forwards the request, the SIS sends an error response (default: 500) to the service so that it will no longer take part in the call. The request forwarded by the service continues with the remainder of the composition. Responses to the initial request and subsequent requests in the call will not be passed to the service.

The extension-option element may include a <reject> element as seen in terminate clauses for SIP. If present, the status code, reason phrase and headers in the <reject> element will be included in the error response passed to the service. For example, to generate a custom 599 response:

<invoke service="MyService">
  <extension-options>
    <extension-option name="SIP:traffic-reduce">
      <sip:reject status-code="599" reason-phrase="Traffic Reduce">
        <sip:header name="Reason" value="SIP;cause=599;text=&quot;Traffic Reduce&quot;"/>
      </sip:reject>
    </extension-option>
  </extension-options>
</invoke>

n/a

 
 SIP:keep-external-address-params

This option only applies when invoking external SIP services.

When the SIS invokes an external service, its default behaviour is to copy all header and URI parameters from the incoming initial request’s Route header into the Route header of the outgoing request. This is so that context from upstream servers, often added to the Route header, is propagated to the external service.

If the external platform’s configured address (a SIP URI) contains URI parameters with the same names, these will be replaced by the incoming request’s parameters in the outgoing Route URI.

If this option is present, then the URI parameters of the configured external service address have priority, and will be used in the outgoing request’s Route header.

To use this option it just needs to be present in the <invoke> element as shown:

<invoke service="ExternalService">
  <extension-options>
    <extension-option name="SIP:keep-external-address-params"/>
  </extension-options>
</invoke>

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>
Note

  • 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>
Note

  • 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>
Note

  • 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