Testing the application “GotoIfTime,” I realized that Asterisk doesn’t match a midnight range. So, the code below will always unmatch.
GotoIfTime("PJSIP/101-0000000d", "00:00-08:00,*,17-20,dec,Australia/Sydney?match:")
Now, if I set up the time in the way below, the time just matches perfectly.
GotoIfTime("PJSIP/101-0000000d", 12:00-08:00,*,17-20,dec,Australia/Sydney?match:")
I don’t know if the above implementation might match at noon!
Thoughts?
Can I just check that you aren’t making the standard mistake. Could you confirm that your intent is to match four period, corresponding to the early hours on Friday, Saturday, Sunday, and Monday. If you are expecting one continuous period, that is not how it works.
Thanks for your answer @david551.
Yes, my intention is to match from 12:00 a.m to 8:00 a.m every day. The issue here is that Asterisk doesn’t recognize the value 00:00 as midnight.
On my setup in USA it works correctly:
00:00-08:00 matches midnight to 8am
It did not match at 23:55 then it did match at midnight.
12:00-08:00 matched noon to 8am
It did match at 23:57 and also matched past midnight.
12:00-12:15 did not match at 00:05 (12:05AM)
00:15-00:20 matched at 00:16 and not at 00:21
Asterisk Git-master with PJproject 2.11-dev (all the latest and greatest!)
Unrelated to this, but you shouldn’t use the “latest and greatest” PJSIP with Asterisk. There have been cases where a new version requires changes in Asterisk or else issues occur. It is safest to use the bundled version.
I use PJproject 2.11 because it allows passing the security level to Openssl as opposed to setting a global level for the whole server.
Is there a plan to bundle 2.11 with Asterisk?
Yes, it is in progress and being tested.
Ouch! The code re-implements the localtime function, apparently in order to be able to dynamically set the timezone.
It looks to me that the code correctly encodes the the time pattern and correctly accesses the resulting bit maps, based on the struct tm type structure created, but I wonder if it has a problem in its localtime emulation for Southern hemisphere countries, possibly specifically for those with Eastern longitudes (I think there are significant numbers of users in South America; surely some of them must have used the time pattern features, although it would be surprising if you were the first Australian).
The code is a bit difficult to follow because of the way that it (I assume) handles leap years, and a recursive call, so the above is speculation. If you want to try and decipher it for yourself, the main part is at asterisk/localtime.c at master · asterisk/asterisk · GitHub
At what times does this go wrong, as the only time that timezone is accounted for is when the current time is accessed, so if the pattern works in the USA it should work in Australia, but it is possible that some specific times are not encoded properly before being looked up in the pattern.
The pattern 00:00 doesn’t match midnight. Nevertheless, if I configure 12:00, midnight is matched.
You can do the tests setting up the server time zone to “Australia/Sydney” and then restart Asterisk (18.6.0).
I don’t see any new information in your latest posting.
The time of day matches are done modulo 720 two minute intervals, so 12:00-08:00 would be expected to match midnight. What would be more helpful to know is the exact cut-off time.
The way the code works is that it maintains a 24 element array. Each element contains 30 bits, each corresponding to a 2 minute period. This is all done in local time, so is independent of time zone. If it breaks for midnight local time in Sydney, it will break for midnight local time in San Francisco. However that logic all looks right to me. In fact, midnight is the least likely time for this part of the code to get wrong.
When you check a time, it converts the time in what is supposed to be the same way as the system library routine localtime() would, except that it allows a timezone to be provide on every request. This is specified to generate hours between 00 and 23 and minutes between 00 and 59, so midnight is well defined.
The conversion from this to an index into the above array doesn’t seem to be done in any way in which midnight or the first hour would be handled strangely.
That only leaves me with the simulation of localtime being buggy. I can’t really see how it would just get 00:00 (and 00:01) wrong, so I’d have to theorise that the problem is in the daylight saving correction logic or in the interaction of that with the leap year logic.
I’m assuming that your system clock is correct, although normal Linux installations will ensure that.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.