The Determine Cause Code feature is responsible for determining an appropriate value for the Cause-Code AVP in the IMS-Information AVP used in Diameter charging. It does this by monitoring an ongoing dialog looking for any event that could bring the dialog to an end. It selects an appropriate code based on what kind of dialog ending event it finds.

Details

Feature script name

DetermineCauseCode

Applicable contexts

SIP service

SAS Support

No

Prerequisite features

N/A

Feature execution points

All

Timer usage

N/A

Source Code

This feature’s source code is available in the Sentinel SDK in the sentinel-sip-service-information-modules module pack. It can be viewed by using the create-module command in the SDK with that module pack. This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules relevant to this feature:

Module Name Description

sentinel-sip-service-information-modules

Group module for all service information features, including the modules listed below.

sentinel-sip-service-information-session-state-library

Contains the session state interface for the feature.

sentinel-sip-determine-cause-code-feature

Contains the feature itself.

Session state inputs and outputs

Inputs

Name Type Purpose

CurrentSipFeatureExecutionPoint

Enum

Used to classify a dialog’s type and status.

EndSessionCause

Integer

Used to detect end-of-dialog triggered by an explicit call to the session ender.

Outputs

Name Type Description

DiameterCauseCode

Integer

The value to be used in the Cause-Code AVP

Feature responses

Response Reason

featureHasFinished

feature has finished

Statistics

This feature does not provide any usage statistics.

Behaviour

The DetermineCauseCode feature detects and classifies conditions that would bring about the end of a dialog. The feature runs at the end of every execution point to allow it detect any end of dialog cause. When it executes, the feature will start by determining the type of dialog based on what SIP Request method was used to initiate the dialog. From there, the feature will look for all possible conditions that could bring the dialog to an end. Finally, if the dialog is determined to be ending, a cause code value will be selected based on what condition triggered it and that value will be set in the DiameterCauseCode session state field.

This table summarises the possible cause code values, details of how they are determined follow on below.

Code Meaning

-3xx

Dialog was terminated with a SIP 3xx response. The actual value of the code will match the response status.

-2xx

Dialog was terminated with a SIP 2xx response. The actual value of the code will match the response status.

-2

Subscription dialog ended normally.

-1

Transaction dialog ended normally.

0

Invite session ended normally.

2

Invite session setup failed.

3

There was an internal error in Sentinel and no other code can be determined.

4xx

Dialog was terminated with a SIP 4xx response. The actual value of the code will match the response status.

5xx

Dialog was terminated with a SIP 5xx response. The actual value of the code will match the response status.

6xx

Dialog was terminated with a SIP 6xx response. The actual value of the code will match the response status.

Dialog Classification

The feature classifies the dialog into one of three categories: subscriptions, transactions, and invite sessions. It does this classification by examining the initial execution point that the feature was triggered on, which corresponds to the method of the SIP request the initiated the SIP dialog, as follows:

Execution Point Type Initial Request Method

SipAccess_SessionAccept

Invite Session

INVITE

SipThirdPartyAccess_SessionAccept

Invite Session

INVITE (Triggered by an HTTP GET)

SubscriptionAccept

Subscription

SUBSCRIBE or REFER

SipTransaction_Accept

Transaction

MESSAGE, PUBLISH, OR OPTIONS

Note that the feature does not support REGISTER dialogs.

End of Dialog Detection

The procedures for detecting an ending dialog depends on the dialog type. The detailed procedures for each dialog type are laid out below. Note that a cause code value of 3 will occur any time an internal error prevents the feature from determining a more accurate code.

Transaction Dialogs

When evaluating a transaction dialog, the feature will proceed through the following checks until one results in a cause code value being found and stored in the DiameterCauseCode session state field. If none of the checks produce a cause code then the dialog is considered to be still in progress and session state will not be modified.

  1. Check if the session ender was explicitly invoked to terminate the dialog. If this is the case, then the cause code will match the SIP response status code that was provided to the session ender.

  2. Check if the calling leg has already been released by the leg manager. If this has happened, one of two things can happen:

    1. If a cause code had previously been determined in an earlier run of the feature, that code will be preserved.

    2. If no cause code has been determined, then -1 (Successful transaction) will be used.

  3. Check for a pending final response queued to be sent on the calling leg, if one is found a code will be selected as follows:

    1. If the response status is 200 OK then a code of -1 (Successful transaction) will be used.

    2. For any other final response, the response status will be used.

Subscription Dialogs

When evaluating a subscription dialog, the feature will proceed through the following checks until one results in a cause code value being found and stored in the DiameterCauseCode session state field. If none of the checks produce a cause code then the dialog is considered to be still in progress and session state will not be modified.

  1. Check if the session ender was explicitly invoked to terminate the dialog. If this is the case, then the cause code will match the SIP response status code that was provided to the session ender.

  2. Check if the calling leg has already been released by the leg manager. If this has happened, one of two things can happen:

    1. If a cause code had previously been determined in an earlier run of the feature, that code will be preserved.

    2. If no cause code has been determined, then -2 (End of subscribe dialog) will be used.

  3. Check if the most recently received SUBSCRIBE request has a Expires header with the value 0. If this is the case, then -2 (End of subscribe dialog) will be used.

  4. Check for a final response the most recent SUBSCRIBE request (regardless of whether it has been sent or is queued) that has a status that is greater than or equal to 300. If one is found then the response status will be used as the cause code.

Invite Sessions

For invite sessions, the feature does an additional classification to determine what state the session is in: setup, mid-session, or ending. This classification is made based on the current execution point, and on whether an ACK for the initial INVITE/200 transaction has been sent or received by Sentinel.

For sessions in the setup phase, the feature will proceed through the following checks until one results in a cause code value being found and stored in the DiameterCauseCode session state field. If none of the checks produce a cause code then the dialog is considered to be still in progress and session state will not be modified.

  1. Check if the session ender was explicitly invoked to terminate the dialog. If this is the case, then the cause code will match the SIP response status code that was provided to the session ender.

  2. Check if the calling leg has already been released by the leg manager. If this has happened, one of two things can happen:

    1. If a cause code had previously been determined in an earlier run of the feature, that code will be preserved.

    2. If no cause code has been determined, then 2 (Unsuccessful session setup) will be used.

  3. Check if a SIP BYE request has been sent or received, or is queued to be sent on the calling party leg. If this is the case, then 2 (Unsuccessful session setup) will be used.

  4. Check for a final response to the initial INVITE request (regardless of whether it has been sent or is queued) that has a status that is greater than or equal to 300. If one is found then the response status will be used as the cause code.

For sessions in the mid-session phase, the DiameterCauseCode session state field will be immediately set to 0 (Normal end of session) as this is guaranteed from this point.

For session in the ending phase will check if a cause code has been determined in an earlier run of the feature. If one has been, nothing will change. If there is no cause code, then 0 (Normal end of session) will be set in the DiameterCauseCode session state field.

Previous page Next page
Sentinel Express Version 4.1