Here's a weird one. For me anyway.
I'm configuring custom prompts for a CUE AA. When I set the business open/closed hours I get the "closed" greeting, even though I'm the designated open time frame. When I clear out the schedule and have nothing marked as closed, it plays correctly.
I've checked the times/dates on CUCME and CUE and they are accurate.
Solved! Go to Solution.
Are you sure your marking the correct open hours, when you select the hours in the schedule these are hours that the business is open. They greyed out is the hours that are closed.
When you clear the schedule it means that the system does not depend on the schedule and is always open.
From your statement it sounds to me like you may have mixed this up.
"When I clear out the schedule and have nothing marked as closed"
Hope this helps, if so please rate below.
Alright.... have you checked the AA script to ensure that your greetings are mapped to the appropriate variable. Sorry if i'm being very basic but I want to cover everything.
I'm using the default script and just changing the prompts. I've attached screen shots of the AA config and the Business schedule. In the screen shot I have it set for "systemschedule" which has every block listed as open. The screen shot of the schedule is for the tailored one that did not work during working hours.
So, the AABody.wav file say "thanks for calling, press "1" dial by extension..." etc. This was recorded by me. The Closed.wav should only play during the "closed" hours on the schedule. If I change the config to use the new schedule (the one in the screen shots), the "Closed.wav" file plays first, then the AABody.wav.
Your config looks fine. Have you listened to the AABusinessOpen.wav to ensure that the recording is accurate to it's purpose.
Have you changed the aa.aef script parameters with CUE Script Editor?
could you send your aa.aef file?
I've verified the recordings and have not changed the aa.aef script. I've had to do that before and I try to stay away from doing that if I can. I'm using the default script that is part of CUCME, which can't be downloaded.
I think that may be it. I'm getting reports that vm messages are 12 hours off. The clock via the web GUI is correct. CLI on CME is correct, but on the CUE CLI I think it may be off. At say, 1:30 pm it will say:
01:30:24 EDT, etc...
It doesn't specify am or pm, so I'm assuming it's a 24 hour clock. I tried to find an easy way to adjust the time setting but I can't find it. Is there a way to adjust the CUE clock manually?
CUE doesn't really have an internal clock to set. It gets all its clocking from the (configured) NTP server. It uses that time and its configured timezone to generate its local time stamps.
So it's a matter of figuring out the timezone on CUE and where it's getting its clocking from.
I set the CME router as the NTP master and have CUE pointing to that for the time. I need to reload the module but have not been given a maint window to do that yet.
I'm hoping that will take care of it.
Thanks for all the help.
Reloading CUE will cause it to fully resync to the NTP server (and basically your only option if things are out of sync and not getting better on their own). There were some issues pre-CUE2.0 that I seem to remember, but since then I think it's been stable. I'd question whether something "unusual" happened (maybe the time or NTP config on the CME was changed, or the CUE's NTP server settings or timezone settings changed without reloading, etc). There's a few 'show ntp...' commands on CUE that can help you see if it's getting anything from the NTP server. There's also a 'trace ntp all'. It'll show you NTP packets sent & received. You can pretty much let that one run and periodically do a:
show trace buff long | inc "ntp ntp"
to see what's happening.
I didn't have CME set as the ntp master, which was probably the "unusual" thing. So I fixed that and pointed CUE to it. We'll see how things are after a reload.
Do you know if just reloading CUE will do the trick, or should I reload the whole router?
Just reloading CUE will be fine. Actually (little-known fact) issuing the 'reload' command from the router doesn't actually reload CUE. It just reloads the router. So that won't work at all.