The MMTelWifiChargingFinalisation feature handles the finalisation of charging when a call is answered over WiFi.
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 |
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/4.0.0;4.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 |
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 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:
-
Set the session output variable called
MonitorCallOnly
totrue
. -
Find all charging instances associated with the session.
-
For each charging instance it finds it will:
-
Determine if it is a reservation charging instance.
-
Check that the instance has not already been finalised.
-
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 isRO
(online) orDEFAULT
(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.