Cisco Unity Troubleshooting Guide, Release 3.1(2)
Internal and External Calls

Table Of Contents

Internal and External Calls

About Problems with Internal and External Calls

Cisco Unity Is Not Answering Any Internal and/or External Calls

The Phone System Settings Are Incorrect

Cisco Unity Was Not Restarted After an Exchange Shutdown and Restart

The COM Port Is Unavailable to Cisco Unity (Serial Integrations Only)

Corruption in Windows ACM Causes Callers to Hear Reorder Tone or Dead Air Shortly After Cisco Unity Startup

The Phone System Is Not Generating a Ring Signal (Circuit-Switched Systems Only)

Cisco Unity Is Not Answering Some Internal or External Calls

Hunt Groups Are Programmed Incorrectly

Routing Rules Are Not Working Correctly

The Number of System Key Ports Is Incorrect

Calls Are Sent to the Wrong Cisco Unity Ports

A Port Is Disabled or Set Incorrectly

A Phone Line or Voice Card Is Not Working


Internal and External Calls


About Problems with Internal and External Calls

Call problems fall into two categories:

No internal or external calls are answered

Problems that prevent internal calls from being answered are a subset of problems that prevent external calls from being answered. See the "Cisco Unity Is Not Answering Any Internal and/or External Calls" section.

Some internal or external calls are answered

If you determine that the problem occurs only with some internal or external calls, see the "Cisco Unity Is Not Answering Some Internal or External Calls" section.


If you encounter a call problem that is not described in this chapter, contact the Cisco Technical Assistance Center (TAC).

Cisco Unity Is Not Answering Any Internal and/or External Calls

There are several possible reasons that Cisco Unity may not answer any internal and/or external calls. In this section, possible causes are listed in order, from most likely to least likely to occur:

The Phone System Settings Are Incorrect

Cisco Unity Was Not Restarted After an Exchange Shutdown and Restart

The COM Port Is Unavailable to Cisco Unity (Serial Integrations Only)

Corruption in Windows ACM Causes Callers to Hear Reorder Tone or Dead Air Shortly After Cisco Unity Startup

The Phone System Is Not Generating a Ring Signal (Circuit-Switched Systems Only)

The Phone System Settings Are Incorrect

When the phone system settings in the Cisco Unity Administrator do not match the type of phone system that Cisco Unity is connected to, Cisco Unity may not answer calls.

To verify the phone system settings in the Cisco Unity Administrator


Step 1 In the Cisco Unity Administrator, click System > Switch.

Step 2 In the Set Active Switch Type section, verify all values.

Step 3 Correct any incorrect values for the phone system.

Step 4 If you changed values in Step 3, click Save.

Step 5 Shut down and restart Cisco Unity.


Cisco Unity Was Not Restarted After an Exchange Shutdown and Restart

When you shut down and restart Microsoft Exchange on the Cisco Unity server, Cisco Unity may need to be restarted manually.

The COM Port Is Unavailable to Cisco Unity (Serial Integrations Only)

Serial traffic during a Windows startup may result in Windows assigning the COM port to a Microsoft Ballpoint Serial Mouse, thus making it unavailable to Cisco Unity. When Windows starts, it searches for the pointing device (usually a mouse). If a serial mouse is detected, Windows disables the port so that a device driver for the mouse can load instead. If a device is not detected, Windows disables the port. A disabled COM port does not display any information in Control Panel > Ports.

If the serial integration was working correctly before shutting down and restarting the Cisco Unity server, but not after, perform the following procedure to determine if the COM port is available.

To view COM port assignments


Step 1 Go to Control Panel > Ports.

Step 2 Confirm that the COM port connected to the serial cable, usually COM 1, is listed in the Ports box.

If the COM port for the serial integration is listed, skip to "The Phone System Is Not Generating a Ring Signal (Circuit-Switched Systems Only)" section.

If the COM port for the serial integration is not listed, continue with Step 3.

Step 3 On the Windows Start menu, click Run. Enter Regedit and click OK.

Step 4 Click Hkey_Local_Machine > Hardware > Description > System > MultifunctionAdapter.

Step 5 Click folder 4, 5, or 6 and locate the SerialController folder.

Step 6 The SerialController folder contains folders with a single digit numeric designation (0, 1, and so on). Click the folder that corresponds to the serial integration COM port number.

Step 7 Double-click the Identifier key in the folder you chose in Step 6. If the Identifier key Value Data is Microsoft Ballpoint Serial Mouse, instead of a COM port (COM1, COM2, and so on), continue with the next procedure, To disable the detection of devices on COM ports in Windows.


To disable the detection of devices on COM ports in Windows


Step 1 Make a backup copy of the Boot.ini file.

Step 2 Remove the Hidden, System, and Read-only attributes from the Boot.ini file.

Step 3 Using a text editor (such as Notepad) open the Boot.ini file.

Step 4 Add the /NoSerialMice option to the end of each entry in the [operating systems] section of Boot.ini. The /NoSerialMice option is not case sensitive. See the following list for syntax options.

/NoSerialMice

Disables the detection of serial mice on all COM ports.

/NoSerialMice:COM<x>

Disables the detection of serial mice on COM<x>, where < x> is the port number.

/NoSerialMice:COM<x,y,z>

Disables the detection of serial mice on COM<x, y and z> ports.


Sample Windows Boot.ini file with /NoSerialMice option added:

[boot loader]
   timeout=3
   default=multi(0)disk(0)rdisk(0)partition(1)\WINNT35
[operating systems]
   multi(0)disk(0)rdisk(0)partition(1)\WINNT35="Windows NT Workstation
      Version 3.51" /NoSerialMice
multi(0)disk(0)rdisk(0)partition(1)\WINNT35="Windows NT Workstation
      Version 3.51 [VGA mode]" /basevideo /sos /NoSerialMice

Step 5 Save the Boot.ini file and exit the text editor.

Step 6 Restore the Hidden, System, and Read-only attributes to the Boot.ini file.

Step 7 Shut down and restart Windows.


Corruption in Windows ACM Causes Callers to Hear Reorder Tone or Dead Air Shortly After Cisco Unity Startup

A few sites have experienced a problem when using both G.711 and G.729a codecs with Cisco Unity. The problem occurs shortly after Cisco Unity starts. Calls received immediately after startup are answered, but within a few minutes, Cisco Unity stops answering calls.

This problem occurs only under the following conditions:

When transcoding between G.729a and G.711 codecs is required in a Cisco Unity system. This includes any instances of G.729a prompts, messages, or greetings, even if Cisco Unity is in a G.711 region. The possibility that this problem can exist on a G.711 system has not been completely ruled out.

When there are identical sequences of Miu wave errors in the Event log from more than one port at the same time, beginning with:

Component Miu: Thread 0x<NUM> had a Failure on Port X in AvWav

There will usually be four to six of these errors from one port intermingled with an identical sequence of four to six errors from another port. Errors from other ports may also be present.

When the problem occurs within a few minutes of system startup, and when it can be consistently reproduced. In other words, restarting the Cisco Unity server eliminates the problem temporarily, but it reoccurs. If a problem with similar symptoms occurs days after startup, or is sporadic, it is likely a different problem.

When Cisco Unity transcodes wave formats, it uses Microsoft Windows ACM (Audio Compression Manager) to call into the third-party G.729a codec. When multiple threads call into the Windows ACM function AcmStreamConvert() at the same time, they can conflict with one other and generate errors, causing callers to hear dead air or the reorder tone. Restarting the Cisco Unity server clears the corruption in Windows ACM temporarily, but it does not prevent the problem from reoccurring.

An application-level workaround, an optional registry setting, makes Windows ACM globally thread-safe. To enable the registry setting, do the following procedure, To enable the ForceGlobalAcmThreadSafety registry setting.

The procedure is not required on all systems that use transcoding. Because it can have a performance impact, it should be done only if all of the conditions listed above are present.

To enable the ForceGlobalAcmThreadSafety registry setting


Step 1 Start Regedit.


Caution Changing the wrong registry key or entering an incorrect value can cause the server to malfunction. Before you edit the registry, confirm that you know how to restore it if a problem occurs. (Refer to the "Restoring" topics in Registry Editor Help.) Note that a typical backup of the Cisco Unity server does not back up the registry. Also note that for a Cisco Unity failover system, registry changes on one Cisco Unity server must be made manually on the other Cisco Unity server, because registry changes are not replicated. If you have any questions about changing registry key settings, contact Cisco TAC.

Step 2 If you do not have a current backup of the registry, click Registry > Export Registry File, and save the registry settings to a file.

Step 3 Expand HKEY_LOCAL_MACHINE\Software\ActiveVoice.

Step 4 On the Edit menu, click New Key.

Step 5 Name the new key UnityAvWav.

Step 6 Click the new UnityAvWav key, then on the Edit menu, click New Key.

Step 7 Name the new key 1.0.

Step 8 Click the new 1.0 key, then on the Edit menu, click New Dword.

Step 9 Name the new Dword ForceGlobalAcmThreadSafety, and set the Value to 1.

Step 10 Close the Registry Editor.

Step 11 For the settings to take effect, restart the Cisco Unity server.

Step 12 Confirm that the problem does not reoccur within the first few minutes after Cisco Unity restarts. If the problem does reoccur, set the ForceGlobalAcmThreadSafety DWORD Value back to 0, to avoid a system performance impact. Contact Cisco TAC for further assistance.


The Phone System Is Not Generating a Ring Signal (Circuit-Switched Systems Only)

In order for Cisco Unity to answer calls, all ports and trunks must be configured correctly.

To test whether the phone system is generating a ring signal


Step 1 Set up a test phone (Phone 1) for single-line testing. For more information, see the "Troubleshooting Preparation" section on page 1-1.

Step 2 On an extension that is connected to the phone system but that is not connected to Cisco Unity (Phone 2), call Phone 1.

If Phone 1 rings, the phone system recognizes the port and is generating a ring signal.

If Phone 1 does not ring, skip to Step 6.

Step 3 Repeat Step 2 for each extension that is normally connected to Cisco Unity.

Step 4 On Phone 2, dial the access code necessary to get an external line, then call Phone 1.

If Phone 1 rings, the trunk is configured correctly to be answered by Cisco Unity ports.

If Phone 1 does not ring, skip to Step 6.

Step 5 Repeat Step 4 for each extension that is normally connected to Cisco Unity.

Step 6 Verify the phone system programming, and change values as necessary.

Step 7 Confirm that the wiring and the jacks are securely connected.

Step 8 Repeat Step 1 through Step 5.

If Phone 1 rings for each extension tested, the phone system is generating a ring signal and the ports and trunks are programmed correctly.

If Phone 1 still does not ring for each extension tested, contact the phone system vendor.


Cisco Unity Is Not Answering Some Internal or External Calls

There are several possible reasons that Cisco Unity may not answer some internal and/or external calls. In this section, possible causes are listed in order, from most likely to least likely to occur:

Hunt Groups Are Programmed Incorrectly

Routing Rules Are Not Working Correctly

The Number of System Key Ports Is Incorrect

Calls Are Sent to the Wrong Cisco Unity Ports

A Port Is Disabled or Set Incorrectly

A Phone Line or Voice Card Is Not Working

Hunt Groups Are Programmed Incorrectly

Depending on your phone system and whether Cisco Unity failover is installed, do one of the following procedures, as appropriate, to verify the hunt group programming for voice messaging ports on the phone system.

To confirm hunt group programming for voice messaging ports (Cisco CallManager integration without Cisco Unity failover)


Step 1 In Cisco CallManager Administration, click Service > Service Parameters.

Step 2 On the Service Parameters Configuration page, click the server that Cisco CallManager is installed on.

Step 3 In the Configured Services list, click Cisco CallManager.

Step 4 In the Configured Service Parameters list, click ForwardMaximumHopCount.

Step 5 Confirm that ForwardMaximumHopCount is set to a value of twice the number of CallManager ports connected to Cisco Unity. For example, on a 48 port system, the ForwardMaximumHopCount should be set to 96.

Step 6 Confirm that the voice messaging ports are set to forward on both Busy and Ring-No-Answer.

Step 7 Put the first voice messaging port into a Busy state.

Step 8 Set up two test phones. For more information, see the "Setting Up For a Diagnostic Test (Cisco CallManager Integration Only)" section on page 1-2.

Step 9 Access an external line from Phone 2, and call Phone 1. The first available port should take the call.

Step 10 Put the next port into a Busy state, Disable the port you just tested via the Cisco Unity Administrator, and then repeat Step 9.

Step 11 Repeat until all the ports have been tested in a Busy state. When all voice messaging ports are disabled, and the last port is busy, CallManager should do whatever you programmed it to do when all lines are busy, such as forward the call to the attendant number. If this does not happen, change the CallManager programming and repeat the test.


To confirm hunt group programming for voice messaging ports (Cisco CallManager integration with Cisco Unity failover)


Step 1 In Cisco CallManager Administration, click Service > Service Parameters.

Step 2 On the Service Parameters Configuration page, click the server that Cisco CallManager is installed on.

Step 3 In the Configured Services list, click Cisco CallManager.

Step 4 In the Configured Service Parameters list, click ForwardMaximumHopCount.

Step 5 Confirm that ForwardMaximumHopCount is set to a value of twice the number of CallManager ports connected to Cisco Unity. For example, on a 48 port system, the ForwardMaximumHopCount should be set to 96.

Step 6 For the ports on the Cisco Unity primary server, confirm that the voice messaging ports are set to forward on Busy. In addition, for Ring-No-Answer, confirm that the first port on the Cisco Unity primary server is set to forward to the first port on the Cisco Unity secondary server.

For the ports on the Cisco Unity secondary server, confirm that the voice messaging ports are set to forward on Busy. In addition, for Ring-No-Answer, confirm that the first port on the Cisco Unity secondary server is set to forward to the first port on the Cisco Unity primary server.

Step 7 Put the first voice messaging port for the Cisco Unity primary server into a Busy state.

Step 8 Set up two test phones. For more information, see the "Setting Up For a Diagnostic Test (Cisco CallManager Integration Only)" section on page 1-2.

Step 9 Access an external line from Phone 2, and call Phone 1. The first available port for the Cisco Unity primary server should take the call.

Step 10 Put the next port for the Cisco Unity primary server into a Busy state, Disable the port you just tested via the Cisco Unity Administrator, and then repeat Step 9.

Step 11 Repeat until all the ports for the Cisco Unity primary server have been tested in a Busy state. When all voice messaging ports for the Cisco Unity primary server are disabled, and the last port is busy, CallManager should do whatever you programmed it to do when all lines are busy, such as forward the call to the attendant number. If this does not happen, change the CallManager programming and repeat the test.

Step 12 Manually make the Cisco Unity primary server inactive so that the Cisco Unity secondary server becomes active.

Step 13 Repeat Step 7 through Step 11 to confirm hunt group programming on the Cisco Unity secondary server.

Step 14 Manually make the Cisco Unity primary server active so that the Cisco Unity secondary server becomes inactive.


To confirm hunt group programming (circuit-switched phone systems only)


Step 1 Set up a test phone (Phone 1) for single-line testing. For more information, see the "Troubleshooting Preparation" section on page 1-1.

Step 2 Connect Phone 1 to the last line in the first hunt group.

Step 3 Busy every extension in the first hunt group except the last one by using the phone system programming. (The Ports page in the Cisco Unity Administrator does not currently allow busying of individual lines.)

Step 4 From an extension that is connected to the phone system but that is not connected to Cisco Unity (Phone 2), dial the first hunt group pilot number.

If Phone 1 rings, continue with Step 5.

If you hear the busy tone or if Phone 1 does not ring, verify the phone system programming for the first hunt group and change values as necessary, then repeat this step. If Phone 1 still does not ring, contact the phone system vendor.

Step 5 Busy the last extension, so that every extension in the first hunt group is busied.

Step 6 On Phone 2, dial the first hunt group pilot number again.

If you hear the busy tone, the first hunt group is programmed correctly.

If you do not hear the busy tone, verify the phone system programming for the first hunt group and change values as necessary, then repeat this step. If you still do not hear the busy tone, contact the phone system vendor.

For details on programming hunt groups, see the documentation for your phone system.

Step 7 Repeat Step 1 through Step 6 for each hunt group.


Routing Rules Are Not Working Correctly

By default, Cisco Unity does not reject any calls. If routing rules have been changed, Cisco Unity may have been unintentionally programmed to reject some internal or external calls.

To confirm that Cisco Unity routing rules are working correctly


Step 1 On the Windows Start menu, click Programs > Unity > Unity Diagnostic Tool.

Step 2 On the Cisco Unity Diagnostic Viewer screen, click the Configure Micro Traces icon.

Step 3 In the Groups list, click Arbiter.

Step 4 In the Flags list, click Diagnostics 14, 15, and 16.

Step 5 In the Groups list, click Ruler Domain.

Step 6 In the Flags list, click Diagnostic 11.

Step 7 On the Cisco Unity Diagnostic Viewer screen, click Start New Log Files.

Step 8 Reproduce the problem.

Step 9 To view the log files, click Process > AvCsMgr, and then click the Current log file.

Step 10 The selected log file is formatted and displayed in the right pane.

Step 11 To export or save a copy of the log file, click Action > Export list.

Step 12 Name the file and save it to a location of your choice in .txt or .csv format.

Step 13 To turn off the traces set in Step 3 through Step 6, on the Cisco Unity Diagnostic Viewer screen, click Disable All Traces.

Step 14 Click CommServer > TechTools.

Step 15 Open the AvRulerEditor.

Step 16 Click Routing to view the actual conditions of routing rules. Compare the conditions of the routing rules with the information gathered from the diagnostic file to see why a rule is applied to a call.

Step 17 If you need to make a change to a routing rule, in the Cisco Unity Administrator, click Call Management > Call Routing.

Do not use AVRulerEditor to change routing rules. For more information, refer to the "How Call Routing Rules Work" section in the "Call Routing" chapter of the Cisco Unity System Administration Guide. The Cisco Unity System Administration Guide is available on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity31/sag/index.htm.

If you are unable to determine if routing rules are the source of the problem, or if you need assistance interpreting the information in the diagnostic logs or AVRulerEditor, contact Cisco TAC.


The Number of System Key Ports Is Incorrect

When the system key is programmed for fewer voice ports than are installed in the Cisco Unity server, Cisco Unity does not answer calls on the extra ports. (For example, if the voice cards in the Cisco Unity server have 48 ports but the system key is programmed for 24 ports, Cisco Unity will answer calls only on the first 24 ports.)

To verify the number of ports


Step 1 In the Cisco Unity Administrator, click System > Licensing > Licensed Features.

Step 2 Confirm that the Voice Ports value matches the number of ports on the voice cards.

If the values match, continue with the following "Calls Are Sent to the Wrong Cisco Unity Ports" section. If the value is smaller than the number of ports on voice cards in the Cisco Unity server, contact your sales representative.


Calls Are Sent to the Wrong Cisco Unity Ports

If the phone system is programmed to send calls to a port on Cisco Unity that is not configured to answer calls, Cisco Unity will not answer the call. In addition, for systems equipped with certain voice cards, the call will never be dropped. This means the port will not be used again for its designated purpose (for example, turning message waiting indicators on and off) until the Cisco Unity server is restarted.

To confirm that calls are being sent to the correct Cisco Unity ports


Step 1 In the Cisco Unity Administrator, click System > Ports.

Step 2 Note which ports are designated to answer calls.

Step 3 In the phone system programming, confirm that calls are being sent only to those ports designated to answer calls. Change the phone system programming if necessary.

If you have a Cisco CallManager integration, continue with Step 4. For all other integrations, skip to Step 7.

Step 4 Press the Test button on the TSP. If the test fails, the problem is most likely in the CallManager configuration. If the test succeeds, the problem is most likely in the Cisco Unity configuration.

Step 5 If there is no failover CallManager, confirm that the Automatically Reconnect to the Primary CCM on Failover box is not checked.

Step 6 Confirm that Remote Access Connection Manager is disabled.

Step 7 If you make a change to the phone system programming, shut down and restart Cisco Unity to clear any hung ports.


A Port Is Disabled or Set Incorrectly

If a port is disabled or set incorrectly, it will not answer calls.

To confirm that ports are set correctly


Step 1 In the Cisco Unity Administrator, click System > Ports.

Step 2 Verify the settings for each port.

If a port is disabled, uncheck the Disabled Out of Service box to enable it.

If all of the ports are enabled and set correctly, continue with the "A Phone Line or Voice Card Is Not Working" section.

If all of the ports cannot be enabled by using the Cisco Unity Administrator, perform the next procedure, To enable ports in the Registry.


To enable ports in the Registry


Caution Changing the wrong registry key or entering an incorrect value can cause the server to malfunction. Before you edit the registry, verify that you know how to restore it if a problem occurs. Note that a typical backup of the Cisco Unity server does not back up the registry. Refer to the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe for additional information. If you have any questions about changing this registry key setting, contact Cisco TAC.


Step 1 On the Windows Start menu, click Run.

Step 2 Enter Regedit and click OK.

Step 3 If you do not have a current backup of the registry, click Registry > Export Registry File, and save the registry settings to a file.

Step 4 Click Hkey_Local_Machine > Software > ActiveVoice > Arbiter > 1.0 > PortConfiguration > Dev<n>, where <n> is the number of the disabled port.

Step 5 Double-click Capabilities.

Step 6 In the Edit Dword Value window, change the Capabilities to 0xfffffff.

Step 7 While still in the Hkey_Local_Machine > Software > ActiveVoice directory, click Miu > 1.0 > Initialization > Port<n>, where <n> is the number of the disabled port.

Step 8 Change the OfflineStatus to 0x0.

Step 9 Restart Cisco Unity.

Step 10 In the Cisco Unity Administrator, click System > Ports.

Confirm that all ports are enabled. If a port is still disabled, contact Cisco TAC.


A Phone Line or Voice Card Is Not Working

To isolate a problem with a phone line or voice card


Step 1 Swap the phone lines from one jack to another on a voice card.

If the problem follows a phone line, the problem is in the phone line.

Step 2 Swap the phone lines from a jack on one voice card to a jack on another voice card.

If the problem follows a jack, the problem is in the jack.

Step 3 Swap the locations of voice cards.

If the problem follows a voice card, the problem is in the card.

For information on testing Dialogic voice cards, see the "Universal Dialogic Diagnostics Utility" section on page 9-20.


Related section

The "Voice Port Settings" section in the "System Settings" chapter of the Cisco Unity System Administration Guide. The Cisco Unity System Administration Guide is available on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity31/sag/index.htm.