[asterisk-users] Asterisk Realtime Billing Question???

Sherwood McGowan sherwood.mcgowan at gmail.com
Thu Oct 21 02:19:13 CDT 2010


On Thu, Oct 21, 2010 at 1:30 AM, DHAVAL INDRODIYA
<dhaval.it01034 at gmail.com>wrote:

> Hi Sherwood ,
>
> well , i think you did not understand my question , i want real time
> billing
> like as i mentioned that if i want to dial 5 number with different call
> rate how can i access same
> balance into those 5 people, if all are connected how can i periodically
> update billing , as you suggested it will assign total balance to those 5
> people but actually we can not do like this as total balance of user $100 ,
> as per your suggestion it will give $100 for those 5 people which is
> practically wrong i think.
>
> give your thougts.
>
> regards
> dhaval
>
>
> On Thu, Oct 21, 2010 at 11:44 AM, Sherwood McGowan <
> sherwood.mcgowan at gmail.com> wrote:
>
>> On Thu, Oct 21, 2010 at 12:24 AM, DHAVAL INDRODIYA <
>> dhaval.it01034 at gmail.com> wrote:
>>
>>> Hello All,
>>>
>>> after so long time i posted a new question regarding billing, hope
>>> anyone have some solution.
>>>
>>> I have situation in that i want to do billing of more than 1 call in real
>>> time below are scenario and explanation.
>>>
>>>
>>> Scenario:
>>>  A customer called my DID number and after that from here i dial few
>>> number let say 5 number. once number are placed into DIAL
>>> i will put this customer into conference [MEETME] , once a Members are
>>> picked up call they will also patched into conference and
>>> talking is started, every thing working fine with DIAL-PLAN and DB look
>>> up.
>>>
>>> Now, i want to do billing on customer dialed my DID, and from that
>>> actually it DIALED 5 numbers, how can i DO real time billing
>>> into this situation, like numbers can be different It can be
>>> ISD,STD,Local and also free .
>>>
>>> if customer having initial balance of $100 then how can i check balance
>>> every time.in a situation once balance is nil then i want to disconnect
>>> calls . is any one facing this type of situation.
>>>
>>> give me some  idea ,
>>>
>>> regards
>>> Dhaval
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>>               http://www.asterisk.org/hello
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>>
>> Dhaval,
>> This sounds very much like a system I'm working on for a client right now.
>> I'm not permitted to disclose much about it due to the NDA i signed, but
>> I'll risk giving you a point in the right direction.
>>
>> First, you should create a table in your database that has a column called
>> callid, and other columns that you will have to decide upon. This table will
>> be called something like '*call_references*'. Oh, and you'll want to
>> define callid as the primary key for records in that table, but DO NOT make
>> it an autoincrement, you're going to populate it with a value that is
>> described in the next step.
>>
>> Second, at the beginning of the original call you mentioned, define a
>> variable that will be unique to that call. I personally have done this by
>> stripping all non-digits from the caller's callerid (using
>> Set(newcid=${FILTER(0123456789,${CALLERID(number)})} ), and then adding the
>> to ${EPOCH}. I did it this way: ${MATH(${newcid}+${EPOCH})}.
>>
>> Next (this is where I have to start being a bit vague), you're going to
>> perform an INSERT query, creating a new call_references record (using that
>> variable I just showed you how to construct as callid's value).
>>
>> Now, when you defined that variable, you should have preceded the variable
>> name with two underscores ( __ ), which will tell Asterisk that channels
>> spawned by the current channel will inherit that variable and it's value.
>>
>> Voila, you now have a method for storing realtime data such as billing
>> information between MULTIPLE calls.
>>
>> I wish I could tell you more, but I can't violate my client's
>> Non-Disclosure Agreement.
>>
>> Hope this helps you out!
>>
>> Sherwood McGowan
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>               http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

Well, you got the right guy, I've written several different RT billing
setups for clients ranging from small residential ITSPs all the way up to a
wholesale carrier in Austria. . .

What you'd have to do is have a column called "freeze" in your table that
you keep customer accounts and billing info in (mainly, the balance). Then,
you'd need a 'frozen' table, with three columns: id, accountid (or some
other name/reference that references the customer in question), and amount.

Now, the "freeze" column in the account table defines how many minutes worth
of funds (at the rate the call is being charged to the customer) you're
going to make unavailable to the customer until the call is completed. You
multiply the value from "freeze" against the rate the call is going to be
charged at, resulting in "amount_to_freeze". Subtract that number from the
customer's current balance, and then create a record in the "frozen" table
with that customer's accountid and put the value of amount_to_freeze into
the "amount" column.

Finally,when the customer's call(s) completes, calculate the total charge
for the call, check to see if it's more than `frozen`.`amount`, and if it
is, subtract `frozen`.`amount` from the total charge, and then subtract the
remaining amount from the customer's balance. If the total is *not* more
than than `frozen`.`amount`, you'll subtract total from `frozen`.`amount`,
and then ADDING the remaining amount to the customer's balance. (Being the
doofus I am, I called that procedure "thawing", LOL)

In addition to the freezing of funds, you'll need to perform some magic and
limit the length of the customer's calls based on the balance of the account
just before freezing funds. This will need to be in conjunction with having
a maximum number of concurrent calls the customer can have, and taking that
into account when limiting each call.

It sounds complicated but I wrote this type of system several times, the
first couple were native to Asterisk using AELv2 (no AGI calls, more secure,
less resources hogged, etc), and then I wrote the last one using MySQL
stored procedures to perform just about ALL of the calculations and logic.
Basically at the beginning of a call, Asterisk would execute a stored
procedure called something like freeze_and_limit and passing two arguments,
the accountid and the rate per minute their call is going to cost (could
have also just fed the SP the destination and let it calculate THAT too).
MySQL would return the number of milliseconds the customer's call could be.

Alright, hopefully THAT gets you heading in the right direction, because if
I write much more I'd be getting into EXACTLY how I wrote up the "FLaT"
(Freeze, Limit, and Thaw) system, and that would be depriving me of
potential consulting fees I'd normally get for just implementing it for a
customer.

Cheers mate, and good luck :)
Sherwood McGowan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20101021/f23d4459/attachment.htm 


More information about the asterisk-users mailing list