Ok, it seems the UTC theory was right. Quoting from "man gmtime_r":
"The gmtime() function converts the calendar time timep to broken-down
time representation, expressed in Coordinated Universal Time (UTC)".
This is an ugly behavior IMO (to reset counters at 21:00), and we should
consider the timezone-adjusted local time, perhaps using localtime_r().
Does this sound like a more natural behavior to you?
Thanks,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 04.04.2018 16:54, Denis via Users wrote:
Ok, i will check it.
And what about "sequential call"? Should i make TT?
P.S. I will ask you about one thing yet.
Can i detect current 'time' using Opensips script? And compare it someway?
Thank you.
--
С уважением, Денис.
Best regards, Denis
04.04.2018, 15:13, "Liviu Chircu" <[email protected]>:
Did OpenSIPS crash or restart between 0:25 - 3:20? I double checked, and
"total_calls" cannot be reset in another way.
Another possibility is that the code sees GMT time. Since Москва is on
GMT+3, this may well explain the situation: first calls were placed
around 21:25 GMT, then the "total calls" limit was hit. At 0:00, the
counters were reset, so another 29 calls successfully passed through
starting with 0:20.
Let's keep an eye out for the "total calls" metric during normal hours,
for a couple of days, so we confirm the above hypothesis (or not).
Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com/>
_______________________________________________
Users mailing list
[email protected] <mailto:[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
