Cisco PGW 2200 Softswitch Release 9.8 Operations, Maintenance, and Troubleshooting Guide
Cisco PGW 2200 Softswitch Platform Operations
Downloads: This chapterpdf (PDF - 1.46MB) The complete bookPDF (PDF - 6.01MB) | Feedback

Cisco PGW 2200 Softswitch Platform Operations

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

Re-entering 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 a 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 a 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: March 10, 2011, OL-0800-14

This chapter presents recommended operating procedures for the Cisco PGW 2200 Softswitch platform.

Ensure that all components are correctly installed, configured, and provisioned according to the instructions provided in the relevant documentation. All components should have started successfully, as described in Chapter 2, "Cisco PGW 2200 Softswitch Platform Component Startup and Shutdown Procedures."


Note To operate the Cisco PGW 2200 Softswitch, you should understand the complexities of the system, be experienced in administering the system, and be capable of using the UNIX operating system with system-administrator proficiency.


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 that you should perform daily are presented 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 You should 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. After you have successfully started an MML session, the prompt changes as shown in the following example:

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 learn which Cisco PGW 2200 Softswitch is active, 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, like 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 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 6-90.

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 that are described in the "Monitoring the Alarms Status" section. Perform the actions necessary to correct the condition that caused the associated alarms. The alarms that require you to take corrective action and their associated actions can be found in the "Alarm Troubleshooting Procedures" section on page 6-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 Softswitches 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 like 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, compare the active configuration to the previous configuration.

Step 5 Collect system data according to the "Collecting System Data for Cisco TAC" section on page 6-93 and contact the Cisco TAC to analyze the problem further and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xviii.


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 like the following:


Note The following sample output was generated by Cisco PGW 2200 Softswitch Release 9.7(3) Patch 14 software. 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 stop, you can see "process name:STOPPED" in the system output.



Note If you enter this MML command 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 xviii for more information on contacting the Cisco TAC.

If any of the processes stop, contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xviii 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. The Cisco PGW 2200 Softswitch software process manager processes all these processes.

There are three different process monitoring levels:

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 file or script and sets or clears an alarm that is 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 that are 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 fails, it causes a critical out-of-service alarm.

 

ENG-01

Call engine. It is an active process. If it goes 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 goes down, it causes a major out-of-service alarm.

 

TCAP-01

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

 

pril3-1

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

 

mgcp-1

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

 

h248-1

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

 

sip-1

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

 

eisup-1

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

 

ss7-i-1

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

 

m3ua-1

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

 

sua-1

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

 

iua-1

IUA protocol handler. It is a passive process. If it goes 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 goes down, it causes a major out-of-service alarm.

 

ALM-01

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

 

AMDMPR-01

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

 

MM-01

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

 

CDRDMPR-01

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

 

MMDB-01

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

 

POM-01

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

FTG-01
Failover Group
 

FOD-01

Failover (switchover) controller. It is a monitoring process. If it goes 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. It trims older files if the current amount of free space goes below a specified threshold. This is a monitoring process. If it goes down, it causes a minor out-of-service alarm.

 

LMAGT-01

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

SNMPG-01
SNMP Group
 

MEASAGT

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

 

OPERSAGT

Operational SNMP Agent. This process is an active process. If it goes down, it causes 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. To monitor the alarm status of the Cisco PGW 2200 Softswitch continuously, 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, determine the appropriate course of action by referring to the listing for that alarm in Cisco PGW 2200 Softswitch Release 9 Messages Reference. For detailed descriptions of the actions that are required to resolve the problems that are associated with the alarm, see the "Alarm Troubleshooting Procedures" section on page 6-4.

You can also find additional information on the conditions that caused the alarms by viewing the system logs. You can view the logs 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.

Press Ctrl-C to stop the alarm monitor.


Note When you begin to monitor alarms continuously, you must 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 that is 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 that is entered during system provisioning. In the example, these components are LPC-01, IOCM-01, MGC1alink2, and MGC1alink3.

All system components are described in 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 of a second, thousandths of a second (milliseconds), and time zone. The time that is displayed is the system time. In the example, these times 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 the 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, you should clear them immediately.


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

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

Minor (MN)—Note and then clear minor alarms as soon as possible. Determine how often this alarm appears, because it might indicate 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. Only the SNMP Manager retrieves events of the informational severity level.

An Alarm Example

This section provides 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 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 the signaling services that are 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 you enter the rtrv-dest:all MML command 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 indicates 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 in service (IS) for any of the signaling service, check your alarms retrieval MML session for signaling-related alarms. The "Monitoring the Alarms Status" section describe the method for setting up an alarms-retrieval MML session.

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 6-4. If the alarm is not in that section, corrective action is not required. More information on the alarm can be found in 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 also use the rtrv-dest MML command to retrieve information on individual signaling services using the procedure that is presented in the "Retrieving Signaling Service States" section.


Understanding the Signaling Service State Information

The following sections describe the information that is returned by the system when you enter the rtrv-dest command, as shown in the following example:

"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 preceding example, the signaling services are sigsrv1, sigsrv2, and sigsrv3.

Package

The PKG field lists the protocol package that is 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 OOS1 .

INB

Install busy

When a system is first configured, all signaling links default to this state and must be manually set IS2 by entering 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 state is its normal operating state.

MOOS

Manually out-of-service

The link to the signaling service has been manually set to 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.

1 OOS = out-of-service.

2 IS = in-service.


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 presented in the following list:

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. This state occurs 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 you enter the rtrv-dest MML command after a switchover occurs, 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 indicates 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.

Step 2 Start an MML session.

Step 3 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 4 If the primary service state is not IS for any of the routes, check your alarms-retrieval MML session for signaling-related alarms. The "Monitoring the Alarms Status" section describes the method for setting up an alarms-retrieval MML session.

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 6-4. If the alarm is not in that section, corrective action is not required. More information on the alarm can be found in 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 that is returned by the system when you enter the rtrv-rte command, as shown in the following example:

"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 services that are 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 linksets that are 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 that is 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

System has taken the SS7 route OOS.

INB

Install busy

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

IS

In-service

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

MOOS

Manually out-of-service

SS7 route has been manually set to OOS.

OOS

Out-of-service

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

TRNS

Transient

State of the link to the SS7 route is currently being changed.

UNK

Unknown

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 following list presents the valid states:

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

You should verify 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 takes some time. It takes more time to page through the information.

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.

Step 2 Start an MML session.

Step 3 Enter the following command:

rtrv-cic:sig_srv:cic=number[,rng=range]

Where:

sig_srv—MML name of the signaling service that is associated with the displayed CICs.

number—A valid CIC number.

range—Specifies a range of CICs for the system to retrieve. The system displays the status of all CICs between number and number+range.

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 like 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 4 If the primary service state is not IS for any of the CICs, or if a CIC is blocked, check your alarms-retrieval MML session for bearer-related alarms. The "Monitoring the Alarms Status" section describes the method for setting up an alarms-retrieval MML session.

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 6-4. If the alarm is not in that section, corrective action is not required. More information on the alarm can be found in Cisco PGW 2200 Softswitch Release 9 Messages Reference.


Understanding CIC States

The elements of the output from the rtrv-cic MML command are described in the following paragraphs.

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 state 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, because of 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 a new call.

Out

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

Idle

Circuit is available for use.


Media Gateway State

The GW_STAT field identifies the current state of the media gateway that is 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, it indicates that the associated T1 or E1 has failed. This state 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 state occurs because of 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 because of a media gateway event. For example, a media gateway interface might fail, which causes the transmission of an RSIP message; but, the associated CICs remain in-service. As another example, this block type might occur when an RSIP message is not acted upon because of a mismatch between the MGCP hostname in the RSIP string and the host name that is provisioned in the media gateway. If the associated switch does not responding to group unblock messages, the CICs stay in the GATEWAY circuit block state. Your CICs should 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 transition from this state. If the CICs stay in the GATEWAY circuit block state, troubleshoot the problem with the media gateway.

INTERFACE_DISABLED

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—An external message that is generated by a network element outside the media gateway blocked the CIC.

LOCMAN

Blocked manually using an MML command, such as blk-cic. You can remove this block by issuing the unblk-cic or reset-cic MML commands.

LOCUNK

Locally blocked for unknown reasons. This block indicates that a software problem possibly blocked the CIC but the software did not track the cause of the block.

MATE_UNAVAIL

Locally blocked on a nailed-up system because of a media gateway event (for example, the media gateway sent a group service message or the media gateway is out of service). If the associated switch does not respond to group unblock messages, the CICs stay in the MATE_UNAVAIL circuit block state. Your CICs should be in this state when you bring up the Cisco PGW 2200 Softswitch or media gateway. When the associated switch acknowledges the unblock message, the CICs transition from 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 blocked automatically.

REMMAN

Remotely blocked manually.



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


Verifying System Statistics

You should monitor the Cisco PGW 2200 Softswitch system statistics daily. The system statistics provide 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 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 like 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 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. The CRMs are sent to maintain synchronization after a link failure on the IP side. These CRMs are treated as active calls, which increases the number of in-progress calls returned by this command.


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

If the response to the command indicates that the percentage of disk space capacity is at 90 percent or higher, you must delete files from your disk, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section on page 6-169.

Verifying the Number of Active Processes

You should check the number of active processes on the Cisco PGW 2200 Softswitch daily. To check, 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 xviii 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 check, log into the active Cisco PGW 2200 Softswitch and enter the following UNIX command:

who

The system returns a response like 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 xviii for more information on contacting the Cisco TAC.

Verifying Available Virtual Memory

The operating system that is 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. This data write to disk enables the system to use that block of memory for another purpose. The space on the disk that is dedicated to this function is called swap space. When 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 system uses the tmp directory to run several special files, such as FIFOs, which the system requires to run properly. As the amount of space that is 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 minimize the amount of space that the tmp directory consumes.


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 conduct this comparison, perform the following steps:


Note Be aware that the time of day when you enter these commands affects 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. However, this reduction in virtual memory might not indicate a need to contact the Cisco TAC.

Consider performing this procedure during a period of less active call processing, to determine an average amount of available virtual memory.


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, complete the following steps:


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

Step 2 Enter the following UNIX commands:

cd /usr/sbin
prtconf | grep Memory

The system returns a response like the following:

Memory size: 2048 Megabytes

Step 3 To determine the size of the swap space on the disk, enter the following UNIX command:

swap -s

The system returns a response like the following:

total: 235272k bytes allocated + 65912k reserved = 301184k used, 5471344k available

Step 4 Add the amount of physical memory to the amount of swap space. This value is the maximum virtual memory for your system.

Step 5 To determine the amount of available virtual memory, enter the following UNIX command:

vmstat 

The system returns a response like 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 that is listed in the response (5509624 and 1365192 in the preceding example) represents the total amount of available virtual memory. This amount should always be greater than 10 percent of the maximum virtual memory. If virtual memory is less than 10 percent, proceed to Step 5.


Note You can also 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 page for the vmstat command for more information.

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


Step 6 Collect the system data that is described in the "Collecting System Data for Cisco TAC" section on page 6-93. Contact the Cisco TAC to analyze the problem further and to determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xviii.


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) daily. To check, perform the following steps:


Step 1 Log in to a Cisco ITP-L, and enter the following Cisco IOS command to check the amount of available memory:

show mem

The system returns a response like 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 memory use is less than 90 percent, the procedure is complete. If the response indicates that the Cisco ITP-L has a small amount of available memory, you might need to add additional memory to the Cisco ITP-L to manage call processing.


Note Be aware that the time of day when you enter this command will affect the overall accuracy of the response. If you enter this command during your busiest hours, the amount of available memory could be quite small. However, this memory reduction might not indicate a need to add additional memory.

Consider performing this procedure during a period of less active call processing, to determine an average amount of available memory.


Step 2 See the documentation for Cisco 2800 Series Integrated Services Routers for more information pertaining to memory requirements.


Periodic Maintenance Procedures

This section contains procedures that are performed either automatically, on a schedule, by the system, or that you perform regularly to maintain proper operation of the Cisco PGW 2200 Softswitch platform. Schedule the procedures that you must perform manually according to your own requirements. The maintenance procedures include the following:

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 that Sun Microsystems (the hardware manufacture) provided, for detailed information on such procedures.


Automatic Disk Space Monitoring

The Cisco PGW 2200 Softswitch software includes a script that is called disk monitor (diskmonitor.sh). Disk monitor periodically checks the amount of disk space that is 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. 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 that are stored in the configuration library (which is found in the /opt/CiscoMGC/etc/CONFIB_LIB directory). Disk monitor trims the older configurations when the number of configurations exceeds the maximum value you set in the associated XECfgpParm.dat disk monitor parameter. The process manager runs the disk monitor script once every minute.

For prior releases, users were encouraged to ensure that no more than 64 configurations were stored in the configuration library. This recommendation was made to ensure the proper functioning of switchovers and the prov-sync MML command. If the system stores more than 64 configurations, switchovers and the prov-sync command time out and fail. Such timeouts and failures occur because the standby Cisco PGW 2200 Softswitch attempts to copy over all the configurations that are stored on the active Cisco PGW 2200 Softswitch.

Currently, the Cisco PGW 2200 Softswitch software automatically manages the process that administers the configuration library. You set the disk monitor parameter to establish the maximum number of configurations that are allowed in the configuration library. The system trims the older configurations as necessary.

The following parameters in the XECfgParms.dat file control the disk monitor:

diskmonitor.Limit—Specifies the number of days to preserve data before the system trims data. The default value is 7.

diskmonitor.OptFileSys—Allows monitoring of optional user-configurable file systems. This utility monitors the /opt file system for threshold crossing. Using this parameter, you can monitor additional file systems (disk slices) by setting the parameter to the preferred directory, such as /tmp, /usr or /var. The messages that are 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.

The following sample log entry shows how a log entry might appear:

Filesystem /var has exceeded 80 percent full


Note Disk monitor does not trim files in these file systems.


diskmonitor.Threshold—Specifies the percentage of disk usage that, when exceeded, generates a DISK alarm, and initiates disk trimming. The default value is 80.

diskmonitor.CdrRmFinished—Specifies how many days to keep completed (polled) call detail record (CDR) files. The default value is 0. The default specifies that the Cisco BAMS polls the Cisco PGW 2200 Softswitch. The CDR.bin files remain in a user-configurable directory until the Cisco BAMS trims them (using the format CDR_timestamp.finished). Alternatively, the disk monitor trims the file from the user-configurable directory.

diskmonitor.SoftLimit—Specifies the operation that the system performs when the system reaches the threshold number of days that is specified for the diskmonitor.Limit parameter. If this parameter is set to true, the disk monitor decrements the value in the diskmonitor.Limit parameter one day at a time (that is, from 7 to 6 to 5, and so on) until the disk utilization level drops below the percentage of disk set by the diskmonitor.Threshold parameter. If this parameter is set to false, the disk monitor closes when the system saves files continuously for the number of days set for the diskmonitor.Limit parameter or when disk usage reaches the percentage of use set for the diskmonitor. Threshold parameter. When disk monitor stops, the system generates a DISK alarm. The files can then be deleted manually. The default value is false.

diskmonitor.CoreRmDays—Specifies the number of 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. This parameter is not present in the XECfgParm.dat file initially. 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 that are stored in the configuration library. To change the value of this parameter, enter it manually into the XECfgParm.dat file.

diskmonitor.PreserveCDRs—This parameter affects the performance of the disk monitor in coordination with the diskmonitor.Threshold, diskmonitor.Limit, and diskmonitor.SoftLimit parameters. If diskmonitor.PreserveCDRs is set to true, the system saves the CDR files during each stage of the disk monitor process. If diskmonitor.PreserveCDRs is set to false, the system manages the CDR files according to the settings of the diskmonitor.Threshold, diskmonitor.Limit, and diskmonitor.SoftLimit parameters. That is, the system will stop saving the CDR files when disk usage surpasses the percentage of use set by the diskmonitor.Threshold parameter.

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, have not exceeded 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, the disk monitor attempts to trim the files according to the number of days defined by the diskmonitor.Limit parameter. For instance, if diskmonitor.Limit is set to 7, the disk monitor deletes any files older than 7 days.

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 have not exceeded 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 system exits disk monitor and raises a DISK alarm.

c. If the disk utilization exceeds the threshold, and diskmonitor.SoftLimit is set to true, the disk monitor begins decreasing the number of days for which logs can be stored (the value that is defined in diskmonitor.Limit), and stops as soon as disk utilization drops beneath the threshold specified by the diskmonitor.Threshold parameter.

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 configured usage threshold, the Cisco PGW 2200 Softswitch generates a DISK alarm (a major alarm). The DISK alarm warns of a disk partition overrun and of insufficient disk space. See the "DISK" section on page 6-38 for information about the corrective actions that are required to resolve a DISK alarm.

Disk monitor does not trim some other files, such as call trace files, which use large amounts of disk space. You might need to delete call trace files periodically. The system creates call trace files when you perform call traces while troubleshooting a problem. These files can be rather large. 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 6-169.

Configuring Disk Monitor

You can configure the disk monitor only while the Cisco PGW 2200 Softswitch software is turned off. Therefore, you should configure disk monitor only during initial installation. For more information on configuring the disk monitor during initial installation, see the XECfgParms.dat section of Cisco PGW 2200 Softswitch Release 9.8 Software Installation and Configuration Guide.

To configure disk monitor after initial installation, perform the following steps:


Caution To perform the following procedure, turn off the Cisco PGW 2200 Softswitch software. 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 xviii for more information on contacting the Cisco TAC.

If your system is a single Cisco PGW 2200 Softswitch in a simplex configuration, performing this procedure causes the system 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 6-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 6-4. If the alarms are not in that section, corrective action is not required. For more information on those alarms, see the Cisco PGW 2200 Softswitch Release 9 Messages Reference.

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

Step 3 On each host, modify the disk monitor parameters in the XECfgParm.dat files. Use the procedure that is described in the "Rebooting Software to Modify Configuration Parameters" section on page 6-183.

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

diskmonitor.OptFileSys—Enables monitoring user-configurable file systems. This utility monitors the /opt file system for threshold crossing. Using this parameter, you can monitor additional file systems (disk slices) by setting the parameter to the preferred directory, such as /tmp, /usr, or /var. The system sends the messages that are associated with this parameter to the platform.log file. To retrieve these messages, you must scan the platform.log file for messages. The system presents the messages in the following format:

Filesystem <file_system_name> has exceeded <num> percent full.

The following sample output shows how a message appears:

Filesystem /var has exceeded 80 percent full


Note Disk monitor does not trim the files in these file systems.


diskmonitor.Threshold—Sets the percentage of disk usage. When disk usage exceeds the threshold, the system raises alarms and begins to trim files. The default value is 80.

diskmonitor.CdrRmFinished—Specifies how many days to keep completed CDR files. The default value is 0. The default specifies that the Cisco BAMS polls the Cisco PGW 2200 Softswitch. The CDR.bin files remain in a user-configurable directory until the Cisco BAMS renames them (using the format CDR_timestamp.finished). Alternatively, the disk monitor trims the file from the user-configurable directory.

diskmonitor.SoftLimit—Specifies the operation that the system performs when the system reaches the threshold number of days that is specified for the diskmonitor.Limit parameter. 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 to 6, 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. You can delete the files manually. The default value is false.

diskmonitor.CoreRmDays—Specifies the number of days to keep core dump files 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—Specifies the maximum number of configurations that can be stored in the configuration library. This parameter is not present in the XECfgParm.dat file initially. 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 that are stored in the configuration library. To change the value of this parameter, you must enter it manually into the XECfgParm.dat file.


Caution The Cisco PGW 2200 Softswitch software is case-sensitive. Enter the parameter name correctly, or the system will not modify the maximum number of configurations.


Note 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 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 that are 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 in the /opt/CiscoMGC/var/log directory. The XECfgParm.dat file parameter sets the name of the system log file, 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 because 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.

Size of the active system log file exceeded the value that is set in the XECfgParm.dat parameter, fileRotateSize.

Time elapsed since the last log rotation exceeded the value that is set in the XECfgParm.dat parameter, fileRotateInterval.

When the system rotates the system log file, it archives the current system log file and opens a new system log file. The system stores the archived log file in the /opt/CiscoMGC/var/spool directory. Once the Cisco PGW 2200 Softswitch software is operating, the log server takes over the actual file rotation function of renaming the active file to a historical file with a new filename. The filename is constructed according to the following format:

logFileNamePrefix_yyyymmddhhmmss.log, where the time stamp indicates the system date and time when the log is rotated.

Rotating System Logs Manually

You can also run the log rotation script manually to force the system to archive the current system log file. To run the script manually, 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 to ensure that you can restore the Cisco PGW 2200 Softswitch after it is forced out of service by a natural or man-made disaster. The plan should include regular backups of the system software.

See the "Backing Up System Software" section for more information about backup operations. Store the backup data for your system in a secure location, in a site separate from the equipment, to ensure that the same disaster does not affect the backed up data.

For information on performing a disaster recovery, see the "Recovering from Cisco PGW 2200 Softswitch Failure" section on page 6-172.

Backing Up System Software

Schedule regular 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 easier to restore system information from backup data than to recreate it.

Furthermore, if a failure occurs because the system software is not backed up, you will lose critical configuration information. Create a backup schedule. Perform small or incremental backups daily, and a large or complete backup once a week.


Note Back up your system software during periods of low call volume to minimize the effect of the backup on call processing.


The following section describes backup procedures:

Backup Procedures for Cisco PGW 2200 Softswitch Software

Backup Procedures for Cisco PGW 2200 Softswitch Software

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


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 You can run the various backup operations that are described in the following sections only 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 are in the "Restoring Procedures for Cisco PGW 2200 Softswitch Software" section on page 6-177.


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—Complete 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 Do not store backup files on your local Cisco PGW 2200 Softswitch. Storing backup files on the local host reduces the amount of disk space available to process call data. Also, it does not ensure that the data is safe if a natural disaster occurs.



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


retries—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—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 by which the backup file is saved to a directory path called /dev/rmt/h0, with a maximum of three attempts, each 60 seconds apart, enter the following UNIX command:

mgcbackup -d /dev/rmt/h0 -r 3 -t 60


Note You can enter Ctrl-C 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—Name of the Cisco PGW 2200 Softswitch, such as MGC-01.

yyyymmdd—Date on which the backup file is created, in a year-month-day format, such as 20011130.

hhmmss—Time when 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 like 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, press Ctrl-C.


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

The system returns a response like 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 must be 1 to 10 alphanumeric characters in length.


After you enter the name of your automatic backup, the system returns a response like 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 Do not store backup files on your local Cisco PGW 2200 Softswitch. Storing backup files on the local host reduces the amount of available disk space to process call data. Also, it does not ensure that the data is safe if a natural disaster occurs.



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


After you enter your directory path, the system returns a response like 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 like 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 like the following:

Enter the day of the week (default=everyday): 

Step 7 Enter the day or days of the week on which 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 the day or days of the week setting, the system returns a response like the following:

Enter the time (HH:MM):

Step 8 Enter the time at which you want to start the automatic backup operation, in hour:minute format.


Note The range for hour is from 00 to 23, and the range for minute is from 0 to 59.



Note 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 call processing.


After you enter the time setting, the system returns a response like the following:

Save this scheduled backup (Y or N)?

Step 9 Enter Y to add this automatic backup operation, or enter N if you do not want to add an automatic backup operation.


Note Press Ctrl-C at any time to halt the execution of the mgcbackup script.


The system returns a response like the following:

Press enter to continue: 

Step 10 Press Enter to return to the backup schedule menu. You can either exit the utility or schedule another backup activity.


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

mgc_hostname_yyyymmdd_hhmmss_backup

Where:

hostname—Name of the Cisco PGW 2200 Softswitch, such as MGC-01.

yyyymmdd—Date on which the backup file is created, in a year-month-day format, such as 20011130.

hhmmss—Time at which the backup file is created, in an 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 like 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 like 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 to remove from the schedule.

The system returns a response like the following:

Delete this scheduled backup (Y or N)?

Step 4 Enter Y to delete an automatic backup operation, or enter N if you do not want to delete an automatic backup operation.


Note Press Ctrl-C at any time to halt the execution of the mgcbackup script.


The system returns a response like 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 schedule another backup 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 like 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 like 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 to continue to delete all automatic backup operations, or enter N if you do not want to delete all automatic backup operations.


Note Press Ctrl-C at any time to halt the execution of the mgcbackup script.


The system returns a response like 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 schedule another backup 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 like 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 like 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 schedule another backup 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 like 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 beneath the filename.


Step 2 Press enter to return to the backup schedule menu. You can either exit the utility or schedule another backup 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 to back up the software license.


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


To back up a license on the Cisco PGW 2200 Softswitch, you must copy all the files under /opt/CiscoMGC/license to a secure location. To restore the license files on the Cisco PGW 2200 Softswitch, you must copy these saved license files back to the /opt/CiscoMGC/license folder.


Note 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 occurs on the Cisco PGW 2200 Softswitch, the system might generate core dump files, which are stored in the $BASEDIR/var directory. You can review 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 (foverd) 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 The process manager processes the core dump file when it receives a signal from a failed child process. If the process manager dumps the core file, it does not perform the preceding steps.


Regular Operations

This section contains procedures that you can perform on the Cisco PGW 2200 Softswitch. The following sections describe the regular operations:

Managing MML Sessions

Managing Signaling Channels

Managing Bearer Channels

Managing SIP Communications

Provisioning a Cisco PGW 2200 Softswitch

Managing a Cisco PGW 2200 Softswitch Platform

Managing System Measurements

Managing Call Detail Records

Using the Cisco MGC Viewer Toolkit

Managing MML Sessions

The following sections describe the operations that you can use to manage an MML session:

Displaying Previously Entered MML Commands

Displaying Information About MML Commands

Re-entering Previously Entered MML Commands

Retrieving Active MML Sessions

Ending an MML Session

Displaying Previously Entered MML Commands

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 system displays the last MML command that was entered.

To redisplay the last MML command that was entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the h command.

h

The system returns a response like 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 h::number command:

Where number is the number of the MML command you want to display. The last MML command that you entered is 1; the command you entered before that is 2, and so on.

For example, to redisplay the 10th-most-recently entered MML command, enter the h::10 command.

The system returns a response like 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 commands that you entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the h:: start_num, end_num command.

Where:

start_num—Number of the first MML command you want to display. The last MML command that you entered is 1; the command you entered before that is 2, and so on.

end_num—Number of the earliest MML command you want to display.

For example, to redisplay all of the commands from the second to the 5th-most-recently entered MML commands, enter the h::2, 5 command:

The system returns a response like 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

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 help: command_name command.

Where command_name is the name of the MML command for which you want information.

For example, if you want information on the set-log MML command, enter the help:set-log command:

The system returns a response like 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 this log 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 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.

   ;

Re-entering Previously Entered MML Commands

Use the r MML commandto re-enter an MML command, either a specific MML command or the last MML command you entered.

To re-enter the last MML command that you entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the r command:

The system returns a response appropriate to the previously entered command. For example, if the previously entered command was rtrv-spc:all, the system returns a response like the following:

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 re-enter a particular MML command that you entered, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the r::number command:

Where number is the number of the MML command you want to re-enter. The last MML command that you entered is 1, the command that you entered before that is 2, and so on.

For example, to re-enter the 10th-most-recently entered MML command, 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 rtrv-mml command.

The system returns a response like 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

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 with the Reliable User Datagram Protocol (RUDP) that is proprietary to Cisco.

Facility Associated Signaling (FAS)—Found in ISDN PRI or DPNSS over a 64-Kbps channel. Some form of Link Access Protocol (LAP), for example Q.921, provides reliable delivery.

FAS over IP (FAS/IP)—Same as FAS, but uses IP as its transport mechanism. Q.921 LAPD or RUDP/SM provides reliable delivery.

Media Gateway Control Protocol (MGCP)—Signaling channel, which uses UDP/IP, provides reliable delivery.

The following sections describe the information that the system returns 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

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 to in-service (IS) by using the set MML commands.

IS

In-service

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

MOOS

Manually out-of-service

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

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

State of the signaling channel is currently being changed.

UNK

Unknown

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 presented in the following list:

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 following sections describe the operations that you can use to manage signaling channels:


Note To ensure that you are retrieving the correct service states of the signaling channels, always perform the following retrieval procedures 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 because of 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 task 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 rtrv-dest: sig_srv command:

Where sig_srv is the MML name of a signaling service.

The system returns a response like 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 6-103.


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 rtrv-c7lnk: C7_linkname | c7_linksetname command:

For example, to retrieve the service state for an SS7 link called c7link1, enter the command:

rtrv-c7lnk:c7link1

The system returns a message like 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 rtrv-c7lnk: all command:

The system returns a message like 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 6-105.

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 rtrv-iplnk:iplink_name command:

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 like 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 rtrv-iplnk:all command:

The system returns a message like 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 6-105.

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 rtrv-iproute:iproute_name command:

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 like 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 rtrv-iproute:all command:

The system returns a message like 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 6-106.

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 state 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 because of 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 rtrv-dchan:dchan_name command:

For example, to retrieve the service state for the D-channel that is 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 like 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 like 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 rtrv-dchan:all command:

The system returns a message like 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 6-106.

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 rtrv-spc:ss7_sig_srv command:

Where SS7_sig_srv is the MML name for the associated SS7 signaling service.

The system returns a response like 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 rtrv-spc:all command:

The system returns a response like 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 6-104.

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 rtrv-rte:dpc command:

Where dpc is the MML name for the associated destination point code (DPC).

The system returns a response like 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 rtrv-rte:all command:

The system returns a response like 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 6-103.

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 rtrv-lssn:all command:

The system returns a response like 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 6-107.

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 rtrv-association:assoc_name command:

For example, to retrieve the service state of an association called assoc1, enter the following command:

rtrv-association:assoc1

The system returns a message like 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 rtrv-association:all command:

The system returns a message like 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 6-122.

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) by using the set-iplnk MML command.

IS

In-service

Association is IS and fully operational. This state 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 because of a configuration failure.

COOS

Commanded out-of-service

Association has been set to 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 rtrv-tcap-trans command:

The system returns a response like 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 specified period, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the clr-tcap-trans::t=number command:

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, enter the following command:

clr-tcap-trans::t=60

Enabling Group Service Reset Messages

Occasionally, you might 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. Modifying these properties can enable the Cisco PGW 2200 Softswitch to synchronize its bearer channel blocking state with the blocking state 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 Do not enable the Cisco PGW 2200 Softswitch to send GSR messages.


Note You can use the CMM or the VSPT to enable the sending of GSR messages on your system. See 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 that you want to send GRS messages.

For example, to enable the sending of GRS messages on an SS7 signaling service named ss7svc1, 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 that 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

Retrieving DPNSS Virtual Bearer Channel Status

Blocking CICs

Retrieving the Administrative State

Retrieving DPNSS Virtual Bearer Channel Status

Verifying Proper Replication of Calls

Perform the steps in the following procedure to ensure that the standby Cisco PGW 2200 Softswitch becomes fully operational and that it is replicating calls in progress completely:


Caution The following command retrieves the status of all provisioned traffic channels. If you have many traffic channels, consider limiting the command to a subset of the provisioned channels, perhaps according to signaling-service-by-signaling-service. For example, to see just the provisioned channels for a signaling service named ss7svc2, 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 rtrv-tc:all command:

Depending on the release of the Cisco PGW 2200 Softswitch software you are running and the type of configuration you are using on the associated media gateway, the system returns a different set of responses.

When the Cisco PGW 2200 Softswitch software is configured for signaling, the system returns a response like 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 like 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 preceding procedure for that system.


Caution Switchover operations cause the loss of all SS7 messages that are transmitted to the Cisco PGW 2200 Softswitch for approximately 3 seconds. This switchover 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 of bearer channels that are associated with one or more signaling destinations that are being held by a media gateway, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the rtrv-tc-held:sig_dest| &sign_dest...command:

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 that are associated with the specified signaling destinations are being held by a media gateway, the system returns a response like 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 that are associated with the specified signaling destinations are being held by a media gateway, the system returns a response like 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 that are held by a media gateway, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the rtrv-tc-held:all command:

When none of the bearer channels are being held by a media gateway, the system returns a response like 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 like 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 might need to block a CIC or a range of CICs on your Cisco PGW 2200 Softswitch. Blocking a single CIC sends a BLA message to the destination SSP. Blocking a range of CICs sends a CGB message 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 the active Cisco PGW 2200 Softswitch, start an MML session, and enter the blk-cic:sig_srv:CIC=number command:

Where:

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

number—Number of the CIC you want to block.

For example, to block CIC number 1, which is associated with a signaling service called ss7svc1, enter the blk-cic:ss7svc1:cic=1 command:

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

Where:

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

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

range—Specifies the end of the range of CICs to block.


Note You can configure the Cisco PGW 2200 Softswitch software 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 you configure an ISUP signaling service to issue individual supervision messages, use of the range option issues individual supervision messages 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, enter the following command:

blk-cic:ss7svc:cic=1,rng=20

To verify that the CICs 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 CICs to service, you must unblock the CICs as described in the "Unblocking CICs" section on page 6-139.

Retrieving the Administrative State

The administrative state refers to the state of CICs (on the Cisco PGW 2200 Softswitch) and spans bearer channels (on the associated media gateway). There are three possible states: locked, unlocked, and shutdown. 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 that are 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 an object that consists of groups of CICs or spans bearer channels, you receive an inferred target state that is 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.

To change the administrative state of a component, see the "Setting the Administrative State" section on page 6-124.

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 rtrv-admin-state:mgc command:

Where mgc is the MML name of the Cisco PGW 2200 Softswitch.

The system returns a response like the following:

Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "mgca:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"

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 6-124.

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 rtrv-admin-state:gateway command:

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 like the following:

Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "mgw1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"

To change the administrative state of the media gateway, see the "Setting the Administrative State of a Media Gateway" section on page 6-125.

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 rtrv-admin-state:trkgrp command:

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 like the following:

Media Gateway Controller  - MGC-03 2000-02-17 14:27:52
M  COMPLD
   "trunkgrp1:PST=UNLOCK,LOCK=0,UNLOCK=384,SHUTDOWN=0"

To change the administrative state of the trunk group, see the "Setting the Administrative State of a Trunk Group" section on page 6-125.

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 rtrv-admin-state:sig_srv command:

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 that is associated with a DPC.

EISUP signaling service.

The system returns a response like 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 change the administrative state of the signaling service, see the "Setting the Administrative State of a Signaling Service" section on page 6-126.

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 rtrv-admin-state:sig_srv,span=x command:

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 that is associated with a DPC.

EISUP signaling service.

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

For example, to determine the administrative state of span number 2 that is associated with a signaling service called ss7svc1, enter the rtrv-admin-state:ss7svc1,span=2 command:

The system returns a response like 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 rtrv-admin-state:sig_srv,span=x,bc=y[,rng=range] command:

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 that is associated with a DPC.

EISUP signaling service.

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

y—Numeric value that identifies the non-ISUP bearer channel number.

range—Value such that y+range is a valid bearer channel number. The system retrieves the administrative state for all bearer channels between y and y+range.

For example, to determine the administrative state of bearer channel numbers 2 through 6, associated with a signaling service called ss7svc1, enter the rtrv-admin-state:ss7svc1,span=2,bc=2,rng=5 command:

The system returns a response like 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 change the administrative state of the spans, see the "Setting the Administrative State of Spans" section on page 6-127.

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 rtrv-admin-state:sig_srv,cic=number[,rng=range] command:

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 that is associated with a DPC.

EISUP signaling service.

number—Valid CIC number.

range—Value such that y+range is a valid CIC number. The system retrieves the administrative state for all CICs between y and y+range.

For example, to determine the administrative state of CICs 2 through 11 associated with a signaling service called ss7svc1, enter the rtrv-admin-state:ss7svc1,cic=2,rng=9 command:

The system returns a response like 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 change the administrative state of the CICs, see the "Setting the Administrative State of CICs" section on page 6-128.

Retrieving DPNSS Virtual Bearer Channel Status

You can retrieve the status of DPNSS virtual 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, enter the rtrv-virt-tc:dpnss-path MML command:

Where:

VTC—Virtual channel number.

CALL—Status of the call: IDLE, IN, or OUT (call direction).

PST—Primary state. Valid values are:

AOOS—Resource has been taken out of service by the system.

INB—Installed busy (resource has been created but not yet commanded IS or OOS with 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. You can use many of the procedures that are defined for signaling channels and bearer channels to manage SIP communications. Use the following procedures strictly for 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) endpoint, you might 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.

Step 2 Start an MML session.

Step 3 Enter the sta-dns-info:sippath_name: "URL | cache_entry_name | null_string" command:

Where:

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

URL—Associated world-wide-web (www) address. If you enter the associated URL in this command, the command in Step 4 displays the IP address and the time-to-live (TTL) values.

cache_entry_num—DNS cache entry number. If you enter the associated cache entry number in this command, the command in Step 4 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 4 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 that is 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 4 Request the contents of the specified DNS cache that is associated with an SIP signaling service. To issue this request, enter the rtrv-dns-info:sippath_name command:

Where: sippath_name—MML name of the SIP signaling service that 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 like 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 like 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 like 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

To purge the DNS cache, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the sta-dns-purge:sippath_name command:

Where:

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

For example, to purge the DNS cache that is associated with the signaling service, sipsigpath, enter the sta-dns-purge:sipsigpath command:


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 to use the command 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 rtrv-sip:type [timerperiod=min | detail] command:

Where:

type—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 period, 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 SIP-to-SIP calls that have excessive durations, you can cancel those calls using the procedure that is described in the "Stopping SIP-to-SIP Calls" section on page 6-155.


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 that is 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 you enter the standard version of this command, the system returns a response like 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 you enter this command with the optional command to provide detailed call data, the system returns a response like 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 the rtrv-callinfo command 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 rtrv-callinfo:target [:mateprottype][,calltime][,detail] command:

Where:

target—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—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 period, 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 you enter this command with the optional command to provide detailed call data, the system returns a response like 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 a Cisco PGW 2200 Softswitch

The following sections describe the operations that you can use to provision the 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

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

Starting a Provisioning Session

To start a provisioning session, log into the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-sta::srcver="curr_ver",dstver="mod_ver" command:

Where:

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

new—New default configuration session; 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, you cannot use new as the source configuration once a provisioning session has been saved and activated by using prov-cpy or prov-dply. After 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—New configuration version name that contains your provisioning changes.

For example, to use a configuration version called ver1 as the basis for a version that you want to call ver2, 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. To add components to your system, see Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide. 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 save and activate changes: prov-cpy and prov-dply.


Caution Using the prov-cpy and prov-dply MML commands can severely impact your system call processing performance, depending on the extent of your provisioning changes. Enter these commands only during a maintenance window when traffic is minimal.

The prov-cpy MML command saves and activates your changes on the active
Cisco PGW 2200 Softswitch. Typically, this command is 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 use prov-cpy, you should enter the prov-sync MML command immediately afterwards to save and activate your changes on the standby Cisco PGW 2200 Softswitch.


Note To add new signaling links or CICs to the signaling links and CICs previously provisioned, enter the prov-cpy command. To save the new signaling links and CICs to the standby
Cisco PGW 2200 Softswitch, enter 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 after the prov-sync command completes the synchronization.



Caution Using the prov-sync MML command can severely impact your system call processing performance. Enter the prov-sync command during a maintenance window when traffic is minimal.


Note When you use the prov-sync MML command 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, the provisioning session automatically ends. To make additional provisioning changes, start a new provisioning session as described in the "Starting a Provisioning Session" section.


Enter the prov-dply MML command to save and activate your changes on the active and standby
Cisco PGW 2200 Softswitches. Typically, you use this command to save and activate changes on Cisco PGW 2200 Softswitches in high-availability or continuous-service configurations. Do not use this command on a Cisco PGW 2200 Softswitch in a simplex configuration.


Note When you enter the prov-dply command, your provisioning session automatically ends, unless an error occurs during execution. To make additional provisioning changes, start a new provisioning session as described in the "Starting a Provisioning Session" section.


Ending a Provisioning Session Without Activating your Changes

To end a provisioning session, without saving and activating the changes made during your session, enter the prov-stp MML command. This command ends the current provisioning session and the changes are not entered.

Invoking Dynamic Reconfiguration

You can dynamically reconfigure, that is modify or delete, selected components that you have provisioned on the 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 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 reconfigure dynamically.


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 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 that is 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. You can perform dynamic reconfiguration without shutting down or restarting either the Cisco PGW 2200 Softswitch software or the Sun host platform.

The following list presents the Cisco PGW 2200 Softswitch component types that you can dynamically reconfigure. You cannot dynamically reconfigure any other component types.

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-13 lists the preconditions that you must establish for the component before you can perform any modification or deletion 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 6-103).

or

Block type for the CIC must be set to locally blocked (see the "Blocking CICs" section) and the associated media gateway span and time slot 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 6-103).

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 6-105).

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 6-104).

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 6-107).

Trunk groups

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

None.


For example, 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. In this phase, all of the processes load the new configuration data. At the beginning of the update phase, the system displays an SNMP alarm to indicate that the update is starting. At the end of the update phase, the alarm clears, and if MML initiated commit or deploy, the system returns the MML response.

To change the current configuration of a component using dynamic reconfiguration, you can use only the provisioning tools that are 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 cross check 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 following sections describe how to use this command to retrieve provisioning data:

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 retrieve provisioning data, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-rtrv:component:name=MML_name command:

Where:

component—MML component type that is 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—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 that is called opc, enter the prov-rtrv:opc:name="opc" command:

The system returns a response like 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 depends upon the component type that is associated with the desired component.

For example, to view the properties for an SS7 signaling service that is called ss7svc1, you would enter the prov-rtrv:sigsvcprop:name="ss7svc1" command:

The system returns a response like 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 selected components that are provisioned on your system. To retrieve data on selected components, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-rtrv:all command:


Note This command returns data on all signaling components, except for signaling service and linkset properties.


The system returns a response like 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 retrieve data on all components of a type, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-rtrv:component:"all" command:

Where:

component is the MML component type that is associated with the desired provisioned component group. You can find a complete list of MML component types in
Cisco PGW 2200 Softswitch Release 9 MML Command Reference.


Note You cannot use the prov-rtrv command to retrieve signaling or routing properties (that is sigsvcprop, lnksetprop, and trnkgrpprop). You can list the properties for only one signaling or routing component per command instance. Please use the following format:

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

Where:

propComp—MML component name that corresponds to the property type that you want to retrieve, as presented in the following list:

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 that is associated with the desired linkset.


For example, to view the provisioning data for all DPCs, enter the prov-rtrv:dpc:"all" command:

The system returns a response like 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 retrieve provisioning data on the current session, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-rtrv:session command:

The system returns a response like 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 retrieve protocol data, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-rtrv:variants command:

The system returns a response like 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 the Cisco PGW 2200 Softswitch by using the following commands. For more information on provisioning and maintaining dial plans, see 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 that are contained in those files in batch mode to copy the setup 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—Directory path to the location of the exported provisioning data files.

filename—Name of the provisioning data file you want to import.

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

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

2. export_trunks.dat—Created only when trunks are configured on your system

3. export_trkgrp.dat—Created only when trunk groups are configured on your system)

4. routing.mml—Contains routing plans

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

For example, to import the provisioning data that is stored in the config.mml file, which is located in the /opt/ CiscoMGC/etc/cust_specific/saved_config directory, 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 currently provisioned setup of the Cisco PGW 2200 Softswitch in MML-command form to a file or files. This export enables 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 restore a Cisco PGW 2200 Softswitch to a baseline provisioning environment. See the "Importing Provisioning Data" section for information on importing the provisioning data that the prov-exp MML command created.

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

Where:

tid—Types of data. The following list presents the data types:

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 that is specified on your system. The filename depends on the customer group ID for each dial plan; that is, the filename conforms to the format custGrpID.mml.

trkgrp—Trunk group data only.

trunk—Trunk data only.

allEntire 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 that is 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, enter the prov-exp:config:dirname="saved_config" command:

To export all of the current configuration of the Cisco PGW 2200 Softswitch to several files, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-exp:all:dirname="eport_directory_name" command:

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 that is established at installation.

When you enter the prov-exp command, the system creates the following files in the specified directory:

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. The filename includes 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 that are stored in the /opt/CiscoMGC/etc/ cust_specific saved_config directory, enter the prov-exp:all:dirname="saved_config" command:

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 processed effectively. The regulation requires 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, it rejects a user-defined percentage of calls (depending on internal overload level) and sends an ISUP release message 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 that is 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 that is offered by rerouting calls or by rejecting a percentage of the calls. This response to congestion 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, size of queues and buffers, or amounts of other resources that are needed for call processing. This detection of congestion 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 by rejecting calls. When call volume causes the Cisco PGW 2200 Softswitch to reach one of its machine congestion levels (MCLs), the system can send ACL indications to the adjacent signaling points and release a percentage of calls that you define.

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 following sections provide the procedures for managing call rejection percentages:

Modifying the MCL Call Reject Settings

Retrieving the MCL Call Reject Settings

The Cisco PGW 2200 Softswitch raises alarms that are associated with three of the MCLs. The Cisco PGW 2200 Softswitch raises an alarm as it detects an MCL. These alarms are automatically cleared when the Cisco PGW 2200 Softswitch exits an MCL. Table 3-15 shows the alarm that corresponds to each which MCL. For more information on these alarms, see
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, as the Cisco PGW 2200 Softswitch detects a transition in congestion from MC1 to MC2 and back, the raising and clearing of alarms progresses 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 that correspond to Cisco PGW 2200 Softswitch 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 Cisco PGW 2200 Softswitch Release 9 Management Information Base Guide.


Modifying the MCL Call Reject Settings

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


Note You can use the Cisco Voice Services Provisioning Tool (VSPT) to modify the MCL call release settings. For more information on using the Cisco VSPT, see 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 that are 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 that is defined by value. Calls are released when the Cisco PGW 2200 Softswitch enters MCL1. The default value is 25.

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

mcl3—Specifies the percentage of calls that is defined by value, Calls 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 so that 30 percent of calls are released when the Cisco PGW 2200 Softswitch detects MCL1, enter the prov-ed:mclcallreject:name="mcl1", callreject=30 command:

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 prov-rtrv:mclcallreject:name="mcl_name" command:

Where:

mcl_name—Name of the MCL setting. The following names are valid:

mcl1

mcl2

mcl3

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

For example, to retrieve the settings for an MCL called mcl1, enter the prov-rtrv:mclcallreject:name="mcl1" command:

The system returns a message like 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 prov-rtrv:mclcallreject:"all" command.

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 might be rerouted or released instead of being sent to congested signaling points.

There are two types of outgoing load congestion controls:

Cancel-to (CANT)—Because of congestion, causes the rejection of a percentage of the traffic that would have been routed to an SS7 signaling path (systems that are configured for signaling) or to a trunk group (systems that are configured for call control).


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


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


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


When applying congestion controls, the CANT control is given precedence over the skip control. Percentages that are 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 that are 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


CANT and skip percentages can be different depending on the type of traffic.

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 that are 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. You can configure only one ACCRC per SS7 signaling path (signaling configurations) or trunk group (call control configurations) that supports outgoing traffic. If you do not assign an ACCRC to an SS7 signaling path or trunk group, the system performs the default ACC response procedures.

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 following list presents the field values for the default ACCRC:

acl1drcant—50

acl1drskip—20

acl1arcant—50

acl1arskip—20

acl2drcant—90

acl2drskip—20

acl2arcant—90

acl2arskip—20

acl3drcant—100

acl3drskip—0

acl3arcant—100

acl3arskip—0

When an adjacent signaling point sends an ACL indication, the Cisco PGW 2200 Softswitch enables the actions that are defined in the ACCRC for a duration that is defined by the configurable ACL timer ACLDur.

The following sections describe how to manage OCL:

Adding an ACC Response Category on a 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 a System Configured for Signaling

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


Note You can use the Cisco VSPT to add an ACCRC. For more information on using the Cisco VSPT, see 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 specifies 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 that is defined in value. Calls are released when an adjacent signaling point sends an ACL indication of 1.

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

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

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


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


For example, to configure an ACCRC called cat1 so 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, 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 add an ACCRC. For more information on using the Cisco VSPT, see Cisco Voice Services Provisioning Tool Users 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 specifies a percentage of calls that are released when an adjacent signaling point sends a congestion indication of a particular ACL level. The following fields can be configured:

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

acl1drskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 1.

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

acl1arskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 1.

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

acl2drskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 2.

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

acl2arskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 2.

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

acl3drskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 3.

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

acl3arskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 3.

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


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


For example, to configure an ACCRC on a trunk group that is called cat1 so that when an ACL indication of 1 is received, 20 percent of direct routed calls are rejected, 20 percent of direct routed calls are rerouted, 10 percent of alternate routed calls are rejected, and 10 percent of alternate routed calls are rerouted, 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 for 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 a trunk group named trunk, 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 a system that is configured for signaling, perform the following steps:


Note You can use the Cisco VSPT to modify an ACCRC. For more information on using the Cisco VSPT, see Cisco Voice Services Provisioning Tool Users 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 specifies a percentage of calls that is released when an adjacent signaling point sends a congestion indication of a particular ACL level. You can modify the following fields:

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

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

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

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

For example, to modify the configuration of an ACCRC called cat1 so that 30 percent of calls are rejected when an ACL of 1 is received, 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 modify an ACCRC. For more information on using the Cisco VSPT, see Cisco Voice Services Provisioning Tool Users 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 specifies a percentage of calls that is released when an adjacent signaling point sends a congestion indication of a particular ACL level. You can modify the following fields:

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

acl1drskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 1.

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

acl1arskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 1.

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

acl2drskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 2.

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

acl2arskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 2.

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

acl3drskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 3.

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

acl3arskip—Specifies the percentage of calls that is defined in value. Calls are rerouted to an alternate trunk group when an adjacent signaling point sends an ACL indication of 3.

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

For example, to modify the configuration an ACCRC on a trunk group that is called cat1 so that 30 percent of calls are rejected when an ACL of 1 is received, 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 delete an ACCRC. For more information on using the Cisco VSPT, see Cisco Voice Services Provisioning Tool Users 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 delete the signaling path, enter the prov-dlt:ss7path:name="comp_name" command:

Where:

comp_name—MML name for the SS7 signaling path 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, enter the prov-dlt:ss7path:name="access1" command:

Step 3 Enter the prov-dlt:accrespcat:name="cat_name" command to delete an ACCRC:

Where:

cat_name—Name of the ACCRC to delete.

For example, to delete an ACCRC called cat1, enter the prov-dlt:accrespact:name= "cat1" command:

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 a system when it is configured for call control, perform the following steps:


Note You can also use the Cisco VSPT to delete an ACCRC. For more information on using the Cisco VSPT, see Cisco Voice Services Provisioning Tool Users 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 delete the trunk group, enter the prov-dlt:trnkgrp:name="comp_name" command:

Where:

comp_name—MML name for the trunk group 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, enter the prov-dlt:trnkgrp:name="access1" command:

Step 3 Enter the following command to delete an ACCRC:

prov-dlt:accrespcat:name="cat_name"

Where:

cat_name—Name of the ACCRC to delete.

For example, to delete an ACCRC called cat1, enter the prov-dlt:accrespact:name="cat1" command:

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 the 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 prov-rtrv:accrespact:name= "cat_name" command:

Where:

cat_name—Name of the ACCRC for which you want settings.

The system lists the settings for each of the ACCRC fields.

For example, to retrieve the settings for an ACCRC called cat1, enter the prov-rtrv:accrespact:name="cat1" command:

The system responds with a message like 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 the system, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the prov-rtrv:accrespact:"all" command:

The system responds with a message like 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 that is associated with an ACCRC on your system when it configured for signaling, perform the following steps:


Note You can use the Cisco VSPT to modify the SS7 signaling path that is associated with an ACCRC. For more information on using the Cisco VSPT, see 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 an SS7 signaling path that 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, enter the prov-ed:sigsvcprop:name= "acces2",ACCRespCatName="cat1" command:

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 that is associated with an ACCRC on your system when it is configured for call control, perform the following steps:


Note You can use the Cisco VSPT to modify the trunk group that is associated with an ACCRC. For more information on using the Cisco VSPT, see 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 trunk group that 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 a trunk group named trunk2, enter the prov-ed:trnkgrpprop:name="trunk2",ACCRespCatName="cat1" command:

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 that are specified for that congestion level on the trunk group or SS7 signaling path. The trunk group or SS7 signaling path is associated with the release message and starts an ACL timer (ACLDur). You can configure the duration of this timer on a trunk group or SS7 signaling path. The default value of the ACLDur timer is 5 seconds. When the ACL timer expires, the system deactivates the congestion controls on the trunk group or SS7 signaling path.


Note You might need to adjust timers depending on the size of your trunk group.


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


Note You can also use the Cisco VSPT to modify the settings for an ACL timer. For more information on using the Cisco VSPT, see 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, enter one of the following:

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

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

comp_name—MML name for the SS7 signaling path or trunk group for which you modify the duration of the ACL timer.

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

For example, to change the duration of the ACL timer to 20 seconds on a trunk group named trunk1, 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

When the Cisco PGW 2200 Softswitch is overloaded and must reduce congestion, it uses Incoming load control (ILC) to regulate incoming traffic. When the Cisco PGW 2200 Softswitch enters and abates the different MCLs, it reroutes or rejects calls according to user-defined settings.

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

The following list presents the measurements of five threshold values that determine the MCLs:

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 physical memory address space that is in use.

Virtual memory address utilization (virtualmemory)—Measures the percentage of virtual memory address space that 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 is 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


The following sections describe ICL:

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, it sends an ACL value to adjacent signaling points in an ISUP release message that is based on the MCL. Because 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. 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 that is specified for that overload level is released. In this case, the associated ISUP release message does not contain an ACL indication. The ISUP release message still indicates the proper clear cause.



Note You can use the Cisco VSPT to map the MCL to the congestion standard used by the adjacent signaling points. For more information on using the Cisco VSPT, see 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, enter one of the following:

sigsvcprop—Component type for signaling path properties, used to map MCL for systems that are configured for signaling.

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

comp_name—MML name for the SS7 signaling path or trunk group for which you map 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 next to a signaling point that uses the ITU congestion standard, enter the prov-ed:trnkgrpprop:name="trunk1",MaxACL=2 command:

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 the 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 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 specifies the onset and abatement values for the selected threshold type. Configure the following fields:

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 that are associated with the cpu, memoryaddress, and virtualmemory threshold types is a percentage, ranging from 0 to 100. The valid value for fields that are 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, to modify the MCL threshold values for the cpu threshold type, enter the following command to set the following values:

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 that are 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 prov-rtrv:mclthreshold:name="thres_type" command:

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 physical memory address space that is in use.

virtualmemory—Measures the percentage of virtual memory address space that is in use.

The system responds lists the values for each of the fields that are associated with the MCL threshold type.

For example, to retrieve the values for the queuelen MCL threshold type, enter the prov-rtrv:mclthreshold:name="queuelen" command:

The system returns a message like 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 Softswitch, start an MML session, and enter the prov-rtrv:mclthreshold:"all" command:

The system responds lists 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 a Cisco PGW 2200 Softswitch Platform

The following sections describe the operations that you can use to manage the 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 the Logging Level of Software Processes

Retrieving System Statistics

Performing a Manual Switchover

In a continuous service configuration, you can swap the roles of the active Cisco PGW 2200 Softswitch and the standby Cisco PGW 2200 Softswitch by issuing the appropriate MML command from the management interface of the active Cisco PGW 2200 Softswitch. You can accomplish a switchover 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 only one Cisco PGW 2200 Softswitch is processing all calls, it will reject a manual switchover request.

Typically, manual switchovers are 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 the call processing performance of the system. All established calls are retained, but any calls in the process of being set up might be dropped. Attempt a manual switchover only during a maintenance period when traffic is minimal.

If you need to order a manual switchover to perform maintenance or upgrade procedures on one or both of the Cisco PGW 2200 Softswitches, complete the following steps or the call engine might delete all calls. 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 that are required to clear any alarms in the "Alarm Troubleshooting Procedures" section on page 6-4. If the alarms do not appear in that section, corrective action is not required for those alarms. See 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 the call processing performance of the system. Enter this command only during a maintenance period when traffic is minimal.

Step 5 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.

Step 6 Check that all 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 Softswitch is fully operational and that debugging is turned off before taking the active Cisco PGW 2200 Softswitch OOS, or there might be a total interruption of service.

A 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


Caution Switchover operations cause the loss of all SS7 messages that are transmitted to the Cisco PGW 2200 Softswitch for approximately 3 seconds. The loss of messages 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 completed successfully. To verify a switchover, follow the procedure that is described in the "Verifying Successful Completion of a Switchover" section.


Verifying Successful Completion of a Switchover

Determine whether a switchover (automatic or manual)is completed successfully by retrieving the status of each Cisco PGW 2200 Softswitch. When all of the processes are active (the time that is required for all processes to start 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 is as expected, the switchover is completed successfully. If one of the Cisco PGW 2200 Softswitches does not return the expected platform state, the switchover did not complete successfully. See the "Recovering from a Switchover Failure" section on page 6-170.

Understanding Switchover

Configure Cisco PGW 2200 Softswitches in an Active-Standby mode. In this mode, one Cisco PGW 2200 Softswitch runs active traffic while checkpointing information to the standby Cisco PGW 2200 Softswitch. In a 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 switchover subsystem is to preserve calls if a system fails. At any given time, one Cisco PGW 2200 Softswitch should be active while the other Cisco PGW 2200 Softswitch is in a 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 (in regard to call-processing) as the active Cisco PGW 2200 Softswitch. In response to 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 3 seconds in which all messaging is lost in the process of switching over call control.


Note If your system is 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 when a critical alarm is generated. Alternatively, you can perform a manual switchover, which typically is part of a maintenance or troubleshooting procedure. For more information on performing a manual switchover, see the "Performing a Manual Switchover" section.


Note When a Cisco PGW 2200 Softswitch temporarily loses IP continuity and causes an automatic switchover, the newly standby Cisco PGW 2200 Softswitch can require as many as 6 minutes to return to the in-service state.


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—Manages 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. ProcM starts the alarm manager, configuration manager, call engine, IOCCs, and other processes, including foverd (the failover daemon).

The failover daemon controls the continuous service architecture. 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 Cisco PGW 2200 Softswitch Release 9 Messages Reference for detailed information about alarms, especially the critical alarms.

The foverd process directs manual switchovers. The switchover configuration provides the following:

Minimal interruption of service if a single machine fails

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 switchover 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 3 seconds, all messaging is lost. This messaging loss 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 switchover on system A is cleared, its state remains OOS. When the critical event is cleared, the alarm manager sends another message (a Clear Alarm message) to the foverd process. The foverd process directs system A to a standby state (if the peer system B is still in the active state).

When the critical event clears, 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 MTP3 IOCC checkpoints the state of the SS7 network. 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 Softswitches (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 depends on the SS7 network traffic load and on link and linkset requirements. Generally, you should have a minimum of two links per linkset. One link per Cisco ITP-L provides SS7 reliability. To further enhance redundancy, you should spread the links in a linkset 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 about 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 if control messages to the bearer devices 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 always initiates automatically upon 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 considers the circuit 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 is in use, the Cisco PGW 2200 Softswitch does not attempt to rebuild the call, but releases all associated resources. Although the Cisco PGW 2200 Softswitch is the controlling authority, when it discovers a discrepancy during a circuit audit, the Cisco PGW 2200 Softswitch releases all allocated resources and drops all calls.

Checkpointing

Checkpointing of calls ensures that established calls are preserved if a switchover occurs. 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 when 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 processing 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)—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)—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—Request synchronization of the configurations of the two Cisco PGW 2200s. This request is required after startup and transition from the standalone Cisco PGW 2200 Softswitch to the standby available configuration.

Switchover—If a switchover occurs, 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. Manually direct 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 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 like 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), whereas 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:

http://www.cisco.com/kobayashi/sw-center/sw-voice.shmtl

Select your software version from the list. 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 the active Cisco PGW 2200 Softswitch.

Step 4 Open the instruction files and follow the procedures to install the patches.

Step 5 Once you have installed the new patches, run the check inventory utility to ensure that the patches installed correctly by entering the following UNIX commands:


Caution Do not run the inventory utility while the system is actively processing calls, because it can reduce the call processing rate.


Note To run the inventory utility, you must have 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 that is 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, 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 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 anomaly occurs, 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 patches, you should determine whether a problem truly exists. The utility compares the software on your system to a master list. It is possible that your environment might not use all of the 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 uses that software, proceed to Step 8.


Step 7 Re-install the patches, repeating Step 3 through Step 6. If your second attempt at downloading and installing the patches succeeds, the procedure is complete. Otherwise, proceed to Step 8.

Step 8 Collect system according to the directions provided in the "Collecting System Data for Cisco TAC" section on page 6-93 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 xviii.


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 rtrv-log:process command:

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), enter the rtrv-log:eng-01 command:

The system returns a response like 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 the processes, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the rtrv-log:all command:

The system returns a response like 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 process requires special treatment. To retrieve the logging level of PM-01, you must specify it individually with the command, as shown in the preceding example.


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 rtrv-ne-health::sys command:

The system returns a message like 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 xviii for more information on contacting the Cisco TAC.

If you detect that alarms are active, you can find the current alarms by using the procedure in the "Retrieving All Active Alarms" section on page 6-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 like 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 single 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, the Cisco PGW 2200 Softswitch sends CRMs to the PBX for each channel to ensure that there are no active calls present in the PBX. The system sends CRMs to ensure that synchronization can be maintained after a link failure on the IP side. These CRMs are treated as active calls, which increases the number of in-progress calls returned by this command.


If the Cisco PGW 2200 Softswitch uses many CPU resources over an extended period, you should contact the Cisco TAC for assistance. See the "Obtaining Documentation and Submitting a Service Request" section on page xviii 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 like 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 single 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, the Cisco PGW 2200 Softswitch sends CRMs to the PBX for each channel to ensure that there are no active calls present in the PBX. The system sends CRMs to ensure that synchronization can be maintained after a link failure on the IP side. These CRMs are treated as active calls, which increases the number of in-progress calls returned by this command.


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

If the response to the command indicates that the system is using 90 percent or more of its disk capacity, you must delete files from your disk drive, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section on page 6-169.

Managing System Measurements

The following sections describe the operations to manage the Cisco PGW 2200 Softswitch system measurements:

Retrieving Measurements

Clearing Measurements

Retrieving Link or Linkset Measurements

Retrieving SS7 Signaling Point Measurements

Retrieving Measurement Thresholds

Modifying Measurement Thresholds

Retrieving Measurements

View and search the measurements results that are stored in the measurements log file using the measurement viewer that is 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.".

The measurement category and component identification number uniquely defines each measurement (or counter). You can retrieve individual measurements using the following MML command from the active Cisco PGW 2200 Softswitch:

rtrv-ctr:comp:"meas_cat"

Where:

comp—MML name of the component. A complete list of components can be found in the Cisco PGW 2200 Softswitch Release 9 MML Command Reference. You can retrieve a list of provisioned components by entering the prov-rtrv:all MML command.

meas_cat—Desired measurement category. You can find a complete list of measurement categories 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 rtrv-ctr:dpc1:"ISUP: XMIT IAM TOT" command:

The system returns a message like 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

The measurement category and component identification number uniquely defines each measurement (or counter). Retrieve individual measurements using the following MML command from the active Cisco PGW 2200 Softswitch:

clr-ctr:comp:"meas_cat"

Where:

comp—MML name of the component. For a complete list of components, see the Cisco PGW 2200 Softswitch Release 9 MML Command Reference. You can retrieve a list of selected provisioned components by entering the prov-rtrv:all MML command.

meas_cat—Desired measurement category. You can find a complete list of measurement categories 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 clr-ctr:dpc1: "ISUP: XMIT IAM TOT" command.

Retrieving Link or Linkset Measurements

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 rtrv-lnk-ctr:link command.

Where:

link is the MML name of the SS7 link.

For example, to view the measurements for a link that is called ls1link1, enter the rtrv-lnk-ctr:ls1link1 command.

The system returns a response like 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 rtrv-lnk-ctr:linkset command:

Where:

linkset is the MML name of the SS7 linkset.

For example, to view the measurements for each link within a linkset that is called ls1, you would enter the rtrv-lnk-ctr:ls1link1 command:

The system returns a response like 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 rtrv-lnk-ctr:all command:


The system returns a response like 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 rtrv-sp-ctr:point_code command:

Where:

point_code is the MML name of the SS7 signaling point.

For example, to view the measurements for a point code that is called dpc2, enter the rtrv-sp-ctr:dpc2 command:

The system returns a response like 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 rtrv-sp-ctr:all command:

The system returns a response like 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 that are 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 rtrv-thres::"meas_cat" command:

Where:

meas_cat is the desired measurement category.

For example, to display the threshold settings for the measurement category, SIP: RETX MSG TOT, enter the rtrv-thres::"SIP: RETX MSG TOT" command:

Text like 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 (86,400 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 rises 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 rises above this value.

The response also shows the clear threshold value (clrthres), the alarm threshold value (almthres), and the alarm category that is associated with the measurement (alarmcat).

Modifying Measurement Thresholds

You can modify the thresholds for the system measurements. To modify the thresholds, enter the following MML command at the active Cisco PGW 2200 Softswitch:

set-thres::cat="meas_cat",interval=seconds,THRES=value

Where:

meas_cat—Measurement category to modify.

seconds—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—Desired threshold value.

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 Cisco PGW 2200 Softswitch Release 9 Billing Interface Guide.

The following sections present procedures for managing CDR log files:

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 convert, including the file path.

filename—Name for the file that is output when this command executes, 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 stops when you enter Control-C.

To convert an archived CDR log file from binary format to CSV format, 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 like 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

View the CDR results that are stored in the CDR log file using the CDR viewer that is 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.

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 convert, including the file path.

filename—Name for the file that is output when this command executes, 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 stops when you enter Control-C.

To convert an archived CDR log file from binary format to a readable format, 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 like 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. Use the Cisco MGC viewer toolkit to view different types of files on the Cisco PGW 2200 Softswitch. This section describes the toolkit and its various components.

The Cisco MGC viewer toolkit includes a suite of viewing tools that run on the Cisco PGW 2200 Softswitch to provide quick and efficient access to diagnostic and troubleshooting information.

The following sections describe the listed viewers:

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 GUI application that is 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 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 Foreground (text) and background (non-text) settings can conflict if your local display settings conflict with the toolkit color settings. This conflict can render the text within various fields in the toolkit applications unreadable.

If you have problems reading text on any of the toolkit screens, 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, set your display to 1024 pixels.



Note If you are using the xterm server to log into 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 system displays the MGC Toolbar window.

Using the Alarm Viewer

The alarm viewer enables you to 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, then select ReadMe. The help text appears. You can also access a listing of the current alarm log files by clicking 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 To open the alarm viewer, click Alarm Viewer on the Cisco MGC toolbar. A popup window displays, which warns you that running this tool can affect system performance, and asks if you want to launch the tool. Click Yes to continue. The Alarm Viewer window loads and displays (as shown in Figure 3-2).

Figure 3-2 Alarm Viewer Window

Step 2 To view current alarms as they occur, check the Alarm Continuous<ACTIVE, NEW>,Not Filtered check box. The tool displays the current alarms in the field at the bottom of the viewer. Alarms appear in the field as they occur. To stop displaying current alarms, uncheck the check box.

Step 3 Search for alarms that occurred between dates and times, by specifying month, day, year, hour, and minute settings. Choose a starting date and time from the Start Date/Time drop-down lists. Then choose a stop 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).

If you select the Use Current Time as Stop Time check box, you disable the Stop Date/Time drop-down lists and enable a search until the current date and time.

Step 4 To search by a component, choose a component type from the Component Type drop-down list. To search by a component or to view the entire contents of the files, choose the ALL entry.

From the drop-down list to the right of the Component Type list, choose subcomponents for the component you selected. To specify an individual subcomponent, or to view the entire contents of the files, choose the NO_SPECIFIC entry.

Step 5 To search by an alarm category, select a category type from the alarm category pane. To select one or more alarm categories, click the Select check box and select the alarm categories ( to select multiple categories, hold down the Ctrl key while selecting). To avoid searching by a category, or to view the entire contents of the file), check the ALL check box.

Step 6 Click Execute to search the files within the chosen time frame. The contents display as multicolored text in the field at the bottom of the window. (See Figure 3-2.)

The following list describes the text colors that are associated with each alarm severity level:

Comments—White

Cleared—Green

Information—Blue

Warning—Yellow

Error—Orange

Critical—Red

Step 7 To view the logs that might be associated with an alarm, click Log Viewer. The Log Record View tab window appears (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.

To modify the criteria for the related logs search, click the LogView menu. The LogView menu has two options. One option modifies the name of the log file to search (the log file prefix). The other option modifies the period for which the search occurs (the log time range).

To modify the name of the log file to search, 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 filename. 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 To perform additional searches, repeat Step 2 to Step 6. The color of the text from the old search changes from multicolored to blue. The newly requested search data appears as multicolored text, after the old data. Scroll through the field to view the data you added. If you no longer require the previously requested data, you can clear the display field by clicking Clear before you click Execute. You can also reset the search criteria by clicking Reset.

Step 9 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 the content again, the contents of the field are added to the alarmRec.log file, after the previously saved data. To avoid adding the new search data to the previous data, 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. The system writes CDRs into files that contain information about telephone activity. Also, the system saves CDR files in binary format.


Note For more information on CDRs, see 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 enable users to get a real-time feed of CDRs and call detail blocks (CDBs) from the Cisco PGW 2200 Softswitch. You can route the CDR and CDB data 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 in the $BASEDIR/var/spool directory.

The CDR viewer enables you to view and search CDRs that reside in the CDR logs. The formats of the CDBs and call data elements (CDEs) that comprise CDRs are specified in
Cisco PGW 2200 Softswitch Release 9 Billing Interface Guide. These records are designed for database loading, not for user reading. The CDR viewer can help you understand these records. The CDR viewer also provides useful searching functions that are based on the search criteria you select.


Note Your screen might be slightly different from this example, depending on the 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 view and search CDR files, complete the following steps:


Step 1 To open the CDR viewer, click CDR Viewer on the Cisco MGC toolbar. A popup window warns you that running this tool can affect system performance and asks 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).

You cannot modify the first five fields in the window. These fields list the directory paths and filenames for the related data files.

Step 3 To modify the CDR source directory on your local host, click in the CDR Data Directory field and change the displayed information.

Step 4 You can specify the message types to query. By default, the tool enables querying all message types.

To filter out certain message types, select these message types from the All Possible Message Types field and click the right arrow button. The CDR viewer displays the selected message types in the Selected filtering field.

To remove a message type from the Selected filtering field, select that message type and click the left arrow button.

Figure 3-4 Config Tab Window


Searching the CDR Files

To search the various CDR files by component and category, complete the following steps:


Step 1 To open the CDR viewer, click CDR Viewer on the Cisco MGC toolbar. A popup window displays. The window warns you that running this tool can affect system performance and asks you if you want to launch the tool. Click Yes to continue. By default, the CDR Viewer window loads and displays the Query tab window (Figure 3-5).

If you 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 alarms that occurred between dates and times, by specifying month, day, year, hour, and minute settings. To conduct a search, choose a starting date and time from the Start Date/Time drop-down list boxes. Then choose a stop 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 default values results in a null search (no records).

If you select the Use Current Time as Stop Time check box, you disable the Stop Date/Time drop-down lists and enable a search until the current date and time.

Step 3 To view your selected CDR files in their entirety, proceed to Step 7.

To search through your selected CDR files for particular types of CDRs, proceed to Step 4.

Step 4 You can search through your selected CDR files according to the following seven field values:

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 many field values as you require.

Step 5 Enter a search qualifier and a related string for each field value that you select. Choose a search qualifier for the search string from the drop-down list box that is located to the right of the field value you select. The following list presents the search qualifiers:

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 that is 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 chose.

Repeat this step for all field values that you select 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 select (AND), or you can search for CDBs that have any of the field values you select (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 period. A popup window displays while the contents load. The contents display as multicolored text in the field at the bottom of the window.

Step 8 To perform additional searches, repeat Step 2 to Step 7. The color of the text from the old search changes from multicolored to black. The viewer inserts the newly requested search data as multicolored text after the old data. Scroll through the field to view the data you added. If you no longer require the previously requested data, clear the display field by clicking Clear before you click Execute. You can reset the search criteria by clicking Reset.

Step 9 To save the displayed data, click Save. The viewer saves the contents of the field to the file you specified in the Config tab window.

If you perform another search and save that content, the viewer adds the contents of the field to the same file, after the previously saved data. If you do not want to add the data 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 the 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 perform the following functions:

List Configuration Versions in Library—Returns a list of the configuration versions that are 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 use as the production version.


Note Do 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 delete.

Using the Log Viewer

The log viewer enables 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 6-170. For a listing of the platform log messages,
see Cisco PGW 2200 Softswitch Release 9 Messages Reference.

You can see a listing of the current log filenames by clicking the File menu and selecting the Log List option. 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 To open the log viewer, click Log Viewer on the Cisco MGC toolbar. A popup window displays. The window warns you that running this tool can affect system performance and asks if you want to launch the tool. Click Yes to continue. The Log Viewer window loads and displays (see Figure 3-7).

Figure 3-7 Log Viewer

Step 2 You can search for alarms that occurred between dates and times, by specifying month, day, year, hour, and minute settings. To conduct a search, choose a starting date and time from the Start Date/Time drop-down list boxes. Then choose a stop 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).

If you select the Use Current Time as Stop Time check box, you disable the Stop Date/Time drop-down lists and enable a search until the current date and time.


Note You can clear the query options that you select at any time by clicking Reset Query Options.


Step 3 To view all of the logs within the time range you specified in Step 3, click the Show All check box. If you choose this option, your search can be based only 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 specified, proceed to Step 4 to further refine your search criteria before displaying the logs.

Step 4 To search for logs within certain log categories, 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 following list presents the available categories:

GEN

ENV

TIOS

CP

PROT

MGMT

MML

Step 5 To search for logs of certain severities, 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 that you select 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 Search for logs that contain certain text strings. You can search for up to two text strings. To conduct a search, enter the desired search strings in the Text String fields. The text is case-sensitive. The viewer allows all characters.

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.

To search using two text strings, enter your strings in the upper and lower Text String fields.

To search for logs that contain both of your text strings, select the And check box. 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 that is used in your text strings, 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 like 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 affect 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. To stop a search in progress, click Stop Query in the dialog box.


Note Stopping the query can take several seconds.


Your results might include several pages of information. You can use several buttons to navigate through the results. To go to the end of the results, click Bottom. To go to the next page of results, click More. To go to the beginning of the results, click Top.

Step 9 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 filename for your data in the File Name field and click Save.

Step 10 To perform additional searches, repeat Step 2 to Step 9. The old search data is appended to the new search data. Clear the display field by clicking Clear before you click Execute Query.


Using the Measurement Viewer

The measurement viewer enables you to 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. The help text displays. You can also see a list of the current measurement logs by choosing File > Measurement List. You can exit the measurement viewer in 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 To open the measurement viewer, click Measurement Viewer on the Cisco MGC toolbar. A popup window displays. The window warns you that running this tool can affect system performance and asks if you want to launch the tool. Click Yes to continue. The viewer displays the Measurement Viewer window (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 set up a search, 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 default values results in a null search (no records).


b. Choose a stop date and time from the Stop Date/Time drop-down lists.


Note If you select the Use Current Time as Stop Time check box, the viewer disables the Stop Date/Time drop-down list boxes and allows the search to continue to the current date and time.


Figure 3-8 Measurement Viewer Window

c. To refine your search further 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. To refine your search further by specifying a system component type, proceed to Step 3.

To refine your search further by specifying a measurement category type, proceed to Step 4.

To execute a search that is 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 contents of the files, 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 that are configured on your system.


b. To refine your search further 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 instructs the viewer to search for all system components of the chosen component type.


c. To refine your search further by specifying a measurement category type, proceed to Step 4.

To execute a search that is 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 contents of the files, 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 that are associated with that type.


b. To refine your search further 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 instructs the viewer to search for all measurements of the chosen category.


Step 5 Click Execute to search the files within the chosen period. The viewer displays the results of the search as blue text in the field at the bottom of the window.

Step 6 To perform additional searches, repeat Step 2 to Step 5. The color of the text from the old search changes from blue to black. The viewer inserts the new search data in blue text, following the preceding data. Scroll through the field to view the data you added.

If you no longer require the previously requested data, you can clear the display field by clicking Clear before you click Execute. You can also reset the search criteria by clicking Reset.

Step 7 To save the displayed data, click Save. The viewer saves the contents of the field 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 contents, the viewer adds the contents of the field to the measRec.log file, after the previously saved data. If you do not want to add the new search data 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. Click Trace Viewer in the Cisco MGC toolbar to open the Traces Files window. The Trace Files window lists the call trace files that you can choose (Figure 3-9). When you select a file, click View to open the Trace Viewer window (Figure 3-10). In the Trace Viewer window, you can select various call trace activities. For more information about call traces, see the "Performing a Call Trace" section on page 6-156.

Figure 3-9 Trace Viewer Window

Figure 3-10 Trace Viewer Window

Using the Translation Verification Viewer

The translation verification viewer enables you to interface with the translation verification tool. The translation verification tool provides a way to understand how the Cisco PGW 2200 Softswitch processes calls based on the configured dial plan. This tool creates a simulation of the processing of a call. Use this tool on a system that is 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 To open the translation verification viewer, click Translation Verification on the Cisco MGC toolbar. A popup window displays. The popup window warns you that running this tool can affect system performance and asks 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 Enter the incoming trunk group number for your simulated call in the trunk group number field.

Step 3 Specify an ISDN preference for the selection of an 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 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 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.

The result of the trace appears like the following example:

>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 default values are being used. This trace type is suited for determining the results that the viewer used to produce the outgoing numbers and trunk group.

The following 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 that are generated during generic analysis. This trace type is suited for determining where in the dial plan or number analysis problems occurred.

The following 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 the elements of your dial plan that you need to modify, if necessary.

Step 9 Click Execute to perform a dial plan translation verification. The viewer displays results in the field at the bottom of the window.

Step 10 To verify additional dial plan translations, repeat Step 2 to Step 9. The newly requested data is inserted after the old data. Scroll through the field to view the data you added. If you no longer require the previously requested data, you can clear the display field by clicking Clear before you click Execute.

Step 11 To save the displayed data, click SaveinFile. The viewer saves the contents of the field 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 To open the translation verification viewer, click Translation Verification on the Cisco MGC Toolbar. A popup window displays. The popup window warns that running this tool can affect system performance and asks 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 reveal the directory paths to the files used by this viewer. You cannot modify the values in these fields.

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 that the various toolkit applications created. The MML export feature creates subdirectories, which contain configuration information in the form of MML commands.


Note You cannot use the file options viewer to delete files in 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 back up the software configuration of the 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 the 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 6-177.

Figure 3-15 illustrates the main window for the MGC restore viewer.

Figure 3-15 MGC Restore Viewer Window