On a side note, the good news is that you can easily bypass this bug
within the event_route: simply ignore any negative "concurrent calls"
reports! Hopefully, it won't take long until we get to the bottom of it,
and provide the official fix.
Cheers,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 13.06.2018 14:04, Liviu Chircu wrote:
Hi, Guillaume!
That definitely looks like a bug. Most likely, we are either talking
about a locking issue, causing too few increments, or a dialog
callback issue, causing too many decrements. Marking this as a bug --
I will try to find some time and review the concerned code asap.
Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 13.06.2018 12:24, Guillaume Montassier wrote:
Hi list,
I have a strange behavior possibly a bug with opensips fraud module.
Sometime an call is block because of a critical threshold on
concurrent calls. The vast majority of the time it work really well.
But sometime, when I raise E_FRD_CRITICAL and check
$var(val);$var(thr) I got something like this -1;31. Meaning that on
a maximum of 31 calls the user is on -1.
I don't get where that -1 came from and why it raise a critical
alert. Also, that -1 appears uniquely on that concurrent calls
parameters, all the others parameters work fine.
Any idea? or tips for debugging?
Thanks,
Guillaume MONTASSIER
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
