Table Of Contents
Working with Voice Application Systems and Software
Configuring Voice Application Systems and Software for Use with ITM
Enabling SNMP for an SPE on ICS 7750
Enabling Traps and Suspect Phone Detection
Changing the Cisco CallManager Cluster Name
Setting a Media Server's SNMP Services Community String Rights
Setting the CCM MIB Variables for IP Phone Movement Tracking
Determining when to Issue a CCMHttpServiceInaccessible Event
Working with Voice Application Systems and Software
The following topics describe hardware-specific and version-specific tasks and behavior:
•
Configuring Voice Application Systems and Software for Use with ITM
•
Determining when to Issue a CCMHttpServiceInaccessible Event
Note
See Cisco CallManager Compatibility Matrix on Cisco.com for complete up-to-date information about Cisco CallManager versions and support.
Configuring Voice Application Systems and Software for Use with ITM
Table E-1 lists tasks that you must perform before ITM can successfully monitor Cisco voice application software.
Enabling SNMP for an SPE on ICS 7750
Note
You must use this procedure only if you are running an ICS 7750 with Cisco CallManager 3.1 or 3.2.
If you have an ICS 7750, you must enable SNMP for each SPE Cisco CallManager:
Step 1
From the Cisco CallManager Administration pages, enable SNMP (EnableSNMP) in the Service Parameter window.
Step 2
Restart the SPE through the System Manager:
a.
From a command prompt, start the System Manager.
For example:
b.
Click the shutdown/restart link.
c.
Click the restart button for the SPE.
Enabling Traps and Suspect Phone Detection
Note
You must use this procedure only if you are running an ICS 7750 with Cisco CallManager 3.1 or 3.2.
This procedure enables ITM to do the following:
•
Receive traps from Cisco CallManager Release 3.1 and 3.2.
•
Detect suspect phones for Cisco CallManager Release 3.2.
Note
You do not need to run this procedure on a media server running Cisco CallManager 3.3 or 4.0.
Step 1
On the ITM system, open a DOS command prompt.
Step 2
Navigate to <NMSROOT>\objects\vhm\bin.
Note
NMSROOT is the directory where CiscoWorks is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.
Step 3
Enter the EnableTrapAndSuspectPhone command followed by these parameters: <read/write community string> <Cisco CallManager system name>.
For example, enter:
d:\> EnableTrapAndSuspectPhone admin 172.20.121.2
Step 4
Press Enter.
Changing the Cisco CallManager Cluster Name
Note
You must use this procedure only if you are running a media server with Cisco CallManager 3.3 or 4.0.
ITM cannot manage two clusters with the same name. If you are managing multiple Cisco CallManager 3.3 clusters, you must change the default cluster name. Cisco CallManager 3.3 uses the default cluster name StandAloneCluster.
Note
For detailed instructions on configuring Cisco CallManager, see the Cisco CallManager documentation.
Step 1
Open the Cisco CallManager Administration page.
Step 2
From the menu bar, select System, and choose Enterprise Parameters. The Enterprise Configuration page opens.
Step 3
In the Cluster ID field, enter a new cluster name.
Step 4
Click Update.
Setting a Media Server's SNMP Services Community String Rights
Note
Use this procedure on media servers running voice application software.
ITM cannot monitor supported voice applications running on a media server if community string rights for SNMP services are set to none. The SNMP queries will not succeed unless the rights for the community string are changed to read-only, read-write, or read-create.
Step 1
On the media server system, select Start > Settings > Control Panel > Administrative Tools > Services. The Services window opens.
Step 2
Double-click SNMP Service. The SNMP Services Properties window opens.
Step 3
Select the Security tab.
Step 4
Select Community String and click Edit.
Step 5
Change the rights from NONE to READ ONLY.
Note
ITM requires read-only rights. You are not required to set the rights to read-write or read-create.
Setting the CCM MIB Variables for IP Phone Movement Tracking
Note
You must use this procedure only if you are using Cisco CallManager 3.1 or 3.2.
For IP Phone Movement Tracking to work (see the "IP Phone Movement Tracking (Minor Discovery)" section) you must make sure that the following MIB variables of CISCO-CCM-MIB are set to the appropriate values:
•
ccmPhoneStatusUpdateStorePeriod
•
ccmPhoneFailedStorePeriod
For each Cisco CallManager, use the utility SetCCMStorePeriods to set these variables. The utility is available under:
NMSROOT/conf/pif/bin
Note
NMSROOT is the directory where ITM is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.
The utility consists of the following:
SetCCMStorePeriods [ -f failedStorePeriod ] [ -u statusUpdateStorePeriod ] ccmAddress rwCommunity
If you do not specify the -u and -f options, the utility uses the following default values:
statusUpdateStorePeriod = 1800 (seconds)
and
failedStorePeriod = 1800 (seconds)
Determining when to Issue a CCMHttpServiceInaccessible Event
Note
The information in this topic applies to a Cisco CallManager cluster, the nodes of which run Cisco CallManager Release 4.0 or later only. Cisco CallManager 4.0 is supported only if you have installed IDU 2 or later.
ITM follows standard serviceability guidelines by querying the publisher in a Cisco CallManager cluster. If the publisher rejects the query, ITM generates the CCMHttpServiceInaccessible event for the cluster without querying other nodes (Cisco CallManagers) as per Cisco CallManager serviceability guidelines.
Table E-2 explains how ITM determines when to generate the CCMHttpServiceInaccessible event and what you can do to decrease the number of events.
Table E-2 Understanding and Responding to CCMHttpServiceInaccessible Events
Why Cisco CallManager Might Reject a Query
|
How ITM Handles a Rejected Query
|
How You Can Handle Specific Instances of These Events
|
Client request rate is higher than allowed by server.
|
• Retries for 4 minutes at 30-second intervals.
• After 4 minutes, if the Cisco CallManager continues to reject the query, ITM writes an error message to the log file.
• After an additional 4 minutes, if the query continues to fail, ITM generates the CCMHttpServiceInaccessible event.
|
Check the Cisco CallManager for high CPU usage.
If event occurs during polling, consider increasing Cisco CallManager or cluster polling settings (see Table 17-6). See the "Editing Polling Parameters" section.
If event occurs during discovery, perform rediscovery. See the "Rediscovering a Device" section.
|
Cannot handle the request within 30 seconds.
|
• Retries for 4 minutes at 1-minute intervals.
• After 4 minutes, if the Cisco CallManager continues to reject the query, ITM writes an error message to the log file.
• After an additional 4 minutes, if the query continues to fail, ITM generates the CCMHttpServiceInaccessible event.
|
Check the Cisco CallManager for high CPU usage.
If event occurs during polling, consider increasing Cisco CallManager or cluster polling settings (see Table 17-6). See the "Editing Polling Parameters" section.
If event occurs during discovery, perform rediscovery. See the "Rediscovering a Device" section.
|