Joe,
I really appreciate your thoughts, and your keying in on this issue. I apologize for the length of this post but before I get into it, I just want to point out to the community how immensely helpful Joe is and what a vast font of knowledge we have in him. I certainly would not be where I am today with A2Billing or Asterisk without Joe Roper. Truly.
Joe - My opinion is that you might be over-thinking it just a bit, and in doing so I think you've made a mistake. Please forgive me as I try to make my point below if I get in any way sharp. I present this argument with much respect.
In the states, when you request a rate-table from a carrier and get an 8 digit rate table from a carrier, (1 NPA NXX X) they are giving you a solemn vow. An 8 digit table (refered to as a 7 digit table here, since no one would include the 1*) has ~1.4 million rows - it is incredibly specific. These rows aren't committed to willy-nilly. If 1 901 201 1XXX costs less than 1 901 201 2XXX, there's a reason for that - some CLEC somewhere has that 2XXX block and charges a little more for access etc, and that carrier knows about it and wants their margin intact.
Likewise, bigger carriers (read really big - Verizon, Level3 etc) might only give you a 7 digit rate table, (or an 1 NPA NXX, refereed to as a 6 digit table here*). Their margins are better because they might run the infrastructure in the area or have better deals because they're a huge monster, for example. They don't need to mark up the 2XXX anymore than the 1XXX so they don't. Their rates to the area are likely better than the other carrier that needed to mark that one area up, so processing the call through them is an important thing.
I would argue that saying A2Billing needs to compensate for Carriers that have bad rate tables is very dangerous ground. For one, how can you know it is compensating properly? What is the point of LCR if you can't actually use it to route calls to their destinations based on cost?
I understand your example - I really do. That carrier of yours that wants 10p for a 50p route (if he were in the US anyway) needs to get burned, and as a result update their rate table. Meanwhile, you need to save 40p/min. That is Telecom - always has been. A2Billing can't be responsible for that. When they update their rate table and you load it up, your LCR engine will know about it too. Alternatively, if they pass the burn on to you, you can simply update that specific rate in your deck (either accurately, or just to disable it) so as not to go through that carrier - but in the case of a larger carrier, that less specific rate may legitimately be cheaper. How is A2Billing supposed to know which it is? One is a mistake, and the other is by design. My argument is that A2Billing should respect the one that is by design.
You're right though - this is not a minor change. I don't really expect someone to come along and say "Oh yeah, swap out line 223 of XYZ file with this line and it'll work" (though I'd welcome anyone to try!!) But the way rate-tables are written here, the correct way to determine the cost of a call from that carrier is to find the most specific rate from that carrier in their rate table. If it is less specific than another carrier's rate table, they're still saying that is the rate. Hell, it probably came out of the customer side of THEIR LCR engine.
The query I submitted above came from a commercial LCR engine the company I work from in my day job wrote. It is "how you do LCR in Telecom". I changed the table and column names for it to work against A2B's db. If your upstream reseller isn't being specific about a premium rate in their rate-deck, that is considered VERY bad form (and most certainly their fault) - bad enough to take legal action here in the states (if the table was up to date.) A2Billing can't be responsible for that.
Now - your other point -
what if the carrier doesn't/won't route calls to those high-dollar areas? I've run into that here in the states. I have a very low cost International/A-Z provider that has an excellent international rates, and a good flat rate to the US - $0.0101. They are not in the US so they don't understand all the ins and outs, but they also don't care. What they've done is stopped routing to very rural areas where it costs them more than x. They only guarantee 50% delivery anyway, so if I want to take advantage their really good rates to anywhere, I have to be able to choose them based only on the 1 digit (country code of 1 for the US) AND I need to be prepared to fail over to a backup provider. The query above actually returns to you the two cheapest providers from the customer's callplan for that destination regardless of the number of digits that match so theoretically it could route the call to one, then the next on failure - BUT A2Billing already has a failover trunk, which is usually "good-enough". Lets leave failover aside though - I really just want to establish LCR.
You also referred to LCD - or LCR based on the customer's cost - which is certainly a different issue entirely. A lot of small-time provider (like me I'm sure) gain their market share by offering a
flat rate to US destinations, knowing full well that there are 1.6 million destinations and that the cost is most certainly not flat. Actually - I'm sure you know this since FonicaTec offers their Penny service (not to say that I consider FonicaTec small-time). Offering a service like that is a wager that the traffic will be balanced with an emphasis on the 80% of destinations who's cost is far below $0.01, and much less emphasis on the 20% that are $0.02-$0.04/min. (If FonicaTec has a flat-rate provider that they resell for the Penny route, than it is that upstream provider making the wager but someone's doing it.+) In this case, if the small-time provider wants to increase his margins in those rural areas, he needs to fine an upstream provider that is local to those rural destinations and get their rate tables in his LCR engine.
+Any large provider offering a flat-rate will provide a guideline for 'normal' traffic that qualifies for their flat-rate. Take
www.gafachi.com - these guys are a large scale us provider. They might even qualify as a proper carrier here, yet they offer a tiered flat-rate.
http://www.gafachi.com/d/2341974/xUdpvYLsRuelydoa/1/0/prod/product/wholesale_voip_termination/ shows 100,000-1,999,999 min/month at $0.080, but below that is a
http://www.gafachi.com/d/2341974/xUdpvYLsRuelydoa/2/0/prod/product/standard_usage_guidelines/ inside which you'll see that things are not so simple. It says that no more than 0.04% of calls can be to a "Tier 8" destination as defined by
http://www.gafachi.com/sd/gafachi_tier_2009_10_28.zip, and that guy has 140,000 rows - a mere 6-digit table.
In this table 1 901 201 2121 (0.0049 and 0.0043 in my example above) is only 0.0057 above 100,000 min/month and so is 1 901 201 1212 - their margin (as you can see) is enough to cover the difference. I'll admit, we learned about this - not through the small print, but because our traffic didn't fit their guidelines and our projected costs didn't match our actual costs. We called gafachi support and they explained it to us. Welcome to Telecom they said.
I digress. Joe - bottom line. I understand your fears. I'm just more scared of the alternative. Building A2Billing to compensate for the potential mistakes in rate tables at the cost of properly supporting LCR seems to me a mistake - a mistake I am perfectly willing to help try to fix if my case is well stated enough to warrant a repair... I'm happy to provide whatever knowledge I have to get this 'right'. I'm no php dev - I'd be embarassed for areski to see my php scripts that I use instead of Access to build my 1.4 million row ratecards (64M!), then my bash scripts that use split to break them them up into the 65 999k csv's so that I can load them into A2Billing within their 1000k upload limit. That is per-provider. (You can see how being able to use a 140,000 row 6-digit ratetable could be something I'd want to pursue. Imagine if your cc_ratecard table had 4.2 million rows!)
Now I reiterate my apologies for length above and hope that people are willing to read my diatribe.