The B2BUA ECUR charging features define event charging with unit reservation behaviour for Sentinel SIP as a B2BUA.
Details
Feature script name |
B2BUAEcurpre-feature, B2BUAEcurpost-feature |
|---|---|
Applicable contexts |
SIP service |
SAS Support |
Yes |
Prerequisite features |
B2BUA |
Feature execution points |
|
Pre- and post-features
The B2BUA ECUR pre- and post-features cover event charging using a reserve/confirm model. The features are responsible for:
-
creating the reservation charging instance (
B2BUAChargingFeatureUtil.DEFAULT_ECUR_CHARGING_INSTANCE) and default session counter on an initial SUBSCRIBE, MESSAGE, OPTIONS, or PUBLISH request -
performing the initial credit check
-
detection of message delivery or nondelivery conditions and credit finalisation.
The general use case is that a message will be B2BUA’d through Sentinel. The ECUR pre-feature will request a credit check, then allow delivery of the message. When a response to the B2BUA’d message is received, the credit reservation will be confirmed (or refunded).
|
|
|
|
Session state inputs and outputs
Inputs
| Name | Format | Description | Behaviour if null/invalid |
|---|---|---|---|
SentinelSelectionKey |
Selection key |
For selecting mappers |
Increment InputParameterErrors Common cleanup actions |
CurrentSipFeatureExecutionPoint |
Enum value |
Used to classify the triggering event |
N/A |
B2BUAChargingCounterAddress |
Key/value pairs identifying the session charged service |
Determines which counter the feature will update with charging data (the ECUR features only treat one counter as the session charging counter at a time). Also see Outputs. |
No-op unless initial request |
LatestOcsAnswer |
Last received CCA |
Passed through to a charging mapper to generate the session counter values |
Exception thrown, if the feature is expecting a response from the OCS. Otherwise ignored. |
RequestUnitsServiceSpecific |
Non-negative long |
The number of pending requested units, or the number of reported used units, depending on state. |
N/A |
Outputs
| Name | Format | Description |
|---|---|---|
B2BUAChargingCounterAddress |
Key/value pairs identifying the session charged service |
Mapped from initial incoming chargeable event request in SIP-initiated sessions to determine the default session counter against which the units will be charged. |
Charging API interactions
The charging API interactions fall under the following categories:
-
charging instructions issued on the
B2BUAChargingFeatureUtil.DEFAULT_ECUR_CHARGING_INSTANCEitself -
updates made to all counters on the charging instance, mainly limited to updates from CCAs and credit finalisation
-
complete implementation of event based charging on the default counter.
Interaction with the default charging instance
Interaction with the default charging instance includes bxref#:initialisation[initialisation], bxref#initial-and-update-credit-checks[checks for initialisation and updates], and bxref#:finalisation[finalisation].
Initialisation
When the pre-feature is first triggered on an incoming event request, it creates the default ECUR charging instance, under the name B2BUAChargingFeatureUtil.B2BUA_ECUR_CHARGING_INSTANCE. It then maps the initial request to a session counter address written to the session state field B2BUAChargingCounterAddress. This is the default session counter on which all ECUR based charging is performed.
Initial and update credit checks
On any trigger other than an incoming chargeable event request, both features check whether the B2BUAChargingFeatureUtil.DEFAULT_ECUR_CHARGING_INSTANCE has been initialised. The first step is to check the instance exists in the ChargingManager, then that the instance has a session counter with the address specified in session state B2BUAChargingCounterAddress. If either check fails, the feature ends immediately on the assumption that ECUR is not enabled.
The pre-feature will issue a credit reservation for an incoming chargeable event request. The called party leg is suspended until the OCS authorises the call.
Interaction with all session counters
When a CCA is received, all counters on the ChargingInstance will be processed according to the algorithm outlined in Counter Update Algorithm Pseudo Code.
If a credit finalisation is raised, the post-feature will clear the pending requested units on all session counters.
When charging using a non-default counter, another feature will need to set reported used and pending requested units on the counters as needed.
Interaction with the default session counter
The default ECUR session counter is fully managed by the ECUR pre- and post-features. Generally speaking, user features need not interact directly with this counter.
Mappers
This feature uses two mappers:
-
The first converts the initial SIP request to SessionCounterAddress.
The default implementation is SipRequestToSessionCounterAddress:// a mapper that takes a {{SipRequest}} and generates a {{SessionCounterAddress}}. final Mapper<SentinelSipSessionState> mapper = getMapperLibrary().findMapper( getSessionState().getSentinelSelectionKey(), SipRequest.class, SessionCounterAddress.class, mappingPoint); -
The second mapper converts a CCA into a list of session counters.
The default implementation is CCAtoSessionCounterList:// a mapper that takes a {{CreditControlAnswer}} and generates a {{List<SessionCounter>}}. final Mapper<SentinelSipSessionState> mapper = getMapperLibrary().findMapper( getSessionState().getSentinelSelectionKey(), CreditControlAnswer.class, List.class mappingPoint);
