The goal of the new charging architecture for Sentinel SIP is to separate SIP service logic and charging, while supporting as many use cases as possible.
|
Sentinel SIP provides a flexible charging architecture that offers more control over how to apply charging to a session. While this architecture is only available to Sentinel SIP (and by extension Sentinel VOLTE), it will be used in other cores in the future. |
Online charging
Online charging is both the primary and necessarily most feature-rich charging mode in Sentinel. There is support for:
-
session charging with unit reservation (SCUR)
-
event charging with unit reservation (ECUR)
-
immediate event charging (IEC).
The charged units have flexible semantics that can be customised to suit the need. For example, the main unit might be milliseconds for timing an INVITE session; while a secondary unit of CC-Service-Specific-Units might be used to charge a MESSAGE request in that same dialog.
Online charging takes advantage of the charging API to provide complete but extensible behaviour in a range of scenarios. Some examples of supported SIP scenarios are:
-
charged or uncharged announcements
-
event notification and single transactions using IEC or ECUR.
Sentinel SIP supports several standard charging use cases out of the box. You can enable or enhance business through:
-
system-wide and feature-specific configuration
-
scenario-specific configuration, using the Sentinel selection key
-
selection and composition of charging rules using feature scripts (including ChargingManager predicates)
-
extending and adding features and mappers with the SDK, using Sentinel SIP’s simple and flexible Charging Manager.
Offline charging
Offline charging is supported by not running the charging features in the feature scripts, and just recording CDRs.
Components
Charging in Sentinel SIP uses these components:
Features and mappers
Nearly all charging business rules are encapsulated within features and mappers. Furthermore, charging behaviour is mostly decoupled from SIP functionality. The overlap of SIP logic with charging is usually limited to detecting call conditions that affect charging, temporarily suspending messages during a credit check, or ending legs due to charging conditions. That means the core SIP functionality can generally be provided by SIP features without regard to charging, which can be mixed in via charging-specific features.
Charging Mappers are used for a variety of purposes including to map SIP messages to SessionCounterAddresses, SessionCounters to CCRs, and CCAs back to SessionCounters.
Charging Manager
The Charging Manager provides a simple API (backed by the Sentinel mediation layer) for features to issue charging requests. 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.
SIP Session Counters
SIP Session Counters are used to set and track the units sent and received in diameter mediation requests and responses
Service Timer Provider
The Service Timer Provider can be used to set validity time timers, SCUR reauth timers, or timers for any other purpose. It is already used by B2BUAScur for regular reauths; and the mediation layer already times validity and request timeouts for each charging instance.
B2BUAChargingFeatureUtil
The B2BUAChargingFeatureUtil provides a set of static utility methods and algorithms, for example to attribute granted units from a CCA to SessionCounters or to calculate used units. The utility is available in the b2bua-charging-sbb-part SDK module. The SCUR and other system charging features use it. It implements the individual steps in the Counter update algorithm pseudo code, and could be re-used by modified or alternative charging features.
Existing SIP charging features
Many charging-related SIP features come with Sentinel SIP to provide an out-of-the-box comprehensive set of common SIP charging business rules.
B2BUAScur pre and post features
B2BUAScur pre and post features implement the minimum required behaviour for SCUR-based charging of a SIP B2BUA, as well as foundational support for these behaviours for user-defined counters:
-
initialising the default SCUR charging instance and session counter on an initial incoming request
-
performing an initial credit check, suspending outgoing initial requests until a successful response is received
-
updating reservations as needed (based on the timer set from granted SCUR units on each CCA)
-
responding to RARs
-
calculating and setting used units on the SCUR counter with every reservation
-
allocating all (both SCUR and service-specific counters) units granted and sent on every CCA.
SDP comparison
SDP comparison extends basic SCUR charging with additional reauthorisations on every meaningful SDP change. It works like this:
-
Detect meaningful SDP updates and issue a reauthorisation.
-
If the credit check fails, roll back the SDP and reauthorise.
-
If the rollback credit check fails, raise
endSession.
B2BUAEcur pre and post features
The B2BUAEcur pre and post features implement the minimum required behaviour for ECUR-based charging of a SIP B2BUA, as well as foundational support for these behaviours for user-defined counters:
-
initialising the default ECUR charging instance and session counter on an initial incoming event-chargeable request
-
performing an initial credit check, suspending outgoing initial request until a successful response is received
-
calculating and setting used units on the ECUR counter for the reservation and termination
-
allocating all (both ECUR and service-specific counters) units granted and sent on both CCAs.
B2BUAIEC pre and post features
The B2BUAIEC pre and post features implement the minimum required behaviour for IEC-based charging of a SIP B2BUA, as well as foundational support for these behaviours for user-defined counters:
-
initialising the default IEC charging instance and session counter on an initial incoming event-chargeable request
-
performing a direct debit, suspending outgoing initial requests until a successful response is received
-
allocating all units (for both IEC and service-specific counters) granted and sent on both CCAs
-
issuing a refund on service delivery failure.
SipMidCallPlayAnnouncement feature
Though not a charging feature per se, this feature demonstrates that charging can be suspended by any feature at any time and for any purpose.
The announcement properties include a field, SuspendCharging, which indicates to the SipMidCallPlayAnnouncement feature
that it should suspend all charging instances while the call parties are disconnected. The result is that the time period
for the announcement is not charged. Reauths will still be handled by the
B2BUAScur feature, which will also compensate for the suspended time in its calculation of used units.
