Cisco PGW 2200 Softswitch Release 9 Operations, Maintenance, and Troubleshooting Guide - Chapter 3 - Cisco PGW 2200 Softswitch Platform Operations [Cisco PGW 2200 Softswitch]

Table Of Contents

Cisco PGW 2200 Softswitch Platform Operations

Daily Tasks

Starting an MML Session

Verifying the Platform State of the Cisco PGW 2200 Softswitches

Verifying That Processes Are Running

Understanding Processes

Monitoring the Alarms Status

Understanding Alarms

An Alarm Example

Verifying the Status of all Signaling Services

Understanding the Signaling Service State Information

Verifying State of all SS7 Routes

Understanding the SS7 Route State Information

Verifying CIC States

Understanding CIC States

Verifying System Statistics

Verifying the Number of Active Processes

Verifying the Number of Users

Verifying Available Virtual Memory

Verifying Available Memory on the Cisco ITP-Ls

Periodic Maintenance Procedures

Automatic Disk Space Monitoring

Configuring Disk Monitor

Automatic System Log Rotation

Rotating System Logs Manually

Creating a Disaster Recovery Plan

Backing Up System Software

Backup Procedures for Cisco PGW 2200 Softswitch Software

Processing a Core Dump File

Regular Operations

Managing MML Sessions

Displaying Previously Entered MML Commands

Displaying Information About MML Commands

Reentering Previously Entered MML Commands

Retrieving Active MML Sessions

Ending an MML Session

Managing Signaling Channels

Retrieving Signaling Service States

Retrieving Service State of C7/SS7 Links or Linksets

Retrieving the Service State for IP Links

Retrieving the Service State for IP Routes

Retrieving the Service State of D-Channels

Retrieving the State of SS7 Signaling Services

Retrieving the State of SS7 Routes

Retrieving the State of All Local Subsystem Numbers

Retrieving the Service State for Associations

Retrieving TCAP Transactions

Clearing TCAP Transactions

Enabling Group Service Reset Messages

Managing Bearer Channels

Verifying Proper Replication of Calls

Retrieving the States of Bearers Held By a Media Gateway

Blocking CICs

Retrieving the Administrative State

Retrieving DPNSS Virtual Bearer Channel Status

Managing SIP Communications

Managing the DNS Cache

Retrieving SIP Call Information

Provisioning your Cisco PGW 2200 Softswitch

Starting a Provisioning Session

Saving and Activating your Provisioning Changes

Ending a Provisioning Session Without Activating your Changes

Invoking Dynamic Reconfiguration

Retrieving Provisioning Data

Provisioning a Dial Plan

Importing Provisioning Data

Exporting Provisioning Data

Managing Automatic Congestion Control

Managing your Cisco PGW 2200 Softswitch Platform

Performing a Manual Switchover

Verifying Successful Completion of a Switchover

Verifying the Patch Level of the Cisco PGW 2200 Softswitch

Retrieving the Logging Level of Software Processes

Retrieving System Statistics

Managing System Measurements

Retrieving Measurements

Clearing Measurements

Retrieving Link or Linkset Measurements

Retrieving SS7 Signaling Point Measurements

Retrieving Measurement Thresholds

Modifying Measurement Thresholds

Managing Call Detail Records

Converting Individual CDR Files to ASCII Format

Converting Individual CDR Files to a Readable Format

Using the Cisco MGC Viewer Toolkit

Launching the Cisco MGC Toolbar

Using the Alarm Viewer

Using the Call Detail Record Viewer

Using the Config-Lib Viewer

Using the Log Viewer

Using the Measurement Viewer

Using the Trace Viewer

Using the Translation Verification Viewer

Using the File Options Viewer

Using the MGC Backup Viewer

Using the MGC Restore Viewer

Cisco PGW 2200 Softswitch Platform Operations

Revised: December 7, 2009, OL-0800-12

This chapter contains recommended operating procedures for the Cisco PGW 2200 Softswitch platform. In these procedures, the assumption is that all components have been correctly installed, configured, and provisioned in accordance with the instructions provided in the relevant documentation. All components are assumed to have been successfully started, as described in Chapter 2, "Cisco PGW 2200 Softswitch Platform Component Startup and Shutdown Procedures."

Note Operation of the Cisco PGW 2200 Softswitch platform should be performed by someone who has been trained in the complexities of the system, who has some experience administering the system, and who understands UNIX at the system administrator level.

This chapter contains the following sections:

•Daily Tasks

•Periodic Maintenance Procedures

•Regular Operations

Daily Tasks

The following section details the procedures you should perform on a daily basis on the Cisco PGW 2200 Softswitch. These procedures use Man-Machine Language (MML) and UNIX commands. These procedures can also be performed using the optional Cisco MGC Node Manager (MNM) application. For more information on using the Cisco MNM to operate the Cisco PGW 2200 Softswitch, see the Cisco Media Gateway Controller Node Manager User Guide.

The tasks you should perform on a daily basis are found in the following sections:

•Starting an MML Session

•Verifying the Platform State of the Cisco PGW 2200 Softswitches

•Verifying That Processes Are Running

•Monitoring the Alarms Status

•Verifying the Status of all Signaling Services

•Verifying State of all SS7 Routes

•Verifying CIC States

•Verifying System Statistics

•Verifying the Number of Active Processes

•Verifying the Number of Users

•Verifying Available Virtual Memory

•Verifying Available Memory on the Cisco ITP-Ls

Starting an MML Session

When a procedure requires that you start an MML session, you must perform the following steps:

Note We recommend that you run your MML sessions from the active Cisco PGW 2200 Softswitch, unless the procedure indicates otherwise.

Step 1 Log in to the active Cisco PGW 2200 Softswitch.

Note Do not log in as UNIX root. The MML session fails if you attempt to start it as UNIX root.

Step 2 Enter the following command at the UNIX prompt:
mml
If you receive an error message indicating that sessions are already in use, enter the following command:
mml -s session number
Use any session number from 2 through 12 and repeat until you find a vacant session. Once you have successfully started an MML session, the prompt changes to:
machine_name mml>
Verifying the Platform State of the Cisco PGW 2200 Softswitches

You can determine which of your Cisco PGW 2200 Softswitches is the active Cisco PGW 2200 Softswitch and which is the standby Cisco PGW 2200 Softswitch. If your system uses a Cisco PGW 2200 Softswitch in a simplex configuration, the single Cisco PGW 2200 Softswitch is always active. To do this, complete the following steps:

Step 1 Log into one of the Cisco PGW 2200 Softswitches, start an MML session, and enter the following command to determine its platform state:
rtrv-ne
The system should return a message, similar to the following, if it is currently the active Cisco PGW 2200 Softswitch:
MGC-01 - Media Gateway Controller 2008-10-07 02:56:16.623 EDT
M  RTRV
   "Type:MGC"
   "Hardware platform:sun4u sparc SUNW,Sun-Fire-V210"
   "Vendor:"Cisco Systems, Inc.""
   "Location:MGC-01 - Media Gateway Controller"
   "Version:"9.8(1)""
   "Platform State:ACTIVE"
The valid values for the Platform State field are ACTIVE, STANDBY, or OOS.

Step 2 Log into the other Cisco PGW 2200 Softswitch, start an MML session, and enter the following command to determine its platform state:
rtrv-ne
The system should return a message that indicates that it is in either the active or standby platform state.

If the Cisco PGW 2200 Softswitches have changed their platform state, determine why the switchover occurred by searching the contents of the active system log file, as described in the "Viewing System Logs" section on page 8-83.

Under normal operations, one Cisco PGW 2200 Softswitch should be active and the other Cisco PGW 2200 Softswitch should be standby.

If the platform state of either Cisco PGW 2200 Softswitch is OOS, check the alarms as described in the "Monitoring the Alarms Status" section, and take the actions necessary to correct the condition that caused the associated alarm(s). The alarms that require you to take corrective action and their associated actions can be found in the "Alarm Troubleshooting Procedures" section on page 8-4. A complete listing of alarms can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

If the platform state of both Cisco PGW 2200 Softswitch is active, proceed to Step 5.

Step 3 Use the following command to quit the MML session:
quit
Step 4 Verify that the active configuration has not changed using the following UNIX commands:
cd /opt/CiscoMGC/etc
ls -l
The system returns a response similar to the following:
total 35350
-rw-r--r--   1 mgcusr mgcgrp     38240 May  8 10:46 02.trigger
-rw-rw-r--   1 mgcusr   mgcgrp     20488 Oct 10  2000 64eisup.bat
lrwxrwxrwx   1 mgcusr   mgcgrp        43 Aug  1 18:55 active_link -> 
/opt/CiscoMGC/etc/CONFIG_LIB/CFG_pol-addipl
-rw-rw-rw-   1 mgcusr   mgcgrp     30907 Jul 24 15:29 alarmCats.dat
-rw-rw-rw-   1 mgcusr   mgcgrp      2064 Jun  4 10:57 alarmTable.dat
-rw-rw-rw-   1 mgcusr   mgcgrp         0 Jun  4 10:57 auxSigPath.dat
Identify the active_link file. The listing indicates which configuration is currently active. The active configuration in the example is CFG_pol-addipl.

If the configuration has changed, you may want to compare the active configuration to the previous configuration.

Step 5 Collect system data as described in the "Collecting System Data for Cisco TAC" section on page 8-87 and contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xx.

Verifying That Processes Are Running

To verify that the processes on your Cisco PGW 2200 Softswitch are running, perform the following steps:

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-softw:all
The system returns a response similar to the following:

Note This is an example on Cisco PGW 2200 Softswitch Release 9.7(3) Patch 14. The system output varies based on your software version, patch version, and configuration.
MGC-01 - Media Gateway Controller 2008-04-16 00:22:02.696 EDT
M  RTRV
   "CFM-01:RUNNING ACTIVE"
   "ALM-01:RUNNING ACTIVE"
   "MM-01:RUNNING ACTIVE"
   "AMDMPR-01:RUNNING ACTIVE"
   "CDRDMPR-01:RUNNING ACTIVE"
   "DSKM-01:RUNNING IN N/A STATE"
   "MMDB-01:RUNNING IN N/A STATE"
   "POM-01:RUNNING ACTIVE"
   "MEASAGT:RUNNING ACTIVE"
   "OPERSAGT:RUNNING ACTIVE"
   "Replic-01:RUNNING ACTIVE"
   "ENG-01:RUNNING ACTIVE"
   "IOCM-01:RUNNING ACTIVE"
   "TCAP-01:RUNNING IN N/A STATE"
   "FOD-01:RUNNING IN N/A STATE"
   "LMAGT-01:RUNNING ACTIVE"
   "pril3-1:RUNNING IN N/A STATE"
   "mgcp-1:RUNNING IN N/A STATE"
<Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
   "h248-1:RUNNING IN N/A STATE"
   "sip-1:RUNNING IN N/A STATE"
   "eisup-1:RUNNING IN N/A STATE"
   "eisup-2:RUNNING IN N/A STATE"
   "ss7-i-1:RUNNING IN N/A STATE"
   "m3ua-1:RUNNING IN N/A STATE"
   "sua-1:RUNNING IN N/A STATE"
   "iua-1:RUNNING IN N/A STATE"
Note If any of the processes are stopped, you can see "process name:STOPPED" in the system output.

Note If this MML command is entered on the standby Cisco PGW 2200 Softswitch, the state of the processes is either RUNNING STANDBY or RUNNING IN N/A STATE.

Step 2 If any of the processes are initializing, wait a few moments and repeat Step 1. If that process is still initializing, contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

If any of the processes are stopped, contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

Understanding Processes

The Cisco PGW 2200 Softswitch software contains processes and process groups that perform various functions. These functions include managing the I/O channels; generating alarms, call detail records (CDRs), and logs; and performing signal conversion. All these processes are managed by the process manager process of the Cisco PGW 2200 Softswitch software.

Three different monitoring levels are offered:

•Active process—Controlled and monitored directly by the process manager.

•Passive process—Does not communicate with the process manager.

•Monitoring process—Periodically runs an executable or script and sets or clears an alarm based on the return code. This type of process can monitor other processes or tasks that can be checked programmatically. Some examples are the amount of available disk space, system daemon existence, and established process dependency.

Table 3-1 shows the system processes and process groups controlled by the process manager. All the processes are in the directory /opt/CiscoMGC/bin.

Table 3-1 Processes Controlled by the Process Manager

Group

Process

Description

ENGG-01

Engine Group

Replic-01

Replicator controller. It is an active process. If it should go down, it causes a critical out-of-service alarm.

ENG-01

Call engine. It is an active process. If it should go down, the system cannot process calls. Its failure causes a critical out-of-service alarm.

IOSG-01

I/O Subsystem Group

IOCM-01

I/O channel manager. It is a passive process. If it should go down, it causes a major out-of-service alarm.

TCAP-01

TCAP and SCCP protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

pril3-1

ISDN protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

mgcp-1

MGCP protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

h248-1

H.248 protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

sip-1

SS7 protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

eisup-1

EISUP protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

ss7-i-1

SS7 protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

m3ua-1

M3UA protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

sua-1

SUA protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

iua-1

IUA protocol handler. It is a passive process. If it should go down, it causes a major out-of-service alarm.

XEG-01

Execution Environment Group

CFM-01

Configuration manager. It is an active process. If it should go down, it causes a major out-of-service alarm.

ALM-01

Alarm manager. It is an active process. If it should go down, it causes a major out-of-service alarm.

AMDMPR-01

Alarm and measurement dumper. It is an active process. If it should go down, it causes a major out-of-service alarm.

MM-01

Measurement manager. It is an active process. If it should go down, it causes a major out-of-service alarm.

CDRDMPR-01

CDR dumper. It is an active process. If it should go down, it causes a major out-of-service alarm.

MMDB-01

TimesTen database. It is a passive process. If it should go down, it causes a minor out-of-service alarm.

POM-01

Provisioning object manager. It is an active process. If it should go down, it causes a major out-of-service alarm.

FTG-01

Failover Group

FOD-01

Failover controller. It is a monitoring process. If it should go down, it causes a minor out-of-service alarm.

PFMG-01

Platform Monitoring Group

DSKM-01

Disk space monitor. This shell script monitors disk space and trims back older files in case the current amount of free space is below a specified threshold. This is a monitoring process. If it should go down, it causes a minor out-of-service alarm.

LMAGT-01

Cisco PGW 2200 Softswitch license management agent. This is a active process. If it should go down, it causes a critical out-of-service alarm.

SNMPG-01

SNMP Group

MEASAGT

Measurements SNMP agent. This is an active process. If it should go down, this is a major out-of-service alarm.

OPERSAGT

Operational SNMP Agent. This is an active process. If it should go down, this is a major out-of-service alarm.

Monitoring the Alarms Status

If you monitor the alarm status of the Cisco PGW 2200 Softswitch continuously, you can determine how often a particular alarm occurs in a specific period of time. To monitor the alarm status of the Cisco PGW 2200 Softswitch on a continuous basis, perform the following steps:

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-alms::cont
The system returns a response that shows all active alarms:
MGC-01 - Media Gateway Controller 2001-11-16 11:57:54.949 EST
 M  RTRV
    "AMDMPR-01: 2001-11-16 11:57:54.583 EST,ALM=\"MAJOR M-OOS\",SEV=MJ"
    "CDRDMPR-01: 2001-11-16 11:57:54.583 EST,ALM=\"MAJOR M-OOS\",SEV=MJ"
    "MMDB-01: 2001-11-16 11:57:54.583 EST,ALM=\"SOFTW NON\",SEV=MJ"
    "MMDB-01: 2001-11-16 11:57:54.583 EST,ALM=\"MINOR M-OOS\",SEV=MN"
    "MEASAGT: 2001-11-16 11:57:54.583 EST,ALM=\"SOFTW NON\",SEV=MJ"
    "MEASAGT: 2001-11-16 11:57:54.583 EST,ALM=\"MAJOR M-OOS\",SEV=MJ"
    "UNK: 2001-11-16 11:57:54.583 EST,ALM=\"CHAN BAD TOT 15\",SEV=MN"
    "UNK: 2001-11-16 11:57:54.583 EST,ALM=\"CHAN BAD TOT 60\",SEV=MN"
    "UNK: 2001-11-16 11:57:54.583 EST,ALM=\"CHAN BAD TOT 24\",SEV=MN"
    "UNK: 2001-11-16 11:57:54.583 EST,ALM=\"CHAN BAD TOT 15\",SEV=MN"
    "UNK: 2001-11-16 11:57:54.583 EST,ALM=\"CHAN BAD TOT 60\",SEV=MN"
    "UNK: 2001-11-16 11:57:54.583 EST,ALM=\"CHAN BAD TOT 24\",SEV=MN"
    ;
Step 2 If an alarm appears, you can determine the appropriate course of action by referring to the listing for that alarm in the Cisco PGW 2200 Softswitch Release 9 Messages Reference. Detailed descriptions of the actions required to resolve the problems associated with the alarm are found in "Alarm Troubleshooting Procedures" section on page 8-4.

You can also find additional information on the conditions that caused the alarms by viewing the system logs. The logs can be viewed using the log viewer, part of the Cisco MGC viewer toolkit. For information on using the log viewer, see the "Using the Log Viewer" section.

Use the Ctrl-C keyboard command to stop the alarm monitor.

Note Once you have begun monitoring alarms continuously, you will need to open another MML session to perform any additional tasks. See the "Starting an MML Session" section for more information on starting additional MML sessions.

Understanding Alarms

The following subsections describe each of the message components for the typical alarm response shown below:
	"LPC-01: 2001-02-26 09:16:07.806 EST,ALM=\"SCMGC MTP3 COMM FAIL\",SEV=MJ"
	"IOCM-01: 2001-02-26 09:17:00.690 EST,ALM=\"Config Fail\",SEV=MN"
	"MGC1alink2: 2001-02-26 09:17:47.224 EST,ALM=\"SC FAIL\",SEV=MJ"
	"MGC1alink3: 2001-02-26 09:17:47.225 EST,ALM=\"SC FAIL\",SEV=MJ"
Component ID

The first element of the alarm message identifies the system component that generated the alarm, using the customer-defined description of the component given during system provisioning. In our example, these are LPC-01, IOCM-01, MGC1alink2, and MGC1alink3.

All system components are described in the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide.

Time Stamp

The second element of the alarm message identifies the time of the alarm by year, month, day, hour, minute, hundredths, thousandths of a second (milliseconds), and time zone. The time displayed is the system time. In the example, these would be 2001-02-26 09:16:07.806 EST, 2001-02-26 09:17:00.690 EST, 2001-02-26 09:17:47.224 EST, and 2001-02-26 09:17:47.225 EST.

Alarm Category

The third element of the alarm message identifies the alarm category. It indicates the MML description of the alarm/event. In our example:

•ALM=\"SCMGC MTP3 COMM FAIL\" indicates an SCMGC-MTP3 communications failure.

•ALM=\"Config Fail\" indicates a configuration failure.

•ALM=\"SC FAIL\" indicates a signal channel failure.

Severity Level

The last element of the alarm message identifies the severity level of the alarm. The four levels are

•Critical (CR)—A serious problem exists in the network. Critical alarms cause a switchover, where the active Cisco PGW 2200 Softswitch switches processing to the standby Cisco PGW 2200 Softswitch. Because critical alarms affect service, they should be cleared immediately.

Caution Critical alarms cause the system to automatically switchover. While a switchover is in progress, new calls are dropped and in-progress calls are sustained.

•Major (MJ)—A problem exists that disrupts service. Major alarms should be cleared immediately. These alarms differ from critical alarms in that they do not cause a switchover from the active
Cisco PGW 2200 Softswitch to the standby Cisco PGW 2200 Softswitch.

•Minor (MN)—Minor alarms should be noted and cleared as soon as possible. You might also want to research how often this alarm is appearing, because it may be an indicator of a bigger problem.

•Informational (IN)—This severity level applies to messages that provide information about typical events and conditions. Informational messages do not require corrective action. Examples are timer expirations, values that have exceeded preset thresholds, and unexpected responses from endpoints to signaling messages sent by the Cisco PGW 2200 Softswitch. Events with a severity level of informational are retrieved only by the SNMP Manager.

An Alarm Example

This section gives an alarm example, SS7 SIG SRVC UNAVAIL.

Output of rtrv-alms MML command
MGC-01 - Media Gateway Controller 2008-4-21 03:14:42.733 EDT
 M  RTRV
    "ss7svc1: 2008-4-21 03:12:15.563 EDT,ALM=\"SS7 SIG SRVC UNAVAIL\",SEV=MJ"
In this example, the component that generates the alarm is ss7svc1. The timestamp for this alarm is 2008-4-21 03:12:15.563 EDT. The alarm category indicates that an SS7 signaling service is unavailable. The severity for this alarm is major.

Details for this alarm

To view the detailed description, cause, alarm type, severity and action of this alarm, see the Cisco PGW 2200 Softswitch Release 9 Messages Reference at

http://www.cisco.com/en/US/docs/voice_ip_comm/pgw/9/system/message/errmsg.html

Alarm Log

To view the archived alarm, view alm.csv in the folder /opt/CiscoMGC/var/log.
...
0, 1208761935,127,0,2,"SS7 Signaling Service Unavailable", "ss7svc1", "IosChanMgr"
...
See the "Understanding the Format of Log Files Archived Using Data Dumper" section on page A-5 for the detailed information on the alarm log format.

Verifying the Status of all Signaling Services

To verify the status of all of the signaling services provisioned on your Cisco PGW 2200 Softswitch, perform the following steps:

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-dest:all
The system returns a response similar to the following:
   Media Gateway Controller - MGC-04 2000-04-05 08:05:36
M  RTRV
   "sigsrv1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
   "sigsrv2:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
   "sigsrv3:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
   "sigsrv4:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
   "sigsrv5:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
   "sigsrv6:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
   "eisupftsvc:PKG=EISUP,ASSOC=SWITCHED,PST=IS,SST=UND"
   "eisupsvc1:PKG=EISUP,ASSOC=SWITCHED,PST=IS,SST=UND"
Note If the rtrv-dest:all MML command is entered after a switchover has occurred, the state of some of the signaling services might be listed as undefined (UND). UND is the default state for a signaling service when the system starts. In this instance, UND states indicate that the Cisco PGW 2200 Softswitch has not received a service state message for the associated signaling service since the switchover occurred. No user action is required.

Step 2 If the primary service state is not IS for any of the signaling service, check your alarms retrieval MML session for signaling-related alarms. The method for setting up an alarms retrieval MML session is described in the "Monitoring the Alarms Status" section.

If a signaling-related alarm appears, you can determine the appropriate course of action by searching for the corrective actions for that alarm in the "Alarm Troubleshooting Procedures" section on page 8-4. If the alarm is not in that section, corrective action is not required. More information on the alarm can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

You can also find additional information on the conditions that caused the alarms by viewing the system logs. The logs can be viewed using the log viewer, part of the Cisco MGC viewer toolkit. For information on using the log viewer, see the "Using the Log Viewer" section.

Note You can use the also use the rtrv-dest MML command to retrieve information on individual signaling services using the procedure found in the "Retrieving Signaling Service States" section.

Understanding the Signaling Service State Information

The following sections describe the information returned by the system when you enter the rtrv-dest command, as in the example below:
"sigsrv1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
"sigsrv2:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
"sigsrv3:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"
Destination

The first field lists the MML name of the associated signaling service. In the above example, this is sigsrv1, sigsrv2, and sigsrv3.

Package

The PKG field lists the protocol package associated with the destination. In the example, the protocol is SS7-ANSI.

Association

The ASSOC field shows the type of association, either unknown, switched, or a specific channel for the signaling service. In the example, the association type is SWITCHED.

Primary Service State

The PST field shows the current primary service state of the signaling service. In the example, all of the signaling services have a primary service state of IS. Table 3-2 lists the valid primary service state values:

Table 3-2 Signaling Service Primary Service States

Link State ID

Link State

Description

AOOS

Automatically out-of-service

The system has taken the signaling service out-of-service (OOS).

INB

Install busy

When a system is first configured, all signaling links default to this state and must be manually set in-service (IS) through the use of the set-c7lnk, set-iplnk, or set-dchan MML commands.

IS

In-service

The link to the signaling service is IS and fully operational. This is its normal operating state.

MOOS

Manually out-of-service

The link to the signaling service has been manually taken OOS.

OOS

Out-of-service

The link to the signaling service is OOS from the remote end. The system is actively trying to restore the link.

TRNS

Transient

The state of the link to the signaling service is currently being changed.

UNK

Unknown

The state of the link to the signaling service is not known.

Secondary Service State

The SST field shows the current secondary service state of the specified signaling service. In the example, all of the signaling services have a secondary service state of UND. The valid states are listed below:

•CEA—Commanded into emergency alignment.

•CIS—Commanded in service.

•CONG—Congestion.

•COOS—Commanded out of service.

•CINH—Commanded to the inhibited state.

•CRTE—Created.

•CUINH—Commanded to the uninhibited state.

•DLT—Deleted.

Note DLT is a transition state. It is seen when you are making provisioning changes to the associated signaling service.

•EIS—Engine in service.

•EOOS—Engine out of service.

•FLD—Failed.

•FOOS—Forced out of service.

•RST—Reset.

•RSTO—Restored.

•UND—Undefined.

Note If the rtrv-dest MML command is entered after a switchover has occurred, the state of some of the signaling services might be listed as undefined (UND). UND is the default state for a signaling service when the system starts. In this instance, UND states indicate that the
Cisco PGW 2200 Softswitch has not received a service state message for the associated signaling service since the switchover occurred. No user action is required.

Verifying State of all SS7 Routes

To verify the status of all of the SS7 routes provisioned on your Cisco PGW 2200 Softswitch, perform the following steps:

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-rte:all
The system returns a message similar to the following:
Media Gateway Controller - MGC-01 2002-05-22 15:19:51 M RTRV 
   "ss7srv1:linkset1,APC=apc-1,OPC=opc-1,PRIO=1,PST=IS,SST=NA"
   "ss7srv1:linkset2,APC=apc-2,OPC=opc-1,PRIO=1,PST=IS,SST=NA"
   "ss7srv2:linkset1,APC=apc-3,OPC=opc-2,PRIO=1,PST=IS,SST=NA"
   "ss7srv2:linkset2,APC=apc-3,OPC=opc-2,PRIO=1,PST=IS,SST=NA"
   "ss7srv3:linkset1,APC=apc=4,OPC=opc-3,PRIO=1,PST=IS,SST=NA"
   "ss7srv3:linkset2,APC=apc=4,OPC=opc-4,PRIO=1,PST=IS,SST=NA"
Step 2 If the primary service state is not IS for any of the routes, check your alarms retrieval MML session for signaling-related alarms. The method for setting up an alarms retrieval MML session is described in the "Monitoring the Alarms Status" section.

If a signaling-related alarm appears, you can determine the appropriate course of action by searching for the corrective actions for that alarm in the "Alarm Troubleshooting Procedures" section on page 8-4. If the alarm is not in that section, corrective action is not required. More information on the alarm can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

You can also find additional information on the conditions that caused the alarms by viewing the system logs. The logs can be viewed using the log viewer, part of the Cisco MGC viewer toolkit. For information on using the log viewer, see the "Using the Log Viewer" section.

Understanding the SS7 Route State Information

The following sections describe the information returned by the system when you enter the rtrv-rte command, as shown in the example below:
"ss7srv1:linkset1,APC=apc-1,OPC=opc-1,PRIO=1,PST=IS,SST=NA"
"ss7srv1:linkset2,APC=apc-2,OPC=opc-1,PRIO=1,PST=IS,SST=NA"
"ss7srv2:linkset1,APC=apc-3,OPC=opc-2,PRIO=1,PST=IS,SST=NA"
"ss7srv2:linkset2,APC=apc-3,OPC=opc-2,PRIO=1,PST=IS,SST=NA"
Signaling Service

The first field lists the MML name for the signaling service associated with the SS7 route. In the example, the signaling services are ss7srv1 and ss7srv2.

Linkset

The second field lists the MML name for the linkset associated with the SS7 route. In the example, the linksets are linkset1 and linkset 2.

Adjacent Point Code

The APC field lists the MML name for the adjacent point code (APC) associated with the SS7 route. In the example there are APCs:

•apc-1

•apc-2

•apc-3

•apc-4

Originating Point Code

The OPC field lists the MML name for the originating point code (OPC) associated with the SS7 route. In the example there are OPCs:

•opc-1

•opc-2

•opc-3

•opc-4

Priority

The PRIO field lists the priority provisioned for this SS7 route. In the example, all of the SS7 routes have a priority of 1.

Primary Service State

The PST field shows the current primary service state of the destination. In the example, all of the SS7 routes have a primary service state of IS. Table 3-3 lists the valid primary service state values:

Table 3-3 SS7 Route Primary Service States

Link State ID

Link State

Description

AOOS

Automatically out-of-service

The system has taken the SS7 route out-of-service (OOS).

INB

Install busy

When a system is first configured, all signaling links default to this state and must be manually set in-service (IS) through the use of the set-dest MML command.

IS

In-service

The SS7 route is IS and fully operational. This is its normal operating state.

MOOS

Manually out-of-service

The SS7 route has been manually taken OOS.

OOS

Out-of-service

The SS7 route is OOS from the remote end. The system is actively trying to restore the link.

TRNS

Transient

The state of the link to the SS7 route is currently being changed.

UNK

Unknown

The state of the link to the SS7 route is not known.

Secondary Service State

The SST field shows the current secondary service state of the specified destination. In the example, all of the SS7 routes have a primary service state of NA. The valid states are listed below:

•ACKD—SS7 Acknowledgement delay

•BSNR—SS7 backward sequence number received (BSNR)

•CIS—Commanded in service

•CONF—Configuration failure

•COOS—Commanded out of service

•ENGR—Call engine reset

•ISPEND—In service, pending

•LCNG—Congestion, local

•LINE—Line failure

•LINH—SS7 local inhibit

•LINK—Link failure

•LINS—Linkset failure

•NA—Cause not available

•OOSPEND—Out of service, pending

•PRHB—SS7 prohibited

•RBLK—SS7 remote blocked

•RCNG—Congestion, remote

•RINH—SS7 remote inhibit

•RSTR—SS7 restricted

•SERR—SS7 signal error

•STBY—Cause standby

•SUPPENT—Supporting entity

•TPATH—Traffic path

•UNK—Cause unknown

Verifying CIC States

We recommend verifying the status of your circuit identification codes (CICs) in groups, to ensure that you have current state information. Retrieving the status of all of your CICs at once can take a while to obtain, and then a long time to page through.

To verify the status of CICs provisioned on your Cisco PGW 2200 Softswitch in groups, perform the following steps:

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-cic:sig_srv:cic=number[,rng=range]
Where:

•sig_srv—MML name of the signaling service associated with the CICs to be displayed.

•number—A valid CIC number.

•range—Specifies a range of CICs to be retrieved. The status of all CICs between number and number+range are displayed.

For example, the following MML command retrieves bearer channel information for CICs 10 to 15 on signaling service c7s-1:
rtrv-cic:c7s-1:cic=10,rng=5
When the Cisco PGW 2200 Softswitch software is configured for signaling, the system returns a response similar to the following:
   Media Gateway Controller - MGC-04 2000-04-05 08:05:54
M  RTRV
	"c7s-1:CIC=10,PST=IS,CALL=IDLE,BLK=NONE"
	"c7s-1:CIC=11,PST=IS,CALL=IDLE,BLK=NONE"
	"c7s-1:CIC=12,PST=IS,CALL=IDLE,BLK=NONE"
	"c7s-1:CIC=13,PST=IS,CALL=IDLE,BLK=NONE"
	"c7s-1:CIC=14,PST=IS,CALL=IDLE,BLK=NONE"
	"c7s-1:CIC=15,PST=IS,CALL=IDLE,BLK=NONE"
When the Cisco PGW 2200 Softswitch software is configured for call control, the system returns a response similar to the following:
   Media Gateway Controller - MGC-04 2000-04-05 08:05:54
M  RTRV
   "c7s-1:CIC=10,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=11,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=12,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=13,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=14,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=15,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
Step 2 If the primary service state is not IS for any of the CICs, or a CIC is blocked, check your alarms retrieval MML session for bearer-related alarms. The method for setting up an alarms retrieval MML session is described in the "Monitoring the Alarms Status" section.

If a bearer channel-related alarm appears, you can determine the appropriate course of action by searching for the corrective actions for that alarm in the "Alarm Troubleshooting Procedures" section on page 8-4. If the alarm is not in that section, corrective action is not required. More information on the alarm can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

Understanding CIC States

The elements of the output from the rtrv-cic MML command is described in the paragraphs that follow.

Circuit Identification

The output of this command identifies the MML name of the associated signaling channel and the number for each CIC.

Primary Service State

The PST field shows the current primary service state of the CIC. Table 3-4 lists the valid primary service state values:

Table 3-4 CIC Primary Service States

Link State ID

Link State

Description

IS

In-service

The traffic channel or CIC is IS and fully operational. This is its normal operating state.

OOS

Out-of-service

The traffic channel or CIC is OOS from the remote end. The system is actively trying to restore the link. Individual CICs can be OOS even if the destination is IS, due to signaling events such as Q.931 service messages.

Call State

The CALL field identifies the current call state of each CIC. After a call is initiated, a circuit does not return to the Idle (available) state until all related release signaling is satisfactorily completed (the correct release sequence). In and Out call states indicate that the CIC is not available for new calls. Table 3-5 describes the various call states.

Table 3-5 CIC Call States

State

Description

In

Incoming call is in progress. Bearer channel is not available for new call.

Out

Outgoing call is in progress. Bearer channel is not available for new call.

Idle

Circuit is available for use.

Media Gateway State

The GW_STAT field identifies the current state of the media gateway associated with each CIC. Table 3-6 describes the various media gateway states.

Table 3-6 Media Gateway States

State

Description

CARRIER_FAILURE

Individual CIC has failed. If this state is seen for all CICs associated with a T1 or E1, this indicates that the associated T1 or E1 has failed. This is the only media gateway state that is checkpointed to the standby Cisco PGW 2200 Softswitch.

CXN_IS

The connection is in-service on the active Cisco PGW 2200 Softswitch.

CXN_OOS_ACTIVE

The connection is out of service on the active Cisco PGW 2200 Softswitch.

CXN_OOS_STANDBY

The connection is out of service on the standby Cisco PGW 2200 Softswitch.

GW_HELD

The connection is being held at the media gateway. This occurs due to a command timeout or an unexpected response. This state is only applicable to the active Cisco PGW 2200 Softswitch.

Circuit Block Type

The BLK field identifies the type of circuit block that has been placed on the CIC. Blocked circuits are not available for calls. Table 3-7 describes the valid circuit block types.

Table 3-7 Circuit Block Types

Type

Description

COT_FAIL

Blocked because a continuity test failed on the CIC.

GATEWAY

Locally blocked on a switched system due to a media gateway event (for example, a media gateway interface fails causing an RSIP message to be sent, but the associated CICs remain in-service or when an RSIP message is not acted upon due to a mismatch between the MGCP host name in the RSIP string and the host name provisioned in the media gateway). If the associated switch is not responding to group unblock messages, the CICs stay in the GATEWAY circuit block state. Your CICs will be in this state when you bring up the Cisco PGW 2200 Softswitch or media gateway. Once the associated switch acknowledges the unblock message, the CICs are taken out of this state. If the CICs stay in the GATEWAY circuit block state, troubleshoot the problem with the media gateway.

INTERFACE_DISABLED

The interface is disabled because the system received a CGB message or a new service has been started which is still in the install busy (INB) state.

LOCAUTO

Hardware blocking type—the CIC is blocked by an external message generated by a network element outside the media gateway.

LOCMAN

Blocked manually using an MML command, such as blk-cic. This is removable using the unblk-cic or reset-cic MML commands.

LOCUNK

Locally blocked for unknown reasons. This indicates a potential software problem whereby a CIC has become blocked but the software did not track the cause of the blocking.

MATE_UNAVAIL

Locally blocked on a nailed-up system due to a media gateway event (for example, a group service message received from the media gateway or the media gateway is out of service). If the associated switch is not responding to group unblock messages, the CICs stay in the MATE_UNAVAIL circuit block state. Your CICs will be in this state when you bring up the Cisco PGW 2200 Softswitch or media gateway. Once the associated switch acknowledges the unblock message, the CICs are taken out of this state. If the CICs stay in the MATE_UNAVAIL circuit block state, troubleshoot the problem with the media gateway.

NONE

There is no block on the CIC. DS0 is available for use.

REMAUTO

Remotely automatically blocked.

REMMAN

Remotely blocked manually.

Note Block types are additive: for example, LOCMAN (locally, manually blocked) and REMMAN (remotely, manually blocked) can both be active at the same time.

Verifying System Statistics

You should monitor the Cisco PGW 2200 Softswitch system statistics on a daily basis. The system statistics provide you with the following information:

•Platform state

•Number of active alarms

•Current congestion level

•Call success and failure rates

•CPU utilization level

•Amount of available memory

•Disk usage

You can retrieve all of the statistics for your system by entering the following MML command on the active Cisco PGW 2200 Softswitch:
rtrv-ne-health::all
The system returns a message similar to the following:
   MGC-01 - Media Gateway Controller 2008-10-07 03:22:49.444 EDT
M  COMPLD
   "Platform State:ACTIVE"
   "0 critical, 0 major, 0 minor active alarms"
   "Machine Congestion Level = MCL 0 (No Congestion), Reason: not applicable"
   "Current in progress calls = 0, half calls = 0, full calls = 0, call attempts= 0 cps"
   "CPU 0 Utilization = 0 % CPU 1 Utilization = 0 %"
   "Memory (KB): 5131609 Free virtual, 5872025 Total virtual, 2097152 Total real, 0 Total 
Dial Plan"
   "Interval (minutes)           15      60      1440"
   "CALL: SuccCall TOT           0       0       0"
   "CALL: FailCall TOT           0       0       0"
   "CALL: SIPLicRej TOT          0       0       0"
   "CALL: H323LicRej TOT         0       0       0"
   "CALL: TDMLicRej TOT          0       0       0"
   "CALL: TimesTenLicRej TOT     0       0       0"
   "Filesystem            kbytes    used   avail capacity  Mounted on"
   "/dev/md/dsk/d3       1988623  500185 1428780    26%    /"
   "/dev/md/dsk/d12      57440581 9876786 46989390    18%    /opt"
   ;
Note In a particular instance, the number of in-progress calls does not reflect the actual number of active calls. When an E1 link in a PBX comes up, CRMs are sent to the PBX for each channel to ensure that there are no active calls present in the PBX. This is done to ensure that synchronization can be maintained after a link failure on the IP side. These CRMs are treated as active calls, therefore increasing the number of in-progress calls returned by this command.

If over 80 percent of CPU resources are being used over an extended period of time, you should contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

If the response to the command indicates a percentage of disk space capacity used 90 percent or higher, you must delete files from your disk drive, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section on page 8-165.

Verifying the Number of Active Processes

You should check the number of active processes on the Cisco PGW 2200 Softswitch on a daily basis. To do this, log into the active Cisco PGW 2200 Softswitch and use the following UNIX command:
ps -ef
The system returns a response similar to the following:
UID   PID  PPID  C    STIME TTY      TIME CMD
root     0     0  0 10:28:20 ?        0:00 sched
root     1     0  0 10:28:20 ?        0:27 /etc/init -
root     2     0  0 10:28:20 ?        0:00 pageout
root     3     0  0 10:28:20 ?        1:01 fsflush
root   174   173  0 10:29:03 ?        0:00 /usr/sbin/ntpdate -s -w 172.24.239.41
root   148     1  0 10:28:48 ?        0:00 /usr/lib/nfs/lockd
root   617     1  0 10:29:23 console  0:00 /usr/lib/saf/ttymon -g -h -p va-hoover console 
login:  -T sun -d /dev/console -
root   237     1  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestend
root   116     1  0 10:28:36 ?        0:00 /usr/sbin/keyserv
root   114     1  0 10:28:36 ?        0:00 /usr/sbin/rpcbind
root   616     1  0 10:29:23 ?        0:00 /usr/lib/saf/sac -t 300
root   141     1  0 10:28:47 ?        0:00 /usr/sbin/inetd -s
daemon   146     1  0 10:28:48 ?        0:00 /usr/lib/nfs/statd
root   165     1  0 10:29:02 ?        0:11 /usr/lib/autofs/automountd
root   317     1  0 10:29:13 ?        0:00 /usr/sbin/rpc.bootparamd
root   169     1  0 10:29:02 ?        0:00 /usr/sbin/syslogd
root   173     1  0 10:29:02 ?        0:00 /sbin/sh /etc/rc2.d/S74xntpd start
root  2867   141  0 10:05:23 ?        0:00 in.telnetd
root   182     1  0 10:29:03 ?        0:00 /usr/sbin/cron
root   198     1  0 10:29:03 ?        0:00 /usr/lib/lpsched
root   227     1  0 10:29:05 ?        0:00 /usr/lib/utmpd
root   217     1  0 10:29:04 ?        0:00 /usr/lib/power/powerd
root   618     1  0 10:29:23 ?        0:00 /opt/CiscoMGC/bin/critagt -d
root   235     1  0 10:29:05 ?        0:00 /usr/lib/sendmail -bd -q15m
root   238   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 0
root   239   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 1
root   240   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 2
root   241   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 3
root   242   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 4
root   243   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 5
root   244   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 6
root   245   237  0 10:29:06 ?        0:00 /opt/TimesTen32/32/bin/timestensubd -id 7
root   290     1  0 10:29:12 ?        0:00 /usr/sbin/vold
root   620   616  0 10:29:23 ?        0:00 /usr/lib/saf/ttymon
root   315     1  0 10:29:13 ?        0:01 /usr/sbin/in.rarpd -a
root   621   618  0 10:29:23 ?        0:05 /opt/CiscoMGC/bin/snmpdm -tcplocal -d
root   622   618  0 10:29:24 ?        0:00 /opt/CiscoMGC/bin/mib2agt -d
mgcusr   610     1  0 10:29:18 ?        0:02 procM
root   623   618  0 10:29:24 ?        0:00 /opt/CiscoMGC/bin/hostagt
root   624   618  0 10:29:24 ?        0:01 /opt/CiscoMGC/bin/fsagt
mgcusr   774   610  0 10:31:18 ?        0:17 ../bin/mmdbd -X 30007
mgcusr   626   610  0 10:29:24 ?        0:19 ../bin/LogServerd -X 30013
root   627   610  0 10:29:24 ?        0:05 ../bin/almM -X 30002
mgcusr   669   610  0 10:29:24 ?        0:08 ../bin/cdrDmpr -X 30005
mgcusr   637   610  0 10:29:24 ?        6:11 ../bin/amDmpr -X 30004
mgcusr   681   610  0 10:29:25 ?        0:11 ../bin/pom -X 30008
mgcusr   690   610  0 10:29:42 ?        0:02 ../bin/replicator -X 3000d -C ../ 
etc/XECfgParm.dat -t
mgcusr   670   610  0 10:29:24 ?        0:01 ../bin/cfgM -X 30001
mgcusr   673   610  0 10:29:25 ?        0:43 ../bin/measMgr -X 30003
mgcusr   689   610  0 10:29:42 ?        1:29 ../bin/engine -X 3000e
mgcusr   776   610  0 10:31:19 ?        0:01 ../bin/TCAP -X 30010
root   691   610  0 10:29:42 ?        0:01 ../bin/mmSAgt -X 30009
root   692   610  0 10:29:43 ?        0:04 ../bin/sagt -X 3000a
root   693   610  0 10:29:43 ?        0:01 ../bin/provSAgt -X 3000b
root   775   610  1 10:31:18 ?       37:37 ../bin/ioChanMgr -X 3000f
mgcusr   777   610  0 10:31:23 ?        0:12 ../bin/MGCP -X 30016
mgcusr   778   610  0 10:31:23 ?        0:27 ../bin/ISDNL3 -X 3000c
mgcusr   779   610  0 10:31:23 ?        0:26 ../bin/ISDNL3 -X 30011
mgcusr   780   610  0 10:31:23 ?        0:30 ../bin/ISDNL3 -X 30014
mgcusr   781   610  0 10:31:23 ?        0:01 ../bin/ISDNL3 -X 30015
mgcusr   782   610  0 10:31:23 ?        0:42 ../bin/SS7 -X 30017
root   783   610  0 10:31:23 ?        0:05 ../bin/foverd -X 30012
mgcusr2 5458  5456  0 11:07:28 pts/0    0:00 -tcsh
root  5456   141  0 11:07:28 ?        0:00 in.rlogind
root   367     1  0 14:21:02 ?        0:00 /usr/sbin/nscd
mgcusr  2869  2867  0 10:05:23 pts/1    0:00 -csh
root  3101  2869  0 10:06:49 pts/1    0:00 ps -ef
The response should indicate that there are between 60 and 100 processes active. If the response indicates that there are more than 100 active processes, you should contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

Verifying the Number of Users

You should check the number of users on the Cisco PGW 2200 Softswitch on a daily basis. To do this, log into the active Cisco PGW 2200 Softswitch and enter the following UNIX command:
who
The system returns a response similar to the following:
mgcusr pts/0        May 29 11:07    (mgcusr-u5.somecompany.com)
mgcusr2 pts/1        May 30 10:05    (mgcusr2-u6.somecompany.com)
Only known login IDs should be listed in the response. If the response indicates that there are unknown login IDs, or login sessions that have lasted a very long time, you should contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

Verifying Available Virtual Memory

The operating system used on the Cisco PGW 2200 Softswitch, Solaris (Version 8 or 10), is a virtual memory system. A virtual memory system adds to the available memory by writing the contents of an unused block of memory to the disk drive, enabling that block of memory to be used for another purpose. The space on the disk drive dedicated to this function is known as the swap space. Once the data in that block of memory is needed again, the system reads the stored block from the swap space back into memory.

In a typical Cisco PGW 2200 Softswitch installation, the tmp directory (/tmp) is a temporary file system mount that coexists in the same physical disk partition as the swap space. The tmp directory is used to run a number of special files, such as FIFOs, that are required for the system to run properly. As the amount of space allocated to the tmp directory increases, the amount of space available for running Cisco PGW 2200 Softswitch processes decreases, which can cause functional problems. You need to ensure that the amount of space consumed by the tmp directory is kept to a minimum.

Caution Do not copy other files into the /tmp directory, such as patches or other software. Use of this directory for temporary storage or for downloading can cause functional problems with the Cisco PGW 2200 Softswitch software.

To determine the amount of available virtual memory, you must compare the amount of virtual memory in use to the maximum amount of virtual memory for your system. To do this, perform the following steps:

Note Be aware that the time of day at which you enter these commands effects the overall accuracy of the response. If you enter these commands during your busiest hours, the amount of available virtual memory could be quite small, but this may not indicate a need to contact the Cisco TAC.

If this is the case, consider also performing this procedure during a less active call processing time, to determine an average amount of available virtual memory.

Step 1 The maximum amount of virtual memory is the sum of the physical memory and the size of the swap space. To determine the amount of physical memory on your system, log in to the active Cisco PGW 2200 Softswitch and enter the following UNIX commands:
cd /usr/sbin
prtconf | grep Memory
The system returns a response similar to the following:
Memory size: 2048 Megabytes
Step 2 To determine the size of the swap space on the disk drive, enter the following UNIX command:
swap -s
The system returns a response similar to the following:
total: 235272k bytes allocated + 65912k reserved = 301184k used, 5471344k available
Step 3 Add the amount of physical memory to the amount of swap space. This value is the maximum virtual memory for your system.

Step 4 To determine the amount of available virtual memory, enter the following UNIX command:
vmstat 
The system returns a response similar to the following:
kthr       memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr m1 m2 m3 m4 in   sy  cs us sy id
 0 0 0 5509624 1365192 0 0  0  0  0  0  0  0  0  0  0  405 252  318 0 0  100
The amount of swap and free memory listed in the response (5509624 and 1365192 in the above example) represents the total amount of available virtual memory. This amount should always be greater than 10 percent of the maximum virtual memory. If this is not the case, proceed to Step 5.

Note You also can use this command to check the available virtual memory repeatedly. Enter it in the format vmstat n, where n is the number of seconds between checks. See the man pages on the vmstat command for more information.

When the vmstat command is used to check the available virtual memory repeatedly, you should ignore the first line of output.

Step 5 Collect system data as described in the "Collecting System Data for Cisco TAC" section on page 8-87 and contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xx.

Verifying Available Memory on the Cisco ITP-Ls

You should check the amount of available memory on your Cisco IP Transfer Point LinkExtenders (ITP-Ls) on a daily basis. To do this, perform the following steps:

Step 1 Log in to a Cisco ITP-L, and enter the following IOS command to check the amount of available memory:
show mem
The system returns a response similar to the following:
                Head    Total(b)     Used(b)     Free(b)   Lowest(b) Largest(b)
Processor   80CF71E0    16813600     7885028     8928572     8900652 8891892
      I/O    1D00000    19922944     6975904    12947040    12938256 12937500
Ensure that the memory used is less than 90 percent of the total available memory. If this is the case, the procedure is complete. If the response indicates that the Cisco ITP-L has a small amount of available memory, you may need to add additional memory to the Cisco ITP-L to handle your system's call processing load.

Note Be aware that the time of day at which you enter this command will have an effect on the overall accuracy of the response. If you enter this command during your busiest hours, the amount of available memory could be quite small, but this may not indicate a need to add additional memory.

If this is the case, consider also performing this procedure during a less active call processing time, to determine an average amount of available memory.

Step 2 See the "Upgrading DRAM" section on page 6-17 for more information on how to add additional memory to a Cisco ITP-L.

Periodic Maintenance Procedures

This section contains procedures that are either performed on automatically, on a scheduled basis, by the system or should be performed by you on a regular basis to keep the Cisco PGW 2200 Softswitch platform operating smoothly. You should schedule the procedures that are performed manually as you see fit. These maintenance procedures include

•Automatic Disk Space Monitoring

•Automatic System Log Rotation

•Rotating System Logs Manually

•Creating a Disaster Recovery Plan

•Backing Up System Software

•Processing a Core Dump File

Note This section does not include information on maintaining the Sun host server hardware. You should routinely perform general maintenance tasks and diagnostic checks on the host hardware. See the documentation provided by Sun Microsystems, the hardware manufacturer, for detailed information on these types of procedures.

Automatic Disk Space Monitoring

The Cisco PGW 2200 Softswitch software includes a script called disk monitor (diskmonitor.sh) that periodically checks the amount of disk space used within the configurable set of disk partitions. Disk monitor ensures that there is sufficient disk space available in each disk partition for the system to continue to operate at peak performance. To do this, disk monitor deletes (trims) the older log files in the /opt/CiscoMGC/var/log and /opt/CiscoMGC/var/spool directories until the disk space usage is within the specified threshold (set using the XECfgParm.dat parameter, diskmonitor.Threshold).

The disk monitor can also track the number of configurations stored in the configuration library (which is found in the /opt/CiscoMGC/etc/CONFIB_LIB directory) and trim the older configurations when the number of configurations exceeds the maximum value you have set in the associated XECfgpParm.dat disk monitor parameter. The process manager runs the disk monitor script once every minute.

In prior releases, it was recommended that the user ensure that there were never more than 64 configurations stored in the configuration library. This recommendation was made to ensure the proper functioning of switchovers and the prov-sync MML command. In instances where the system was storing more than 64 configurations, switchovers and the prov-sync command would time out and fail as the standby Cisco PGW 2200 Softswitch attempts to copy over all of the configurations stored on the active Cisco PGW 2200 Softswitch.

Now the process of administering the configuration library is handled automatically by the Cisco PGW 2200 Softswitch software. The user sets the disk monitor parameter to establish the maximum number of configurations allowed in the configuration library, and the system will trim the older configurations as necessary.

Disk monitor is controlled using the following parameters in the XECfgParms.dat file:

•diskmonitor.Limit—Specifies the number of days to preserve data before trimming is initiated. The default value is 7.

•diskmonitor.OptFileSys—Allows for optional user-configurable file systems to be monitored. This utility monitors the /opt file system for threshold crossing. Using this parameter, you can monitor additional file systems (disk slices) by setting parameter to the preferred directory, such as /tmp, /usr or /var. The messages associated with this parameter are sent to the platform.log file. To retrieve these messages, you must scan the platform.log file for messages using the following format: Filesystem file_system_name has exceeded num percent full. For example:
Filesystem /var has exceeded 80 percent full
Note The files in these file systems are not trimmed by disk monitor.

•diskmonitor.Threshold—Specifies the percentage of disk usage at which alarming and disk trimming is initiated. The default value is 80.

•diskmonitor.CdrRmFinished—Specifies how many days to keep finished (polled) call detail record (CDR) files. The default value is 0, which means that if the Cisco BAMS is polling the Cisco PGW 2200 Softswitch, CDR.bin files remain in a user-configurable directory until they are renamed by the Cisco BAMS (using the format CDR_timestamp.finished) and/or the disk monitor trims the file from user-configurable directory.

•diskmonitor.SoftLimit—Specifies the action to be taken once the number of days threshold set in the diskmonitor.Limit parameter is reached. If this parameter is set to true, disk monitor decrements the value in the diskmonitor.Limit parameter one day at a time (that is, from 7 down to 6, and then down to 5, and so on) until the utilization level drops below the threshold. If this parameter is set to false, disk monitor closes and the system generates a DISK alarm. The files can then be deleted manually. The default value is false.

•diskmonitor.CoreRmDays—Specifies how many days to keep core dump files. The default value is 1, which means that core dump files are kept for one day before disk monitor removes them automatically.

•diskmonitor.CfgRmDirs—This parameter specifies the maximum number of configurations that can be stored in the configuration library. The valid values are the range of integers from 3 through 64. The default value is 64. Entering a value outside of the range of valid values disables monitoring of the number of entries stored in the configuration library. If you want to change the value of this parameter, you may need to add it manually to the XECfgParm.dat file.

Disk monitor performs the following steps in its inspection of disk utilization levels:

1. Verify that the standard and optional partitions, as defined in diskmonitor.OptFileSys, are not over the thresholds for disk utilization or the configuration library, as defined in diskmonitor.Threshold and diskmonitor.CfgRmDirs, respectively.

a. If neither threshold is exceeded, disk monitor exits.

b. If the disk utilization threshold is exceeded, disk monitor attempts to trim the files based on the number of days, as defined in diskmonitor.Limit.

c. If the configuration library threshold is exceeded, disk monitor trims the number of configuration files to match the setting in the diskmonitor.CfgRmDirs parameter, starting with the oldest.

2. Once files are trimmed, disk monitor verifies again that the standard and optional partitions are not over the thresholds for disk utilization and the configuration library.

a. If neither threshold is exceeded, disk monitor exits.

b. If the disk utilization threshold is exceeded, and diskmonitor.SoftLimit is set to false, the disk monitor is exited and a DISK alarm is raised.

c. If the disk utilization threshold is exceeded, and diskmonitor.SoftLimit is set to true, disk monitor begins decreasing the number of days that logs can be stored (the value defined in diskmonitor.Limit), stopping as soon as the disk is under the disk utilization threshold.

d. If the configuration library threshold is exceeded, disk monitor trims the number of configuration files to match the setting in the diskmonitor.CfgRmDirs parameter, starting with the oldest.

If any disk partition exceeds the configurable usage threshold, the Cisco PGW 2200 Softswitch generates a DISK alarm (a major alarm), a warning of a disk partition overrun, and a warning of insufficient disk space. See the "DISK" section on page 8-37 for information about the corrective actions required to resolve a DISK alarm.

Some other files, such as call trace files, take up large amounts of disk space and are not trimmed by disk monitor. You may have to periodically delete call trace files. Call trace files are created when you perform call traces as part of troubleshooting a problem. These files can be rather large, and leaving them on your disk could cause problems. For more information about deleting call trace files, see the "Deleting Unnecessary Files to Increase Available Disk Space" section on page 8-165.

Configuring Disk Monitor

Configuration of the disk monitor can only be done while the Cisco PGW 2200 Softswitch software is turned off. For this reason, disk monitor is typically configured only during the initial installation. For more information on configuring the disk monitor during initial installation, see the XECfgParms.dat section of the Cisco PGW 2200 Softswitch Release 9.8 Software Installation and Configuration Guide.

You can perform the configuration after initial installation. To do this, perform the following steps:

Caution Performing the following procedure requires that the Cisco PGW 2200 Softswitch software be turned off. Do not attempt the following procedure without the guidance of the Cisco TAC. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

If your system uses a single Cisco PGW 2200 Softswitch in a simplex configuration, performing this procedure causes you to drop all calls.

Step 1 Determine whether any alarms are pending on the active Cisco PGW 2200 Softswitch, as described in the "Retrieving All Active Alarms" section on page 8-3.

If any alarms are pending, you can determine the appropriate courses of action by searching for the corrective actions for those alarms in the "Alarm Troubleshooting Procedures" section on page 8-4. If the alarms are not in that section, corrective action is not required. More information on those alarms can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

Step 2 Repeat Step 1 for the standby Cisco PGW 2200 Softswitch.

Step 3 Modify the disk monitor parameters in the XECfgParm.dat files, which are listed below, on each host, using the procedure described in the "Rebooting Software to Modify Configuration Parameters" section on page 8-178.

•diskmonitor.Limit parameter—Sets the number of days to preserve logged data before trimming is initiated. The default value is 7.

•diskmonitor.OptFileSys—Allows for optional user-configurable file systems to be monitored. This utility monitors the /opt file system for threshold crossing. Using this parameter, you can monitor additional file systems (disk slices) by setting parameter to the preferred directory, such as /tmp, /usr or /var. The messages associated with this parameter are sent to the platform.log file. To retrieve these messages, you must scan the platform.log file for messages using the following format: Filesystem file_system_name has exceeded num percent full. For example:
Filesystem /var has exceeded 80 percent full
Note The files in these file systems are not trimmed by disk monitor.

•diskmonitor.Threshold—Sets the percentage of disk usage at which alarming and disk trimming is initiated. The default value is 80.

•diskmonitor.CdrRmFinished—Sets the number of days that finished CDR files are kept in the log directory. The default value is 0, which means that if the Cisco BAMS is polling the Cisco PGW 2200 Softswitch, CDR.bin files remain in a user-configurable directory until they are renamed by the Cisco BAMS (using the format CDR_timestamp.finished) and/or the disk monitor trims the file from user-configurable directory.

•diskmonitor.SoftLimit—Determines what action is taken once the number of days threshold set in the diskmonitor.Limit parameter is reached. If this parameter is set to true, disk monitor decrements the value in the diskmonitor.Limit parameter one day at a time (that is, from 7 down to 6 then down to 5 and so on), until the utilization level drops below the threshold. If this parameter is set to false, disk monitor exits and the system generates a DISK alarm. The default value is false.

•diskmonitor.CoreRmDays—Sets the number of that core dump files are kept in the log directory. The default value is 1, which means that core dump files are kept for one day before disk monitor removes them automatically.

•diskmonitor.CfgRmDirs—Sets the maximum number of configurations that can be stored in the configuration library. The valid values are the range of integers from 3 through 64. The default value is 64. This parameter is not present in the XECfgParm.dat file initially. If you want to modify the value, you must enter the parameter manually into the file.

Caution The Cisco PGW 2200 Softswitch software is case-sensitive. Ensure that you enter the parameter name correctly, or the maximum number of configurations will not be modified.

Note We recommend that you keep the latest configurations, store older configurations on system backups, and delete those older configurations from the library. For information on deleting configurations from the library, see the procedure in the "Using the Config-Lib Viewer" section.

Note If you want to ensure the proper functioning of the prov-sync MML command, set the diskmonitor.CfgRmDirs parameter to a value between 50 and 60. Entering a value outside of the range of valid values (3 through 64) disables monitoring of the number of entries stored in the configuration library.

Automatic System Log Rotation

As the system operates, the Cisco PGW 2200 Softswitch software creates the system logs that are stored in a file stored in the /opt/CiscoMGC/var/log directory. The name of the system log file is set by the XECfgParm.dat file parameter, logFileNamePrefix (the default value is platform). The Cisco PGW 2200 Softswitch software stops writing to the current system log file, archives the contents of that file, and commences writing to a new system log file. This process is referred to as log rotation.

Log rotation occurs as a result of one of the following conditions:

•Cisco PGW 2200 Softswitch software startup (the log rotation script is run)

•Log rotation script (log_rotate.sh) is run manually

•The size of the active system log file has exceeded the value set in the XECfgParm.dat parameter, fileRotateSize.

•The time elapsed since the last log rotation has exceeded the value set in the XECfgParm.dat parameter, fileRotateInterval.

When the system rotates the system log file, the current system log file is archived and a new system log file is opened. The archived log file is stored in the /opt/CiscoMGC/var/spool directory. Once the
Cisco PGW 2200 Softswitch software is up and running, the log server takes over the actual file rotation responsibility of renaming the active file to a historical file with a new file name with the following format: logFileNamePrefix_yyyymmddhhmmss.log, where the time stamp indicates the system date/time at the time of log rotation.

Rotating System Logs Manually

You can also run the log rotation script manually to force the current system log file to be archived. To do this, log into the active Cisco PGW 2200 Softswitch as root, and enter the following UNIX command:
/opt/CiscoMGC/bin/log_rotate.sh
The system creates a new current system log file and archived log file, as described in the "Automatic System Log Rotation" section.

Creating a Disaster Recovery Plan

You should formulate a disaster recovery plan for your Cisco PGW 2200 Softswitch platform to ensure that your system can be restored to service quickly after it has been taken out-of-service by a natural or man-made disaster. A key element in your disaster recovery plan should be ensuring that regular backups of your system's software are performed. See the "Backing Up System Software" section for more information about backup operations. We also recommend that the backup data for your system be stored in a secure location, in a site separate from the equipment, to ensure that they are not affected by the same disaster.

For information on performing a disaster recovery, see the "Recovering from Cisco PGW 2200 Softswitch(es) Failure" section on page 8-167.

Backing Up System Software

You should perform regularly scheduled system software backups on both the active and standby Cisco PGW 2200 Softswitches to protect critical system data such as configuration files, which are irreplaceable if lost. If a catastrophic failure occurs, it is much easier to restore system information from backup data than to recreate it. Furthermore, such a failure could cause critical configuration information to be lost if it has not been backed up. We recommend that you create a backup schedule, ensuring that small or incremental backups are performed daily, and a large or full backup once a week.

Note We recommend that you back up your system software during periods of low call volume to minimize the effect of the backup on your call processing.

The backup method available for the Cisco PGW 2200 Softswitch software is described in the following sections:

•Backup Procedures for Cisco PGW 2200 Softswitch Software

Backup Procedures for Cisco PGW 2200 Softswitch Software

This backup method uses a script to backup the configuration data for the Cisco PGW 2200 Softswitch software, select UNIX administrative files, and the Main Memory Database (MMDB). This script only performs full backups. This script enables you to perform manual backups, schedule and administer automatic backups, and view a history of the last 30 backup operations performed.

Note If your Cisco PGW 2200 Softswitch is a continuous service system, ensure that you perform backup procedures on both Cisco PGW 2200 Softswitches.

Note The various backup operations described in the following sections can only be run when you are logged in to your system as mgcusr. You cannot perform any backup operation while you are logged in as root.

Note The procedures for restoring system data can be found in the "Restoring Procedures for Cisco PGW 2200 Softswitch Software" section on page 8-173.

The following sections provide the backup procedures:

•Performing a Manual Backup Operation

•Scheduling an Automatic Backup Operation

•Listing Scheduled Automatic Backup Operations

•Removing an Automatic Backup Operation from the Schedule

•Listing the Backup Operation History

•Performing a License Backup Operation (Release 9.7(3))

Performing a Manual Backup Operation

To perform a manual backup operation, enter the following UNIX command on the Cisco PGW 2200 Softswitch:
mgcbackup -d path [-r retries -t retry_time]
Where:

•path—The full path of the directory in which to store the backup file, for example a directory on a remote server that you have mounted on your system, or the local tape drive (the local tape drive is the default location).

Note We recommend that you do not store backup files on your local Cisco PGW 2200 Softswitch, as storage of backup files on the local host reduces the amount of disk space available to process call data, and does not ensure that the data is safe in the event of a natural disaster.

Note If the path you enter is for a tape device, be aware that a new tape must be entered into the device for each backup. The backup data on a used tape will be overwritten by this operation.

•retries—The number of times to check for an active provisioning session on the Cisco PGW 2200 Softswitch, before aborting the backup operation. The default value is 0, and the maximum value is 100.

Note A backup operation cannot start while there is an active provisioning session on the Cisco PGW 2200 Softswitch.

•retry_time—The number of seconds to wait between checks for an active provisioning session on the Cisco PGW 2200 Softswitch. The default value is 30 seconds, and the maximum value is 3600 seconds.

For example, to perform a manual backup operation where the backup file is saved to a directory path called /dev/rmt/h0, with a maximum of three attempts, each 60 seconds apart, you would enter the following UNIX command:
mgcbackup -d /dev/rmt/h0 -r 3 -t 60
Note You can enter a Ctrl-C keyboard command at any time to halt the execution of the mgcbackup script.

The backup file is stored in the specified directory path in the following format:
mgc_hostname_yyyymmdd_hhmmss_backup
Where:

•hostname—The name of the Cisco PGW 2200 Softswitch, such as MGC-01.

•yyyymmdd—The date the backup file is created, in a year-month-day format, such as 20011130.

•hhmmss—The time the backup file is created, in an hour-minute-second format, such as 115923.

Scheduling an Automatic Backup Operation

To schedule an automatic backup operation, perform the following steps:

Note You can schedule an automatic backup operation only when you are logged in to your system as mgcusr. You cannot schedule an automatic backup operation while you are logged in as root.

Step 1 Enter the following UNIX command on the Cisco PGW 2200 Softswitch:
mgcbackup -s
The system returns a response similar to the following:
Backup Schedule Menu
--------------------
1. Add a scheduled backup
2. Delete a scheduled backup
3. Delete all scheduled backups
4. List scheduled backups
5. Exit
Selection: 
Note To exit the script at anytime, use Ctrl-C.

Step 2 Enter 1 to add an automatic backup operation to the schedule.

The system returns a response similar to the following:
Add a Scheduled Backup
----------------------
Enter the name of the backup: 
Step 3 Enter the name of your backup.

Note The name of the backup can only be between 1 and 10 alphanumeric characters in length.

After you enter the name of your automatic backup, the system returns a response similar to the following:
Enter the directory to place the backup file (default=/dev/rmt/0): 
Step 4 Enter the directory path where you want the backup file stored.

Note Your local tape drive is the default directory.

Note We recommend that you do not store backup files on your local Cisco PGW 2200 Softswitch, as storage of backup files on the local host reduces the amount of available disk space to process call data, and does not ensure that the data is safe in the event of a natural disaster.

Note If the path you enter is for a tape device, be aware that a new tape must be entered into the device for each backup. The backup data on a used tape will be overwritten by this operation.

After you enter your directory path, the system returns a response similar to the following:
Enter the number of retries (default=0):
Step 5 Enter the number of times to check for an active provisioning session on the Cisco PGW 2200 Softswitch before aborting the backup operation.

Note A backup operation cannot start while a provisioning session is active on the Cisco PGW 2200 Softswitch.

Note The maximum number of retries is 100.

After you enter the number of retries, the system returns a response similar to the following:
Enter the time between retries (default=30 seconds): 
Step 6 Enter the number of seconds to wait between checks for an active provisioning session on the Cisco PGW 2200 Softswitch.

Note The maximum number of seconds between checks is 3600.

After you enter the time between attempts, the system returns a response similar to the following:
Enter the day of the week (default=everyday): 
Step 7 Enter the day(s) of the week that you would like the backup operation performed. The following values are valid:

•SUNDAY

•MONDAY

•TUESDAY

•WEDNESDAY

•THURSDAY

•FRIDAY

•SATURDAY

•WEEKDAYS

•WEEKENDS

•EVERYDAY

After you enter your day(s) of the week setting, the system returns a response similar to the following:
Enter the time (HH:MM):
Step 8 Enter the time to start your automatic backup operation, in hour:minute format.

Note The range for hour is 00-23, and the range for minute is 00-59.

Note We recommend that you schedule your automatic backup operation for a time when your system is likely to have a minimum amount of call volume to minimize the effect of the backup on your call processing.

After you enter your time setting, the system returns a response similar to the following:
Save this scheduled backup (Y or N)?
Step 9 Enter Y if you want to add this automatic backup operation, or enter N if you do not want to add an automatic backup operation.

Note You can enter a Ctrl-C keyboard command at any time to halt the execution of the mgcbackup script.

The system returns a response similar to the following:
Press enter to continue: 
Step 10 Press enter to return to the backup schedule menu. You can either exit the utility or perform another backup scheduling activity.

When the automatic backup operation is performed, the backup file is stored in the specified directory path in the following format:
mgc_hostname_yyyymmdd_hhmmss_backup
Where:

•hostname—The name of the Cisco PGW 2200 Softswitch, such as MGC-01.

•yyyymmdd—The date the backup file is created, in a year-month-day format, such as 20011130.

•hhmmss—The time the backup file is created, in a hour-minute-second format, such as 115923.

Removing an Automatic Backup Operation from the Schedule

To remove an automatic backup operation from the schedule, perform the following steps:

Step 1 Enter the following UNIX command on the Cisco PGW 2200 Softswitch:
mgcbackup -s
The system returns a response similar to the following:
Backup Schedule Menu
--------------------
1. Add a scheduled backup
2. Delete a scheduled backup
3. Delete all scheduled backups
4. List scheduled backups
5. Exit
Selection: 
Step 2 Enter 2 to remove an automatic backup operation from the schedule.

The system returns a response similar to the following:
Delete a Scheduled Backup
-------------------------
Name	Retries	Timeout	Day	Time	Directory
Back1	5	60	everyday	12:00	/var/cisco
Mybackup	0	30	weekdays	04:00	/var/cisco
Enter the name of the backup to be deleted: 
Step 3 Enter the name of the automatic backup operation you want to remove from the schedule.

The system returns a response similar to the following:
Delete this scheduled backup (Y or N)?
Step 4 Enter Y if you want to continue with deleting an automatic backup operation, or enter N if you do not want to delete an automatic backup operation.

Note You can enter a Ctrl-C keyboard command at any time to halt the execution of the mgcbackup script.

The system returns a response similar to the following:
Scheduled backup name deleted.
Press enter to continue: 
Where name is the name of the deleted scheduled backup, as specified in Step 3.

Step 5 Press enter to return to the backup schedule menu. You can either exit the utility or perform another backup scheduling activity.

Removing all Automatic Backup Operations from the Schedule

To remove all of the automatic backup operations from the schedule, perform the following steps:

Step 1 Enter the following UNIX command on the Cisco PGW 2200 Softswitch:
mgcbackup -s
The system returns a response similar to the following:
Backup Schedule Menu
--------------------
1. Add a scheduled backup
2. Delete a scheduled backup
3. Delete all scheduled backups
4. List scheduled backups
5. Exit
Selection: 
Step 2 Enter 3 to remove all automatic backup operations from the schedule.

The system returns a response similar to the following:
Delete all Scheduled Backups
-----------------------------
Name	Retries	Timeout	Day	Time	Directory
Back1	5	60	everyday	12:00	/var/cisco
Mybackup	0	30	weekdays	04:00	/var/cisco
Delete all scheduled backups (Y or N)?
Step 3 Enter Y if you want to continue with deleting all automatic backup operations, or enter N if you do not want to delete all automatic backup operations.

Note You can enter a Ctrl-C keyboard command at any time to halt the execution of the mgcbackup script.

The system returns a response similar to the following:
All scheduled backups deleted.
Press enter to continue: 
Where name is the name of the deleted scheduled backup, as specified in Step 3.

Step 4 Press enter to return to the backup schedule menu. You can either exit the utility or perform another backup scheduling activity.

Listing Scheduled Automatic Backup Operations

To list the scheduled automatic backup operations, perform the following steps:

Step 1 Enter the following UNIX command on the Cisco PGW 2200 Softswitch:
mgcbackup -s
The system returns a response similar to the following:
Backup Schedule Menu
--------------------
1. Add a scheduled backup
2. Delete a scheduled backup
3. Delete all scheduled backups
4. List scheduled backups
5. Exit
Selection: 
Step 2 Enter 4 to list the scheduled automatic backup operations.

The system returns a response similar to the following:
Scheduled Backups
-----------------
Name	Retries	Timeout	Day	Time	Directory
Back1	5	60	everyday	12:00	/var/cisco
Mybackup	0	30	weekdays	04:00	/var/cisco
Press enter to continue: 
Step 3 Press enter to return to the backup schedule menu. You can either exit the utility or perform another backup scheduling activity.

Listing the Backup Operation History

To see a history of the last 30 backup operations, perform the following steps:

Step 1 Enter the following UNIX command on the Cisco PGW 2200 Softswitch:
mgcbackup -l
The system returns a response similar to the following:
Status		File   			    
Success		/var/Cisco/mgc_venus_20011010_153003_backup
Success		/var/Cisco/mgc_venus_20011011_153003_backup
Success		/var/Cisco/mgc_venus_20011012_153003_backup
Press enter to continue: 
Note If a backup operation fails, the reason for the failure is listed below the file name.

Step 2 Press enter to return to the backup schedule menu. You can either exit the utility or perform another backup scheduling activity.

Performing a License Backup Operation (Release 9.7(3))

On Cisco PGW 2200 Softswitch Release 9.7(3), you must perform a license backup operation in order to back up the software license.

Note You receive Cisco PGW 2200 Softswitch license files by e-mails. If you have already performed the license backup, ignore this operation.

To do a license backup on the Cisco PGW 2200 Softswitch, you must copy all the files under /opt/CiscoMGC/license to a safe place. To restore the license files on the Cisco PGW 2200 Softswitch, you need copy these saved license files back to /opt/CiscoMGC/license folder.

Note If you want to install the Cisco PGW 2200 Softswitch software on a new machine, you must contact Cisco TAC for another license file.

Processing a Core Dump File

If a system crash should occur on your Cisco PGW 2200 Softswitch, the system might generate core dump file(s), which are stored in the $BASEDIR/var directory. You can use the core dump files as part of the diagnosis process, to determine what caused the system to crash. The system periodically searches the $BASEDIR/var directory for core dump files.

When the system identifies a core dump file, it performs the following steps:

•Determines which executable dumped the core.

•Finds the current time of the system.

•Renames the core dump file, inserting the executable that dumped the core and the date and time that the file was identified, using the following format:

core.execname_yyyymmddhhmms

For example, if the failover daemon process dumped the core on August 17, 2001 at 12:29:37, the core dump file is named as follows:

core.foverd_20010817122937

•Raises a crash information collected alarm.

Note All of the processing of the core dump file(s) is performed by the process manager, after the process manager receives a signal from a failed child process. If the process manager should cause the core to be dumped, the steps listed above are not performed.

Regular Operations

This section contains procedures that you can perform on your Cisco PGW 2200 Softswitch as needed. The regular operations are described in the following sections:

•Managing MML Sessions

•Managing Signaling Channels

•Managing Bearer Channels

•Managing SIP Communications

•Provisioning your Cisco PGW 2200 Softswitch

•Managing your Cisco PGW 2200 Softswitch Platform

•Managing System Measurements

•Managing Call Detail Records

•Using the Cisco MGC Viewer Toolkit

Managing MML Sessions

The operations you can use to manage an MML session are described in the following sections:

•Displaying Previously Entered MML Commands

•Displaying Information About MML Commands

•Reentering Previously Entered MML Commands

•Retrieving Active MML Sessions

•Ending an MML Session

Displaying Previously Entered MML Commands

You can use the h MML command to redisplay an MML command or a series of MML commands, depending on the number or range that you enter. If you do not enter a number or range, the last MML command entered is displayed.

To redisplay the last MML command entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
h
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  RTRV
   "RTRV-TC:ALL"
   /* command 1 */
To redisplay a particular MML command that you entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
h::number
Where number is the number of the MML command you want to display. The last MML command you entered is equal to 1, the command you entered before that would be equal to 2, and so on.

For example, to redisplay the tenth most recently entered MML command, you would enter the following command:
h::10
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  RTRV
   "RTRV-C7LNK:ALL"
   /* command 10 */
To redisplay a range of MML command that you entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
h::start_num,end_num
Where:

•start_num—The number of the first MML command you want to display. The last MML command you entered is equal to 1, the command you entered before that would be equal to 2, and so on.

•end_num—The number of the last MML command you want to display.

For example, to redisplay all of the commands from the second to the fifth most recently entered MML commands, you would enter the following command:
h::2,5
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  RTRV
   "RTRV-C7LNK:ALL"
   /* command 5 */
   "RTRV-SOFTW:ALL"
   /* command 4 */
   "RTRV-TC:ALL"
   /* command 3 */
   "STP-AUD"
   /* command 2 */
Displaying Information About MML Commands

You can use the help MML command to display information on all MML commands or detailed information on individual commands. To display information on a specific MML command, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
help:command_name
Where command_name is the name of the MML command for which you want information.

For example, if you wanted information on the set-log MML command, you would enter the following command:
help:set-log
The system would return a response similar to the following:
   MGC-01 - Media Gateway Controller 2008-10-07 04:22:17.894 EDT
M  COMPLD
   set-log
-------------------------------------------------------------
Purpose:
--------
Set Logging Level of a process or all processes.
Syntax:
-------
set-log:<proc>:<log level>[,mcl="mcl"][,confirm]
set-log:all:<log level>[,mcl="mcl"][,confirm]
Command Description:
proc -- The various actively and passively monitored processes running on the Cisdisplay 
all processes.
log level -- Sets the logging level for the specified process.  Logging levels are as 
follows:
-  CRIT  -- Critical level messages.
-  ERR   -- Error condition messages.
-  WARN  -- Warning condition messages.
-  INFO  -- Informational messages.
-  TRACE -- Trace messages.
-  DEBUG -- Debug-level messages (lowest level). A CONFIRM parameter is required for the 
DEBUG log level. Do not set thislog level unless directed to by the TAC.
mcl -- Machine Congestion Level.
Logging at any given level implies upper levels are included.  In other words, setting the 
INFO logging level also sets the WARN, ERR, and CRIT levels.  The order of the levels 
shown above can also be viewed as a verbosity level, in that at CRIT the least information 
is logged, and at DEBUG the most information is logged.
Input Description:
------------------
There are multiple targets/components for this command. To get target/component specific 
help select from one of the following targets/components.
 :
all :
Output Description:
-------------------
all :
Examples:
---------
The MML command shown in the following example sets the logging level of PM-01 process to 
DEBUG:
mml> SET-LOG:PM-01:DEBUG
Media Gateway Controller - MGC-01 2000-01-16 09:38:03
M CMPLD
"PM-01:DEBUG"
;
Comments:
---------
This command was introduced in Release 7.4 and replaces the CHG-LOG command.
Note that the process manager (PM-01) is not included in in the "all" parameter, because 
it is a special process. The logging level of PM-01 must be set individually, as in the 
example above.
Also, the DSKM-01 and LOG-01 (the disk monitor and log server processes, respectively) do 
not accept log-level change requests.
   ;
Reentering Previously Entered MML Commands

You can use the r MML command reenter an MML command, either a specific MML command or the last MML command you entered.

To reenter the last MML command entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
r
The system returns a response appropriate to the previously entered command. For example, if the previously entered command was rtrv-spc:all, a response similar to the following would be returned:
MGC-01 - Media Gateway Controller 2001-06-08 10:20:38
M  RTRV
   "sigsrv1:DPC=244.001.045,DNW=2:OPC=244.001.004:AOOS"
   "sigsrv2:DPC=244.018.030,DNW=2:OPC=244.001.004:AOOS"
   "sigsrv3:DPC=244.018.031,DNW=2:OPC=244.001.004:AOOS"
   "sigsrv4:DPC=244.018.032,DNW=2:OPC=244.001.004:AOOS"
   "sigsrv5:DPC=244.018.033,DNW=2:OPC=244.001.004:AOOS"
To reenter a particular MML command that you entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
r::number
Where number is the number of the MML command you want to reenter. The last MML command you entered is equal to 1, the command you entered before that would be equal to 2, and so on.

For example, to reenter the tenth most recently entered MML command, you would enter the following command:
r::10
The system returns a response appropriate to the previously entered command.

Note You can also use the up arrow key to re-execute a previously entered MML command.

Retrieving Active MML Sessions

To retrieve information on the active MML sessions, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-mml
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2008-10-17 04:37:17.586 EDT
M  RTRV
   mml1: mgcusr
The response lists the session number (mml1 in the example) and the user ID of the session owner (mgcusr in the example).

Ending an MML Session

You can use the quit MML command to end your current MML session.

Managing Signaling Channels

Signaling channels are bidirectional transport mechanisms for call-control signaling between the Cisco PGW 2200 Softswitch and other devices, such as the Cisco ITP-Ls, that provide necessary delivery reliability for higher-layer protocols. All types of signaling channels have basically the same functionality and are managed similarly. Unless otherwise noted, all commands, counters, and alarms apply to all types of signaling channels.

The basic types of signaling channels on the Cisco PGW 2200 Softswitch are

•SS7 Message Transfer Part (MTP)—Used for reliable delivery. MTP level 2 provides point-to-point delivery. MTP level 3 maintains multiple load-sharing links and multiple routes between SS7 point codes.

•SS7 MTP over IP (SS7/IP)—MTP level 2 is terminated on the Cisco ITP-L. MTP level 3 is backhauled to the Cisco PGW 2200 Softswitch by means of the Cisco-proprietary Reliable User Datagram Protocol (RUDP).

•Facility Associated Signaling (FAS)—Found in ISDN PRI or DPNSS over a 64-Kbps channel. Reliable delivery is provided by some form of Link Access Protocol (LAP), for example Q.921.

•FAS over IP (FAS/IP)—Same as FAS, but uses IP as its transport mechanism. Reliable delivery is provided by Q.921 LAP-D or RUDP/SM.

•Media Gateway Control Protocol (MGCP)—Reliable delivery is also provided by the MGCP, which uses UDP/IP.

The following sections describe the information returned by the system when you retrieve signaling channel data using MML commands.

Signaling channel name

The first field lists the MML name of the signaling channel.

Parent Name

The second field lists the MML name of the parent of the signaling channel or linkset.

Link ID

The LID field lists the associated link identification number.

Subsystem Number

The SSN field lists the associated subsystem number.

Primary Service State

The PST field shows the current primary service state of the signaling channel on the local Cisco PGW 2200 Softswitch. Table 3-8 lists the valid primary service state values:

Table 3-8 Signaling Channel Primary Service States

Link State ID

Link State

Description

AOOS

Automatically out-of-service

The system has taken the signaling channel out-of-service (OOS).

INB

Install busy

When a system is first configured, all signaling links default to this state and must be manually set in-service (IS) through the use of the set MML commands.

IS

In-service

The signaling channel is IS and fully operational. This is its normal operating state.

MOOS

Manually out-of-service

The signaling channel has been manually taken OOS.

OFF_DUTY

Off duty

State of signaling channels when a retrieve command is entered on the standby Cisco PGW 2200 Softswitch. The current service state is maintained only on the active Cisco PGW 2200 Softswitch.

OOS

Out-of-service

The signaling channel is OOS from the remote end. The system is actively trying to restore the signaling channel. The links on the standby Cisco PGW 2200 Softswitch are always OOS (with a secondary service state of STBY) because the current service state is maintained only on the active Cisco PGW 2200 Softswitch.

TRNS

Transient

The state of the signaling channel is currently being changed.

UNK

Unknown

The state of the signaling channel is not known.

Secondary Service State

The SST field shows the current secondary service state of the specified signaling channel on the local Cisco PGW 2200 Softswitch. The valid states are listed below:

•ACKD—SS7 Acknowledgement delay

•BSNR—SS7 backward sequence number received (BSNR)

•CIS—Commanded in service

•CONF—Configuration failure

•COOS—Commanded out of service

•ENGR—Call engine reset

•ISPEND—In service, pending

•LCNG—Congestion, local

•LINE—Line failure

•LINH—SS7 local inhibit

•LINK—Link failure

•LINS—Linkset failure

•NA—Cause not available

•OOSPEND—Out of service, pending

•PRHB—SS7 prohibited

•RBLK—SS7 remote blocked

•RCNG—Congestion, remote

•RINH—SS7 remote inhibit

•RSTR—SS7 restricted

•SERR—SS7 signal error

•STBY—Host is in the standby state

•SUPPENT—Supporting entity

•TPATH—Traffic path

•UNK—Cause unknown

The operations you can use to manage an signaling channels are described in the following sections:

Note To ensure that you are retrieving the correct service states of the signaling channels, always perform the retrieval procedures below on the active Cisco PGW 2200 Softswitch. The current service states of the signaling channels are maintained only on the active Cisco PGW 2200 Softswitch. If you retrieve the service state of a signaling channel on the standby Cisco PGW 2200 Softswitch, the system always returns a message that indicates that the links are out-of-service due to the host being in the standby state (i.e., "c7link1:ls01,LID=0:OOS,STBY" /* Link 1 in Linkset 1 */). Such a message does not indicate that the signaling channel itself is out-of-service. If a switchover occurs, the service state for each signaling channel remains the same as the standby Cisco PGW 2200 Softswitch assumes the active role.

•Retrieving Signaling Service States

•Retrieving Service State of C7/SS7 Links or Linksets

•Retrieving the Service State for IP Links

•Retrieving the Service State for IP Routes

•Retrieving the Service State of D-Channels

•Retrieving the State of SS7 Signaling Services

•Retrieving the State of SS7 Routes

•Retrieving the State of All Local Subsystem Numbers

•Retrieving the Service State for Associations

•Clearing TCAP Transactions

•Enabling Group Service Reset Messages

Retrieving Signaling Service States

Retrieving state information about your signaling services is a task that performed daily. For more information about this and other daily task see the "Daily Tasks" section.

To retrieve information about a specific signaling service, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-dest: sig_srv
Where sig_srv is the MML name of a signaling service.

The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 14:53:03
M  RTRV
   "sigsrv1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=RCNG"
For more information on the response to this command, see the "Understanding the Signaling Service State Information" section.

If the destination is in a primary service state other than IS, attempt to bring it into service, as described in the "Setting the Service State of a Signaling Service" section on page 8-97.

Note If the rtrv-dest MML command is entered after a switchover has occurred, the state of some of the signaling services might be listed as undefined (UND). UND is the default state for a signaling service when the system starts. In this instance, UND states indicate that the Cisco PGW 2200 Softswitch has not received a service state message for the associated signaling service since the switchover occurred. No user action is required.

Retrieving Service State of C7/SS7 Links or Linksets

To retrieve the service state for an individual SS7 link, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-c7lnk:C7_linkname|c7_linksetname
For example, to retrieve the service state for an SS7 link called c7link1, enter the command:
rtrv-c7lnk:c7link1
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "c7link1:ls01,LID=0:IS"  /* Link 1 in Linkset 1 */
To retrieve service state for all of the SS7 links, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-c7lnk:all
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "c7link1:ls01,LID=0:IS"  /* Link 1 in Linkset 1 */
   "c7link2:ls01,LID=1:IS"  /* Link 2 in Linkset 1 */
   "c7link3:ls02,LID=0:IS"  /* Link 1 in Linkset 2 */
   "c7link4:ls02,LID=1:IS"  /* Link 2 in Linkset 2 */
The valid service states for a C7/SS7 link are identical to the primary service state listings for signaling channels, as found in the "Managing Signaling Channels" section. If the link is in any other state than IS, attempt to bring the linkset into service, as described in the "Setting the Service State of a C7/SS7 Link or Linkset" section on page 8-98.

Retrieving the Service State for IP Links

To retrieve the service state for an individual IP link, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-iplnk:iplink_name
For example, to retrieve the service state of an IP link called iplink1, enter the following command:
rtrv-iplnk:iplink1
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "iplink1:IS"
To retrieve attributes for all of the IP links, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-iplnk:all
The system returns a message similar to the following, which shows the IP links to and from the
Cisco PGW 2200 Softswitches and the associated media gateways (different solutions might use different media gateways).
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "iplink1:OOS
   "iplink2:OOS
   "iplink3:OOS
   "iplink4:OOS
   "iplink5:OOS
   "iplink6:OOS
The valid service states for an IP link are identical to the primary service state listings for signaling channels, as found in the "Managing Signaling Channels" section. If the link is in any other state than IS, attempt to bring the linkset into service, as described in the "Setting the Service State of an IP Link" section on page 8-98.

Retrieving the Service State for IP Routes

To retrieve the service state for an individual IP route, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-iproute:iproute_name
For example, to retrieve the service state of an IP route called iprte1, enter the following command:
rtrv-iproute:iprte1
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "iprte1:IS"
To retrieve attributes for all of the IP routes, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-iproute:all
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "iprte1:IS
   "iprte2:IS
The valid service states for an IP route are described in the following sections. If the route is in any other state than IS, attempt to bring it into service, as described in the "Setting the Service State of an IP Route" section on page 8-99.

IP Route Primary Service States

The PST field shows the current primary service state of the IP route. Table 3-9 lists the valid primary service state values:

Table 3-9 IP Route Primary Service States

Link State ID

Link State

Description

IS

In-service

Route is IS and fully operational. This is its normal operating state.

OOS

Out-of-service

Route is OOS. The system is actively trying to restore the link.

IP Route Secondary Service States

The SST field shows the current secondary service state of the specified IP route. Table 3-10 lists the valid secondary service state values:

Table 3-10 IP Route Secondary Service States

Link State ID

Link State

Description

CONF

Configuration

Route is OOS due to a configuration failure.

COOS

Commanded out-of-service

Route has been commanded OOS by the operator.

OFF_DUTY

Off duty

Route is available for use, but not currently being used.

STBY

Standby

Routes on the standby Cisco PGW 2200 Softswitch.

Retrieving the Service State of D-Channels

To retrieve the service state for an individual D-channel, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-dchan:dchan_name
For example, to retrieve the service state for D-channel called dchan-1, enter the following command:
rtrv-dchan:dchan-1
When the D-channel is associated with an FAS signaling path, the system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "dchan-1:fas1,LID=0:IS"
   ;
In this response, fas1 is the signaling path, or a logical grouping of D-channels (equivalent to a linkset). The LID is the line identifier, or the logical line ID of the D-channel within the signaling path (equivalent to the SLC in SS7). IS is the primary service state of the D-channel.

When the D-channel is associated with an NFAS signaling path, the system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "dchan-1:nfas1,LID=0:PRI,backup=dchan-2:STBY"
   ;
In this response, nfas1 is the signaling path, or a logical grouping of D-channels (equivalent to a linkset). The LID is the line identifier, or the logical line ID of the D-channel within the signaling path (equivalent to the SLC in SS7). The next field indicates whether the specified D-channel is the primary (PRI) channel or the standby (STBY). Finally, the backup field specifies the MML name of the D-channel that is configured as the backup to the specified D-channel. This field is displayed only when a backup D-channel has been provisioned. For information on provisioning backup D-channels, see the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide.

To retrieve the service state for all of the D-channels, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-dchan:all
The system returns a message similar to the following, which shows the signaling links to and from the Cisco PGW 2200 Softswitches and the associated media gateways (different solutions might use different media gateways).
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "dchan1:nfas1,LID=0:IS"
   "dchan2:nfas1,LID=1:IS"
   "dchan3:fas1,LID=0:IS" 
The valid service states for a D-channel are identical to the primary service state listings for signaling channels, as found in the "Managing Signaling Channels" section. If the link is in any other state than IS, attempt to bring the linkset into service, as described in the "Setting the Service State of a D-channel" section on page 8-100.

Retrieving the State of SS7 Signaling Services

To retrieve the current state for an SS7 signaling service, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-spc:SS7_sig_srv
Where SS7_sig_srv is the MML name for the associated SS7 signaling service.

The system returns a response similar to the following:
   MGC-01 - Media Gateway Controller 2001-06-12 16:10:21
M  RTRV
   "ss7sigsrv1:DPC=244.001.041,DNW=2:OPC=244.001.005:AOOS"
To retrieve the current state for all of your SS7 signaling services, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-spc:all
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 16:04:59
M  RTRV
   "ss7sigsrv1:DPC=244.001.045,DNW=2:OPC=244.001.004:IS"
   "ss7sigsrv2:DPC=244.018.030,DNW=2:OPC=244.001.004:IS"
   "ss7sigsrv3:DPC=244.018.031,DNW=2:OPC=244.001.004:IS"
   "ss7sigsrv4:DPC=244.018.032,DNW=2:OPC=244.001.004:IS"
   "ss7sigsrv5:DPC=244.018.033,DNW=2:OPC=244.001.004:IS"
The valid service states for a signaling service are found in the "Understanding the Signaling Service State Information" section. If the signaling service is in any other state than IS, attempt to bring it into service, as described in the "Setting the Service State of an SS7 Signaling Service" section on page 8-97.

Retrieving the State of SS7 Routes

To retrieve the current state for an SS7 route, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-rte:dpc
Where dpc is the MML name for the associated destination point code (DPC).

The system returns a response similar to the following:
   MGC-01 - Media Gateway Controller 2001-06-12 16:17:55
M  RTRV
   "dpc1:linkset1,APC=244.001.040,PRIO=1,PST=AOOS,SST=NA"
To retrieve the current state for all of SS7 routes, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-rte:all
The system returns a response similar to the following:
   MGC-01 - Media Gateway Controller 2001-06-12 16:15:51
M  RTRV
   "dpc1:linkset1,APC=244.001.040,PRIO=1,PST=AOOS,SST=NA"
   "dpc2:linkset2,APC=244.001.041,PRIO=1,PST=AOOS,SST=NA"
   "dpc4:linkset4,APC=244.001.044,PRIO=1,PST=AOOS,SST=NA"
   "dpc5:linkset5,APC=244.001.045,PRIO=1,PST=AOOS,SST=NA"
   "dpc8:linkset8,APC=244.018.030,PRIO=1,PST=AOOS,SST=NA"
   "dpc9:linkset9,APC=244.018.031,PRIO=1,PST=AOOS,SST=NA"
   "dpc10:linkset10,APC=244.018.032,PRIO=1,PST=AOOS,SST=NA"
   "dpc11:linkset11,APC=244.018.033,PRIO=1,PST=AOOS,SST=NA"
The valid service states for a linkset are identical to the primary service state listings for signaling channels, as found in the "Managing Signaling Channels" section. If the linkset is in any other state than IS, attempt to bring the linkset into service, as described in the "Setting the Service State of a Signaling Service" section on page 8-97.

Retrieving the State of All Local Subsystem Numbers

To retrieve the state of all local subsystem number (SSNs), log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-lssn:all
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  RTRV
   "TCAP-01:SSN=1,PST=IS"
   "TCAP-01:SSN=2,PST=OOS"
The response indicates the name of the associated process, the SSN, and the state (either in-service or out-of-service). If any of the local SSNs are out of service, proceed to the "Setting the Service State of a Local Subsystem Number" section on page 8-100.

Retrieving the Service State for Associations

To retrieve the service state for an individual association, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-association:assoc_name
For example, to retrieve the service state of an association called assoc1, enter the following command:
rtrv-association:assoc1
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "assoc1:IS"
To retrieve attributes for all of the associations, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-association:all
The system returns a message similar to the following:
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "assoc1:OOS
   "assoc2:OOS
   "assoc3:OOS
   "assoc4:OOS
The valid service states for an association are described in the following sections. If the association is in any other state than IS, attempt to bring it into service, as described in the "Resolving an Association Alarm" section on page 8-115.

Association Primary Service States

The PST field shows the current primary service state of the association. Table 3-11 lists the valid primary service state values:

Table 3-11 Association Primary Service States

Link State ID

Link State

Description

INB

Install busy

When a system is first configured, all associations default to this state and must be manually set in-service (IS) through the use of the set-iplnk MML command.

IS

In-service

Association is IS and fully operational. This is its normal operating state.

OOS

Out-of-service

Association is OOS. The system is actively trying to restore the association.

Association Secondary Service States

The SST field shows the current secondary service state of the specified association. Table 3-12 lists the valid secondary service state values:

Table 3-12 Association Secondary Service States

Link State ID

Link State

Description

CONF

Configuration

Association is OOS due to a configuration failure.

COOS

Commanded out-of-service

Association has been commanded OOS by the operator.

STBY

Standby

Association on the standby Cisco PGW 2200 Softswitch.

Retrieving TCAP Transactions

To retrieve the number of active transaction capabilities application part (TCAP) transactions, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-tcap-trans
The system returns a response similar to the following:
   Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  RTRV
   "TCAP-01:TRANS=0"
Clearing TCAP Transactions

To clear all TCAP transactions that are older than a period you specify, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
clr-tcap-trans::t=number
Where number is the time period, in seconds, after which you want to clear TCAP transactions.

For example, to clear all TCAP transactions that are older than 60 seconds, you would enter the following command:
clr-tcap-trans::t=60
Enabling Group Service Reset Messages

You may want to modify the properties of an SS7 signaling service to enable your system to send SS7 group service reset (GSR) messages for all CICs during point code initialization, so that the Cisco PGW 2200 Softswitch to synchronize its bearer channel blocking state with that of the end office. The process of modifying the properties of a signaling service is referred to as dynamic reconfiguration. For more information about dynamic reconfiguration, see the "Understanding Dynamic Reconfiguration" section.

Caution We do not recommend enabling the sending of GSR messages on your Cisco PGW 2200 Softswitch.

Note You can use the CMM or the VSPT to enable the sending of GSR messages on your system. See the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide for more information about using the CMM or VSPT to modify the properties of an SS7 signaling service.

To enable the sending of GSR messages, perform the following steps:

Step 1 Start a provisioning session as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to set the property that enables the sending of GRS messages for CICs during point code initialization:
prov-ed:ss7path:name="comp_name",GRSEnabled=true
Where: comp_name—MML name for the SS7 signaling service on which you are enabling the sending of GRS messages.

For example, to enable the sending of GRS messages on an SS7 signaling service named ss7svc1, you would enter the following command:
prov-ed:ss7path:name="ss7svc1",GRSEnabled=true
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Managing Bearer Channels

The operations you can use to manage an MML session are described in the following sections:

•Verifying Proper Replication of Calls

•Retrieving the States of Bearers Held By a Media Gateway

•Blocking CICs

•Retrieving the Administrative State

Verifying Proper Replication of Calls

Ensure that the standby Cisco PGW 2200 Softswitch becomes fully operational and that the replication of calls in progress has been completed by performing the steps in the following procedure:

Caution The following command retrieves the current status of all provisioned traffic channels. If you have a large number of traffic channels, you might want to limit the command to a subset of the provisioned channels, perhaps on a signaling-service-by-signaling-service basis. For example, to see just the provisioned channels for a signaling service named ss7svc2, you would enter the following command: rtrv-tc:name="ss7svc2".

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-tc:all
The system returns a different set of responses, depending on which release of the Cisco PGW 2200 Softswitch software you are running and the type of configuration you are using on the associated media gateway.

When the Cisco PGW 2200 Softswitch software is configured for signaling, the system returns a response similar to the following:
Media Gateway Controller - MGC-67 2000-04-05 08:08:12
M  RTRV
   "c7s-1:CIC=1,PST=IS,CALL=IDLE,BLK=NONE"
   "c7s-1:CIC=2,PST=IS,CALL=IDLE,BLK=NONE"
   "c7s-1:CIC=3,PST=IS,CALL=IDLE,BLK=NONE"
   "c7s-1:CIC=4,PST=IS,CALL=IN,BLK=NONE"
   "c7s-1:CIC=5,PST=IS,CALL=IN,BLK=NONE"
   "c7s-1:CIC=6,PST=IS,CALL=IN,BLK=NONE"
   "c7s-1:CIC=7,PST=IS,CALL=IN,BLK=NONE"
   "c7s-1:CIC=8,PST=IS,CALL=IN,BLK=NONE"
   "c7s-1:CIC=9,PST=IS,CALL=IN,BLK=NONE"
When the Cisco PGW 2200 Softswitch software is configured for call control, the system returns a response similar to the following:
   Media Gateway Controller - MGC-04 2000-04-05 08:05:54
M  RTRV
   "c7s-1:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=2,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=3,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=4,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=5,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=6,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=7,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=8,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "c7s-1:CIC=9,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
Note An explanation of the fields in the response can be found in the "Understanding CIC States" section.

Step 2 Repeat Step 1 on the standby Cisco PGW 2200 Softswitch.

Step 3 Verify that the CICs in both systems are in sync and show the same status.

Calls in progress should say CALL=IN for both systems.

If necessary, you can force the active Cisco PGW 2200 Softswitch to do a maintenance switchover (see the "Performing a Manual Switchover" section) and repeat the above procedure for that system.

Warning Switchover operations cause the loss of all SS7 messages transmitted to the Cisco PGW 2200 Softswitch for approximately three seconds. This affects unstable in-progress calls as well as new calls. Stable in-progress calls are not affected.

Retrieving the States of Bearers Held By a Media Gateway

You can retrieve the states of bearer channels being held by a media gateway. To retrieve the state of a group bearer channels associated with one or more signaling destination(s) that are being held by a media gateway, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-tc-held:sig_dest| &sign_dest...
Where sig_dest is a logical signaling destination, such as an SS7 point code, FAS path, IP FAS path, or DPNSS path.

When none of the group of bearer channels associated with the specified signaling destination(s) are being held by a media gateway, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 16:28:39
M  RTRV
   "ss7svc1"
   /* No bearer channels in held state */
When bearer channels associated with the specified signaling destination(s) are being held by a media gateway, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 16:28:39
M  RTRV
   "ss7svc1:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=2,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=3,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=4,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=5,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=6,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=7,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=8,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=9,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
To retrieve the state of all bearer channels held by a media gateway, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-tc-held:all
When none of the bearer channels are being held by a media gateway, the system returns a response similar to the following:
Retrieving results.  This could take a few moments...
   MGC-01 - Media Gateway Controller 2001-06-12 16:28:39
M  RTRV
   "ss7svc1"
   /* No bearer channels in held state */
   "ss7svr2"
   /* No bearer channels in held state */
When bearer channels are being held by a media gateway, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 16:28:39
M  RTRV
   "ss7svc1:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=2,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=3,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=4,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=5,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=6,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=7,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=8,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc1:CIC=9,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=10,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=11,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=12,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=13,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=14,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=15,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=16,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=17,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
   "ss7svc2:CIC=18,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
Blocking CICs

You may need to block a CIC or a range of CICs on your Cisco PGW 2200 Softswitch. Blocking a single CIC causes a BLA message to be sent to the destination SSP. Blocking a range of CICs causes a CGB message to be sent to the destination SSP. The range option only can be used to block CICs within a given trunk (T1 or E1).

To block a single CIC, log in to your active Cisco PGW 2200 Softswitch, start an MML session and enter the following command:
blk-cic:sig_srv:CIC=number
Where:

•sig_srv—MML name of a signaling service associated with the CIC you want to block.

•number—The number of the CIC you want to block.

For example, to block CIC number 1, which is associated with a signaling service called ss7svc1, you would enter the following command:
blk-cic:ss7svc1:cic=1
To block a range of CICs, log in to your active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
blk-cic:sig_srv:CIC=number,RNG=range
Where:

•sig_srv—MML name of a signaling service associated with the CICs you want to block.

•number—The number of the first CIC in the range of CICs you want to block.

•range—Specifies the end of the range of CICs to be blocked.

Note The Cisco PGW 2200 Softswitch software can be configured to issue individual or group supervision messages for point codes that are associated with an ISUP signaling service. ISUP signaling services issue group supervision messages by default. If an ISUP signaling service is configured to issue individual supervision messages, use of the range option causes individual supervision messages to be issued for each CIC in the range, instead a single group supervision message.

For example, to block CIC number 1 through 20, which are associated with a signaling service called ss7svc1, you would enter the following command:
blk-cic:ss7svc:cic=1,rng=20
To verify that the CIC(s) have been successfully blocked, retrieve the status of the affected CICs as described in the "Verifying CIC States" section. When you want to return the CIC(s) to service, you must unblock the CIC(s) as described in the "Unblocking CICs" section on page 8-133.

Retrieving the Administrative State

The administrative state refers to the state of CICs (on the Cisco PGW 2200 Softswitch) and spans and bearer channels (on the associated media gateway). There are three possible states: locked, unlocked, and shutdown. You can use the rtrv-admin-state MML command to determine the administrative state of several objects in the Cisco SS7 solution environment, including the Cisco PGW 2200 Softswitch, an associated MGCP media gateway, a trunk group, a signaling service, spans and bearer channels associated with a signaling service (for non-ISUP trunks), and CICs associated with a signaling service (for ISPU trunks).

When you retrieve the administrative state of a object that consists of groups of CICs or spans and bearer channels, you receive an inferred target state, based on the following criteria:

•If all circuits are in a locked state, the inferred target administrative state is locked.

•If at least one circuit is in an unlocked state, the inferred target administrative state is unlocked.

•If the circuits are in a mixture of the locked and shutdown states, the inferred target administrative state is shut down.

If you want to change the administrative state of a component, see the "Setting the Administrative State" section on page 8-118.

The following procedures describe how you can use the rtrv-admin-state MML command:

•Retrieving the Administrative State of a Cisco PGW 2200 Softswitch

•Retrieving the Administrative State of a Media Gateway

•Retrieving the Administrative State of a Trunk Group

•Retrieving the Administrative State of a Signaling Service

•Retrieving the Administrative State of Spans

•Retrieving the Administrative State of CICs

Retrieving the Administrative State of a Cisco PGW 2200 Softswitch

To retrieve the administrative state of a Cisco PGW 2200 Softswitch, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:mgc
Where mgc is the MML name of the Cisco PGW 2200 Softswitch.

The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "mgca:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
If you want to change the administrative state of the Cisco PGW 2200 Softswitch, see the "Setting the Administrative State of a Cisco PGW 2200 Softswitch" section on page 8-118.

Retrieving the Administrative State of a Media Gateway

To retrieve the administrative state of an associated media gateway, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:gateway
Where gateway is the MML name of the associated media gateway.

Note Not all media gateway types are applicable. Supported types are CU, MUX, and MGW external nodes.

The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "mgw1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
If you want to change the administrative state of the media gateway, see the "Setting the Administrative State of a Media Gateway" section on page 8-119.

Retrieving the Administrative State of a Trunk Group

To retrieve the administrative state of a trunk group, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:trkgrp
Where trkgrp is the MML name of the trunk group.

Note This command can only be used for time-division multiplexing (TDM) trunk groups. Allow the corresponding MML name for component type "0020".

The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "trunkgrp1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
If you want to change the administrative state of the trunk group, see the "Setting the Administrative State of a Trunk Group" section on page 8-119.

Retrieving the Administrative State of a Signaling Service

To retrieve the administrative state of a signaling service, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:sig_srv
Where sig_srv is the MML name of the signaling service. The following signaling service types are valid for this command:

•For in-band TDM up to MUX and then time switched to TDM media and sent to the Cisco PGW 2200 Softswitch.

•For in-band TDM signaling up to CU and then encapsulated and sent over IP to the Cisco PGW 2200 Softswitch.

•For in-band TDM signaling up to the media gateway and then converted to NI2 and sent to the
Cisco PGW 2200 Softswitch over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco PGW 2200 Softswitch).

•Signaling service or routeset associated with a DPC.

•EISUP signaling service.

The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "ss7svc1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
If you want to change the administrative state of the signaling service, see the "Setting the Administrative State of a Signaling Service" section on page 8-120.

Retrieving the Administrative State of Spans

To retrieve the administrative state of a single span, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:sig_srv,span=x
Where:

•sig_srv is the MML name of the signaling service. The following signaling service types are valid for this command:

–For in-band TDM up to MUX and then time switched to TDM media and sent to the Cisco PGW 2200 Softswitch.

–For in-band TDM signaling up to CU and then encapsulated and sent over IP to the Cisco PGW 2200 Softswitch.

–For in-band TDM signaling up to the media gateway and then converted to NI2 and sent to the
Cisco PGW 2200 Softswitch over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco PGW 2200 Softswitch).

–Signaling service or routeset associated with a DPC.

–EISUP signaling service.

•x—A16-bit value that identifies an ISDN/PRI physical cable.

For example, to determine the administrative state of span number 2 associated with a signaling service called ss7svc1, you would enter the following command:
rtrv-admin-state:ss7svc1,span=2
The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "ss7svc1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
To retrieve the administrative state of a bearer channel or a range of bearer channels in a span, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:sig_srv,span=x,bc=y[,rng=range]
Where:

•sig_srv is the MML name of the signaling service. The following signaling service types are valid for this command:

–For in-band TDM up to MUX and then time switched to TDM media and sent to the Cisco PGW 2200 Softswitch.

–For in-band TDM signaling up to CU and then encapsulated and sent over IP to the Cisco PGW 2200 Softswitch.

–For in-band TDM signaling up to the media gateway and then converted to NI2 and sent to the
Cisco PGW 2200 Softswitch over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco PGW 2200 Softswitch).

–Signaling service or routeset associated with a DPC.

–EISUP signaling service.

•x—A16-bit value that identifies an ISDN/PRI physical cable.

•y—A numeric value that identifies the non-ISUP bearer channel number.

•range—A value such that y+range is a valid bearer channel number. The administrative state for all bearer channels between y and y+range are retrieved.

For example, to determine the administrative state of bearer channels numbers 2 through 6, associated with a signaling service called ss7svc1, you would enter the following command:
rtrv-admin-state:ss7svc1,span=2,bc=2,rng=5
The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "ss7svc1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
If you want to change the administrative state of the spans, see the "Setting the Administrative State of Spans" section on page 8-121.

Retrieving the Administrative State of CICs

To retrieve the administrative state of a CIC or a range of CICs, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-admin-state:sig_srv,cic=number[,rng=range]
Where:

•sig_srv is the MML name of the signaling service. The following signaling service types are valid for this command:

–For in-band TDM up to MUX and then time switched to TDM media and sent to the Cisco PGW 2200 Softswitch.

–For in-band TDM signaling up to CU and then encapsulated and sent over IP to the Cisco PGW 2200 Softswitch.

–For in-band TDM signaling up to the media gateway and then converted to NI2 and sent to the
Cisco PGW 2200 Softswitch over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco PGW 2200 Softswitch).

–Signaling service or routeset associated with a DPC.

–EISUP signaling service.

•number—A valid CIC number.

•range—A value such that y+range is a valid CIC number. The administrative state for all CICs between y and y+range are retrieved.

For example, to determine the administrative state of CICs 2 through 11 associated with a signaling service called ss7svc1, you would enter the following command:
rtrv-admin-state:ss7svc1,cic=2,rng=9
The system returns a response similar to the following:
Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "ss7svc1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"
If you want to change the administrative state of the CICs, see the "Setting the Administrative State of CICs" section on page 8-123.

Retrieving DPNSS Virtual Bearer Channel Status

You can retrieve the status of DPNSS vitual bearer channels by issuing the rtrv-vir-tc command. The rtrv-vir-tc command displays the same output as the rtrv-tc command except that it eliminates the SPAN and GW_STAT fields.

To retrieve the status of DPNSS virtual bearer channels, issue the following MML command:

rtrv-virt-tc:dpnss-path

Where:

•VTC—The virtual channel number.

•CALL—The status of the call: IDLE, IN, or OUT (call direction).

•PST—Primary state; valid values are

–AOOS—The resource has been taken out of service by the system.

–INB—Installed busy (resource has been created but not yet commanded IS or OOS by means of the SET-DEST command).

–IS—In service.

–MOOS—Manually taken out of service.

–OOS—Out of service.

–TRNS—Transient; the state is currently being changed.

–UNK—Unknown.

•BLK—Blocking state

–NONE—There is no block on the CIC. DS0 is available for use.

•TRANS—Number of active transactions.

The MML command shown in the following example displays information for a DPNSS virtual bearer channel:
mml> rtrv-virt-tc:dpnss-path-1:
   MGC-01 - Media Gateway Controller 2009-01-19 13:36:14.202 CST
M  RTRV
   "dpnss-path-1:VTC=33,CALL=IDLE,PST=IS,BLK=NONE"
   "dpnss-path-1:VTC=34,CALL=IDLE,PST=IS,BLK=NONE"
   "dpnss-path-1:VTC=35,CALL=IDLE,PST=IS,BLK=NONE"
   "dpnss-path-1:VTC=36,CALL=IDLE,PST=IS,BLK=NONE"
   "dpnss-path-1:VTC=37,CALL=IDLE,PST=IS,BLK=NONE"
   "dpnss-path-1:VTC=38,CALL=IDLE,PST=IS,BLK=NONE"
Managing SIP Communications

The Cisco PGW 2200 Softswitch software supports SIP call control. Many of the procedures defined for signaling channels and bearer channels can be used to manage SIP communications. The following procedures are strictly for use in managing SIP communications:

•Managing the DNS Cache

•Retrieving SIP Call Information

Managing the DNS Cache

When you have provisioned the Cisco PGW 2200 Softswitch to function as a Session Initiation Protocol (SIP) end point, you may need to manage the content of the DNS cache.

Displaying the Contents of the DNS Cache

To display the contents of the DNS cache, perform the following steps:

Step 1 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
sta-dns-info:sippath_name:"URL | cache_entry_num | null_string"
Where:

•sippath_name—MML name of the SIP signaling service associated with the DNS cache.

•URL—The associated WWW address. If you enter the associated URL in this command, the command in Step 2 displays the IP address and the time to live (TTL) values.

•cache_entry_num—The DNS cache entry number. If you enter the associated cache entry number in this command, the command in Step 2 displays the URL, IP address and TTL values.

•null_string—An empty string (entered as "" in the command line). If you enter a null string in this command, the command in Step 2 displays the DNS IP addresses, size of the cache, percentage of the cache being used, and the local TTL value.

For example, to start a DNS information request for the cache associated with the signaling service, sipsigpath, enter one of the following commands:
sta-dns-info:sipsigpath:"sipphone1.cisco.com"
sta-dns-info:sipsigpath:"10"
sta-dns-info:sipsigpath:""
Step 2 Request the contents of the specified DNS cache associated with a SIP signaling service. To do this, enter the following command:
rtrv-dns-info:sippath_name
Where: sippath_name—MML name of the SIP signaling service you entered in Step 1.

If you entered the associated URL along with name of the SIP signaling service in Step 1, the system returns a message similar to the following.
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   IP address = 193.12.174.56
   TTL = 240
If you entered the associated cache entry number along with the name of the SIP signaling service, the system returns a message similar to the following.
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   URL = sipphone3.cisco.com
   IP address = 193.12.174.56
   TTL = 240
If you entered a null string along with the name of the SIP signaling service, the system returns a message similar to the following.
   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   DNS 1 address 193.12.77.2
   DNS 2 address 193.21.9.76
   Cache size = 280
   Cache usage = 81
   Local TTL = 240   ;
Purging the Contents of the DNS Cache

If you want to purge the DNS cache, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
sta-dns-purge:sippath_name
Where: sippath_name—MML name of the SIP signaling service associated with the DNS cache.

For example, to purge the DNS cache associated with the signaling service, sipsigpath, enter the following command:
sta-dns-purge:sipsigpath
Retrieving SIP Call Information

From Release 9.3(2) to Release 9.5(2)

Starting in Release 9.3(2), you can use the rtrv-sip MML command to retrieve call information data, such as SIP call identification number, and the originating and terminating numbers, for any call that uses SIP for at least one end of the call. The following sections describe how the command can be used to retrieve SIP call information.

To retrieve information about calls that use SIP for at least one end of the call, log in to the active Cisco PGW 2200 Softswitch, and enter the following command:
rtrv-sip:type [timerperiod=min | detail]
Where:

type—The signaling service type can be one of the following:

–all—Displays all calls that use SIP for at least one end of a call.

–tdm—Displays calls that use SS7, ISDN, or other protocols of this type on the other end of a call (one end of the call is always SIP).

–ip—Displays calls that use EISUP or H.323 on the other end of a call (one end of the call is always SIP).

–sip—Displays calls that use SIP on both ends of a call (a SIP-to-SIP call)

•min—Optional parameter to limit the content of the response to calls that have durations over the specified amount, in minutes. For example if you entered the parameter as timerperiod=120, the response to this command would be limited to calls of the specified type that are over 120 minutes in duration.

Note If you find that you have SIP-to-SIP calls that have excessive durations, you can cancel those calls using the procedure described in the Stopping SIP-to-SIP Calls, page 8-150.

•detail—Optional parameter to provide the calling (from) and the called (to) number for the specified type of calls.

The standard version of this command returns a response that indicates the SIP call identification name and the protocol type used on the other end of the call. The protocol type can be one of the following:

•TDM—Used when the other end of the call is SS7, ISDN, or other protocols of this type

•IP—Used when the other end of the call is EISUP or H.323

•SIP—Used when the other end of the call is SIP (a SIP-to-SIP call)

When the standard version of this command is entered, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2002-05-13 10:02:08.833 PST
M  RTRV
   "sip-sigpath:CID=10177b4e1aed3d8679b40d824a72e2e9@172.22.119.82," 
   "sip-sigpath:CALL=OUT,MATE_FAMILY=SIP" 
   "sip-sigpath:CID=10177b4e1aed3d8679b40d824a72e2e9@172.22.119.82," 
   "sip-sigpath:CALL=IN,MATE_FAMILY=SIP" 
   "sip-sigpath:CID=1febf77f5ba699047c1251194a4cd23c@172.22.119.82," 
   "sip-sigpath:CALL=OUT,MATE_FAMILY=SIP"
   "sip-sigpath:CID=1febf77f5ba699047c1251194a4cd23c@172.22.119.82," 
   "sip-sigpath:CALL=IN,MATE_FAMILY=IP" 
   "sip-sigpath:CID=257df6bc34dcec346102c00233b68b34@172.22.119.82," 
   "sip-sigpath:CALL=OUT,MATE_FAMILY=IP"
When this command is entered with the optional command to provide detailed call data, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2002-05-13 10:02:08.833 PST
M  RTRV
   "sip-sigpath:CID=10177b4e1aed3d8679b40d824a72e2e9@172.22.119.82," 
   "sip-sigpath:CALL=OUT,MATE_FAMILY=SIP,FROM=2025553230,TO=4080000284" 
   "sip-sigpath:CID=10177b4e1aed3d8679b40d824a72e2e9@172.22.119.82," 
   "sip-sigpath:CALL=IN,MATE_FAMILY=SIP,FROM=2025553230,TO=4080000284" 
   "sip-sigpath:CID=1febf77f5ba699047c1251194a4cd23c@172.22.119.82," 
   "sip-sigpath:CALL=OUT,MATE_FAMILY=SIP,FROM=2025555589,TO=4080000439""sip-sigpath:CID=1f
    ebf77f5ba699047c1251194a4cd23c@172.22.119.82," 
   "sip-sigpath:CALL=IN,MATE_FAMILY=IP,FROM=2025555589,TO=4080000439" 
   "sip-sigpath:CID=257df6bc34dcec346102c00233b68b34@172.22.119.82," 
   "sip-sigpath:CALL=OUT,MATE_FAMILY=IP,FROM=2025559602,TO=4080000205"
From Release 9.6(1) to Release 9.7(3)

Starting in Release 9.6(1), use rtrv-callinfo to display the call IDs of all EISUP/SIP calls on the system.

Note See "RTRV-CALLINFO—Display Call IDs of EISUP/SIP (Release 9.6(1))" in Chapter 2 of Cisco PGW 2200 Softswitch Release 9 MML Command Reference at
http://www.cisco.com/en/US/docs/voice_ip_comm/pgw/9/command/reference/mmlref_1.html

To retrieve information about calls that use SIP for at least one end of the call, log in to the active Cisco PGW 2200 Softswitch, and enter the following command:
rtrv-callinfo:target[:mateprottype][,calltime][,detail]
Where:

•target—The signaling service type can be one of the following:

–all—Displays all calls that use SIP for at least one end of a call.

–MML names for SIP or EISUP signaling service.

•mateprottype—The signaling service type can be one of the following:

–all—Displays all calls that use SIP or EISUP on both ends of a call.

–sip—Displays calls that use SIP on both ends of a call (a SIP-to-SIP call) or calls use EISUP for EISUP-SIP calls.

–eisup—Displays calls that use SIP on both ends of a call (a SIP-to-SIP call) or calls use EISUP for EISUP-EISUP calls.

–tdm—Displays calls that use SIP on both ends of a call (a SIP-to-SIP call) or calls that use SS7, ISDN, or other protocols of this type on the other end of a call (one end of the call is always SIP).

–ip—Displays calls that use SIP on both ends of a call (a SIP-to-SIP call) or calls that use EISUP or H.323 on the other end of a call (one end of the call is always SIP).

•calltime—Optional parameter to limit the content of the response to calls that have durations over the specified amount, in minutes. For example if you entered the parameter as timerperiod=120, the response to this command would be limited to calls of the specified type that are over 120 minutes in duration.

•detail—Optional parameter to provide the calling (from) and the called (to) number for the specified type of calls.

When this command is entered with the optional command to provide detailed call data, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2002-05-13 10:02:08.833 PST
M  RTRV
   "sippath-sip-outbound:CALL=OUT,MATE_FAMILY=SIP,FROM=3330000,TO=sipp"
   "sippath-sip-outbound:CID=5248672-32474@10.0.120.3,"
   "sippath-sip-outbound:CALL=IN,MATE_FAMILY=SIP,FROM=sipp,TO=3330000"
   "sippath-sip-outbound:CID=5248672-32474@10.0.120.3,"
   "sippath-sip-outbound:CALL=OUT,MATE_FAMILY=SIP,FROM=3330000,TO=sipp"
   "sippath-sip-outbound:CID=5248673-32474@10.0.120.3,"
   "sippath-sip-outbound:CALL=IN,MATE_FAMILY=SIP,FROM=sipp,TO=3330000"
   "sippath-sip-outbound:CID=5248673-32474@10.0.120.3,"
   "sippath-sip-outbound:CALL=OUT,MATE_FAMILY=SIP,FROM=3330000,TO=sipp"
   "sippath-sip-outbound:CID=5248674-32474@10.0.120.3,"
   "sippath-sip-outbound:CALL=IN,MATE_FAMILY=SIP,FROM=sipp,TO=3330000"
   "sippath-sip-outbound:CID=5248674-32474@10.0.120.3,"
   "sippath-sip-outbound:CALL=OUT,MATE_FAMILY=SIP,FROM=3330000,TO=sipp"
   "sippath-sip-outbound:CID=5248675-32474@10.0.120.3,"
Provisioning your Cisco PGW 2200 Softswitch

The operations you can use to provision your Cisco PGW 2200 Softswitch are described in the following sections:

•Starting a Provisioning Session

•Saving and Activating your Provisioning Changes

•Ending a Provisioning Session Without Activating your Changes

•Invoking Dynamic Reconfiguration

•Retrieving Provisioning Data

•Provisioning a Dial Plan

•Importing Provisioning Data

•Exporting Provisioning Data

•Managing Automatic Congestion Control

For more detailed information about provisioning your Cisco PGW 2200 Softswitch, see the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide.

Starting a Provisioning Session

You may need to start a provisioning session as part of your system operations. To do this, log into the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-sta::srcver="curr_ver",dstver="mod_ver"
Where:

•curr_ver—The name of the current configuration version. In place of the name of the current configuration version, you can also enter:

–new—A new default session configuration; no existing source configuration is available.

–active—Selects the active configuration as the source for configuration changes.

Note You can use new as the source configuration only when there is no existing, active set of provisioning data in the configuration library. Therefore, new cannot be used as the source configuration once a provisioning session has been saved and activated by using prov-cpy or prov-dply. Once you have saved and activated a set of data, you must use either active or the name of the set of provisioning data as the source configuration.

Note If you do not know the name of your current configuration session, you can use the CONFIG-LIB viewer in the MGC toolbar to determine that name. For more information on the CONFIG-LIB viewer, proceed to the "Using the Config-Lib Viewer" section.

•mod_ver—A new configuration version name that contains your provisioning changes.

For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:
prov-sta::srcver="ver1",dstver="ver2"
Once a provisioning session is underway, you may use the prov-add, prov-ed, or prov-dlt MML commands to add, modify, and delete components on your system. If you want to add components to your system, see the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide. If you want to modify or delete components on your system, see the "Invoking Dynamic Reconfiguration" section.

There are two ways to close your provisioning session: save and activate your provisioning changes or end your provisioning session without saving and activating your changes. For more information on saving and activating your provisioning changes, see the "Saving and Activating your Provisioning Changes" section. For more information on ending your provisioning session without saving and activating your changes, see the "Ending a Provisioning Session Without Activating your Changes" section.

Saving and Activating your Provisioning Changes

When you have completed making provisioning changes in your session, you must enter a command to save and activate your changes. There are two different provisioning MML commands that do this: prov-cpy and prov-dply.

Caution Using the prov-cpy and prov-dply MML commands can severely impact your system's call processing performance, depending on the extent of your provisioning changes. We recommend that these commands be issued during a maintenance window when traffic is minimal.

The prov-cpy MML command is used to save and activate your changes on the active Cisco PGW 2200 Softswitch. This command is typically used to save and activate changes on a Cisco PGW 2200 Softswitch in a simplex configuration. However, you can use the prov-cpy MML command on Cisco PGW 2200 Softswitches in high-availability or continuous-service configurations, to save and activate your changes on the active Cisco PGW 2200 Softswitch. If you choose to do this, you should enter the prov-sync MML command immediately afterwards, to have your changes saved and activated on the standby Cisco PGW 2200 Softswitch.

Note When you add new signaling links and/or CICs to your provisioning data using the prov-cpy command, and then save your new objects to the standby Cisco PGW 2200 Softswitch using the prov-sync command, the link and call state data are not synchronized. To ensure that the link and call state data are synchronized, reboot the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch once prov-sync has completed its synchronization.

Caution Using the prov-sync MML command can severely impact your system's call processing performance. We recommend that this command be issued during a maintenance window when traffic is minimal.

Note When the prov-sync MML command is used to synchronize the provisioning settings on the standby Cisco PGW 2200 Softswitch with current settings on the active Cisco PGW 2200 Softswitch, the system does not indicate when the synchronization process has failed.

Note When you enter the prov-cpy command, your provisioning session is also automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session as described in the "Starting a Provisioning Session" section.

The prov-dply MML command is used to save and activate your changes on the active and standby
Cisco PGW 2200 Softswitches. This command is typically used to save and activate changes on Cisco PGW 2200 Softswitches in high-availability or continuous-service configurations. This command should not be used on a Cisco PGW 2200 Softswitch in a simplex configuration.

Note When you enter the prov-dply command, your provisioning session is also automatically ended, unless an error occurs during execution. If you want to make additional provisioning changes, you must start a new provisioning session as described in the "Starting a Provisioning Session" section.

Ending a Provisioning Session Without Activating your Changes

You may find that you want to end a provisioning session without saving and activating the changes you have entered during your session. If this is the case, you can enter the prov-stp MML command. This command ends your current provisioning session and your changes are not entered.

Invoking Dynamic Reconfiguration

You can dynamically reconfigure, that is modify or delete, select components that you have provisioned on your Cisco PGW 2200 Softswitch. The following procedure lists the sequence of actions you must perform (actual steps to take depend on the provisioning tool you use):

Note For more information on which components can be dynamically reconfigured, see the "Understanding Dynamic Reconfiguration" section.

Step 1 Start a provisioning session as described in the "Starting a Provisioning Session" section.

Step 2 Enter the prov-ed or prov-dlt MML commands to change or delete a component. See the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide for more information on the specific structure of the command for the component type you want to dynamically reconfigure.

Note To change or delete a component, you might have to meet certain preconditions, such as changing the service state of the component to OOS using MML commands (as mentioned in Table 3-13).

Step 3 Repeat Step 2 for each component that you want to modify or delete. See the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide for provisioning guidelines.

Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Step 4 After completing a dynamic reconfiguration operation on the Cisco PGW 2200 Softswitch, you must issue a service message from the associated media gateway to invoke the changes throughout your SS7 solution.

Note See the documentation associated with your media gateway for more information on issuing service messages.

Understanding Dynamic Reconfiguration

Dynamic reconfiguration is a function in the Cisco PGW 2200 Softswitch software that allows you to modify or delete Cisco PGW 2200 Softswitch components while the Cisco PGW 2200 Softswitch software is still in service. Dynamic reconfiguration can be performed without shutting down or restarting either the Cisco PGW 2200 Softswitch software or the Sun host platform.

The Cisco PGW 2200 Softswitch component types that can be dynamically reconfigured are listed below. No other component types can be dynamically reconfigured.

•CICs

•Point codes (DPC, originating point code [OPC], or APC)

•Physical interfaces (TDM, ATM, or Ethernet)

•Signaling links (TDM, ATM, or SS7)

•Signaling services

•SS7 subsystems

•SS7 routes

•Trunk groups

•Component properties (linksets, signaling services, and trunk groups)

Table 3-1 lists the preconditions that must be met for the component before any modification or deletion action can be performed as part of dynamic reconfiguration. There are no preconditions for adding components as part of dynamic reconfiguration.

Table 3-13 Dynamic Reconfiguration Preconditions

Component

Preconditions

CICs

Call state of the CIC must be IDLE (see the "Verifying CIC States" section) and the service state of the associated DPC must be set to OOS (see the "Setting the Service State of a Signaling Service" section on page 8-97).

or

Block type for the CIC must be set to locally blocked (see the "Blocking CICs" section) and the associated media gateway span and timeslot must be set to OOS (see the documentation for the media gateway).

Point codes (DPC, OPC, or APC) and SS7 routes

Service state of the point code and SS7 route must be set to OOS (see the "Setting the Service State of a Signaling Service" section on page 8-97).

Signaling links (TDM, ATM, or SS7)

Service state of the signaling link must be set to OOS (see the "Setting the Service State of a C7/SS7 Link or Linkset" section on page 8-98).

Signaling services

Service state of the signaling service must be set to OOS (see the "Setting the Service State of an SS7 Signaling Service" section on page 8-97).

SS7 subsystems

Service state of the subsystems and routes must be set to OOS (see the "Setting the Service State of a Local Subsystem Number" section on page 8-100).

Trunk groups

Component properties (linksets, signaling services, and trunk groups)

None.

For example, if you want to change the settings for a DPC or remove it altogether, you must first set the service state of the DPC to OOS, before attempting to make changes. If you do not set the service state to OOS, your dynamic reconfiguration request is rejected with an error message.

During dynamic reconfiguration, the system goes through two phases. First, it validates the service states of all objects being changed. If any error is encountered, no reconfiguration takes place on any of the objects. Error messages indicate which components are in error. The format of the error message is "Component's MML name, process rejecting change, reason for rejecting the change, remedy."

If no errors are encountered during the validation phase, the update phase proceeds. This is where the new configuration data is loaded by all of the processes. At the beginning of the update phase, an SNMP alarm is displayed to indicate update starting. At the end of the update phase, the alarm clears, and, if commit/deploy was initiated by MML, the MML response is returned.

To change the current configuration of a component using dynamic reconfiguration, you can only use the provisioning tools provided with the Cisco PGW 2200 Softswitch, MML provisioning commands or an SNMP provisioning agent (such as the Cisco Voice Services Provisioning Tool (Cisco VSPT)).

Provisioning or configuring by using any other means can cause errors during the dynamic reconfiguration process. Using these tools is required because the dynamic reconfiguration process relies on the provisioning tools to validate the data values and, more importantly, to crosscheck the dependencies of the objects. For example, the provisioning tool ensures that adding a signal transfer point (STP) first requires the existence of the associated route.

Retrieving Provisioning Data

You can use the prov-rtrv MML command to retrieve information about your current provisioning settings. The ways in which you can use this command to retrieve provisioning data are described in the following sections:

•Retrieving Data for an Individual Component

•Retrieving Data for Select Components

•Retrieving Data for All Components of a Particular Type

•Retrieving Data on the Current Provisioning Session

•Retrieving Data on Supported Signaling Protocols

Retrieving Data for an Individual Component

You can retrieve provisioning data on any individual component on your system. To do this, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:component:name=MML_name
Where:

•component—The MML component type associated with the desired component. You can determine the MML names for select provisioned component types using the prov-rtrv:all MML command.

•MML_name—The MML name for the desired component. You can determine the MML names for select components using the prov-rtrv:all MML command.

For example, to view the provisioning data for a point code called opc, you would enter the following command:
prov-rtrv:opc:name="opc"
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2000-08-25 16:28:56
M  RTRV
   ""session=active:ptcode"
   /* 
   NAME = opc
   DESC = Originating Point Code
   NETADDR = 201.1.100
   NETIND = 2
   */
The response to the command is dependent upon the component type associated with the desired component.

For example, to view the properties for an SS7 signaling service called ss7svc1, you would enter the following command:
prov-rtrv:sigsvcprop:name="ss7svc1"
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-01 10:09:47
M  RTRV
   "session=active:sigsvcprop"
   /*
adjDestinations = 16
AlarmCarrier = 0
BOrigStartIndex = 0
BothwayWorking = 1
BTermStartIndex = 0
CctGrpCarrier = 2
CGBA2 = 0
CircHopCount = 0
CLIPEss = 0
CotInTone = 2010
CotOutTone = 2010
CotPercentage = 0
dialogRange = 0
ExtCOT = Loop
ForwardCLIinIAM = 1
ForwardSegmentedNEED = 1
GLARE = 0
GRA2 = 0
GRSEnabled = false
InternationalPrefix = 0
layerRetries = 2
layerTimer = 10
MaxACL = 3
maxMessageLength = 250
mtp3Queue = 1024
NationalPrefix = 0
NatureOfAddrHandling = 0
Normalization = 0
OMaxDigits = 24
OMinDigits = 0
OOverlap = 0
OwnClli = na
RedirMax = 3
ReleaseMode = Async
restartTimer = 10
RoutePref = 0
sendAfterRestart = 16
slsTimer = 300
srtTimer = 300
sstTimer = 300
standard = ANSI92
SwitchID = 0
TMaxDigits = 24
TMinDigits = 0
TOverlap = 0
variant = SS7-ANSI
VOIPPrefix = 0
   */
Retrieving Data for Select Components

You can retrieve data on select components provisioned on your system. To do this, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:all
Note This command returns data on all signaling components, except for signaling service and linkset properties.

The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 17:12:49
M  RTRV
   "session=active:all"
   /*
NAME                  COMPID    Parent Name           TID              Description
----                  --------  -----------           ---              -----------
"ether1"              00050003  "MGC-01"              CARD             "Ethernet Card 1"
"ether2"              00050004  "MGC-01"              CARD             "Ethernet Card 2"
"enif1"               00060003  "ether1"              ENETIF           "Ethernet IF 1"
"enif2"               00060004  "ether2"              ENETIF           "Ethernet IF 2"
"ls1"                 00080001  "dpc1"                LNKSET           "link set 1 to 
2600-202-INET-6a"
"ls2"                 00080004  "dpc2"                LNKSET           "link set 2 to 
2600-203-INET-6a"
"ls-itu"              00080005  "stp1"                LNKSET           "Lkset stp1,1-6-1"
"va-5300-202-1"       00100001  "va-5300-202"         IPLNK            "link 1 to 
va-5300-202"
"va-5300-202-2"       00100002  "va-5300-202"         IPLNK            "link 2 to 
va-5300-202"
"va-5300-203-1"       00100003  "va-5300-203"         IPLNK            "link 1 to 
va-5300-203"
"va-5300-203-2"       00100004  "va-5300-203"         IPLNK            "link 2 to 
va-5300-203"
"va-5800-5-1"         00100005  "va-5800-5"           IPLNK            "link 1 to 
va-5300-202"
"va-5800-5-2"         00100006  "va-5800-5"           IPLNK            "link 2 to 
va-5800-5"
"route1"              00110001  "MGC-01"              SS7ROUTE         "route to dpc1 via 
ls1"
"rt3"                 00110005  "MGC-01"              SS7ROUTE         "SS7 Rte3-for scp2"
"rt1"                 00110006  "MGC-01"              SS7ROUTE         "SS7 Rte1-stp1"
"rt2"                 00110007  "MGC-01"              SS7ROUTE         "SS7 Rte2-for scp1"
"route2"              0011000a  "MGC-01"              SS7ROUTE         "route to dpc2 via 
ls2"
"opc2"                00130002  "MGC-01"              PTCODE           "Own Pointcode"
"dpc2"                00130004  "MGC-01"              PTCODE           "TDM Switch dpc2 
Pointcode"
"opc1"                00130006  "MGC-01"              PTCODE           "Own Pointcode"
"dpc1"                00130007  "MGC-01"              PTCODE           "TDM Switch dpc1 
Pointcode"
"va-5300-202"         00140001  "nas1"                NASPATH          "Serviceto nas1"
"va-5300-203"         00140002  "nas2"                NASPATH          "Serviceto nas2"
"va-5800-5"           00140003  "nas1"                NASPATH          "Serviceto nas1"
"ss7svc2"             00150002  "dpc2"                SS7PATH          "SS7 service to 
dpc2"
"ss7svc1"             00150005  "dpc1"                SS7PATH          "SS7 service to 
dpc1"
"nas1"                00160001  "MGC-01"              EXTNODE          "va-5300-202"
"nas2"                00160002  "MGC-01"              EXTNODE          "va-5300-203"
"nas8"                00160003  "MGC-01"              EXTNODE          "va-5800-5"
"ls1link1"            001d0001  "ls1"                 C7IPLNK          "link 1 of ls1 to 
va-2600-202"
"ls2link1"            001d0002  "ls2"                 C7IPLNK          "link 1 of ls2 to 
va-2600-202"
"ls1link2"            001d0003  "ls1"                 C7IPLNK          "link 2 of ls1 to 
va-2600-203"
"ls2link2"            001d0004  "ls2"                 C7IPLNK          "link 2 of ls2 to 
va-2600-203"
"lk-3"                001d0005  "ls-itu"              C7IPLNK          "SS7ITU 2600-91"
"stp1"                001e0001  "MGC-01"              APC              "STP 1"
"scp1"                001e0002  "MGC-01"              APC              "SCP1 for PC/SSN"
"scp2"                001e0003  "MGC-01"              APC              "SCP2 for PC/SSN"
"ss7subsys3"          001f0003  "MGC-01"              SS7SUBSYS        "pc_ssn scp2 
rte-ssn 254"
"ss7subsys1"          001f0004  "MGC-01"              SS7SUBSYS        "ssn 254(800)"
"ss7subsys2"          001f0005  "MGC-01"              SS7SUBSYS        "pc_ssn s
cp1 rte-ssn 254"
   */
Retrieving Data for All Components of a Particular Type

You can retrieve provisioning data on all components of a particular type on your system. To do this, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:component:"all"
Where: component is the MML component type associated with the desired provisioned component group. You can find a complete list of MML component types in the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide.

Note Components that are used to retrieve signaling or routing properties (that is sigsvcprop, lnksetprop, and trnkgrpprop) cannot use this command. The properties for only one signaling or routing component can be listed per command instance. Please use the following format:

prov-rtrv:propComp:name="compName" | name="ss7famName"

Where:

propComp—MML component name appropriate to the property type you want to retrieve, as listed below:

sigsvcprop—Provides maintenance access to the properties of signaling services.
trnkgrpprop—Provides maintenance access to the properties of trunk groups
lnksetprop—Provides maintenance access to the properties of linksets.

compName - MML name of a previously provisioned signaling service or trunk group.
ss7famName - MML name of the SS7 family associated with the desired linkset.

For example, to view the provisioning data for all DPCs, you would enter the following command:
prov-rtrv:dpc:"all"
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 17:16:42
M  RTRV
   "session=active:dpc"
   /*
NAME                  NETADDR      NETIND
----                  -------      ------
dpc2                  2.2.2        2
dpc1                  1.1.1        2
   */
Retrieving Data on the Current Provisioning Session

You can retrieve provisioning data on the current provisioning session. To do this, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:session
The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-06-13 13:39:19
M  RTRV
   "session=jtest:session"
   /*
Session ID = mml1
SRCVER = active
DSTVER = jtest
   */
Retrieving Data on Supported Signaling Protocols

You can retrieve protocol data for the current provisioning session. To do this, log in to the active
Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:variants
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-12 17:18:25
M  RTRV
   "session=active:variants"
   /*
MDO File name         Protocol Family        Switch Type
-------------         --------------        -----------
ANSISS7_CLEAR         SS7-ANSI              20
ANSISS7_MCI           SS7-ANSI              0
ANSISS7_NOATPTX       SS7-ANSI              0
ANSISS7_SPRINT        SS7-ANSI              0
ANSISS7_STANDARD      SS7-ANSI              0
ATT_41459             ISDNPRI               17
ATT_41459_C2          ISDNPRI               17
BELL_1268             ISDNPRI               22
BELL_1268_C3          ISDNPRI               22
BTNUP_BTNR167         SS7-UK                5
BTNUP_IUP             SS7-UK                5
BTNUP_NRC             SS7-UK                5
DPNSS_BTNR188         DPNSS                 26
EISUP                 EISUP                 0
ETS_300_102           ISDNPRI               27
ETS_300_102_C1        ISDNPRI               27
ETS_300_102_C6        ISDNPRI               27
ETS_300_121           SS7-ITU               0
ETS_300_172           ISDNPRI               29
ETS_300_356           SS7-ITU               0
HKTA_2202             SS7-ITU               0
ISUPV1_POLI           SS7-ITU               0
ISUPV2_32DIG          SS7-ITU               0
ISUPV2_CZECH          SS7-ITU               0
ISUPV2_FINNISH96      SS7-ITU               0
ISUPV2_FRENCH         SS7-ITU               0
ISUPV2_GERMAN         SS7-ITU               0
ISUPV2_JAPAN          SS7-Japan             10
ISUPV2_KPNPB          SS7-ITU               0
ISUPV2_NTT            SS7-Japan             0
ISUPV2_SPANISH        SS7-ITU               0
ISUPV2_SWISS          SS7-ITU               0
ISUPV2_TELEFONICA     SS7-ITU               0
ISUPV2_VIETNAM        SS7-ITU               0
ISUPV3_UK             SS7-UK                0
ISUPV3_UK_AXE10       SS7-UK                15
ISUPV3_UK_AXE10_BTNETCHAT  SS7-UK                15
ISUPV3_UK_BTNETCHAT   SS7-UK                0
Q721_BASE             SS7-ITU               5
Q721_BRAZILIAN        SS7-ITU               5
Q721_CHINA            SS7-China             5
Q721_FRENCH           SS7-ITU               5
Q721_PHILLIPINE       SS7-ITU               5
Q761_ARGENTINA        SS7-ITU               0
Q761_ARGENTINA_C2     SS7-ITU               0
Q761_AUSTRL           SS7-ITU               0
Q761_AUSTRL_C2        SS7-ITU               0
Q761_BASE             SS7-ITU               0
Q761_BELG_BCOM        SS7-ITU               0
Q761_BELG_ISUP_CUJO   SS7-ITU               0
Q761_BELG_MOBI        SS7-ITU               0
Q761_CHILE            SS7-ITU               0
Q761_CHINA            SS7-China             0
Q761_CHINA_MOB        SS7-China             0
Q761_CHINA_MOB        SS7-ITU               0
Q761_DANISH           SS7-ITU               0
Q761_INDIA            SS7-ITU               0
Q761_KOREAN           SS7-ITU               0
Q761_NEWZEALAND       SS7-ITU               0
Q761_PERU             SS7-ITU               0
Q761_PORTUGAL         SS7-ITU               0
Q761_SIEMENS_MOBI     SS7-ITU               0
Q761_SINGAPORE        SS7-ITU               0
Q761_TAIWAN           SS7-ITU               0
Q761_THAILAND         SS7-ITU               0
Q767_BASE             SS7-ITU               0
Q767_BRAZIL           SS7-ITU               0
Q767_COLOMBIA         SS7-ITU               0
Q767_GUATEMALA        SS7-ITU               0
Q767_INDONESIA        SS7-ITU               0
Q767_ITAL             SS7-ITU               0
Q767_ITAL_INTERCONNECT  SS7-ITU               0
Q767_MEXICAN          SS7-ITU               0
Q767_RUSS             SS7-ITU               0
Q767_SPAN             SS7-ITU               0
Q767_SWED             SS7-ITU               0
Q767_TELSTRA          SS7-ITU               0
Q767_TURKISH          SS7-ITU               0
T113_BELL             SS7-ANSI              0
dummy                 AVM                   0
dummy                 MGCP                  0
dummy                 TCAPOverIP            0
dummy                 VSI                   0
   */
Provisioning a Dial Plan

You can provision dial plans on your Cisco PGW 2200 Softswitch using the commands listed below. For more information on provisioning and maintaining dial plans, see the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.

•numan-add—Adds an element to a dial plan.

•numan-dlt—Deletes an element from a dial plan.

•numan-ed—Edits an existing element in a dial plan.

•numan-rtrv—Displays information pertaining to an element or all elements in a dial plan.

Note You can verify dial plans using the translation verification viewer on the Cisco MGC toolbar. For information on using the translation verification viewer, see the "Verifying a Dial Plan Translation" section.

Importing Provisioning Data

You can import provisioning data files (created using the prov-exp MML command) and execute the MML commands contained in those files in batch mode to copy the set up from another system, or return a system to a baseline configuration. See the "Exporting Provisioning Data" section for more information on exporting provisioning data.

To import the provisioning data files and execute the MML commands in batch mode, log in to the active Cisco PGW 2200 Softswitch, and enter the following UNIX command:
mml -b export_directory_path/filename
Where:

•export_directory_path—The directory path to the location of the exported provisioning data files.

•filename—The name of the provisioning data file you want to import.

The provisioning data files must be provisioned in the following order:

•config.mml—Contains core configuration data (signaling services, SS7 nodes)

•export_trunks.dat (created only when trunks are configured on your system)

•export_trkgrp.dat (created only when trunk groups are configured on your system)

•routing.mml—Contains routing plans

•custGrpID.mml—One of these files is created for each existing dial plan, with the file being named with the associated customer group ID number.

For example, to import the provisioning data stored in the config.mml file, which is located in the /opt/ CiscoMGC/etc/cust_specific/saved_config directory, you would enter the following command:
mml -b /opt/CiscoMGC/etc/cust_specific/saved_config/config.mml
Exporting Provisioning Data

You can use the prov-exp MML command to export the current provisioning set up of your Cisco PGW 2200 Softswitch in MML-command form to a file or files. This allows you to copy the provisioning data from one Cisco PGW 2200 Softswitch and set up another Cisco PGW 2200 Softswitch with that same provisioning data or to restored a Cisco PGW 2200 Softswitch to a baseline provisioning environment. See "Importing Provisioning Data" section for information on importing the provisioning data created by the prov-exp MML command.

To export part of the current configuration of your Cisco PGW 2200 Softswitch to a file, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-exp:tid:dirname="export_directory_name"
Where:

•tid—Types of data. These can be:

–config—Core configuration data (signaling services, SS7 nodes), including trunks and trunk groups. This selection creates the following files: config.mml, export_trunks.dat (created only when trunks are configured on your system), and export_trkgrp.dat (created only when trunk groups are configured on your system).

–routing—Routing plans. This selection creates a file called routing.mml

–numan—Dial plans. This selection creates a file for each dial plan specified on your system. The file name is dependent on the customer group ID for each dial plan, that is the names of the files follows the format custGrpID.mml.

–trkgrp—Trunk group data only.

–trunk—Trunk data only.

–all—Entire configuration (all data).

•export_directory_name—Name of the directory to which the data is exported. This directory is a subdirectory within the /opt/CiscoMGC/etc/cust_specific directory established at installation.

For example, to export the core configuration data to a file stored in the /opt/CiscoMGC/etc/ cust_specific/saved_config directory, you would enter the following command:
prov-exp:config:dirname="saved_config"
To export all of the current configuration of your Cisco PGW 2200 Softswitch to several files, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-exp:all:dirname="export_directory_name"
Where export_directory_name is the name of the directory to which the data is exported. This directory is a subdirectory within the /opt/CiscoMGC/etc/cust_specific directory established at installation.

The system creates the following files in the specified directory when this command is entered:

•config.mml—Contains core configuration data (signaling services, SS7 nodes)

•export_trunks.dat (created only when trunks are configured on your system)

•export_trkgrp.dat (created only when trunk groups are configured on your system)

•routing.mml—Contains routing plans

•custGrpID.mml—One of these files is created for each existing dial plan, with the file being named with the associated customer group ID number.

•GLBL.awhite—Contains global screening data for A-number white lists. Introduced in Release 9.4(1).

•GLBL.ablack—Contains global screening data for A-number black lists. Introduced in Release 9.4(1).

•GLBLbwhite—Contains global screening data for B-number white lists. Introduced in Release 9.4(1).

•GLBLbblack—Contains global screening data for B-number black lists. Introduced in Release 9.4(1).

For example, to export all of the provisioning data into files stored in the /opt/CiscoMGC/etc/ cust_specific saved_config directory, you would enter the following command:
prov-exp:all:dirname="saved_config"
Managing Automatic Congestion Control

The Cisco PGW 2200 Softswitch supports Automatic Congestion Control (ACC). ACC dynamically regulates incoming traffic on the Cisco PGW 2200 Softswitch to levels that can be handled effectively by rejecting a percentage of new calls when the Cisco PGW 2200 Softswitch is congested. ACC increases the throughput of completed calls through the telephone network during periods of overload.

ACC provides three major functions:

•Rejection of calls to prevent internal congestion—When the Cisco PGW 2200 Softswitch is congested, a user-defined percentage of calls (depending on internal overload level) are rejected and an ISUP release message is sent to the adjacent signaling point. That ISUP release message has a clear cause of Switch Equipment Congestion and contains an Automatic Congestion Level (ACL) value that indicates the overload level of the Cisco PGW 2200 Softswitch. For a call that is in progress when overload occurs and the call clears normally, the ISUP release message has a clear cause of Normal Call Clearing and an ACL value associated with the current overload level of the Cisco PGW 2200 Softswitch.

•Reception and response to congested status—When an adjacent signaling point is congested, the Cisco PGW 2200 Softswitch can reduce the amount of traffic offered by re-routing calls or rejecting a percentage of the calls. This is referred to as outgoing load control (OLC).

•Detection and transmission of congested status—The Cisco PGW 2200 Softswitch can indicate its current level of congestion to adjacent signaling points using SS7 ISUP. Detection of congestion is based on dynamic measurements such as CPU occupancy, sizes of queues and buffers, or amounts of other resources needed for call processing. This is referred to as incoming load control (ILC).

ACC is described in the following sections:

•Managing Call Rejection Percentages

•Managing Outgoing Load Control

•Managing Incoming Load Control

Managing Call Rejection Percentages

ACC enables the Cisco PGW 2200 Softswitch to manage its internal congestion level through the rejection of calls. When call volume causes the Cisco PGW 2200 Softswitch to reach one of its machine congestion levels (MCLs), ACL indications can be sent to the adjacent signaling points and a percentage of the calls, based on your definitions, are released.

The valid values for MCL are shown in Table 3-14.

Table 3-14 Machine Congestion Level Values

Machine Congestion Level

Description

MCO

No congestion present.

MC1

Mild congestion.

MC2

Moderate congestion.

MC3

Severe congestion.

The procedures for managing call rejection percentages can be found in the following sections:

•Modifying the MCL Call Reject Settings

•Retrieving the MCL Call Reject Settings

The Cisco PGW 2200 Softswitch has alarms associated with three of the MCLs. These alarms are issued as the Cisco PGW 2200 Softswitch enters an MCL. These alarms are automatically cleared once the Cisco PGW 2200 Softswitch exits an MCL. Table 3-15 shows which MCLs are associated with which alarms. For more information on these alarms, see the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

Table 3-15 Alarm Associations for MCLs

Machine Congestion Level

Associated Alarm

MC1

OverloadLight

MC2

OverloadMedium

MC3

OverloadHeavy

For example, if, over several CPU timer interval periods, the Cisco PGW 2200 Softswitch were to enter MC1, go up to MC2, and then return to MC1, the alarms would be set or cleared as follows:

1. The OverloadLight alarm is set.

2. The OverloadLight alarm is cleared.

3. The OverloadMedium alarm is set.

4. The OverloadMedium alarm is cleared.

5. The OverloadLight alarm is set.

Note The alarms associated with the Cisco PGW 2200 Softswitch's MCLs create SNMP traps. To identify these alarms among the SNMP traps, look for the tpAlarmCatName object to contain the name of the alarm (OverloadLight, OverloadMedium, or OverloadHeavy) and the tpAlarmSet object to indicate whether the alarm is being set (2) or cleared (1). For more information on the MIBs for the Cisco PGW 2200 Softswitch, see the Cisco PGW 2200 Softswitch Release 9 Management Information Base Guide.

Modifying the MCL Call Reject Settings

To modify the percentage of calls rejected for a particular MCL, perform the following steps:

Note You can also use the Cisco Voice Services Provisioning Tool (VSPT) to make the provisioning changes necessary to modify the MCL call release settings. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify the percentage of calls released for a particular MCL:
prov-ed:mclcallreject:name="mcl_name",callreject=value
Where:

•mcl_name—Name of the MCL level for which you want to modify the call release percentage. The following names are valid:

–mcl1—Specifies the percentage of calls defined in value that are released when the Cisco PGW 2200 Softswitch enters MCL1. The default value is 25.

–mcl2—Specifies the percentage of calls defined in value that are released when the Cisco PGW 2200 Softswitch enters MCL2. The default value is 50.

–mcl3—Specifies the percentage of calls defined in value that are released when the Cisco PGW 2200 Softswitch enters MCL3. The default value is 100.

•value—Percentage of calls that are released. The valid range is 0 through 100.

For example, to modify the percentage of MCL1 such that 30 percent of calls are released when the Cisco PGW 2200 Softswitch meets the conditions necessary to enter MCL1, you would enter the following command:
prov-ed:mclcallreject:name="mcl1",callreject=30
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Retrieving the MCL Call Reject Settings

You can retrieve the settings for one or all of the MCLs on your Cisco PGW 2200 Softswitch. To retrieve the settings for a single MCL, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:mclcallreject:name="mcl_name"
Where: mcl_name—The name of the MCL for which you want settings. The following names are valid:

•mcl1

•mcl2

•mcl3

The system responds with a listing of the call release settings for that MCL.

For example, to retrieve the settings for an MCL called mcl1, you would enter the following command:
prov-rtrv:mclcallreject:name="mcl1"
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2001-02-23 14:13:40
M  RTRV
   "session=accstuff:mclcallreject"
   /* MCLNAME = mcl1
CALLREJECT = 25
   */
To retrieve the settings for every MCL on your system, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:mclcallreject:"all"
The system responds with a listing of the call release settings for each MCL.
MGC-01 - Media Gateway Controller 2001-02-23 14:15:02
M  RTRV
   "session=accstuff:mclcallreject"
   /* 
Name                 CallReject
-------------------- ----------
mcl1                 25
mcl2                 50
mcl3                 100
   */
Managing Outgoing Load Control

Outgoing load control (OLC) regulates outgoing traffic to reduce congestion on other signaling points that provide an ACL indication to the Cisco PGW 2200 Softswitch. Traffic may be re-routed or released instead of being sent to congested signaling points.

There are two types of outgoing load congestion controls:

•Cancel-to (CANT)—Causes a percentage of the traffic that would have been routed to an SS7 signaling path (systems configured for signaling) or trunk group (systems configured for call control) to be rejected due to congestion.

Note The Cisco PGW 2200 Softswitch configured for signaling was formerly called the Cisco SC2200 Signaling Controller. The Cisco PGW 2200 Softswitch configured for call control was formerly called the VSC3000 Virtual Switch Controller. Some documentation for your telephony solution may use these names.

•Skip—Causes a percentage of the traffic that would have routed to a trunk group to overflow to alternate routes. If an alternate route is not available, calls are rejected due to congestion.

Note Skip controls are available only on trunk groups (systems configured for call control).

When applying congestion controls, the CANT control is given precedence over the skip control. Percentages assigned to CANT and skip for each ACL are independent. If both skip and CANT percentages are specified for a trunk group, these percentages are applied independently, based on the number of calls offered to a trunk group. The results are given in Table 3-16.

Table 3-16 CANT and Skip Results Matrix

CANT

Skip

Result

Yes

Yes

CANT

No

Yes

Skip

No

No

None

Yes

No

CANT

Depending on the type of traffic, there can be different CANT and skip percentages.

•Direct routed—This trunk group is the first choice in a list of routes in a priority sequence coming from the adjacent signaling point.

•Alternate routed—This trunk group is an alternate route in a list of routes in priority sequence coming from the adjacent signaling point.

Note The alternate routed control is available only on trunk groups (call control configurations).

The outgoing load congestion controls are configured in sets referred to as ACC response categories (ACCRCs). The ACCRCs attach a label to a set of configuration data for each control that can be reused. Only one ACCRC can be configured per SS7 signaling path (signaling configurations) or trunk group (call control configurations) that supports outgoing traffic. If an ACCRC is not assigned to an SS7 signaling path or trunk group, the default ACC response procedures are performed.

There is an ACCRC field for each control type combination of every ACL indication level (for example, there are three alternate routed skip control fields for ACL 1, 2, and 3: acl1arskip, acl2arskip, and acl3arskip). The Cisco PGW 2200 Softswitch comes configured with a default ACCRC, which cannot be modified. The field values for the default ACCRC are listed below:

•acl1drcant—50

•acl1drskip—20

•acl1arcant—50

•acl1arskip—20

•acl2drcant—90

•acl2drskip—20

•acl2arcant—90

•acl2arskip—20

•acl3drcant—100

•acl3drskip—0

•acl3arcant—100

•acl3arskip—0

Once an ACL indication is received from a adjacent signaling point, the actions defined in the ACCRC are enabled for the amount of time defined in a configurable ACL timer (ACLDur).

The following sections describe how to manage OCL:

•Adding an ACC Response Category on System Configured for Signaling

•Adding an ACC Response Category on a System Configured for Call Control

•Modifying an ACC Response Category on a System Configured for Signaling

•Modifying an ACC Response Category on a System Configured for Call Control

•Deleting an ACC Response Category on a System Configured for Signaling

•Deleting an ACC Response Category on a System Configured for Call Control

•Retrieving ACC Response Category Settings

•Modifying the SS7 Signaling Path Associated with an ACC Response Category

•Modifying the Trunk Group Associated with an ACC Response Category

•Modifying an ACL Timer

Adding an ACC Response Category on System Configured for Signaling

To add an ACCRC on your system when it is configured for signaling, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to add an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to configure the values for an ACCRC:
prov-add:accrespcat:name="cat_name"[,field_name=value,field_name=value...]
Where:

•cat_name—MML name for the ACCRC.

•field_name—ACCRC field that is used to specify a percentage of calls that are released when a congestion indication of a particular ACL level is received from an adjacent signaling point. The following fields can be configured:

–acl1drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 1 is received from an adjacent signaling point.

–acl2drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 2 is received from an adjacent signaling point.

–acl3drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 3 is received from an adjacent signaling point.

•value—Percentage of calls that are released. The valid range is 0 through 100.

Note Any ACCRC field that you do not enter a value for is set to 0.

For example, to configure an ACCRC called cat1 such that 20 percent of calls are rejected when an ACL of 1 is received, 50 percent of calls are rejected when an ACL of 2 is received, and 98 percent of calls are rejected when an ACL of 3 is received, you would enter the following command:
prov-add:accrespact:name="cat1",acl1drcant=20,acl2drcant=50,acl3drcant=98
Step 3 Enter the following command to associate an ACCRC with an SS7 signaling path:
prov-ed:sigsvcprop:name="comp_name",ACCRespCatName="cat_name"
Where:

•comp_name—MML name for the SS7 signaling path to be associated with an ACCRC.

Note If you do not know the MML name of the SS7 signaling path, use the prov-rtrv:ss7path:"all" command to find the name.

•cat_name—MML name for the ACCRC.

For example, to associate an ACCRC called cat1 with an SS7 signaling path named access1, you would enter the following command:
prov-ed:sigsvcprop:name="access1",ACCRespCatName="cat1"
Step 4 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Adding an ACC Response Category on a System Configured for Call Control

To add an ACCRC on your system when it is configured for call control, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to add an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User's Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to configure the values for an ACCRC:
prov-add:accrespcat:name="cat_name"[,field_name=value,field_name=value...]
Where:

•cat_name—MML name for the ACCRC.

•field_name—ACCRC field that is used to specify a percentage of calls that are released when a congestion indication of a particular ACL level is received from an adjacent signaling point. The following fields can be configured:

–acl1drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 1 is received from an adjacent signaling point and this trunk group is configured as a direct route from that signaling point.

–acl1drskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 1 is received from an adjacent signaling point.

–acl1arcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 1 is received from an adjacent signaling point and this trunk group is configured as an alternate route from that signaling point.

–acl1arskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 1 is received from an adjacent signaling point.

–acl2drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 2 is received from an adjacent signaling point and this trunk group is configured as a direct route from that signaling point.

–acl2drskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 2 is received from an adjacent signaling point.

–acl2arcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 2 is received from an adjacent signaling point and this trunk group is configured as an alternate route from that signaling point.

–acl2arskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 2 is received from an adjacent signaling point.

–acl3drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 3 is received from an adjacent signaling point and this trunk group is configured as a direct route from that signaling point.

–acl3drskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 3 is received from an adjacent signaling point.

–acl3arcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 3 is received from an adjacent signaling point and this trunk group is configured as an alternate route from that signaling point.

–acl3arskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 3 is received from an adjacent signaling point.

•value—Percentage of calls that are released. The valid range is 0 through 100.

Note Any ACCRC field that you do not enter a value for is set to 0.

For example, to configure an ACCRC on a trunk group called cat1 such that when an ACL indication of 1 is received, 20 percent of direct routed calls are rejected, 20 percent of direct routed calls are re-routed, 10 percent of alternate routed calls are rejected, and 10 percent of alternate routed calls are re-routed, you would enter the following command:
prov-add:accrespact:name="cat1",acl1drcant=20,acl1drskip=20,acl1arcant=10,acl1arskip=10
Step 3 Enter the following command to associate an ACCRC with a trunk group:
prov-ed:trnkgrpprop:name="comp_name",ACCRespCatName="cat_name"
Where:

•comp_name—MML name for the trunk group on which you want to configure an ACCRC.

Note If you do not know the MML name of the trunk group, use the prov-rtrv:trnkgrp:"all" command to find the name.

•cat_name—MML name for the ACCRC you want to configure.

For example, to create an ACCRC called cat1 on an trunk group named trunk, you would enter the following command:
prov-ed:trnkgrpprop:name="trunk1",ACCRespCatName="cat1"
Step 4 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Modifying an ACC Response Category on a System Configured for Signaling

To modify an ACCRC on your system when it is configured for signaling, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to modify an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User's Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify the configuration of an ACCRC:
prov-ed:accrespcat:name="cat_name"[,field_name=value,field_name=value...]
Where:

•cat_name—MML name for the ACCRC.

•field_name—ACCRC field that is used to specify a percentage of calls that are released when a congestion indication of a particular ACL level is received from an adjacent signaling point. The following fields can be modified:

–acl1drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 1 is received from an adjacent signaling point.

–acl2drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 2 is received from an adjacent signaling point.

–acl3drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 3 is received from an adjacent signaling point.

•value—Percentage of calls that are released. The valid range is 0 through 100.

For example, to modify the configuration of an ACCRC called cat1 such that 30 percent of calls are rejected when an ACL of 1 is received, you would enter the following command:
prov-ed:accrespact:name="cat1",acl1drcant=30
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Modifying an ACC Response Category on a System Configured for Call Control

To modify an ACCRC on your system when it is configured for call control, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to modify an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User's Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify the configuration for an ACCRC:
prov-ed:accrespcat:name="cat_name"[,field_name=value,field_name=value...]
Where:

•cat_name—MML name for the ACCRC.

•field_name—ACCRC field that is used to specify a percentage of calls that are released when a congestion indication of a particular ACL level is received from an adjacent signaling point. The following fields can be modified:

–acl1drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 1 is received from an adjacent signaling point and this trunk group is configured as a direct route from that signaling point.

–acl1drskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 1 is received from an adjacent signaling point.

–acl1arcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 1 is received from an adjacent signaling point and this trunk group is configured as an alternate route from that signaling point.

–acl1arskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 1 is received from an adjacent signaling point.

–acl2drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 2 is received from an adjacent signaling point and this trunk group is configured as a direct route from that signaling point.

–acl2drskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 2 is received from an adjacent signaling point.

–acl2arcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 2 is received from an adjacent signaling point and this trunk group is configured as an alternate route from that signaling point.

–acl2arskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 2 is received from an adjacent signaling point.

–acl3drcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 3 is received from an adjacent signaling point and this trunk group is configured as a direct route from that signaling point.

–acl3drskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 3 is received from an adjacent signaling point.

–acl3arcant—Specifies the percentage of calls defined in value that are released when an ACL indication of 3 is received from an adjacent signaling point and this trunk group is configured as an alternate route from that signaling point.

–acl3arskip—Specifies the percentage of calls defined in value that are re-routed to an alternate trunk group when an ACL indication of 3 is received from an adjacent signaling point.

•value—Percentage of calls that are released. The valid range is 0 through 100.

For example, to modify the configuration an ACCRC on a trunk group called cat1 such that 30 percent of calls are rejected when an ACL of 1 is received, you would enter the following command:
prov-ed:accrespact:name="cat1",acl1drcant=30,acl1arcant=30
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Deleting an ACC Response Category on a System Configured for Signaling

To delete an ACCRC on your system when it is configured for signaling, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to delete an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User's Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Before you can delete an ACCRC, you must delete the associated SS7 signaling path. To do this, enter the following command:
prov-dlt:ss7path:name="comp_name"
Where: comp_name—MML name for the SS7 signaling path you want to delete.

Note If you do not know the MML name of the SS7 signaling path, use the prov-rtrv:ss7path:"all" command to find the name.

For example, to delete an SS7 signaling path named access1, you would enter the following command:
prov-dlt:ss7path:name="access1"
Step 3 Enter the following command to delete an ACCRC:
prov-dlt:accrespcat:name="cat_name"
Where: cat_name—The name of the ACCRC you want to delete.

For example, to delete an ACCRC called cat1, you would enter the following command:
prov-dlt:accrespact:name="cat1"
Step 4 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Deleting an ACC Response Category on a System Configured for Call Control

To delete an ACCRC on your system when it is configured for call control, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to delete an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User's Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Before you can delete an ACCRC, you must delete the associated trunk group. To do this, enter the following command:
prov-dlt:trnkgrp:name="comp_name"
Where: comp_name—MML name for the trunk group you want to delete.

Note If you do not know the MML name of the trunk group, use the prov-rtrv:trnkgrp:"all" command to find the name.

For example, to delete a trunk group named access1, you would enter the following command:
prov-dlt:trnkgrp:name="access1"
Step 3 Enter the following command to delete an ACCRC:
prov-dlt:accrespcat:name="cat_name"
Where: cat_name—The name of the ACCRC you want to delete.

For example, to delete an ACCRC called cat1, you would enter the following command:
prov-dlt:accrespact:name="cat1"
Step 4 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Retrieving ACC Response Category Settings

You can retrieve the settings for one or all of the ACCRCs configured on your Cisco PGW 2200 Softswitch. To retrieve the settings for a single ACCRC, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:accrespcat:name="cat_name"
Where: cat_name—The name of the ACCRC for which you want settings.

The system responds with a listing of the settings for each of the ACCRC fields.

For example, to retrieve the settings for an ACCRC called cat1, you would enter the following command:
prov-rtrv:accrespact:name="cat1"
The system responds with a message similar to the following:
MGC-01 - Media Gateway Controller 2001-02-23 12:23:20
M  RTRV
   "session=jimacc:accrespcat"
   /* NAME  = cat1
ACL1DRCANT = 20
ACL1DRSKIP = 10
ACL1ARCANT = 20
ACL1ARSKIP = 10
ACL2DRCANT = 50
ACL2DRSKIP = 20
ACL2ARCANT = 50
ACL2ARSKIP = 20
ACL3DRCANT = 98
ACL3DRSKIP = 2
ACL3ARCANT = 98
ACL3ARSKIP = 2
   */
To retrieve the settings for every ACCRC on your system, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
prov-rtrv:accrespcat:"all"
The system responds with a message similar to the following.
MGC-01 - Media Gateway Controller 2001-02-23 11:15:32
M  RTRV
   "session=migrated:accrespcat"
   /* 
Name                 Acl1DrCant Acl1DrSkip Acl1ArCant Acl1ArSkip Acl2DrCant Acl2DrSkip 
Acl2ArCant Acl2ArSkip Acl3DrCant Acl3DrSkip Acl3ArCant Acl3ArSkip
-------------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
cat1                 20   10   20   10   50   20   50   20   98   2    98   2    
default              50   20   50   20   90   20   90   20   100  0    100  0    
   */
Modifying the SS7 Signaling Path Associated with an ACC Response Category

To modify the SS7 signaling path associated with an ACCRC on your system when it configured for signaling, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to modify the SS7 signaling path associated with an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify which SS7 signaling path is associated with an ACCRC:
prov-ed:sigsvcprop:name="comp_name",ACCRespCatName="cat_name"
Where:

•comp_name—MML name for the SS7 signaling path to be associated with an ACCRC.

Note If you do not know the MML name of the SS7 signaling path, use the prov-rtrv:ss7path:"all" command to find the name.

•cat_name—MML name for the ACCRC.

For example, to associate an ACCRC called cat1 with an SS7 signaling path named access2, you would enter the following command:
prov-ed:sigsvcprop:name="access2",ACCRespCatName="cat1"
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Modifying the Trunk Group Associated with an ACC Response Category

To modify the trunk group associated with an ACCRC on your system when it is configured for call control, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to modify the trunk group associated with an ACCRC. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify which trunk group is associated with an ACCRC:
prov-ed:trnkgrpprop:name="comp_name",ACCRespCatName="cat_name"
Where:

•comp_name—MML name for the trunk group to be associated with an ACCRC.

Note If you do not know the MML name of the trunk group, use the prov-rtrv:trnkgrp:"all" command to find the name.

•cat_name—MML name for the ACCRC.

For example, to associate an ACCRC called cat1 with an trunk group named trunk2, you would enter the following command:
prov-ed:trnkgrpprop:name="trunk2",ACCRespCatName="cat1"
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Modifying an ACL Timer

When the Cisco PGW 2200 Softswitch receives ACL indication from an adjacent signaling point, it activates the controls specified for that congestion level on the trunk group or SS7 signaling path associated with the release message and starts an ACL timer (ACLDur). The duration of this timer can be configured on a trunk group or SS7 signaling path basis, with a default value of 5 seconds. When the ACL timer expires, the congestion controls on the trunk group or SS7 signaling path are deactivated.

Note Timers may require adjustment depending on the size of your trunk group.

To modifying the settings for the ACL timer associated with a particular trunk group or SS7 signaling path, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to modify the settings for an ACL timer. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify the property that sets the duration of the ACL timer:
prov-ed:component:name="comp_name",ACLDur=num
Where:

•component—MML component type name for the SS7 signaling path or trunk group properties. Depending on the type of system you have, enter one of the following:

–sigsvcprop—Component type for signaling path properties, used to set the ACL timer duration on systems configured for signaling.

–trnkgrprop—Component type for trunk group properties, used to set the ACL timer duration on
systems configured for call control.

•comp_name—MML name for the SS7 signaling path or trunk group on which you are modifying the duration of the ACL timer.

•num—Duration of the ACL timer in seconds. The default value is 5 seconds.

For example, to change the duration of the ACL timer to 20 seconds on a trunk group named trunk1, you would enter the following command:
prov-ed:trnkgrpprop:name="trunk1",ACLDur=20
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Managing Incoming Load Control

Incoming load control (ILC) is used to regulate incoming traffic to reduce congestion on the Cisco PGW 2200 Softswitch when it is overloaded. When the Cisco PGW 2200 Softswitch enters and abates the different MCLs, calls are re-routed or rejected, based on user-defined settings.

Because ITU-based signaling points use a three-level congestion standard, a command is available that maps the MCL values to the ITU congestion standard. No modification is necessary for systems that use the ANSI congestion standard.

The MCLs are determined by the measurement of five threshold values, as listed below:

•Call rate (callrate)—Measures the number of incoming call attempts per second.

•CPU utilization (cpu)—Measures the percentage of CPU utilization.

•Engine input queue length (queuelen)—Measures the number of messages waiting in the call engine input queue.

•Memory address utilization (memoryaddress)—Measures the percentage of how much physical memory address space is in use.

•Virtual memory address utilization (virtualmemory)—Measures the percentage of how much virtual memory address space is in use.

You can configure the onset and abatement settings for each of these threshold values. You can also configure the percentage of calls that are released once the thresholds are met. Table 3-17 lists the default values for the MCL thresholds.

Table 3-17 Default Values for the MCL Thresholds

Threshold

MCL1 Onset

MCL1 Abate

MCL2 Onset

MCL2 Abate

MCL3 Onset

MCL3 Abate

cpu

82

75

90

77

93

85

virtualmemory

80

75

85

80

90

80

memoryaddress

84

80

88

82

93

85

queuelen

75

60

80

70

85

75

callrate

0

0

0

0

0

0

ICL is described in the following sections:

•Mapping Machine Congestion Level to the ANSI or ITU Congestion Standard

•Modifying MCL Threshold Values

•Retrieving MCL Threshold Values

Mapping Machine Congestion Level to the ANSI or ITU Congestion Standard

When the Cisco PGW 2200 Softswitch is overloaded, an ACL value is sent to adjacent signaling points in an ISUP release message based on the MCL. Since ANSI- and ITU-based signaling points have different maximum ACL values, the Cisco PGW 2200 Softswitch uses a property, MaxACL, associated with an SS7 signaling service or trunk group, to map the ACC maximum overload level value to the maximum ACL value used by the adjacent signaling point.

ANSI-based signaling points have a maximum ACL value of 3, ITU-based signaling points have a maximum ACL value of 2, and the ACC maximum overload level value is 3. When MaxACL is set to 3, the maximum MCL value is mapped to the ANSI standard, (the default value for MaxACL is 3). When MaxACL is set to 2, the maximum MCL value is mapped to the ITU standard. MaxACL also has a third possible setting, 0, which disables the sending of ACL indications in the ISUP release message. Table 3-18 shows how the MaxACL settings map the MCL values to the ANSI and ITU congestion standards.

Note Disabling the MaxACL parameter (setting it to `0') does not disable the ACC functionality. If the MaxACL parameter is set to `0' and the Cisco PGW 2200 Softswitch becomes congested, the percentage of calls specified for that overload level are released, and the associated ISUP release message does not contain an ACL indication. The ISUP release message still indicates the proper clear cause.

Note You can also use the Cisco VSPT to make the provisioning changes necessary to map the MCL to the congestion standard used by the adjacent signaling points. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

To map the MCL to the appropriate congestion standard for the associated signaling point, perform the following steps:

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to set the property that maps the MCL to the congestion standard used by the adjacent signaling point:
prov-ed:component:name="comp_name",MaxACL=num
Where:

•component—MML component type name for the SS7 signaling path or trunk group properties. Depending on the type of system you have, enter one of the following:

–sigsvcprop—Component type for signaling paths properties, used to map MCL for systems configured for signaling.

–trnkgrprop—Component type for trunk group properties, used to map MCL for systems configured for call control.

•comp_name—MML name for the SS7 signaling path or trunk group on which you are mapping the MCL to the congestion standard used by the adjacent signaling point.

•num—Number that indicates how to map the MCL values. Table 3-18 lists the valid values for this parameter and their associated congestion levels.

Table 3-18 MCL Mapping Values

MaxACL Value

Congestion Standard

MCL Value

ACL Value in Release Message

0

N/A

MC0 through MC3

ACL is disabled

2

ITU

MC0
MC1
MC2
MC3

ACL is not present
1
2
2

3

ANSI

MC0
MC1
MC2
MC3

ACL is not present
1
2
3

For example, to map the MCL on a trunk group named trunk1 which is adjacent to a signaling point that uses the ITU congestion standard, you would enter the following command:
prov-ed:trnkgrpprop:name="trunk1",MaxACL=2
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Modifying MCL Threshold Values

To modify existing MCL threshold values on your Cisco PGW 2200 Softswitch, perform the following steps:

Note You can also use the Cisco VSPT to make the provisioning changes necessary to modify existing MCL threshold values. For more information on using the Cisco VSPT, see the Cisco Voice Services Provisioning Tool User Guide.

Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to modify existing MCL threshold values:
prov-ed:mclthreshold:name="thres_type"[,field_name=value,field_name=value,...]
Where:

•thresh_type—MML name for the MCL threshold type for which you want to modify values. The following threshold types are valid.

–callrate—Measures the number of incoming call attempts per second.

–cpu—Measures the percentage of CPU utilization.

–queuelen—Measures the number of processes waiting in the call engine input queue.

–memoryaddress—Measures the percentage of how much physical memory address space is in use.

–virtualmemory—Measures the percentage of how much virtual memory address space is in use.

•field_name—MCL threshold field that is used to specify the onset and abatement values for the selected threshold type. The following fields can be configured:

–mcl1onset—Specifies the threshold, as defined in value, at which the Cisco PGW 2200 Softswitch enters MCL1.

–mcl1abate—Specifies the threshold, as defined in value, at which the Cisco PGW 2200 Softswitch abates MCL1.

–mcl2onset—Specifies the threshold, as defined in value, at which the Cisco PGW 2200 Softswitch enters MCL2.

–mcl2abate—Specifies the threshold, as defined in value, at which the Cisco PGW 2200 Softswitch abates MCL2.

–mcl3onset—Specifies the threshold, as defined in value, at which the Cisco PGW 2200 Softswitch enters MCL3.

–mcl3abate—Specifies the threshold, as defined in value, at which the Cisco PGW 2200 Softswitch abates MCL3.

•value—Specifies the threshold value for the specified field. The valid value for fields associated with the cpu, memoryaddress, and virtualmemory threshold types is a percentage, ranging from 0 to 100. The valid value for fields associated with the callrate and queuelen threshold types is any nonnegative integer.

Note Setting the thresholds for any of the fields to 0 disables the all of the MCL settings.

For example, you would enter the following command to modify the MCL threshold values for the cpu threshold type, such that the following values are set:

•MCL1 is reached when CPU utilization reaches 75 percent

•MCL1 abates when CPU utilization reaches 65 percent
prov-add:mclthreshold:name="cpu",mcl1onset=75,mcl1abate=65
Step 3 Save and activate your provisioning changes as described in the "Saving and Activating your Provisioning Changes" section.

Retrieving MCL Threshold Values

You can retrieve the values for one or all of the MCL threshold types configured on your Cisco PGW 2200. To retrieve the settings for a single MCL threshold type, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:
prov-rtrv:mclthreshold:name="thres_type"
Where: thresh_type—MML name for the MCL threshold type. The following threshold types are valid.

•callrate—Measures the number of incoming call attempts per second.

•cpu—Measures the percentage of CPU utilization.

•queuelen—Measures the number of processes waiting in the call engine input queue.

•memoryaddress—Measures the percentage of how much physical memory address space is in use.

•virtualmemory—Measures the percentage of how much virtual memory address space is in use.

The system responds with a listing of the values for each of the fields associated with the MCL threshold type.

For example, to retrieve the values for the queuelen MCL threshold type, you would enter the following command:
prov-rtrv:mclthreshold:name="queuelen"
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2001-02-23 14:09:42
M  RTRV
   "session=accstuff:mclthreshold"
   /* NAME  = queuelen
MCL1ONSET = 75
MCL1ABATE = 60
MCL2ONSET = 80
MCL2ABATE = 70
MCL3ONSET = 85
MCL3ABATE = 75
   */
   ;
To retrieve the values for every MCL threshold type on your system, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:
prov-rtrv:mclthreshold:"all"
The system responds with a listing of the settings for each field for all of the ACCRCs.
MGC-01 - Media Gateway Controller 2001-02-23 14:11:11
M  RTRV
   "session=accstuff:mclthreshold"
   /* 
Name          Mcl1Onset Mcl1Abate Mcl2Onset Mcl2Abate Mcl3Onset Mcl3Abate
------------- --------- --------- --------- --------- --------- ---------
callrate      0         0         0         0         0         0         
cpu           82        75        90        77        95        85        
memoryaddress 84        80        88        82        93        85        
queuelen      75        60        80        70        85        75        
virtualmemory 80        75        85        80        90        80        
   */
Managing your Cisco PGW 2200 Softswitch Platform

The operations you can use to manage your Cisco PGW 2200 Softswitch platform are described in the following sections:

•Performing a Manual Switchover

•Verifying Successful Completion of a Switchover

•Verifying the Patch Level of the Cisco PGW 2200 Softswitch

•Retrieving the Logging Level of Software Processes

•Retrieving the Logging Level of Software Processes

•Retrieving System Statistics

Performing a Manual Switchover

In the continuous service configuration, you can swap the roles of the active Cisco PGW 2200 Softswitch and the standby Cisco PGW 2200 Softswitch by invoking the appropriate MML command from the management interface of the active Cisco PGW 2200 Softswitch. A switchover can be done only from the active Cisco PGW 2200 Softswitch, because only the active Cisco PGW 2200 Softswitch can command the standby Cisco PGW 2200 Softswitch to take over. If there is only one Cisco PGW 2200 Softswitch processing all calls, a manual switchover request is rejected.

Manual switchovers are typically performed for the following reasons:

•To periodically switch the roles of the Cisco PGW 2200 Softswitches

•To upgrade the existing software to a new release

•To bring down a system for hardware maintenance

Caution Performing a manual switchover can severely impact your system's call processing performance. All established calls are retained, but any calls in the process of being setup may be dropped. We recommend that this command be issued during a maintenance window when traffic is minimal.

When you need to order a manual switchover to perform maintenance or upgrade procedures on one or both of the Cisco PGW 2200 Softswitches, use the following steps or all calls might be killed by the call engine. Starting with both the active and standby Cisco PGW 2200 Softswitches operating normally, you can invoke a manual switchover from one system to the other by completing the following steps:

Step 1 Determine whether both the active and standby Cisco PGW 2200 Softswitches are operating normally, as described in the "Verifying the Platform State of the Cisco PGW 2200 Softswitches" section.

Step 2 Determine whether any alarms are pending on either system, as described in the "Monitoring the Alarms Status" section.

If any alarms are pending, you must correct the situation that caused the alarms. Search for the corrective actions required to clear any alarms in the "Alarm Troubleshooting Procedures" section on page 8-4. If the alarms do not appear in that section, corrective action is not required for those alarms. See the Cisco PGW 2200 Softswitch Release 9 Messages Reference for more information on those alarms.

Step 3 Ensure that calls are being replicated from the active Cisco PGW 2200 Softswitch to the standby Cisco PGW 2200 Softswitch, as described in the "Verifying Proper Replication of Calls" section.

Step 4 Enter the following MML command to synchronize the provisioning data on the standby Cisco PGW 2200 with the data on the active Cisco PGW 2200 Softswitch:
prov-sync
Caution Using the prov-sync MML command can severely impact your system's call processing performance. We recommend that this command be issued during a maintenance window when traffic is minimal.

Step 5 Determine platform state of both Cisco PGW 2200 Softswitches, as described in the "Verifying the Platform State of the Cisco PGW 2200 Softswitches" section.

Step 6 Check that all the processes on the active Cisco PGW 2200 Softswitch are in the running state, as described in the "Verifying That Processes Are Running" section.

Caution The next step forces a manual switchover to the standby Cisco PGW 2200 Softswitch. Ensure that the standby Cisco PGW 2200 is fully operational and that debugging is turned off before taking the active Cisco PGW 2200 OOS, or there might be a total interruption of service.

Switchover can also cause call processing to fail if debugging is turned on.

Step 7 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
sw-over::confirm
Warning Switchover operations cause the loss of all SS7 messages transmitted to the Cisco PGW 2200 Softswitch for approximately three seconds. This affects unstable in-progress calls as well as new calls. Stable in-progress calls are not affected.

Site alarms are automatically set until the OOS Cisco PGW 2200 Softswitch is returned to an IS state.

Step 8 Verify that the switchover has been successfully performed. To do this, follow the procedure described in the "Verifying Successful Completion of a Switchover" section.

Verifying Successful Completion of a Switchover

You can determine whether a switchover (automatic or manual) was successfully completed by retrieving the status of each Cisco PGW 2200 Softswitch. Once all of the processes to come up (the time it takes for this to happen depends on the amount of traffic), determine the platform state of both Cisco PGW 2200 Softswitches, as described in the "Verifying the Platform State of the Cisco PGW 2200 Softswitches" section. If the platform state of both Cisco PGW 2200 Softswitches was as expected, the switchover was successfully completed. If one of the Cisco PGW 2200 Softswitches does not return the expected platform state, the switchover was not successfully completed. See the "Recovering from a Switchover Failure" section on page 8-166.

Understanding Switchover

Cisco PGW 2200 Softswitches can be arranged in an Active-Standby configuration in which one Cisco PGW 2200 Softswitch runs active traffic while checkpointing information to the standby Cisco PGW 2200 Softswitch. In the continuous service configuration, the active Cisco PGW 2200 Softswitch is paired with an identical standby Cisco PGW 2200 Softswitch that automatically takes over if a failure or switchover occurs. The continuous service architecture of the Cisco PGW 2200 Softswitch increases the reliability, availability, and failure-aversion capabilities of the system.

The primary goal of the Cisco PGW 2200 Softswitch failover subsystem is call preservation when there is a system failure. This is achieved by interconnecting two Cisco PGW 2200 Softswitches while the system carries out the logical functions of call control. At any point, one Cisco PGW 2200 Softswitch is in the active role and the other Cisco PGW 2200 Softswitch is in the standby role. The active Cisco PGW 2200 Softswitch carries out the call control function and updates the standby Cisco PGW 2200 Softswitch about call-processing events. The standby Cisco PGW 2200 Softswitch maintains the same system state (from the call-processing point of view) as the active Cisco PGW 2200 Softswitch. In the event of a critical failure on the active Cisco PGW 2200 Softswitch, the standby switches to the active role and takes over the call control function. There is a period of approximately three seconds in which all messaging is lost in the process of switching over call control.

Note If your system is using a simplex configuration (a single Cisco PGW 2200 Softswitch), or is functioning in standalone mode (the standby Cisco PGW 2200 Softswitch is in the OOS service state), the system cannot perform a switchover. In these instances, the active Cisco PGW 2200 Softswitch remains in the active service state when a critical failure occurs.

Switchovers can occur automatically (also known as failovers) when a critical alarm is generated, or a switchover can be performed manually, typically as part of a maintenance or troubleshooting procedure. For more information on performing a manual switchover, see the "Performing a Manual Switchover" section.

Note When an automatic switchover is caused by the temporary loss of all Cisco PGW 2200 Softswitch/IP continuity, the newly standby Cisco PGW 2200 can take upwards of 6 minutes to come in-service.

Fault-Tolerant Components

The following component processes of the Cisco PGW 2200 Softswitch are fault-tolerant. In other words, each of these processes knows its own state (Active/Standby/Out-of-Service) and the corresponding state of its peer process on the standby system.

•Process manager (procM)—Spawns and manages all processes in the system

•Failover daemon (foverd)—Determines and switches platform states

•Call engine—Handles call-processing functions

•Replicator—Replicates call states from the active Cisco PGW 2200 Softswitch to the standby Cisco PGW 2200 Softswitch

•I/O channel controller (IOCC)—Manages the signaling messages

•I/O channel manager (IOCM)—Manages the protocol-specific IOCCs

Failover Daemon

The active Cisco PGW 2200 Softswitch runs the procM process. ProcM automatically starts when the Cisco PGW 2200 is booted and, in turn, starts the alarm manager, configuration manager, call engine, IOCCs, and other processes, including foverd.

The continuous service architecture is controlled by the failover daemon. The failover daemons on both Cisco PGW 2200s coordinate the active, standby, and OOS states of those hosts.

The alarm manager process also plays a significant role in a continuous service system. The alarm manager raises the alarm when a critical event occurs and clears the alarm when the condition that caused the alarm is cleared. See the Cisco PGW 2200 Softswitch Release 9 Messages Reference for detailed information regarding alarms, specifically which alarms are critical.

The foverd process directs manual switchovers. The switchover configuration provides the following:

•Minimal interruption of service in the event of failure of a single machine

•Maintenance of a consistent configuration on both the active and standby Cisco PGW 2200 Softswitches

•Avoidance of false switchovers that could cause disruption of service

A critical event is typically a critical process dying or the failure of a subsystem or component that can critically affect call processing. A forced failover occurs automatically when the conditions governing it are met; it is system-initiated and not user-initiated. When a critical event occurs, the alarm manager sends a specific message to the foverd process, indicating the occurrence of the critical event.

When the failover daemon receives notification that a critical event has occurred on the active Cisco PGW 2200, the failover daemon initiates a forced switchover to the standby Cisco PGW 2200. The standby Cisco PGW 2200 transitions immediately to the active state. For approximately three seconds, all messaging is lost. This affects established and new calls.

The occurrence of a critical event on system A results in its peer, system B, becoming active while system A goes to an OOS state. Until the critical event that triggered the failover on system A is cleared, its state remains OOS. When the critical event is cleared, the alarm manager sends another message, known as a Clear Alarm message, to the foverd process. The foverd process drives system A to a standby state (if the peer system (B) is still in the active state).

When the critical event is cleared, the failed Cisco PGW 2200 Softswitch (A) comes back online. It can then become the standby for the currently active Cisco PGW 2200 Softswitch (B). Initially, system A is still OOS. The platform state of system A continues to be OOS until the critical event is cleared.

The Call Engine checkpoints call information from the active Cisco PGW 2200 to the standby Cisco PGW 2200. In addition, the state of the SS7 network is checkpointed by the MTP3 IOCC. The MTP2 terminal functionality resides on the Cisco ITP-Ls to enable the fault-tolerant MTP3 solution.

The Cisco ITP-Ls are responsible for SS7 MTP2 message processing. The Cisco ITP-Ls communicate directly with the Cisco PGW 2200 Softswitch (active and standby) using RUDP, but they send SS7 traffic only to the active Cisco PGW 2200 Softswitch.

Note The number of Cisco ITP-Ls is dependent on the SS7 network traffic load and on link and linkset requirements. It is generally recommended that a minimum of two links per linkset, one link per Cisco ITP-L, be used to provide SS7 reliability. To further enhance redundancy, it is recommended that the links in a linkset be spread across multiple Cisco ITP-Ls so that any single unit can be removed, added, or serviced without disrupting the SS7 network.

Circuit Auditing

An auditing process discovers discrepancies in circuit states between the Cisco PGW 2200 Softswitch and the media gateways it controls. During a switchover, discrepancies might exist as to the state of bearer circuits (CICs) between the newly active Cisco PGW 2200 Softswitch and the bearer devices it controls. Discrepancies in circuit states between the active Cisco PGW 2200 Softswitch and the bearer devices could also occur as the result of control messages to the bearer devices that get lost.

The circuit auditing mechanism can be run periodically at configured intervals or after an automatic or manual switchover. It can also be initiated manually using the MML command, sw-over::confirm. The audit capability is always initiated automatically on indication of critical error conditions from solution components, adjacent SS7 switches, or when critical Cisco PGW 2200 Softswitch conditions occur. The circuit-auditing mechanism detects and resolves circuit state discrepancies that it discovers and resynchronizes the Cisco PGW 2200 and the bearer devices.

The circuit auditing mechanism is a function of the call engine process in the active Cisco PGW 2200 Softswitch. The call engine subsystem starts a thread to perform the circuit-auditing function upon notification of a switchover event from the fault manager.

The circuit auditing mechanism commands the bearer devices to reflect the circuit state of the Cisco PGW 2200 Softswitch. If a bearer device believes the circuit to be in use and the Cisco PGW 2200 Softswitch does not, the Cisco PGW 2200 releases the circuit. However, if the Cisco PGW 2200 Softswitch shows that a bearer circuit is in use and discovers that the bearer device does not show that circuit as in use, the Cisco PGW 2200 Softswitch does not attempt to rebuild the call, but releases all associated resources. Even though the Cisco PGW 2200 Softswitch is the controlling authority, the only course of action when a discrepancy is discovered during a circuit audit is to release all of the allocated resources, which means dropping the call.

Checkpointing

Checkpointing of calls ensures that established calls are preserved in the event of a switchover. The Call Engine sends checkpoint events to the local checkpoint process at one point during call setup and at one point in the call release phase.

Checkpointing is also applied to the following protocol supervisory messages and MML commands that change the logical state of the bearer circuits:

•Blocking and Unblocking Messages and Commands

•Circuit Reset Messages and Commands

The local checkpointing process is responsible for securing these events to disk if the standby Cisco PGW 2200 is unavailable and for forwarding those events to the remote checkpointing process once it does become available. If the standby Cisco PGW 2200 Softswitch is running, checkpoint events are batched and forwarded to the remote checkpointing process.

The remote checkpointing process is responsible for handling the checkpoint events from the active Cisco PGW 2200 Softswitch, delivering only established calls to the remote call engine. The remote call engine process begins checkpointing events for calls when it begins active call processing.

The following scenarios are supported:

•Standalone (no standby Cisco PGW 2200 Softswitch available)—You can specify the activation or deactivation of checkpointing. If checkpointing is activated, all checkpoint events are secured to disk.

•Startup (standby Cisco PGW 2200 Softswitch unavailable)—The local checkpointing process retains or secures all events until the standby Cisco PGW 2200 Softswitch is available and a request for synchronization is completed.

•Synchronization—You can request synchronization of the configurations of the two Cisco PGW 2200s. This is required after startup and transition from the standalone Cisco PGW 2200 Softswitch to the standby available configuration.

•Switchover—In the event of a switchover (or failover), the standby Cisco PGW 2200 Softswitch assumes the primary responsibility for processing calls and securing checkpoint events.

Checkpointing is also implemented to support forward Cisco PGW 2200 Softswitch software migration by one release. You can manually take the standby Cisco PGW 2200 Softswitch out of service, upgrade the software to the new release, and resynchronize calls with the active Cisco PGW 2200 Softswitch. For detailed procedures on upgrading the Cisco PGW 2200 Softswitch software, see the Cisco PGW 2200 Softswitch Release 9.8 Software Installation and Configuration Guide.

Verifying the Patch Level of the Cisco PGW 2200 Softswitch

As of Release 9.2 of the Cisco PGW 2200 Softswitch software, you can verify the patch level of your Cisco PGW 2200 Softswitch software by performing the following steps:

Step 1 Display the current patch level of your system by logging into the active Cisco PGW 2200 Softswitch as root and entering the following UNIX command:
pkginfo | grep Patch
The system returns a response similar to the following:
application CSCOgp003      Cisco Media Gateway Controller Software Patch Package
application CSCOgp009      Cisco Media Gateway Controller Software Patch Package
application CSCOgs003      Cisco Media Gateway Controller Software Patch Package
system      SUNWswmt       Patch Utilities
Look for the Cisco PGW 2200 Softswitch patch with the largest number to determine the current patch level. In the example, the current protocol patch level is patch 9 (CSCOgp009), while the system patch level is patch 3 (CSCOgs003).

Note For more information on the patches to the release of the Cisco PGW 2200 Softswitch software you are running, see the release notes associated with your release. To determine which release of the Cisco PGW 2200 Softswitch software you are running, enter the rtrv-ne MML command, as described in the "Verifying the Platform State of the Cisco PGW 2200 Softswitches" section.

Step 2 Determine the patches available for your version of Cisco PGW 2200 Softswitch software by entering the following URL on an Internet browser:

http://www.cisco.com/public/sw-center/sw-voice.shmtl

Select your software version from the list and a list of currently available patches displays.

If you find that your patch level matches the current patch level on the web page, the procedure is complete. Otherwise, proceed to Step 3.

Step 3 Download the latest patches and associated installation instruction files to your active Cisco PGW 2200 Softswitch.

Step 4 Open the instruction files and follow the procedures within to install the patches.

Step 5 Once you have installed the new patches, run the check inventory utility to ensure that the patches have installed correctly by entering the following UNIX commands:

Caution This utility should not be run while the system is actively processing calls, as it can reduce the call processing rate.

Note This utility can only be run by a user with root permissions. If you are not logged in as root, you must enter the UNIX command sudo before the utility name to ensure proper execution.
cd /opt/CiscoMGC/bin
chk_inv [>file_path]
Note You must be in the /opt/CiscoMGC/bin directory to run the check inventory utility.

Where file_path is an optional parameter used when you want to redirect the output of the utility to a file. If you do not redirect the output to a file, the results are written to your screen.

For example, to redirect the results of the check inventory utility to a file called inv.out, you would enter the following command:
chk_inv >/opt/CiscoMGC/local/inv.out
Step 6 Review the utility results, either on-screen or by opening the file. If the results indicate that there are no problems with the installation, the procedure is complete. Otherwise, proceed to Step 7.

Caution The check inventory utility uses a 32-bit cyclic redundancy check (CRC) to verify your system's software. A 32-bit CRC can have a value anywhere from 1 to over 4 billion. However, there is a slight possibility that two sets of data can have the same CRC value. If this should occur, you will receive a false positive from the utility.

Note If the utility results indicate that there is a problem with a part of the software outside of the Cisco PGW 2200 Softswitch software patch(es), you should determine whether a problem truly exists. The utility compares the software on your system against a master list, and it is possible that your environment may not be using every piece of software on that master list. If the utility indicates that a piece of software is missing, and your system configuration does not use that software, you do not need to load that software. However, if the utility identifies a problem with other software, and your system is using that software, proceed to Step 8.

Step 7 Re-install the patch(es), repeating steps 3 through 6. If your second attempt at downloading and installing the patch(es) succeeds, the procedure is complete. Otherwise, proceed to Step 8.

Step 8 Collect system data as described in the "Collecting System Data for Cisco TAC" section on page 8-87 and contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xx.

Retrieving the Logging Level of Software Processes

You can use the rtrv-log MML command to retrieve the current logging level of a single process or of all of the processes. For more information on processes, see "Understanding Processes" section.

To retrieve the current logging level of a single process, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-log:process
Where process is the MML name of the desired process. For a list of valid process names, see the "Understanding Processes" section.

For example, to retrieve the current logging level of the call engine process (eng-01), you would enter the following command:
rtrv-log:eng-01
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2000-01-16 09:38:03
M  RTRV
   "ENG-01:INFO"
To retrieve the current logging level of all of the processes, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-log:all
The system returns a response similar to the following:
Media Gateway Controller  - MGC-01 2000-01-16 09:38:03
M  RTRV
   "ENG-01:INFO"
Note The process manager (PM-01) is not included in the "all" parameter, because this is a special process. To retrieve the logging level of PM-01, it must be used individually, as in the example above.

Retrieving System Statistics

You can retrieve various system statistics for the Cisco PGW 2200 Softswitch using the MML command, rtrv-ne-health, and its subcommands. The system statistics are described in the following paragraphs:

•Retrieving System State and Alarm Statistics

•Retrieving Calling Statistics

•Retrieving System Usage Statistics

Retrieving System State and Alarm Statistics

To display the platform state and alarm statistics, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-ne-health::sys
The system returns a message similar to the following:
Media Gateway Controller 2000-06-07 16:39:41
M  RTRV
   "Platform State:ACTIVE"
   "2 critical, 4 major, 8 minor active alarms"
If the platform state is not the value you expected, enter the same command on the other Cisco PGW 2200 Softswitch to determine if it is the active Cisco PGW 2200 Softswitch. If the other Cisco PGW 2200 Softswitch is also not the active Cisco PGW 2200 Softswitch, contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

If you find that alarms are active, you can determine the current alarms using the procedure in the "Retrieving All Active Alarms" section on page 8-3.

Retrieving Calling Statistics

Enter the following MML command on the active Cisco PGW 2200 Softswitch to display the machine congestion level, calls in progress, CPU utilization, and call success and failure statistics:
rtrv-ne-health::callp
The system returns a message similar to the following:
   MGC-01 - Media Gateway Controller 2008-10-08 01:33:20.530 EDT
M  COMPLD
   "Platform State:ACTIVE"
   "0 critical, 0 major, 0 minor active alarms"
   "Machine Congestion Level = MCL 0 (No Congestion), Reason: not applicable"
   "Current in progress calls = 0, half calls = 0, full calls = 0, call attempts= 0 cps"
   "CPU 0 Utilization = 0 % CPU 1 Utilization = 0 %"
   "Memory (KB): 5131609 Free virtual, 5872025 Total virtual, 2097152 Total real, 0 Total 
Dial Plan"
   "Interval (minutes)           15      60      1440"
   "CALL: SuccCall TOT           0       0       0"
   "CALL: FailCall TOT           0       0       0"
   "CALL: SIPLicRej TOT          0       0       0"
   "CALL: H323LicRej TOT         0       0       0"
   "CALL: TDMLicRej TOT          0       0       0"
   "CALL: TimesTenLicRej TOT     0       0       0"
   ;
Note In a particular instance, the number of in-progress calls does not reflect the actual number of active calls. When an E1 link in a PBX comes up, CRMs are sent to the PBX for each channel to ensure that there are no active calls present in the PBX. This is done to ensure that synchronization can be maintained after a link failure on the IP side. These CRMs are treated as active calls, therefore increasing the number of in-progress calls returned by this command.

If a large amount of CPU resources are being used over an extended period of time, you should contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

Retrieving System Usage Statistics

Enter the following MML command on the active Cisco PGW 2200 Softswitch to display the processor, memory, and file system usage statistics:
rtrv-ne-health::load
The system returns a message similar to the following:
   MGC-01 - Media Gateway Controller 2008-10-08 01:41:25.179 EDT
M  COMPLD
   "Platform State:ACTIVE"
   "0 critical, 0 major, 0 minor active alarms"
   "Machine Congestion Level = MCL 0 (No Congestion), Reason: not applicable"
   "Current in progress calls = 0, half calls = 0, full calls = 0, call attempts= 0 cps"
   "CPU 0 Utilization = 0 % CPU 1 Utilization = 0 %"
   "Memory (KB): 5131609 Free virtual, 5872025 Total virtual, 2097152 Total real, 0 Total 
Dial Plan"
   "Filesystem            kbytes    used   avail capacity  Mounted on"
   "/dev/md/dsk/d3       1988623  500185 1428780    26%    /"
   "/dev/md/dsk/d12      57440581 9876786 46989390    18%    /opt"
   ;
Note In a particular instance, the number of in-progress calls does not reflect the actual number of active calls. When an E1 link in a PBX comes up, CRMs are sent to the PBX for each channel to ensure that there are no active calls present in the PBX. This is done to ensure that synchronization can be maintained after a link failure on the IP side. These CRMs are treated as active calls, therefore increasing the number of in-progress calls returned by this command.

If a large amount of CPU resources are being used over an extended period of time, you should contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xx for more information on contacting the Cisco TAC.

If the response to the command indicates a percentage of disk space capacity used 90 percent or higher, you must delete files from your disk drive, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section on page 8-165.

Managing System Measurements

The operations you can use to manage the Cisco PGW 2200 Softswitch system measurements are described in the following sections:

•Retrieving Measurements

•Clearing Measurements

•Retrieving Link or Linkset Measurements

•Retrieving SS7 Signaling Point Measurements

•Retrieving Measurement Thresholds

•Modifying Measurement Thresholds

Retrieving Measurements

You can view and search the measurements results stored in the measurements log file using the measurement viewer included in the Cisco MGC viewer toolkit. For more information on viewing and searching measurement log files, see the "Viewing and Searching System Measurement Files" section. For more information on log files, see Appendix A, "Configuring Cisco PGW 2200 Softswitch Log Files.".

Each measurement (or counter) is uniquely defined by its measurement category and component identification number. You can retrieve individual measurements using the following MML command from the active Cisco PGW 2200 Softswitch:
rtrv-ctr:comp:"meas_cat"
Where:

•comp—The MML name of the component. A complete list of components can be found in the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide. You can retrieve a list of select provisioned components by entering the prov-rtrv:all MML command.

•meas_cat—The desired measurement category. A complete list of measurement categories can be found in Appendix D, "Cisco PGW 2200 Softswitch Measurements."

For example, to view the ISUP IAM transmission measurement totals for a component called dpc1, enter the following MML command:
rtrv-ctr:dpc1:"ISUP: XMIT IAM TOT"
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2000-07-11 10:15:50
M  RTRV
   "dpc1:CAT=\"ISUP: XMIT IAM TOT\",INT=300,VAL=353"
   "dpc1:CAT=\"ISUP: XMIT IAM TOT\",INT=1800,VAL=2501"
Clearing Measurements

Each measurement (or counter) is uniquely defined by its measurement category and component identification number. You can retrieve individual measurements using the following MML command from the active Cisco PGW 2200 Softswitch:
clr-ctr:comp:"meas_cat"
Where:

•comp—The MML name of the component. A complete list of components can be found in the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide. You can retrieve a list of selected provisioned components by entering the prov-rtrv:all MML command.

•meas_cat—The desired measurement category. A complete list of measurement categories can be found in Appendix D, "Cisco PGW 2200 Softswitch Measurements."

For example, to clear the ISUP IAM transmission measurement totals for a component called dpc1, enter the following MML command:
clr-ctr:dpc1:"ISUP: XMIT IAM TOT"
Retrieving Link or Linkset Measurements

You can use the rtrv-lnk-ctr MML command to retrieve the system measurements for a single link, all the links in a linkset, or all links. For a complete list of system measurements, see Appendix D, "Cisco PGW 2200 Softswitch Measurements."

To retrieve a list of system measurements for a single link, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-lnk-ctr:link
Where link is the MML name of the SS7 link.

For example, to view the measurements for a link called ls1link1, you would enter the following command:
rtrv-lnk-ctr:ls1link1
The system returns a response similar to the following:
MGC-03 - Media Gateway Controller 2000-08-22 16:32:23
M  RTRV
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=86400,VAL=0"
"ls1link1:CAT=\"SC: XMIT FRM TOT\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: XMIT FRM TOT\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: XMIT FRM TOT\",INT=86400,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD TOT\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD TOT\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD TOT\",INT=86400,VAL=0"
"ls1link1:CAT=\"C7LNK: MSU DROP-CONG\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: DUR UNAVAIL\",INT=1800,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD CRC\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD CRC\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD CRC\",INT=86400,VAL=0"
"ls1link1:CAT=\"C7LNK: DUR IS\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: RCV SIO TOT\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: XMIT SIO TOT\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: RCV SU ERR\",INT=1800,VAL=0"
To retrieve a list of system measurements for the links that make up a linkset, log in to the active
Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-lnk-ctr:linkset
Where linkset is the MML name of the SS7 linkset.

For example, to view the measurements for each link within a linkset called ls1, you would enter the following command:
rtrv-lnk-ctr:ls1link1
The system returns a response similar to the following:
MGC-03 - Media Gateway Controller 2000-08-22 16:32:23
M  RTRV
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=86400,VAL=0"
"ls1link1:CAT=\"SC: XMIT FRM TOT\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: XMIT FRM TOT\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: XMIT FRM TOT\",INT=86400,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD TOT\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD TOT\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD TOT\",INT=86400,VAL=0"
"ls1link1:CAT=\"C7LNK: MSU DROP-CONG\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: DUR UNAVAIL\",INT=1800,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD CRC\",INT=900,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD CRC\",INT=3600,VAL=0"
"ls1link1:CAT=\"SC: RCV BAD CRC\",INT=86400,VAL=0"
"ls1link1:CAT=\"C7LNK: DUR IS\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: RCV SIO TOT\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: XMIT SIO TOT\",INT=1800,VAL=0"
"ls1link1:CAT=\"C7LNK: RCV SU ERR\",INT=1800,VAL=0"
"ls1link2:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: RCV FRM TOT\",INT=3600,VAL=0"
"ls1link2:CAT=\"SC: RCV FRM TOT\",INT=86400,VAL=0"
"ls1link2:CAT=\"SC: XMIT FRM TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: XMIT FRM TOT\",INT=3600,VAL=0"
"ls1link2:CAT=\"SC: XMIT FRM TOT\",INT=86400,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD TOT\",INT=3600,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD TOT\",INT=86400,VAL=0"
"ls1link2:CAT=\"C7LNK: MSU DROP-CONG\",INT=1800,VAL=0"
"ls1link2:CAT=\"C7LNK: DUR UNAVAIL\",INT=1800,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD CRC\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD CRC\",INT=3600,VAL=0"
"ls1link2 CAT=\"SC: RCV BAD CRC\",INT=86400,VAL=0"
"ls1link2:CAT=\"C7LNK: DUR IS\",INT=1800,VAL=0"
"ls1link2:CAT=\"C7LNK: RCV SIO TOT\",INT=1800,VAL=0"
"ls1link2:CAT=\"C7LNK: XMIT SIO TOT\",INT=1800,VAL=0"
"ls1link2:CAT=\"C7LNK: RCV SU ERR\",INT=1800,VAL=0"
To retrieve a list of system measurements for all the links on your Cisco PGW 2200 Softswitch, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-lnk-ctr:all
The system returns a response similar to the following:
MGC-03 - Media Gateway Controller 2000-08-22 16:32:23
M  RTRV
"ls1link1:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: RCV FRM TOT\",INT=3600,VAL=0"
"ls1link2:CAT=\"SC: RCV FRM TOT\",INT=86400,VAL=0"
"ls1link2:CAT=\"SC: XMIT FRM TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: XMIT FRM TOT\",INT=3600,VAL=0"
"ls1link2:CAT=\"SC: XMIT FRM TOT\",INT=86400,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD TOT\",INT=900,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD TOT\",INT=3600,VAL=0"
"ls1link2:CAT=\"SC: RCV BAD TOT\",INT=86400,VAL=0"
"ls2link1:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls2link1:CAT=\"SC: RCV FRM TOT\",INT=3600,VAL=0"
"ls2link1:CAT=\"SC: RCV FRM TOT\",INT=86400,VAL=0"
"ls2link1:CAT=\"SC: XMIT FRM TOT\",INT=900,VAL=0"
"ls2link1:CAT=\"SC: XMIT FRM TOT\",INT=3600,VAL=0"
"ls2link1:CAT=\"SC: XMIT FRM TOT\",INT=86400,VAL=0"
"ls2link1:CAT=\"C7LNK: RCV SU ERR\",INT=1800,VAL=0"
"ls2link2:CAT=\"SC: RCV FRM TOT\",INT=900,VAL=0"
"ls2link2:CAT=\"SC: RCV FRM TOT\",INT=3600,VAL=0"
"ls2link2:CAT=\"SC: RCV FRM TOT\",INT=86400,VAL=0"
"ls2link2:CAT=\"SC: XMIT FRM TOT\",INT=900,VAL=0"
"ls2link2:CAT=\"SC: XMIT FRM TOT\",INT=3600,VAL=0"
"ls2link2:CAT=\"SC: XMIT FRM TOT\",INT=86400,VAL=0"
"ls2link2:CAT=\"SC: RCV BAD TOT\",INT=900,VAL=0"
"ls2link2:CAT=\"SC: RCV BAD TOT\",INT=3600,VAL=0"
Retrieving SS7 Signaling Point Measurements

You can use the rtrv-sp-ctr MML command to retrieve the system measurements for a single SS7 signaling point or for all SS7 signaling points. For a complete list of system measurements, see Appendix D, "Cisco PGW 2200 Softswitch Measurements."

To retrieve a list of system measurements for a single SS7 signaling point, log in to the active
Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-sp-ctr:point_code
Where point_code is the MML name of the SS7 signaling point.

For example, to view the measurements for a point code called dpc2, you would enter the following command:
rtrv-sp-ctr:dpc2
The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-06-13 14:08:39
M  RTRV
   "dpc2:CAT=\"ISUP: XMIT BLA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT BLA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: CHAN MATE UNAVAILABLE\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: CHAN MATE UNAVAILABLE\",INT=1800,VAL=0"
   "dpc2:CAT=\"SP: cInit out\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: cInit out\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: cInit out\",INT=86400,VAL=8"
   "dpc2:CAT=\"SP: PDU in\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: PDU in\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: PDU in\",INT=86400,VAL=50"
   "dpc2:CAT=\"ISUP: XMIT CGB TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGB TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CQM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CQM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV LPA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV LPA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RSC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RSC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ACM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ACM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CCR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CCR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: UNEX MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: UNEX MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT IAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT IAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV IAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV IAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: UNREC MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: UNREC MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CFN TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CFN TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CCR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CCR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ANM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ANM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT COT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT COT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ANM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ANM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV COT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV COT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT BLO TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT BLO TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: ABN REL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: ABN REL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT REL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT REL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGU TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGU TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT SUS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT SUS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV SUS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV SUS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FOT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FOT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CFN TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CFN TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT LPA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT LPA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FAC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FAC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FAC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FAC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGUA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGUA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT USR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT USR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGUA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGUA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV USR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV USR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ACM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ACM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FOT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FOT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT PAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT PAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGB TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGB TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RLC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RLC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV REL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV REL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RLC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RLC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"C7SP: SP DUR UNAVAIL\",INT=300,VAL=0"
   "dpc2:CAT=\"C7SP: SP DUR UNAVAIL\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UCIC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UCIC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"C7SP: XMIT MSU DROP/RTE\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RSC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RSC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RES TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RES TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UCIC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UCIC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RES TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RES TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV PAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV PAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT EXM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT EXM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGU TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGU TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV EXM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV EXM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INF TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INF TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INF TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INF TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLO TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLO TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"SP: cInit in\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: cInit in\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: cInit in\",INT=86400,VAL=17"
   "dpc2:CAT=\"ISUP: XMIT CPG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CPG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"SP: PDU out\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: PDU out\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: PDU out\",INT=86400,VAL=99"
   "dpc2:CAT=\"ISUP: RCV CQR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CQR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CPG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CPG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRA TOT\",INT=1800,VAL=0"
To retrieve a list of system measurements for all the SS7 signaling points on your Cisco PGW 2200 Softswitch, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
rtrv-sp-ctr:all
The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-06-13 14:08:39
M  RTRV
   "opc2"
   /* No active counters found for this component/category */
   "dpc2:CAT=\"ISUP: XMIT BLA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT BLA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: CHAN MATE UNAVAILABLE\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: CHAN MATE UNAVAILABLE\",INT=1800,VAL=0"
   "dpc2:CAT=\"SP: cInit out\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: cInit out\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: cInit out\",INT=86400,VAL=8"
   "dpc2:CAT=\"SP: PDU in\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: PDU in\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: PDU in\",INT=86400,VAL=50"
   "dpc2:CAT=\"ISUP: XMIT CGB TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGB TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CQM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CQM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV LPA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV LPA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RSC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RSC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ACM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ACM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CCR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CCR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: UNEX MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: UNEX MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT IAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT IAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV IAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV IAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: UNREC MSG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: UNREC MSG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CFN TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CFN TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CCR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CCR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ANM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT ANM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT COT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT COT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ANM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ANM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV COT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV COT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT BLO TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT BLO TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: ABN REL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: ABN REL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT REL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT REL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGU TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGU TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT SUS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT SUS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CVT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV SUS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV SUS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FOT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FOT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CFN TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CFN TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UBL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CVT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT LPA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT LPA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FAC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FAC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FAC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV FAC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGUA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGUA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UBL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT USR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT USR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGUA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGUA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV USR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV USR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ACM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV ACM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FOT TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT FOT TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT PAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT PAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGB TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGB TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RLC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RLC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV REL TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV REL TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RLC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RLC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"C7SP: SP DUR UNAVAIL\",INT=300,VAL=0"
   "dpc2:CAT=\"C7SP: SP DUR UNAVAIL\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UCIC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV UCIC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGBA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CGBA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"C7SP: XMIT MSU DROP/RTE\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRS TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT GRS TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RSC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RSC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RES TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT RES TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UCIC TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT UCIC TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RES TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV RES TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV PAM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV PAM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV GRA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT EXM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT EXM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGU TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CGU TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV EXM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV EXM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INF TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INF TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQM TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CQM TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INF TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV INF TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLO TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV BLO TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"SP: cInit in\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: cInit in\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: cInit in\",INT=86400,VAL=17"
   "dpc2:CAT=\"ISUP: XMIT CPG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CPG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"SP: PDU out\",INT=900,VAL=0"
   "dpc2:CAT=\"SP: PDU out\",INT=3600,VAL=0"
   "dpc2:CAT=\"SP: PDU out\",INT=86400,VAL=99"
   "dpc2:CAT=\"ISUP: RCV CQR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CQR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT CRA TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CPG TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CPG TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INR TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: XMIT INR TOT\",INT=1800,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRA TOT\",INT=300,VAL=0"
   "dpc2:CAT=\"ISUP: RCV CRA TOT\",INT=1800,VAL=0"
   "opc1"
   /* No active counters found for this component/category */
   "dpc1:CAT=\"ISUP: XMIT BLA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT BLA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: CHAN MATE UNAVAILABLE\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: CHAN MATE UNAVAILABLE\",INT=1800,VAL=0"
   "dpc1:CAT=\"SP: cInit out\",INT=900,VAL=0"
   "dpc1:CAT=\"SP: cInit out\",INT=3600,VAL=0"
   "dpc1:CAT=\"SP: cInit out\",INT=86400,VAL=1"
   "dpc1:CAT=\"SP: PDU in\",INT=900,VAL=0"
   "dpc1:CAT=\"SP: PDU in\",INT=3600,VAL=0"
   "dpc1:CAT=\"SP: PDU in\",INT=86400,VAL=13"
   "dpc1:CAT=\"ISUP: XMIT CGB TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGB TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV BLA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV BLA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CQR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CQR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CQM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CQM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CVR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CVR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV LPA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV LPA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT RSC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT RSC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT ACM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT ACM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT UBA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT UBA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT MSG TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT MSG TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CCR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CCR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV UBA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV UBA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV MSG TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV MSG TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: UNEX MSG TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: UNEX MSG TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT IAM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT IAM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: UNREC MSG TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: UNREC MSG TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV IAM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV IAM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CFN TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CFN TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CCR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CCR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT ANM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT ANM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT COT TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT COT TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV ANM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV ANM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV INR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV INR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV COT TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV COT TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT BLO TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT BLO TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: ABN REL TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: ABN REL TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT REL TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT REL TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CVR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CVR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGU TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGU TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT SUS TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT SUS TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CVT TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CVT TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT GRA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT GRA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV SUS TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV SUS TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV FOT TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV FOT TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV GRS TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV GRS TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CFN TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CFN TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT UBL TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT UBL TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CVT TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CVT TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT LPA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT LPA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT FAC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT FAC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV FAC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV FAC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGUA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGUA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV UBL TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV UBL TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT USR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT USR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGUA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGUA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV USR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV USR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV ACM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV ACM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT FOT TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT FOT TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT PAM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT PAM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGB TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGB TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV RLC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV RLC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV REL TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV REL TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CRM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CRM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGBA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGBA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT RLC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT RLC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"C7SP: SP DUR UNAVAIL\",INT=300,VAL=0"
   "dpc1:CAT=\"C7SP: SP DUR UNAVAIL\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CRM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CRM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV UCIC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV UCIC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGBA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CGBA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"C7SP: XMIT MSU DROP/RTE\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT GRS TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT GRS TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV RSC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV RSC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT RES TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT RES TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT UCIC TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT UCIC TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV RES TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV RES TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV PAM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV PAM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV GRA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV GRA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT EXM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT EXM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGU TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CGU TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV EXM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV EXM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT INF TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT INF TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CQM TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CQM TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV INF TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV INF TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"SP: cInit in\",INT=900,VAL=0"
   "dpc1:CAT=\"SP: cInit in\",INT=3600,VAL=0"
   "dpc1:CAT=\"SP: cInit in\",INT=86400,VAL=5"
   "dpc1:CAT=\"ISUP: RCV BLO TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV BLO TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CPG TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CPG TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"SP: PDU out\",INT=900,VAL=0"
   "dpc1:CAT=\"SP: PDU out\",INT=3600,VAL=0"
   "dpc1:CAT=\"SP: PDU out\",INT=86400,VAL=19"
   "dpc1:CAT=\"ISUP: RCV CQR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CQR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CRA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT CRA TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CPG TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CPG TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT INR TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: XMIT INR TOT\",INT=1800,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CRA TOT\",INT=300,VAL=0"
   "dpc1:CAT=\"ISUP: RCV CRA TOT\",INT=1800,VAL=0"
Retrieving Measurement Thresholds

Each measurement has a profile that contains information concerning the time intervals, or thresholds, for reporting measurements. A profile can have unique thresholds set for 15-minute, 60-minute, and 24-hour intervals. Thus, each measurement can have up to three thresholds in its profile.

To retrieve the thresholds for a particular measurement, enter the following MML command:
rtrv-thres::"meas_cat"
Where meas_cat is the desired measurement category.

For example, to display the threshold settings for the measurement category, SIP: RETX MSG TOT, you would enter the following MML command:
rtrv-thres::"SIP: RETX MSG TOT"
Text similar to the following is displayed:
   MGC-01 - Media Gateway Controller 2008-10-24 01:40:57.770 EDT
M  RTRV
   "SIP: RETX MSG TOT"
   ":INT=1800,"
   ":type=upper,clrthres=100,almthres=125,alarmcat=\"SIP: RE-XMIT MSG TOT\""
   ;
The INT field lists the thresholds for the 15-minute (900 seconds), 60-minute (3600 seconds) and 24-hour (86400 seconds) intervals. The type field identifies the threshold type, in this case, upper. The type field has two possible values, upper or down. Upper indicates that the alarm is generated when the measurement value gets above the alarm threshold value. The alarm is cleared when the measurement value falls below the clear threshold value. Down indicates that the alarm is generated when the measurement value falls below the alarm threshold. The alarm is cleared when the measurement value gets above this value.

The response also shows the clear threshold value (clrthres), the alarm threshold value (almthres), and the alarm category associated with the measurement (alarmcat).

Modifying Measurement Thresholds

You can modify the thresholds for the system measurements. To do this, enter the following MML command at the active Cisco PGW 2200 Softswitch:
set-thres::cat="meas_cat",interval=seconds,THRES=value
Where:

•meas_cat—The measurement category you want to modify.

•seconds—The number of seconds in the interval. The valid values are 900 for the 15-minute, 3600 for the 60-minute, and 86400 for the 24-hour interval.

•value—The desired threshold value.

For example, to set the threshold to a value of 125 in the 30-minute (1800 seconds) interval for the
SIP: RETX MSG TOT measurement category, enter the following command:
set-thres::cat="SIP: RETX MSG TOT",interval=1800, thres=125
Managing Call Detail Records

CDRs contain call billing records for your system. The Cisco PGW 2200 Softswitch stores the CDRs in log files. For more information on log files, see Appendix A, "Configuring Cisco PGW 2200 Softswitch Log Files." For more information on CDRs, see the Cisco PGW 2200 Softswitch Release 9 Billing Interface Guide.

Procedures for managing CDR log files are found in the following sections:

•Converting Individual CDR Files to ASCII Format

•Converting Individual CDR Files to a Readable Format

Converting Individual CDR Files to ASCII Format

You can convert individual CDR log files from their binary storage format to a comma-separated-value (CSV) format by entering the following UNIX command at the active Cisco PGW 2200 Softswitch:
MGC_Toolkit cdrconvert -input cdrlogfile -output filename -outformat 1 [-follow]
Where:

•cdrlogfile—Name of the CDR log file to be converted, including the file path.

•filename—Name for the file that is output by execution of this command, including the file path.

•-outformat 1—Specifies that the output file should be in CSV format.

•-follow—Used when you are converting the active CDR file. Processing of the active CDR file continues as CDR logs are created in the active file. Processing is stopped when you enter a Control C.

For example to convert an archived CDR log file from binary format to CSV format, you would enter the following UNIX command:
MGC_Toolkit cdrconvert -input /opt/CiscoMGC/var/spool/cdr_20011113100350_002172.bin 
-output /tmp/cdr.csv -outformat 1
The output file stores the CDR log file data in a manner similar to the following:
1090,,1,2001/Nov/13 EST 10:3:50,0X0000000000000000,2001/Nov/13 10:3:50 
,MGC-CDR-NODE-STRING 1100,,1,2001/Nov/13 EST 10:18:50,0X0000000000000000,2001/Nov/13 EST 
10:18:50,2,MGC-CDR-NODE-STRING
Converting Individual CDR Files to a Readable Format

You can view the CDR results stored in the CDR log file using the CDR viewer included in the Cisco MGC viewer toolkit. For more information on viewing CDR log files using the CDR viewer, see the "Using the Call Detail Record Viewer" section.

You can also convert the contents of individual CDR log files to a readable format using the following UNIX command entered at the active Cisco PGW 2200 Softswitch:
MGC_Toolkit cdrconvert -input cdrlogfile -output filename -outformat 2 [-follow]
Where:

•cdrlogfile—Name of the CDR log file to be converted, including the file path.

•filename—Name for the file that is output by execution of this command, including the file path.

•-outformat 2—Specifies that the output file should be in a readable format.

•-follow—Used when you are converting the active CDR file. Processing of the active CDR file continues as CDR logs are created in the active file. Processing is stopped when you enter a Control C.

For example to convert an archived CDR log file from binary format to a readable format, you would enter the following UNIX command:
MGC_Toolkit cdrconvert -input /opt/CiscoMGC/var/spool/cdr_20011113100350_002172.bin 
-output /tmp/cdr.csv -outformat 2
The output file stores the CDR data in a manner similar to the following:
0X0000000000000000 -----------------------------------------
0X0000000000000000 File_Header(1090)
0X0000000000000000 Unique_Call_ID(5000):
0X0000000000000000 Ver(4000): 1
0X0000000000000000 Create_Tm(4001): 2001/Nov/13 10:3:50 EST
0X0000000000000000 Call_Ref_ID(4002): 0X0000000000000000
0X0000000000000000 File_Start_Time(6001): 2001/Nov/13 10:3:50 EST
0X0000000000000000 Host_ID(6000): MGC-CDR-NODE-STRING
0X0000000000000000 MGC_Version(6004): "9.1(4.3)"
0X0000000000000000 -----------------------------------------
0X0000000000000000 -----------------------------------------
0X0000000000000000 File_Footer(1100)
0X0000000000000000 Unique_Call_ID(5000):
0X0000000000000000 Ver(4000): 1
0X0000000000000000 Create_Tm(4001): 2001/Nov/13 10:18:50 EST
0X0000000000000000 Call_Ref_ID(4002): 0X0000000000000000
0X0000000000000000 File_End_Time(6002): 2001/Nov/13 10:18:50 EST
0X0000000000000000 Total_CDBNum(6003): 2
0X0000000000000000 Host_ID(6000): MGC-CDR-NODE-STRING
0X0000000000000000 MGC_Version(6004): "9.1(4.3)"
0X0000000000000000 -----------------------------------------
Using the Cisco MGC Viewer Toolkit

This section describes the various components of the Cisco MGC viewer toolkit. The Cisco MGC viewer toolkit is used to view different types of files on the Cisco PGW 2200 Softswitch. This section describes the various components and the toolkit concept as a whole.

The Cisco MGC viewer toolkit is a suite of viewing tools that were developed to run on the Cisco PGW 2200 to provide quick and efficient access to diagnostic and troubleshooting information.

The following viewers are discussed in the following subsections:

•Launching the Cisco MGC Toolbar

•Using the Alarm Viewer

•Using the Call Detail Record Viewer

•Using the Config-Lib Viewer

•Using the Log Viewer

•Using the Measurement Viewer

•Using the Trace Viewer

•Using the Translation Verification Viewer

•Using the File Options Viewer

•Using the MGC Backup Viewer

•Using the MGC Restore Viewer

The Cisco MGC toolbar (Figure 3-1) is a graphical user interface (GUI) application used to launch the various viewers in the toolkit. Each application runs independently of the others. The toolbar includes a button for launching each application in the toolkit.

Figure 3-1 Cisco MGC Toolbar

You can run multiple instances of the Cisco MGC toolbar at one time, but only one instance of each tool at a time. If the selected application is already running, a message is displayed stating that your user ID and the application are already running. However, different tools can be run simultaneously. There is also a Close button on the toolbar, which is used to close the toolbar; however, closing the toolbar does not stop toolkit applications that are already running.

Caution The potential exists for foreground (text) and background (non-text) settings to conflict because your local display settings might conflict with the toolkit's color settings, thus rendering the text within various fields in the toolkit applications unreadable.

If you have problems reading text on any of the toolkit screens, please change the foreground color to a darker color on your display to see if that solves the problem.

Launching the Cisco MGC Toolbar

To launch the Cisco MGC toolbar, log in to the active Cisco PGW 2200 Softswitch, and enter the following command at the UNIX prompt:
MGC_Toolkit
Note For optimal performance, your display should be set to 1024 pixels.

Note If you are using the XTERM server to log in the active Cisco PGW 2200 Softswitch, use the following UNIX command to set the DISPLAY parameter:
export DISPLAY=server IP address:port
Then run the following UNIX command on your XTERM server.
xhost +

The MGC Toolbar window is displayed.

Using the Alarm Viewer

The alarm viewer helps you view and search records that reside in the current and archived alarm record logs. The formats of the various alarm records are specified in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

The alarm viewer includes a help file, which contains information about the viewer. To access this information, click the Help menu, select ReadMe, and the help text is displayed. You can also access a listing of the current alarm log files by clicking on the File menu and selecting the Alarm List option. You can exit the alarm viewer in one of two ways: in the Query Criteria portion of the window, click Exit; or from the File menu, select Exit.

Viewing and Searching Alarm Record Files

Complete the following steps to view and search various system alarm files:

Step 1 Open the alarm viewer. To do this, click Alarm Viewer on the Cisco MGC toolbar. A popup window displays warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes if you want to continue. The Alarm Viewer window loads and displays (as shown in Figure 3-2).

Figure 3-2 Alarm Viewer Window

Step 2 You can view current alarms as they happen. To do this, check the Alarm Continuous<ACTIVE, NEW>,Not Filtered check box. The current alarms are displayed in the field at the bottom of the viewer, and alarms are added to the field as they occur. To stop displaying current alarms, uncheck the check box.

Step 3 You can search for alarms that occurred between a certain dates and times, specifying month, day, year, hour, and minute settings. To do this, choose a starting date and time from the Start Date/Time drop-down list boxes and then choose a stopping date and time from the Stop Date/Time drop-down lists.

The current date and time are the default values for both the start and stop values for the time period; however, using these default values results in a null search (no records).

The Use Current Time as Stop Time check box, if selected, disables the Stop Date/Time drop-down lists and allows searching to be performed up until the current date and time.

Step 4 To search by a component, choose a component type from the Component Type drop-down list. If you do not want to search by a component or you want to view the entire contents of the file(s), choose the ALL entry.

From the drop-down list to the right of the Component Type list, choose subcomponents for the component you selected. If you do not want to specify an individual subcomponent, or you want to view the entire contents of the file(s), choose the NO_SPECIFIC entry.

Step 5 To search by an alarm category, select a category type from the alarm category pane. If you want to select one or more alarm categories, click the Select check box and select your desired alarm categories (if you want to select multiple categories, you must hold down the Ctrl key while selecting). If you do not want to search by a category or you want to view the entire contents of the file(s), check the ALL check box.

Step 6 Click Execute to search the files within the chosen time frame. The contents are displayed as multicolored text in the field at the bottom of the window. See Figure 3-2.

The following list describes the text colors associated with each alarm severity level

•Comments—White

•Cleared—Green

•Information—Blue

•Warning—Yellow

•Error—Orange

•Critical—Red

Step 7 If you want to view the logs that may be associated with this alarm, click Log Viewer and the Log Record View tab window is displayed (see Figure 3-3). By default, the viewer searches the platform log files for related logs that occurred within 60 seconds before and after the alarm occurred.

If you want to modify the criteria for the related logs search, click the LogView menu. This menu has two options, to modify the name of the log file to be searched (the log file prefix) and to modify the period the search occurs (the log time range).

To modify the name of the log file to be searched, click the LogView menu and choose the Log File Prefix option. The Log File Prefix window displays. Select the contents of the Log File Prefix field and enter the desired log file name. Click Set to close this window.

To modify the period of the search, click the LogView menu and choose the Log Time Range option. The Log Time Range window displays. Choose the contents of the Time Before Alarm field and enter the desired period in seconds. Choose the contents of the Time After Alarm field and enter the desired period in seconds. Click Set to close this window.

Step 8 If you want to perform additional searches, repeat steps 2 to 6. The color of the text from the old search changes from multicolored to blue, and the newly requested search data is inserted as multicolored text, appearing after the old data. Scroll down through the field to view the data you have added. You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data. You can also reset the search criteria by clicking Reset.

Step 9 If you want to save the displayed data, click Save. The contents of the field are saved to a file with the following directory path:

/opt/CiscoMGC/etc/cust_specific/toolkit/alarmRec.log

If you perform another search and save that content again, the contents of the field are added into the alarmRec.log file, after the previously saved data. If you do not want the new search data to be added onto the previous data, you must change the name of the alarmRec.log file before you save the new data. To change the name of a file, see the procedures in the "Using the File Options Viewer" section.

Figure 3-3 Log Record View Tab Window

Using the Call Detail Record Viewer

CDRs contain basic call billing information, such as date and time, duration, and the calling number and called number. CDRs are written into files that contain information about telephone activity. CDR files are saved in a binary format.

Note For more information on CDRs, see the Cisco PGW 2200 Softswitch Release 9 Billing Interface Guide.

The CDR dumper (see Figure 1-2) provides logging capabilities on the Cisco PGW 2200 Softswitch for all CDRs. Also, the CDR dumper supports external user application programming interfaces (APIs). The APIs allow users to get a real-time feed of CDRs and call detail blocks (CDBs) from the Cisco PGW 2200 Softswitch that can be routed to a third-party mediation application for use in billing.

The CDR dumper operates according to the configuration set up in the XECfgParm.dat file. When certain thresholds are met, the CDR dumper closes and saves the generated CDB records into the $BASEDIR/var/spool directory.

The CDR viewer is designed to help you view and search call detail records that reside in the CDR logs. The formats of the CDBs and call data elements (CDEs) that comprise CDRs are specified in the Cisco PGW 2200 Softswitch Release 9 Billing Interface Guide. These records are designed for database loading, not user reading. The CDR viewer can help you understand these records, and it also provides useful searching functions based on the search criteria you select.

Note Your screen might be slightly different from this example, depending on which release of the software you are running.

You can exit the CDR viewer in one of two ways: in the Query Criteria portion of the window, click Exit, or from the File menu, select Exit.

Configuring the CDR Viewer

Whenever you start the CDR viewer, you must choose several configuration settings before you can view or search the CDR files. To do this, complete the following steps:

Step 1 Open the CDR viewer. To do this, click CDR Viewer on the Cisco MGC toolbar. A popup window displays warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes if you want to continue. The CDR Viewer window loads and displays.

Step 2 Click the Configuration tab. The Configuration tab window displays (Figure 3-4).

The first five fields in the window cannot be modified. These fields list the directory paths and file names for the related data files.

Step 3 You can modify the CDR source directory on your local host. To do this, click in the CDR Data Directory field and change the displayed information.

Step 4 You can specify the message type(s) to be queried. All message types are enabled for querying by default.

If you want to filter out certain message types, select these message types from the All Possible Message Types field and click on the right arrow button. Your selected message types are displayed in the Selected filtering field.

To remove a message type from the Selected filtering field, select that message type in that field and click the left arrow button.

Figure 3-4 Config Tab Window

Searching the CDR Files

You can search through the various CDR files by component and category. To do this, complete the following steps:

Step 1 Open the CDR viewer. To do this, click CDR Viewer on the Cisco MGC toolbar. A popup window displays, warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes if you want to continue. The CDR Viewer window loads and displays the Query tab window by default (Figure 3-5).

If you have just opened the viewer, you must configure it before you can search the CDR files. See the "Configuring the CDR Viewer" section.

Step 2 You can search for logs that occurred between a certain dates and times, specifying month, day, year, hour, and minute settings. To do this, choose a starting date and time from the Start Date/Time drop-down lists and then choose a stopping date and time from the Stop Date/Time drop-down lists.

Figure 3-5 Query Tab Window

The current date and time are the default values for both the start and stop values for the time period; however, using these values results in a null search (no records).

The Use Current Time as Stop Time check box, if selected, disables the Stop Date/Time drop-down list boxes and allows searching to continue to the current date and time.

Step 3 If you want to view your selected CDR file(s) in their entirety, proceed to Step 7.

If you want to search through your selected CDR file(s) for particular type(s) of CDRs, proceed to
Step 4.

Step 4 You can search through your selected CDR files based on seven different field values. They are as follows:

•Calling Party Number

•Dialed Party Number

•Originating Trunk Group Number

•Terminating Trunk Group Number

•Originating Trunk Number

•Terminating Trunk Number

•Call Reference ID

To select a field value, click the check box next to the name. You can select as few or as many field values as you require.

Step 5 Enter a search qualifier and related string for each of the field values you selected. To do this, choose a search qualifier, as defined below, for the search string from the drop-down list box to the right of a field value you have selected.

•Equal to—The selected field in the CDB is equal to the value defined in the search string.

•Has—Any substring of the selected field in the CDB has the value defined in the search string.

•Begins with—The selected field in the CDB begins with the value defined in the search string.

•Ends with—The selected field in the CDB ends with the value defined in the search string.

Enter a search string in the field to the right of the search qualifier you just chose.

Repeat this step for all field values that you have selected for your search.

Step 6 Choose a query operator (AND or OR) for your search. You can search for CDBs that have all of the field values you selected (AND), or you can search for CDBs that have any of the field values you selected (OR). The default value is AND. Click the appropriate check box to specify your query operator.

Step 7 Click Execute to search the files within the selected time frame. A popup window displays while the contents load. The contents are displayed as multicolored text in the field at the bottom of the window.

Step 8 If you want to perform additional searches, repeat steps 2 to 13. The color of the text from the old search changes from multicolored to black, and the newly requested search data is inserted as multicolored text, appearing after the old data. Scroll down through the field to view the data you have added. You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data. You can also reset the search criteria by clicking Reset.

Step 9 If you want to save the displayed data, click Save. The contents of the field are saved to the file you specified in the Config tab window.

If you perform another search and save that content again, the contents of the field are added to the same file, after the previously saved data. If you do not want the data to be added to the previous data, you must change the name of the file before you save again. To change the name of a file, see the procedures in the "Using the File Options Viewer" section.

Using the Config-Lib Viewer

You can use the Config-Lib viewer (Figure 3-6) to manage the contents of the configuration library. The configuration library stores the various system configurations that you created while you provisioned your Cisco PGW 2200 Softswitch.

Click CONFIG-LIB on the Cisco MGC toolbar to open an xterm window and execute the config-lib script. To quit the Config-Lib viewer, enter q at the prompt.

The Config-Lib Viewer enables you to do the following functions:

•List Configuration Versions in Library—Returns a listing of the configuration versions stored in the library and identifies the configuration that is currently being used (referred to as the production version). To activate this function, enter 1 at the prompt.

•Save Production to a new Library Version—Saves your current configuration settings to a new version file. When you select this function, the Cisco PGW 2200 Softswitch software must not be running, or an error message is displayed. For more information on stopping the Cisco PGW 2200 Softswitch software, see the "Shutting Down the Cisco PGW 2200 Softswitch Software Manually" section on page 2-4. To activate this function, enter 2 at the prompt and then enter the name for the new library version.

Figure 3-6 Config-Lib Viewer

•Copy Library Version to Production—Restores your Cisco PGW 2200 Softswitch to the settings in an old configuration version. When you select this function, the Cisco PGW 2200 Softswitch software must not be running, or an error message is displayed. For more information on stopping the Cisco PGW 2200 Softswitch software, see the "Shutting Down the Cisco PGW 2200 Softswitch Software Manually" section on page 2-4. To activate this function, enter 3 at the prompt and then enter the number of the library version to be set as the production version.

Note We recommend that you not attempt to restore an old configuration version without the assistance of the Cisco TAC.

•Remove Configuration Library Version—Deletes a configuration version from the library. When you select this function, the Cisco PGW 2200 Softswitch software must not be running, or an error message is displayed. For more information on stopping the Cisco PGW 2200 Softswitch software, see the "Shutting Down the Cisco PGW 2200 Softswitch Software Manually" section on page 2-4. To activate this function, enter 4 at the prompt and then enter the number of the library version to be deleted.

Using the Log Viewer

The log viewer allows you to search for, retrieve, and display log messages from the platform log files. For more information on platform log files see the "Recovering from a Switchover Failure" section on page 8-166. For a listing of the platform log messages, see the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

You can see a listing of the current log file names by clicking the File menu and selecting the Log List option. You can exit the log viewer in one of two ways: click Exit, or from the File menu, select Exit.

Searching Log Record Files

Complete the following steps to search through various platform log files:

Step 1 Open the log viewer. To do this, click Log Viewer on the Cisco MGC toolbar. A popup window displays warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes if you want to continue. The Log Viewer window loads and displays (Figure 3-7).

Figure 3-7 Log Viewer

Step 2 You can search for logs that occurred between certain dates and times, specifying month, day, year, hour, and minute settings. To do this, choose a starting date and time from the Start Date/Time drop-down lists and then choose a stopping date and time from the Stop Date/Time drop-down lists.

The current date and time are the default values for both the start and stop values for the time period; however, using these values results in a null search (no records).

The Use Current Time as Stop Time check box, if selected, disables the Stop Date/Time drop-down list boxes and allows searching to continue to the current date and time.

Note You can clear the query options you select at any time by clicking Reset Query Options.

Step 3 If you want to view all of the logs within the time range you have specified in Step 3, click the Show All check box. If you choose this option, your search can be only based on a text string. Go to Step 6 for more information on performing text searches.

If you do not want to view all of the logs within the time range you have specified, proceed to Step 4 to further refine your search criteria before displaying the logs.

Step 4 You can search for logs within certain log categories. To do this, select your desired category or categories by clicking one or more entries in the Category list box. To select multiple entries, hold down either the Ctrl or Shift key while clicking. The available categories are:

•GEN

•ENV

•TIOS

•CP

•PROT

•MGMT

•MML

Step 5 You can search for logs of certain severities. To do this, select a severity or severities by clicking one or more entries in the Severity list box. To select multiple entries, hold down either the Ctrl or Shift key while clicking.

The severity choices are cumulative—each level selected also displays all levels below it. For example, the ERR selection displays both ERR (error) and CRIT (critical) messages. The severity levels are

•TRACE

•INFO

•WARN

•ERR

•CRIT

Step 6 You can search for logs that contain certain text string(s). You can search for up to two text strings. To do this, enter the desired search string(s) in the Text String fields. The text is case-sensitive, and all characters are allowed.

If you want to search by only one text string, enter that string in the upper Text String field, and do not enter a string in the lower Text String field.

If you want to search using two text strings, enter your strings in the upper and lower Text String fields.

If you want to search for logs that contain both of your text strings, select the And check box. If you want to search for logs that contain either of your text strings, check the Or check box.

If you want the text search to match the case used in your text string(s), click the Match Case check box.

If you do not want to search for text strings, click the None check box.

Step 7 You can also choose to display debug messages. Debug messages do not conform to the log message format. If you choose this option, the debug messages are filtered only on the date/time and text strings. To display debug messages, click the Show Debug messages check box. The viewer displays debug messages similar to the following:
platform.log ... : currently active log
Fri Apr 14 17:57:19:253 2000 | ProcessManager (PID 24929) <Debug>
initialized process info for 'POM-01'
Fri Apr 14 17:57:25:908 2000 | ProcessManager (PID 24929) <Debug>
Received heartbeat response from process CFM-01
Caution Displaying debug messages can seriously impact system performance.

Step 8 Click Execute Query to display the results of your search. The results are displayed in the field at the bottom of the window, in increments of 5 MB blocks.

While the application is searching through the log files, a dialog box appears and shows the progression of the search. If you want to stop a search in progress, click Stop Query in the dialog box.

Note Stopping the query can take several seconds.

Your results may run to several pages of information. You can use several buttons to navigate through your results. To go to the end of your results, click Bottom. To go to the next page of results, click More. To go to the beginning of your results, click Top.

Step 9 If you want to save the displayed data, choose the File > Save. A popup window lists the default save directory (/opt/CiscoMGC/etc/cust_specific/toolkit). Enter a file name for your data in the File Name field and click Save.

Step 10 If you want to perform additional searches, repeat steps 2 to 9. The old search data is appended to the new search data. You can clear the display field by clicking Clear before you click Execute Query.

Using the Measurement Viewer

The measurement viewer helps you view and search records that reside in the measurement record logs. The formats of the various measurement records are specified in Appendix D, "Cisco PGW 2200 Softswitch Measurements."

The measurement viewer includes a help file, which contains information about the viewer. To access this information, choose Help > ReadMe, and the help text is displayed. You can also see a listing of the current measurement logs by choosing File > Measurement List. You can exit the measurement viewer in one of two ways: in the Query Criteria portion of the window, click Exit; or choose File > Exit.

Viewing and Searching System Measurement Files

Complete the following steps to view and search various system measurement files:

Step 1 Open the measurement viewer. To do this, click Measurement Viewer on the Cisco MGC toolbar. A popup window displays warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes if you want to continue. The Measurement Viewer window is displayed (Figure 3-8).

Step 2 You can search for logs that occurred between certain dates and times, by specifying date, time, and counter interval settings. To do this, perform the following steps:

a. Choose a starting date and time from the Start Date/Time drop-down lists.

Note The current date and time are the default values for both the start and stop values for the time period; however, using these values results in a null search (no records).

b. Choose a stopping date and time from the Stop Date/Time drop-down lists.

Note The Use Current Time as Stop Time check box, if selected, disables the Stop Date/Time drop-down list boxes and allows searching to continue to the current date and time.

Figure 3-8 Measurement Viewer Window

c. If you want to further refine your search by specifying a counter interval, choose an interval from the Counter Interval drop-down list. The following intervals are valid for this field:

–NO_SPECIFIC (default value)

–5_Minute

–15_Minute

–30_Minute

–60_Minute

–24_Hours

d. If you want to further refine your search by specifying a system component type, proceed to Step 3.

If you want to further refine your search by specifying a measurement category type, proceed to Step 4.

If you want to execute a search based on your current search criteria, proceed to Step 5.

Step 3 To search by a system component, perform the following steps:

a. Choose a system component type from the Component Type drop-down list box. If you do not want to search by a system component or you want to view the entire content of the file(s), choose the ALL entry in the Component Type list box.

Note When you choose a system component type, the drop-down list to the right of the Component Type list box fills with the names of the system components of that type configured on your system.

b. If you want to further refine your search by specifying a particular system component, choose a system component name from the drop-down list box to the right of the Component Type list box.

Note The default value for this field is to search for all system components of the chosen component type.

c. If you want to further refine your search by specifying a measurement category type, proceed to Step 4.

If you want to execute a search based on your current search criteria, proceed to Step 5.

Step 4 To search by a measurement category, perform the following steps:

a. Choose a measurement category type from the Category Type drop-down list. If you do not want to search by a measurement category or you want to view the entire content of the file(s), choose the ALL entry in the Category Type list box.

Note When you choose a measurement category type, the drop-down list to the right of the Category Type list box fills with the names of all of the measurements associated with that type.

b. If you want to further refine your search by specifying a particular measurement, choose a measurement from the drop-down list to the right of the Category Type list box.

Note The default value for this field is to search for all measurements of the chosen category.

Step 5 Click Execute to search the files within the chosen time frame. The results of the search are displayed as blue text in the field at the bottom of the window.

Step 6 If you want to perform additional searches, repeat steps 2 to 5. The color of the text from the old search changes from blue to black and the newly requested search data is inserted as blue text, appearing after the old data. Scroll down through the field to view the data you have added.

You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data. You can also reset the search criteria by clicking Reset.

Step 7 If you want to save the displayed data, click Save. The contents of the field are saved to a file with the following directory path:

/opt/CiscoMGC/etc/cust_specific/toolkit/measRec.log

If you perform another search and save the resulting content, the contents of the field are added into the measRec.log file, after the previously saved data. If you do not want the new search data to be added to the previous data, you must change the name of the measRec.log file before you save the new data. To change the name of a file, see the procedures in the "Using the File Options Viewer" section on page 3-130.

Using the Trace Viewer

You can use the trace viewer as part of performing a call trace. Clicking Trace Viewer in the Cisco MGC toolbar opens the Traces Files window, which lists the call trace files from which you can choose (Figure 3-9). When you select a file, you can click View, which opens the Trace Viewer window (Figure 3-10), which allows you to perform a variety of call trace activities. For more information about call traces, see the "Performing a Call Trace" section on page 8-151.

Figure 3-9 Trace Viewer Window

Figure 3-10 Trace Viewer Window

Using the Translation Verification Viewer

The translation verification viewer allows you to interface with the translation verification tool. The translation verification tool provides you with a means to understand how calls are being processed based on your system's dial plan. This tool creates a simulation of a call being processed by the dial plan. This tool is meant for use in systems configured for call control.

Note The translation verification viewer does not simulate the screening database and cause analysis dial plan functions.

You can exit the translation verification viewer by choosing File > Exit.

Verifying a Dial Plan Translation

Complete the following steps to verify a dial plan translation:

Step 1 Open the translation verification viewer. To do this, click Translation Verification on the Cisco MGC toolbar. A popup window displays warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes. The Translation Verification Viewer window loads and the DialPlan Translation tab window is displayed by default (Figure 3-11).

Step 2 Enter the incoming trunk group number for your simulated call in the trunk group number field.

Step 3 Specify an ISDN preference for the selecting of the outgoing trunk by choosing a value from the message specific ISDN preference drop-down list. The following values are valid for this field.

•ISDN_NOT_REQUIRED (default value)

•ISDN_PREFERRED

•ISDN_REQUIRED

Step 4 Specify the Nature Of Address (NOA) setting for the called party by choosing a value from the called party's Nature of Address drop-down list. The following values are valid for this list.

•NOA_NATIONAL (default value)

•NOA_NONE

•NOA_UNKNOWN

•NOA_SUBSCRIBER

•NOA_INTERNATIONAL

•NOA_NETWORK

•NOA_MERIDIAN

•NOA_ABBR

•NOA_UNIQUE_3DIG_NATL_NUM

•NOA_ANI

•NOA_NO_ANI_RECD

•NOA_NON_UNIQUE_SUBSCRIBER

•NOA_NON_UNIQUE_NATIONAL

•NOA_NON_UNIQUE_INTERNATIONAL

•NOA_OPRREQ_TREATED

•NOA_OPRREQ_SUBSCRIBER

•NOA_OPRREQ_NATIONAL

•NOA_OPRREQ_INTERNATIONAL

•NOA_OPRREQ_NO_NUM

Figure 3-11 DialPlan Translation Tab Window

•NOA_CARRIER_NO_NUM

•NOA_950_CALL

•NOA_TEST_LINE_CODE

•NOA_INT_INBOUND

•NOA_NAT_OR_INTL_CARRIER_ACC_CODE_INC

•NOA_CELL_GLOBAL_ID_GSM

•NOA_CELL_GLOBAL_ID_NMT_900

•NOA_CELL_GLOBAL_ID_NMT_450

•NOA_CELL_GLOBAL_ID_AUTONET

•NOA_PORTED_NUMBER

•NOA_PISN_SPECIFIC_NUMBER

•NOA_UK_SPECIFIC_ADDRESS

•NOA_SPARE

•NOA_SUBSCRIBER_OPERATOR_REQUESTED

•NOA_NATIONAL_OPERATOR_REQUESTED

•NOA_INTERNATIONAL_OPERATOR_REQUESTED

•NOA_NO_NUMBER_PRESENT_OPERATOR_REQUESTED

•NOA_NO_NUMBER_CUT_THROUGH_TO_CARRIER

•NOA_950_PUBLIC_HOTEL_LINE

•NOA_TEST_CALL

•NOA_MCI_VNET

•NOA_INTERNATIONAL_OPERATOR_TO_OPERATOR_OUTSIDE_WZI

•NOA_INTERNATIONAL_OPERATOR_TO_OPERATOR_INSIDE_WZI

•NOA_DIRECT_TERMINATION_OVERFLOW

•NOA_ISN_EXTENDED_INTERNATIONAL_TERMINATION

•NOA_TRANSFER_ISN_TO_ISN

•NOA_CREDIT_CARD

•RESERVED

Step 5 Specify the Numbering Plan Indicator (NPI) setting for the called party by choosing a value from the called party's Numbering Plan Indicator drop-down list. The following values are valid for this field.

•NPI_E164 (default value)

•NPI_NONE

•NPI_DATA

•NPI_TELEX

•NPI_PNP

•NPI_NATIONAL

•NPI_TELEPHONY

•NPI_MARITIME_MOBILE

•NPI_LAND_MOBILE

•NPI_ISDN_MOBILE

Step 6 Specify the called number in the called numbers field.

Step 7 Specify the calling number in the calling numbers field.

Step 8 Specify the level of the trace by choosing a value from the trace level drop-down list. The following values are valid for this list.

•result (default)—Returns the originating trunk group number, called and calling party numbers, outgoing called and calling party numbers, and the resulting trunk group. This trace type is suited for quick call analysis.

Here is an example result trace:
>simWriter -tgnum 7001 -isdnp 1 -cdnoa 4 -cdnpi 1 -cdpn 7075511234 -cgpn 7034843
368
>Result of Execution
Originating side: A-number     7034843368
                   B-number     7075511234
                   Trunk group  7001
Outgoing side:    A-number     7034843368
                   B-number     7075511234
                   No suitable trunk group found!
*Internal errors/warnings were encountered during translation!
>OK
•diagnostic—Returns limited information about all of the stages of number and route analysis and messages and warnings about data files being read and whether or not default values are being used. This trace type is suited for determining which results were used to produce the outgoing numbers and trunk group.

Here is an example diagnostic trace:
>simWriter -tgnum 7001 -isdnp 1 -cdnoa 4 -cdnpi 1 -cdpn 7075511234 -cgpn 7034843
368 -diag
>Result of Execution
********************************************************
* START call translation verification diagnostic summary *
**********************************************************
  performing Dial Plan Base.
  performing Profile Analysis (NOA).
*Internal errors/warnings were encountered during translation!
********************************************************
*  END call translation verification diagnostic summary  *
**********************************************************
Analysing .dat files:
used default Route Prefernce
used default Terminating Max Digits
used default Terminating Min Digits
used default Originating Min Digits
used default Originating Max Digits
the Originating Start Index property for tg-7001 was not found in /opt/CiscoMGC/
etc/properties.dat
Customer Group ID's do not match up in the sigPath and Properties files
used default Carrier Screening property
used default AOCEnabled field
used the default field for default directory number
used the default Database Access Error flag
Analysis complete, writing message...
Message completed, running simulator...
>OK
•full—Returns complete information about all of the stages of number and route analysis. It also includes all tables and parameters from flat files and internal errors generated during generic analysis. This trace type is suited for determining where in the dial plan or number analysis problems occurred.

Here is an example full trace:
>simWriter -tgnum 7001 -isdnp 1 -cdnoa 4 -cdnpi 1 -cdpn 7075511234 -cgpn 7034843
368 -full
>Result of Execution
********************************************
* START full call translation verification *
********************************************
Decoding generic analysis trace...
the length of the trace is 82 bytes
( 1)entering Dial Plan Base.
( 2) tracing Dial plan, entering Dial Plan Base table with...
( 1)   0 parameter(s):
( 2)   reading Dial Plan Base table...
( 1)     1 error/warning code read:
*Internal Error:Table could not be read
( 1)ending Dial Plan Base...
( 1)entering Call Information Reception.
(13) A Number:'7034843368'
(13) B Number:'7075511234'
( 1)ending Call Information Reception...
( 1)entering Profile Analysis (NOA).
(13) Tracing call number:'7075511234' (Called party number)
( 7) Trace for customer:'jst1'
( 5) TreeBase:'10'
( 2) tracing Dial plan, entering NOA table with...
( 1)   1 parameter(s):
( 4)     NOA table index = 4.
( 2)   reading NOA table...
( 1)     1 error/warning code read:
*Internal Error:Table could not be read
( 1)ending Profile Analysis (NOA)...
( 1)end of trace reached
********************************************
* DONE full call translation verification *
* with  0 bytes left untranslated          *
********************************************
Analysing .dat files:
used default Route Prefernce
used default Terminating Max Digits
used default Terminating Min Digits
used default Originating Min Digits
used default Originating Max Digits
the Originating Start Index property for tg-7001 was not found in /opt/CiscoMGC/
etc/properties.dat
Customer Group ID's do not match up in the sigPath and Properties files
used default Carrier Screening property
used default AOCEnabled field
used the default field for default directory number
used the default Database Access Error flag
Analysis complete, writing message...
Message completed, running simulator...
>OK
The content of the field identifies for you which elements of your dial plan need to be modified, if necessary.

Step 9 Click Execute to perform a dial plan translation verification. The results are displayed in the field at the bottom of the window.

Step 10 If you want to verify additional dial plan translations, repeat steps 2 to 9. The newly requested data is inserted after the old data. Scroll down through the field to view the data you have added. You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data.

Step 11 If you want to save the displayed data, click SaveinFile. The contents of the field are saved to a file specified in the XECfgParms.dat file.

Viewing Dial Plan Translation Configuration Data

Complete the following steps to view the dial plan translation configuration data:

Step 1 Open the translation verification viewer. To do this, click Translation Verification on the Cisco MGC Toolbar. A popup window displays warning you that running this tool can impact system performance and asking you if you want to launch the tool. Click Yes. The Translation Verification Viewer window loads and displays the DialPlan Translation tab window by default (Figure 3-11).

Step 2 Click the Config tab to display the Config tab window (Figure 3-12). The fields in this window display the directory paths to the files used by this viewer. The values in these fields cannot be modified.

Figure 3-12 Configuration Tab Window

Using the File Options Viewer

The file options viewer (Figure 3-13) enables you to manage (rename, delete) the files within the $BASEDIR/etc/cust_specific directory. This directory contains all files created by the various toolkit applications. These subdirectories are created through the MML export feature and contain configuration information in the form of MML commands.

Note You cannot use the file options viewer to delete files within the $BASEDIR/etc/cust_specific/export directory.

Figure 3-13 File Options Viewer Window

Using the MGC Backup Viewer

The MGC backup viewer enables you to backup the software configuration of your Cisco PGW 2200 Softswitch. For more information on using the MGC backup utility, see the "Backup Procedures for Cisco PGW 2200 Softswitch Software" section.

Figure 3-14 illustrates the main window for the MGC backup viewer.

Figure 3-14 MGC Backup Viewer Window

Using the MGC Restore Viewer

The MGC restore viewer enables you to restore a previously stored configuration to your Cisco PGW 2200. For more information on using the MGC restore utility, see the "Restoring Procedures for Cisco PGW 2200 Softswitch Software" section on page 8-173.

Figure 3-15 illustrates the main window for the MGC restore viewer.

Figure 3-15 MGC Restore Viewer Window