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

Table Of Contents

Cisco PGW 2200 Softswitch Platform Operations

Daily Tasks

Starting an MML Session

Verifying the Platform State of the Cisco PGW 2200 Softswitches

Verifying That Processes Are Running

Understanding Processes

Monitoring the Alarms Status

Understanding Alarms

An Alarm Example

Verifying the Status of all Signaling Services

Understanding the Signaling Service State Information

Verifying State of all SS7 Routes

Understanding the SS7 Route State Information

Verifying CIC States

Understanding CIC States

Verifying System Statistics

Verifying the Number of Active Processes

Verifying the Number of Users

Verifying Available Virtual Memory

Verifying Available Memory on the Cisco ITP-Ls

Periodic Maintenance Procedures

Automatic Disk Space Monitoring

Configuring Disk Monitor

Automatic System Log Rotation

Rotating System Logs Manually

Creating a Disaster Recovery Plan

Backing Up System Software

Backup Procedures for Cisco PGW 2200 Softswitch Software

Processing a Core Dump File

Regular Operations

Managing MML Sessions

Displaying Previously Entered MML Commands

Displaying Information About MML Commands

Reentering Previously Entered MML Commands

Retrieving Active MML Sessions

Ending an MML Session

Managing Signaling Channels

Retrieving Signaling Service States

Retrieving Service State of C7/SS7 Links or Linksets

Retrieving the Service State for IP Links

Retrieving the Service State for IP Routes

Retrieving the Service State of D-Channels

Retrieving the State of SS7 Signaling Services

Retrieving the State of SS7 Routes

Retrieving the State of All Local Subsystem Numbers

Retrieving the Service State for Associations

Retrieving TCAP Transactions

Clearing TCAP Transactions

Enabling Group Service Reset Messages

Managing Bearer Channels

Verifying Proper Replication of Calls

Retrieving the States of Bearers Held By a Media Gateway

Blocking CICs

Retrieving the Administrative State

Managing SIP Communications

Managing the DNS Cache

Retrieving SIP Call Information

Provisioning your Cisco PGW 2200 Softswitch

Starting a Provisioning Session

Saving and Activating your Provisioning Changes

Ending a Provisioning Session Without Activating your Changes

Invoking Dynamic Reconfiguration

Retrieving Provisioning Data

Provisioning a Dial Plan

Importing Provisioning Data

Exporting Provisioning Data

Managing Automatic Congestion Control

Managing your Cisco PGW 2200 Softswitch Platform

Performing a Manual Switchover

Verifying Successful Completion of a Switchover

Verifying the Patch Level of the Cisco PGW 2200 Softswitch

Retrieving the Logging Level of Software Processes

Retrieving System Statistics

Managing System Measurements

Retrieving Measurements

Clearing Measurements

Retrieving Link or Linkset Measurements

Retrieving SS7 Signaling Point Measurements

Retrieving Measurement Thresholds

Modifying Measurement Thresholds

Managing Call Detail Records

Converting Individual CDR Files to ASCII Format

Converting Individual CDR Files to a Readable Format

Using the Cisco MGC Viewer Toolkit

Launching the Cisco MGC Toolbar

Using the Alarm Viewer

Using the Call Detail Record Viewer

Using the Config-Lib Viewer

Using the Log Viewer

Using the Measurement Viewer

Using the Trace Viewer

Using the Translation Verification Viewer

Using the File Options Viewer

Using the MGC Backup Viewer

Using the MGC Restore Viewer

Cisco PGW 2200 Softswitch Platform Operations

Revised: July 22, 2009, OL-0800-10

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

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

This chapter contains the following sections:

•Daily Tasks

•Periodic Maintenance Procedures

•Regular Operations

Daily Tasks

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

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

•Starting an MML Session

•Verifying the Platform State of the Cisco PGW 2200 Softswitches

•Verifying That Processes Are Running

•Monitoring the Alarms Status

•Verifying the Status of all Signaling Services

•Verifying State of all SS7 Routes

•Verifying CIC States

•Verifying System Statistics

•Verifying the Number of Active Processes

•Verifying the Number of Users

•Verifying Available Virtual Memory

•Verifying Available Memory on the Cisco ITP-Ls

Starting an MML Session

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verifying That Processes Are Running

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

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

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

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

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

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

Understanding Processes

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

Three different monitoring levels are offered:

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

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

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

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

Table 3-1 Processes Controlled by the Process Manager

Group

Process

Description

ENGG-01

Engine Group

Replic-01

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

ENG-01

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

IOSG-01

I/O Subsystem Group

IOCM-01

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

TCAP-01

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

pril3-1

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

mgcp-1

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

h248-1

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

sip-1

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

eisup-1

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

ss7-i-1

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

m3ua-1

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

sua-1

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

iua-1

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

XEG-01

Execution Environment Group

CFM-01

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

ALM-01

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

AMDMPR-01

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

MM-01

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

CDRDMPR-01

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

MMDB-01

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

POM-01

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

FTG-01

Failover Group

FOD-01

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

PFMG-01

Platform Monitoring Group

DSKM-01

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

LMAGT-01

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

SNMPG-01

SNMP Group

MEASAGT

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

OPERSAGT

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

Monitoring the Alarms Status

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

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

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

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

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

Understanding Alarms

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

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

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

Time Stamp

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

Alarm Category

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

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

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

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

Severity Level

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

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

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

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

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

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

An Alarm Example

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

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

Details for this alarm

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

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

Alarm Log

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

Verifying the Status of all Signaling Services

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

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

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

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

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

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

Understanding the Signaling Service State Information

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

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

Package

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

Association

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

Primary Service State

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

Table 3-2 Signaling Service Primary Service States

Link State ID

Link State

Description

AOOS

Automatically out-of-service

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

INB

Install busy

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

IS

In-service

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

MOOS

Manually out-of-service

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

OOS

Out-of-service

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

TRNS

Transient

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

UNK

Unknown

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

Secondary Service State

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

•CEA—Commanded into emergency alignment.

•CIS—Commanded in service.

•CONG—Congestion.

•COOS—Commanded out of service.

•CINH—Commanded to the inhibited state.

•CRTE—Created.

•CUINH—Commanded to the uninhibited state.

•DLT—Deleted.

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

•EIS—Engine in service.

•EOOS—Engine out of service.

•FLD—Failed.

•FOOS—Forced out of service.

•RST—Reset.

•RSTO—Restored.

•UND—Undefined.

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

Verifying State of all SS7 Routes

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

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

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

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

Understanding the SS7 Route State Information

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

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

Linkset

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

Adjacent Point Code

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

•apc-1

•apc-2

•apc-3

•apc-4

Originating Point Code

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

•opc-1

•opc-2

•opc-3

•opc-4

Priority

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

Primary Service State

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

Table 3-3 SS7 Route Primary Service States

Link State ID

Link State

Description

AOOS

Automatically out-of-service

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

INB

Install busy

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

IS

In-service

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

MOOS

Manually out-of-service

The SS7 route has been manually taken OOS.

OOS

Out-of-service

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

TRNS

Transient

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

UNK

Unknown

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

Secondary Service State

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

•ACKD—SS7 Acknowledgement delay

•BSNR—SS7 backward sequence number received (BSNR)

•CIS—Commanded in service

•CONF—Configuration failure

•COOS—Commanded out of service

•ENGR—Call engine reset

•ISPEND—In service, pending

•LCNG—Congestion, local

•LINE—Line failure

•LINH—SS7 local inhibit

•LINK—Link failure

•LINS—Linkset failure

•NA—Cause not available

•OOSPEND—Out of service, pending

•PRHB—SS7 prohibited

•RBLK—SS7 remote blocked

•RCNG—Congestion, remote

•RINH—SS7 remote inhibit

•RSTR—SS7 restricted

•SERR—SS7 signal error

•STBY—Cause standby

•SUPPENT—Supporting entity

•TPATH—Traffic path

•UNK—Cause unknown

Verifying CIC States

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

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

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

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

•number—A valid CIC number.

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

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

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

Understanding CIC States

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

Circuit Identification

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

Primary Service State

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

Table 3-4 CIC Primary Service States

Link State ID

Link State

Description

IS

In-service

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

OOS

Out-of-service

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

Call State

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

Table 3-5 CIC Call States

State

Description

In

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

Out

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

Idle

Circuit is available for use.

Media Gateway State

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

Table 3-6 Media Gateway States

State

Description

CARRIER_FAILURE

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

CXN_IS

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

CXN_OOS_ACTIVE

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

CXN_OOS_STANDBY

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

GW_HELD

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

Circuit Block Type

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

Table 3-7 Circuit Block Types

Type

Description

COT_FAIL

Blocked because a continuity test failed on the CIC.

GATEWAY

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

INTERFACE_DISABLED

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

LOCAUTO

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

LOCMAN

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

LOCUNK

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

MATE_UNAVAIL

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

NONE

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

REMAUTO

Remotely automatically blocked.

REMMAN

Remotely blocked manually.

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

Verifying System Statistics

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

•Platform state

•Number of active alarms

•Current congestion level

•Call success and failure rates

•CPU utilization level

•Amount of available memory

•Disk usage

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

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

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

Verifying the Number of Active Processes

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

Verifying the Number of Users

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

Verifying Available Virtual Memory

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

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

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

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

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

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

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

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

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

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

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

Verifying Available Memory on the Cisco ITP-Ls

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

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

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

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

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

Periodic Maintenance Procedures

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

•Automatic Disk Space Monitoring

•Automatic System Log Rotation

•Rotating System Logs Manually

•Creating a Disaster Recovery Plan

•Backing Up System Software

•Processing a Core Dump File

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

Automatic Disk Space Monitoring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Configuring Disk Monitor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Automatic System Log Rotation

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

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

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

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

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

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

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

Rotating System Logs Manually

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

Creating a Disaster Recovery Plan

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

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

Backing Up System Software

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

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

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

•Backup Procedures for Cisco PGW 2200 Softswitch Software

Backup Procedures for Cisco PGW 2200 Softswitch Software

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

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

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

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

The following sections provide the backup procedures:

•Performing a Manual Backup Operation

•Scheduling an Automatic Backup Operation

•Listing Scheduled Automatic Backup Operations

•Removing an Automatic Backup Operation from the Schedule

•Listing the Backup Operation History

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

Performing a Manual Backup Operation

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

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

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

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

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

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

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

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

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

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

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

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

Scheduling an Automatic Backup Operation

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

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

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

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

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

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

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

Note Your local tape drive is the default directory.

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

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

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

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

Note The maximum number of retries is 100.

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

Note The maximum number of seconds between checks is 3600.

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

•SUNDAY

•MONDAY

•TUESDAY

•WEDNESDAY

•THURSDAY

•FRIDAY

•SATURDAY

•WEEKDAYS

•WEEKENDS

•EVERYDAY

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

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

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

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

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

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

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

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

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

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

Removing an Automatic Backup Operation from the Schedule

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

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

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

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

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

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

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

Removing all Automatic Backup Operations from the Schedule

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

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

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

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

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

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

Listing Scheduled Automatic Backup Operations

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

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

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

Listing the Backup Operation History

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

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

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

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

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

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

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

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

Processing a Core Dump File

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

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

•Determines which executable dumped the core.

•Finds the current time of the system.

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

core.execname_yyyymmddhhmms

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

core.foverd_20010817122937

•Raises a crash information collected alarm.

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

Regular Operations

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

•Managing MML Sessions

•Managing Signaling Channels

•Managing Bearer Channels

•Managing SIP Communications

•Provisioning your Cisco PGW 2200 Softswitch

•Managing your Cisco PGW 2200 Softswitch Platform

•Managing System Measurements

•Managing Call Detail Records

•Using the Cisco MGC Viewer Toolkit

Managing MML Sessions

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

•Displaying Previously Entered MML Commands

•Displaying Information About MML Commands

•Reentering Previously Entered MML Commands

•Retrieving Active MML Sessions

•Ending an MML Session

Displaying Previously Entered MML Commands

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

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

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

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

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

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

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

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

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

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

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

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

Retrieving Active MML Sessions

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

Ending an MML Session

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

Managing Signaling Channels

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

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

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

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

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

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

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

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

Signaling channel name

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

Parent Name

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

Link ID

The LID field lists the associated link identification number.

Subsystem Number

The SSN field lists the associated subsystem number.

Primary Service State

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

Table 3-8 Signaling Channel Primary Service States

Link State ID

Link State

Description

AOOS

Automatically out-of-service

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

INB

Install busy

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

IS

In-service

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

MOOS

Manually out-of-service

The signaling channel has been manually taken OOS.

OFF_DUTY

Off duty

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

OOS

Out-of-service

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

TRNS

Transient

The state of the signaling channel is currently being changed.

UNK

Unknown

The state of the signaling channel is not known.

Secondary Service State

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

•ACKD—SS7 Acknowledgement delay

•BSNR—SS7 backward sequence number received (BSNR)

•CIS—Commanded in service

•CONF—Configuration failure

•COOS—Commanded out of service

•ENGR—Call engine reset

•ISPEND—In service, pending

•LCNG—Congestion, local

•LINE—Line failure

•LINH—SS7 local inhibit

•LINK—Link failure

•LINS—Linkset failure

•NA—Cause not available

•OOSPEND—Out of service, pending

•PRHB—SS7 prohibited

•RBLK—SS7 remote blocked

•RCNG—Congestion, remote

•RINH—SS7 remote inhibit

•RSTR—SS7 restricted

•SERR—SS7 signal error

•STBY—Host is in the standby state

•SUPPENT—Supporting entity

•TPATH—Traffic path

•UNK—Cause unknown

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

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

•Retrieving Signaling Service States

•Retrieving Service State of C7/SS7 Links or Linksets

•Retrieving the Service State for IP Links

•Retrieving the Service State for IP Routes

•Retrieving the Service State of D-Channels

•Retrieving the State of SS7 Signaling Services

•Retrieving the State of SS7 Routes

•Retrieving the State of All Local Subsystem Numbers

•Retrieving the Service State for Associations

•Clearing TCAP Transactions

•Enabling Group Service Reset Messages

Retrieving Signaling Service States

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

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

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

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

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

Retrieving Service State of C7/SS7 Links or Linksets

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

Retrieving the Service State for IP Links

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

Retrieving the Service State for IP Routes

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

IP Route Primary Service States

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

Table 3-9 IP Route Primary Service States

Link State ID

Link State

Description

IS

In-service

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

OOS

Out-of-service

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

IP Route Secondary Service States

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

Table 3-10 IP Route Secondary Service States

Link State ID

Link State

Description

CONF

Configuration

Route is OOS due to a configuration failure.

COOS

Commanded out-of-service

Route has been commanded OOS by the operator.

OFF_DUTY

Off duty

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

STBY

Standby

Routes on the standby Cisco PGW 2200 Softswitch.

Retrieving the Service State of D-Channels

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

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

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

Retrieving the State of SS7 Signaling Services

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

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

Retrieving the State of SS7 Routes

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

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

Retrieving the State of All Local Subsystem Numbers

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

Retrieving the Service State for Associations

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

Association Primary Service States

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

Table 3-11 Association Primary Service States

Link State ID

Link State

Description

INB

Install busy

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

IS

In-service

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

OOS

Out-of-service

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

Association Secondary Service States

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

Table 3-12 Association Secondary Service States

Link State ID

Link State

Description

CONF

Configuration

Association is OOS due to a configuration failure.

COOS

Commanded out-of-service

Association has been commanded OOS by the operator.

STBY

Standby

Association on the standby Cisco PGW 2200 Softswitch.

Retrieving TCAP Transactions

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

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

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

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

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

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

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

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

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

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

Managing Bearer Channels

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

•Verifying Proper Replication of Calls

•Retrieving the States of Bearers Held By a Media Gateway

•Blocking CICs

•Retrieving the Administrative State

Verifying Proper Replication of Calls

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

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

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

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

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

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

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

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

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

Retrieving the States of Bearers Held By a Media Gateway

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

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

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

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

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

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

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

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

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

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

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

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

Retrieving the Administrative State

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

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

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

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

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

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

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

•Retrieving the Administrative State of a Cisco PGW 2200 Softswitch

•Retrieving the Administrative State of a Media Gateway

•Retrieving the Administrative State of a Trunk Group

•Retrieving the Administrative State of a Signaling Service

•Retrieving the Administrative State of Spans

•Retrieving the Administrative State of CICs

Retrieving the Administrative State of a Cisco PGW 2200 Softswitch

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

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

Retrieving the Administrative State of a Media Gateway

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

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

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

Retrieving the Administrative State of a Trunk Group

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

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

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

Retrieving the Administrative State of a Signaling Service

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

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

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

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

•Signaling service or routeset associated with a DPC.

•EISUP signaling service.

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

Retrieving the Administrative State of Spans

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

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

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

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

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

–Signaling service or routeset associated with a DPC.

–EISUP signaling service.

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

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

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

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

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

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

–Signaling service or routeset associated with a DPC.

–EISUP signaling service.

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

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

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

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

Retrieving the Administrative State of CICs

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

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

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

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

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

–Signaling service or routeset associated with a DPC.

–EISUP signaling service.

•number—A valid CIC number.

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

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

Managing SIP Communications

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

•Managing the DNS Cache

•Retrieving SIP Call Information

Managing the DNS Cache

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

Displaying the Contents of the DNS Cache

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

–MML names for SIP or EISUP signaling service.

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

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

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

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

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

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

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

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

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

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

•Starting a Provisioning Session

•Saving and Activating your Provisioning Changes

•Ending a Provisioning Session Without Activating your Changes

•Invoking Dynamic Reconfiguration

•Retrieving Provisioning Data

•Provisioning a Dial Plan

•Importing Provisioning Data

•Exporting Provisioning Data

•Managing Automatic Congestion Control

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

Starting a Provisioning Session

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

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

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

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

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

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

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

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

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

Saving and Activating your Provisioning Changes

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

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

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

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

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

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

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

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

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

Ending a Provisioning Session Without Activating your Changes

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

Invoking Dynamic Reconfiguration

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

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

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

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

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

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

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

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

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

Understanding Dynamic Reconfiguration

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

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

•CICs

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

•Physical interfaces (TDM, ATM, or Ethernet)

•Signaling links (TDM, ATM, or SS7)

•Signaling services

•SS7 subsystems

•SS7 routes

•Trunk groups

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

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

Table 3-13 Dynamic Reconfiguration Preconditions

Component

Preconditions

CICs

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

or

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

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

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

Signaling links (TDM, ATM, or SS7)

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

Signaling services

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

SS7 subsystems

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

Trunk groups

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

None.

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

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

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

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

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

Retrieving Provisioning Data

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

•Retrieving Data for an Individual Component

•Retrieving Data for Select Components

•Retrieving Data for All Components of a Particular Type

•Retrieving Data on the Current Provisioning Session

•Retrieving Data on Supported Signaling Protocols

Retrieving Data for an Individual Component

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

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

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

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

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

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

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

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

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

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

Where:

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

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

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

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

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

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

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

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

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

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

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

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

Importing Provisioning Data

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

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

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

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

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

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

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

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

•routing.mml—Contains routing plans

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

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

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

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

•tid—Types of data. These can be:

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

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

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

–trkgrp—Trunk group data only.

–trunk—Trunk data only.

–all—Entire configuration (all data).

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

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

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

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

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

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

•routing.mml—Contains routing plans

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

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

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

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

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

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

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

ACC provides three major functions:

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

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

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

ACC is described in the following sections:

•Managing Call Rejection Percentages

•Managing Outgoing Load Control

•Managing Incoming Load Control

Managing Call Rejection Percentages

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

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

Table 3-14 Machine Congestion Level Values

Machine Congestion Level

Description

MCO

No congestion present.

MC1

Mild congestion.

MC2

Moderate congestion.

MC3

Severe congestion.

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

•Modifying the MCL Call Reject Settings

•Retrieving the MCL Call Reject Settings

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

Table 3-15 Alarm Associations for MCLs

Machine Congestion Level

Associated Alarm

MC1

OverloadLight

MC2

OverloadMedium

MC3

OverloadHeavy

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

1. The OverloadLight alarm is set.

2. The OverloadLight alarm is cleared.

3. The OverloadMedium alarm is set.

4. The OverloadMedium alarm is cleared.

5. The OverloadLight alarm is set.

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

Modifying the MCL Call Reject Settings

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

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

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

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

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

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

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

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

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

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

Retrieving the MCL Call Reject Settings

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

•mcl1

•mcl2

•mcl3

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

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

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

There are two types of outgoing load congestion controls:

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

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

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

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

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

Table 3-16 CANT and Skip Results Matrix

CANT

Skip

Result

Yes

Yes

CANT

No

Yes

Skip

No

No

None

Yes

No

CANT

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

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

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

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

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

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

•acl1drcant—50

•acl1drskip—20

•acl1arcant—50

•acl1arskip—20

•acl2drcant—90

•acl2drskip—20

•acl2arcant—90

•acl2arskip—20

•acl3drcant—100

•acl3drskip—0

•acl3arcant—100

•acl3arskip—0

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

The following sections describe how to manage OCL:

•Adding an ACC Response Category on System Configured for Signaling

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

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

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

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

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

•Retrieving ACC Response Category Settings

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

•Modifying the Trunk Group Associated with an ACC Response Category

•Modifying an ACL Timer

Adding an ACC Response Category on System Configured for Signaling

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

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

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

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

•cat_name—MML name for the ACCRC.

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

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

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

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

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

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

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

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

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

•cat_name—MML name for the ACCRC.

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

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

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

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

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

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

•cat_name—MML name for the ACCRC.

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

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

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

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

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

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