Understanding default balance creation, Blocker flag behavior, and 1-second call overage

[M B]

Hi all,

We've been running CGRateS with OpenSIPS for prepaid billing and encountered a few interesting behaviors we wanted to share and get community input on.

Setup:

• Accounts have two balances: Daily_Toll_Free_Topup (*voice, 20 min/day, Weight: 20) and Unified_Monetary_Balance (*monetary, Weight: 10, 0 value by default)
• AllowNegative: false on all accounts
• debit_interval: 0s

1. 1-second call overage + default balance creation

With debit_interval: 0s, CGRateS authorizes the full MaxUsage (20 min) at call start. OpenSIPS cgrates module sets the dialog timeout accordingly. However if call runs for 20 minutes and 1 second, causing CGRateS to round up to 21 minutes, creating and charging $0.01 to a *default balance - even with AllowNegative: false. The *default balance is automatically created and goes negative.

Our question: is this expected behavior? We would expect AllowNegative: false to prevent any balance from going negative. Is the *default balance treated differently?

We believe this is due to SIP signaling delay between OpenSIPS sending BYE and the actual call termination. Has anyone found a clean way to handle this — either by subtracting a few seconds from MaxUsage, or via CGRateS configuration?

2. Blocker flag behavior

We set Blocker: true on Unified_Monetary_Balance thinking it would prevent the fallthrough to RP_ALL_DESTINATIONS. However we've since learned that Blocker simply stops CGRateS from evaluating any further balances after that balance — it does NOT prevent *default creation or the rating plan fallthrough per se. Can anyone confirm the exact mechanics of how Blocker interacts with rating plan fallthrough?

Any insights appreciated.

Thanks

[Armir Veliaj]

Hi bul...@gmail.com,

Please check below for both of your inquiries:

1. 1-second call overage and default balance creation

Yes, this is expected behavior. With debit_interval: 0s no debit loop is started, the session is authorized once at the start and no live debiting is performed during the call. Any extra cost at the end of the call is rated by CDR processing, and that difference falls through to *default which is created as a fallback and can go negative.
"AllowNegative: false" does not prevent this, it only applies during the authorization phase, and during CDR processing it simply produces a warning log without blocking.

To avoid chances of going negative you can put in debit_interval as smallest value as possible.
Another strategy for not reaching into negative would be  keeping a low-weight buffer balance that gets consumed  before it reaches *default. And if you want a cleanup mechanism, *topup_zero_negative can be set up as an ActionType to reset the negative account.


2. Blocker flag behavior


"Blocker: true" stops CGRateS from evaluating any further balances once that balance is reached. If the balance cannot fully cover the remaining cost, an "INSUFFICIENT_CREDIT_BALANCE_BLOCKER" log is thrown and the process stops there, so *default is not created in this case. If the balance fully covers the cost, the debit is finalized and no further balances are checked.

"Blocker: false" allows CGRateS to continue past that balance and when no balance can cover the remaining cost, *default is created and goes negative.


Hope this helps.

Thanks,
Armir 

--
You received this message because you are subscribed to the Google Groups "CGRateS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cgrates+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cgrates/4e22c8cb-1117-4894-a825-3fd6b7e62830n%40googlegroups.com.

[M B]

Thanks a lot for the clarification.