Jean-Michel Hiver
2006-Jan-17 16:55 UTC
[Asterisk-Users] How do you deal with subprefixes with LCR?
Hi List, I am working on least cost routing code on the moment, and I am stumbling on a problem. Say you have provider A having: Prefix XXX 0.10 Prefix XXXYYY 0.20 And provider B having Prefix XXX 0.15 You're stuck, because you cannot decide if provider B's "XXX" prefix also covers XXXYYY numbers or not. If it doesn't, it would be a waste to try and contact it. Or maybe worse, you might be dialing a destination which /does/ work but is not displayed in the rates list and could be billed a lot more. At the moment, the way I am dealing with this is by trying the longest prefixes first. So in this case, the preference order would be: Prefix XXXYYY 0.20 (Provider A) Prefix XXX 0.10 (Provider B) Prefix XXX 0.15 (Provider C) However there is also a problem with this approach. Say a 'provider C' comes along with the following price list: Prefix XXXX 0.30 Prefix XXXX 0.30 Prefix XXXX 0.30 Now some 'XXXX' numbers might be chosen first when potentially provider A's 'XXX' prefixes were cheaper! Any ideas on how to deal with this? Cheers, Jean-Michel.
Peter Bowyer
2006-Jan-17 23:24 UTC
[Asterisk-Users] How do you deal with subprefixes with LCR?
On 17/01/06, Jean-Michel Hiver <jhiver@ykoz.net> wrote:> Hi List, > > > I am working on least cost routing code on the moment, and I am > stumbling on a problem. > > Say you have provider A having: > > Prefix XXX 0.10 > Prefix XXXYYY 0.20 > > And provider B having > > Prefix XXX 0.15 > > > You're stuck, because you cannot decide if provider B's "XXX" prefix > also covers XXXYYY numbers or not. If it doesn't, it would be a waste to > try and contact it. Or maybe worse, you might be dialing a destination > which /does/ work but is not displayed in the rates list and could be > billed a lot more.I guess you need to determine each provider's rate for the route in question separately using the 'longest first' algorithm, then compare the rates you've found. Deal with the 'doesn't cover routes not specifically listed' issue as an attribute of the provider. Or a dummy catch-all at $99.99/min which your code knows never to select. In the end, if the provider doesn't give sufficient information about their charges for routes not specifically listed, there's not much you can do... Peter -- Peter Bowyer Email: peter@bowyer.org Tel: +44 1296 768003 VoIP: sip:peter@bowyer.org VoIP: *5048707000@sipbroker.com FWD: **275*5048707000 VoipTalk: **473*5048707000
Quoting Jean-Michel Hiver <jhiver@ykoz.net>: I don't think there is any way around this problem. This is more a question of the terms of the agreement between both parties as to what happens if a particular number was matched by a prefix not listed in the providers A-Z. A provider must list all the prefixes for every charging zone and the rates should be based only on their list of prefixes. My personal view is that providers should apply some diligence and present as detailed a list of prefixes as they can. I believe that on strict legal grounds alone they are bound by the prices attached to the prefixes. It can be problem when some users of your service find out that some numbers such as premium numbers are undercharged and put as much traffic as they can through your service until it is spotted. In this case you would have done no wrong nor benefited from it, so why should you bear the losses? I think providers should be accountable for these problems. The only solution to this is to obtain a more comprehensive list of prefixes from other providers and interpolate the missing ones into your providers rate card with comparable rates or disable your providers trunk on those prefixes. You will suffer less abuse and if the provider jacks you up for the correct rates, you would have been compensated somewhat. If you have some problems implementing the solution I have described, contact me off list> Hi List, > > > I am working on least cost routing code on the moment, and I am > stumbling on a problem. >You should have stumbled on to this problem quite a while ago. :)> Say you have provider A having: > > Prefix XXX 0.10 > Prefix XXXYYY 0.20 > > And provider B having > > Prefix XXX 0.15 > > > You're stuck, because you cannot decide if provider B's "XXX" prefix > also covers XXXYYY numbers or not. If it doesn't, it would be a waste to > try and contact it. Or maybe worse, you might be dialing a destination > which /does/ work but is not displayed in the rates list and could be > billed a lot more. > > At the moment, the way I am dealing with this is by trying the longest > prefixes first. So in this case, the preference order would be: > > Prefix XXXYYY 0.20 (Provider A) > Prefix XXX 0.10 (Provider B) > Prefix XXX 0.15 (Provider C) > > > However there is also a problem with this approach. Say a 'provider C' > comes along with the following price list: > > Prefix XXXX 0.30 > Prefix XXXX 0.30 > Prefix XXXX 0.30 > > > Now some 'XXXX' numbers might be chosen first when potentially provider > A's 'XXX' prefixes were cheaper! > > Any ideas on how to deal with this? > > Cheers, > Jean-Michel. > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.