[Asterisk-Users] How do you deal with subprefixes with LCR?

[Jean-Michel Hiver]

Obelix a écrit :

>Quoting Jean-Michel Hiver <jhiver at 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.
>  
>
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 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.
>
>_______________________________________________
>--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
>  
>