Description

Feature script name

B2BUAIECPreFeature, B2BUAIECPostFeature

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

The B2BUA IEC pre and post features cover event charging using a charge/refund model. The features are responsible for:

  • creating the reservation charging instance (B2BUAChargingFeatureUtil.DEFAULT_IEC_CHARGING_INSTANCE) and default session counter on an initial SUBSCRIBE, MESSAGE, OPTIONS, or PUBLISH request

  • instructing the charging manager to send a direct debit to the OCS

  • detection of message nondelivery conditions and refunding as necessary

The general use case is that a chargeable message — a SUBSCRIBE, MESSAGE, OPTIONS, or PUBLISH — will be B2BUA’d through Sentinel. The IEC post feature will trigger a direct debit, then allow delivery of the message. If a response to the B2BUA’d message is received which indicates non-delivery, the amount debited will be refunded.

For a high level overview of Sentinel charging see Sentinel SIP Charging Architecture

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 or 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 All of Sentinel for SIP’s charging features make use of Sentinel’s comprehensive charging API — see Using the SIP Charging Manager

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 IEC 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

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

  • updates made to all counters on the charging instance, mainly limited to updates from CCAs.

  • complete implementation of event based charging on the default counter.

Interaction with the default charging instance

Initialisation

When the pre-feature is first triggered on an incoming event request, it creates the default IEC charging instance, under the name B2BUAChargingFeatureUtil.B2BUA_IEC_CHARGING_INSTANCE. It then maps the initial event request to a session counter address written to the session state field B2BUAChargingCounterAddress. This is the default session counter on which all IEC based charging is performed.

Initial debit

On any trigger other than an incoming chargeable event request, both features check whether the B2BUAChargingFeatureUtil.DEFAULT_IEC_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 IEC is not enabled.

The pre feature will instruct the charging instance to send a direct debit message to the OCS.

The post feature will set the pending requested units and suspend the called party leg until the OCS authorises the call.

Refund

If the feature is triggered on a non-success response to a chargeable event, the pre feature will instruct the charging instance to refund the amount that was initially debited.

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. The pre 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 IEC session counter is fully managed by the IEC 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 post feature is triggered on a chargable event, the pending requested units will be set to the value of RequestUnitsServiceSpecific in session state, unless they have already been set to a non-zero value. If the pending requested units value is non-zero, it will not be overwritten.

Mappers

This feature uses two mappers:

  • The first converts the initial SIP request to a 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 4.1