prefixes in a round-robin manner, his "sequential calls" value would never exceed 1"
prefixes in a round-robin manner, his "sequential calls" value would never exceed 1.
,Denis, they all match the same prefix. "810" is the same number match, over and over again, so the sequential calls is not reset. Please fix your number matching if you want it to work differently.
Best regards,
Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.comOn 25.04.2018 17:41, Denis via Users wrote:Hello Liviu!Sorry, for long answer.I do not quite understand07:08 was the first call to 810 prefix from 00:00 where counters, how you mentioned, has been reset.So, after 15 calls i can see, that Opensips drop any calls with appropriate reason ("fraud detected")The only counter that has such value is "sequential_calls_critical". Another counters are long away from this value.Anyway you doubt that "sequential_calls_critical" is the reason of call`s block?Thank you.--С уважением, Денис.Best regards, Denis24.04.2018, 12:41, "Liviu Chircu" <li...@opensips.org>:,Hi Denis,
It is difficult for me to assess your intervals, and triggering reasons. For example, your sheet starts at 07:08 AM, but the counter accumulation is reset way back, at 00:00.
Please provide some actual fraud event logs, with a log such as below, so we can blame the sequential calls for sure:
event_route [E_FRD_CRITICAL]
{
fetch_event_params("$var(param);$var(val);$var(thr);$var(user);$var(number);$var(ruleid)");
xlog("E_FRD_CRITICAL: $var(param);$var(val);$var(thr);$var(user);$var(number);$var(ruleid)\n");
}Best regards,
Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.comOn 24.04.2018 12:06, Denis via Users wrote:Hello Liviu!"Yes, the "sequential calls" holds the size of the last batch of calls
sent to the same number. For example, if a user were to dial 44 and 45
prefixes in a round-robin manner, his "sequential calls" value would
never exceed 1."Here you can find acc from one of the client (from the beginning of the 24.04)and fraud module params looks likeprefix: 810start_hour: 00:00end_hour: 23:59daysoftheweek: Mon-Suncpm_warning: 10cpm_critical: 11call_duration_warning: 1499call_duration_critical: 1500total_calls_warning: 99total_calls_critical: 100concurrent_calls_warning: 25concurrent_calls_critical: 30sequential_calls_warning: 14sequential_calls_critical: 15Something wronge))))As you can see the client dial different numbers but module detects fraud anyway.--С уважением, Денис.Best regards, Denis19.04.2018, 18:14, "Liviu Chircu" <li...@opensips.org>:,Hi Denis!
Good catch! For the first time, I documented a parameter, but forgot to export it for the script writer as well! :)
It is now fixed. Thank you!
Cheers,
Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.comOn 19.04.2018 17:28, Denis via Users wrote:Hello, Liviu!I had installed latest Opensips 2.2 (Opensips 2.2.6)In a log file, during start of Opensips, i can seeERROR:core:set_mod_param_regex: parameter <use_local_time> not found in module <fraud_detection>Where is mistake?Thank you.--С уважением, Денис.Best regards, Denis13.04.2018, 09:49, "Denis via Users" <users@lists.opensips.org>:Ok, thank you--С уважением, Денис.Best regards, Denis12.04.2018, 14:23, "Liviu Chircu" <li...@opensips.org>:,,Use $Ts [1] to get the current UNIX timestamp in seconds.
[1]: http://www.opensips.org/Documentation/Script-CoreVar-2-4#toc91
Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.comOn 12.04.2018 14:08, Denis via Users wrote:Liviu, is there any way to find out current time from Opensips during call processing (some functions, variables etc which i can use in opensips.cfg)?Thank you--С уважением, Денис.Best regards, Denis12.04.2018, 13:50, "Liviu Chircu" <li...@opensips.org>:,Hi Denis,
The fraud detection module has no such mechanism, currently. We could invent some variables such as $frd_last_warn, $frd_last_crit, $frd_first_warn, $frd_first_crit. They would output a UNIX timestamp. If there were no warnings during the current interval, the timestamp value would be 0. Can't think of anything better now - you can polish this idea and open up a pull request if you want.
How many users do you have? The "cachedb_local" offers a fast and configurable hash implementation. Why wouldn't it be a good solution in order to store/fetch the above-mentioned timestamps for each of your users?
Best regards,
Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.comOn 10.04.2018 13:11, Denis via Users wrote:Hello, Liviu!"So you want to check the time of the last fraud detection attempt for a user?"Yes, but not for store this time to anywhere.I want to detect the time of the first fraud call, and if this time, for example, between 19:00 and 09:00, make some actions.Can i do it with Opensips?Thank you.--С уважением, Денис.Best regards, Denis10.04.2018, 12:28, "Liviu Chircu" <li...@opensips.org>:Hi Denis,
Yes, the "sequential calls" holds the size of the last batch of calls
sent to the same number. For example, if a user were to dial 44 and 45
prefixes in a round-robin manner, his "sequential calls" value would
never exceed 1.
So you want to check the time of the last fraud detection attempt for a
user? You can use "cachedb_local", for example, and hold the last fraud
detection timestamp for each user. Also, note that check_fraud() [1] has
some useful return codes (-1 and -2), in case you don't want to use the
E_FRD_ events.
Cheers,
[1]:
http://www.opensips.org/html/docs/modules/2.4.x/fraud_detection.html#func_check_fraud
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 09.04.2018 09:12, Denis via Users wrote:Hello, Liviu!
Thank you very much!
I will try your fix.
And, What does "Sequential calls" mean? These are calls to one number?
So, if we have situation dealing with reset counters, i want to make
one thing.
I want to check the time when fraud has been detected and if this
time, say, after 19:00 make some actions. How can i check time of the
call processing?
Thank you.
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users