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
Confirming the Phone System Settings
Confirming That Cisco Unity Was Restarted After an Exchange Shutdown and Restart
Confirming That a COM Port Is Available to Cisco Unity (Serial or SMDI Integrations Only)
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 (Circuit-Switched Systems Only)
Cisco Unity Is Not Answering Some Internal or External Calls
Confirming Hunt Groups
Confirming Routing Rules
Confirming Voice Messaging Port Licensing
Confirming Voice Messaging Port Settings
Confirming Phone Lines and Voice Cards
Internal and External Calls
About Problems with Internal and External Calls
Call problems fall into two categories:
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. 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. (Serial integrations only) Confirm that a COM port is available. See the "Confirming That a COM Port Is Available to Cisco Unity (Serial or SMDI Integrations Only)" section.
4. 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.
5. (Circuit-switched systems only) Confirm that the phone system generates a ring signal. See the "Confirming That the Phone System Generates a Ring Signal (Circuit-Switched Systems 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.
Confirming That a COM Port Is Available to Cisco Unity (Serial or SMDI Integrations Only)
Serial or SMDI traffic during a Windows startup may result in Windows assigning the COM port to a serial mouse, thus making the COM port 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 no device is 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, do the following procedure to determine whether the COM port is available.
To View COM Port Assignments
Step 1 On the Windows Start menu, click Control Panel > Ports.
Step 2 Look to see if the COM port connected to the serial cable, usually COM1, is listed in the Ports box.
If the COM port for the serial integration is listed, skip to the "Confirming That the Phone System Generates 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 Expand the key 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 refers to a mouse—for example Microsoft Ballpoint Serial Mouse—instead of a COM port (COM1, COM2, and so on), continue with the "To Disable the Detection of Devices on COM Ports in Windows" procedure.
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 Open the Boot.ini file by using a text editor such as Notepad.
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 the COM<x> port.
|
/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.
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. (Refer to 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 (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 "Preparations for Troubleshooting the Phone System" 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. Continue with Step 5.
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.
If the extensions ring, the trunk is configured correctly. Skip the remaining steps in this procedure.
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. 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.
5. Confirm that the phone lines and voice cards are working correctly. See the "Confirming Phone Lines and Voice Cards" 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 CallManager Integration, Without Cisco Unity Failover)
Step 1 Set up two test phones. For more information, see the "Setting Up For a Diagnostic Test (Cisco CallManager or SIP Integrations Only)" 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 CallManager integration guide (available at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_configuration_guides_list.html), and repeat this step.
If the problem persists for this voice messaging port, refer to the Cisco CallManager documentation at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_technical_documentation.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 CallManager 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 CallManager 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 CallManager Integration, with Cisco Unity Failover)
Step 1 Set up two test phones. For more information, see the "Setting Up For a Diagnostic Test (Cisco CallManager or SIP Integrations Only)" 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 CallManager integration guide (available at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_configuration_guides_list.html), and repeat this step.
If the problem persists for this voice messaging port, refer to the Cisco CallManager documentation at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_technical_documentation.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 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 CallManager will forward the call to the secondary server. If this does not happen, change the Cisco CallManager 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 (Circuit-Switched Phone Systems Only)
Step 1 Set up a test phone (Phone 1) for single-line testing. For more information, see the "Preparations for Troubleshooting the Phone System" 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 the Tools Depot window, under Diagnostic Tools, double-click Unity Diagnostic Tool.
Step 3 On the Cisco Unity Diagnostic Viewer screen, 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 On the Cisco Unity Diagnostic Viewer screen, click Start New Log Files.
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.
Step 11 The selected log file is formatted and displayed in the right pane.
Step 12 To export or save a copy of the log file, click Action > Export List.
Step 13 Name the file and save it to a location of your choice in .txt or .csv format.
Step 14 To turn off the traces set in Step 4 through Step 7, on the Cisco Unity Diagnostic Viewer screen, click Disable All Traces.
Step 15 Browse to the \CommServer\TechTools directory.
Step 16 Open the AvRulerEditor.
Step 17 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 18 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 AvRulerEditor, 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 the voice cards in the Cisco Unity server have 48 ports but only 24 ports are licensed, 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 Confirm that the Voice Ports value matches the following:
•The number of ports on the phone system that connect to Cisco Unity.
•(Only integrations that use voice cards) The number of ports on the voice cards installed on the Cisco Unity server.
Step 3 If the values in Step 2 match, continue with the following "Confirming Voice Messaging Port Settings" section.
If the value is smaller than the number of ports or voice cards in the Cisco Unity server, contact your sales representative.
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 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 all of the ports are enabled and set correctly, continue with the "Confirming Phone Lines and Voice Cards" section.
•If all of the ports cannot 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
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 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 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 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.
Confirm that all ports are enabled. If a port is still not enabled, contact Cisco TAC.
Confirming Phone Lines and Voice Cards
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 12-15.
Feedback
