I am curious about what would be the best approach to the following scenario:
Two geographically different clusters (CUCM,CCX). ACD calls originally destined to cluster 1 should route to cluster 2 and vise versa in a fail-over scenario or during high call volume/high wait time, etc.
My question is, in order to retain some type of reporting that makes it easily distinguishable this has occurred what would need to be done? My basic instinct tells me nothing super crazy but I am having some doubts so I am just throwing it out there to garnish some ideas from the community.
Please rate useful posts and mark answers as correct if applicable.
Gotcha. If you already have HA enabled over LAN / WAN, then you should be covered from a system failover standpoint. If you haven't already, you should enable DRS and schedule regular backups. But, if you wanted to manually redirect callers during a failover scenario, then you could;
1. Login to CUCM Admin
2. Navigate to Device > CTI Route Point > click 'Find' > select Extension(s) > Call Forward settings
3. Enter a Destination and CSS for "Forward All"
Again, this would be used to redirect all inbound calls during the unlikely event UCCX was completely down. In this case, you would pull CDRs from CUCM to determine the call volume. The other option would be "Forward on CTI Failure" but you could inadvertently redirect callers IF the connection fails. Again, you shouldn't worry about another level of redundancy.
As far as redirecting callers based on current queue times, estimated queue times, or agent availability shouldn't be that difficult. You would simply use the Get Reporting Statistics step to determine the Current Wait Time or Expected Wait Time. Same concept for Logged-In Resources or Ready Resources. With these statistics, you can use IF or Switch Statements to alter the path of the call. If there's too many calls in queue, then go this way.
What happens next, well, that really depends on how you want to report this call event. When a call is queued, the call will be counted as 1x presented. You can 1) dequeue the call which is reported by a couple of CSQ based reports. The reports should present this call event as 1x presented, 0x handled, 0x abandoned and 1x dequeued. Or, you can "mark" the call as handled before you redirect the call via Set Contact Info step. This should be reported as 1x presented, 1x handled, 0x abandoned and 0x dequeued. I don't believe you can "mark" a call as handled after you successfully redirect the call but then again, I haven't confirmed that either.
EDIT: You can also set Call Variables and display this data to the "Call Custom Variable Report". It's another way to track where the call came from.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...