This script keeps track of calls on Asterisk SIP channels and drops them when account credit has expired. Usually accounts end up in negative balance because of script errors or by the way Asterisk and A2B handle concurrent calls on the same account. This script is meant to prevent negative balances or exceeding credit limit.

This script runs as a cron job that constantly checks on asterisk for active calls and the remaining account credit. It has been tested to work on SIP channels, but may work on any type of channel by removing the SIP restriction. Other types of channels were not tested.

Installation steps Asterisk > 1.6.x , A2B > 1.9.4, PHP 5.2+

Modify files in A2B

1a.In /usr/local/src/Star2Billing194/common/lib/Class.A2Billing.php in the run_dial function.Add these two lines at the top of the function before the dial

1b.In /usr/local/src/Star2Billing194/common/lib/Class.A2Billing.php in the call_2did function.Add this line near the top of the function under the line "$selling_rate = $listdestination[0][9];" (ths is added to the channel in asterisk)

Code:

$agi ->set_variable("callrate",$selling_rate);

1c.In /usr/local/src/Star2Billing194/common/lib/Class.A2Billing.php in the call_did function.Add this line near the top of the function under the line "$res = 0;" (ths is added to the channel in asterisk)

Code:

$agi ->set_variable("callrate",$listdestination[0][9]);

1d.In /usr/local/src/Star2Billing194/common/lib/Class.RateEngile.php in function rate_engine_performcallAdd this line

2. Copy the script below, change the name to .php and set it as a cron job to run every minute (exactly one minute no more no less for proper operation). Also edit the cofiguration variable in the new .php file to point to the asterisk binary et al.

It can also be ran from the command line, eg; php /usr/local/src/Star2Billing194/Cronjobs/a2billing_check_simult.php -v

But here, in your script, we're making some function out of asterisk box itself, why, where's the reason, is not better use own asterisk call-limit directive as it's running with the callcounter?? Because running an external script even, it' may have bugs and overload the cpu socket, or where's the reason, did you tried already the call-limit and the callcounter functions, and they fail with you??

You made some good points. I have not yet tried what you suggested. but the thinking behind this is when [email protected] and Asterisk all fail, then this is the last line of defence.

Consider when [email protected] gives the wrong time-out value as in script errors, when asterisk fails to hangup the call for whatever reason or when concurrent calls for the same account is active, there is no mechanism to track this cost realtime. This script comes very close to that.

As for the load factor, that's a concern , but [email protected] already has 10 cron jobs running and this script does way less and does not access any database.

For the future, closer integration with asterisk is the only way to achieve this and minimize the load factor.

Consider when [email protected] gives the wrong time-out value as in script errors, when asterisk fails to hangup the call for whatever reason or when concurrent calls for the same account is active, there is no mechanism to track this cost realtime. This script comes very close to that.

But if you turn callcounter directive to on, in sip.conf and in the db, as I add that row in cc_sip_buddies, asterisk will stat to run his own counter, so it's not depending on a2billing agi script any more... Then asterisk turn the counter, and according to the cal-limit fixed for each user, asterisk drop whatever incoming calls over that limite...

Sorry, this what I understand from that, if I'm mistaking, correct me!!

Also, here we may fix channels for users, so if we're using wholesale traffic, we need to set and limit channels, I'd use this directive for each peer to fix the channels, I guess is the best, or not??

Quote:

As for the load factor, that's a concern , but [email protected] already has 10 cron jobs running and this script does way less and does not access any database.

In my case I have more, cause I run a2billing crons, then anti scanning cron each half minute, from here: http://www.teamforrest.com/blog/171/ast ... und-block/ ... also the backups crons for the DB each 10 minutes... so lastly the serve will be only running crons or handle traffic...

The question, did you use already this what are you proposing, dose it worked for you?? I'd test what I did by running sipp script to check if really asterisk will do this, or how it's... if you want, send me a PM, we would run sipp reciprocally, to test and report the community here...

Hi Vulcan,I just re-test my previous proposed solution here: viewtopic.php?f=34&t=9294, by running sipp testing, and it seem to be working perfect, calls are being drop after limit excess. below the trace:

Thanks for the info. That addresses a different issue; though, those settings are limiting the number of concurrent calls a peer can make.

The script above addresses a different problem, and that is to cut off calls at the the credit limit if Asterisk does not do it. It is for those calls that might run into negative due to various errors. Currently A2B calculates the credit correctly, but not always the timeout and not always if enough credit is available for the call (bugs).

As long as A2B reports the correct credit, the script works because it gets the CDR billsec realtime from asterisk.

Thanks for the info. That addresses a different issue; though, those settings are limiting the number of concurrent calls a peer can make.

The script above addresses a different problem, and that is to cut off calls at the the credit limit if Asterisk does not do it. It is for those calls that might run into negative due to various errors. Currently A2B calculates the credit correctly, but not always the timeout and not always if enough credit is available for the call (bugs).

As long as A2B reports the correct credit, the script works because it gets the CDR billsec realtime from asterisk.

Hmmm, interesting, we're talking about different issues, in the same direction. We need first to limit the calls to avoid asterisk to accept more calls, this is generic, but your script appoint to calculate and run realtime billing to avoid going in negative... interesting, I'd go to setup this...

That is all great that both are working to be sure bad things does not happen.... My hat is off to you for the effort.I think that if you are doing this to get around a bug in a2b why not fix the bug instead? Perhaps work with the developers to get it fixed and we all benefit from it. if this is not a real bug still it is big enough to justify some effort to get it changed before someone really gets hurt. This has a direct effect in all our pocket books.Asterisk is already complex enough in itself that this recompiling and changing of asterisk can only come back to bite us all.

The installation described is just a utility and not absolutely necessary if you patch the code. It was created as a stop gap until the real problem could be found (also safeguarding against unforseen problems in A2B , Asterisk or the SIP protocol).

The problem affected POSPAID and concurrent POSTPAID/PREPAID calls, in that, accounts ended up in negative balances , timeout value incorrect and credit limit verification. The timeout value and credit limit verification are fixed with patch , but the concurrent calls negative balance is inherent in the design. It will actually need a customised version of Asterisk or a running realtime utility to fix that. So compliling might be in the future to eliminate negative balances.

This utility only allows one minute over the credit limit in all cases (SIP) if call does not hangup for whatever reason.

Quote:

That is all great that both are working to be sure bad things does not happen.... My hat is off to you for the effort

Not both are tinkering with asterisk , just mine, ubunter's is standard in Asterisk and concerns max number of concurrent calls a peer can make and thats it. It is also a different issue entirely. Not a fix for the bugs.

First of all no need to make modification in asterisk source code and recomiling "core show channels concise " gives you the required information about the active channels with seperator as "!" and also provides FULL channel names without shortened.

now i am implementing your code to work with AMI, instead of shell execute.

Who is online

Users browsing this forum: No registered users and 1 guest

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