Design Flaw or Am I Missing Something?

[RShrove]

With centralized call processing, if a branch site loses WAN connectivity, the HQ site, where the CCM resides, can no longer reach a branch phone user by dialing the users 4 or 5 digit DN. CCM has no way of learning of the WAN failure.

If the remote site were its own cluster & the clusters were joined by a trunk then gateway redundancy could resolve this problem.

If we were merely low on bandwidth between HQ & the branch site AAR could resolve the problem.

But if the WAN connection goes down & the remote site is not a separate cluster, it is my understanding there is no solution. HQ users who call the remote site will probably go straight to voicemail.

The remote site doesn't have a problem; SRST will kick-in for them. They can maintain full functionality.

Am I missing something or is this a CCM design flaw?

[Erick Bergquist]

What about having backup/redundant WAN links?

When the WAN goes down, there data also goes down.

Even if the remote site was it's own cluster, a inter-cluster trunk needs to traverse over a IP network to get there and if IP connectivity to them is down it don't work.

I can see where this could be viewed as a CCM issue, but it can also be viewed as a network design issue also.

[ptalbot]

I haven't tested this, but you bring up an interesting point with AAR. Using locations based call admission control, you might be able to accomplish this by lying to CM about available bandwidth, but I doubt it could be done automatically. You could go into CM (manually upon learning of WAN failure) and change the bandwidth settings to tell CM that it doesn't have enough bandwidth between the locations to make a call, at that point, AAR could dial around. I realize this is not very elegant, but could work in the event of extended WAN outage.

[JOSE TORRES]

This is something that has been brought up before and has been sent up to Cisco to attempt to come up with a solution.

This is one big reason for having the PSTN connectivity terminate at the same site as the phones. This way outside callers will always be able to get to them when SRST kicks in.

[mamoss]

I agree, this has been an ongoing issue for several years. It is generally only a problem where incoming calls are centrally located.

I have raised several feature requests to Cisco suggesting somekind of fail detection whereby if all phones at an SRST site fail to register, assume there is an IP WAN failure and push the calls out/in via PSTN. Of course this will only work if the remote site has PSTN access and DDIs allocated.

[rbradfield]

I seem to remember the way round this is to have route patterns for the remote sites which adds the full number(prefix to the extension number) and goes out the local gateway. when connection across the wan is lost , the phones are no longer registered to the callmanager, so it will use the route pattern instead.

HTH

Richard

[tpetzold_2]

Well to answer the original question. You understanding is correct CallManager can't detect the WAN failure and will send all calls to voicemail. The users would have to manually dial the full phone number. As to whether this is a design flaw would depend on who you ask. I think the developers would tell you that this is not something CallManager was ever supposed to do so it's not a feature. You make up your own mind.

As for Richards comment this might work until CallManager 4.0. In 4.0 the phone's extension is never removed from the digit analysis table even when the phone unregisters so CallManager will always match the phones DN and never match the route pattern. That's progress for you!

[RShrove]

Thank you all for responding. All you responses have been helpful.