cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2020
Views
18
Helpful
10
Replies

Unity connection call forward to specific mailbox via pstn

kkhanis
Level 4
Level 4

Hi guys,

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:

  1. Set the Phones to manually forward a call (Call Not Answered) by manually updating this field to a pilot number in Unity Connection
  2. Set the line to preserve the original called number and redirected number (using the  Forwarded Call Information Display on Device section)
  3. 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.

Kamran

3 Accepted Solutions

Accepted Solutions

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

See http://www.cisco.com/en/US/customer/docs/voice_ip_comm/connection/8x/requirements/8xcucsysreqs.html#wp262764

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.

Hailey

View solution in original post

Rob Huffman
Hall of Fame
Hall of Fame

Hi Kamran,

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

friendly

Integrating Voice Mail with Cisco Unified SRST

http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/srst/configuration/guide/srs_mail.html#wp1345580

Cheers!

Rob

View solution in original post

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.

View solution in original post

10 Replies 10

David Hailey
VIP Alumni
VIP Alumni

Kamran,

You are concerned about losing VM at a remote site in the case of a WAN outage right?  So, in that scenario your remote sites would be in SRST mode. Your plan requires you to manually set call forwarding configurations on the phones presumably in WAN sites (or that's how I read this).  However, if the WAN is down and these sites have no connection to CUCM then the call forward configurations would not be applied as the phones would be registered to an SRST gateway.  Maybe I'm reading your plan wrong - if so, just clarify for me and I'll be glad to think it through further.

The best immediate way to get redundancy for WAN sites for voicemail is by implementing SRSV (Survivable Remote Site Voicemail).  SRSV provides redundant VM service for remote sites.  For example, in a WAN outage where sites cannot access a centralized Unity Connection system then SRSV provides backup VM services, Automated Attendant, or Call Handler services in SRSV mode.  It requires additional licensing and hardware but looks like this:

Central site - CUCM, Unity Connection, and SRSV-UMG installed in an ISR router(s) (UMG stands for Unified Messaging Gateway).

Remote site - SRSV-CUE module (Cisco Unity Express) installed in ISR router

The UMG handles VM provisioning between central and remote sites as well as upload of VM for the remote site to the central location once the WAN is restored.  Check it out here:  http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps5745/ps10769/data_sheet_c78-600182.html

Hailey

Please rate helpful posts!

Hi David,

Thanks a lot for the quick response. You are right, the sites will be in SRST...but we can set the CFNA using the "call-forward noan" on the ephone DN couldnt we?

The SRSV you suggest is very helpful but the only issue is that it needs cucm ver 8.0 at the minimum. So until we upgrade, could we possibly make use of this CFNA?

Thanks again,

Kamran

Actually...instead of call-forward noan, we could use the "alias" command to implement cfna:

alias 1 74545 to 74545 cfw 2128875551 timeout 12

This would provide ephone specific cfna instead of a global forwarding.

Any idea if this is practical?

Regards,
Kamran

For SRSV, you're right - it does require CUCM 8.0 but not Unity Connection 8.0.  You can run it with Unity Connection 7.1(3); however, you lose some functionality there (specifically AA, I believe).

OK - so you're talking about doing something locally on the SRST gateways.  I will assume you have staff onsite that would be able to do this.  Personally, my first thought is that operationally it is likely to be more pain than gain.  However, whether it works or not will depend.  For example, do you have a PRI or just POTS lines for SRST at remote sites.  If it's good ol' POTS, you may need to look further at whether or not you're going to be running into ANI/RDNIS/CLID preservation issues here.  I'm also thinking of utilization of the resources you have in SRST - you don't want to unnecessarily tie up all of your lines if you can avoid it.  The primary focus in SRST (IMO) should be provide a way for callers to at least call out during an outage and if you can give them more than that then that's good but the hope would be that the WAN outage is relatively short.

I'm not saying your idea won't work - but there things you need to consider for sure (such as how analog will perform with redirection).  This isn't something that I'd want to get into but that doesn't mean it's wrong, either.

Hailey

You are right David, it would be a bit complicated even more since its PRI (RDNIS preservation etc). What about using Unity Connection 7 warm standby model? The voicemails would be backed up by DRF right?

The only issue I see in that is we will need to shut down the whole cluster if the branch goes down and we need to bring up the warm standby server...

Thanks again for the the advice...has been most helpful!

Regards,

Kamran

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

See http://www.cisco.com/en/US/customer/docs/voice_ip_comm/connection/8x/requirements/8xcucsysreqs.html#wp262764

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.

Hailey

Rob Huffman
Hall of Fame
Hall of Fame

Hi Kamran,

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

friendly

Integrating Voice Mail with Cisco Unified SRST

http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/srst/configuration/guide/srs_mail.html#wp1345580

Cheers!

Rob

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.

Thanks a lot for the detailed response David! Most helpful.

Regarding the voicemail in case of SRST...the issue with our pri links is that the Telco provider messes with the RDNIS so we wont be able to forward the call to the proper mailbox...but we could set up interview handlers to possibly get the caller to manually reach the proper voicemail (doubt that would be the best solution). This was the reason I was trying to setup cfna for each specific ephone that registers on SRST to forward to a dedicated Alternate Extension local to the voicemail system.

Thanks Rob!

Regarding the voicemail in case of SRST...the issue with our pri links  is that the Telco provider messes with the RDNIS so we wont be able to  forward the call to the proper mailbox by globally forwarding the calls to voicemail...but we could set up interview  handlers to possibly get the caller to manually reach the proper  voicemail (doubt that would be the best solution).

This was the reason I  was trying to setup cfna for each specific ephone that registers on  SRST to forward to a dedicated Alternate Extension local to the  voicemail system.

Thanks again!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: