[Spce-user] Prefix matching mode crashes with long numbers (mr6.5.3)

[Rene Krenn]

Both issues fixed for upcoming versions.

br

 

Von: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Rene Krenn
Gesendet: Montag, 18. Februar 2019 10:37
An: 'Henk' <henk at voipdigit.nl>; spce-user at lists.sipwise.com
Betreff: Re: [Spce-user] Prefix matching mode crashes with long numbers (mr6.5.3)

 

> Then there is still a problem with the UI, it always inserts a "." in the source field if you leave the field empty.

I believe too meanwhile.

Thanks for pointing; will report back when the issues are fixed, both oft hem should be minor.

regards

 

Von: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Henk
Gesendet: Montag, 18. Februar 2019 10:30
An: spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com> 
Betreff: Re: [Spce-user] Prefix matching mode crashes with long numbers (mr6.5.3)

 

Hi Rene,

Then there is still a problem with the UI, it always inserts a "." in the source field if you leave the field empty.

Regards,
Henk

On 18-2-2019 10:12, Rene Krenn wrote:

>So in prefix mode do you still use a REGEX source pattern?

No, to match any source in prefix matching, leave it empty instead of „.“

The form defaults are for regex modes only.

 

> About the get_billing_fee problem, when do you expect a fix?

An unintentional casting is happening, presumably because of missing quotes at some point.

Not this sprint, i presume.

 

br

 

Von: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Henk
Gesendet: Montag, 18. Februar 2019 09:54
An: spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com> 
Betreff: Re: [Spce-user] Prefix matching mode crashes with long numbers (mr6.5.3)

 

Hi Rene,

My question was about the source pattern, as I first suspected this had something to do with the error. I uploaded a csv with empty source pattern, but when editing the rate the GUI fills in "." which is a REGEX pattern. So in prefix mode do you still use a REGEX source pattern, or is prefix mode only for the destination?

About the get_billing_fee problem, when do you expect a fix?

Regards,
Henk

On 17-2-2019 21:41, Rene Krenn wrote:

Hi,

 

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

Thx for pointing.

 

> 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"?

This is the default for destination, kept to not change the behaviour with (legacy) .csv uploads.

For fee match modes other than regex, some dedicated destination (pefix) needs to be provided anyway to make sense.

 

regards 

 

Von: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Henk
Gesendet: Sonntag, 17. Februar 2019 20:00
An: spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com> 
Betreff: [Spce-user] Prefix matching mode crashes with long numbers (mr 6.5.3)

 

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 <mailto:31652222222 at 0.0.0.0> ','80131201111111 at 1.1.1.1 <mailto: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/pipermail/spce-user_lists.sipwise.com/attachments/20190220/c5b3c5be/attachment-0001.html>