I was looking at different disaster scenarios for a unity connection setup and had a question regarding one of them.
For a scenario where branches to a callmanager cluster are connection via WAN, usually it is not feasible to pay for the high WAN requirements to implement unity connection clustering over WAN (20ms latency and min 58mbps). In this case if we deploy our unity connection cluster on our central datacentres, we are vulnerable to losing voicemial in case of WAN failures on our branch sites.
As a way around it, I was thinking in case of this situation, if we could do the following:
- Set the Phones to manually forward a call (Call Not Answered) by manually updating this field to a pilot number in Unity Connection
- Set the line to preserve the original called number and redirected number (using the Forwarded Call Information Display on Device section)
- Create Routing Rules in unity connection in its Forwarded Routing Table to forward this call to its specific mailbox.
I know this would require us to manually put the forward on the line incase of such an outage...but it would still give us some kind of voicemail availability.
What are your thoughts on this? Has anyone ever implemented something similar or foresees any issues?
Any piece of advice would be extremely appreciated.
Thanks in advance.
Thanks Rob (5 back at you). I intended to point this out in my previous thread but forgot. My original message was to say that use of POTS imposes some issues. However, PRI is a bit easier to ensure things will be preserved. In either case, I still don't think it's an optimal solution but...you need to determine the real requirement and the best solution for you.
I just wanted to add one reference to the great help from Hailey (+5 D-Man)
Because you are using a PRI for your remote/Branch site(s) this becomes a fair bit more
Integrating Voice Mail with Cisco Unified SRST
I don't really see the Warm Standby redundancy model as the ideal solution for providing voice mail services when a single branch/remote office goes down. Here is how warm standby works:
To use a warm-standby server as your disaster recovery model, you:
•Install a spare Cisco Unity Connection server at a remote or disaster recovery location without populating the database on the server.
•Use the Disaster Recovery System to back up Connection data on the currently active server, and store the backups at the remote or disaster recovery location.
•In the event of a disaster, restore the backup to the warm-standby Connection server at the remote or disaster recovery location and activate that server.
You can use a warm-standby server as a temporary replacement either for a single server or for an entire Connection cluster. If you have a warm-standby server as a backup to a Connection cluster, activate the warm-standby server only when both servers in the cluster are unavailable.
In your scenario, let's say a remote site loses WAN connectivity but all other sites are up and running fine. Your proposal would be to actually bring down voice messaging for all other sites by shutting down the centralized cluster and turning up a warm standby server to accommodate a single remote site. The length of the outage for everyone would be the amount of time it takes you to do a DRS restore and get the warm standby server up and running. Conversely, once the remote site's WAN connectivity is restored then you would be bringing down voice messaging services again during the time it takes you to get the centralized cluster up and running and healthy again.
If you ABSOLUTELY need to provide voice messaging redundancy for your remote sites then my 3 best suggestions at the moment would be as follows (listed in no particular order):
1) Consider Unity Connection 8x. The requirement for clustering between buildings (still not technically referred to as clustering over WAN) have been reduced quite a bit. RTT time latency cannot be more than 150ms. BW guidelines are as follows:
Depending on the number of voice messaging ports on each Connection server, the path of connectivity must have the following guaranteed bandwidth with no steady-state congestion:
–For 50 voice messaging ports on each server—7 Mbps
–For 100 voice messaging ports on each server—14 Mbps
–For 150 voice messaging ports on each server—21 Mbps
–For 200 voice messaging ports on each server—28 Mbps
–For 250 voice messaging ports on each server—35 Mbps
2) Consider a UC 8x solution with CUCM 8x and CUC 8x and implement SRSV. I think this warrants serious consideration given the nature of your questions.
3) Consider having a standalone voicemail solution locally for remote sites. It may be cost prohibitive but you may stand up a local Unity Connection server and then use digital networking to provide a unified directory amongst all servers. Alternatively, you may just run CUE (Unity Express) locally at every site. I don't particular like this option primarily because it increases the operational and administrative costs of the systems as a whole. It could also end up being quite costly and a bit overboard given other alternatives.