Cisco Unified Communications Manager (CallManager)

Document ID: 24816

Contents

Introduction

This document describes the recommended way of configuring the Cisco CallManager in order for Cisco Unity failover to work correctly. This document does not attempt to describe the Enhanced Failover feature of Cisco Unity in full detail, rather to illustrate the important pieces necessary for configuring the Cisco CallManager to take advantage of this feature. For more information about the Cisco Unity Failover feature see the Cisco Unity Failover Guide.

Note: This assumes Cisco Unity version 3.1 or above.

Problem

The Cisco Unity Failover feature is a software-level redundancy mechanism where a secondary Cisco Unity server is ready to take calls if a failure occurs with the primary Cisco Unity server.  Enhanced Failover uses Microsoft SQL replication to transfer configuration settings (not actual call state) from a primary Cisco Unity server to a secondary one. A keepalive mechanism ensures that the relevant services are still running on the primary server. If the primary server fails the secondary is ready to take calls. 

If the Cisco CallManager is not configured correctly to work with this feature, then the failover feature may not work at all or heavy call volume may lead to high CPU use on the Cisco CallManager server.

Note:  This feature is independent of the Unity TSP setting where a Unity server will register with a different CallManager server, if one server goes down. 

Solution

From the Cisco CallManager point of view, each Cisco Unity server is registered to the same Cisco CallManager cluster using different directory numbers (and different port names)*. The first port of the primary Cisco Unity server will be the voicemail pilot number for all users. When things are working correctly, the Cisco CallManager routes the first call to the first voicemail port (on the primary server), if busy it routes to the second port, and so on.  The last port of the primary Cisco Unity server will forward to the first port of the secondary Unity server and trigger a failover, so proper port capacity planning is essential. 

Within the Cisco CallManager, forwarding calls through a large number of forwarding hops in the traditional way is a very CPU-intensive operation.  For this reason, in systems where there are large numbers of voicemail ports or a high rate of inbound calls to voicemail, we recommend setting the advanced call forwarding flag to minimize this problem.   This flag allows the Cisco CallManager to hunt through voicemail ports more efficiently.

This parameter does not affect the number of forwarding hops that can occur by regular IP phones (for example, if a regular IP phone is set to forward to an extension, which is set to forward to another extension, and so on).  Now the number of forwarding hops for regular phones (Forward Maximum Hop Count ) is now configured independently of voicemail forwarding hops (VoicemailMaximumHopCount) in the Cisco CallManager service parameters.

Warning:  The Advanced Call Forwarding flag does change the behavior of the forwarding logic for voicemail ports within the Cisco CallManager.  Specifically, only the call forward no answer setting is consulted when determining which port to forward to (the call forward busy setting no longer matters).  This behavior is described in more detail in the sections below.

The primary advantage of the Advanced Call Forwarding logic is better performance due to lower CPU use on the Cisco CallManager.  The disadvantage is that Cisco Unity cannot failover to its secondary system if an unresponsive port is encountered (for example, the port is still registered with the Cisco CallManager, but it is no longer able to accept a call).  In this case, for every call presented to this port, the caller would hear ringback until the ring-no-answer timer expires.  Then they would be forwarded to the next available voicemail port.  Another drawback may be that when all available ports are used, the next call will forward to the first port of the secondary server and trigger a failover.  This will not cause any call drops, but it does mean that new calls will go to the secondary server and the primary Cisco Unity server will unregister its ports from the Cisco CallManager as users hang up.

Important: Begining in Cisco CallManager build 3.2(2c) Support Patch G, due to CSCdy30248, the forwarding behavior will change. Instead of consulting only the forward-no-answer parameter to determine voicemail forwarding, only the forward-busy parameter will be used. For this reason, it is extremely important to configure the forward-no-answer and forward-busy settings to be the same, so no adverse behavior will occur after an upgrade. With this version of Cisco CallManager, it will be possible to configure the Cisco Unity failover's first line as the forward-no-answer destination for each line on the primary Cisco Unity server. This will trigger a failover when an unresponsive Cisco Unity port is encountered. It can also give the administrator the option not to forward (no answer) the last port of the primary to the secondary server, but instead to a live attendant, if available, thereby only causing a failover if:

• All Cisco Unity ports of the primary become unregistered.
• The primary Unity server encounters a critical failure and misses the keepalives with the secondary server.
• A locked port condition on one of the primary Cisco Unity ports occurs and a caller gets forwarded (after the no-answer timer expires) to the secondary.

Enabling AdvancedCallForwardHopFlag and Changing VoicemailMaximumHopCount

Warning:  Setting the AdvancedCallForwardHopFlag changes the behavior of the forwarding logic for voicemail ports in Cisco CallManager.  A significant side effect is that if, for some reason, a Cisco Unity port is registered but does not accept the call, no Unity failover is triggered.  Instead, after the ring-no-answer timeout, the next available port is searched.  This will occur for every call which is presented to the port which is dead. 

To configure advanced call forwarding, access the Cisco CallManager Administration web page.

1. Select Service > Service Parameters.

   

2. Select a server running Cisco CallManager.

   

3. Click the Cisco CallManager service.



4. Locate the AdvancedCallForwardHopFlag and select True.



5. Select the VoicemailMaximumHopCount and set it to twice the number of available voicemail ports on one server (for example, 2 x 72 ports = 144).  Technically, this could also be the total number of ports used to call into Cisco Unity only (for example, 2 x 68 = 136), but the few extra ports will not be significant to CallManager utilization.

Note:  The ForwardMaximumHopCount should not be changed.  With AdvancedCallForwardHopFlag = True, this parameter only applies to regular, non-voicemail forwarding.  So to keep the CPU in check the default setting, 12 is recommended.

Note:  The VoicemailMaximumHopCount may be less than twice the number of voice ports if you do not want all the Cisco Unity ports be used to route calls to Unity.  For example, if the last 10 ports on both the primary and secondary Cisco Unity servers are only configured for outbound dialing and notification (for example, they are not configured to answer in Unity), then the VoicemailMaximumHopCount should be 2 x 62 = 124.

6. Click Update.
7. Click Select Another Server and repeat steps 2 through 6 for each server in the cluster running the Cisco CallManager service.

Important:  Now that the AdvancedCallForwardHopFlag is true, the voicemail ports work differently.  Only the Call Forward No Answer parameter is consulted when deciding where to forward a call.  So when a call is presented to the voicemail pilot number, CallManager scans a list of ports, each port is either in use or not in use.  If a port is not in use, then it is presented with the call.   If it is in use, then it goes to the next sequential port based on the Call Forward No Answer setting (not the Call Forward Busy setting).

When configuring the voicemail ports in the Cisco CallManager for Unity Failover, it is important to configure each Call Forward No Answer number to the next sequential port.  For the last port on the primary server, the Call Forward No Answer number will be configured to be the first port of the secondary Unity server.

What this means is that if all ports on the primary Cisco Unity server are in use, then the CallManager will route the next inbound call to the secondary Unity server which will trigger an automatic failover assuming the "Force Failover If Call Arrives on Inactive Secondary" setting is checked in the Cisco Unity Failover monitor.  This is expected, so proper capacity planning is essential.

Adding Voicemail Ports to Cisco CallManager

In general, it is recommended to place all voicemail port numbers into their own partition, except for the pilot number on the primary server, which needs to be in a partition that all users with access to voicemail can reach (such as the <None> partition). 

From the Cisco CallManager point of view, the calls flow as follows:

In this figure, notice the calls to voicemail are always routed to the primary voicemail port. Often this number is in a generally accessible Cisco CallManager partition and all other ports are in a different partition that cannot be dialed directly from a user phone. This gives the impression of a single voicemail number to call.  This is also very important for the numbers on the Cisco Unity secondary server, since even an accidental call placed to a number on the secondary server would trigger a failover. 

From there the call is either answered by the primary Cisco Unity server or forwarded to the next port of the same server (using the Forward No Answer setting).  If all ports are unavailable (busy, no answer, or not even registered), then the call is forwarded to the first port of the secondary server, where an automatic failover trigger is initiated.  This means that under load, exceeding the total number of free ports on the primary server will trigger a failover (assuming the "Force Failover if Call Arrives on Inactive Secondary" setting is checked in the Cisco Unity Failover monitor) because there is no distinction between a forward based on a busy, no answer, or any other non-idle condition.  What this also means is that if a call is presented to a port that is idle but Cisco Unity is configured not to answer the call (or the port is locked), then the call will be forced to forward no answer after the default 10-second timeout to the next available port.  If multiple ports are in this condition, the user may think that Cisco Unity is not responding and hang up the call.  If neither Cisco Unity system responds, then the call will be forwarded to a live operator extension.

Note:  The last number in the hunt group on the primary/secondary server may not necessarily be the very last port which the system is licensed.  If some ports on the Cisco Unity server are reserved for outbound calls only, then the last port you want Cisco CallManager to use to forward calls to Cisco Unity must have Call Forward No Answer configured for the first port of the secondary Unity server. 

On this server, PriUnity-VI1 is the first port of the primary server. The first port is extension 29100, which is the main pilot number for the voicemail system. The remaining voicemail ports for the primary Cisco Unity server are 12001 - 12071 (there are 72 ports total). In this case, the first port is in the <None> partition so every IP phone can call the number, while the remaining ports are in the MainVoicemail partition, which is only reachable by devices that have the MainVoicemailCSS (Calling Search Space). The CSS for the device is set to RTPUnrestrictedCSS, which has access to a much wider range of numbers and is necessary so calls from Cisco Unity work.

Note: The following screenshots are from Cisco CallManager 3.1.

To add a large number of ports, the easiest is to use the Cisco Voicemail Port Wizard.  Choose the settings such that all ports are in the restricted partition as shown below.

After adding the ports navigate to the first port and change the partition (and possibly the DN) so everyone can call the number.  The reason that the Device Calling Search Space is set to an unrestricted one is so calls initiated by Cisco Unity can have full access to place calls.  This may be different depending on the outbound calling/transfer access you wish to enforce.  The Operator Directory Number will be the Forward Busy/Forward No Answer setting for the last port, so it has been set to the number that will be used as the first port on the secondary Cisco Unity server. Otherwise, this would need be be done manually.

The failover server ports are SecUnity-VIX. It also has 72 ports and the number of the first port must be 12100, as configured in the Forward No Answer field for the primary server's last port. The Forward No Answer number on the secondary server (or the Operator Directory Number if using the Cisco Voicemail Port Wizard) is set to the attendant phone number (0 in this case). If the first number is busy, it tries the second port of the secondary server. In the example below it is forwarded to 12101, the second port of the secondary server, although it might be an attendant's number in case of a failure where both servers are off-line.

Note: All port configuration on both Cisco CallManager and Cisco Unity (Calling Search Spaces and Partitions on the Cisco CallManager and port assignments for dial-in/dial-out/MWI) should be identical for both sets of voicemail ports. In this example, the first voicemail port on the primary server is in the <None> partition, which is available to anyone. All other voicemail ports are in the VMInternalPT partition, which no one can dial except for devices that have the VMInternalCSS.  The first port of the secondary Unity server will also be in the VMInternalPT partition.

Selecting Failover Method with Cisco Unity

For more information about the Cisco Unity Failover Configuration, please see:

• How to Configure the Unity Failover Configuration Wizard.

Each Cisco Unity TSP configuration would be identical, except for the port name. The primary Cisco Unity server would use PriUnity-VI and the secondary server would use SecUnity-VI.

Since the only way Cisco CallManager will route a call to the secondary server is if the ports of the primary Cisco Unity server are unavailable (such as they are unregistered), the Unity failover configuration itself should typically have the "Force Failover if call arrives on inactive secondary" box checked on the Failover server configuration.

1. From the secondary Cisco Unity server, select Start > Programs > Unity > Failover Monitor.
2. Select Configure.
3. Check the Force Failover if call arrives on inactive secondary (this is the default setting).

Note: In normal operating conditions, both the primary and failover servers will register their lines with the Cisco CallManager. The exception is when the failover Cisco Unity server is active, and the primary server becomes available again but is not configured for Automatic Failover/Failback. If it did register its ports, then Cisco CallManager would simply route calls to that number and failback would be initiated.

Related Information

• Voice, Telephony and Messaging Technologies
• Voice, Telephony and Messaging Devices
• Voice, Telephony and Messaging Software
• Cisco Technical Assistance Center (TAC)