2. Verify that the DTMF duration and interdigit timing settings for Cisco Unified Communications Manager (CM) (formerly known as Cisco Unified CallManager) and gateways have been set to 100 milliseconds. (Any value within the range of 80 and 100 milliseconds is fine.) In some versions of Cisco Unified CM, the default value for the H225 DTMF Duration parameter is 300 milliseconds, which causes problems for the Bridge. See the applicable Cisco documentation for details on locating and changing the applicable parameters in Cisco Unified CM and the gateways.

4. Verify that the Octel servers are running a supported protocol. The Octel servers must be running Octel analog networking. Neither Octel digital networking nor the VOICENET protocol is supported by the Bridge.

5. Verify that the name of the Bridge server can be resolved. If there are name resolution problems, you need to reconfigure DNS or add a reference to the Bridge server in the HOSTS file on the server on which the Voice Connector is installed and/or on the server that sends outbound SMTP messages to the Bridge server. See the "Configuring the Bridge and Testing the Configuration" section on page 2-20 for more information.

6. Verify that the Active Directory schema is extended. Confirm that the schema was successfully extended by checking the log file that ADSchemaSetup creates on the desktop.

9. Verify that search scopes include the Cisco Unity bridgehead server. The Subscriber and Blind Addressing search scopes (which are set on the Network > Primary Location > Addressing Options page in the Cisco Unity Administrator) must be set to either the dialing domain or global level. This must be done for each Cisco Unity server in the network. The search scopes for the auto-attendant and directory handlers (which are configured separately) must also include the Cisco Unity bridgehead server.

10. Verify that each Bridge delivery location is correctly configured.

12. Verify that the correct serial number and legacy mailbox ID is assigned to each Cisco Unity subscriber.

13. Verify that the Active Directory Connector is correctly configured. In organizations where Exchange 5.5 co-exists with either Exchange 2000 or Exchange 2003, the Connection Agreements for the Active Directory Connector must be carefully configured. If users on the Exchange 5.5 server experience problems addressing messages to Bridge subscribers, confirm that the Active Directory Connector is configured correctly.

Overview of Troubleshooting Logs, Traces, and Tools

This section provides a summary of the logs, traces, and other tools available for troubleshooting message delivery and directory synchronization problems between Cisco Unity and the Bridge. For descriptions of the tools, see the following sections:

Tools for Troubleshooting Communication Problems Between the Bridge and the Octel Nodes

This section provides a summary of the logs, traces, and other tools available for troubleshooting communication problems between the Bridge and the Octel nodes.

•Bridge Analog Network and Node Analyzer (BANANA)—BANANA is a stand-alone application that runs on the Bridge server. It is designed to assist with monitoring and troubleshooting analog communication between the Bridge and Octel nodes in the analog network. It also provides detail and summary call activity information. BANANA monitors and parses the call traces described below, and presents the data in a format that makes the call traces easier to understand. BANANA is available on the Bridge CD. We recommend that you install it.

•Call Traces—(Also referred to as the Starfish logs or SFLOGs.) The files are located on the Bridge server in the <Bridge Path>\Starfish\Log directory. To obtain information about messages coming from or going to Octel servers through the Bridge voice-fax cards, you increase the Call Tracing Level on the System Settings page in the Bridge Administrator. The log records actions that the Bridge service attempts, notes whether those actions are completed successfully, and records the reasons for failed actions. Within the Log directory are files named SFLOG.YYYYMMDD.LOG, where YYYY is the year, MM is the month, and DD is the day. Each file contains log entries for one hour of the day; the filename indicates which hour. The directory also contains the log file SFLOG.LOG, to which the Bridge server adds current entries, and which is then saved to the applicable hour log. Log files that are older than 24 hours are overwritten.

Each entry in the log files begins with the word "SFLOG," followed by a number, the date and time, the line number used by the call, and an action. For example:

In the example log above, a call went out on line 3, another call went out on line 2, and then the Octel answered the call that was initiated on line 3. Although you can use Notepad to view the call traces, we recommend that you use BANANA instead. BANANA parses the logs and presents them in a format that allows you to more easily follow the progress of a call.

•Call Queue Logs—Call Queue log files are located on the Bridge server in the <Bridge Path>\Starfish\Log directory. The Call Log Retention setting on the Systems Settings page allows you to specify the number of days that logs are saved. A separate file is used for each day. Files are named CallLog_YYYYMMDD.LOG where YYYY is the year, MM is the month and DD is the day. Call logs are used by the Bridge Traffic Analyzer for generating reports on Bridge activity.

•Line Status Page—The Line Status page in the Bridge Administrator allows you to monitor status information for the phone lines of the Bridge server as it communicates with Octel servers. It also allows you to enable or disable specific phone lines for the Bridge server.

•Queue Status Page—The Queue Status page in the Bridge Administrator allows you to monitor status information in the outbound message queue on the Bridge server.

•Bridge Traffic Analyzer—The Bridge Traffic Analyzer is a report generation utility that reads the call queue log files on the Bridge server and generates a graph and a summary table that can be saved as a comma-separated value (CSV) file. The Bridge Traffic Analyzer is available in Tools Depot on the Cisco Unity server, or you can download it from http://www.CiscoUnityTools.com. This tool typically is used for monitoring purposes and not for troubleshooting. However, if messages are not getting delivered in a timely manner, this tool will help you understand Bridge port utilization. See the "Bridge Traffic Analyzer" section on page 6-5 for more information.

•Event Viewer—The Bridge services record errors and warnings to the Windows Event Viewer application log. The Windows Event Viewer on the Bridge server should be one of the first places you look when troubleshooting.

Tools for Troubleshooting Communication Problems Between the Bridge and Cisco Unity

•Temporary SMTP Messages—On the Bridge Administrator Digital Networking page, set Retention Days for Temporary SMTP Messages to a non-zero value. Subsequently, temporary SMTP messages are stored on the Bridge server in the following directories:

–<path>\VPIM\Xcode\Inbound\Tmp—Messages from Cisco Unity are stored in this directory. If messages appear in this directory, you know that messages are getting to the Bridge from Cisco Unity.

–<path>\VPIM\Internet\Out\Tmp directory—Messages to Cisco Unity are stored in this directory. If messages appear in this directory, you know that messages from Octel have made it this far.

•VPIM Traces—Trace files are located on the Bridge server in the <path>\VPIM\Trace directory. Increase the Tracing Level on the Digital Networking page in the Bridge Administrator to obtain information about messages coming from or going to Cisco Unity. Within the Trace directory are the files VPIM.mmddtttt.LOG. Each file contains log entries for one hour of the day; the filename indicates which hour.

•VPIM Message Log—Related to the VPIM Traces is the log file VpimMsg.log, which is located on the Bridge server in the <path>\VPIM\MsgLog directory. The Bridge server adds current entries, and saves the applicable hour trace file. Log files that are older than 24 hours are overwritten.

Tools for Troubleshooting Problems with the Voice Connector

•Voice Connector Log File—The Voice Connector logs are located on the Exchange server on which the Voice Connector is installed in the directory <ExchangeServerPath>\VoiceGateway\LogFiles. The files are named in the format GwIvc_<YyMmDd >.log, where Yy in the year, Mm is the month, and Dd is the day.

•Event Viewer—The Voice Connector service records some errors to the Windows Event Viewer logs on the Exchange server on which it is installed.

Tools for Troubleshooting Problems in Exchange

•Exchange Message Tracking Tool—This tool is available in the Exchange System Administrator.

•Exchange SMTP Logging—You enable SMTP logging from within the Exchange System Administrator.

•Event Viewer—The CsBridgeConnector service, which is responsible for keeping the directories on the Bridge and Cisco Unity synchronized, logs several errors to the Windows Event Viewer application log on the Cisco Unity bridgehead server (that is, the Cisco Unity server that is configured for networking with the Bridge).

•Sent/Received vCard Data—This data, which can help you troubleshoot directory synchronization problems, is located on the Cisco Unity server in \CommServer\MsgArchive.

Messages Are Not Delivered from Cisco Unity to Octel

This section provides troubleshooting information to help you determine why voice messages from Cisco Unity are not received on an Octel system. When a Cisco Unity subscriber sends a voice message to an Octel subscriber, the message is passed by Cisco Unity to the Exchange MTA, which hands the message over to the Voice Connector. The Voice Connector converts the message to VPIM format (with proprietary extensions) and puts it in the SMTP pickup directory to be sent to the Bridge via SMTP.

Figure 7-1 illustrates at a high level the message flow from Cisco Unity to Octel, and the troubleshooting logs, traces, and tools that you can use to determine where the problem is along the path. For simplicity, the illustration shows messages originating from subscriber mailboxes. This is true when subscribers use Cisco Unity ViewMail for Microsoft Outlook or the Cisco Unity Inbox to send messages, but when subscribers use the TUI, the messages originate from the Exchange partner server.

Figure 7-1 Troubleshooting Message Flow from Cisco Unity to Octel

Bridge In and Out Directories

Conceptually, these directories divide the Bridge into the SMTP side and the analog side. The Unity Bridge service controls messages on the analog side, and the Digital Networking service controls messages on the SMTP side. Bridge\In and Bridge\Out are transitional directories. Messages from Cisco Unity are delivered to the Bridge\In directory by the Digital Networking service, where they are picked up by the Unity Bridge service for delivery to the Octels. In the other direction, messages from the Octels are delivered to the Bridge\Out directory by the Unity Bridge service, where they are picked up by the Digital Networking service for delivery to Cisco Unity via Exchange. If either service is stopped for some reason, messages will queue up as shown in Table 7-1.

Table 7-1 Messages Queue Up When the Unity Bridge Service and/or the Digital Networking Service Stop

Digital Networking Service

Unity Bridge Service

Messages from Cisco Unity to the Octels...

Messages from the Octels to Cisco Unity...

Running

Not Running

Will queue up in the Bridge\In directory until the Unity Bridge service starts and picks them up.

Will queue up on the Octel servers.

Not Running

Running

Will be stuck in the Exchange SMTP outgoing queues.

Will queue up in the Bridge\Out directory until the Digital Networking service starts and picks them up.

Not Running

Not Running

Will be stuck in the Exchange SMTP outgoing queues.

Will queue up on the Octel servers.

Troubleshooting Why Messages Are Not Delivered from Cisco Unity to Octel

This section guides you through the process of troubleshooting message delivery problems from Cisco Unity to Octel. Figure 7-2 illustrates the troubleshooting process at a high level.

Figure 7-2 Troubleshooting Why Messages Are Not Delivered from Cisco Unity to Octel

Enabling Logs and Traces

Before you begin sending test messages to track down the problem, do all of the following procedures to enable the applicable logs, traces, and other troubleshooting tools:

Note The most up-to-date version of BANANA is available at http://www.CiscoUnityTools.com. When you start BANANA, it checks the CiscoUnityTools website to see if a newer version is available, and if so, prompts you about upgrading.

To Enable Troubleshooting Logs and Traces on the Bridge Server

Step 1 In the Bridge Administrator, go to the Digital Networking page and set Retention Days For Temporary SMTP Messages to the number of days that you want to retain the messages.

Step 2 Set the Tracing Level to Flow.

Step 3 Click Save.

Step 4 Go to the System Settings page, and set the Call Tracing Level to Verbose.

Step 5 Click Save.

To Increase the Voice Connector Logging Level

Step 1 Log on to the Exchange server on which the Voice Connector is installed.

You need to enable message tracking on each Exchange server that participates in message delivery: the Exchange server (or servers) on which the Voice Connector is installed, and the Exchange server on which the Cisco Unity subscriber mailbox is located.

Are Outbound Calls Attempted?

To determine whether calls are attempted, you use BANANA admin to view the call traces. To obtain the needed information from the call traces, the Call Tracing Level field on the System Settings page in the Bridge Administrator must be set to Verbose or Debug. Logs for analog activity are stored in this directory, one log per hour, for a period of 24 hours. The current log is named sflog.log. The logs for the previous 24 hours are named sflog.mmddtttt.log, where mm=month, dd=day, and tttt=time of day in hours and minutes (on a 24-hour clock).

When the call traces are processed by BANANA, it stores all necessary data in its bdgdata.mdb database. Although the call traces from which the data is extracted are retained for only 24 hours, BANANA will retain the data for up to 14 days (configurable to the hour) as long as BANANA processes call traces—either manually or automatically—at least once per 24 hours.

Step 2 If you have not already done so, set the Log Location and Output Folder location as described in the following sub-steps. If you have already set the locations, skip to Step 3.

a. In the Files Location section, if the path for the Log Location is set to d:\Bridge\Starfish\Log, skip to Step 2b. Otherwise, enter or browse to the directory where the analog call traces are stored. This directory can be identified by the presence of files with names that begin with SFLOG.

b. Optionally, change the location of the Output Folder. This is the directory in which BANANA stores the logs and CSV files that it generates.

Step 3 Click Process Call Data. BANANA processes the log file, and then populates the Calls and Errors grids. Depending on the amount of data in the log file, this could take several minutes.

Step 4 In the Calls grid, click the Inbound column header to sort the calls by inbound and outbound. Inbound calls are indicated with a check mark.

If you want to see whether a specific call was attempted, and there are numerous calls in the grid, you may want to sort the calls by the TimeStampBegin column or the OctelSerialNumber column.

Note See the "Viewing Data in the BANANA admin Interface" section of BANANA Help for more information.

Troubleshooting Why Outbound Calls Are Not Attempted

•Is the Octel node delivery schedule active?—In the Bridge Administrator, go to the Octel Node configuration page for each node. Confirm that the settings in the Message Delivery Windows section of the page indicate that the delivery schedule is active.

•Is the Unity Bridge service running?—On the Bridge server, open the Services Control Panel and confirm that the Unity Bridge service is running.

•Are any lines enabled?—In the Bridge Administrator, go to the Line Status page to view the status for each line.

•Is only one line enabled?—In the Bridge Administrator, go to the Line Status page to view the status for each line. The Bridge will not dial out when only one line is enabled.

•Are all ports busy with incoming calls?—In the Bridge Administrator, go to the Line Status page to view the status for each line.

•Is there a problem with the Bridge analog cards or drivers?—On the Bridge server, open the Windows Event Viewer Application log, and look for warnings and errors related to the cards and drivers.

•Are lines retired?—In the Bridge Administrator, go to the Line Status page to view the status for each line. On the Bridge server, you can also open the Windows Event Viewer Application log, and look for warnings and errors related to retired lines (for example, "Retired for callouts"). If line retirements occur, plug an analog phone into the lines going to the Bridge. Confirm that you get dial tone when you go off hook.

When a problem occurs that prevents the Bridge from initiating an outgoing analog call on a particular analog port—for example, a line cord is not plugged in or there is no dial tone from the phone system—and when the same problem occurs on the same port four times in succession, the Bridge will retire that port and log the following warning in the Windows Event Viewer Application log: "Line X: Retired for callouts." This port will then be unavailable for outgoing calls. However, if the same port receives an incoming call and the connection is successful, the port will be put back into service for both incoming and outgoing calls, and another warning will appear in the Application Event Viewer: "Line X: Callouts re-started." This allows the Bridge to resolve the situation automatically if the condition clears up, or at the minimum allows the port to continue to receive incoming calls even if the problem initiating outgoing calls persists.

If all enabled analog lines on the Bridge server become retired due to these conditions, another warning will appear in the Application Event Viewer: "No lines are available for placing outgoing callouts." As soon as at least one port receives an incoming call and becomes available, another warning will appear in the log: "Lines are once again available for outgoing calls."

If these warnings appear frequently in the Application Event Viewer log, the analog lines connected to the Bridge server should be checked to see what problems may be occurring. After resolving any issues with the lines, any ports currently retired can be returned to service either by calling into the retired ports to trigger an automatic return to service, or by restarting the Unity Bridge service from the Services Control Panel.

Troubleshooting Why Outbound Calls Are Failing

When the Bridge uses a Cisco gateway connected to Cisco Unified Communications Manager (CM) (formerly known as Cisco Unified CallManager) for analog connectivity with the Octels, verify that:

•The DTMF duration and interdigit timing settings for Cisco Unified CM and gateways have been set to 100 milliseconds. (Any value within the range of 80 to 100 milliseconds is fine.) In some versions of Cisco Unified CM, the default value for the H225 DTMF Duration parameter is 300 milliseconds, which causes problems for the Bridge. See the applicable Cisco documentation for details on locating and changing the applicable parameters in Cisco Unified CM and the gateways.

If the preceding advice does not resolve the problem, do the following:

•In the Calls grid of the BANANA admin, click the ExitCode column header to sort the calls by exit code. Calls that completed successfully are indicated by an OK in the ExitCode column. Calls that did not complete successfully instead have an error code (a number beginning with an "E") listed in the ExitCode column.

•For each call in the Calls grid that encountered an error, a record exists in the Errors grid. This record provides specific details regarding the condition under which the call was terminated, including the state of the protocol that was in process, and the reason the call could not be completed. When you click a call with an error code in the Calls grid, the corresponding record is highlighted in the Errors grid. The record in the Errors grid lists the exit code, call state, and reason for the call failure.

Table 7-2 maps error codes to configuration problems, and to other problems that result in outbound call failures.

Table 7-2 Configuration and Other Problems That Result in Outbound Call Failures

Error Code

Description

E00010001

A Line Error occurs when the Bridge detects a line problem after going off hook and prior to dialing a phone number. The most common cause of this condition is failure to receive dial tone on the line. Plug an analog phone into the source of one of the analog lines and verify that you hear dial tone, and can successfully dial a phone number.

E00010003

The Bridge detected a busy condition after dialing the specified phone number for this node. On busy analog networks, this condition can occur occasionally. However, repeated failures to contact the remote node because of busy line conditions can result in messages not being delivered in a timely manner. Repeated failures can also result in the messages being returned to the Cisco Unity senders, when the number of retries exceeds the Attempts If Busy setting on the Bridge System Settings page.

Confirm that the phone number specified for the node being called is correct by dialing the phone number from a regular phone. If you verify that the phone number is correct, but continue to experience busy conditions with this node, contact the system administrator of this Octel system to see if there is a reason the system is often unavailable.

E00010004

The Bridge detected ringing on the line after dialing the specified phone number for this node, but the call was never answered. Confirm that the phone number specified for the node being called is correct, by dialing the phone number from a regular phone and verifying that the expected voice mail system answers.

•The Octel servers are running a supported protocol. The Octel servers must be running Octel analog networking. Neither Octel digital networking nor the VOICENET protocol is supported by the Bridge.

E00030005

On an outbound call, after the Bridge sends the BD handshake tones, it expects to receive the CDD handshake response. When an outbound call from the Bridge is answered, but no CDD is received, this may indicate:

•That the call was not answered by an Octel that supports the Octel Analog Networking feature. Check the phone number for the Octel Node profile of the serial number that the Bridge was attempting to contact.

•Poor line quality. If the line quality is such that the audio being sent to the Bridge is not clear, this is usually the first state in which you will observe problems. To determine what the Bridge may be experiencing when calling this number, plug an analog phone into the source of one of the analog lines and dial the phone number as configured for this Octel Node.

•Failure to detect call progress, such as ringback or busy tone, on the analog line. If the Bridge is able to place a call successfully, but receives no further indication of the call progress within 20 seconds, it will assume the call has been answered and begin to send the BD wake up tones. If the call has not actually been answered, you may receive this error. To determine what the Bridge may be experiencing when calling this number, plug an analog phone into the source of one of the analog lines and dial the phone number as configured for this Octel Node.

•The Octel servers are running a supported protocol. The Octel servers must be running Octel analog networking. Neither Octel digital networking nor the VOICENET protocol is supported by the Bridge.

E00050005

On an outbound call from the Bridge to an Octel, after the Bridge sends the BD handshake tones and receives the CDD handshake response, it sends a string of 18 DTMF digits, including the serial number of the Octel that the Bridge is attempting to communicate with. If no response is received from the Octel, it is possible that the serial number sent from the Bridge did not match the serial number of the Octel that answered the call. Verify that the serial number and phone number for the Octel Node profile are correct.

E00070005

If observed repeatedly, this may indicate that the remote system does not have a location profile configured for the Unity Node serial number that the Bridge server is using. When the Bridge sends the session header, this packet includes the Unity Node serial number that the Bridge is calling as. If the remote system requires this serial number to be configured on a location profile, and it does not have one matching the serial number that the Bridge used in the session header, the remote system will disconnect without sending the session header response. Note that not all systems that support Octel analog networking require confirmation of the calling serial number at this stage. Also note that E00070005 will be the exitcode if the remote system did not receive all of the session header DTMF digits as sent by the Bridge, even if location profiles on both systems are configured correctly.

E00160010

Confirm that the Octel node with which the Bridge communicates supports the fax feature.

E00160099

Confirm that all gateway and phone system devices between the Octel and the Bridge support fax transmission.

E00010017

Upon dialing the phone number of the remote system, the Bridge received intercept tones from the phone service provider, indicating the number dialed is out of service. The Bridge counts this condition against the Attempts If Busy threshold configured on the System Settings page. When the number of retries exceeds the Attempts If Busy setting, all messages queued for delivery to this remote system will be returned to the Cisco Unity senders as non-deliverable.

Confirm that the phone number specified for the node being called is correct by dialing the phone number from a phone.

Error Handling Added for Problematic Outbound Analog Messages

There are many reasons why the analog delivery of an outbound message can fail (for example, a bad connection caused by an interruption on the line or poor line quality). However, message-delivery failure can also occur as a result of problems delivering one particular message. The Max Play Attempts Per Message setting was added to the System Settings page in the Bridge Administrator to allow you to control how long the Bridge attempts to deliver a particular message before returning it to the sender as undeliverable. (See the"System Settings" section on page 10-2 for more information on the Max Play Attempts Per Message setting.)

The specific condition for which the new Max Play Attempts Per Message setting is applicable is the following sequence of events:

1. A message being transmitted from the Bridge contains a tone (a DTMF tone or a background noise or voice that matches the frequencies of a DTMF tone or disconnect tone).

2. Detection of the tone by the Octel during recording causes the Octel to disconnect the call, causing the message transmission to fail.

3. The Octel does not deliver the incomplete message transmission to the recipient.

4. When the Bridge completes playing the message, it receives no response from the Octel.

5. The Bridge requeues the message at the front of the outgoing analog queue for delivery to the Octel.

Because the problematic tone is in the voice message itself, the unsuccessful sequence will repeat each time the Bridge attempts delivery of the message to the Octel. When this condition occurs, text similar to the following will be displayed in the Starfish logs on the Bridge server and in the call details displayed by the Cisco Unity Bridge Analog Network and Node Analyzer (BANANA) each time that delivery of the message is attempted:

After playing the # to signal completion of the message, the Bridge expects to receive DTMF tone 8 from the Octel. If viewed in BANANA, the condition is logged as "Expected data not received" in the "Save Request" state.

The failure condition is explicitly tracked per message. Each time that message delivery is unsuccessful due to this condition, the "Max Play Attempts Per Message" for a particular message is incremented by 1. As successive attempts to deliver the message fail, subsequent messages received by the Bridge from Cisco Unity for delivery to the Octel node are placed behind the message in the outbound analog queue. When the threshold for "Max Play Attempts Per Message" as configured on the System Settings page is reached for the message, only the message is returned as undeliverable to Cisco Unity. Any other messages in the analog outgoing queue for the Octel node are retained in the queue, and the next delivery attempt to the Octel node resumes with the next message in the queue.

Event Viewer Warnings

When the Bridge is unable to deliver a message to an Octel, the Bridge returns a nondelivery receipt (NDR) to the sender and logs warnings to the Event Viewer Application log. The Bridge detects the following conditions and logs warnings in the Event Viewer:

•When the message sent from Cisco Unity contains a serial number that the Bridge does not recognize. Each Cisco Unity subscriber account must have a serial number and legacy mailbox ID in order to exchange messages with Octel subscribers. When a Cisco Unity subscriber sends a message to an Octel subscriber, the serial number of the Cisco Unity subscriber is added to the header of the message. The Bridge will not deliver a message when the serial number in the message header does not match a serial number of a Unity Node configured on the Bridge.

•When any of the analog delivery thresholds configured on the System Settings page has been reached. (The System Settings thresholds are: Attempts If Busy, Attempts on No Answer, Attempts on Bad Connection, Max Play Attempts Per Message, Max Retention Time - Normal, and Max Retention Time - Urgent.)

•When the message recording is in an invalid WAV file format (either the message was recorded by using a codec that cannot be converted by the Bridge, or the WAV attachment contains no voice data).

•When the mailbox of the Octel recipient is full.

•When the recipient mailbox does not exist on the Octel node.

Do Outbound Messages Reach the Voice Connector?

If messages do not reach the Bridge, the next step is to determine whether the messages reach the Voice Connector, by examining the Voice Connector log file. Following are the logs (with source code line numbers and file names deleted) for a successfully processed Cisco Unity to Bridge voice message, with the logging level set to Information:

The line containing "!!!!! Processing Outgoing OMNI Voice message !!!!!!" indicates that the Voice Connector is receiving messages. The lines containing "Delivered file to SMTP" and "Remove from message queue" indicate that processing was successfully completed. If there are problems with processing, there will be error messages in the log between the "!!!!! Processing Outgoing OMNI Voice message !!!!!!" and "Delivered file to SMTP" lines.

Troubleshooting Why Outbound Messages Do Not Reach the Voice Connector

•Is the Voice Connector service running?—On the Exchange server on which the Voice Connector is installed, open the Services Control Panel and confirm that the Exchange 2000 Voice Connector service is running.

•Are there errors in Event Viewer?—On the Exchange server on which the Voice Connector is installed, in the Windows Event Viewer system and application logs, look for warnings or errors.

•Are the Exchange route group connectors configured properly?—If the Voice Connector is not installed in the same routing group as the mailbox of the subscriber who sent the message, verify that Exchange route group connectors are properly set up to route messages between the groups.

•Are test messages delivered to subscribers homed on the Exchange server on which the Voice Connector is installed?—Send a test message from the subscriber who sent a message that was not delivered to another subscriber whose mailbox is on the same server on which the Voice Connector is installed.

Step 1 On the Exchange server on which the Voice Connector is installed, in the Exchange System Manager under the Connectors subtree, right-click AvExchangeIVC_<Machine name>, and select Properties.

Step 2 Click the Address Space tab and confirm that a type OMNI is listed with an Address of * and a Cost of 1.

Step 3 Confirm that the Connector Scope is set to Entire Organization.

Step 4 Determine whether the messages are still in the process of being routed, or if they are routing incorrectly within the Exchange network. Use Exchange Message Tracking to view the recent tracking history of messages within the network. Look for messages with a recipient of "[OMNI:...]" or "IMCEAOMNI-...".

Does the Voice Connector Hand Off Messages for Pickup by the SMTP Service?

If a line containing "!!!!!! Processing Outgoing OMNI Voice message !!!!!!" appears in the GwIvc_<date>.log file, do the following procedure. The presence of this line indicates that the Voice Connector is receiving messages from Exchange and is processing them, so the next step is to determine whether the Voice Connector sends the messages back to Exchange to be sent out via the Exchange SMTP queues.

To Determine Whether the Voice Connector Hands Off Messages to Exchange

Step 2 Within the next 5 to 20 lines—the placement varies depending on whether the logging level is set to Information or Function—look for separate lines containing each of the following messages, which indicate who the message is from:

Troubleshooting Why the Voice Connector Does Not Hand Off Messages for Pickup by the SMTP Service

•Are there errors in the Event Viewer?—On the Exchange server on which the Voice Connector is installed, in the Windows Event Viewer system and application logs, look for warnings or errors. In particular:

–Look for warnings or errors that indicate that messages have been returned because of invalid attachments.

–Look for warnings that include the text "ciscoEcsbuRemoteNodeID for current user not found" or "ciscoEcsbuLegacyMailbox for current user not found." These messages indicate that the Cisco Unity subscriber who sent the message does not have the Octel Serial Number (ciscoEcsbuRemoteNodeId) or Legacy Mailbox values defined that are necessary for processing voice messages to and from the Cisco Unity Bridge server.

–Look for warnings that include the text "Address Message: Unknown Error, Check GwIvc_<Date>.log." These warnings may indicate that the Bridge server address and node ID have not been properly defined on the Primary Location page in the Cisco Unity Administrator.

–If the Windows System Event log shows that the Voice Connector is not able to log on, or if voice messages are accumulating in the MTS-OUT queue, download and run the Microsoft Exchange Best Practices Analyzer, and make the changes that Microsoft recommends. (These symptoms are commonly related to Exchange permissions, especially with the Local System account.) See the "To Run the Microsoft Exchange Best Practices Analyzer" procedure.

•Are messages stuck in the MTS-IN and MTS-OUT queues? Do one of the following procedures, as applicable:

Step 3 In the left pane, expand the Servers container, and then expand the server on which the Voice Connector is installed.

Step 4 In the server container, click Queues.

Step 5 Look in the MTS-IN and MTS-OUT queues to see if any messages appear to be stuck.

Step 6 Click Find Now to see all of the messages that are in the queue.

To Run the Microsoft Exchange Best Practices Analyzer

Step 1 Download the Microsoft Exchange Best Practices Analyzer version 2.7 or later from the Microsoft website.

The download page for the Microsoft Exchange Best Practices Analyzer includes a link to a quick-start guide, which explains how to install and run the analyzer. You may also want to print this guide.

Step 2 Run the analyzer.

Step 3 Follow the Microsoft recommendations, especially any recommendations related to the Local System account.

Does the SMTP Service Attempt to Send Messages?

If you have determined that the Voice Connector successfully processes messages and puts them in the SMTP pickup folder for delivery via SMTP, but the messages never make it to the Bridge, check the SmtpPickupPath registry key, the SMTP log file, and the SMTP queues, as described in this section.

Checking the SmtpPickupPath Registry Key

The Voice Connector places outgoing messages to the Bridge in the SMTP pickup directory on the Exchange 2000 or Exchange 2003 server on which the Voice Connector is installed. In typical installations, the path to the SMTP pickup directory is C:\Program Files\Exchsvr\Mailroot\vs 1\Pickup. The Microsoft Windows SMTP service monitors the pickup directory, and when it detects a message in the directory, the service attempts to send the message to the destination that is specified in the message header.

During installation, the Voice Connector setup program obtains the path to the SMTP pickup directory from Active Directory. The Voice Connector setup writes the path to the registry in the key HKEY_LOCAL_MACHINE\SOFTWARE\Active Voice\AvIvc\SmtpPickupPath. When the Voice Connector service starts, it reads the path stored in the SmtpPickupPath registry key, and subsequently places outgoing messages to the Bridge in that directory.

If you changed the SMTP pickup directory in Active Directory, Active Directory automatically updates the IIS metabase. In this case, the Voice Connector should use the path specified in Active Directory, and you should not need to modify the SmtpPickupPath registry key. However, to be safe, you should verify that the path that is specified in the SmtpPickupPath matches what you specified in Active Directory.

If you changed the path to the SMTP pickup directory in the IIS metabase by using metaedit, Active Directory may not have been updated, and the Voice Connector may place outgoing Bridge messages in a directory that the SMTP service is not monitoring. In this rare situation, you have two choices:

•Use ADSI Edit to change the path to the SMTP pickup directory in Active Directory. The path is stored in the attribute msExchSmtpPickupDirectory. For more information on using ADSI Edit, refer to the Microsoft documentation.

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.) 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\Active Voice\AvIvc

Step 4 In the right-pane, double-click the SmtpPickupPath value.

Step 5 In the Edit String dialog box, change the path in the Value Data field, and click OK.

Step 10 Send a test message to verify that it is delivered to the Bridge.

Checking the SMTP Logs

Check the SMTP log files on the server on which the Voice Connector is installed to see whether the SMTP server is attempting to send messages to the Bridge server. The default location of the log files is:

C:\Windows\System32\LogFiles\SMTPSVC1

If the SMTP service is attempting but failing to send the messages, look for a 4xx or 5xx code indicating the cause of the failure.

Checking the SMTP Queues

Check the SMTP queues for messages that are stuck by doing the applicable procedure:

Step 1 In the Exchange System Manager, for each server in the organization, expand the Administrative Groups\<Administrative Group Name>\Servers\<Server Name>\Protocols\SMTP\Default SMTP Virtual Server\Queues tree.

Step 2 Look for messages that appear to be stuck. Messages addressed from the Voice Connector to the Bridge will have a Recipient address similar to <mailbox>@<bridge server address> or directory@<bridge server address>.

Step 1 In the Exchange System Manager, for each server in the organization, expand the Administrative Groups\<Administrative Group Name>\Severs\<ServerName>\Queues tree.

Step 2 Check all of the queues listed in Queue Viewer. Look for messages that appear to be stuck. Messages addressed from the Voice Connector to the Bridge will have a Recipient address similar to <mailbox>@<bridge server address> or directory@<bridge server address>.

Troubleshooting Why the Bridge Does Not Receive Messages That Are Sent Via SMTP

Do the following procedure to determine if the fully qualified domain name of the Bridge server is entered correctly.

To Verify That the Domain Name of the Bridge Server Is Entered Correctly

Step 1 In the Cisco Unity Administrator, go to the Bridge Delivery Location page for the applicable remote Octel server on the Cisco Unity bridgehead server.

Step 2 Confirm that the name in the Bridge Server Full Computer Name field on the Bridge Delivery Location page of the Cisco Unity Administrator exactly matches the Bridge Server Full Computer Name field on the Digital Networking page in the Bridge Administrator on the Bridge server.

Step 3 Confirm that both settings match the Full Computer Name of the Bridge server as listed in the Windows System Control Panel on the Network Identification tab on the Bridge server.

Step 4 In a command prompt window on the Exchange/SMTP server, enter the command nslookup <Bridge Server> where <Bridge Server> is the fully qualified domain name of the Bridge server as entered in the locations above.

If the returned response is Non-Existent Domain, check the configuration of the DNS zones in which the servers are located. Make any necessary changes so that the fully-qualified domain name of the Bridge is recognizable from the zone in which the Exchange/SMTP server is located.

•Confirm that the Exchange/SMTP servers used for relaying messages outside of the organization are not restricted from relaying messages to unknown servers, or if they are restricted, that relaying messages to the Bridge server IP address is explicitly allowed. Depending on your network configuration, you may need to manually enter a DNS MX record for the Bridge in order to allow SMTP message delivery to it, but usually this is not necessary.

•If there is a firewall between the Bridge and the SMTP relay server, confirm that SMTP traffic is allowed on port 25.

•Check to see whether e-mail leaving your Exchange organization is re-routed to a smart host, non-Exchange corporate SMTP relay server, secure e-mail server, Exchange 2007 Edge Transport server, or any other traffic filtering server that may not route SMTP messages to the Bridge server. If so, an Exchange SMTP connector can be configured to send only those message addressed to the Bridge server directly to the Bridge without being re-routed. Do the following "To Configure an Exchange SMTP Connector to Route Messages Addressed to the Bridge Server Directly to the Bridge" procedure.

To Configure an Exchange SMTP Connector to Route Messages Addressed to the Bridge Server Directly to the Bridge

Caution Consult the Exchange administrator for your organization before doing this procedure. Misconfiguration of the SMTP connector could result in problems routing other SMTP mail for the organization.

Step 1 On the Exchange server on which the Voice Connector is installed, open the Exchange System Manager. (The SMTP connector must be created on the Exchange server on which the Voice Connector is installed.)

Step 2 Expand the tree in the left pane to view the Connectors directory. On some servers the Connectors directory will be in the Organization root. On others, most notably where multiple Routing Groups are being used, you will need to be sure to select the Connectors directory under the Routing Group in which the Voice Connector is installed.

Step 3 Right-click Connectors and select New > SMTP Connector.

Step 4 On the General tab, enter a meaningful name.

Step 5 On the General tab, select Forward All Mail Through this Connector to the Following Smart Hosts. In the field below, enter the IP address of the Bridge server enclosed in square brackets (for example: [10.10.255.1]).

Step 6 On the General tab, click Add.

Step 7 Select the server on which the Voice Connector is installed, and click OK to set this as the bridgehead server for the SMTP connector.

Step 8 Click the Address Space tab.

Step 9 On the Address Space tab, click Add.

Step 10 Select SMTP and click OK.

Step 11 In the E-Mail Domain field, enter the fully qualified domain name of the Bridge server. The name should match the following:

•The Full Computer Name of the Bridge server as listed in the Windows System Control Panel on the Network Identification tab on the Bridge server.

•The Cisco Unity Bridge Domain Name in the Digital Networking page in the Bridge Administrator.

•The Bridge server address entered in the Cisco Unity Administrator on the Primary Location page on the Cisco Unity bridgehead server (the server licensed for the Bridge).

Step 12 Leave the value in the Cost field set to 1, and click OK.

Step 13 Click OK to complete the configuration of the SMTP connector.

Step 14 Send a test voice message from Cisco Unity to an Octel recipient to see whether the message arrives at the Bridge.

Step 15 Send a test e-mail to an outside address to verify that e-mail still works.

After You Finish Troubleshooting

When finished troubleshooting, you should reset most of the logs and traces back to their defaults. However, leave the call tracing level on the System Settings page in the Bridge Administrator set to Verbose, as this call tracing level is required by BANANA.

Caution Logs and traces that you enable on the Bridge server, on the Exchange server on which the Voice Connector is installed, and on the Cisco Unity server can take up a great deal of hard disk space. Disable the logs and traces when you finish troubleshooting, with the exception of the call traces (also referred to as the starfish logs) on the Bridge server.

Reset the following logs and traces:

•In the Bridge Administrator, on the Digital Networking page:

–Reset the Retention Days for Temporary SMTP Messages back to 0 (zero). (These messages consume significant hard disk space, so you should always configure this setting to zero unless you are troubleshooting and are monitoring hard disk consumption.)

–Reset the Tracing Level back to None. (Typically, these logs do not consume significant hard disk space, so you may choose to leave the Tracing Level set to Flow.)

•In the Exchange System Manager:

–Reset the Voice Connector Logging Level back to Warning. (You may choose to leave these logs set to the Information level, which provides more detail than the Warning level. With logging at the Information level, you should monitor the hard disk space consumed by the log files. You may need to adjust the Log Recycle Days setting or set a limit for the hard disk space allowed for the logs.) Do the following "To Decrease the Voice Connector Logging Settings (Exchange 2000 and Exchange 2003)" procedure.

–Disable Exchange message tracking. (You may choose to leave message tracking enabled. Monitor occasionally to make sure that no more than the available hard disk space is consumed for storage of these logs.)

–Disable SMTP logging. (You may choose to leave these logs enabled. Monitor occasionally to make sure that no more than the available hard disk space is consumed for storage of these logs.)

Note that the properties pages for administering the Voice Connector are always displayed in English.

Step 5 Click the Advanced tab.

Step 6 Click Warning (Level 3) to adjust the logging level.

Step 7 Click OK and exit Exchange System Manager.

Step 8 Open the Windows Services MMC.

Step 9 Right-click Exchange 2000 Voice Connector and select Restart.

Step 10 Exit the Windows Services MMC.

Messages Are Not Delivered from Octel to Cisco Unity

This section provides troubleshooting steps for identifying why a voice message is not delivered from an Octel node to a Cisco Unity subscriber.

When an Octel subscriber sends a voice message to a Cisco Unity subscriber, the Octel node passes the message to the Cisco Unity Bridge via analog lines. The Bridge converts the received Octel message to a VPIM message (with proprietary extensions) and sends it via SMTP to the Voice Connector for Exchange 2000. The Voice Connector converts the message to a WAV file and hands it back to Exchange to be delivered to the Cisco Unity subscriber mailbox. Note that the Cisco Unity server does not play a role in delivering voice messages from an Octel node to a Cisco Unity subscriber mailbox.

Figure 7-3 illustrates at a high level the message flow from Octel to Cisco Unity, and the troubleshooting logs, traces, and tools that you can use to determine where the problem is along the path.

Figure 7-3 Troubleshooting Message Flow from Octel to Cisco Unity

Bridge In and Out Directories

Conceptually, these directories divide the Bridge into the SMTP side and the analog side. The Unity Bridge service controls messages on the analog side, and the Digital Networking service controls messages on the SMTP side. Bridge\In and Bridge\Out are transitional directories. Messages from Cisco Unity are delivered to the Bridge\In directory by the Digital Networking service, where they are picked up by the Unity Bridge service for delivery to the Octels. In the other direction, messages from the Octels are delivered to the Bridge\Out directory by the Unity Bridge service, where they are picked up by the Digital Networking service for delivery to Cisco Unity via Exchange. If either service is stopped for some reason, messages will queue up as shown in Table 7-3.

Table 7-3 Messages Queue Up When the Unity Bridge Service and/or the Digital Networking Service Stop

Digital Networking Service

Unity Bridge Service

Messages from Cisco Unity to the Octels...

Messages from the Octels to Cisco Unity...

Running

Not Running

Will queue up in the Bridge\In directory until the Unity Bridge service starts and picks them up.

Will queue up on the Octel servers.

Not Running

Running

Will be stuck in the Exchange SMTP outgoing queues.

Will queue up in the Bridge\Out directory until the Digital Networking service starts and picks them up.

Not Running

Not Running

Will be stuck in the Exchange SMTP outgoing queues.

Will queue up on the Octel servers.

Troubleshooting Why Messages Are Not Delivered from Octel to Cisco Unity

This section guides you through the process of troubleshooting message delivery problems from to Octel to Cisco Unity. Figure 7-4 illustrates the troubleshooting process at a high level.

Figure 7-4 Troubleshooting Why Messages Are Not Delivered from Octel to Cisco Unity

Enabling Logs and Traces

Before you begin sending test messages to track down the problem, do all of the following procedures to enable the applicable logs, traces, and other troubleshooting tools:

Note The most up-to-date version of BANANA is available at http://www.CiscoUnityTools.com. When you start BANANA, it checks the CiscoUnityTools website to see if a newer version is available, and if so, prompts you about upgrading.

To Enable Troubleshooting Logs and Traces on the Bridge Server

Step 1 In the Bridge Administrator, go to the Digital Networking page and set Retention Days For Temporary SMTP Messages to the number of days that you want to retain the messages.

Step 2 Set the Tracing Level to Flow.

Step 3 Click Save.

Step 4 Go to the System Settings page, and set the Call Tracing Level to Verbose.

Step 5 Click Save.

To Increase the Voice Connector Logging Level

Step 1 Log on to the Exchange server on which the Voice Connector is installed.

You need to enable message tracking on each Exchange server that participates in message delivery: the Exchange server (or servers) on which the Voice Connector is installed, and the Exchange server on which the Cisco Unity subscriber mailbox is located.

Message tracking in Exchange 2007 is enabled by default on Mailbox, Hub Transport and Edge Transport servers. The default location of the logs is C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\MessageTracking.

Step 1 Open the Exchange Management Shell.

Step 2 To get message tracking information on a Mailbox server, enter the following command, but substitute the name of your server for <ServerName>:

Get-MailboxServer <ServerName> | fl *messagetracking*

Step 3 To get message tracking information on a Transport server, enter the following command:

Get-TransportServer <ServerName> | fl *messagetracking*

Step 4 To enable message tracking on a Mailbox server, enter the following command:

Set-MailboxServer <ServerName> -MessageTrackingLogEnabled:$true

Step 5 To enable message tracking on a Transport server, enter the following command:

Does the Bridge Receive Inbound Calls?

Step 2 If you have not already done so, set the Log Location and Output Folder location as described in the following sub-steps. If you have already set the locations, skip to Step 3.

a. In the Files Location section, if the path for the Log Location is set to d:\Bridge\Starfish\Log, skip to Step 2b. Otherwise, enter or browse to the directory where the analog call traces are stored. This directory can be identified by the presence of files with names that begin with SFLOG.

b. If applicable, change the location of the Output Folder. This is the directory in which BANANA stores the logs and CSV files that it generates.

Step 3 Click Process Call Data. BANANA processes the log file, and then populates the Calls and Errors grids. Depending on the amount of data in the log file, this could take several minutes.

Step 4 In the Calls grid, click the Inbound column header to sort the calls by inbound and outbound. Inbound calls are indicated with a check mark.

If you want to see whether a specific call was received, and there are numerous calls in the grid, you may want to sort the calls by the TimeStampBegin column, the UnitySerialNumber column, or the OctelSerialNumber column.

Troubleshooting Why the Bridge Does Not Receive Inbound Calls

•Verify that the analog phone lines are plugged into the Bridge server and Octel servers.

•Verify the delivery phone number for the Bridge. Call the Bridge delivery phone number to see whether the Bridge answers. If the delivery phone number is correct and the Bridge answers, the inbound call will show up in BANANA admin. (In BANANA admin, click Process Call Data to see the record added to the Calls and Errors grids.)

•Check the node profiles on the Octel servers to verify that they are configured with the correct delivery phone number for the Bridge.

•If you have modified the default values for Queued Call Threshold and Max Ports Per Node on the System Settings page in the Bridge Administrator, and if message traffic is heavy enough, it is possible that all of the ports will be used for outgoing messages, leaving no ports available for incoming messages. If this is a concern, you may want to designate one or more ports to be used only for incoming calls. The Line Status page in the Bridge Administrator allows you to specify whether each line is to be used for both incoming and outgoing calls or only for incoming calls. See the "Controlling the Number of Ports Used for Outgoing Messages" section on page 6-1 for more information.

Are Inbound Calls Failing?

In the Calls grid of the BANANA admin, click the ExitCode column header to sort the calls by exit code. Calls that completed successfully have "OK" listed in the ExitCode column. Calls that did not complete successfully have an error code (a number beginning with an "E") listed in the ExitCode column.

For each call in the Calls grid that encountered an error, a record exists in the Errors grid. This record provides specific details about the condition under which the call was terminated, including the state of the protocol that was in process, and the reason that the call could not be completed. When you click a call with an error code in the Calls grid, the corresponding record is highlighted in the Errors grid. The record in the Errors grid lists the exit code, call state, and reason for the call failure.

If the inbound call completed successfully, a copy of the message should be saved to the Bridge\VPIM\Internet\Out and Bridge\VPIM\Internet\Out\Tmp directories.

The message will stay in the Bridge\VPIM\Internet\Out\Tmp directory only for the number of days that is set in the Retention Days for Temporary SMTP Messages setting on the Digital Networking page of the Bridge Administrator. The message will stay in the Bridge\VPIM\Internet\Out directory until it is successfully delivered via SMTP.

Messages that the Bridge could not deliver are stored in Bridge\VPIM\Internet\Out\Failed. Note that when the Bridge saves a message to the Failed directory, it also logs a message in the Event Viewer Application log. So check both the Failed directory and the Event Viewer.

•The DTMF duration and interdigit timing settings for Cisco Unified CM and gateways have been set to 100 milliseconds. (Any value within the range 80 and 100 milliseconds is fine.) In some versions of Cisco Unified CM, the default value for the H225 DTMF Duration parameter is 300 milliseconds, which causes problems for the Bridge. See the applicable Cisco documentation for details on locating and changing the applicable parameters in Cisco Unified CM and the gateways.

If the above steps do not fix the problem, refer back to BANANA admin, as described below. Table 7-4 maps error codes to configuration problems and other problems that result in inbound call failures.

Table 7-4 Configuration and Other Problems That Result in Inbound Call Failures

Error Code

Description

E00020005

On an inbound call, after the Bridge plays the opening prompt, it expects to receive the BD handshake tones from the calling node. When the Bridge answers an incoming call but no BD is received:

•This may indicate that the calling Octel has not detected that the Bridge answered, due to poor line quality or problems with audio in the Bridge to Octel direction.

•Check to see whether the digits received were CD (a wake-up packet) and/or if the following warning appears in the Event Viewer Application log:

Event Type: WarningEvent Source: BridgeEvent Category: NoneEvent ID: 108Bridge received an incoming call that could not be processed. The calling server does not have a Serial Number defined in its Bridge node profile.Verify that all remote servers configured to communicate with Bridge have Serial Numbers for allBridge nodes.

Receipt of a wake-up packet of CD indicates that the calling Octel server does not have the serial number of the Unity recipient node defined in the applicable network node profile. The Octel is requesting the serial number from the Bridge. Because the Bridge can proxy for more than one serial number within the Octel network, the Bridge cannot respond with a serial number. The calling Octel must have the serial numbers for the Unity nodes configured in the applicable network node profiles prior to calling the Bridge.

•The Octel servers are running a supported protocol. The Octel servers must be running Octel analog networking. Neither Octel digital networking nor the VOICENET protocol is supported by the Bridge.

E00020014

If the calling Octel server does not have the Cisco Unity node serial number defined in its node configuration, the Bridge hangs up immediately when it receives a call from the Octel node. Additionally, the Bridge logs the following warning to the Windows Event Log:

Event Type: WarningEvent Source: BridgeEvent Category: NoneEvent ID: 108Bridge received an incoming call that could not be processed. The calling server does not havea Serial Number defined in its Bridge node profile.Verify that all remote servers configured to communicate with Bridge have Serial Numbers forall Bridge nodes.

Because the Bridge requires the Cisco Unity node serial number to be configured on the Octel server, you must define the serial number for the Cisco Unity node in the node profile on the Octel server.

E00040013

On an inbound call from an Octel to the Bridge, after the Bridge receives the BD handshake tones and sends the CDD handshake response, it expects to receive an encrypted string of 18 DTMF digits that includes the serial number of the node that the Octel is attempting to communicate with. If the Bridge hangs up without sending a response, it is possible that the serial number that was sent from the Octel did not match any of the Unity Node profiles configured on the Bridge.

On the Bridge server, verify that the serial number on each Unity Node is correct, and that a Unity Node with the correct serial number has been created for each node that the Bridge represents within the Octel network.

If the serial numbers in the Unity Node profiles on the Bridge are correct, then the calling Octel may be sending an incorrect serial number. At this point in the call, the Bridge does not know the serial number of the calling Octel server. The easiest way to find out which Octel called is to look at Cisco Unified Communications Manager or PBX log files. If you do not have access to the phone system log files, and if there are only a few Octel servers in the network, then all of the node profiles on each Octel server can be checked for an incorrect serial number. However, when there are many Octel servers in the network, checking every node profile on every Octel server to find an incorrect serial number when you do not know the number you are looking for can be very time consuming. If this error appears repeatedly, the following steps may help to determine the serial number that the calling Octel was attempting to contact.

1. Browse to the \Bridge\Starfish\Log directory on the Bridge server.

2. In Notepad, open the sflog.*.log for the period during which the behavior has been observed.

3. Search for the string Initial Handshake Failed. You should see a sequence of events similar to the following:

Line 4: Call Received.Line 4: Playing 1.sphLine 4: Received BDLine 4: Playing CDDLine 4: Received 12*D8#93697B08#CB*Line 4: Initial handshake failed. Received either bad data or a request to communicate witha node that is not yet configured on Bridge.Line 4: ReceivedLine 4: Incoming Call Completed.

Because Octel analog networking packets are encrypted, you cannot determine the serial number of the node that the Octel is attempting to communicate with by looking at the DTMF packet. But there is a decryption utility on the Bridge server that can be used to determine the serial number. For the decryption utility to work, you will need to find two occurrences of this handshake failure in the log file.

4. Copy the DTMF packet from the "Received" line that appears immediately after "Playing CDD" for both occurrences. (In the example above, you would copy the packet 12*D8#93697B08#CB*, and if the above example included another occurrence of the handshake failure, you would also copy that DTMF packet.)

5. On the Bridge server, open a command prompt window and change to the directory where starfish.exe is located. (The default location is \Bridge\Starfish\Bin.)

E00040013, continued

6. At the command line in the bin directory, enter the following command:

starfish -p <packet1> <packet2>Where <packet1> is the DTMF packet copied from the "Received" line of the first occurrence and<packet2> is the DTMF packet copied from the "Received" line of the second occurrence.

The utility returns the possible matches for the serial number of the node that is being called. It is possible that the utility will return 30 or more matches, but most of them can be eliminated as possibilities because they contain more than 5 digits. For example:

It is unlikely that you will ever encounter an Octel node with a serial number longer than 5 digits, so you can consider any matches greater than 5 digits to be invalid. In the above example, that leaves only 14801, 20953, 80337 and 86489 as potential matches. At this point, the list is small enough that you should be able to determine which of these serial numbers should be configured as a Unity Node on the Bridge, or which serial number may have been configured in error on the network profile of an Octel node.

E00160010

Confirm that the Octel node with which the Bridge communicates supports the fax feature.

E00160099

Confirm that all gateway and phone system devices between the Octel and the Bridge support fax transmission.

Do Inbound Messages Reach the Voice Connector?

When a message has reached the Bridge\VPIM\Internet\Out directory, it will wait there until it is delivered to the Voice Connector via SMTP. Usually, a message will arrive in the Bridge\VPIM\Internet\Out directory and leave the directory again within one minute, so you may not even see it. (Note however that a copy of the message should be saved to the Bridge\VPIM\Internet\Out\Tmp directory if you have set the Retention Days for Temporary SMTP Messages setting on the Digital Networking page to a value greater than 0.)

To Verify That a Message Gets to the Voice Connector

Step 1 Log on to the Exchange server on which the Voice Connector is installed.

Step 2 Open the GwIvc_<Date>.log. The default location for the Voice Connector log files is <Exchange Server Path>\VoiceGateway\LogFiles.

Step 3 Check the log during the time that the message was sent for any inbound messages similar to "Processing incoming OMNI address message." If there are no inbound messages, the message did not reach the Voice Connector.

Troubleshooting Why the Voice Connector Does Not Receive Messages from the Bridge

Step 1 In a command prompt window on the Bridge server, enter the command nslookup <Exchange/SMTP Server>, where <Exchange/SMTP Server> is the fully qualified domain name of the Exchange/SMTP server that handles incoming SMTP messages.

Step 2 If the returned response is Non-Existent Domain, check the configuration of the DNS zones where the servers are located. Make any necessary changes so that the fully-qualified domain name of the Exchange/SMTP server is recognizable from the zone in which the Bridge server is located.

Step 7 If you see the message 220 <ESMTP Server + domain> Microsoft ESMTP Mail Service, Version: <Version number> Ready at <Date and time>, you do not need to identify a separate ESMTP server name in the Bridge configuration.

If you see the error message Connection to <Unity SMTP Mail Suffix>...Could Not Open a Connection to Host on Port 25: Connect Failed, you need to enter an ESMTP server in the Digital Networking configuration on the Bridge server. You should be able to telnet to the ESMTP server on port 25.

•Verify that the relay of messages is not restricted from the Bridge server to the Exchange SMTP servers. Depending on your network configuration, you may need to manually enter a DNS MX record for the Exchange server in order to allow SMTP message delivery to it, but usually this is not necessary.

•Look in the SMTP logs to see if any errors are reported.

•Use Exchange Message Tracking in the Exchange System Manager to see whether the message is reaching Exchange at all. The message will be addressed to the Voice Connector in the format (IMCEAOMNI-AvVoiceMessage@<Unity SMTP Mail Suffix>).

•Are messages stuck in the MTS-IN and MTS-OUT queues? Do one of the following procedures, as applicable:

Step 3 Expand the Servers container, and then expand the server on which the Voice Connector is installed.

Step 4 Within the server container, click Queues. You should see AvExchangeIVC<Server name> listed in the pane on the right.

Step 5 Double-click AvExchangeIVC<Server name>. A queue window opens.

Step 6 Click Find Now to see all of the messages that are in the queue.

•Check the Windows Event Viewer System and Application logs for errors or warnings on the Bridge server and on the Exchange server on which the Voice Connector is installed.

•Check to see whether, after entering the Windows 2000 SMTP server, e-mail entering your Exchange organization is re-routed to a smart host, non-Exchange corporate SMTP relay server, secure e-mail server, or any other traffic filtering server that may not route incoming SMTP messages to the Voice Connector in Exchange. In particular, this may be an issue when Exchange is using a shared Domain Name Space where Exchange is not configured as authoritative for this address. If this is true in your circumstance, a special Recipient Polity for the Voice Connector and an Exchange SMTP connector can be configured to send only those message addressed to the Voice Connector from the Bridge directly to the Voice Connector without being re-routed. See the following procedures:

Caution Consult the Exchange administrator for your organization before doing the following procedures. Miscommunication of the Recipient Policies and/or the SMTP connector could result in problems routing other SMTP mail for the organization.

To Create a Special Recipient Policy for the Voice Connector

Step 1 On the Exchange server on which the Voice Connector is installed, open the Exchange System Manager. (The Recipient Policy must be created on the Exchange server on which the Voice Connector is installed.)

Note If you need to make the change to a lot of Unity Nodes, you can use the Cisco Unity Bridge Bulk Node utility. The utility is available for download from the Cisco Unity Tools website at http://www.ciscounitytools.com. For details on the Bulk Node utility, see the Readme.htm file that is included with the utility.

Step 5 Open the Services applet on the Bridge Server, and restart the Digital Networking service.

To Configure an Exchange SMTP Connector to Route Messages from the Bridge Server Directly to the Voice Connector

Step 1 On the Exchange server on which the Voice Connector is installed, open the Exchange System Manager.

Step 2 Expand the tree in the left pane to view the Connectors directory. On some servers the Connectors directory will be in the Organization root. On others, most notably where multiple Routing Groups are being used, you will need to be sure to select the Connectors directory under the Routing Group in which the Voice Connector is installed.

Step 3 Right-click Connectors and click New > SMTP Connector.

Step 4 On the General tab, enter a meaningful name.

Step 5 On the General tab, select Forward All Mail Through This Connector to the Following Smart Hosts. In the field below, enter the IP address of the Exchange server on which the Voice Connector is installed, enclosed in square brackets (for example, "[10.10.255.1]").

Step 6 On the General tab, click Add.

Step 7 Select the server on which the Voice Connector is installed and click OK to set this as the bridgehead server for the SMTP connector.

Step 14 Send a test voice message from Octel to a Cisco Unity subscriber to see whether the message is delivered.

Step 15 Send a test e-mail to an outside address to verify that e-mail still works.

Troubleshooting Voice Message Flow from the Voice Connector to the Subscriber Mailbox

Follow the steps in this section when voice messages make it to the Voice Connector, but are not delivered to the subscriber mailbox.

•Open the GwIvc.log and look for any errors about the incoming message. Troubleshoot any errors that are displayed.

•On the Exchange server on which the Voice Connector is installed, look in the Windows Event Viewer System and Application logs. Look for warnings or errors. In particular, look for warnings or errors that indicate that messages have been returned because of invalid attachments.

Step 1 On the Exchange server on which the Voice Connector is installed, in the Exchange System Manager under the Connectors subtree, right-click AvExchangeIVC_<Machine name>, and select Properties.

Step 2 When the Exchange System Manager Cleanup Agent has been run, the name of the Voice Connector changes to Exchange 2000 Voice Connector (<Machine name>).

Step 3 Click the Address Space tab and confirm that a type OMNI is listed with an Address of * and a Cost of 1.

Step 4 Confirm that the Connector Scope is set to Entire Organization.

•If the Voice Connector is not installed in the same routing group as the mailbox of the subscriber who sent the message, verify that Exchange routing group connectors are properly set up to route messages between the groups.

•Use Exchange message tracking to follow the message through Exchange and determine why it was not delivered.

After You Finish Troubleshooting

When finished troubleshooting, you should reset most of the logs and traces back to their defaults. However, leave the call tracing level on the System Settings page in the Bridge Administrator set to Verbose, as this call tracing level is required by BANANA.

Caution Logs and traces that you enable on the Bridge server, on the Exchange server on which the Voice Connector is installed, and on the Cisco Unity server can take up a great deal of hard disk space. Disable the logs and traces when you finish troubleshooting, with the exception of the call traces (also referred to as the starfish logs) on the Bridge server.

Reset the following logs and traces:

•In the Bridge Administrator, on the Digital Networking page:

–Reset the Retention Days For Temporary SMTP Messages back to 0 (zero). (These messages consume significant hard disk space, so you should always configure this setting to zero unless you are troubleshooting and monitoring hard disk consumption.)

–Reset the Tracing Level back to None. (Typically, these logs do not consume significant hard disk space, so you may choose to leave the Tracing Level set to Flow.)

•In the Exchange System Manager:

–Reset the Voice Connector Logging Level back to Warning. (You may choose to leave these logs set to the Information level, which provides more detail than the Warning level. With logging at the Information level, you should monitor the hard disk space consumed by the log files. You may need to adjust the Log Recycle Days setting or set a limit for the hard disk space allowed for the logs.)

–Disable Exchange message tracking. (You may choose to leave message tracking enabled. Monitor occasionally to make sure that no more than the available hard disk space is consumed for storage of these logs.)

–Disable SMTP logging. (You may choose to leave these logs enabled. Monitor occasionally to make sure that no more than the available hard disk space is consumed for storage of these logs.)

Directory Messages Are Not Processed

If voice messages between Cisco Unity and the Octels are delivered successfully in both directions, chances are that directory messages will be also be delivered successfully. As Figure 7-5 and Figure 7-6 illustrate, the trouble spots are similar. However, if you do encounter a problem with directory messages, see the "CsBridgeConnector Traces" section for information on enabling the traces on the Cisco Unity bridgehead server.

If directories get out of synch, see the following sections for information on how to force full synchronizations:

Step 7 After the problem reoccurs, or sufficient time has passed to gather message data, in the tree in the left pane of the Unity Diagnostic tool, click Processes > AvCsMgr, and click the Current log file to view it.

Full Synchronization of Bridge Subscribers with Octel Node Directories

If the Octel node directory (or directories) on the Bridge server becomes out of synch with Cisco Unity, you can force the Cisco Unity bridgehead server to request that all Bridge servers send their entire Octel node directories to the Cisco Unity bridgehead server, which updates the Bridge subscriber information in Cisco Unity. For large directories, the process of synchronizing Bridge subscriber data with the Octel node directories may take several hours to complete. Subscribers can still send and receive messages while the directories are synchronizing.

Full Synchronization of Cisco Unity Subscribers with the Unity Node Directories

For directory data about newly-created subscribers to be automatically sent to the Bridge, you first create the subscribers in Cisco Unity, and then create corresponding Unity Nodes on the Bridge. If you do the reverse and create a Unity Node on the Bridge before creating any subscribers with the same serial number, you will have to force a synchronization.

During normal operation, Cisco Unity automatically synchronizes subscriber information with the Bridge on a regular basis. When a subscriber account is added, deleted, or modified, Cisco Unity sends the account information to the Bridge. The Bridge makes this information available to other Octel nodes when they make an administrative call to retrieve the voice and text names of Cisco Unity subscribers.

You may want to force synchronization if the Cisco Unity server, the Bridge, or the network connection to the Bridge has been down for a period of time, and if there have been numerous changes to subscriber information in Cisco Unity.

Directory synchronization does not affect messaging. Subscribers can still send and receive messages when the directories are not synchronized.