[Asterisk-Users] about billing realtime (maybe OT)

Simone Cittadini mymailforlists at gmail.com
Mon May 8 01:58:19 MST 2006


I've followed with interest the discussion about realtime billing, 
anyway, even if it could be a fascinating subject as a developer, I've 
always felt that from a project management point of view the problem is 
simply non-existent, because the money lost with wide-grained control is 
unimportant against the higher system complexity and time spent in 
research to achieve fine-grained control.

I've tried to put a couple of formulae on paper to be less qualitative 
and more quantitative, be warned that :

1) I don't came from a TLC background, maybe there is something about 
call flows that I'm missing
2) I'm not a "businessman", maybe there's something about money flows 
that I'm missing

There are 3 ways to control customer's credit, different implementations 
have been proposed, but basically :

- "pre dial control", the simplest :

    if credit < 0 do the Dial
       else redirect to the Playback(sorry, money makes the world turn)

    on hangup update credit

- "set maxtime per call", still easy to implement, a bit more heavy on 
the cpu, since you have to do some math before the call

    if credit > 0 find the price for requested number and set maxtime, 
do the call
       else Playback(go away, loser)
   
    on hangup update credit
   
- "set maxtime per call flow", complex to implement, heavier on the cpu 
since it needs some kind of polling, heavier on db if you don't cache 
credit data

    set maxtime per call
   
    then during the call :
       every n minutes do :
          for each call in the flow (one customer, one flow):
             credit = credit - (n * call price per minute)
             update maxtime

    on hangup update credit


Since this is becoming long I'll go quickly to the point :

    the max money you can loose with "pre dial control", which is 
obviously the more wide-grained, is

       2 * MaxConcurrentCalls * MaxCallLength * medium_price_per_minute

    I dont' take in account MaxPricePerMinute since high international 
prices are way too higher and less frequent than the average ones.
    Given MCL = 1 hour (if you don't set this value chances are your 
provider is setting it) and MCC = 20 (that's my biggest customer limit, 
and the average is 15/18) we loose around 100$, supposing high prices ( 
I'm actually loosing 72 euro ). This seems to support my feeling, just 
update the credit in a cronjob every 30 minutes or so and you should 
sleep safe.

    for the average case :

       2 * average_calls_per_update_interval * average_call_length * 
medium_price_per_minute

       now we can infer average_calls_per_update_interval and 
average_call_length with select in the db, but I suppose there is some 
function like
      
          average_calls_per_update_interval = f(update_interval, 
hour-of-the-day)

    and my new feeling is that inserting different update_intervals in 
different hours-of-the-day in your crontab, so that the above formula 
stays below a value choosen with the investors, you can minimize the 
extra cpu usage while keeping the system simple and achieve results 
equivalent to the ones of more complex solutions.

(as they say in books, I leave the Max/avg formulae for the other cases 
as an exercise for the reader)



More information about the asterisk-users mailing list