Has anyone come up with a good DR plan for when your remote site loses connectivity to the Central Controller? For example, we have a CallManager cluster in Chicago that all phone devices for the contact center register to. The agents sitting at these devices logon to PG's that are also located in the Chicago cluster facility. These PG's then communicate back to the central controller located in Cincinatti. We recently experienced a loss of connectivity between Chicago and Cincinatti which meant we could no longer deliver ICM calls to the Chicago skill groups. This scenario would be ok if it were to last only a few minutes but in this case we were down for hours and were unable to deliver calls for that period of time. We've tossed around some solutions such as building temporary hunt groups or delivering directly to extensions, but obviously neither is a very good solution, especially in a large enterprise contact center. This particular Chicago facility contains many different lines of business and call types. Maintaining some type of DR hunt group would be a nightmare in and of itself. I'd be curious to hear any other suggestions and whether or not anyone has struggled with this same issue. Cisco offers up a parent/child solution in 7.0, however I find it particularly weak in what it offers. It's essentially like building a self contained ICM at each of your locations. This increases scripting and goes away from the heart of what IPCC is all about in my opinion which is centralized queuing. Thanks for any insights/opinions/suggestions!
Yeah. You are correct, there is no clean solution. Have you thought about splitting the central controllers between Chicago and Cincinnati? If connectivity to the central controller is lost, there honestly is no clean "queuing" solution. If you have a local IVR, you could have the forward failure, busy, and no answer of your dialed number route to a locally registered IVR Route Point that triggers a script to still allow the callers to select which skill group they want to talk to. However, as you stated its a lot of extra scripting but really your only option?
Have you thought about adding another WAN connection or ISDN dial-backup? If you don't have voice over this backup connection, and just need to pass ctios control traffic and ipcc control traffic, it could probably handle it.
Sorry, I should have been a bit clearer in our setup. The central controller is actually in 2 locations, Cincinatti and Lexington. Also, we have a fairly sophisticated WAN architecture with diverse routes into each building in Chicago. I think our biggest concern is a local fiber cut in the Chicago area or something to that affect.
I'm curious about the local IVR. Yes, we do have queue managers in Chicago but I'm curious how I can queue a call to a skill group based on caller selection if the PG can't communicate to the central controller. Maybe you were referring to the Parent/Child setup?
Sorry as well. I wasn't meaning to say you could queue calls. With the Central Controller down you could route calls to a Route Point (not registered to pguser, but just a Jtapi Route point) that sends the calls to an IVR script where callers could still make choices. You would then have to route them to broadcast Hunt Pilots or something. It would give the appearance that nothing was wrong from the customer perspective :)
This would interesting idea....you could have the callers come into this IVR script, use the "Call Hold" step > then the "Place Call" step to place a call to a broadcast group that had agents. The agents would answer the phone and be prompted by the IVR to "enter any digit to accept this call" or something similar. The agent could enter the digit and then "terminate" that contact in the IVR script and redirect the call to that extension immediately. That way the customer just hears MOH during this process and not a bunch of ringback. A decent amount of confguration, but it would work :)
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...