This version fixes minor bugs, in particular related to re-seller support.

It implements a new CheckFraud job, that advises the administrator in case of suspected calls that can be made from hacked VoIP accounts. It is enabled configuring these settings:

# Used from job CheckFrauds (enabled only in commercial version)
# The job run according the scheduling of `check_cost_limits_after_minutes`
#
check_frauds:
max_unprocessed_calls: 10
# if there are more than these unprocessed calls,
# then advise the administrator, because there can be unnoticed high calls costs

compare_xx_last_days_respect_customer_daily_max_cost: 5
# note: customer daily max cost is the customer monthly max cost, specified in the user interface,
# divided by 30. Set to 0 for disabling it.

compare_x_last_months_respect_current_costs: 3
# warn if a customer spent a 25% more than the maximum cost of last x months in the
# same day of week and a comparable hour of the day (hours grouped by 00-06, 06-12, 12-18, 18-24).
# Set to 0 for disabling it.

Remember executing:

./configure.sh

after upgrading the configurations.

This version fixes another serious bug about recognition of call cost limits, very similar to previous bug. The source of both bugs was a naive copy and paste of already working code, without applying all the needed changes, and without a serious review of code. Sorry.

If you are using an older version of Asterisell and you do not want upgrading, you can apply manually this fix, because it is rather simple. Inside file 'apps/asterisell/lib/jobs/checks/CheckPartiesWithoutParams', replace:

const FILE_WITH_LAST_CHECK_DATE = "last_check_call_cost_limit";

with:

const FILE_WITH_LAST_CHECK_DATE = "last_CheckPartiesWithoutParams";

and:

$checkFile = CheckCallCostLimit::FILE_WITH_LAST_CHECK_DATE;

with:

$checkFile = self::FILE_WITH_LAST_CHECK_DATE;

The commercial version contains some checks for anomalous calls, for discovering frauds of VoIP calls. More details and more powerful checks, will be part of 3.11 release.

This version fix a serious bug about recognition of call cost limits.

If you are using an older version of Asterisell and you do not want upgrading, you can apply manually this fix, because it is rather simple:

@@ -32,7 +32,7 @@ class CheckPartiesWithoutParams extends FixedJobProcessor {
 -    const FILE_WITH_LAST_CHECK_DATE = "last_check_call_cost_limit";
 +    const FILE_WITH_LAST_CHECK_DATE = "last_CheckPartiesWithoutParams";

This version introduces a bug-fix in installation instructions and in database upgrade procedure.

Database upgrade requires a user with "alter table privileges". So to the Asterisell user configured in "config/databases.yml", must have these rights. From MySQL shell:

CREATE USER 'asterisell3user'@'localhost' IDENTIFIED BY 'some-password-here';
GRANT ALL ON asterisell3.* TO 'asterisell3user'@'localhost';

This example, supposes that "asterisell3" is the name of created Asterisell database, and "asterisell3user" the name of database user.

NOTE: "GRANT ALL" is needed in order to support the database upgrade script.

The database upgrade script check for this and signal the problem.

If you have already updated the database with a user without these privileges, and using the previous version of Asterisell, you must remove upgrade data from the database shell:

delete from ar_database_version;

and execute upgrade script again.

This version contains a small bug-fix.

Errors during importing of CSV files, are signaled in the error table, but if the administrator delete them, they are not generated again (on the contrary of all other errors generated from Asterisell), because by default a CSV file with errors is not imported again, and it remains silently in the processing directory.

With this bug-fix, the administrator must delete explicitly these errors, because the delete all problems button does not delete them automatically. So the administrator is (more) conscious of what he is doing.

In practice the worst-case scenario, is rather infrequent because if there are problems in the format of a CSV file, there are probably similar problems in other CSV files, so the administrator is aware that there are CSV files to process again.

In any case, after applying this patch, check also if there are pending CSV files in the processing directory.

There is now a better database upgrade process:

cd scripts
php upgradedb.php

Fixed a bug about the display in CALL REPORT of internal and external telephone numbers, when in app.yml config file, the the internal_external_telephone_numbers setting is 1.

Fixed a minor bug in displaying an error message about CSV imported rates.

Please read all the notes about 3.9.0 version.

There are minor database upgrade problems in Asterisell 3.9.0.

If you are planning the upgrading, please wait few days. I will improve the upgrade process using a better method, and I will release a new version of Asterisell.

This new version of Asterisell introduces many new features and improvements:

• full support for Resellers (a Reseller is a separate instance of Asterisell, reselling the VoIP calls of another Asterisell instance);
• 2x speedup of Call-Report;
• fixed a memory-leak problem during CDR rating process (it affects only the rating of thousands of CDRs);
• update of telephone prefixes description table;
• invoices can have inclusive or exclusive ending date;
• invoices can be configured for containing long details on called geographic-locations, or only short details on used connection types (fixed-lines/mobile lines/special numbers);
• the Call-Report, exported CSV file format can be further configured from app.yml;
• installation page on this site contains hints about configuring MySQL for 10x speedup in case of many CDRs;
• validators on user names and passwords;
• recognition of some error-prone rates;
• removed not used indexes from CDR table;
• various minor improvements to forms and helps;

The major drawbacks of this upgrade, it is that it modifies the CDR table. No data will be lost, but during upgrade, the CDR table will be locked. During upgrade process new CDRs will not inserted inside the table. If it contains milions of records, then the lock can last also for 1 hour. If this is a problem, let me know. It is possible creating a script for making the upgrade using a temporary CDR table, avoiding any lock.

For upgrading, follow the upgrading instructions on this site.

If some indexes fails to be removed and it returns an error message, execute again the database upgrade script.

After upgrading, check apps/asterisell/config/app.yml file and update the settings:

• decimal_separator_symbol_in_csv
• numbers_as_strings_in_csv
• csv_field_separator

After database upgrade, you can upgrade your current telephone prefix table using:

cd scripts
php reset_db_and_init_data.php merge-telephone-prefixes

This is not needed, if you are making a new installation.