[Spce-user] Billing fee selection by rate-o-mat

[Julian Seifert]

Hi,

sorry for highjacking this thread but there was something I was wondering about the billing/rating process.
Have you considered instead of utilizing a regex engine (which is cpu hungry) to utilize a multibit-trie
or n-ary tree for determining the billing zone. (memory hungry)

I know it's way less powerful tan regex but at least for us (and I might think this would 
be the same for a lot of others too) we have big prefixtables (Dialcode prefixes) with about
20-40 thousand entries which very exactly map phonenumber to the respective billingzone.

(We currently use a n-ary (n=10 as in 0-9) tree with Leafs pointing to the billingzone. 
so there is prefix 4915 which would be processed to 4->9->1->5 in the tree and pointing to "German mobile" billing zone. 
And for example when a mobile number (49151123456789) appears in cdr as destination it's 4 numeric comparisons and array access to determine the billingzone for the call. I hope I explain it well enough for you to get the gist of it. 
 

I'm asking because I am wondering how the internal ratingsystem using regexpressions performs when facing hundreds to thousands of entries and having tens of thousands of calls per day.  I am quite hesitant to load our dialcodes as regexpressions into the system ;) (having about 20k regexpressions and rating calls against it sounds quite scary - but I'm totally not sure about it and only curious if there is experience regarding the scaling of the rating system) 

kind regards,

  Julian
________________________________________
Von: Spce-user [spce-user-bounces at lists.sipwise.com]" im Auftrag von "Rene Krenn [rkrenn at sipwise.com]
Gesendet: Mittwoch, 11. Mai 2016 14:39
An: Barry Flanagan; manwe at sipdoc.net
Cc: spce-user at lists.sipwise.com
Betreff: Re: [Spce-user] Billing fee selection by rate-o-mat

sry, didnt want to shock anyone;

i just looked at the code again; the corresponding logic in rate-o-mat
is covered by the query below:

"SELECT id, source, destination, ".
                "onpeak_init_rate, onpeak_init_interval, ".
                "onpeak_follow_rate, onpeak_follow_interval, ".
                "offpeak_init_rate, offpeak_init_interval, ".
                "offpeak_follow_rate, offpeak_follow_interval, ".
                "billing_zones_history_id, use_free_time ".
                "FROM billing.billing_fees_history WHERE billing_profile_id = ? ".
                "AND bf_id IS NOT NULL AND type = ? ".
                "AND direction = ? AND ? REGEXP(source) AND ? REGEXP(destination) ".
                "ORDER BY LENGTH(destination) DESC, LENGTH(source) DESC LIMIT 1"

so it sorts by pattern stringlength and picks the first (longest) fee
that matches the sip uri.

for Jons example, i.e. 34677705188 will match

1. ^34[6-7][0-9]+ (the longest regexp that matches, longer than
^34677705188 !)
2. if 1. wouldn't exist it would take ^34677705188
3. if 2. wouldn't exist it would take .*

the reason why it still happens that the third .* is applied by come
from the source match pattern of the fee - as you see in the query both
have to match.

Jon, can you give complete examples of your 3 fee records?

regards, rene



_______________________________________________
Spce-user mailing list
Spce-user at lists.sipwise.com
https://lists.sipwise.com/listinfo/spce-user