provided by Star2Billing S.L.

Hi Les,
Yes, I would setup 6 ratecards on one call plan.

How good I am programming on PHP and MySQL? well, I have a strong background on Microsoft .NET technologies and SQL Server, I know how to program and I know about databases... so the language is not important.

I just applied my changes to my production environment I will share the results in 12 hours...

kind regards
Christian

Hi Christian,

As long as there is a known required input procedure to get the requested and required output, everything should be good. (I would think)

I have sent you a PM for a more off topic question.

Kind Regards,

Les

Hi,
It has been three days since I applied the patch to my production environment and everything is working just fine!!

I have created a ticket with the .diff file, so you can easily see my changes.


Give the change a chance and make your test, share your results.

Kind regards.
Christian

All least cost routing software has to route by the longest prefix.. There is no way to get around this. A2billing's least cost routing in the AGI doesn’t need to be changed or modified. When you get Prefix and Rate Data from multiable companies you must normalized the data in such a way so that your calls willl not route to company offering service to the exact same area as another company with a higher price because of it having a longer prefix.

With this being said the only changes needed in a2billing in regards to the least cost routing would have to be how it import the Rate Data. A normalizing scripted would be needed either at the time of importing the records or after the records are imported. Keep in mind the Data being entered is what needs to be modified and not the A2billing Agi Least cost routing code.

Hi Sam,
Yes, the suggested change uses the longest prefix per provider, it is a must since our providers bill us with the longest prefix.
As I mention on the ticket, I use the longest prefix per provider and for that prefix 'sample' I choose the cheapest and deliver the call.

Kind regards
Christian

Hi Sam,

I believe Christian's mod is doing what you are suggesting here. The only requirement for it to work would be having separate ratecards for each route/grade group a provider issues. If provider offers rate groups Great, Okay, and SoSo you would need to make three ratecards specifically for that provider/trunk.

You cannot make one ratecard with multiple provider/trunks.

I have used billing software that has the same separate ratecard per trunk requirements.

If Christian testing is showing data that it is working, wouldn't this suggest this may be a good solution for normalizing long prefix vs LCR?

Kind Regards,

Les

Hi,
What happens if the sell price is diferent for each provider?, will you be sending your clients a rate sheet(as a result of a call plan with lcr export) that will not macht your realtime rates?

Kind Regards,
mtel

Hi,
Well, how do you generate your price list now?
My first thoughts are:
- Keep the same method for generating your price list
- If a call goes for another route is because is the cheapest route with the longest prefix. Your customer will get a lower rate.


kind regards
Christancho

Hi Christancho,

I want to say great job on your code. It will indeed solve the problem many are having with the true least cost routing. Your Fix was a simple solution that solved a major issue. But as you can see and pointed out by a MTEL your code will cause other features not to work properly or eliminate them altogether. Just to name another one, with your FIX one can not have 2 providers under the the same Tariffplan. If am not badly mistaken I believe this will effect how the fail-over works as well. If i didn't already write script to normalize the routes before entering them I would have been tickled to death to use your fix and it would of been a life-saver for me. Thank you very much for posting your fix.

I just finished up the code for MTEL.. These are the steps he takes to shorten and normalize his routes.

1. Import the first provider to A2billing using the A2billing web interface.
2. run a series of sql statements that removes the data from cc_cardcard table and shorten the prefixes when possible and outputs the data into a new table.
3. once all the providers have been processed in this manner another series of SQL scripts are ran twice to add all the routes to a table with a trigger which normalizes the prefixes based on price and outputs this data to a table.
4. Finally the last script is ran to copy the data back to the A2billing cc_ratecard table.

Due to some limitation of the MySQL trigger code this is a several step precess but the end results the data is usable so that built in a2billing least cost routing and other features work perfectly as they are intended to.

This data will not only be usable to a2billling but other other call platforms as well. The ideal way to do it is to edit the data with a script such as PHP or JAVA after it has been entered into a2billing. This would greatly simplify the way I am doing it and will not prevent other a2billing features or functions from working.

regardless how useful your code might be to you and some others i don't believe it will make it into a2billing simply because it will create a need for too many other changes. Hopefully someone will write a PHP script that will normalized prefixes for a group of tariff plans. There need to be some settings and options so user can chose which tariff plans to normalize.

Hi Sam,

When you say Tariffplan do you mean ratecard or call plan?

Kind Regards,

Les

I mean ratecard

Hi Sam,
Thanks for your comments, you are very kind.

Well, I have tested the proposed change and in fact, when a call cannot be connected through its selected trunk it will be routed to the failover trunk.

May I suggest to use one ratecard per provider, and use one call plan with as many providers (ratecards) you wish to compete among them.

Hope this configuration works for your business model.

Kind regards
Christancho

Hi Christancho,
I could be mistaken but i think there is a fail-over feature in a2billing that goes belong just fail-overing to trunk but actually to the next shortest prefix in the the same ratecard. (Not call plan) I believe for this reason is why some would find it very important to put multiple providers under the same rate-card. I am not 100% sure but i thought this feature apply only to ratecards and not to a call plan that you might have assigned several rate-cards assigned to.

Just failing over to another trunk really ruins your ability to do least cost routing. Based on some complexed routes half to 90% of the calls might fail-over and you dont want these going to another trunk where you have no control over least cost routing.

Best Regards
Samuel Atkins

I have sent you a PM for a more off topic question.

Where did you send me a pm to or from? I never got anything.

Regards
Samuel Atkins