asterisk2billing.org
http://forum.asterisk2billing.org/

Realtime billing - taking off credit during a call
http://forum.asterisk2billing.org/viewtopic.php?f=15&t=2818		 Page 1 of 1
Author:  elbow [ Mon Nov 19, 2007 6:35 pm ]
Post subject:  Realtime billing - taking off credit during a call
Hi,

Is there any existing support in A2Billing to allow credit to be deducted steadily _during_ a call rather than taken off lump-sum at the end of the call?

I have a customer who needs to use a customer's A2Billing credit both to cover the phone call and other network costs. So, at the same time as the call is charged, they need to in parallel bill other variable costs.

Its very important to them that the customer doesn't go overdrawn.

We have an idea to implement it, but just want to check that I didn't overlook existing code.

Regards,
Steve
Author:  xrg [ Mon Nov 19, 2007 7:56 pm ]
Post subject: 
We have already given a little thought in that: currently, a2b is based on the L() function of asterisk's 'Dial()' application. That is, it can only stop the call once, at a predefined time.

You could possibly hack around that and have a parallel thread that will signal the asterisk channel to close when the call is due to end. But, that will always remain an ugly hack.

The proper solutions would be asterisk to implement billing 'ticks', i.e. predefined checks that will periodically check if the call is allowed to continue....
Author:  elbow [ Tue Nov 20, 2007 2:32 am ]
Post subject: 
Hi Xrg,

Thanks for the reply.

For billing "ticks" to work, we'd have to tell Asterisk the billing intervals and all that with the call?

In my case that wouldn't be adequate, because we have an external process also taking credit. So there's no way Asterisk by itself would know when the call must be dropped.

So I think it will be necessary to actually soft hangup the call.

Steve
Author:  xrg [ Tue Nov 20, 2007 7:41 am ]
Post subject: 
There is one more implication, if you are determined to implement billing in a 'politicaly correct' manner: at most ISDN (including PRI's, of course), you may have AOC packets, that actually say "now, your provider bills you".. The correct way would be, at those lines, to have the AOC packets processed and passed (through the 'ticks' mechanism) to a2billing...

But I guess I've gone too far already..
Author:  asiby [ Tue Nov 20, 2007 8:14 am ]
Post subject: 
Elbow, what you need is feasible and we need the same feature. We have it currently on the drawing board but it won't be available soon for a couple of reasons. Even thought it is possible, the database updates intervals will have to be carefully chosen otherwise, your system will just spend much of the bandwidth and CPU power on updating the DB. That may affect voice quality and much more.

Regards
Author:  stavros [ Tue Nov 20, 2007 9:49 am ]
Post subject: 
xrg wrote:
to have the AOC packets processed and passed (through the 'ticks' mechanism) to a2billing...
I thought everyone working on AOC support on Asterisk had thrown in the towel due to the deep architectural changes that would be needed to do it correctly?

asiby wrote:
Elbow, what you need is feasible and we need the same feature. We have it currently on the drawing board
I didn't realise we could coax Asterisk into returning control to an AGI until after the Dial command completes.
Elbow should be aware that this proposed solution is probably not the panacaea he seeks; he seems to want multiple applications deducting from the same balance in realtime. I think perhaps RADIUS enabled applications would be better suited to this task.

asiby wrote:
the database updates intervals will have to be carefully chosen otherwise, your system will just spend much of the bandwidth and CPU power on updating the DB.
I think a well chosen index should remove all worries on this count. An index across the uniqueid and starttime fields should suffice if your UPDATE statements' WHERE clauses can use the same fields.
Author:  elbow [ Tue Nov 20, 2007 1:06 pm ]
Post subject: 
stavros wrote:
asiby wrote:
Elbow, what you need is feasible and we need the same feature. We have it currently on the drawing board
I didn't realise we could coax Asterisk into returning control to an AGI until after the Dial command completes.
Elbow should be aware that this proposed solution is probably not the panacaea he seeks; he seems to want multiple applications deducting from the same balance in realtime. I think perhaps RADIUS enabled applications would be better suited to this task.


Hi,

My mental design for "interim" billing was to use an external process running alongside the agi. So at the time the AGI script dials, it drops a row into an "active calls" table. Afterwards it removes that row. Rows in that table are used as the input to the interim billing process.

In the meantime a lengthy discussion at the customer's seems to have resulting in splitting the accounting for voice and the other stuff and having the customer re-charge each "bucket" separately. Simpler for us.

Thanks,
Steve
Author:  krzykat [ Tue Nov 20, 2007 3:08 pm ]
Post subject: 
Realtime is very nice. I'd love to see us be able to have so that at the desired "ticks" - such as 30 second incremental billing, every 30 seconds, it grabs and subtracts from the balance the next 30 second billing. This way, if you are doing say a wholesale operation where one customer has 10 calls concurrent, you could stop him from going negative. Obviously - the choice of the increment is crucial and if someone did 1 second increment with a heavy load, it would impact the system greatly.

But can it be done? Could A2B have another thread that runs and deducts the money each 30 seconds, and also if insufficient funds, doesn't allow the next increment and closes the line? Sounds like a lot of work, and then is it worth it ??
Author:  xrg [ Tue Nov 20, 2007 4:20 pm ]
Post subject: 
krzykat wrote:
But can it be done? Could A2B have another thread that runs and deducts the money each 30 seconds, and also if insufficient funds, doesn't allow the next increment and closes the line? Sounds like a lot of work, and then is it worth it ??


That would be possible with FastAGI instead of AGI.. But then, we would surely want a script in a multithread application. We would have to drop PHP, because it is not multithreaded.
Author:  asiby [ Tue Nov 20, 2007 11:41 pm ]
Post subject: 
No need for multithreading of any sort. Just leave that to me. It's all under control and it look much like Elbow's idea. The best way do know if it will work for sure is to try it. But feel free to make objections :D. That will probably help us perfect the code even more.

Speaking of multithreading, what really happen when the same asterisk box receives another call while the agi is already running? It will be interesting to know that. If more than one a2billing.php process are running, could that pose some sort of problem (hypothetically)? If so, it could explain some random and yet unexplained behaviors that we are observing with a2billing. (It's just a thought)

I know that while php itself and its 'core extensions' are thread safe, many 3rd party extensions are not. So if none of those 'thread unsafe' extensions are being used, it should be possible to use php in a threaded environment. But that's not what I intend to do.

Added after 1 hours 25 minutes:

Oh, by the way, FastAGI AGI only allow to implement an AGI call over a TCP socket. So instead of having the AGI script in the same box, it can be called from another box. Not sure how that will help thought.

In our drawings, the AGI script will be in the box containing A2Billing.
Page 1 of 1 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/