thanks mate, for useful and good information provided by you, i am not asking you that please write down your all LOGIC and explain everything to me, as per your explanation i can see it will deduct amount for only 1 call but what actually i am searching for is if user made 5 concurrent calls and i have to limit all calls and each destination number having different rate may be some of them ISD and some of them local. that will create more problem to me, i think there is some solutions for this . could you suggest any reference for the same, it will be more helpful to me.
thanks in advance, regards Dhaval On Thu, Oct 21, 2010 at 12:49 PM, Sherwood McGowan < [email protected]> wrote: > > > On Thu, Oct 21, 2010 at 1:30 AM, DHAVAL INDRODIYA < > [email protected]> 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 < >> [email protected]> wrote: >> >>> On Thu, Oct 21, 2010 at 12:24 AM, DHAVAL INDRODIYA < >>> [email protected]> 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 > > -- > _____________________________________________________________________ > -- 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
