[OpenSIPS-Users] Fraud Detection Module

[Liviu Chircu]

Hi Benjamin,


There is already a rare concurrency issue reported by Guillaume a few 
months ago [1], while item number 3) is already on GitHub [2].  I'm 
trying to schedule a half-day of work soon, so I tick off all of these, 
along with analysing your test cases.  FWIW, 2.2 -> 2.4 fraud_detection 
code is almost identical.


Cheers,


[1]: https://github.com/OpenSIPS/opensips/issues/1389
[2]: https://github.com/OpenSIPS/opensips/issues/890

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 10.10.2018 18:22, Benjamin Pasquet wrote:
> Hello,
>
> I have some questions about fraud detection module and more 
> particulary about the sequential call statistics.
> I am actualy in opensips version 2.2.2 but I tried in 2.2.4 and 2.2.7, 
> and I don't understand well behavior what I see on each version.
>
> 1) First, in relation to the behavior of the sequential call 
> statistics, I will give you an exemple to try to explain what I 
> expected and what I found.
>
> I have this following rules :
>
> ruleidprofileidprefix...
> 1100000033
> 2100000044
> 3200000033
> 4200000044
>
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 0 to 1.
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 1 to 2.
> User 10000 call the 0044123456789, I do check_fraud(10000, 
> 0044123456789, 10000), who match with the rule 2, the sequential call 
> counter of the rule 2 goes from 0 to 1.
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 2 to 3 --> I was expecting that the 
> counter to go back to 1 cause the last number called by this user is 
> different.
> User 10000 call the 0033987654321, I do check_fraud(10000, 
> 0033987654321, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 3 to 4 --> I was expecting that the 
> counter to go back to 1 for the same reasons than the previously case, 
> and further, for this rule and prefix, le number called is different, 
> that's why I was expecting even more that the counter to go back to 1
>
> User 20000 call the 0033123456789, I do check_fraud(20000, 
> 0033123456789, 20000), who match with the rule 1, the sequential call 
> counter of the rule 3 goes from 0 to 1.
> User 20000 call the 0033123456789, I do check_fraud(20000, 
> 0033123456789, 20000), who match with the rule 1, the sequential call 
> counter of the rule 3 goes from 1 to 2.
>
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 4 to 5 --> For this user, this prefix, 
> le called number is different than the previous one called, I was 
> expected that the counter to go back to 1 even if another user have 
> called this number just previously.
>
> For summarize, I was expected that the counter is reset per user for 
> all its rules, from the time the number called by the user is 
> different from the previous one.
>
> 2) Secondly, the FRAUD statistics are daily reset, but which parameter 
> are concerned?
> Total calls
> Calls per minute
> Concurrent calls
> Number of sequential calls
> Call duration
>
> 3) Thirdly and the last point, is it possible to set a value for a 
> parameter rule who permit to don't check this one? Like set the 
> warning and critical parameter values of the sequential call to -1 for 
> a rule for exemple (I have find this supposition into the mailing list).
>
> Thank you in advance for your answer,
> Best regards, Benjamin
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181016/17f491f6/attachment.html>