1.14 Troubleshooting

This topic provides answers to problems you may encounter when monitoring Avaya Communication Manager with AppManager.

1.14.1 Port Number Already in Use

Problem: You receive an event message similar to the following:

UDP port <port number> is already in use by phones associated with the Communication Manager at address <IP address>. You must specify a different UDP port for RTCP packets to be sent to/from the Communication Manager at address <IP address>. 

Possible Cause: You discovered more than one Communication Manager. Events are raised if multiple Communication Managers compete for the same port number. AppManager is configured to use UDP port 5005 for RTCP packet delivery and TCP port 9000 for CDR delivery.

Solution: Configure your Communication Managers to use unique port numbers. Then configure AppManager Security Manager with the new port numbers. For more information, see Configuring Communication Manager To Send RTCP Packets and CDRs and Configuring Unique Port Numbers for Multiple Communication Managers.

1.14.2 PhoneQuality Script Not Collecting Complete Data

Problem: The PhoneQuality script does not gather data about phone calls you know took place.

Possible Cause: There is a large difference between the frequency with which Communication Manager sends RTCP packets to AppManager and the frequency with which AppManager listens for incoming RTCP packets. If the frequencies are different, some calls may be lost:

  • When RTCP packets are sent less frequently than AppManager listens for them, AppManager may determine a call is completed when it is not. AppManager then marks the call complete and discards any remaining packets that arrive later for that call.

  • When RTCP packets are sent more frequently than AppManager listens for them, it takes AppManager longer to determine a call is completed, especially when the call does not contain a BYE message, which happens occasionally.

Solution: Configure Communication Manager to send RTCP packets at the same frequency with which AppManager listens for them. For more information, see Configuring Communication Manager To Send RTCP Packets and CDRs and Configuring Unique Port Numbers for Multiple Communication Managers.

1.14.3 PhoneQuality Data Points Returned Inconsistently

Problem: The PhoneQuality script returns data points at inconsistent intervals.

Possible Cause: If you monitor a large number of active phones and you collect data for most or all monitored statistics (MOS, R-Value, jitter, latency, packet loss), the AppManager agent may be unable to keep pace with the amount of data that is being collected. In this situation, the AppManager agent throttles any collected data, and then, when processing capacity permits, creates one data point based on an average of the throttled values. This throttling can result in data points created at various, inconsistent times during the monitoring period.

Solution: Perform one or both of the following tasks:

  • Reduce the number of active phones you are monitoring

  • Collect data for fewer statistics

1.14.4 Discovery Returns “SNMP Request Failure” Error

Problem: Discovery returns an SNMP Request Failure error message.

Possible Cause: A network router or switch exists between your Communication Manager servers and the proxy agent computer, and the Communication Servers are unable to recognize the IP address of the proxy agent computer. Instead, they see only the IP address of the router or switch, and so are unable to connect to the proxy agent computer using SNMP.

Solution: Configure Communication Manager to recognize the IP address of the router or switch and the IP address of the proxy computer.

To configure the IP address:

  1. Navigate to the Integrated Management Maintenance Web page for your Communication Manager.

  2. For Community name, type ion-test.

  3. In the left pane, click SNMP Agents.

  4. In the “IP Addresses for SNMP Access” section, select Following IP addresses.

  5. In the IP address fields, type the IP addresses of your proxy agent computer and the router or switch that lies between the proxy agent computer and the Communication Manager server.

  6. Click Submit.

1.14.5 Knowledge Script Returns “SNMP Timeout” Error

Problem: Running an AvayaCM Knowledge Script job returns the following error: CHR0392: An SNMP request sent to [IP address] timed out.

Possible Causes: An SNMP timeout has several possible causes:

  • The Avaya SNMP agent is set to SNMP version 1.

  • The server is down or is not running an SNMP agent.

  • The server’s SNMP agent is down.

  • Network congestion or packet loss occurred during the SNMP request.

  • The SNMP community string you provided is incorrect.

  • The queried G3-AVAYA-MIB SNMP tables have not repopulated.

  • The default SNMP timeout period is too short.

  • The Communication Manager is experiencing an internal failure that prevents SNMP communication.

Solutions: Try one or more of the following solutions:

  • Configure each server for SNMP v2. For more information, see “Administering SNMP Agents” in the Administrator Guide for Avaya Communication Manager. If you use the Integrated Management Maintenance Web page to configure SNMP settings in a cluster, the SNMP settings apply only to the server that you are connected to and not to all servers in the cluster. Connect to each server individually and configure SNMP and the firewall.

  • Verify the status of the server or the existence of the SNMP agent.

  • Verify the status of the SNMP agent.

  • Wait and run the script later. Or, if you have NetIQ Vivinet Diagnostics installed, run a diagnosis on the affected IP address.

  • Provide correct community strings in AppManager Security Manager. For more information, see Configuring SNMP Community Strings.

  • Wait for tables to be repopulated. Some tables in the Avaya MIBs repopulate only once an hour.

  • Provide a longer timeout value in the Global SNMP timeout parameter in the Discovery_AvayaCM script. You can verify the current timeout period by selecting the Active SPE object in the TreeView pane and clicking the Details tab. After changing the timeout value, rerun the Discovery job.

1.14.6 Supplemental Database Grows Too Large

Problem: The AvayaCM supplemental database is not pruned by the SQL job that runs every night to clean up the database.

Possible Cause: Your supplemental database is on a SQL Server 2005 Express computer. The overnight SQL job requires Integration Services, which is not supported on SQL Server 2005 Express.

Solution: Run the following stored procedure from a command line. Then configure a Windows Scheduled Task to schedule pruning at an interval of your choosing.

osql -E -S <sql server> -n -d <
database
> -" "exec dbo.Task_AvayaCM_Pruni"ng

where <sql server> is the name of the server that hosts the supplemental database, and where <database> is the name of the database.

For example: osql -E -S SuppDBAvaya -n -d AvayaCM_S8300-Cluster -Q "exec dbo.Task_AvayaCM_Pruning”

The process for configuring a Windows Scheduled Task varies according to your version of Microsoft Windows. Consult your Windows documentation for more information.