Details

Feature script name

B2BUAEcurpre-feature, B2BUAEcurpost-feature

Applicable contexts

SIP service

SAS Support

Yes

Prerequisite features

B2BUA

Feature execution points
Pre

SipAccess_ChargingReauth SipAccess_CreditAllocatedPostCC SipAccess_CreditLimitReachedPostCC SipAccess_ControlNotRequiredPostCC SipAccess_OCSFailurePostCC SipMidSession_CreditAllocatedPostCC SipMidSession_CreditLimitReachedPostCC SipMidSession_OCSFailurePostCC SipMidSession_ChargingReauth SubscriptionSubscriberCheck SubscriptionSipRequest SubscriptionSipResponse CreditFinalised SipTransaction_Response SipTransaction_SubscriberCheck

Post

SipAccess_ChargingReauth SipAccess_CreditAllocatedPostCC SipAccess_CreditLimitReachedPostCC SipAccess_ControlNotRequiredPostCC SipAccess_OCSFailurePostCC SipAccess_PartyResponse SipMidSession_CreditAllocatedPostCC SipMidSession_CreditLimitReachedPostCC SipMidSession_OCSFailurePostCC SipMidSession_ChargingReauth SubscriptionSubscriberCheck SubscriptionSipRequest SubscriptionSipResponse SipLegEnd SipTransaction_Response SipTransaction_SubscriberCheck

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).

Note

  • During any credit check, Sentinel automatically ensures all incoming messages are queued in the SLEE until the CCA (or a timeout) is received; in other words, no further network events will be delivered to Sentinel and processed until the credit check is complete.

  • Currently, Sentinel for SIP only supports one charging instance per Sentinel session, though this instance may have multiple session counters.
Tip

Session state inputs and outputs

Inputs

Name Format Description Behaviour if null/invalid

SentinelSelectionKey
com.opencloud.sentinel.common.SentinelSelectionKey

Selection key
(for example, <platform_operator>::::)

For selecting mappers

Increment InputParameterErrors Common cleanup actions

CurrentSipFeatureExecutionPoint
com.opencloud.sentinel.feature.spi.SipFeatureScriptExecutionPoint

Enum value

Used to classify the triggering event

N/A

B2BUAChargingCounterAddress
com.opencloud.sentinel.charging.sessioncounters.SessionCounterAddress

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
org.jainslee.resources.diameter.ro.types.vcb0.CreditControlAnswer

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
java.lang.Long

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
com.opencloud.sentinel.charging.sessioncounters.SessionCounterAddress

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_INSTANCE itself

  • 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.

Finalisation

Any feature can issue credit finalisation, however if the post-feature detects zero remaining legs or it receives an AbortSessionRequest, it issues credit finalisation itself.

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.

Setting pending requested units on the default counter

When the pre-feature is triggered on a chargable event, the pending requested units will be set to the value of RequestUnitsServiceSpecific in session state.

Setting reported used units on the default counter

When the pre-feature is triggered on the response to a chargable event, the reported used units will be set to the value of RequestUnitsServiceSpecific in session state.

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);

Feature responses

Response Reason

featureHasFinished

feature has finished
Previous page Next page
Sentinel Express Version 3.1.0