[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 XXX0.10 Prefix XXXYYY 0.20 And provider B having Prefix XXX0.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 XXX0.10 (Provider B) Prefix XXX0.15 (Provider C) However there is also a problem with this approach. Say a 'provider C' comes along with the following price list: Prefix 0.30 Prefix 0.30 Prefix 0.30 Now some '' 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
Re: [Asterisk-Users] How do you deal with subprefixes with LCR?
Quoting Jean-Michel Hiver [EMAIL PROTECTED]: 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 XXX0.10 Prefix XXXYYY 0.20 And provider B having Prefix XXX0.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 XXX0.10 (Provider B) Prefix XXX0.15 (Provider C) However there is also a problem with this approach. Say a 'provider C' comes along with the following price list: Prefix 0.30 Prefix 0.30 Prefix 0.30 Now some '' 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. ___ --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
Re: [Asterisk-Users] How do you deal with subprefixes with LCR?
Obelix a écrit : Quoting Jean-Michel Hiver [EMAIL PROTECTED]: 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. I agree. The problem is that to my knowledge, there is no charging zone standard. It would be a lot simpler if there was... 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. Yep. I guess if at least they do a fast-busy on subprefixes which they do not support it would be OK. What's bad is when they make it hang on forever. In my personal experience, VoIPJet has been very bad with this. I wouldn't want the LCR to result in crappy service... 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. And the way I'm doing things now, the LCR is /not/ going to help preventing this kind of stuff... In this case you would have done no wrong nor benefited from it, so why should you bear the losses? Agreed. If providers don't know jack about their own routes then they really ought to do another job... 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. Yeah but in this case, the issue is that all a provider needs to do to be considered cheaper is have a rates table with superfluously long subprefixes... You will suffer less abuse and if the provider jacks you up for the correct rates, you would have been compensated somewhat. Yeah. I think the LCR should definitely at some point have some kind of daemon mode where the tariffs are history recorded so you can make your case with any given provider... but maybe this ought to be another tool. I'll see. If you have some problems implementing the solution I have described, contact me off list I did first do a longest prefix fist algo, and now I have changed it to: a) Make a list of all prefixes from all providers b) For any given prefix, compare the rates which each provider advertises c) Sort all providers per prefix accordingly The solution then for providers to block subprefixes is to apply a ridiculous tariff to them (like $99 per minute or something) and answer with a fast busy on these subprefixes. Cheers, Jean-Michel. 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 XXX0.10 Prefix XXXYYY 0.20 And provider B having Prefix XXX0.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 XXX0.10 (Provider B) Prefix XXX0.15 (Provider C) However there is also a problem with this approach. Say a 'provider C' comes along with the following price list: Prefix 0.30 Prefix 0.30 Prefix 0.30 Now some '' 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. ___ --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 ___ --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
Re: [Asterisk-Users] How do you deal with subprefixes with LCR?
On 17/01/06, Jean-Michel Hiver [EMAIL PROTECTED] 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 XXX0.10 Prefix XXXYYY 0.20 And provider B having Prefix XXX0.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: [EMAIL PROTECTED] Tel: +44 1296 768003 VoIP: sip:[EMAIL PROTECTED] VoIP: [EMAIL PROTECTED] FWD: **275*5048707000 VoipTalk: **473*5048707000 ___ --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
