Support A2Billing :

provided by Star2Billing S.L.

Support A2Billing :
It is currently Thu Mar 28, 2024 9:11 am
Hosted Voice Broadcast


All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Realtime billing - taking off credit during a call
PostPosted: Mon Nov 19, 2007 6:35 pm 
Offline

Joined: Mon Nov 19, 2007 6:29 pm
Posts: 3
Location: Cape Town, South Africa
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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 19, 2007 7:56 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
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....


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 2:32 am 
Offline

Joined: Mon Nov 19, 2007 6:29 pm
Posts: 3
Location: Cape Town, South Africa
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 7:41 am 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
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..


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 8:14 am 
Offline
User avatar

Joined: Mon Apr 30, 2007 6:43 am
Posts: 1060
Location: Canada
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 9:49 am 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 1:06 pm 
Offline

Joined: Mon Nov 19, 2007 6:29 pm
Posts: 3
Location: Cape Town, South Africa
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


Last edited by elbow on Tue Nov 20, 2007 4:07 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 3:08 pm 
Offline
Moderator
User avatar

Joined: Tue Jun 06, 2006 12:14 pm
Posts: 685
Location: florida
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 ??


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 4:20 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 20, 2007 11:41 pm 
Offline
User avatar

Joined: Mon Apr 30, 2007 6:43 am
Posts: 1060
Location: Canada
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 
Hosted Voice Broadcast


All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group