Table Of Contents
Cisco Unity Bridge Troubleshooting
Overview: Bridge Troubleshooting
Common Configuration Problems
Messages Are Not Delivered from Cisco Unity to Octel
Before You Begin
Troubleshooting Why Messages Are Not Delivered from Cisco Unity to Octel
Do Messages Get to the Bridge?
Are Calls Attempted?
Are Dialouts Successful?
Does Octel Answer?
Are Handshakes Successful?
Are Any Messages Transmitted Successfully?
Does the Voice Connector Receive Messages?
Does the Voice Connector Hand Off Messages to Exchange?
Do the Exchange SMTP Outgoing Queues Send Messages?
Messages Are Not Delivered from Octel to Cisco Unity
Before You Begin
Troubleshooting Voice Message Flow from the Octel Node to the Bridge Server
If the Message Was Received by the Bridge
Troubleshooting Voice Message Flow from the Bridge Server to the Voice Connector
Troubleshooting Voice Message Flow from the Voice Connector to the Subscriber Mailbox
Directory Messages from Cisco Unity to the Bridge Are Not Processed
Before You Begin
Directory Messages from the Bridge to Cisco Unity Are Not Processed
Before You Begin
Bridge Troubleshooting Tools
Tools for Troubleshooting Problems on the Bridge Server
Tools for Troubleshooting Problems with the Voice Connector
Tools for Troubleshooting Problems in Exchange
Tools for Troubleshooting Directory Synchronization Problems on the Cisco Unity Server
Enabling and Interpreting Traces for the Brooktrout TR114 on the Bridge
Enabling Debug Traces for the Brooktrout TR114
Disabling Debug Traces for the Brooktrout TR114
Interpreting Debug Traces for the Brooktrout TR114
Potential Bridge Analog Protocol Communication Problems and Applicable Workarounds
Condition A: Echoed Outbound DTMF Digits Are Being Detected as Inbound
Example:
Explanation
Workaround
Condition B: Inbound "9" DTMF Response to Post-Record Outbound "8" DTMF Is Not Detected
Example
Explanation
Workaround
Additional Notes
Cisco Unity Bridge Troubleshooting
Overview: Bridge Troubleshooting
See the following sections for information about troubleshooting message delivery and directory synchronization problems that occur between Cisco Unity and the Bridge:
•
Common Configuration Problems
•Messages Are Not Delivered from Cisco Unity to Octel
•Messages Are Not Delivered from Octel to Cisco Unity
•Directory Messages from Cisco Unity to the Bridge Are Not Processed
•Directory Messages from the Bridge to Cisco Unity Are Not Processed
•Bridge Troubleshooting Tools
•Enabling and Interpreting Traces for the Brooktrout TR114 on the Bridge
•Potential Bridge Analog Protocol Communication Problems and Applicable Workarounds.
Common Configuration Problems
If you have just configured Cisco Unity and the Bridge for networking, and you encounter problems, review the "Task List: Setting Up Cisco Unity and the Bridge for Networking" section on page 1-2, and the "Procedures for Setting Up Networking Between Cisco Unity and the Bridge" section on page 1-3. Also review the information in the "Notable Behavior" section on page 1-67.
Note the following common configuration problems:
•The Octel server is not supported, or is running the wrong protocol. The only supported Octel servers are those listed in Cisco Unity Bridge System Requirements, and Supported Hardware and Software. This document is available on Cisco.com at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_pre_installation_guides_list.html. In addition, the Octel servers must be running Octel Analog Networking. Neither Octel Digital Networking nor the VOICENET protocol is supported by the Bridge.
•The Cisco Unity bridgehead server is not licensed for Bridge ports. This causes the following problems:
–The CsBridgeConnector service fails to start.
–On the Primary Location page in the Cisco Unity Administrator, the Unity Bridge Server Address and Node ID fields are not accessible.
•The Active Directory schema was not extended. Confirm that the schema was successfully extended by checking the log file that ADSchemaSetup creates on the desktop.
•There are problems resolving the name of the Bridge server. 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. See the "Configuring the Bridge" section on page 1-15 for more information.
•The wrong version of the Voice Connector was installed. The Voice Connector for Exchange 2000 is the only Voice Connector supported. Confirm that you installed the correct version. Additionally, for installations running Cisco Unity 3.1(3) - 3.1(5) and 4.0(1), we recommend that you download the most recent 10.0(x) version of the Voice Connector for Exchange 2000, as described in the ""To Download the Voice Connector (Cisco Unity 3.1(3) - 3.1(5) and 4.0(1) Only)" section on page 1-7."
•The Active Directory Connector was incorrectly configured. In organizations where both Exchange 5.5 and Exchange 2000 co-exist, 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.
•The UOmni mailbox was not created. Without this mailbox, directory synchronization between the Bridge and Cisco Unity will not take place.
•The Unity Bridge Node ID on the Primary Location page in the Cisco Unity Administrator contains an incorrect number. The Unity Bridge Node ID field must match the Serial Number parameter in the Unity Node Configuration page in the Bridge Administrator, and must also be entered correctly on each Octel node with which the Bridge communicates.
•The Unity Bridge Server Address field on the Primary Location page in the Cisco Unity Administrator does not contain the fully-qualified domain name of the Bridge server with which this Cisco Unity server is associated. The name must exactly match the name specified as the Cisco Unity Bridge Domain Name on the Digital Networking page in the Bridge Administrator. Both of these must match the name displayed in the Windows System Control Panel on the Network Identification tab in the Full Computer Name field on the Bridge server.
•Search scopes were incorrectly set. The Subscriber and Blind Addressing search scopes in the Cisco Unity Administrator on the Primary Locations > Addressing Options page must be set properly. This must be done for each server that is networked together.
•A Bridge delivery location was not correctly configured. For each remote Octel node, a Bridge delivery location must be configured in the Cisco Unity Administrator. The Octel Node ID on the Bridge delivery location page must match the Serial Number on the corresponding Octel Node configuration page in the Bridge Administrator. Both of these must match the serial number of the Octel Node.
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 hands it back to Exchange to be sent to the Bridge via SMTP. The Bridge converts the received VPIM message to an Octel message and sends it to the Octel node via analog lines.
Figure 2-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.
Figure 2-1 Troubleshooting Message Flow from Cisco Unity to Octel
Note the Bridge\In and Bridge\Out folders in Figure 2-1. These are transitional folders to which the SMTP side delivers messages for the analog side and vice versa.
•If the Digital Networking service is running, but the Unity Bridge service is not running, messages will queue in \Bridge\In until the Unity Bridge service is started and picks them up.
•If the Unity Bridge service is running, but Digital Networking service is not running, messages will queue in \Bridge\Out until Digital Networking service is started and picks them up.
Before You Begin
For installations running Cisco Unity 3.1(3) - 3.1(5) and 4.0(1), we recommend that you download the most recent 10.0(x) version of the Voice Connector for Exchange 2000, as described in the "To Download the Voice Connector (Cisco Unity 3.1(3) - 3.1(5) and 4.0(1) Only)" section on page 1-7.
Before you begin sending test messages, do all of the following procedures to enable the applicable logs, traces, and other troubleshooting tools:
•To Enable Troubleshooting Tools on the Bridge Server
•To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later)
•To Enable Message Tracking in Exchange 2000
•To Enable SMTP Logging in Exchange 2000
To Enable Troubleshooting Tools 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 a value greater than zero.
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 (Voice Connector 10.0 and Later)
Step 1 Log on to the Exchange server on which the Voice Connector is installed.
Step 2 From the Windows Start menu, click Programs > Microsoft Exchange > Exchange System Manager.
Step 3 Expand the Connectors container in the left-hand pane.
Step 4 Right-click Exchange 2000 Voice Connector (<server name>), and select Properties.
Step 5 Click the Advanced tab.
Step 6 In the Logging Level list, click Information.
Step 7 Click OK.
Step 8 In the Windows Services applet, right-click Exchange 2000 Voice Connector (<server name>), and select Restart.
To Enable Message Tracking in Exchange 2000
You need to enable message tracking on each Exchange server that participates in message delivery. This is 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.
Step 1 Open the Exchange System Manager. (From the Windows Start menu, click Programs > Exchange > Exchange System Manager.)
Step 2 Right-click the Exchange server on which you want to enable message tracking, and select Properties.
Step 3 Check Enable Message Tracking.
Step 4 Click OK.
Step 5 Repeat Step 1 through Step 4 for each Exchange server that participates in message delivery.
To Enable SMTP Logging in Exchange 2000
Step 1 Open the Exchange System Manager.
Step 2 In the left-hand pane, expand Servers > <server where Voice Connector is installed> > Protocols > SMTP.
Step 3 Right-click the Default SMTP Virtual Server (or any other SMTP Connector that may be routing mail) and select Properties.
Step 4 Check Enable Logging.
Step 5 In the Active Log Format list, click NCSA Common Log File Format.
Step 6 Click Properties and enter the location for the log file.
Step 7 Click OK twice and close the Exchange System Manager.
After all the troubleshooting tools are set up, send a test message from a Cisco Unity subscriber to a remote Octel subscriber. Then go to the "Troubleshooting Why Messages Are Not Delivered from Cisco Unity to Octel" section for guidance on determining the cause of the problem.
When finished testing, you may want to reset some of the logs and traces back to their defaults:
•In the Bridge Administrator:
–On the Digital Networking page, reset the Retention Days For Temporary SMTP Messages back to zero. (These messages consume significant hard disk space, so you should always configure this setting to zero unless troubleshooting and monitoring hard disk consumption.)
–On the Digital Networking page, reset the Tracing Level back to None. (Typically, these logs do not consume significant hard disk space, so you may want to leave the Tracing Level set to Flow.)
–On the System Settings page, reset the Call Tracing Level back to None. (Typically, these logs do not consume significant hard disk space, so you may want to leave the Call Tracing Level set to Verbose.)
•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 no more than the desired 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 no more than the desired hard disk space is consumed for storage of these logs.)
Troubleshooting Why Messages Are Not Delivered from Cisco Unity to Octel
The flow chart in Figure 2-2 shows the troubleshooting steps. Table 2-1 contains links to topics based on the flow chart to guide you through the troubleshooting process.
Figure 2-2 Messages Are Not Delivered from Cisco Unity to Octel
Table 2-1 Message Are Not Delivered from Cisco Unity to Octel
Question
|
To Answer the Question...
|
If the Answer Is No...
|
If the Answer Is Yes...
|
Do Messages Get to the Bridge?
|
See the procedure, To Determine if Messages Get to the Bridge
|
See the section, No, Messages Do Not Get to the Bridge
|
See the section, Yes, Messages Get to the Bridge
|
Are Calls Attempted?
|
See the procedure, To Determine if Calls Are Attempted
|
See the section, No, Calls Are Not Attempted
|
See the section, Yes, Calls Are Attempted
|
Are Dialouts Successful?
|
See the procedure, To Determine if Dialouts Are Successful
|
See the section, No, Dialouts Are Not Successful
|
See the section, Yes, Dialouts Are Successful
|
Does Octel Answer?
|
See the procedure, To Determine if Octel Answers
|
See the section, No, Octel Does Not Answer
|
See the section, Yes, Octel Answers
|
Are Handshakes Successful?
|
See the procedure, To Determine if Handshakes Are Successful
|
See the section, No, Handshakes Are Not Successful
|
See the section, Yes, Handshakes Are Successful
|
Are Any Messages Transmitted Successfully?
|
See the procedure, To Determine Whether Any Messages Are Transmitted Successfully
|
See the section, No, Messages Are Not Transmitted Successfully
|
See the section, Yes, Messages Are Transmitted Successfully
|
Does the Voice Connector Receive Messages?
|
See the procedure, To Determine if the Voice Connector Receives Messages
|
See the section, No, the Voice Connector Does Not Receive Messages
|
See the section, Yes, the Voice Connector Receives Messages
|
Does the Voice Connector Hand Off Messages to Exchange?
|
See the procedure, To Determine if the Voice Connector Hands Off Messages to Exchange
|
See the section, No, the Voice Connector Does Not Hand Off Messages to Exchange
|
See the section, Yes, the Voice Connector Hands Off Messages to Exchange
|
Do the Exchange SMTP Outgoing Queues Send Messages?
|
See the procedure, To Determine if the Exchange SMTP Outgoing Queues Send Messages
|
See the section, No, the Exchange SMTP Queues Do Not Send Messages
|
See the section, Yes, the Exchange SMTP Queues Send Messages
|
Do Messages Get to the Bridge?
To Determine if Messages Get to the Bridge
Step 1 On the Bridge server, browse to \bridge\vpim\xcode\inbound\tmp.
Messages are saved in this folder when the Retention Days For Temporary SMTP Messages field on the Digital Networking page in the Bridge Administrator is set to a value greater than zero.
Step 2 If there are messages in this folder, SMTP messages are being successfully sent from Exchange to the Bridge server.
No, Messages Do Not Get to the Bridge
See the "Does the Voice Connector Receive Messages?" section.
Yes, Messages Get to the Bridge
See the "Are Calls Attempted?" section.
Are Calls Attempted?
To Determine if Calls Are Attempted
Step 1 On the Bridge server, browse to \bridge\starfish\log.
Note To obtain the needed information from the logs, the Call Tracing Level field on the System Settings page in the Bridge Administrator must be set to Verbose. Logs for analog activity are stored in this folder, 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).
Step 2 Open the log file for the time period in question.
Step 3 Look for messages with the syntax Call Out Process Initiated for Node <node#> Window Type <windowType>, where:
•<node#> is the destination Octel node serial number
•<windowType> is 0, 1, or 2
–0=normal priority voice messages
–1=urgent priority voice messages
–2=administrative (text/voice name retrieval) calls
These messages indicate that the Bridge is checking the queue to see if it is necessary to place an analog call to the specified node and window type. The line following the message indicates if a call is being attempted, as follows:
•If the line following the message is "No messages to deliver" or "No names to retrieve," calls are not being attempted. See the "No, Calls Are Not Attempted" section.
•If the line following the message is anything else, an analog call is being attempted to the specified node. See the "Yes, Calls Are Attempted" section.
Yes, Calls Are Attempted
See the "Are Dialouts Successful?" section.
No, 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 card(s) 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?—On the Bridge server, 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.
In Bridge 2.1(4), the Line Status page in the Bridge Administrator reports if a line has been retired.Whenever a problem occurs that prevents the Bridge from initiating an outgoing analog call on a particular analog port—for example, line cord not plugged in or no dial tone from the phone system—if the same problem happens 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 <CmdArg>X<noCmdArg>: Retired for callouts." This port is now unavailable for outgoing calls. However, if the same port receives an incoming call and connection is successful, the port is put back into service for both incoming and outgoing calls, and another warning appears in the Application Event Viewer: "Line <CmdArg>X<noCmdArg>: 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: "Line(s) 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 via the Services Control Panel.
Are Dialouts Successful?
To Determine if Dialouts Are Successful
Step 1 Look at the same Call Out Process Initiated for Node <node#> Window Type <windowType> lines in the sflog file that you opened in the procedure, To Determine if Calls Are Attempted. If the call is attempted, this line will be followed by another line indicating the status of the call. There are four possibilities:
•Call Status=Answer—The dialout was successful, and the call was successfully answered by the destination Octel node.
•Call Status=Ring No Answer—The dialout was successful, but the destination Octel node did not answer.
•Call Status=Busy—The dialout was successful, but the destination Octel node was busy.
•Call Status=Line Error—The dialout was not successful. The Bridge encountered an error with the analog port or line prior to successfully dialing the phone number.
No, Dialouts Are Not Successful
•Is the correct phone number defined?—In the Bridge Administrator, go to the Octel Node configuration page for each node. Confirm that the Phone Number, Extension and Dial Sequence fields contain correct information.
•Is the dialout successful when you dial the Octel node manually?—Plug an analog phone into the lines going to the Bridge, and dial the Octel node manually.
•Are long distance calls blocked?—If the call to the Octel node is long distance, confirm that long distance calls are not blocked by the phone system on the lines the Bridge is using.
Yes, Dialouts Are Successful
See the "Does Octel Answer?" section.
Does Octel Answer?
To Determine if Octel Answers
Step 1 Look at the same Call Out Process Initiated for Node <node#> Window Type <windowType> lines in the sflog file that you opened in the procedure, To Determine if Calls Are Attempted. If the call is attempted, this line will be followed by another line indicating the status of the call. There are four possibilities:
•Call Status=Answer—The dialout was successful, and the call was successfully answered by the destination Octel node.
•Call Status=Ring No Answer—The dialout was successful, but the destination Octel node did not answer.
•Call Status=Busy—The dialout was successful, but the destination Octel node was busy.
•Call Status=Line Error—The dialout was not successful. The Bridge encountered an error with the analog port or line prior to successfully dialing the phone number.
No, Octel Does Not Answer
•Is the correct phone number defined?—In the Bridge Administrator, go to the Octel Node configuration page for each node. Confirm that the Phone Number, Extension and Dial Sequence fields contain correct information.
•Does Octel answer when you dial the Octel node manually?—Plug an analog phone into the lines going to the Bridge, and dial the Octel node manually.
Yes, Octel Answers
See the "Are Handshakes Successful?" section.
Are Handshakes Successful?
To Determine if Handshakes Are Successful
Step 1 In the sflog file that you opened in the procedure, To Determine if Calls Are Attempted, look for the status line Call Status=Answer. This indicates that the dialout was successful, and the call was successfully answered by the destination Octel node.
Step 2 Look for the next event for this line, which should be Playing BD. This indicates that the Bridge has detected the prompt on the Octel system and is now playing the analog DTMF digits B and D to indicate to the Octel that this is an Octel analog networking call.
Step 3 Following the Playing BD line, look for a line that contains Received CDD. By transmitting the CDD DTMF string, the Octel system indicates that it recognizes this call as an Octel analog networking call and is ready to receive the next DTMF packet.
If instead you see a line that contains Received CC, this indicates that the Octel node is using the VOICENET protocol, which is not supported. The Octel servers must be running Octel analog networking.
Step 4 After two more packets are exchanged in each direction you should see a line indicating Call established from Serial # <Unity/BridgeSerial#> to Serial # <OctelSerial#>. This indicates that the handshake was successful.
Note It is not uncommon to occasionally see the Playing BD line two or three times before the Octel system responds with CDD.
No, Handshakes Are Not Successful
•Is the destination Octel node serial number correct?—In the Bridge Administrator, go to the appropriate Octel Node configuration page. Confirm that the number in the Serial Number field matches the serial number for the destination Octel node.
•Is the serial number for the Unity node correct?—In the Bridge Administrator, go to the Unity Node configuration page. Confirm that the number in the Serial Number field matches the serial number entered in the Octel system. The serial number must be entered on each Octel node.
Yes, Handshakes Are Successful
See the "Are Any Messages Transmitted Successfully?" section.
Are Any Messages Transmitted Successfully?
To Determine Whether Any Messages Are Transmitted Successfully
Step 1 In the sflog file that you opened in the procedure, To Determine if Calls Are Attempted, look for Message Delivered. This line indicates that a message was successfully delivered to the Octel system. There can be multiple messages delivered on the same call, so each Message Delivered line indicates the successful delivery of the message identified on the Sending Message line that precedes the Message Delivered line.
Following is an excerpt from an sflog of a successfully delivered message:
Line 11: Sending Message from mailbox 60032@NYUnityServer5 to mailbox
70044@BridgeServer1.paris.cisco.com
Line 11: Playing D:\Bridge\Starfish\In\80007\86364\935105e7-c584-4167-a0ce-d5b42def44fe
Line 11: Playing completed
Line 11: Message Delivered
The excerpt shows that the message was successfully delivered to the Octel system. If the call abnormally terminates subsequent to these events, it will not affect the delivery of this particular message, and the delivery for this message will not be retried.
No, Messages Are Not Transmitted Successfully
•Does the target mailbox ID of the message correspond to a valid user mailbox on the Octel system?—In the sflog file, confirm that the target mailbox ID on the Sending Message line corresponds to a valid mailbox number on the Octel node.
•Were there line problems?—In the sflog file, search for the phrase "Encountered communication problems with this node." This phrase can indicate poor line quality or DTMF protocol miscommunications. Confirm the quality of the line. Use an analog digit grabber to monitor the DTMF digit durations and inter-digit delays—they should be between 60ms and 120ms.
•Are the messages in the correct format?—In the sflog file, confirm that there is no line indicating the message was in an unsupported format. The Bridge can play messages sent from Cisco Unity in either G.711 or G.729 format.
Yes, Messages Are Transmitted Successfully
If messages are transmitted successfully to the Octel node, but are not delivered to the Octel subscriber, troubleshoot the problem on the Octel node.
Does the Voice Connector Receive Messages?
If messages do not get to the Bridge, the next step is to determine whether the messages get to the Voice Connector by examining the Voice Connector log file. Following are the logs for a successfully processed Cisco Unity to Bridge voice message, with the logging level set to Information:
11/05/02 10:43:09 0F7C INFO (hr=0) Add into message Queue. Message
ID=0000000066C1F96DCBA37C42A5BA14840DE0E8E801002B64AC613589294A90D1C7766DAB1D440000000233AC0000 (LINE=71
FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\AvMessageQueue.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) **** [OUT] Processing message of class [ENVELOPE.IPM.NOTE] ****
(LINE=598 FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\GwIvc.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) CAvOmniDelivery::SendOutOmniMessage: !!!!! Processing Outgoing OMNI
Voice message !!!!!! (LINE=124
FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\OmniDelivery.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) Get User Information for User: /O=JDC2ORG/OU=FIRST ADMINISTRATIVE
GROUP/CN=RECIPIENTS/CN=USR_89000 (LINE=44
FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\AvADUserHomedServer.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) CAvOmniOutMessage::Init: CAvOmniOutMessage:: (MESSAGE)
Sender(/O=JDC2ORG/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=USR_89000). Extension Found= 89000 (LINE=368
FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\AvOmniOutMessage.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) SECURITY :: Check Security for Unity server = (JDC2) (LINE=118
FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\AvBridgeSecurity.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) SECURITY :: Unity Server (JDC2) : Bridge Ports=4. Unity Ports=24
(LINE=129 FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\AvBridgeSecurity.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) Delivered file to SMTP via C:\Program Files\Exchsrvr\Mailroot\vsi
1\pickup\OMN93.tmp (LINE=347 FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\OmniDelivery.cpp)
11/05/02 10:43:09 0F7C INFO (hr=0) Remove from message Queue. Message
ID=0000000066C1F96DCBA37C42A5BA14840DE0E8E801002B64AC613589294A90D1C7766DAB1D440000000233AC0000 (LINE=101
FILE=e:\views\cs_ue4.0.0.277\un_Doh3\ExVoiceGateway2000\GwIvc\AvMessageQueue.cpp)
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.
Examine the Voice Connector log file as described in the next procedure, To Determine if the Voice Connector Receives Messages. Note that the Voice Connector logging level must be set to Information (or Function) as described in the procedure, To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later).
To Determine if the Voice Connector Receives Messages
Step 1 Log on to the Exchange server on which the Voice Connector is installed.
Step 2 Browse to the folder <ExchangeServerPath>\VoiceGateway\logFiles.
Step 3 Open the Voice Connector log file GwIvc_<date>.log. The <date> will be rendered as YyMmDd, where Yy in the year, Mm is the month, and Dd is the day.
Note Be sure to open the correct log file. In this folder, you will also find a Voice Connector performance log file called GwIvc_perf_ YyMmDd.log. The performance log file cannot be used in this procedure.
Step 4 Search for a line containing !!!!!! Processing Outgoing OMNI Voice message !!!!!!
•The presence of this line confirms that the Voice Connector is receiving messages. See the "Yes, the Voice Connector Receives Messages" section.
•The absence of such a line indicates that the Voice Connector is not receiving messages. See the "No, the Voice Connector Does Not Receive Messages" section.
No, the Voice Connector Does Not Receive Messages
•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 a subscriber who sent a message which was not delivered to another subscriber whose mailbox is on the same server on which the Voice Connector is installed.
•Are the Voice Connector settings correct?—Do the procedure, To Verify Voice Connector Settings.
To Verify Voice Connector Settings
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.
Yes, the Voice Connector Receives Messages
See the "Does the Voice Connector Hand Off Messages to Exchange?" section.
Does the Voice Connector Hand Off Messages to Exchange?
If a line containing "!!!!!! Processing Outgoing OMNI Voice message !!!!!!" appears in the GwIvc_<date>.log file, do the procedure, To Determine if the Voice Connector Hands Off Messages to Exchange. 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 if the Voice Connector Hands Off Messages to Exchange
Step 1 In the GwIvc_<date>.log file, locate the line containing !!!!!! Processing Outgoing OMNI Voice message !!!!!! 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 the following, which indicates who the message is from:
...INFO...Get User Information for User:
and
...INFO...Extension Found...
Step 2 Within the next few lines, look for a line containing the following:
...INFO...Delivered file to SMTP
and
...INFO...Rmove from message Queue
•The presence of these lines indicates that the Voice Connector is sending messages back to Exchange. See the "Yes, the Voice Connector Hands Off Messages to Exchange" section.
•If these lines are not present, the Voice Connector is not sending messages back to Exchange. See the "No, the Voice Connector Does Not Hand Off Messages to Exchange" section.
No, the Voice Connector Does Not Hand Off Messages to Exchange
•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 "Address Message: Unknown Error, Check GwIvc_<date>.log...." This 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.
–Look for warnings such as: "Bridge Security Error. Unity Ports < Bridge Ports." The number of Bridge ports licensed on the Cisco Unity bridgehead server must be a number greater than or equal to the number of enabled ports on the Bridge server. If the number of enabled ports on the Bridge server is greater than the number of Bridge ports licensed on the Cisco Unity bridgehead server, the Voice Connector will not allow messages to flow between the Bridge and Cisco Unity and Exchange. In this case, do the procedure, To Set the Correct Number of Ports on the Bridge Server.
To Set the Correct Number of Ports on the Bridge Server
Step 1 In the Bridge Administrator, go to the Line Status page, and disable ports on the Bridge server so that the number of enabled ports is less than or equal to the number of Bridge ports licensed on the Cisco Unity server.
Step 2 On the Bridge server, stop and restart the Unity Bridge service. The Voice Connector should now send messages.
Note Subsequently, if you increase the number of Bridge port licenses on the Cisco Unity server, in the Bridge Administrator, go to the Line Status page and re-enable the lines.
•Are messages stuck in the MTS-IN and MTS-OUT queues? Do the procedure, To Troubleshoot Messages Stuck in the MTS-IN and MTS-OUT Queues.
To Troubleshoot Messages Stuck in the MTS-IN and MTS-OUT Queues
Step 1 In the Exchange System Manager, look for AvExchangeIVC_<machine name> or Exchange 2000 Voice Connector (<servername>) under the Connectors subtree for your site.
Step 2 Look in the MTS-IN and MTS-OUT queues to see if any messages appear to be stuck.
Step 3 Restart the Exchange 2000 Voice Connector service by using the Services Control Panel.
Step 4 Confirm that the Simple Mail Transport Protocol (SMTP) service is running in the Services Control Panel.
Yes, the Voice Connector Hands Off Messages to Exchange
See the "Do the Exchange SMTP Outgoing Queues Send Messages?" section.
Do the Exchange SMTP Outgoing Queues Send Messages?
If the Voice Connector successfully processes messages and hands them off to Exchange, but messages still do not leave the Exchange SMTP outgoing queue, this indicates a problem with Exchange. Although some troubleshooting steps are provided below, you may need to refer to your Exchange documentation.
Additionally, refer to the "Troubleshooting" chapter of the Microsoft Exchange 2000 Server Resource Kit, which is available online through the Microsoft TechNet website.
To Determine if the Exchange SMTP Outgoing Queues Send Messages
Step 1 Check the Exchange SMTP log files to see if the messages from the Voice Connector are properly routed to the SMTP outgoing queue.
Step 2 In the Exchange System Manager, for each server in the organization, expand the <server>\Protocols\SMTP\Default SMTP Virtual Server\Queues subtree.
Step 3 Look for messages that appear to be stuck. Messages addressed to the Voice Connector will have a Recipient address beginning with either OMNI: or IMCEAOMNI-.
Step 4 In the Exchange System Manager, for each server in the organization, expand the <server>\Protocols\X.400\Queues subtree.
Step 5 Look for messages that appear to be stuck. Messages addressed to the Voice Connector will have a Recipient address beginning with either OMNI: or IMCEAOMNI-.
No, the Exchange SMTP Queues Do Not Send Messages
Use Exchange message tracking and look for messages with a Recipient address beginning with either "OMNI:" or "IMCEAOMNI-."
Yes, the Exchange SMTP Queues Send Messages
Do the following troubleshooting tasks when the Exchange SMTP queues send messages, but the Bridge does not receive them:
•Is the fully qualified domain name of the Bridge server entered correctly?—Do the procedure, To Verify That the 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 Primary Location page on the Cisco Unity bridgehead server (the server licensed for the Bridge).
Step 2 Confirm that the Server Address field for the Bridge is the fully qualified domain name of the Bridge server.
Step 3 Confirm that the name in the Server Address field exactly matches the Cisco Unity Bridge Domain Name in the Digital Networking page in the Bridge Administrator.
Step 4 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 5 From a command prompt 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 where 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 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 if e-mail leaving 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 SMTP messages on 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. See the procedure, To Configure an Exchange SMTP Connector to Route Messages Addressed to the Bridge Server Directly to the Bridge, for more information.
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 folder. On some servers the Connectors folder will be in the Organization root. On others, most notably where multiple Routing Groups are being used, you will need to make sure to select the Connectors folder 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. This 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, then click OK.
Step 13 Click OK to complete configuration of the SMTP connector.
Step 14 Send a test voice message from Cisco Unity to an Octel recipient to see if the message makes it to the Bridge.
Step 15 Send a test e-mail to an outside address to verify that e-mail still works.
Messages Are Not Delivered from Octel to Cisco Unity
This section provides some basic troubleshooting steps for identifying why a voice message is not delivered from an Octel node to the Cisco Unity node.
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 to the Voice Connector for Exchange 2000. From the Voice Connector, the voice message is delivered to the appropriate Cisco Unity subscriber Exchange mailbox. Note that the Cisco Unity server does not play a role in delivering voice messages from an Octel node to a Cisco Unity node.
Figure 2-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.
Note the Bridge\In and Bridge\Out folders in Figure 2-3. These are transitional folders in which the SMTP side delivers messages for the analog side and vice versa.
•If the Digital Networking service is running, but the Unity Bridge service is not running, messages will queue in \Bridge\In until the Unity Bridge service is started and picks them up.
•If the Unity Bridge service is running, but Digital Networking service is not running, messages will queue in \Bridge\Out until Digital Networking service is started and picks them up.
Figure 2-3 Troubleshooting Message Flow from Octel to Cisco Unity
Before You Begin
For installations running Cisco Unity 3.1(3) - 3.1(5) and 4.0(1), we recommend that you download the most recent 10.0(x) version of the Voice Connector for Exchange 2000, as described in the "To Download the Voice Connector (Cisco Unity 3.1(3) - 3.1(5) and 4.0(1) Only)" section on page 1-7.
Before you begin sending test messages, do all of the procedures in this section to enable the applicable logs, traces, and other troubleshooting tools, as follows:
•To Enable Troubleshooting Tools on the Bridge Server
•To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later)
•To Enable Message Tracking in Exchange 2000
•To Enable SMTP Logging in Exchange 2000
To Enable Troubleshooting Tools 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 a value greater than zero.
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 (Voice Connector 10.0 and Later)
Step 1 Log on to the Exchange server on which the Voice Connector is installed.
Step 2 From the Windows Start menu, click Programs > Microsoft Exchange > Exchange System Manager.
Step 3 Expand the Connectors container in the left-hand pane.
Step 4 Right-click Exchange 2000 Voice Connector (<server name>), and select Properties.
Step 5 Click the Advanced tab.
Step 6 In the Logging Level list, click Information.
Step 7 Click OK.
Step 8 In the Windows Services applet, right-click Exchange 2000 Voice Connector (<server name>), and select Restart.
To Enable Message Tracking in Exchange 2000
You need to enable message tracking on each Exchange server that participates in message delivery. This is 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.
Step 1 Open Exchange System Manager. (From the Windows Start menu, click Programs > Exchange > Exchange System Manager.)
Step 2 Right-click the Exchange server you want to enable message tracking on, and select Properties.
Step 3 Check Enable Message Tracking.
Step 4 Click OK.
Step 5 Repeat Step 1 through Step 4 for each Exchange server that participates in message delivery.
To Enable SMTP Logging in Exchange 2000
Step 1 Open the Exchange System Manager.
Step 2 In the left-hand pane, expand Servers > <Server where Voice Connector is installed> > Protocols > SMTP.
Step 3 Right click the Default SMTP Virtual Server (or any other SMTP Connector that may be routing mail) and select Properties.
Step 4 Check Enable Logging.
Step 5 In the Active Log Format list, click NCSA Common Log File Format.
Step 6 Click Properties and enter the location for the log file.
Step 7 Click OK twice and close the Exchange System Manager.
After all the troubleshooting tools are set up, send a test message from an Octel subscriber to a Cisco Unity subscriber. Then see the following sections for information to help you determine the cause of the problem:
•Troubleshooting Voice Message Flow from the Octel Node to the Bridge Server
•Troubleshooting Voice Message Flow from the Bridge Server to the Voice Connector
•Troubleshooting Voice Message Flow from the Voice Connector to the Subscriber Mailbox
When finished testing, you may want to reset some of the logs and traces back to their defaults:
•In the Bridge Administrator:
–On the Digital Networking page, reset the Retention Days For Temporary SMTP Messages back to zero. (These messages consume significant hard disk space, so you should always configure this setting to zero unless troubleshooting and monitoring hard disk consumption.)
–On the Digital Networking page, reset the Tracing Level back to None. (Typically, these logs do not consume significant hard disk space, so you may want to leave the Tracing Level set to Flow.)
–On the System Settings page, reset the Call Tracing Level back to None. (Typically, these logs do not consume significant hard disk space, so you may want to leave the Call Tracing Level set to Verbose.)
•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 no more than the desired 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 no more than the desired hard disk space is consumed for storage of these logs.)
Troubleshooting Voice Message Flow from the Octel Node to the Bridge Server
•The Windows Event Viewer on the Bridge server should be the first place to look when troubleshooting voice message flow from an Octel node to a Cisco Unity node. The Bridge services record errors and warnings to the Windows Event Viewer application log, and you can troubleshoot any errors or warnings you find in the Event logs.
•The call log traces can be used to obtain information about messages coming from Octel servers through the Bridge voice-fax card(s). 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 folder are files named SFLOG.mmddtttt.LOG. Each file contains log entries for one hour of the day; the filename indicates which hour.
•Go to the \Bridge\starfish\Log directory and open the SFLOG.log that corresponds to the time the message was sent. Look for the following lines in the log file. The presence of these lines shows a successful transmission from the Octel node to the Bridge server.
SFLOG 1888 664 2002/09/24-17:02:05.968 00000100 Line 7: Received 252B605C794162D39B1C328D83CA153A79C4
SFLOG 1888 664 2002/09/24-17:02:05.968 00000008 Line 7: New Message from mailbox 10006 to mailbox 30022
SFLOG 1888 664 2002/09/24-17:02:05.968 00000100 Line 7: Playing 021#31
SFLOG 1888 664 2002/09/24-17:02:06.890 00000008 Line 7: Recording Voice
SFLOG 1888 664 2002/09/24-17:02:06.890 00000100 Line 7: Recording
c:\Bridge\Starfish\Out\6c37c321-533e-45fc-bdf7-1676c6ed3046
SFLOG 1888 664 2002/09/24-17:03:07.859 00000008 Line 7: Recording completed
SFLOG 1888 664 2002/09/24-17:03:08.859 00000100 Line 7: Received #
SFLOG 1888 664 2002/09/24-17:03:08.859 00000100 Line 7: Playing 8
SFLOG 1888 664 2002/09/24-17:03:11.296 00000100 Line 7: Received 9
SFLOG 1888 664 2002/09/24-17:03:11.296 00000100 Line 7: Playing 0282C6
SFLOG 1888 664 2002/09/24-17:03:12.203 00000008 Line 7: Message Saved
If you do not see the above lines in the log, troubleshoot any errors or discrepancies that may be displayed in the SFLOG. Make sure your phone lines are plugged in and that the Octel node and Cisco Unity node serial numbers and node IDs are configured correctly.
If the calling Octel server does not have the Cisco Unity node serial number defined in its node configuration, then the Bridge hangs up immediately when it receives a call from the Octel node. This condition can be determined observing that the SFLOGs show that the calling Octel sent an initial handshake packet of "CD" instead of "BD" as in the following example:
SFLOG 1732 704 2003/01/10-22:04:49.711 00000008 Line 1: Call Received.
SFLOG 1732 704 2003/01/10-22:04:50.713 00000100 Line 1: Playing 1.sph
SFLOG 1732 704 2003/01/10-22:04:56.531 00000100 Line 1: Received CD
SFLOG 1732 704 2003/01/10-22:04:57.533 00000100 Line 1: Received
SFLOG 1732 704 2003/01/10-22:04:58.083 00000008 Line 1: Incoming Call Completed.
Because the Bridge requires the Cisco Unity node serial number to be configured on the Octel server, you will have to define the serial number for the Cisco Unity node in the node profile on the Octel server. When the serial number for the Cisco Unity node is properly configured in the node profile on the Octel server, the Octel will send the expected "BD" handshake packet which the Bridge will successfully respond to with "CDD" and the call will proceed, as in the following example:
SFLOG 736 752 2002/12/31-21:41:45.017 00000008 Line 3: Call Received.
SFLOG 736 752 2002/12/31-21:41:46.019 00000100 Line 3: Playing 1.sph
SFLOG 736 752 2002/12/31-21:41:51.436 00000100 Line 3: Received
SFLOG 736 752 2002/12/31-21:41:51.436 00000100 Line 3: Playing 1.sph
SFLOG 736 752 2002/12/31-21:41:56.974 00000100 Line 3: Received BD
SFLOG 736 752 2002/12/31-21:41:56.974 00000100 Line 3: Playing CDD
SFLOG 736 752 2002/12/31-21:42:02.052 00000100 Line 3: Received 12##C#5D82AC6AA897
SFLOG 736 752 2002/12/31-21:42:02.062 00000100 Line 3: Protocol Level = 3
SFLOG 736 752 2002/12/31-21:42:02.062 00000100 Line 3: Playing 012444C54331CA
If the Message Was Received by the Bridge
If the SFLOGs indicate that the handshake was successful, and that the Bridge received the message, a copy of the message should be saved to the \Bridge\VPIM\Internet\Out and \Bridge\VPIM\Internet\Out\tmp directories.
Note 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. The message will stay in the \Bridge\VPIM\Internet\Out directory until it is delivered to the Voice Connector.
•Verify that the voice message appears in the \Bridge\VPIM\Internet\Out\tmp directory.
Troubleshooting Voice Message Flow from the Bridge Server to the Voice Connector
Once 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.
•Verify that the voice message made it to the Voice Connector by opening the GwIvc_<date>.log. The default location for the Voice Connector log files is <Exchange Server Path>\VoiceGateway\logFiles on the Exchange server on which the Voice Connector is installed. Check the log for any inbound messages such as "Processing Incoming OMNI Address message" during the time the message was sent. If there are no inbound messages, the message did not reach the Voice Connector.
If the message did not reach the Voice Connector, do the procedure, To Verify That the Domain Name Is Entered Correctly.
To Verify That the Domain Name Is Entered Correctly
Step 1 From a command prompt 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 on which the Voice Connector is installed.
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.
•Verify that the Unity SMTP Mail Suffix is configured correctly on the Bridge server, and determine whether you need to identify an ESMTP server name. Do the procedure, To Verify Whether the Unity SMTP Mail Suffix Is Configured Correctly.
To Verify Whether the Unity SMTP Mail Suffix Is Configured Correctly
Step 1 Open the Exchange 2000 System Manager.
Step 2 Double-click Recipient Policies.
Step 3 Double-click the Default Policy.
Step 4 Click the Email Addresses tab. The Unity SMTP Mail Suffix configured on the Bridge Unity Node should be identical to the SMTP address listed here.
Step 5 Open a command window.
Step 6 At the command prompt, enter telnet <Unity SMTP Mail Suffix> 25.
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 server(s). 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 if the message is hitting Exchange at all. It will be addressed to the Voice Connector (IMCEAOMNI-AvVoiceMessage@<Unity SMTP Mail Suffix>).
•Check to see if messages are stuck in the MTS-IN and MTS-OUT queues. Do the procedure, To Troubleshoot Messages That Are Stuck in the MTS-IN and MTS-OUT Queues.
To Troubleshoot Messages That Are Stuck in the MTS-IN and MTS-OUT Queues
Step 1 In the Exchange System Manager, look for AvExchangeIVC_<machine name> or Exchange 2000 Voice Connector (<servername>) under the Connectors subtree for your site.
Step 2 Look in the MTS-IN and MTS-OUT queues to see if any messages appear to be stuck.
Step 3 Restart the Voice Connector service by using the Services Control Panel.
Step 4 Confirm that the Simple Mail Transport Protocol (SMTP) service is running in the Services Control Panel.
•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 if, 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. This especially may be necessary when Exchange is using a shared Domain Name Space where Exchange is not configured as authoritative for this address. If so, 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:
–To Create a Special Recipient Policy for the Voice Connector
–To Apply the Special Recipient Policy to the Voice Connector
–To Configure the Bridge to Use the Special Recipient Policy
–To Configure an Exchange SMTP Connector to Route Messages from the Bridge Server Directly to the Voice Connector
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
If the only Recipient Policy listed in the Exchange Recipient Policies is the Default Policy, you should not need to perform the procedure below. In this case, configuring a special Recipient Policy is not the solution to whatever problem you are experiencing, and doing so will override the Default Policy, possibly introducing routing problems for all other inbound mail to the Exchange organization.
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.)
Step 2 Right-click Recipient Policies and select New > Recipient Policy.
Step 3 In the New Policy window, select only E-Mail Addresses and click OK.
Step 4 On the General tab, enter a meaningful name. Do not configure any Filter rules:
Step 5 On the E-Mail Addresses (Policy) tab, select the SMTP address and click Edit.
Step 6 Copy the address (for example, "@domain.com") from the Address field and click Cancel.
Step 7 On the E-Mail Addresses (Policy) tab, click New.
Step 8 Select SMTP Address and click OK.
Step 9 Paste the SMTP address that you copied in Step 6 into the Address field.
Step 10 Insert a name (for example, the Bridge server name) followed by a period between the @ sign and the rest of the address (for example, "mybridge.domain.com"). You can use any name as long as it matches what you configure in the procedure, To Configure the Bridge to Use the Special Recipient Policy.
Step 11 Make sure that the This Exchange Organization is responsible for all mail delivery to this address. box is checked.
Step 12 Click OK.
Step 13 Check the box next to the address that you added in Step 10, and make sure this row is highlighted.
Step 14 Click Set as Primary (the new address should change to bold text), and click OK.
Step 15 Click Yes to the warning to update the corresponding recipient e-mail addresses.
Step 16 Right-click the new policy and select All Tasks > Move down as needed until Move down is grayed out. (That is, set this policy to have the lowest policy of all except the Default Policy).
To Apply the Special Recipient Policy 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 Connectors container in the left-hand pane.
Step 3 Right-click Exchange 2000 Voice Connector (<server name>), and select Properties.
Step 4 At the bottom of the Options tab, click the drop down list for Recipient policy to calculate enterprise GDI for MTS-IDs.
Step 5 Select the new recipient policy you created in the procedure, To Create a Special Recipient Policy for the Voice Connector.
Step 6 Click Apply, then click OK to exit.
Step 7 Restart the Exchange 2000 Voice Connector service.
To Configure the Bridge to Use the Special Recipient Policy
Step 1 On the Bridge server in the Bridge Administrator, go to the Digital Networking page.
Step 2 Enter either the fully qualified domain name or the IP address, of the Exchange server on which the Voice Connector is installed, and click Save.
Step 3 Go to the Unity Node page and click Edit. Enter the address you used for the new recipient policy in the procedure, To Create a Special Recipient Policy for the Voice Connector, without the @ sign (for example, "mybridge.domain.com"), and click Save.
Step 4 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 folder. On some servers the Connectors folder will be in the Organization root. On others, most notably where multiple Routing Groups are being used, you will need to make sure to select the Connectors folder 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 Exchange 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 address you used for the new recipient policy in the procedure, To Create a Special Recipient Policy for the Voice Connector, without the @ sign (for example, "mybridge.domain.com").
Step 12 Leave the value in the Cost field set to 1, then click OK.
Step 13 Click OK to complete configuration of the SMTP connector.
Step 14 Send a test voice message from Octel to a Cisco Unity subscriber to see if 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 if the voice message made it to the Voice Connector, but was 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.
•Verify whether the Voice Connector settings are correct. Do the procedure, To Verify Voice Connector Settings.
To Verify Voice Connector Settings
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.
Note Once the Exchange System Manager Cleanup Agent is run, the name of the Voice Connector changes to Exchange 2000 Voice Connector (<machine name>).
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.
•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.
Directory Messages from Cisco Unity to the Bridge Are Not Processed
Figure 2-4 illustrates at a high level the flow of directory messages from Cisco Unity to the Bridge, and the troubleshooting logs, traces, and tools that you can use to determine where the problem is along the path.
Figure 2-4 Troubleshooting Problems with Directory Messages from Cisco Unity to the Bridge
Before You Begin
For installations running Cisco Unity 3.1(3) - 3.1(5) and 4.0(1), we recommend that you download the most recent 10.0(x) version of the Voice Connector for Exchange 2000, as described in the "To Download the Voice Connector (Cisco Unity 3.1(3) - 3.1(5) and 4.0(1) Only)" section on page 1-7.
Before you begin troubleshooting, do all of the procedures in this section to enable the applicable logs, traces, and other troubleshooting tools, as follows:
•To Enable Troubleshooting Tools on the Bridge Server
•To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later)
•To Enable Message Tracking in Exchange 2000
•To Enable SMTP Logging in Exchange 2000
•To Enable CsBridgeConnector Traces
To Enable Troubleshooting Tools 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 a value greater than zero.
Step 2 Set the Tracing Level to Flow.
Step 3 Click Save.
To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later)
Step 1 Log on to the Exchange server on which the Voice Connector is installed.
Step 2 From the Windows Start menu, click Programs > Microsoft Exchange > Exchange System Manager.
Step 3 Expand the Connectors container in the left-hand pane.
Step 4 Right-click Exchange 2000 Voice Connector (<server name>), and select Properties.
Step 5 Click the Advanced tab.
Step 6 In the Logging Level list, click Information.
Step 7 Click OK.
Step 8 In the Windows Services applet, right-click Exchange 2000 Voice Connector (<server name>), and select Restart.
To Enable Message Tracking in Exchange 2000
You need to enable message tracking on each Exchange server that participates in message delivery. This is 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.
Step 1 Open Exchange System Manager. (From the Windows Start menu, click Programs > Exchange > Exchange System Manager.)
Step 2 Right-click the Exchange server on which you want to enable message tracking, and select Properties.
Step 3 Check Enable Message Tracking.
Step 4 Click OK.
Step 5 Repeat Step 1 through Step 4 for each Exchange server that participates in message delivery.
To Enable SMTP Logging in Exchange 2000
Step 1 Open the Exchange System Manager.
Step 2 In the left-hand pane, expand Servers > <server where Voice Connector is installed> > Protocols > SMTP.
Step 3 Right-click the Default SMTP Virtual Server (or any other SMTP Connector that may be routing mail) and select Properties.
Step 4 Check Enable Logging.
Step 5 In the Active Log Format list, click NCSA Common Log File Format.
Step 6 Click Properties and enter the location for the log file.
Step 7 Click OK twice and close the Exchange System Manager.
To Enable CsBridgeConnector Traces
Step 1 On the Windows Start menu, click Programs > Cisco Unity > Unity Diagnostic Tool.
Step 2 On the Cisco Unity Diagnostic Tasks screen, click Configure Micro Traces. The Configure Micro Traces Wizard displays.
Step 3 Click Next to select the traces to enable. See Table 2-2 for details on the appropriate micro traces to set.
Step 4 After selecting the appropriate traces, click Finish.
Step 5 On the Cisco Unity Diagnostic Tasks screen, click Start New Log Files.
Step 6 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.
The selected log file is formatted and displayed in the right pane.
Step 7 To export or save a copy of the log file, click Action > Export List.
Step 8 Name the file and save it to a location of your choice in .txt or .csv format.
Step 9 Disable all diagnostic traces that were activated in Step 3.
Directory Messages from the Bridge to Cisco Unity Are Not Processed
Figure 2-5 illustrates at a high level the message flow from the Bridge to Cisco Unity, and the troubleshooting logs, traces, and tools that you can use to determine where the problem is along the path.
Figure 2-5 Troubleshooting Problems with Directory Messages from the Bridge to Cisco Unity
Before You Begin
For installations running Cisco Unity 3.1(3) - 3.1(5) and 4.0(1), we recommend that you download the most recent 10.0(x) version of the Voice Connector for Exchange 2000, as described in the "To Download the Voice Connector (Cisco Unity 3.1(3) - 3.1(5) and 4.0(1) Only)" section on page 1-7.
Before you begin troubleshooting, do all of the procedures in this section to enable the applicable logs, traces, and other troubleshooting tools, as follows:
•To Enable Troubleshooting Tools on the Bridge Server
•To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later)
•To Enable Message Tracking in Exchange 2000
•To Enable SMTP Logging in Exchange 2000
•To Enable CsBridgeConnector Traces
To Enable Troubleshooting Tools 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 a value greater than zero.
Step 2 Set the Tracing Level to Flow.
Step 3 Click Save.
To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later)
Step 1 Log on to the Exchange server on which the Voice Connector is installed.
Step 2 From the Windows Start menu, click Programs > Microsoft Exchange > Exchange System Manager.
Step 3 Expand the Connectors container in the left-hand pane.
Step 4 Right-click Exchange 2000 Voice Connector (<server name>), and select Properties.
Step 5 Click the Advanced tab.
Step 6 In the Logging Level list, click Information.
Step 7 Click OK.
Step 8 In the Windows Services applet, right-click Exchange 2000 Voice Connector (<server name>), and select Restart.
To Enable Message Tracking in Exchange 2000
You need to enable message tracking on each Exchange server that participates in message delivery. This is 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.
Step 1 Open Exchange System Manager. (From the Windows Start menu, click Programs > Exchange > Exchange System Manager.)
Step 2 Right-click the Exchange server on which you want to enable message tracking, and select Properties.
Step 3 Check Enable Message Tracking.
Step 4 Click OK.
Step 5 Repeat Step 1 through Step 4 for each Exchange server that participates in message delivery.
To Enable SMTP Logging in Exchange 2000
Step 1 Open the Exchange System Manager.
Step 2 In the left-hand pane, expand Servers > <server where Voice Connector is installed> > Protocols > SMTP.
Step 3 Right-click the Default SMTP Virtual Server (or any other SMTP Connector that may be routing mail) and select Properties.
Step 4 Check Enable Logging.
Step 5 In the Active Log Format list, click NCSA Common Log File Format.
Step 6 Click Properties and enter the location for the log file.
Step 7 Click OK twice and close the Exchange System Manager.
To Enable CsBridgeConnector Traces
Step 1 On the Windows Start menu, click Programs > Cisco Unity > Unity Diagnostic Tool.
Step 2 On the Cisco Unity Diagnostic Tasks screen, click Configure Micro Traces. The Configure Micro Traces Wizard displays.
Step 3 Click Next to select the traces to enable. See Table 2-2 for details on the appropriate micro traces to set.
Step 4 After selecting the appropriate traces, click Finish.
Step 5 On the Cisco Unity Diagnostic Tasks screen, click Start New Log Files.
Step 6 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.
The selected log file is formatted and displayed in the right pane.
Step 7 To export or save a copy of the log file, click Action > Export List.
Step 8 Name the file and save it to a location of your choice in .txt or .csv format.
Step 9 Disable all diagnostic traces that were activated in Step 3.
Bridge Troubleshooting 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.
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.
Tools for Troubleshooting Problems on the Bridge Server
•Event Viewer—The Bridge services record errors to the Windows Event Viewer application log.
•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.
•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 folders:
–<path>\VPIM\Xcode\Inbound\Tmp—Messages from Cisco Unity are stored in this folder. If messages appear in this folder, you know that messages are getting to the Bridge from Cisco Unity.
–<path>\VPIM\Internet\Out\Tmp folder—Messages to Cisco Unity are stored in this folder. If messages appear in this folder, 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 folder. 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 folder. The Bridge server adds current entries, and saves the appropriate hour trace file. Log files that are older than 24 hours are overwritten.
•Call Log Traces—Trace files are located on the Bridge server in the <path>\Starfish\Log folder. Increase the Call Tracing Level on the System Settings page in the Bridge Administrator to obtain information about messages coming from or going to Octel servers through the Bridge voice-fax card(s). 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 folder are the files SFLOG.mmddtttt.LOG. 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 appropriate hour log. Log files that are older than 24 hours are overwritten.
•Call Queue Logs—The log files are located on the Bridge server in the <path>\Starfish\Log folder. 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.
•Bridge Traffic Analyzer—The Bridge Traffic Analyzer is a report generation utility that reads the call and 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 on the Cisco Unity Utilities page of the Software Center website on Cisco.com at http://www.cisco.com/pcgi-bin/tablebuild.pl/unity-util.
Tools for Troubleshooting Problems with the Voice Connector
•Voice Connector Log File—The Voice Connector logs information to the file gwivc.log. See the procedure, To Increase the Voice Connector Logging Level (Voice Connector 10.0 and Later), for information on enabling Voice Connector logging.
•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 within the Exchange System Administrator.
Tools for Troubleshooting Directory Synchronization Problems on the Cisco Unity Server
•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.
•CsBridgeConnector Traces—Use the Unity Diagnostic Tool to set the appropriate CsBridgeConnector macro traces to troubleshoot directory synchronization problems. This tool is available on the Windows Start menu (click Programs > Cisco Unity > Unity Diagnostic Tool). See Table 2-2 for details on which micro traces to set.
Table 2-2 Micro Traces Used in Troubleshooting Directory Synchronization Problems
In Order To...
|
Set These Bridge Directory Synchronization Macro Traces...
|
Verify that directory synchronization is working correctly within Cisco Unity
|
Basic Bridge delivery synchronization trace
|
Narrow down directory synchronization problems to a specific Cisco Unity component
|
General Bridge delivery synchronization trace
|
Include additional Cisco Unity components and enable extensive logging
|
Extensive Bridge delivery synchronization trace
|
Enabling and Interpreting Traces for the Brooktrout TR114 on the Bridge
When experiencing analog communication problems between the Bridge and remote Octel nodes, the sflogs on the Bridge are most useful in determining what activity is occurring on the analog calls. However, sometimes determining what is occurring right at the TR114 voice board itself can provide additional information to the exact source of the problem. This section describes how to enable and interpret traces of activity on the TR114 board.
Enabling Debug Traces for the Brooktrout TR114
To Enable Debug Traces for the Brooktrout TR114
Step 1 Browse to the directory Drive:\Path\Starfish\bin, where Drive and Path denote the drive and the topmost directory where the Bridge software is installed.
Step 2 Open the file btcall.cfg with Notepad.exe.
Step 3 Add the following line at the bottom of the file:
debug ./traceinfo.log
Step 4 Save the changes to btcall.cfg and close the file.
Step 5 Restart the Unity Bridge service via the Services Control Panel.
Brooktrout TR114 activity will now be logged to <BridgePath>\Starfish\bin\traceinfo.log. Be aware that each time the Unity Bridge service is restarted, the old traceinfo.log will be deleted and a fresh log begun.
If you need to restart the Unity Bridge service and wish to save the traceinfo.log from the previous test, use the following procedure:
To Save the traceinfo.log from a Previous Test
Step 1 Stop the Unity Bridge service via the Services Control Panel.
Step 2 Rename <BridgePath>\Starfish\bin\traceinfo.log to the filename you wish to save the previous data as.
Step 3 Start the Unity Bridge service via the Services Control Panel.
Note On Bridge servers where message traffic is heavy the traceinfo.log file can grow very large. There is no mechanism for limiting the size of traceinfo.log and no cycling that occurs. When troubleshooting is finished this tracing should be disabled.
Disabling Debug Traces for the Brooktrout TR114
To Disable Debug Traces for the Brooktrout TR114
Step 1 Browse to the directory <BridgePath>\Starfish\bin.
Step 2 Open the file btcall.cfg with Notepad.exe.
Step 3 Remove the following line at the bottom of the file:
debug ./traceinfo.log
Step 4 Save the changes to btcall.cfg and close the file.
Step 5 Restart the Unity Bridge service via the Services Control Panel.
Interpreting Debug Traces for the Brooktrout TR114
Since the Brooktrout TR114 traceinfo.log is run on the same server as the sflog.*.log files, all of the time stamps will match up and you can use these logs together to get a real good picture of what is going on. See the description of the Call Tracing Level field in the "System Settings" section on page 1-50 for information about enabling the sflog.*.log files.
Following is an excerpt from a traceinfo.log on a 4-port Bridge server for an outgoing analog message delivery from the Bridge (serial number 80100) to a remote Octel node (serial number 80200). Descriptions of the events are included, as well as the associated events from sflog.log. This displays the context of actions the board is taking based on requests from the Unity Bridge service (starfish.exe) and vice versa. In the following example traces, the sflog traces begin with the word "SFLOG" followed by a number. Only the sflog.log events for line 3 (TR114 channel 2) are listed. The traceinfo.log events begin with the date and time followed by the TR114 channel that the event occurred on.
Table 2-3 Brooktrout and SFLOG Example Trace
Trace
|
Description
|
11/26 22:59:08.33 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:08.34 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:08.34 2 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:08.35 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:08.37 2 await ring
11/26 22:59:08.37 2 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:08.37 2 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:08.39 1 await ring
11/26 22:59:08.39 1 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:08.39 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:08.41 0 await ring
11/26 22:59:08.41 0 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:08.41 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:08.41 3 await ring
11/26 22:59:08.41 3 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:08.41 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:18.37 2 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:18.39 1 cmd: 0x26 DIS_RING_DET 0x0
|
All of the analog ports on the Bridge are in an idle state. They are repeatedly cycling through their ring detect processes to monitor for incoming calls until they get one, or until an outgoing call is initiated by the Unity Bridge service (starfish.exe). The number immediately following the time stamp is the channel number on the TR114. Note that it is zero based, that is, channels 0-3 correspond to lines 1-4 on the Bridge server. The traces for channel 2 (which is Bridge line 3) are in bold.
|
SFLOG 1396 1700 2002/11/26-22:59:18.384 00000008 Line 3: Call Out
Process Initiated for Node 80200 Window Type 0
|
The Bridge initiates the call out process for node 80200 normal messages (type 0). There is a message to delivery so a request is sent to the TR114 to make the call.
|
11/26 22:59:18.39 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 22:59:18.39 2 dialing ,20
11/26 22:59:18.39 2 cmd: 0x37 DIAL_STRING 0x0
|
These three events are the initiating of an outgoing analog call on channel 2 (Bridge line 3). The dial string is ",20" where the comma is a one second pause and 20 is the phone number being dialed.
|
11/26 22:59:18.41 1 await ring
11/26 22:59:18.41 1 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:18.41 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:18.41 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:18.44 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:18.44 0 await ring
11/26 22:59:18.44 0 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:18.44 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:18.45 3 await ring
11/26 22:59:18.45 3 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:18.45 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:20.15 2 intr: 0xa ISTRDNE 0x0
11/26 22:59:20.15 2 cmd: 0x2b ENA_CALL_PROG 0x23
|
Call progress detection is initiated on the TR114. The TR114 is waiting for detection of ringback, busy or reorder tone, or detection of human voice.
|
1/26 22:59:20.60 2 intr: 0x18 ILOW 0x40
11/26 22:59:20.89 2 intr: 0x19 IHI 0x3a
11/26 22:59:22.14 2 intr: 0x18 ILOW 0xfa
11/26 22:59:22.27 2 intr: 0x19 IHI 0x1a
11/26 22:59:22.77 2 intr: 0x18 ILOW 0x64
11/26 22:59:22.82 2 intr: 0x19 IHI 0xa
11/26 22:59:22.95 2 intr: 0x18 ILOW 0x1a
11/26 22:59:22.95 2 intr: 0x1b CALL_PROG 0x10
111/26 22:59:22.95 2 call progress: HUMAN
|
Voice detection has occurred. A connect event is sent up to the Unity Bridge service.
|
11/26 22:59:22.95 2 cmd: 0x2a DIS_CALL_PROG 0x0
11/26 22:59:22.95 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 22:59:22.95 2 cmd: 0x24 ENABLE_TONE_DET 0x0
SFLOG 1396 1700 2002/11/26-22:59:22.960 00000100 Line 3: Call Status =
Answer
SFLOG 1396 1700 2002/11/26-22:59:22.960 00000100 Line 3: Playing BD
|
Unity Bridge service acknowledges that the call has been answered and sends the tones "BD" to the Octel. DTMF tones are stored .sph files in \bridge\starfish\bin and played through the TR114 as audio files.
|
11/26 22:59:22.97 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 22:59:22.99 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "BD" and associated parameters and begins to play them to the Octel.
|
11/26 22:59:22.99 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 22:59:23.02 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 22:59:23.29 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 completes playing the audio to the Octel. You will only see one pair of SPEECH_START/SPEECH_DONE events for each entire string of DTMF digits sent. Since the TR114 is simply playing recordings of DTMFs given to it by the Unity Bridge service, you will only see the actual DTMF digits sent in the sflogs.
|
11/26 22:59:23.29 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 22:59:24.46 2 intr: 0xb TONE_DETECT 0x8f
11/26 22:59:24.53 2 intr: 0xb TONE_DETECT 0xf
11/26 22:59:24.60 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:24.67 2 intr: 0xb TONE_DETECT 0x0
11/26 22:59:24.75 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:24.82 2 intr: 0xb TONE_DETECT 0x0
Description of Tones Received
So our first tone received is "C" (because f=C). This tone began at 22:59:24.46 (0x8f) and ended at 22:59:24.53 (0xf) so it was 70 milliseconds in duration.
The second tone received is "D" (because 0=D). This tone began at 22:59:24.60 (0x80) and ended at 22:59:24.67 (0x0) so it was 70 milliseconds in duration. The interdigit time between the "C" and the first "D" was 70 milliseconds (22:59:24.60 - 22:59:24.53 = .07 seconds, or 70 milliseconds).
The third tone received is "D" (because 0=D). This tone began at 22:59:24.75 (0x80) and ended at 22:59:24.82 (0x0) so it was 70 milliseconds in duration. The interdigit time between the first "D" and the second "D" was 80 milliseconds (22:59:24.75 - 22:59:24.67 = .08 seconds, or 80 milliseconds).
|
Now the TR114 is detecting incoming DTMF digits from the Octel. There are two TONE_DETECT events for each tone detected, one for the beginning of the tone detected and one when the end is detected. The event for detection of the beginning of a tone will look like "intr: 0xb TONE_DETECT 0x8c", where the "8" indicates it's the beginning of the tone and the "c" is actually telling you what tone was detected. The end of the tone will look just the same, but won't have the "8" in it, e.g. "intr: 0xb TONE_DETECT 0xc". Note the "c" here does not represent the actual DTMF 'C' tone. You have to use the following table to translate it:
1-9 = 1-9
a = 0
b = *
c = #
d = A
e = B
f = C
0 = D
|
SFLOG 1396 1700 2002/11/26-22:59:25.835 00000100 Line 3: Received CDD
|
The "CDD" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
|
SFLOG 1396 1700 2002/11/26-22:59:25.835 00000100 Line 3: Playing
12086D5082AC6AA897
|
Now the Unity Bridge services responds to the CDD packet by requesting the TR114 to play audio of the DTMF digit string "12086D5082AC6AA897"
|
11/26 22:59:25.82 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 22:59:25.82 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 22:59:25.83 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "12086D5082AC6AA897" and associated parameters and begins to play them to the Octel.
|
11/26 22:59:25.85 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 22:59:25.94 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 22:59:28.38 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 completes playing the audio to the Octel.
|
11/26 22:59:28.38 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 22:59:28.42 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:28.43 1 await ring
11/26 22:59:28.43 1 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:28.43 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:28.45 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:28.46 0 await ring
11/26 22:59:28.46 0 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:28.46 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:28.46 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:28.47 3 await ring
11/26 22:59:28.47 3 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:28.47 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:29.56 2 intr: 0xb TONE_DETECT 0x81
11/26 22:59:29.63 2 intr: 0xb TONE_DETECT 0x1
11/26 22:59:29.70 2 intr: 0xb TONE_DETECT 0x83
11/26 22:59:29.77 2 intr: 0xb TONE_DETECT 0x3
11/26 22:59:29.85 2 intr: 0xb TONE_DETECT 0x87
11/26 22:59:29.92 2 intr: 0xb TONE_DETECT 0x7
11/26 22:59:29.99 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:30.06 2 intr: 0xb TONE_DETECT 0x0
11/26 22:59:30.13 2 intr: 0xb TONE_DETECT 0x87
11/26 22:59:30.19 2 intr: 0xb TONE_DETECT 0x7
11/26 22:59:30.26 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:30.33 2 intr: 0xb TONE_DETECT 0x0
11/26 22:59:30.40 2 intr: 0xb TONE_DETECT 0x85
11/26 22:59:30.47 2 intr: 0xb TONE_DETECT 0x5
11/26 22:59:30.54 2 intr: 0xb TONE_DETECT 0x8d
11/26 22:59:30.61 2 intr: 0xb TONE_DETECT 0xd
11/26 22:59:30.68 2 intr: 0xb TONE_DETECT 0x88
11/26 22:59:30.75 2 intr: 0xb TONE_DETECT 0x8
11/26 22:59:30.82 2 intr: 0xb TONE_DETECT 0x8c
11/26 22:59:30.89 2 intr: 0xb TONE_DETECT 0xc
11/26 22:59:30.97 2 intr: 0xb TONE_DETECT 0x87
11/26 22:59:31.04 2 intr: 0xb TONE_DETECT 0x7
11/26 22:59:31.09 2 intr: 0xb TONE_DETECT 0x8a
11/26 22:59:31.16 2 intr: 0xb TONE_DETECT 0xa
11/26 22:59:31.24 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:31.31 2 intr: 0xb TONE_DETECT 0x0
11/26 22:59:31.38 2 intr: 0xb TONE_DETECT 0x88
11/26 22:59:31.45 2 intr: 0xb TONE_DETECT 0x8
|
Now the TR114 is detecting incoming DTMF digits from the Octel.
Using the conversion table:
1-9 = 1-9
a = 0
b = *
c = #
d = A
e = B
f = C
0 = D
We can map the TONE_DETECT events to DTMF digits:
1 3 7 0 7 0 5 d 8 c 7 a 0 8
1 3 7 D 7 D 5 A 8 # 7 0 D 8
(The first line contains the TONE_DETECT events, and the second line contains the DTMF digits.)
|
SFLOG 1396 1700 2002/11/26-22:59:32.464 00000100 Line 3: Received
137D7D5A8#70D8
SFLOG 1396 1700 2002/11/26-22:59:32.464 00000100 Line 3: Protocol Level
= 3
|
The "137D7D5A8#70D8" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
From the received packet the Unity Bridge service can determine the analog Octel networking protocol level used by the Octel server.
|
SFLOG 1396 1700 2002/11/26-22:59:32.464 00000100 Line 3: Playing
2431#73258#51#4B
|
Now the Unity Bridge services responds to the received packet by requesting the TR114 to play audio of the DTMF digit string "2431#73258#51#4B"
|
11/26 22:59:32.45 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 22:59:32.45 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 22:59:32.46 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "2431#73258#51#4B" and associated parameters and begins to play them to the Octel.
|
11/26 22:59:32.49 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 22:59:32.52 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 22:59:34.74 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 completes playing the audio to the Octel.
|
11/26 22:59:34.74 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 22:59:35.92 2 intr: 0xb TONE_DETECT 0x8a
11/26 22:59:35.99 2 intr: 0xb TONE_DETECT 0xa
11/26 22:59:36.06 2 intr: 0xb TONE_DETECT 0x86
11/26 22:59:36.13 2 intr: 0xb TONE_DETECT 0x6
11/26 22:59:36.20 2 intr: 0xb TONE_DETECT 0x89
11/26 22:59:36.27 2 intr: 0xb TONE_DETECT 0x9
11/26 22:59:36.35 2 intr: 0xb TONE_DETECT 0x87
11/26 22:59:36.42 2 intr: 0xb TONE_DETECT 0x7
11/26 22:59:36.49 2 intr: 0xb TONE_DETECT 0x8c
11/26 22:59:36.56 2 intr: 0xb TONE_DETECT 0xc
11/26 22:59:36.63 2 intr: 0xb TONE_DETECT 0x87
11/26 22:59:36.69 2 intr: 0xb TONE_DETECT 0x7
11/26 22:59:36.76 2 intr: 0xb TONE_DETECT 0x86
11/26 22:59:36.83 2 intr: 0xb TONE_DETECT 0x6
11/26 22:59:36.90 2 intr: 0xb TONE_DETECT 0x8a
11/26 22:59:36.97 2 intr: 0xb TONE_DETECT 0xa
11/26 22:59:37.04 2 intr: 0xb TONE_DETECT 0x85
11/26 22:59:37.11 2 intr: 0xb TONE_DETECT 0x5
11/26 22:59:37.18 2 intr: 0xb TONE_DETECT 0x88
11/26 22:59:37.25 2 intr: 0xb TONE_DETECT 0x8
11/26 22:59:37.32 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:37.39 2 intr: 0xb TONE_DETECT 0x0
11/26 22:59:37.47 2 intr: 0xb TONE_DETECT 0x85
11/26 22:59:37.54 2 intr: 0xb TONE_DETECT 0x5
11/26 22:59:37.61 2 intr: 0xb TONE_DETECT 0x88
11/26 22:59:37.66 2 intr: 0xb TONE_DETECT 0x8
11/26 22:59:37.74 2 intr: 0xb TONE_DETECT 0x8d
11/26 22:59:37.81 2 intr: 0xb TONE_DETECT 0xd
11/26 22:59:37.88 2 intr: 0xb TONE_DETECT 0x82
11/26 22:59:37.95 2 intr: 0xb TONE_DETECT 0x2
11/26 22:59:38.02 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:38.09 2 intr: 0xb TONE_DETECT 0x0
|
Now the TR114 is detecting incoming DTMF digits from the Octel.
Using the conversion table:
1-9 = 1-9
a = 0
b = *
c = #
d = A
e = B
f = C
0 = D
We can see that the TONE_DETECT events correspond to the following DTMF digits:
0 6 9 7 # 7 6 0 5 8 D 5 8 A 2 D
|
1/26 22:59:38.43 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:38.44 1 await ring
11/26 22:59:38.44 1 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:38.44 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:38.46 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:38.47 0 await ring
11/26 22:59:38.47 0 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:38.47 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:38.47 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:38.48 3 await ring
11/26 22:59:38.48 3 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:38.48 3 cmd: 0x27 ENA_RING_DET 0x0
SFLOG 1396 1700 2002/11/26-22:59:39.104 00000100 Line 3: Received
0697#76058D58A2D
SFLOG 1396 1700 2002/11/26-22:59:39.104 00000008 Line 3: Call
established from Serial # 80100 to Serial # 80200
|
The "0697#76058D58A2D" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
From the received packet the Unity Bridge service is able to determine that Octel node #80200 has accepted our call and will allow us to proceed.
|
SFLOG 1396 1700 2002/11/26-22:59:39.114 00000100 Line 3: Playing
131A3C13#CAA7A*7AB72*C9D5A647*69D#1A
|
Now the Unity Bridge service responds to the received packet by requesting the TR114 to play audio of the DTMF digit string: "131A3C13#CAA7A*7AB72*C9D5A647*69D#1A"
|
11/26 22:59:39.10 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 22:59:39.10 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 22:59:39.12 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "131A3C13#CAA7A*7AB72*C9D5A647*69D#1A" and associated parameters and begins to play them to the Octel.
|
11/26 22:59:39.15 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 22:59:41.09 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 22:59:44.19 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 finishes playing the audio to the Octel.
|
11/26 22:59:44.19 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 22:59:45.36 2 intr: 0xb TONE_DETECT 0x8a
11/26 22:59:45.43 2 intr: 0xb TONE_DETECT 0xa
11/26 22:59:45.51 2 intr: 0xb TONE_DETECT 0x82
11/26 22:59:45.58 2 intr: 0xb TONE_DETECT 0x2
11/26 22:59:45.65 2 intr: 0xb TONE_DETECT 0x84
11/26 22:59:45.72 2 intr: 0xb TONE_DETECT 0x4
11/26 22:59:45.79 2 intr: 0xb TONE_DETECT 0x83
11/26 22:59:45.86 2 intr: 0xb TONE_DETECT 0x3
11/26 22:59:45.92 2 intr: 0xb TONE_DETECT 0x80
11/26 22:59:45.99 2 intr: 0xb TONE_DETECT 0x0
11/26 22:59:46.06 2 intr: 0xb TONE_DETECT 0x81
11/26 22:59:46.13 2 intr: 0xb TONE_DETECT 0x1
|
Now the TR114 is detecting incoming DTMF digits from the Octel.
Using the conversion table from earlier in this example, we can see that TONE_DETECT events correspond to the following DTMF digits:
|
SFLOG 1396 1700 2002/11/26-22:59:47.145 00000100 Line 3: Received
0243D1
|
The "0243D1" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
|
SFLOG 1396 1700 2002/11/26-22:59:47.145 00000100 Line 3: Playing
67D59228#882313B*0AA*#C#1*DB4579B8D48D7D51A980
|
Now the Unity Bridge service responds to the received packet by requesting the TR114 to play audio of the DTMF digit string "67D59228#882313B*0AA*#C#1*DB4579B8D48D7D51A980"
|
11/26 22:59:47.13 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 22:59:47.13 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 22:59:47.14 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "67D59228#882313B*0AA*#C#1*DB4579B8D48D7D51A980" and associated parameters and begins to play them to the Octel.
|
11/26 22:59:47.17 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 22:59:48.48 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:48.48 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:48.49 1 await ring
11/26 22:59:48.49 1 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:48.49 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:48.49 0 await ring
11/26 22:59:48.49 0 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:48.49 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:48.49 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:48.50 3 await ring
11/26 22:59:48.50 3 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:48.50 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:50.51 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 22:59:53.61 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 completes playing the audio to the Octel.
|
11/26 22:59:53.61 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 22:59:54.82 2 intr: 0xb TONE_DETECT 0x82
11/26 22:59:54.89 2 intr: 0xb TONE_DETECT 0x2
11/26 22:59:54.95 2 intr: 0xb TONE_DETECT 0x83
11/26 22:59:55.02 2 intr: 0xb TONE_DETECT 0x3
11/26 22:59:55.09 2 intr: 0xb TONE_DETECT 0x8e
11/26 22:59:55.16 2 intr: 0xb TONE_DETECT 0xe
11/26 22:59:55.23 2 intr: 0xb TONE_DETECT 0x8d
11/26 22:59:55.30 2 intr: 0xb TONE_DETECT 0xd
11/26 22:59:55.37 2 intr: 0xb TONE_DETECT 0x8f
11/26 22:59:55.44 2 intr: 0xb TONE_DETECT 0xf
11/26 22:59:55.51 2 intr: 0xb TONE_DETECT 0x8e
11/26 22:59:55.58 2 intr: 0xb TONE_DETECT 0xe
|
Now the TR114 is detecting incoming DTMF digits from the Octel.
Using our table from earlier in this example, we can see that the TONE_DETECT events correspond to the following DTMF digits:
|
SFLOG 1396 1700 2002/11/26-22:59:56.589 00000100 Line 3: Begin Mailbox
Update
SFLOG 1396 1700 2002/11/26-22:59:56.589 00000100 Line 3: End Mailbox
Update
SFLOG 1396 1700 2002/11/26-22:59:56.589 00000008 Line 3: Sending
Message from mailbox 57100@JDC1 to mailbox
47100@jdc6a.ecsbu-lab-sea.cisco.com
SFLOG 1396 1700 2002/11/26-22:59:56.589 00000008 Line 3: Playing Voice
SFLOG 1396 1700 2002/11/26-22:59:56.589 00000100 Line 3: Playing
c:\Bridge\Starfish\In\80200\80100\20021127065817606-443f73dd-da28-40ad-
ae0a-26f2c388ff4f
|
Now the Unity Bridge service responds to the received packet by requesting the TR114 to play the actual voice message.
|
11/26 22:59:56.58 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 22:59:56.59 2 play 1024
11/26 22:59:56.59 2 play 2048
11/26 22:59:56.59 2 play 3072
11/26 22:59:56.59 2 play 4096
11/26 22:59:56.59 2 play 5120
11/26 22:59:56.59 2 play 6144
11/26 22:59:56.59 2 play 7168
11/26 22:59:56.59 2 play 8192
11/26 22:59:56.59 2 cmd: 0x5c SPEECH_START 0x0
11/26 22:59:56.59 2 play 9216
11/26 22:59:56.60 2 play 10240
11/26 22:59:56.60 2 play 11264
11/26 22:59:56.60 2 play 12288
11/26 22:59:56.61 2 play 13312
11/26 22:59:56.61 2 play 14336
11/26 22:59:56.61 2 play 15360
11/26 22:59:56.62 2 play 16384
11/26 22:59:56.62 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 22:59:56.63 2 play 17408
11/26 22:59:56.65 2 play 18432
11/26 22:59:56.68 2 play 19456
11/26 22:59:56.70 2 play 20480
11/26 22:59:56.73 2 play 21504
11/26 22:59:56.75 2 play 22528
11/26 22:59:56.78 2 play 23552
11/26 22:59:56.80 2 play 24576
11/26 22:59:56.83 2 play 25600
11/26 22:59:56.85 2 play 26624
11/26 22:59:56.94 2 play 27648
11/26 22:59:57.07 2 play 28672
11/26 22:59:57.20 2 play 29696
11/26 22:59:57.32 2 play 30720
11/26 22:59:57.45 2 play 31744
11/26 22:59:57.58 2 play 32768
11/26 22:59:57.71 2 play 33792
11/26 22:59:57.84 2 play 34816
11/26 22:59:57.96 2 play 35840
11/26 22:59:58.09 2 play 36864
11/26 22:59:58.22 2 play 37888
11/26 22:59:58.35 2 play 38912
11/26 22:59:58.48 2 play 39614
11/26 22:59:58.48 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 22:59:58.49 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:58.49 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:58.50 1 await ring
11/26 22:59:58.50 1 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:58.50 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:58.50 0 await ring
11/26 22:59:58.50 0 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:58.50 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 22:59:58.50 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 22:59:58.51 3 await ring
11/26 22:59:58.51 3 cmd: 0x1f NUM_RINGS 0x1
11/26 22:59:58.51 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:01.57 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 completes playing the audio to the Octel.
|
SFLOG 1396 1700 2002/11/26-23:00:01.586 00000008 Line 3: Playing
completed
|
The Unity Bridge service acknowledges that the playing of the voice message has finished.
|
SFLOG 1396 1700 2002/11/26-23:00:01.586 00000100 Line 3: Playing #
|
Now the Unity Bridge service requests that the TR114 to play the audio of the DTMF digit "#". This indicates to the Octel server the end of the voice message.
|
11/26 23:00:01.58 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 23:00:01.58 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 23:00:01.59 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "#" and associated parameters and begins to play it to the Octel.
|
11/26 23:00:01.59 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 23:00:01.62 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 23:00:01.75 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 finishes playing the audio to the Octel.
|
11/26 23:00:01.75 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 23:00:02.93 2 intr: 0xb TONE_DETECT 0x88
11/26 23:00:03.00 2 intr: 0xb TONE_DETECT 0x8
|
Now the TR114 detects an incoming DTMF digit from the Octel.
Using our table from earlier in this example, we can see that the TONE_DETECT event corresponds to DTMF digit 8.
|
SFLOG 1396 1700 2002/11/26-23:00:04.009 00000100 Line 3: Received 8
|
The "8" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
|
SFLOG 1396 1700 2002/11/26-23:00:04.009 00000100 Line 3: Playing 9
|
Now the Unity Bridge service responds to the received "8" by requesting the TR114 to play audio of the DTMF digit "9".
|
11/26 23:00:04.00 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 23:00:04.00 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 23:00:04.01 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "9" and associated parameters and begins to play it to the Octel.
|
11/26 23:00:04.01 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 23:00:04.04 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 23:00:04.17 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 completes playing the audio to the Octel.
|
11/26 23:00:04.17 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 23:00:05.34 2 intr: 0xb TONE_DETECT 0x82
11/26 23:00:05.41 2 intr: 0xb TONE_DETECT 0x2
11/26 23:00:05.48 2 intr: 0xb TONE_DETECT 0x83
11/26 23:00:05.55 2 intr: 0xb TONE_DETECT 0x3
11/26 23:00:05.63 2 intr: 0xb TONE_DETECT 0x87
11/26 23:00:05.70 2 intr: 0xb TONE_DETECT 0x7
11/26 23:00:05.77 2 intr: 0xb TONE_DETECT 0x86
11/26 23:00:05.84 2 intr: 0xb TONE_DETECT 0x6
11/26 23:00:05.91 2 intr: 0xb TONE_DETECT 0x83
11/26 23:00:05.98 2 intr: 0xb TONE_DETECT 0x3
11/26 23:00:06.04 2 intr: 0xb TONE_DETECT 0x8d
11/26 23:00:06.11 2 intr: 0xb TONE_DETECT 0xd
|
Now the TR114 is detecting incoming DTMF digits from the Octel.
Using our table from earlier in this example, we can see that the TONE_DETECT events correspond to the following DTMF digits:
|
SFLOG 1396 1700 2002/11/26-23:00:07.124 00000100 Line 3: Received
23763A
SFLOG 1396 1700 2002/11/26-23:00:07.124 00000008 Line 3: Message
Delivered
SFLOG 1396 1700 2002/11/26-23:00:07.124 00000008 Line 3: Completed
delivering Messages
|
The "23763A" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
From the received packet the Unity Bridge service is able to determine that Octel node #80200 has successfully received and processed the message.
The Bridge has no more messages in the queue to deliver to this node.
|
SFLOG 1396 1700 2002/11/26-23:00:07.124 00000100 Line 3: Playing
045AC0BA9*84#D002A991C367C8ABDB0C2A4
|
Now the Unity Bridge service requests the TR114 to play audio of the DTMF digit string "045AC0BA9*84#D002A991C367C8ABDB0C2A4"
|
11/26 23:00:07.11 2 cmd: 0x24 ENABLE_TONE_DET 0x0
11/26 23:00:07.11 2 cmd: 0x5e SPEECH_PARAMS 0x0
11/26 23:00:07.13 2 cmd: 0x5c SPEECH_START 0x0
|
The TR114 receives the audio of "045AC0BA9*84#D002A991C367C8ABDB0C2A4" and associated parameters and begins to play them to the Octel.
|
11/26 23:00:07.16 2 intr: 0x2c ECHO_ADAPT 0xa
11/26 23:00:08.51 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:08.51 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:08.52 1 await ring
11/26 23:00:08.52 1 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:08.52 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:08.52 0 await ring
11/26 23:00:08.52 0 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:08.52 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:08.52 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:08.53 3 await ring
11/26 23:00:08.53 3 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:08.53 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:09.10 2 cmd-sync: 0x5d SPEECH_ALTER 0x8
11/26 23:00:12.20 2 intr: 0x38 SPEECH_DONE 0x0
|
The TR114 finishes playing the audio to the Octel.
|
11/26 23:00:12.20 2 cmd: 0x24 ENABLE_TONE_DET 0x3
11/26 23:00:13.39 2 intr: 0xb TONE_DETECT 0x81
11/26 23:00:13.46 2 intr: 0xb TONE_DETECT 0x1
11/26 23:00:13.54 2 intr: 0xb TONE_DETECT 0x85
11/26 23:00:13.61 2 intr: 0xb TONE_DETECT 0x5
11/26 23:00:13.68 2 intr: 0xb TONE_DETECT 0x8e
11/26 23:00:13.75 2 intr: 0xb TONE_DETECT 0xe
11/26 23:00:13.82 2 intr: 0xb TONE_DETECT 0x8a
11/26 23:00:13.89 2 intr: 0xb TONE_DETECT 0xa
11/26 23:00:13.95 2 intr: 0xb TONE_DETECT 0x89
11/26 23:00:14.02 2 intr: 0xb TONE_DETECT 0x9
11/26 23:00:14.09 2 intr: 0xb TONE_DETECT 0x8e
11/26 23:00:14.16 2 intr: 0xb TONE_DETECT 0xe
|
Now the TR114 is detecting incoming DTMF digits from the Octel.
Using our table from earlier in this example, we can see that the TONE_DETECT events correspond to the following DTMF digits:
|
SFLOG 1396 1700 2002/11/26-23:00:15.176 00000100 Line 3: Received
15B09B
|
The "15B09B" detected by the TR114 is passed up to the Unity Bridge service and reported as received in sflog.log.
|
SFLOG 1396 1700 2002/11/26-23:00:16.918 00000008 Line 3: Call Out
Completed.
|
The Unity Bridge service is done and requests the TR114 to hang up the call.
|
11/26 23:00:16.17 2 API version 4.1.1
11/26 23:00:16.17 2 Reset channel
11/26 23:00:16.68 2 intr: 0x3 IRSDONE 0x1
11/26 23:00:16.68 2 TR114 Boot ROM Info: V01.08 04/11/97
11/26 23:00:16.68 2 Country code 10 selected.
11/26 23:00:16.68 2 TR114 firmware download skipped
11/26 23:00:16.69 2 cmd: 0x16 ROMID 0x0
11/26 23:00:16.69 2 intr: 0x4 IDREADY 0x25
11/26 23:00:16.69 2 Firmware Info: TR114+ V1.8.12 4/14/98 ee CHK 0000
Ok
11/26 23:00:16.69 2 FW ID: "FINAL 13:56 whh"
11/26 23:00:16.69 2 cmd: 0x15 DEBUGGING 0x1
11/26 23:00:16.69 2 cmd: 0x45 ID_STRING 0x14
11/26 23:00:16.70 2 cmd: 0x2d SET_DID 0x14
11/26 23:00:16.70 2 cmd: 0x1a TONE_LEN 0x12
11/26 23:00:16.71 2 cmd: 0x1b TONE_INTERDIGIT 0xc
11/26 23:00:16.71 2 cmd: 0x1c PULSE_INTERDIGIT 0x8c
11/26 23:00:16.71 2 cmd: 0x1d PULSE_MAKE 0x8
11/26 23:00:16.72 2 cmd: 0x1e PULSE_BREAK 0xc
11/26 23:00:16.72 2 cmd: 0x18 DIAL_PARAM 0xb
11/26 23:00:16.73 2 cmd: 0x2c SET_CALL_PARA 0x12
11/26 23:00:16.74 2 cmd: 0x19 RING_PARAM 0x4
11/26 23:00:16.75 2 cmd: 0x2f DID_PARAMS 0xa
11/26 23:00:16.76 2 cmd: 0x23 SET_COUNTRY_CODE 0x0
11/26 23:00:16.76 2 cmd: 0x28 DIAL_TYPE 0x0
11/26 23:00:16.77 2 cmd: 0x47 ERROR_CHECKING 0x1
11/26 23:00:16.77 2 cmd: 0x48 ERROR_PARAM 0x83
11/26 23:00:16.78 2 cmd: 0x4f TRANSMIT_LEVELS 0x0
11/26 23:00:16.79 2 cmd: 0x49 RECEIVE_LEVEL 0x10
11/26 23:00:16.80 2 cmd: 0x25 LOOP_CURRENT_MON 0x0
11/26 23:00:16.80 2 cmd: 0x29 BEEP_ENABLE 0x0
11/26 23:00:16.81 2 set dmasize 512
11/26 23:00:16.82 2 cmd: 0x44 BIT_RATE 0x5
11/26 23:00:16.82 2 cmd: 0x46 POLL_BUTTON 0x0
11/26 23:00:16.82 2 cmd: 0x2e PHONE_PARAM 0x6
11/26 23:00:16.84 2 cmd: 0x42 T30_PARAM 0x16
11/26 23:00:16.85 2 cmd: 0x40 MODEM_SETUP 0x1
11/26 23:00:16.86 2 cmd: 0x4a FILTER_COEF 0x28
11/26 23:00:16.87 2 cmd: 0x5f ENHANCED_MODE 0x1
11/26 23:00:16.87 2 cmd: 0x41 FAX_FMT_PARAMS 0xc0
11/26 23:00:16.87 2 05 00 01 05 00 00
11/26 23:00:16.89 2 cmd: 0x64 TR_MINI_CP_PARAMS 0xa
11/26 23:00:16.90 2 setup fast xfers
11/26 23:00:16.91 2 Reset: font file '../fonts/ibmpcps.fz8' unreadable
11/26 23:00:16.91 2 cmd: 0x24 ENABLE_TONE_DET 0x3
|
The TR114 begins the process of reinitializing the channel to be ready for the next incoming or outgoing call.
|
11/26 23:00:16.91 2 await ring
11/26 23:00:16.91 2 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:16.91 2 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:18.52 1 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:18.52 0 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:18.53 0 await ring
11/26 23:00:18.53 0 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:18.53 0 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:18.53 3 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:18.53 1 await ring
11/26 23:00:18.53 1 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:18.53 1 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:18.54 3 await ring
11/26 23:00:18.54 3 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:18.54 3 cmd: 0x27 ENA_RING_DET 0x0
11/26 23:00:26.91 2 cmd: 0x26 DIS_RING_DET 0x0
11/26 23:00:26.92 2 await ring
11/26 23:00:26.92 2 cmd: 0x1f NUM_RINGS 0x1
11/26 23:00:26.92 2 cmd: 0x27 ENA_RING_DET 0x0
|
The TR114 is now ready for the next incoming or outgoing call
|
Potential Bridge Analog Protocol Communication Problems and Applicable Workarounds
A number of different factors play a role in the successful analog communication between the Bridge server and Octel servers. These can include:
•Timing and/or ability to relay DTMFs on IP gear between the Bridge and the Octel (Cisco CallManager, IP gateways, IP routers, DPAs, etc.)
•Poor analog line quality within the PSTN or PBX environment
•The Brooktrout TR114 sensitivity to certain line echo and/or timing conditions
This section focuses on the Brooktrout TR114 sensitivity to certain line echo and/or timing conditions. If analog call failure is suspected due to analog protocol communication problems on the Bridge server, the below information will help to identify known conditions based on the bridge analog call activity logs (sf logs) and recommend the adjustment to be made based on the symptom.
Condition A: Echoed Outbound DTMF Digits Are Being Detected as Inbound
When this occurs, it's most common to see it in the protocol exchange immediately following the recording of an inbound message from the Octel. But it can occur at any point at which the Bridge sends an outbound DTMF packet and detects the last digit or two as inbound digits due to echo conditions.
Example:
SFLOG 656 1488 2003/04/08-17:16:05.431 00000100 Line 4: Received 4*167#CBDDA#03D2166C4D281B3*D11221A#
SFLOG 656 1488 2003/04/08-17:16:05.431 00000008 Line 4: New Message from mailbox 37201 to mailbox 27201
SFLOG 656 1488 2003/04/08-17:16:05.431 00000100 Line 4: Playing 040D56
SFLOG 656 1488 2003/04/08-17:16:14.885 00000100 Line 4: Received
23*789AD25B8A#*5253A64BD0#9A75C58244A729C5D144
SFLOG 656 1488 2003/04/08-17:16:14.895 00000100 Line 4: Playing 030769
SFLOG 656 1488 2003/04/08-17:16:16.377 00000008 Line 4: Recording Voice
SFLOG 656 1488 2003/04/08-17:16:16.377 00000100 Line 4: Recording
c:\Bridge\Starfish\Out\20030409001616377-73a79d03-f949-4a13-9007-3bf714b19494
SFLOG 656 1156 2003/04/08-17:16:21.544 00000008 NodeCallout Activity: No Callout Activity was started.
SFLOG 656 1488 2003/04/08-17:16:22.105 00000008 Line 4: Recording completed
SFLOG 656 500 2003/04/08-17:16:22.135 00000008 New Callout started for Simultaneous Message Delivery to
Node 80200, Window Type 0
SFLOG 656 1496 2003/04/08-17:16:22.135 00000008 Line 3: Call Out Process Initiated for Node 80200 Window
Type 0.
SFLOG 656 1488 2003/04/08-17:16:23.107 00000100 Line 4: Received #
SFLOG 656 1488 2003/04/08-17:16:23.107 00000100 Line 4: Playing 8
SFLOG 656 1488 2003/04/08-17:16:24.328 00000100 Line 4: Received 8
SFLOG 656 1488 2003/04/08-17:16:25.500 00000100 Line 4: Received 9
SFLOG 656 1488 2003/04/08-17:16:26.502 00000100 Line 4: Received
SFLOG 656 1488 2003/04/08-17:16:27.243 00000008 Line 4: Incoming Call Completed.
Explanation
In the above example the Bridge is receiving an inbound voice message from an Octel server. The sending Octel sends a DTMF '#' to indicate the end of the message, to which the receiving Bridge responds with the DTMF '8'. The response expected from the Octel is the DTMF '9'. But as you can see, the DTMF '8' sent by the Bridge was also detected as an inbound DTMF due to echo problems. Because an '8' is not a valid response to the post-record '8' sent by the Bridge, the Bridge aborts the call without processing the subsequent '9'.
Workaround
1. If not already, upgrade the Cisco Unity Bridge to version 2.1(4) or later.
2. If already at 2.1(4) or later, or problems persist after upgrading to 2.1(4) or later:
a. Stop the Unity Bridge service on the Bridge server.
b. Copy all files from <installed drive>:\bridge\starfish\bin\DTMF\80Msec to <installed drive>:\bridge\starfish\bin. Answer 'yes to all' when asked if you want to overwrite the files.
c. Restart the Cisco Unity Bridge server.
3. If problems still persist after step 2, or if you begin experiencing the behavior described in Condition B below:
a. Stop the Unity Bridge service on the Bridge server.
b. Copy all files from <installed drive>:\bridge\starfish\bin\DTMF\60Msec to <installed drive>:\bridge\starfish\bin. Answer 'yes to all' when asked if you want to overwrite the files.
c. Use notepad.exe to add the following lines to the end of the file <drive>:\bridge\starfish\bin\btcall.cfg:
d. Restart the Cisco Unity Bridge server.
Condition B: Inbound "9" DTMF Response to Post-Record Outbound "8" DTMF Is Not Detected
It has been observed in some environments that there is a delay in the Brooktrout TR114 notifying the Bridge that the post-recording send of the DTMF '8' has completed. The delay is typically 1000ms. Usually this behavior is harmless because it typically takes > 1000ms for the Octel server to respond to the '8' with the DTMF '9'. However, there have been situations where the Octel server responds so fast that the DTMF '9' is sent before the TR114 is ready to receive it. In that case, the Bridge is not aware that the response came in and the call is abnormally terminated.
Example
SFLOG 820 2940 2002/11/21-20:11:32.979 00000100 Line 1: Received 01*45*B0533A*D286266*8C4D26#364*222#
SFLOG 820 2940 2002/11/21-20:11:33.011 00000008 Line 1: New Message from mailbox 9052140225 to mailbox 30013
SFLOG 820 2940 2002/11/21-20:11:33.011 00000100 Line 1: Playing 011D#0
SFLOG 820 2940 2002/11/21-20:11:33.932 00000008 Line 1: Recording Voice
SFLOG 820 2940 2002/11/21-20:11:33.932 00000100 Line 1: Recording
D:\Bridge\Starfish\Out\120444d8-b805-475e-833f-e10ad186acc7
SFLOG 820 2940 2002/11/21-20:11:40.136 00000008 Line 1: Recording completed
SFLOG 820 2940 2002/11/21-20:11:41.136 00000100 Line 1: Received #
SFLOG 820 2940 2002/11/21-20:11:41.136 00000100 Line 1: Playing 8
SFLOG 820 2940 2002/11/21-20:11:52.808 00000100 Line 1: Received
SFLOG 820 2940 2002/11/21-20:12:02.824 00000100 Line 1: Received
SFLOG 820 2940 2002/11/21-20:12:03.824 00000100 Line 1: Received
SFLOG 820 2940 2002/11/21-20:12:05.089 00000008 Line 1: Incoming Call Completed.
Explanation
In the above traces, the Octel actually did send the DTMF '9' but the TR114 was 1000ms late returning from the send of the DTMF '8' and the '9' was not detected. Using 60ms DTMF recordings on the Bridge server has proven to prevent this behavior from occurring. 60ms DTMF recordings are the default in Cisco Unity Bridge 2.1(4) and later.
Workaround
1. If not already, upgrade the Cisco Unity Bridge to version 2.1(4) or later.
2. If after upgrading to 2.1(4) you begin to observe the echo problems described in Condition A above:
a. Stop the Unity Bridge service on the Bridge server.
b. Copy all files from <installed drive>:\bridge\starfish\bin\DTMF\60Msec to <installed drive>:\bridge\starfish\bin. Answer 'yes to all' when asked if you want to overwrite the files.
c. Use notepad.exe to add the following lines to the end of the file <drive>:\bridge\starfish\bin\btcall.cfg:
d. Restart the Cisco Unity Bridge server.
Additional Notes
•The afe_config settings defined in btcall.cfg may be lost when upgrading the Cisco Unity Bridge software to a subsequent version. Verify after each upgrade that the settings are still present, and re-define them in btcall.cfg if necessary.
•None of the conditions described above result in 'lost' or truncated messages. When delivery of a message between an Octel server and the Bridge server is aborted by either end, the message will not be delivered on that attempt. Transmission of the entire message will be retried on the next call.
•Prior to 2.1(4) availability, the afe_config settings described above can be defined as per the instructions to address the either issue. They will not be preserved on the upgrade to 2.1(4) so require manual redefinition if the problem behavior persists after the upgrade.
