Table Of Contents
Troubleshooting Internal and External Calls in Cisco Unity 8.x
About Problems with Internal and External Calls in Cisco Unity 8.x
Cisco Unity 8.x Is Not Answering Any Internal and/or External Calls
Confirming the Phone System Settings
Confirming That Cisco Unity Was Restarted After an Exchange Shutdown and Restart
Enabling the ForceGlobalAcmThreadSafety Registry Setting When Corruption in Windows ACM Causes Callers to Hear Reorder Tone or Dead Air Shortly After Cisco Unity Startup
Confirming That the Phone System Generates a Ring Signal (PIMG/TIMG Integrations Only)
Cisco Unity 8.x Is Not Answering Some Internal or External Calls
Confirming Hunt Groups
Confirming Routing Rules
Confirming Voice Messaging Port Licensing
Confirming Voice Messaging Port Settings
Troubleshooting Internal and External Calls in Cisco Unity 8.x
About Problems with Internal and External Calls in Cisco Unity 8.x
Call problems fall into the following categories:
If you encounter a call problem that is not described in this chapter, contact the Cisco Technical Assistance Center (TAC).
Cisco Unity 8.x 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. Use the "Task List for Troubleshooting No Answers on Incoming Calls" to troubleshoot the possible causes.
Task List for Troubleshooting No Answers on Incoming Calls
1.
Confirm that the phone system settings are correct. See the "Confirming the Phone System Settings" section.
2.
Confirm that Cisco Unity was restarted after an Exchange shutdown. See the "Confirming That Cisco Unity Was Restarted After an Exchange Shutdown and Restart" section.
3.
If callers hear a reorder tone or dead air shortly after Cisco Unity startup, enable the ForceGlobalAcmThreadSafety Registry Setting. See the "Enabling the ForceGlobalAcmThreadSafety Registry Setting When Corruption in Windows ACM Causes Callers to Hear Reorder Tone or Dead Air Shortly After Cisco Unity Startup" section.
4.
(PIMG/TIMG integrations only) Confirm that the phone system generates a ring signal. See the "Confirming That the Phone System Generates a Ring Signal (PIMG/TIMG Integrations Only)" section.
Confirming the Phone System Settings
When the phone system settings in the Cisco Unity Telephony Integration Manager (UTIM) do not match the type of phone system that Cisco Unity is connected to, Cisco Unity may not answer calls.
To Confirm the Phone System Settings in UTIM
Step 1
On the Windows Start menu on the Cisco Unity server, click Programs > Cisco Unity > Manage Integrations. UTIM appears.
Step 2
Confirm that the settings match those indicated in the integration guide for your phone system.
Step 3
Correct any incorrect values for the phone system.
Step 4
If you changed values in Step 3, click Save.
Step 5
If prompted, click OK to restart the Cisco Unity server.
Confirming That Cisco Unity Was 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.
Enabling the ForceGlobalAcmThreadSafety Registry Setting When 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 when all of the following conditions are present:
•
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. When this happens, 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 Audio Compression Manager (ACM) 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 another 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
This 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.
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. (See the "Restoring" topics in Registry Editor Help.) 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 the key 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
Restart the Cisco Unity server for the settings to take effect.
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.
Confirming That the Phone System Generates a Ring Signal (PIMG/TIMG Integrations 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 (PIMG/TIMG Integrations)
Step 1
Determine which line you are having trouble with, and unplug it from the voice card. Locate the lines that connect the phone system to the PIMG or TIMG units, and remove one line from one PIMG or TIMG unit.
Step 2
Plug the line into a test phone (Phone 1).
The extension for Phone 1 will be the extension of the phone system port to which this line connects.
Step 3
On an extension that is connected to the phone system (Phone 2), call Phone 1 (the extension of the phone system port to which this line connects).
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 7.
Step 4
Repeat Step 1 through Step 3 for the remaining lines that connect to the PIMG or TIMG units.
Step 5
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 connect to the PIMG or TIMG units. Continue with Step 6.
If Phone 1 does not ring, skip to Step 7.
Step 6
Repeat Step 5 for the remaining lines that connect to the PIMG or TIMG units.
If Phone 1 rings, the trunk is configured correctly. Skip the remaining steps in this procedure.
Step 7
Verify the phone system programming, and change values as necessary.
Step 8
Confirm that the lines are securely connected to the phone system and to the PIMG or TIMG units.
Step 9
Repeat Step 1 through Step 6.
If Phone 1 rings for each line 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 line tested, contact the phone system vendor.
Cisco Unity 8.x 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. Use the "Task List for Troubleshooting Sporadic Answers on Incoming Calls" to troubleshoot the possible causes.
Task List for Troubleshooting Sporadic Answers on Incoming Calls
1.
Confirm that the hunt group programming is correct. See the "Confirming Hunt Groups" section.
2.
Confirm that the routing rules are working correctly. See the "Confirming Routing Rules" section.
3.
Verify that the number of licensed voice messaging ports is correct. See the "Confirming Voice Messaging Port Licensing" section.
4.
Confirm that calls are sent to the correct voice messaging ports and that the ports are enabled. See the "Confirming Voice Messaging Port Settings" section.
Confirming Hunt Groups
Depending on your phone system and whether Cisco Unity failover is installed, do one of the following procedures, as applicable, to verify the hunt group programming for voice messaging ports on the phone system.
To Verify Hunt Group Programming for Voice Messaging Ports (Cisco Unified Communications Manager Integration, Without Cisco Unity Failover)
Step 1
Set up two test phones. For more information, see the "Preparations for Troubleshooting the Phone System in Cisco Unity 8.x" section on page 1-1.
Step 2
From a phone (not either of the test phones), dial the extension of the first answering voice messaging port, and leave the voice messaging port in a busy state.
Step 3
Access an external line from test Phone 2 and call test Phone 1, but do not answer. The call will forward to the next available answering port, and Cisco Unity should answer the call.
If the call is not forwarded to the next available answering port or if Cisco Unity does not answer the call, confirm that the voice messaging ports and service parameters are configured as described in the applicable Cisco Unified Communications Manager integration guide (at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html), and repeat this step.
If the problem persists for this voice messaging port, see the Cisco Unified Communications Manager documentation at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
Step 4
Release the busy voice messaging port.
Step 5
In the Cisco Unity Administrator, go to the System > Ports page, and disable the answering port you just tested by unchecking the Enabled check box for that port. Then click the Save icon.
Step 6
From a phone (not either of the test phones), dial the extension of the next answering voice messaging port, and leave the voice messaging port in a busy state.
Step 7
Repeat Step 3 through Step 6 until all the answering voice messaging ports have been tested in a busy state. When all answering voice messaging ports are disabled, and the last answering port is busy, Cisco Unified CM should do whatever you programmed it to do when all ports are busy, such as forward the call to the attendant number. If this does not happen, change the Cisco Unified CM programming and repeat the test.
Step 8
When testing is complete, in the Cisco Unity Administrator, go to the System > Ports page, and enable the answering ports you just tested by checking the Enabled check box for each port. Then click the Save icon.
To Verify Hunt Group Programming for Voice Messaging Ports (Cisco Unified Communications Manager Integration, with Cisco Unity Failover)
Step 1
Set up two test phones. For more information, see the "Preparations for Troubleshooting the Phone System in Cisco Unity 8.x" section on page 1-1.
Step 2
On the Cisco Unity primary server, on the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.
Step 3
In the Services section, confirm that the primary server is active and the secondary server is inactive.
Step 4
Click Advanced.
Step 5
Check the Disable Automatic Failover and Failback check box.
Step 6
Click OK to close the Failover Monitor.
Step 7
From a phone (not either of the test phones), dial the extension of the first voice messaging port on the primary server, and leave the voice messaging port in a busy state.
Step 8
Access an external line from test Phone 2, and call test Phone 1. The first available port for the primary server should take the call.
If the call is not forwarded to the next available answering port for the primary server or if primary server does not answer the call, confirm that the voice messaging ports and service parameters are configured as described in the applicable Cisco Unified Communications Manager integration guide (at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html), and repeat this step.
If the problem persists for this voice messaging port, see the Cisco Unified Communications Manager documentation at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.
Step 9
Release the busy voice messaging port on the primary server.
Step 10
In the Cisco Unity Administrator on the primary server, go to the System > Ports page, and disable the port you just tested by unchecking the Enabled check box for that port. Then click the Save icon.
Step 11
From a phone (not either of the test phones), dial the extension of the next answering voice messaging port on the primary server, and leave the voice messaging port in a busy state.
Step 12
Repeat Step 8 through Step 11 until all of the answering voice messaging ports on the primary server have been tested in a busy state. When all answering voice messaging ports are disabled, and the last answering port is busy, Cisco Unified CM will forward the call to the secondary server. If this does not happen, change the Cisco Unified CM programming and repeat the test.
Step 13
On the primary server, on the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.
Step 14
Click Force Inactive.
Step 15
Click OK to confirm. The primary server becomes inactive.
Step 16
On the secondary server, on the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.
Step 17
Click Force Active.
Step 18
Click OK to confirm. The secondary server becomes active.
Step 19
Repeat Step 7 through Step 12 on the secondary server to verify the voice messaging port configuration.
Step 20
In the Cisco Unity Administrator on the secondary server, go to the System > Ports page, and enable the ports you tested by checking the Enabled check box for those ports.
Step 21
In the Cisco Unity Administrator on the primary server, go to the System > Ports page, and enable the ports you tested by checking the Enabled check box for those ports.
Step 22
On the secondary server, on the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.
Step 23
Click Force Inactive.
Step 24
Click OK to confirm. The secondary server becomes inactive.
Step 25
On the primary server, on the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.
Step 26
Click Force Active.
Step 27
Click OK to confirm. The primary server becomes inactive.
Step 28
In the Failover Monitor on the primary server, click Advanced.
Step 29
Uncheck the Disable Automatic Failover and Failback check box.
Step 30
Click OK.
To Verify Hunt Group Programming (PIMG/TIMG Integrations Only)
Step 1
Set up a test phone (Phone 1) testing. For more information, see the "Preparations for Troubleshooting the Phone System in Cisco Unity 8.x" 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.
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, and 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, and 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.
Confirming Routing Rules
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 Cisco Unity desktop, double-click the Cisco Unity Tools Depot icon.
Step 2
In the left pane of Tools Depot, under Diagnostic Tools, double-click Unity Diagnostic Tool.
Step 3
In the Cisco Unity Diagnostic Viewer, click the Configure Micro Traces icon.
Step 4
In the Groups list, click Arbiter.
Step 5
In the Flags list, click Diagnostics 14, 15, and 16.
Step 6
In the Groups list, click Ruler Domain.
Step 7
In the Flags list, click Diagnostic 11.
Step 8
In the Cisco Unity Diagnostic Viewer, click the Start New Log Files icon.
Step 9
Reproduce the problem.
Step 10
To view the log files, in the left pane of the Cisco Unity Diagnostic Viewer screen, click Process > AvCsMgr, and then click the Current log file.
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 4 through Step 7, in the Cisco Unity Diagnostic Viewer, click the Reset to Default Traces and follow the instructions.
Step 14
Browse to the \CommServer\TechTools directory.
Step 15
Double-click AvRulerEditor.exe.
Step 16
In the Ruler Editor, under Domains, click Routing and then click Rules 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, go to the Call Management > Call Routing page.
Note
Do not use AvRulerEditor to change routing rules.
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 the Ruler Editor, contact Cisco TAC.
Confirming Voice Messaging Port Licensing
When more voice messaging ports are installed on the Cisco Unity server than are licensed, Cisco Unity does not answer calls on the extra ports. (For example, if a TIMG unit has 48 ports but Cisco Unity is licensed for only 24 ports, Cisco Unity will answer calls only on the first 24 ports.)
To Confirm the Number of Ports
Step 1
On the Cisco Unity server, on the Windows Start menu, click Programs > Cisco Unity > Licensing.
Step 2
In the Cisco Unity Licensing tool, confirm that the Voice Ports feature displays a number in the License column that matches the number of ports on the phone system that connects to Cisco Unity.
Step 3
If the values in Step 2 match, continue with the following "Confirming Voice Messaging Port Settings" section.
Confirming Voice Messaging Port Settings
If the phone system is programmed to send calls to a voice messaging port on Cisco Unity that is not configured to answer calls, Cisco Unity will not answer the call.
To Confirm That Calls Are Being Sent to the Correct Voice Messaging Ports on Cisco Unity
Step 1
In the Cisco Unity Administrator, go to the System > Ports page.
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 that are designated to answer calls. Change the phone system programming if necessary.
Step 4
If you made a change to the phone system programming in Step 3, shut down and restart the Cisco Unity server to clear any hung ports.
If a voice messaging port is disabled or set incorrectly, it will not answer calls.
To Confirm That Voice Messaging Ports Are Set Correctly
Step 1
In the Cisco Unity Administrator, go to the System > Ports page.
Step 2
Verify the settings for each voice messaging port, as follows:
•
If a port is not enabled, check the Enabled check box to enable it.
•
If the ports cannot all be enabled by using the Cisco Unity Administrator, do the following "To Enable Voice Messaging Ports in the Registry" procedure.
To Enable Voice Messaging Ports in the Registry
Step 1
On the Windows Start menu, click Run.
Step 2
Enter Regedit and click OK.
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. (See the "Restoring" topics in Registry Editor Help.) Note that for Cisco Unity failover, 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 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
Expand the key
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
Expand the key
HKEY_LOCAL_MACHINE\Software\ActiveVoice\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 the Cisco Unity server.
Step 10
In the Cisco Unity Administrator, go to the System > Ports page.
Step 11
Confirm that all ports are enabled. If a port is still not enabled, contact Cisco TAC.