A-Z rating

I am going through the documentation for jbilling as part of an assessment for our billing requirements and in every case I have sen so far there are references to the rating of calls being performed by rules and the price is set in the rule.

This seems to work OK for national calling where there are usually only a few different call rates (local, long distance and mobile), but how does it work with A-Z international rating? We currently have over 35,000 that we rate against for long distance destinations and these rates usually change on a monthly basis - modifying 35,000+ rules on a monthly basis doesn't sound like a very efficient way of managing the rating process - is there a lookup process that can be performed where we can load all our rates from a csv into the table with their prefixes and the rating process will match the longest matching prefix against its assigned rate or something similar?

Thanks,

Ben

voicelogic wrote 1 year 30 weeks ago

Thanks Emiliano, I was

Thanks Emiliano, I was thinking along the lines of option 2 with the DB lookup - it turns out that both the existing sources of CDR's for us will do rating of the call so for now I am going to read the records in as rated records and simply use the mediation process to assign the events to an account which leads me to the next question - mapping events to a user / customer - I am guessing the best way to do this is once again with a decision table or a db lookup to say:

if callerid is xyz then allocate event to customer xx

Etc.

Cheers,

Ben

econde wrote 1 year 31 weeks ago

Hi Ben, We do this all the

Hi Ben,

We do this all the time, there are three ways:

- With a decision table: Here you use an excel spreadsheet to load a rate table as rules. Take a look to the Telecom Guide for more details. If you want an example, download the source code. There is a test case there that uses a decision table to rate long distance calls.
- With a DB look up table: Add a class to do the look up of a rate in the DB. It is not hard, and useful if the table is really big. We did this for a 150K table.
- With a memory look up table: Similar to the decision table, but harder to maintain. It involves custom code.

Cheers,

Emiliano Conde
Lead Developer - jBilling

Please register or login to post a comment.