MMTelParallelFA

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-flexible-alerting module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-mmtel-flexible-alerting opencloud#mmtel-flexible-alerting#volte/2.9.0;2.9.0.0

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:

MMTelParallelFA statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → MMTelParallelFA
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].feature.MMTelParallelFA"

The data present in JSLEE profile table MMTelDetermineFAConfigProfileTable is used to configure the behaviour of the Parallel Flexible Alerting feature.

The MMTelParallelFA implements the Flexible Alerting in parallel. It reads the MMTelFAServiceData session variable for the group information and issues INVITE requests towards all members in parallel using SIP parallel forking.

The INVITE request URI will have two parameters added to it.

When a member answers the call with 200 (OK) the feature cancels all other sessions towards the other members and finishes the call setup procedures between the calling party and the member that answered.

It also controls the state of the FA Pilot Identity regarding busy, not reachable and no reply states. The determination of those states, depends on the members responses and on the FA group type: single-user or multiple-users. For further information regarding the state of a Pilot Identity see Flexible Alerting.

The OC-Retarget header is added by MMTel Flexible Alerting to communicate that a retarget has occurred. This header is inserted into the initial INVITEs that goes towards the retargeted party. This is then used in the composition to decide whether to invoke the SCC-AS.

For more details see OC-Retarget Header

The CDIV feature runs before the Flexible Alerting feature on INVITE path. This way, the CFNL and CFU conditions can be applied to the Pilot Number before alerting any FA-Group member.

On the Response path, the CDIV feature runs after the Flexible Alerting feature. CDIV applies the conditions CFB, CFNR, and CFNRc based on the final response that the MMTelParallelFA feature sends to the caller. To avoid the CDIV feature being triggered on any final FA-Group members response, the MMTelParallelFA feature suppresses the CDIV feature execution by setting the session state variable SuppressCdiv. MMTelParallelFA will allow the CDIV feature to execute only after the the state of the Pilot Number is defined by receiving all members final responses or by timing out.

CDIV and MMTelParallelFA are both triggered on each other timers. This guarantees that the MMTelParallelFA feature cancels the ongoing downstream dialogs and that the CDIV feature can execute the CFNR and CFNRc conditions properly.

When the CDIV timer fires first, the MMTelParallelFA feature cancels the downstream dialogs and sends a 408 (Timeout) response towards the caller party. When CDIV executes, it will identify the 408 response and do the proper re-targeting towards the diverted subscriber.

When the MMTelParallelFA timer fires first, the MMTelParallelFA feature stops the CDIV timer and cancels the downstream dialogs and sends a 408 (Timeout) response towards the caller party. When CDIV executes, it identifies the trigger is the MMTelParallelFA timer, identifies the 408 response and do the proper re-targeting towards the diverted subscriber.

In the case when no timer has been fired, CDIV feature uses the sip response sent from the MMTelParallelFA feature to evaluate and execute the proper MMTelCDIV conditions.