Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Bronze

IPCC Enterprise Disaster Recovery

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!

3 REPLIES
Blue

Re: IPCC Enterprise Disaster Recovery

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.

andy - berbee

Bronze

Re: IPCC Enterprise Disaster Recovery

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?

Blue

Re: IPCC Enterprise Disaster Recovery

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 :)

andy - berbee

122
Views
0
Helpful
3
Replies