[Spce-user] LCR not working

[Mark van Herpen]

Hi Andrew, others,

On 03/25/2015 04:35 PM, Andrew Pogrebennyk wrote:
> That is all fine, the lcr rules and gws are cached

> This is the rule you defined with an empty callee prefix, callee and
> caller pattern.

> With perform_peer_lcr: 'yes' kamailio-proxy is working with the
> billing.billing_fees and billing_fees_history tables directly.

OK, thnx. Now it's clear to me that looking at the lcr_* tables wasn't
the right direction :).

> The dispatches error in the log you can ignore, I believe there's a
> solution posted somewhere on the list.

OK, I will ignore that. However, I can't find any solution on the list
about this. (Neither in my own mailbox, or at Google with a search on
site:lists.sipwise.com "Failed to load dispatcher entries" or
site:lists.sipwise.com ds_get_index()

> Do you see anything in the MySQL query log about billing_fees?

No, I only see a query for each peer on the billing_fees_history table:

SELECT id, 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 = 4 AND bf_id IS
NOT NULL AND type = 'call' AND direction = 'out' AND
concat('316<SNIP-DESTNR>','@','<SNIP-DESTDOMAIN>') REGEXP(destination)
AND concat('<SNIP-SRCNR>','@','<SNIP-SOURCEDOMAIN>') REGEXP(source)
ORDER BY LENGTH(destination) DESC, LENGTH(source) DESC LIMIT 1

This query is done 3 times, each time with a different
billing_profile_id which is according with the 3 peers I've configured I
guess.

This gives a result like this:

*************************** 1. row ***************************
                      id: 28363
             destination: ^31
        onpeak_init_rate: 0
    onpeak_init_interval: 1
      onpeak_follow_rate: 0.2
  onpeak_follow_interval: 1
       offpeak_init_rate: 0
   offpeak_init_interval: 1
     offpeak_follow_rate: 0.2
 offpeak_follow_interval: 1
billing_zones_history_id: 2380
           use_free_time: 0
1 row in set (0.00 sec)

The other two billing_profile_id's (2 and 3) give these result:
*************************** 1. row ***************************
                      id: 28362
             destination: ^31
        onpeak_init_rate: 0
    onpeak_init_interval: 1
      onpeak_follow_rate: 0.3
  onpeak_follow_interval: 1
       offpeak_init_rate: 0
   offpeak_init_interval: 1
     offpeak_follow_rate: 0.3
 offpeak_follow_interval: 1
billing_zones_history_id: 2379
           use_free_time: 0
1 row in set (0.00 sec)
*************************** 1. row ***************************
                      id: 28361
             destination: ^31
        onpeak_init_rate: 0
    onpeak_init_interval: 1
      onpeak_follow_rate: 0.1
  onpeak_follow_interval: 1
       offpeak_init_rate: 0
   offpeak_init_interval: 1
     offpeak_follow_rate: 0.1
 offpeak_follow_interval: 1
billing_zones_history_id: 2378
           use_free_time: 0
1 row in set (0.00 sec)


So there is no query on the billing_fee table, as far as I can see. Is
this needed?

After that, the peer is used that was first queried. Each time a
different billing_profile_id is queried first, so one of the 3 peers is
'randomly' chosen.

If you need more info, please let me know.

Grtz,

Mark van Herpen