What is MMTel WiFi Charging Finalisation?

MMTelWifiChargingFinalisation interacts with the T-ADS features in the Sentinel VoLTE SCC AS. It looks for a header that those features attach to responses to the initial INVITE in order to determine if a call has been answered over a WiFi network. If that is the case, it finalises charging.

Feature cheat sheet

B2BUA Instance SAS Support Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

No

Originating and Terminating

 
SipAccess_PartyResponse

No

No

Stateless

POJO

Prerequisite Features

These features must run before MMTelWifiChargingFinalisation:

Source Code

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

> create-module new-wcf-module opencloud#mmtel-wifi-charging-finalisation#volte/3.0.0;3.0.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 a single module:

Module Name Description

mmtel-wifi-charging-finalisation

Contains all of the code for this feature.

Session Input Variables

Attribute Type Comments 
CallType

CallType (enum)

Set by the DetermineCallType feature

 
ChargeMode

ChargeMode (enum)

Set by the DetermineChargeMode feature

Session Output Variables

Attribute Type Comments 
MonitorCallOnly

boolean

The feature will set this to true when it finalises charging.

 
TerminatingDomain

String

The feature will set this to the value of OC-Terminating-Domain header of any 200 response to the original INVITE

Statistics

MMTelWifiChargingFinalisation statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set:
SLEE-Usage → [sentinel.volte.sip service name] → [sentinel.volte.sip SBB name] → feature.MMTelWifiChargingFinalisation

Statistic Increments when…​ 
Started

The feature is started.

 
OCTerminatingDomainHeaderStripped

An OC-Terminating-Domain header is found on an outgoing message and removed.

 
ChargingInstanceFinalised

A non-finalised reservation charging instance is found and finalised.

 
Received2xxForOriginalInvite

A SIP 2xx response for the initial INVITE is received by the feature.

 
TerminatingDomainIsWifi

The feature determines that terminating access is over WiFi.

 
FailedToStart

Sentinel VoLTE encounters an error while attempting to start the feature.

 
IssuedWarning

A non-fatal problem is encountered and the feature and issues a warning.

 
FailedDuringExecution

A fatal problem is encountered and the feature cannot execute correctly.

 
TimedOut

The feature takes too long to complete and Sentinel VoLTE aborts execution.

Behaviour

MMTelWifiChargingFinalisation has simple behaviour and always executes in the same way.

Basic Checks

After being triggered the feature undertakes some basic checks to ensure it should be running, they are:

  • Ensure that a Call Type has been set in session state (i.e. the DetermineCallType feature has run)

  • Ensure that a Charge Mode has been set in session state (i.e. the DetermineChargeMode feature has run)

  • Ensure that the feature was triggered on an incoming SIP response message.

If any of these conditions is not met, the feature immediately terminates execution an raises an error. If they are both met, the feature will continue as described below.

Classifying the Session Status and Response

Once confirming that it is running under the correct conditions, the feature checks the session state and the incoming response to determine if a decision about charging should be made. The requirements for making a decision are:

  • The Call Type is MobileTerminating

  • The Charge Mode is RO (Online charging)

  • The response has a 200 OK status.

  • The response has been sent in reply to the initial INVITE for the call.

If these requirements are all met, the feature will check the response to determine if charging should be finalised. If any are not met, the feature will skip to checking if it needs to strip the OC-Terminating-Domain from the outgoing response.

Handling Charging Status

If the feature has confirmed that the incoming response is a 200 OK for the initial INVITE, it will look for the OC-Terminating-Domain header on the response. If the header is present and has the value PS=WLAN (which indicates the call has been routed to the terminating user over a WiFi network) the feature will finalise charging for the terminating leg of the call.

If it is present, the value of the OC-Terminating-Domain header (regardless of it is) will be stored in the TerminatingDomain session output variable.

If the header is not present or has a value not equal to PS=WLAN, charging for the call will not be affected.

Finalising Charging

If the feature has determined that it is necessary to finalise charging, it will carry out the following procedure:

  1. Set the session output variable called MonitorCallOnly to true.

  2. Find all charging instances associated with the session.

  3. For each charging instance it finds it will:

    1. Determine if it is a reservation charging instance.

    2. Check that the instance has not already been finalised.

    3. If both of those conditions are true, the feature will instruct the instance to undertake charging finalisation.

Stripping the OC-Terminating-Domain Header

Under certain conditions, the feature will strip the OC-Terminating-Domain header from any outgoing messages before finishing execution. These conditions are met when either one of the following is true:

  • The Call Type is MobileOriginating

  • The Call Type is MobileTerminating, and the Charge Mode is RO (online) or DEFAULT (which is treated as online)

If the conditions are met, the feature will strip the header by accessing the outgoing message queue for the leg linked to the leg the response was received on. For every message found in the queue, the feature will check if the header is present and if so, remove it.

If the response was received on a leg that is not linked to another leg, or neither of the above conditions were met, the feature will not attempt to strip the header.

Previous page Next page
Sentinel VoLTE Version 3.0.0