User Guide for IP Telephony Monitor
Working with Voice Application Systems and Software
Downloads: This chapterpdf (PDF - 209.0KB) The complete bookPDF (PDF - 5.58MB) | Feedback

Working with Voice Application Systems and Software

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.

Table E-1 Configuration Tasks by Application Software Version and System 

If you have the following voice application software...
On the following voice application systems...
You must perform the following tasks

Any voice application software that ITM supports

Media Server

Setting a Media Server's SNMP Services Community String Rights

Cisco CallManager 3.1

Cisco CallManager 3.2

Cisco CallManager 3.3

ICS 7750

Enabling SNMP for an SPE on ICS 7750

Cisco CallManager 3.1

Cisco CallManager 3.2

ICS 7750 and
Media Server

Enabling Traps and Suspect Phone Detection

Setting the CCM MIB Variables for IP Phone Movement Tracking

Cisco CallManager 3.3

Cisco CallManager 4.01

Media Server

Changing the Cisco CallManager Cluster Name

1 Cisco CallManager 4.0 is supported only if you have downloaded and installed IDU 2 or later.


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:

\\<ip_address>\icsconfig

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.