[Spce-user] Prefix matching mode crashes with long numbers (mr 6.5.3)

[Henk]

Hi all,

Just did a test with billing fees defined in prefix mode instead of 
regex_longest_match with I normally use (and works fine but slow). I 
noticed an error in the proxy log:
Feb 17 17:36:31 spce proxy[6234]: NOTICE: <script>: Load gws matching 
calling part 'sip:31652222222 at 0.0.0.0' and called user '80131201111111' 
and called part 'sip:80131201111111 at 1.1.1.1:5060' - 
R=sip:8013120111111 at 1.1.1.1:5060
Feb 17 17:36:31 spce proxy[6234]: ERROR: 
(src/swr_aux.c:133:swr_vqueryf_dbh_tx) - MySQL error code is 1690
Feb 17 17:36:31 spce proxy[6234]: ERROR: 
(src/swr_aux.c:142:swr_vqueryf_dbh_tx) - MySQL query failed
Feb 17 17:36:31 spce proxy[6234]: ERROR: 
(src/swr_logic.c:526:swr_get_profile_info) - Error executing profile 
info statement: BIGINT UNSIGNED value is out of range in '(_j at 9 - 1)'

Rate-o-mat also stops with an error. I'm using a prefix so that the 
number is 14 characters long, but this is not large enough for a BIGINT 
to get out of range.

 From the query log:
278 Query    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 id = 
billing.get_billing_fee_id('155','call','out','31652222222 at 0.0.0.0','80131201111111 at 1.1.1.1',null)
278 *Query    rollback*

It looks to me like the stored procedure get_billing_fee_id is the 
source of the problem.

I also noticed that the default billing fee source pattern is "." in the 
UI if you save a fee with an empty field. Is this correct for match mode 
"prefix"? I tested this with an empty field and later on inserted the 
default "." again, with the same results.

Regards,
Henk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20190217/2316ef85/attachment.html>