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

[Rene Krenn]

Hi,

6.5 will introduce enhanced fee match modes:

regex_longest_pattern matching mode: (legacy)
  The fee‘s source/destination represent PCREs which both have to match the
source/destination from the
  CDR. The fee with the longest (most distinctive) destination pattern is
picked. If there are multiple, the one
  with the longest (most distinctive) source pattern is picked.

regex_longest_match matching mode:
  The fee‘s source/destination patterns represent PCREs which both have to
match the source/destination
  from the CDR. The fee with the longest match within the destination string
is picked. If there are multiple,
  the one with the longest match within the source string is picked.

prefix matching mode:
The fee‘s source/destination represent strings which both the
source/destination from the CDR have to start with. The fee with the longest
destination prefix is picked. If there are multiple, the one with the
longest
  source prefix is picked. In Contrast to regex_* match modes this one has
an algorithm that uses index lookup, so there will be O(length(src) *
length(dest) * log(#fees)) instead of regex full table scans. This will be
the preferred mode for tens of thousands of fees in place or high throughput
(peer-peer rating) 

exact matching mode:
  Both the source/destination have to match the source/destination from the
CDR exactly. Fastest, O(log(#fees)).

For maximum flexibility, fees with different matching modes can coexist and
therefore have different precedence.

regards

-----Ursprüngliche Nachricht-----
Von: Julian Seifert [mailto:js at dacor.de] 
Gesendet: Donnerstag, 12. Mai 2016 14:57
An: Julian Seifert <js at dacor.de>; Rene Krenn <rkrenn at sipwise.com>; Barry
Flanagan <barry at flanagan.ie>; manwe at sipdoc.net
Cc: spce-user at lists.sipwise.com
Betreff: AW: [Spce-user] Billing fee selection by rate-o-mat

Hi again,

do I understand correctly that it is not really longest _match_ but longest
regular expression that has _a_ match that is being used to determine the
billingzone?
(so If my number is 499561123 and I have ^499561123 as regex and
^(00|\+)4[9][5][6][1][1] (Yes ARTIFICIALLY constructed) the latter one would
be the "best match" albeit the first being a _direct_ one to one match?

kind regards,

  Julian

________________________________________
Von: Julian Seifert
Gesendet: Donnerstag, 12. Mai 2016 14:54
An: Rene Krenn; Barry Flanagan; manwe at sipdoc.net
Cc: spce-user at lists.sipwise.com
Betreff: AW: [Spce-user] Billing fee selection by rate-o-mat

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