ACD Path failover

[Frontline]

Setting up a new customer with several sites. Main site will have an MXeIII as well as the MiCollab server. There will be 4 additional sites, one with an MXeIII and the other 3 with CXII's. Main site will have (3) PRI's and site with the second MXeIII will have (2) PRI's. If main site goes down there will be provisioning in place to route calls to the secondary MXeIII

All phones register to the main site and will fail over to their respective local controllers if they experience any sort of issue.

There will be several ACD groups for sales. service, etc.

My question is...if the main site were to go down how can I route the ACD calls? The agents will fail over to remote sites, but the ACD path programming does not exist in the remote sites. I can't duplicate the ACD path numbers on the remote sites...(DN conflict with path numbers at main site).
I can build a new path and duplicate everything, but then how can I point the calls to the new path numbers?

Not sure where to go with this...any suggeations welcome!

Thank you

[ZuluAlpha]

It's a bit of a pickle with PRI's because if the controller goes down that has the DID of the ACD group on the PRI then you can't handle it with the remote controllers.

You can't duplicate paths, but you can have failover skill groups.

That said you're not completely out of luck. In the past I have had carriers remote call forward lines when PRI's (or controllers on a PRI) go down so other controllers in the cluster can handle it. They've done it up to ten paths, but I'm sure it can be done for higher volumes. If it's an 800 number you may also be able to change the local number it points too relatively quickly. Main DID 3300 might point to the primary ACD path, then failover DID 3301 is on another controller which one would have find a way to route 3300 to.

Some of the carriers now have redundant inbound routes for SIP trunks - not to say those don't fail either though.

[smarbar]

I have just done something similar with SIP trunks. What I did was send the DID to a hunt group which was resilient to the secondary controller and then stop SDS sharing on a subset of call rerouting always entries, on the primary controller create an ACD path and then put that as the location of the call rerouting entry assigned to the hunt group. On the failover controller create a duplicate ACD path and enter that as the destination for the same call rerouting entry.

[Frontline]

Thank you both for the input

If the main controller or the PRI's on that main controller go down, the carrier will have provisioning in place to then route the DID's/calls to the secondary controller so I think we are good with that aspect.

The main concern was then getting the calls to the correct ACD paths if a failover happens.

smarbar -  I think what you propose is a great idea and I will try setting that up with one group today. They have about 12 ACD paths in total so this is going to be a little time consuming but I think this will cover any situations they may encounter

Thank you both again. I truly appreciate it.

[Tech Electronics]

Frontline,

I had a similar issue with a clustered network. I had a vMCD which was the primary controller for all sites. I had two failover controllers that also supported the PRI for that location. I created the ACD Paths at their respective sites, but I created the Agent Groups on the Primary.

That way when the Primary goes down and the agents fail over they are still going to their ACD Path. Of course if the Secondary and Tertiary controllers went down then the ACD Path was gone, but so was their PRI.

Thanks,

TE

[eugenej]

paths need unique numbers on each system. use a hunt group and make it resilient. Use call reroute always. Don't share the reroute for that hunt group (exclude it). So basically you have a different reroute for each system to each corresponding path.
Agent group and agent are resilient. If you are using MiCC for reporting then your reporting number must be the same and you add them to a virtual group on MiCC.

You can also use a speed dial and point it to the respective paths instead of the hunt group. Again don't share the speed dials. Make them unique for each system.

If you have IVR, you can use IVR to make the queues "resilient"