CIPT1: Time of Day Call Routing Question

azaghul

Is there a known problem with Time of Day configuration?

I've set up my Time Periods, I then add the Time Periods to a Time Schedule, but they don't seem to retain their list order when saved. I re-adjust the order, save the schedule again, and the list rearranges it self. According to CBT Nuggets I'd expect the list to retain its order.

My List before saving

TIME_Easter
TIME_Christmas
TIME_BusinessHours

My List after saving

TIME_BusinessHours
TIME_Easter
TIME_Christmas

Time Period Definitions:

TIME_BusinessHours (Mon-Fri, 08:00-17:00)
TIME_Easter (Apr 22 - Apr 25)
TIME_Christmas (Dec 25 - Dec 2[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_cool.gif[/IMG]

According to the CUCM Admin Guide:

• If multiple time periods get associated to a time schedule and the time periods overlap, time periods with Day of Year settings take precedence over time periods with Day of Week settings.
• Time interval settings take precedence over No Office Hour settings for the same day of the year or day of the week.

I've reconfigured the Time Periods to remove "No Office Hour" settings and replace them with 00:00 - 24:00, but the list still gets re-ordered.

Is there a catch to this, or should I just assume (risky) that CUCM knows what it's doing and will process Day of Year before Day of Week even though the list does not show this?

azaghul

Can anyone direct me to some step-by-step examples for inbound calls? Still trying to head around Time of Day routing, there is obviously some part of the configuration I'm failing to understand...

---

8<

---

Ok, now got internal ToD working, so one step forward, one to go.

---

8<

---

Grrrr. The "oddities" of CUCM.

All now working, either my inbound CSS or changes to a configuration step were not being recognised. Talk about traps for new players.

You only learn so much when something works, but you learn so much more when something doesn't.

pitviper

hehehe, I always forget to hit the reset device button after config changes. This will more often then not bite you later (especially with MGCP gateways). When something seems off now the first thing that I do is reboot all CUCM VMs via the CLI as well as the gateways. I've had a bunch of odd issues (you'll uncover things that you didn't know to look for when you start going through TUC - replication issues and so on) which all seem to stem from putting the VMs in standby and firing them back up later (when they think that everything has been connected all along).

azaghul

Yeah, could have sworn I'd reset the devices. Oh well, we learn by our mistakes, learn more actually.

I've noticed some of those VM standby issues already, system time goes out the window for a start, and I'm only running a single node at this stage. Its shutdown and restart (not a simple reboot) the VMs. When I get to CIPT2 I think it'll be time to power up my IBM/MCS servers, could be less problems.