[SOLVED] Time conditions or calendar bug?

This was working fine and all of a sudden it just fails.

I have two Time condition groups: 1) Holiday Hours 2) regular hours
they are linked to calendars Holiday and Open respectively.

Call flow control routes to time condition “Holiday Hours” which tests against the “Holiday” calendar. if it matches it send the call to the “Closed” IVR, if it does not match it sends it on to Time Condition “regular Hours”

Time Condition Regular hours matches against the Open Hours Calendar. If it matches it sends the call to the open hours IVR, if it fails it sends it to the “Closed” IVR.

today the Regular Hours Time Conditions always fails no matter what is in the “Open” calendar.

I know the Holiday Hours Time Condition works because I’ve changed it’s destination and added/removed entries to it’s calendar and it always functions correctly.

I’ve deleted the Open Hours calendar and re-created it, removed the Regular Hours Time Condition and re-created it, Checked the system time… nothing seems to work.

For the test call below, I’ve routed the call flow directly to the regular hours time condition, can anyone show me where it’s going wrong and returning false from the calendar?:

-- Executing [[email protected]:24] Goto("SIP/VI_30-000087de", "app-daynight,1,1") in new stack
-- Goto (app-daynight,1,1)
-- Executing [[email protected]:1] GotoIf("SIP/VI_30-000087de", "0?ext-local,vmu2001,1:timeconditions,6,1") in new stack
-- Goto (timeconditions,6,1)
-- Executing [[email protected]:1] Set("SIP/VI_30-000087de", "DB(TC/6/INUSESTATE)=INUSE") in new stack
-- Executing [[email protected]:2] Set("SIP/VI_30-000087de", "DB(TC/6/NOT_INUSESTATE)=NOT_INUSE") in new stack
-- Executing [[email protected]:3] AGI("SIP/VI_30-000087de", "calendar.agi,calendar,goto,5ed3f552-cce3-406c-bf0a-ec5ab2b0dc1c,default,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/calendar.agi

calendar.agi,calendar,goto,5ed3f552-cce3-406c-bf0a-ec5ab2b0dc1c,default,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==: Checking Calendar
– <SIP/VI_30-000087de>AGI Script calendar.agi completed, returning 0
– Executing [[email protected]:4] GotoIf(“SIP/VI_30-000087de”, “0?truegoto”) in new stack
– Executing [[email protected]:5] ExecIf(“SIP/VI_30-000087de”, “0?Set(DB(TC/6)=)”) in new stack
– Executing [[email protected]:6] Set(“SIP/VI_30-000087de”, “DEVICE_STATE(Custom:TC6)=INUSE”) in new stack
– Executing [[email protected]:7] ExecIf(“SIP/VI_30-000087de”, “0?Set(DEVICE_STATE(Custom:TCSTICKY)=INUSE)”) in new stack
– Executing [[email protected]:8] GotoIf(“SIP/VI_30-000087de”, “1?ivr-6,s,1”) in new stack
– Goto (ivr-6,s,1)
– Executing [[email protected]:1] Set(“SIP/VI_30-000087de”, “TIMEOUT_LOOPCOUNT=0”) in new stack
– Executing [[email protected]:2] Set(“SIP/VI_30-000087de”, “INVALID_LOOPCOUNT=0”) in new stack
– Executing [[email protected]:3] Set(“SIP/VI_30-000087de”, “_IVR_CONTEXT_ivr-6=”) in new stack
– Executing [[email protected]:4] Set(“SIP/VI_30-000087de”, “_IVR_CONTEXT=ivr-6”) in new stack
– Executing [[email protected]:5] Set(“SIP/VI_30-000087de”, “__IVR_RETVM=”) in new stack
– Executing [[email protected]:6] GotoIf(“SIP/VI_30-000087de”, “0?skip”) in new stack
– Executing [[email protected]:7] Answer(“SIP/VI_30-000087de”, “”) in new stack
> 0x7f32cc9d8d10 – Strict RTP switching to RTP target address 45.63.13.137:12390 as source
– Executing [[email protected]:8] Wait(“SIP/VI_30-000087de”, “1”) in new stack
– Executing [[email protected]:9] Set(“SIP/VI_30-000087de”, “IVR_MSG=custom/closedivr1”) in new stack
– Executing [[email protected]:10] Set(“SIP/VI_30-000087de”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [[email protected]:11] ExecIf(“SIP/VI_30-000087de”, “1?Background(custom/closedivr1)”) in new stack
– <SIP/VI_30-000087de> Playing ‘custom/closedivr1.slin’ (language ‘en’)
> 0x7f32cc9d8d10 – Strict RTP learning complete - Locking on source address 45.63.13.137:12390
whitebirchpbx*CLI> exit

Did a further test watching the asterisk logs for both a good and bad call.

BAD CALL:

-- Goto (app-daynight,1,1)
-- Executing [[email protected]:1] GotoIf("SIP/VI_30-000087de", "0?ext-local,vmu2001,1:timeconditions,6,1") in new stack
-- Goto (timeconditions,6,1)
-- Executing [[email protected]:1] Set("SIP/VI_30-000087de", "DB(TC/6/INUSESTATE)=INUSE") in new stack
-- Executing [[email protected]:2] Set("SIP/VI_30-000087de", "DB(TC/6/NOT_INUSESTATE)=NOT_INUSE") in new stack
-- Executing [[email protected]:3] AGI("SIP/VI_30-000087de", "calendar.agi,calendar,goto,5ed3f552-cce3-406c-bf0a-ec5ab2b0dc1c,default,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/calendar.agi

calendar.agi,calendar,goto,5ed3f552-cce3-406c-bf0a-ec5ab2b0dc1c,default,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==: Checking Calendar
– <SIP/VI_30-000087de>AGI Script calendar.agi completed, returning 0
– Executing [[email protected]:4] GotoIf(“SIP/VI_30-000087de”, “0?truegoto”) in new stack
– Executing [[email protected]:5] ExecIf(“SIP/VI_30-000087de”, “0?Set(DB(TC/6)=)”) in new stack
– Executing [[email protected]:6] Set(“SIP/VI_30-000087de”, “DEVICE_STATE(Custom:TC6)=INUSE”) in new stack
– Executing [[email protected]:7] ExecIf(“SIP/VI_30-000087de”, “0?Set(DEVICE_STATE(Custom:TCSTICKY)=INUSE)”) in new stack
– Executing [[email protected]:8] GotoIf(“SIP/VI_30-000087de”, “1?ivr-6,s,1”) in new stack
– Goto (ivr-6,s,1)

GOOD CALL:

-- Goto (app-daynight,1,1)
-- Executing [[email protected]:1] GotoIf("SIP/VI_30-000087e0", "0?ext-local,vmu2001,1:timeconditions,4,1") in new stack
-- Goto (timeconditions,4,1)
-- Executing [[email protected]:1] Set("SIP/VI_30-000087e0", "DB(TC/4/INUSESTATE)=INUSE") in new stack
-- Executing [[email protected]:2] Set("SIP/VI_30-000087e0", "DB(TC/4/NOT_INUSESTATE)=NOT_INUSE") in new stack
-- Executing [[email protected]:3] AGI("SIP/VI_30-000087e0", "calendar.agi,calendar,goto,ab80dde1-5fac-4c60-bbba-8f2da5113524,America/New_York,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/calendar.agi

calendar.agi,calendar,goto,ab80dde1-5fac-4c60-bbba-8f2da5113524,America/New_York,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==: Setting Timezone To: America/New_York
calendar.agi,calendar,goto,ab80dde1-5fac-4c60-bbba-8f2da5113524,America/New_York,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==: Checking Calendar
calendar.agi,calendar,goto,ab80dde1-5fac-4c60-bbba-8f2da5113524,America/New_York,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==: Calendar: False
calendar.agi,calendar,goto,ab80dde1-5fac-4c60-bbba-8f2da5113524,America/New_York,dHJ1ZXN0YXRl,ZmFsc2VzdGF0ZQ==: Goto:falsestate
– AGI Script Executing Application: (Goto) Options: (falsestate)
– Goto (timeconditions,4,4)
– <SIP/VI_30-000087e0>AGI Script calendar.agi completed, returning 0
– Executing [[email protected]:4] GotoIf(“SIP/VI_30-000087e0”, “0?truegoto”) in new stack
– Executing [[email protected]:5] ExecIf(“SIP/VI_30-000087e0”, “0?Set(DB(TC/4)=)”) in new stack
– Executing [[email protected]:6] Set(“SIP/VI_30-000087e0”, “DEVICE_STATE(Custom:TC4)=INUSE”) in new stack
– Executing [[email protected]:7] ExecIf(“SIP/VI_30-000087e0”, “0?Set(DEVICE_STATE(Custom:TCSTICKY)=INUSE)”) in new stack
– Executing [[email protected]:8] GotoIf(“SIP/VI_30-000087e0”, “1?ivr-4,s,1”) in new stack
– Goto (ivr-4,s,1)

seems like in the bad call the calendar module isn’t fully running?

Figured it out. In the Time Condition I had to explicitly set the timezone. The “Bad” Time condition was using the system timezone. Although checking the date/time etc in the linux cli returned the proper time zone and the system admin module also showed the proper time zone, for some reason the Time Condition needed it set.

looking at the field description in Time Condition I shouldn’t have to set this specifically. It says:

Time Zone: Specify the time zone by name if the destinations are in a different time zone than the server. Type two characters to start an auto-complete pick-list.
Important : Your selection here MUST appear in the pick-list or in the /usr/share/zoneinfo/ directory.

This leads me to believe that if the time zone set in system admin is correct, I shouldn’t have to set it here again to the same time zone. Unless of course I’m reading this wrong.

1 Like

That is correct but when setting time zone on the system you need to reboot the box as aoache and asterisk and other things need to be restarted for it to use the new system timezone.

This was a bug identified last week that was resolved Friday. Fix is in edge. Basically the default time zone was sent in as “default” instead of the real default.

Thanks guys, at least I know I’m not crazy.

Andrew, how long typically does it take to go from edge to general release that is picked up in the module admin updates?

Tony, yes I know about the need to reboot after a timezone change in system admin, the thing that threw me is it hadn’t been changed.

Andrew, which module specifically was the bug in? Calendar? Time Conditions? something else?

It was in calendar.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.