incorrect LCR behavior
Page 2 of 2

Author:  andyml [ Thu Nov 12, 2009 4:36 pm ]
Post subject:  Re: incorrect LCR behavior

Joe - I'm going to start a new thread for rate-card imports. I'm sure it is a topic that everyone is interested in!

Author:  andyml [ Fri Nov 13, 2009 3:05 pm ]
Post subject:  Re: incorrect LCR behavior

So - whats the next step(s) Joe? Do we need to somehow get Areski's attention? This is as far as my knowledge of process goes.

Author:  andyml [ Mon Nov 16, 2009 9:17 pm ]
Post subject:  Re: incorrect LCR behavior

I'm going to e-mail [email protected]. I'll keep you (singular and plural) updated.

Author:  jroper [ Tue Nov 17, 2009 1:07 am ]
Post subject:  Re: incorrect LCR behavior

This thread has been brought to his attention.


Author:  andyml [ Fri Nov 20, 2009 3:02 pm ]
Post subject:  Re: incorrect LCR behavior

Just an update for the community - it has been decided that this problem isn't a bug, but a feature. If you have a more specific rate for a given destination in any applicable ratecard, it is assumed that this rate is better than any other rates that might apply.

Areski see's the potential problem with this but would rather keep a2billing "safe", which certainly has it's value. He has said that he is willing to incorporate a "fix" for what I see as a problem as long as it's behavior is optional. He is also willing to implement said fix (feature?) for appropriate compensation.

My intention is to mull over the query day and night until I figure out what changes need to be made for it to work the way this thread established it should. I'm more than open to any help that might be available and will likely need help with any final implementation if I can figure out how to 'fix' the LCR query.

Thanks to everyone the helped me to refine my argument (Joe!) regarding the function of the currently implemented query, and I hope to report back shortly with a 'solution'. Also thanks for Areski for his attention to the community, and willingness to look critically at his code. He shows an excellent understanding of the meaning of peer review and received it well.


Author:  jroper [ Fri Nov 20, 2009 3:08 pm ]
Post subject:  Re: incorrect LCR behavior

Having also followed Areski's and Andy's discussions with interest, my main fear is as follows:-

Andy argued that it is the fault of the carrier if they do not provide detailed rates, and as a customer, we can take advantage of this, however, a big problem is that a provider may offer 0.3 cents to the whole of the UK, but not actually deliver to the whole of the UK.

Thus, because we do not re-rate the calls on fail over, the customer is going to be undercharged, and the admin will lose much money.

In order to make this work, you would have to recalculate the rate to apply on failover, and that cannot happen in a calling card scenario. ("...your rate is 3 cents per minute, oops, sorry no it isn't, it's 25 cents per minute!!!!...")

Alternatively, you would have to block rates from being used if they fail consecutively, and that is very non trivial I imagine to do, and requires major changes, and creates a whole new set of problems.

I still believe that in that in the future, we should consider separating the customer rates from the carrier rates, which hold many advantages, however this is a massive undertaking, and may increase post dial delay and loads on the database to unacceptable levels with our current architecture.


Author:  andyml [ Fri Nov 20, 2009 3:51 pm ]
Post subject:  Re: incorrect LCR behavior


I didn't realize we didn't re-rate calls on failover, which certainly is a big deal. I'll need to think that one over, though in my scenerio it doesn't change things (I'm trying to sell on a fixed rate anyway...)

Separating the customer rates from the buy rates isn't insignificant by any means, but a2billing's schema is conducive enough for it. The cc_prefix table is already setup to handle information per-destination for the export-via-LCR functionality. It would makes some sense to pre-run the LCR query on every destination, and be able to set the customer sellrate in that table. I know there are hundreds of dependencies but it wouldn't likely require a complete re-write.

So we'll see what happens. It might be a useful little patch to have on hand for the occasional user with heavy, proper LCR requirements... I should have an update shortly.

Author:  jroper [ Fri Nov 20, 2009 4:01 pm ]
Post subject:  Re: incorrect LCR behavior

Most people, but not all use the same customer rates for their customers, irrespective of carrier, hence the reason for considering that step, which would at least ensure that the charge for the destination was correct, with a properly constructed set of rate tables, even if the statistics and carrier costs were not absolutely correct.


Author:  andyml [ Fri Nov 20, 2009 4:09 pm ]
Post subject:  Re: incorrect LCR behavior

Of course, that said, I use 3 different ratecards with different sellrate's depending on the type of customer... Retail, medium-wholesale, and large-wholesale. I'd hate to lose that functionality too :) Currently I just have a copy of the providers for each ratecard, with different sellrates. At least most records get filtered out right away by the first where clause in the query.

Author:  RobertM18 [ Mon Jul 19, 2010 9:12 pm ]
Post subject:  Joe Roper's tutorials - Where for art thou?

andyml wrote:

Can anyone tell me where to find the tutorials?

I'm new here...

Author:  andyml [ Mon Jul 19, 2010 9:27 pm ]
Post subject:  Re: incorrect LCR behavior ... =a2billing is just one of many. That's the one I was talking about though.

Author:  andyml [ Wed Jun 04, 2014 7:37 pm ]
Post subject:  Introducing a New LCR Mode

PROGRESS!!! (Just noticed this) ... -lcr-mode/

Posted on November 9, 2012 by Areski
Star2Billing will be introducing a new LCR (Least Cost Routing) mode into its latest free and open source Switch and VoIP billing system, A2Billing version 2.

By default, A2Billing selects the longest match to the dialed digits from all the rate tables in the call-plan and will select the lowest cost rate. Therefore the rate-tables need to be constructed carefully to take full advantage of LCR as all prefixes to similar destinations have to be of the same length.

The new LCR mode, which can be selected with the lcr_mode switch in the agi-conf, will select to the longest match to the dialed digits in each of the rate tables in the call-plan, and from that list, will select the lowest cost rate.

Both LCR modes can be used on the same platform for different products and services.

A2Billing version 2 is set to be released next week.

Page 2 of 2 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group