Another idea can be have the customers to opt-in for auto-refill if they want to use multiple call feature. Usually this does not have be a high number, just autorefill the account if the balance goes down $1.
Jai www.didforsale.com *Buy DID at low cost http://www.didforsale.com" On Thu, Sep 18, 2008 at 8:14 AM, Jim Boykin <[EMAIL PROTECTED]> wrote: > Thanks guys for inputs...not allowing multiple call is not an option - > essentional thats the problem we try to solve :) > > Since we have our own CDR module, we can avoid external process. What > are the evens to listen for? > > Other ideas will also be appreciated. > > On Thu, Sep 18, 2008 at 8:23 PM, Alex Balashov > <[EMAIL PROTECTED]> wrote: > > Igor Zamocky wrote: > >> Isn't 'don't allow multiple calls' acceptable solution? > >> At least, it's the simplest one :) > >> > >> I can imagine solution with multiple calls allowed, but it needs some > external > >> synchronous processing. With every call you should start process, that > will > >> decrement user's balance based on dialled destination, you have to > update > >> balance every second. After balance=0 you just kill active call(s). > >> > >> The fact, that there are multiple calls means nothing, just more > processes > >> will decrement balance for the same user. > >> > >> Btw, this will give You oportunity upgrade balance during call, so > active call > >> can be longer than we originally thought - of course, you should not use > S(x). > >> > >> There will be probably a lot of other / more effective, easier, ... / > ideas :) > > > > You don't have to update the balance every second - increments of > > something like 10 seconds will do. And you can have one synchronous > > process - not many - that listens to Manager events and updates the call > > times and balances accordingly. An outside process can also trigger a > > Hangup event causing the call to be hung up if credit is exhausted, or > > too low. > > > > Then, you can define a minimum formula for the balance required to admit > > a new call. Something like a minute of credit being required after > > subtracting the usage of all existing simultaneous calls in progress at > > the next projected utilisation polling interval. > > > > But you are essentially correct. Things are, of course, far easier if > > you just don't allow multiple simultaneous calls. :-) > > > > -- Alex > > > > -- > > Alex Balashov > > Evariste Systems > > Web : http://www.evaristesys.com/ > > Tel : (+1) (678) 954-0670 > > Direct : (+1) (678) 954-0671 > > Mobile : (+1) (706) 338-8599 > > > > _______________________________________________ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > > Register Now: http://www.astricon.net > > > > 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 -- > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > Register Now: http://www.astricon.net > > 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 -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
