[SOLVED] Time conditions or calendar bug?

ashcortech · January 13, 2019, 11:28pm

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 [9088677778@from-trunk:24] Goto("SIP/VI_30-000087de", "app-daynight,1,1") in new stack
-- Goto (app-daynight,1,1)
-- Executing [1@app-daynight:1] GotoIf("SIP/VI_30-000087de", "0?ext-local,vmu2001,1:timeconditions,6,1") in new stack
-- Goto (timeconditions,6,1)
-- Executing [6@timeconditions:1] Set("SIP/VI_30-000087de", "DB(TC/6/INUSESTATE)=INUSE") in new stack
-- Executing [6@timeconditions:2] Set("SIP/VI_30-000087de", "DB(TC/6/NOT_INUSESTATE)=NOT_INUSE") in new stack
-- Executing [6@timeconditions: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 [6@timeconditions:4] GotoIf(“SIP/VI_30-000087de”, “0?truegoto”) in new stack
– Executing [6@timeconditions:5] ExecIf(“SIP/VI_30-000087de”, “0?Set(DB(TC/6)=)”) in new stack
– Executing [6@timeconditions:6] Set(“SIP/VI_30-000087de”, “DEVICE_STATE(Custom:TC6)=INUSE”) in new stack
– Executing [6@timeconditions:7] ExecIf(“SIP/VI_30-000087de”, “0?Set(DEVICE_STATE(Custom:TCSTICKY)=INUSE)”) in new stack
– Executing [6@timeconditions:8] GotoIf(“SIP/VI_30-000087de”, “1?ivr-6,s,1”) in new stack
– Goto (ivr-6,s,1)
– Executing [s@ivr-6:1] Set(“SIP/VI_30-000087de”, “TIMEOUT_LOOPCOUNT=0”) in new stack
– Executing [s@ivr-6:2] Set(“SIP/VI_30-000087de”, “INVALID_LOOPCOUNT=0”) in new stack
– Executing [s@ivr-6:3] Set(“SIP/VI_30-000087de”, “_IVR_CONTEXT_ivr-6=”) in new stack
– Executing [s@ivr-6:4] Set(“SIP/VI_30-000087de”, “_IVR_CONTEXT=ivr-6”) in new stack
– Executing [s@ivr-6:5] Set(“SIP/VI_30-000087de”, “__IVR_RETVM=”) in new stack
– Executing [s@ivr-6:6] GotoIf(“SIP/VI_30-000087de”, “0?skip”) in new stack
– Executing [s@ivr-6: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 [s@ivr-6:8] Wait(“SIP/VI_30-000087de”, “1”) in new stack
– Executing [s@ivr-6:9] Set(“SIP/VI_30-000087de”, “IVR_MSG=custom/closedivr1”) in new stack
– Executing [s@ivr-6:10] Set(“SIP/VI_30-000087de”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [s@ivr-6: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

ashcortech · January 13, 2019, 11:47pm

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

BAD CALL:

-- Goto (app-daynight,1,1)
-- Executing [1@app-daynight:1] GotoIf("SIP/VI_30-000087de", "0?ext-local,vmu2001,1:timeconditions,6,1") in new stack
-- Goto (timeconditions,6,1)
-- Executing [6@timeconditions:1] Set("SIP/VI_30-000087de", "DB(TC/6/INUSESTATE)=INUSE") in new stack
-- Executing [6@timeconditions:2] Set("SIP/VI_30-000087de", "DB(TC/6/NOT_INUSESTATE)=NOT_INUSE") in new stack
-- Executing [6@timeconditions: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 [6@timeconditions:4] GotoIf(“SIP/VI_30-000087de”, “0?truegoto”) in new stack
– Executing [6@timeconditions:5] ExecIf(“SIP/VI_30-000087de”, “0?Set(DB(TC/6)=)”) in new stack
– Executing [6@timeconditions:6] Set(“SIP/VI_30-000087de”, “DEVICE_STATE(Custom:TC6)=INUSE”) in new stack
– Executing [6@timeconditions:7] ExecIf(“SIP/VI_30-000087de”, “0?Set(DEVICE_STATE(Custom:TCSTICKY)=INUSE)”) in new stack
– Executing [6@timeconditions: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 [1@app-daynight:1] GotoIf("SIP/VI_30-000087e0", "0?ext-local,vmu2001,1:timeconditions,4,1") in new stack
-- Goto (timeconditions,4,1)
-- Executing [4@timeconditions:1] Set("SIP/VI_30-000087e0", "DB(TC/4/INUSESTATE)=INUSE") in new stack
-- Executing [4@timeconditions:2] Set("SIP/VI_30-000087e0", "DB(TC/4/NOT_INUSESTATE)=NOT_INUSE") in new stack
-- Executing [4@timeconditions: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 [4@timeconditions:4] GotoIf(“SIP/VI_30-000087e0”, “0?truegoto”) in new stack
– Executing [4@timeconditions:5] ExecIf(“SIP/VI_30-000087e0”, “0?Set(DB(TC/4)=)”) in new stack
– Executing [4@timeconditions:6] Set(“SIP/VI_30-000087e0”, “DEVICE_STATE(Custom:TC4)=INUSE”) in new stack
– Executing [4@timeconditions:7] ExecIf(“SIP/VI_30-000087e0”, “0?Set(DEVICE_STATE(Custom:TCSTICKY)=INUSE)”) in new stack
– Executing [4@timeconditions: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?

ashcortech · January 13, 2019, 11:57pm

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.

tonyclewis · January 14, 2019, 12:11am

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.

tm1000 · January 14, 2019, 1:43am

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.

ashcortech · January 14, 2019, 11:31am

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?

ashcortech · January 14, 2019, 11:45am

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?

tm1000 · January 14, 2019, 2:59pm

It was in calendar.

system · January 21, 2019, 2:59pm

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