Per-call cost rounding instead of per-interval

[George Diamantopoulos]

Hello all,

I've recently started experimenting with cgrates, and I think I'm starting to get the hang of it. I've been able to authorise calls via the Kamailio Agent, and see the respective account balance be consumed in real time. The version I've been testing is `0.11.0~dev+20250625191115+238559715-1~deb11u1`.

However, I'd like to achieve the following, and despite a lot of googling I haven't been able to yet:

I'd like to be able to charge in real-time with minimal rounding skew (say with RoundingDecimals>=12), but once the call is concluded, apply the *up rounding method to get at most two (2) decimal digits.

If I'm not mistaken, only the reverse is currently supported because one could do:

• Define a TPDestinationRate with a more coarse RoundingDecimals setting (e.g. 2)
• Set the global RoundingDecimals setting in cgrates.json to a finer setting (e.g. 3)

I understand this would round the charge of each charging increment to 2 decimal points, but once the call is concluded, it will be handled over to CDRs where the global parameter would apply over the total cost of the call.

However, the reverse (which I want to do) seems not to be possible: the global setting will effectively override any higher RoundingDecimals setting elsewhere.

My questions are:

• Is there any way to achieve this? Only apply a rounding function over the total cost of a call, with rounding effects kept to a minimum for charging intervals?
• Is there an upper limit to the RoundingDecimals setting in CGRateS? Or can it be arbitrarily high?
• Even for the reverse scenario described above, how is the discrepancy handled regarding the balance? I mean if there's realtime consumption of balance, and the total call cost were to be lower than all the previously applied real-time charges, would this be reflected by debiting the balance at the end of the call, and after CDR processing?

Thanks! BR,

George

[Armir Veliaj]

Hello George,

The rounding defined in the tariff plans is mainly used for visualizing the cost in the CDRs, and it's not the actual rounding applied to the balance by the system, which is defined in the CGRateS JSON configuration.  

Regarding your question about the limit for RoundingDecimal, it can go up to the maximum precision allowed by float64, which is estimated to be around 17 digits.

If you're using prepaid mode, charging is done in real-time. So, if it happens to add extra during a live call, it will be refunded and reflected in the final CDR.

Hope this helps.

Thanks,
Armir