Hi, Rick!
"drop_requests - Returns the number of requests dropped even before
entering the script routing logic."
Looking at the code, this seems to be false, since the "drop requests"
may also get bumped on each forward() failure (no corresponding socket,
bogus proto, missing proto module,
Hi list!
I cannot find any reason why the Drop_requests statistic is increasing. There
is nothing which correlates in the logs, and also nothing in my PCAP's. (Well
obviously there is traffic in my pcap, just nothing out of the ordinary when
the spikes occur.)
Also no other statistics are spiki
The more I think about it, the more "call duration" makes sense as it is
now. If you want to force a shorter dialog lifetime, there is no need
to duplicate this logic into check_fraud() -- you can already achieve it
by setting custom $DLG_timeout values.
Ideally, we should be able to one or m
As for me, it is not solve the problem, if we will still talking about 'per call' criteria.For example. I set 10 "total calls" with 600 seconds of the "call duration". Your idea will give us 100 minute of successful calls. Not such many for minutes, but may be a lot in money. But, if it is difficul
Thank you for this quick answer.
Guillaume MONTASSIER
De : Users de la part de Liviu Chircu
Envoyé : mercredi 13 juin 2018 13:07:20
À : users@lists.opensips.org
Objet : Re: [OpenSIPS-Users] Fraud module strange behavior
On a side note, the good news is that
Hi Volga,
How large is the presentity data set in your system ? I'm asking as the
routine that seems to be slow queries the presentity table in order to
get the expired presentities - this is done with or without clustering.
Still, in clustering, all the nodes are doing this query, putting ext
Hi Michael,
Thanks for the information.
The printing msg shows that the src and dst IPs are correct.
Maybe a better approach will be to for me to try to reproduce this crash
- is it possible for you to reduce to a cfg file and a HEP packet that
produces the crash, so I can troubleshoot it ?
Hi Tito,
The resume route has no context of the transaction, nor message -> so
the bflags are not available. Still, the event carries all the
information about the new branch to be injected, so you can reach to the
flags via the $avp(bflags) variables - this will keep the bitmask with
all the