Software Directory Structure

Caution Do not edit any .dat files (except for the XECfgParm.dat and trigger.dat files). Use MML or the GUI provisioning tool to make changes to your configuration. In addition, only make changes to the call screening database by using MML or the GUI provisioning tool.

Table 4-2 Software Directory Structure

Directory

Contents

/etc/init.d

Control scripts, including scripts used to stop and start the software.

The initial startup configuration supplied with a new installation of the software.

/opt/CiscoMGC/etc/active_link

The active running configuration that has been committed or deployed.

/opt/CiscoMGC/etc/prov_link

The latest provisioned configuration that has not yet been committed or deployed.

/opt/CiscoMGC/etc/cust_specific

Location of configurations that have been exported using the prov-exp MML command.

/opt/CiscoMGC/lib

System software libraries of *.so object files (including protocol and system libraries).

/opt/CiscoMGC/snmp

SNMP support directory. MIBs are named *.my and are in ASN.1 syntax.

/opt/CiscoMGC/var

Contains the log, spool, trace, and Coredump file directories.

/opt/CiscoMGC/var/log

Default platform informational and error logs.

/opt/CiscoMGC/var/spool

Spool files for CDRs and measurements.

/opt/CiscoMGC/var/trace

Location of trace files created by using the sta-trc MML command.

/opt/SW

PGW software patch files.

Note This directory is not created by the default PGW installation, but is recommended for storing PGW patch files.

/opt/TimesTen

Call screening database files. Do not edit the database.

/opt/Toolkit

The Toolkit application files.

/opt/sun_install

Contains the scripts used to install Solaris patches.

Initial Cisco PGW 2200 Softswitch Software Configuration

The following required configuration parameters in the XECfgParm.dat file (see Table 4-3) are critical to bringing up the system. For a complete list of the parameters found in the XECfgParm.dat file and how they are used by the Cisco PGW 2200 Softswitch, see Appendix A, "XECfgParm.dat File Parameters."

Note The XECfgParm.dat file must be provisioned with the installation of every system. The file consists of set of parameters that are necessary to bring up the system. This set of required parameters is configured via the MGC Environment Configuration Tool.

When you exit the MGC Environment Configuration Tool, the slave file is sent via FTP to the appropriate system.

During Initial Cisco PGW 2200 Softswitch Configuration: We recommend that you put an initial configuration on the active host, otherwise both the active and standby hosts will remain in the stopped state. Do not start the standby host if the active host is not yet provisioned.

When the initial configuration on the active host is deployed, you must change the pom.dataSync parameter to true in the XECfgParm.dat file in the standby host.After setting this parameter to true, you can start the Cisco PGW 2200 Softswitch software on the standby host. As the Cisco PGW 2200 Softswitch software comes up, the data on the standby host is synchronized with the data on the active host. Initiate switchover to bring the active host to the standby state.To accommodate failover conditions where the current active host can become the standby host, you must also set the pom.dataSync parameter to true on the current active host.When upgrading the Cisco PGW 2200 Softswitch software: You must set the pom.dataSync parameter to false on the current active host in order to preserve configuration files.

Controls whether data access is enabled or disabled (if the engine attempts to connect to the MMDB or to call screening database at startup).

Values:

•true = connect to MMDB or call screening database

•false = do not connect to MMDB or call screening database

Default: false

Note This parameter must be set to true in calling scenarios where Euro-LNP, A Number Screening, or other features requiring real time database access are required. Otherwise, it can remain false for an increase in the available system memory usable for call processing.

Specifies the average number of Invokes for a TCAP dialog. A single dialog does not necessarily correspond to a single Invoke. The number of Invokes depends on the call flow for the TCAP dialog. .

Values: 1-10

Default: 1

Note See the note for the TCAP.maxSsnNum parameter.

TCAP.maxSsnNum

Specifies the maximum number of local Subsystem Numbers (SSNs) for the entire TCAP IOCC subsystem.

Values: 1-10

Default: 10

Note The PGW IOCC allocates resources and tracks the TCAP dialogs until the dialog ends. The PGW can support 200000 dialogs and (200000/maxSsnNum) dialogs per SSN. The PGW can support (200000*avgInvokePerDialog) Invokes and (200000*avgInvokePerDialog/maxSsnNum) Invokes per SSN.If the PGW detects repeated NCT/NBT, NoAnswer, RouteSelectFailure, or CalledPartyBusy messages, which then result in a follow-on call, there will be many Invokes for the same TCAP dialog. Therefore, to support higher feature capability, the maximum number of Invokes can be much larger than the maximum number of TCAP dialogs.If you provision the maxSsnNum and avgInvokePerDialog parameters, the maximum number of simultaneous outgoing Invokes per SSN is calculated as (200000* avgInvokePerDialog)/maxSsnNum.

*.transpathId

A unique number that identifies each virtual switch controller within the ASN (Auxiliary Signaling Network).

Default: 01

*.Virtual_IP_Addr1 through *.Virtual_IP_Addr2

Specify virtual IP addresses for the PGW that are used for SIP Failover Support.

Note During the startup of the Cisco PGW 2200 Softswitch software, this parameter is be set automatically to tune the system for optimal performance.

Note For Release 9.4(1) and later, the values of the parameters listed below are automatically set based on the Cisco MGC type you select, to maximize performance for that configuration. Any attempt to change the values of these parameters is overwritten.

Indicates whether the MGC connection type. SWITCHED-MGC specifies a dynamic connection such as a trunk group; NAILED-UP specifies a permanent connection such as a sigpath.

Operational Mode

Indicates the whether the PGW is operating as a stand-alone system or in a fault-tolerant configuration with an active and standby PGW.

Note If you select Active/Standby, you must provide a peer IP address.

Call Screening

Indicates whether call screening is enabled or disabled on the PGW. This setting is optional.

CLLI Code

The CLLI code identifying the site where the PGW is located. This setting is optional.

Local IP Address 1

The primary IP address of the PGW.

Peer IP Address 1

The IP address of the peer PGW. A peer IP address is required for a fault tolerant (Active/Standby) system.

Virtual IP Address 1

Additional virtual IP address for the PGW. Virtual IP addresses can improve failover for SIP connections in the event of a hardware failure.

Virtual IP Address 2

Additional virtual IP address for the PGW. Virtual IP addresses can improve failover for SIP connections in the event of a hardware failure.

Step 4 After you have finished setting the parameters, click Commit button.

Note The required parameters are the Cisco MGC type and its operating mode. There are no default parameters defined when you bring up the XECfg program.

Step 5 The PGW performs the following actions after you commit the new parameters:

•The XECfg program backs up the current XECfgParm.dat file into the XECfgParm.dat.xyz file, where xyz represents the file version number. The version numbers range from 0 to 19.

•If the operating mode is stand-alone, the PGW updates the XECfgParm.dat file with new parameters.

•If the operating mode is fault-tolerant, the PGW updates the XECfgParm.dat file and generates the XECfgParm.data.slave file based on the XECfgParm.dat file.

Note There is no backup for the XECfgParm.dat.slave file.

•The PGW comments out old parameters and inserts the new parameters. The PGW inserts a history line to note updated parameters.

•The PGW moves required parameters to the top of the file for convenience.

Note You can use the comment line to record the file history.

Step 6 When you exit the application, the XECfg program displays a prompt that allows you to transfer the XECfgParm.dat.slave file to a remote machine. To transfer the file to a remote machine, enter the FTP password. Otherwise, exit the application.

Configuring Groups and Users

You must set up groups and users for the Cisco PGW 2200 Softswitch software on each host server. A user must be a member of the "mgcgrp" group to use certain Cisco PGW 2200 Softswitch software functions, such as Man-Machine Language (MML). (MML is an interface that enables you to communicate with the Cisco PGW 2200 Softswitch. Users with full MML privileges have monitor and control access; users with minimal MML privileges have only monitor access. For more information on MML, see the Cisco PGW 2200 Softswitch Release 9 Provisioning Guide (through Release 9.7) and the Cisco PGW 2200 Softswitch Release 9 MML Command Reference.)

Verifying the mgcgrp Group

To verify the mgcgrp group, complete the following steps:

Step 1 Log in to the Cisco PGW 2200 Softswitch host as root.

Step 2 Change to the /etc directory.

Step 3 Edit the group file to verify the entry for the mgcgrp group. The file should contain the following line:

mgcgrp::20000:

Step 4 Save and close the group file.

Step 5 Edit the passwd file to verify the entry for the mgcusr user. The file should contain the following line:

mgcusr:x:20000:20000::/opt/CiscoMGC/local:/bin/csh

If the file does not contain the line, add it.

Step 6 Save and close the password file.

This completes the procedure for verifying the mgcgrp group.

Adding a User with Full MML Privileges

To add a user with full MML privileges, complete the following steps.

Caution If your user's home directory differs from /opt/CiscoMGC/local, you must perform
Step 6 through
Step 7 before using MML.

Step 1 Log in to the Cisco PGW 2200 Softswitch host as root.

Step 2 Enter the following command:

# useradd -uUID-g mgcgrp-d /opt/CiscoMGC/local -s /bin/csh -musername

UID is a user ID that is an integer from 0 through 2147483647 (excluding the numbers 0, 1, 2, 3, 4, 5, 9, 37, 71, 60001, 60002, and 65534, because they are used by the operating system).

Step 3 Add the new username to the mgcgrp group in the group file:

mgcgrp::20000:username

Note The group file is a comma-separated list of user names. If you add more than one user, use commas (with no spaces) to separate one name in the list from another.

Step 4 Enter the following command and press Enter:

passwdusername

Step 5 Type the user's password and press Enter twice when prompted.

Step 6 Log in to the Cisco PGW 2200 Softswitch as the new user.

Step 7 Enter the following command and press Enter:

mml

The MML interface launches. To exit MML, type quit and press Enter.

This completes the procedure for adding a user with full MML privileges.

Adding a User with Minimal MML Privileges

To add a user with full MML privileges, complete the following steps.

Step 1 Log in to the Cisco PGW 2200 Softswitch host as root.

Step 2 Add a group with minimal MML privileges using the following command:

# groupadd minmml

Step 3 Prepare the .cshrc file for the group with minimal MML privileges using the following commands:

# mkdir /opt/CiscoMGC/local/minmml

# cp /opt/CiscoMGC/local/.cshrc /opt/CiscoMGC/local/minmml/.cshrc

# chgrp minmml /opt/CiscoMGC/local/minmml/.cshrc

Step 4 Add a user to the group with minimal MML privileges using the following command:

If your system is running Cisco PGW 2200 Softswitch software Release 9.3(2) or later, Cisco recommends that you migrate the SNMP configuration to a more secure environment by running the config-snmp utility. Use the config-snmp utility to perform the following:

•Modify the snmpd.cnf file to automatically migrate old configuration files to a secure environment.

•Facilitate the addition or deletion of the community string and trap destination.

Note There is no limit to the number of community strings that can be added to the configuration.

Note The config-snmp script only allows you to add or delete an entry to your snmpd.cnf file.

Basic Tasks

The following is an overview of the major tasks you must perform to get the SNMP security provided by the config-snmp utility:

Before You Run the config-snmp Utility

Note If you have completed a first-time installation of the Cisco PGW 2200 Softswitch software with Release 9.7 and its associated patches, copy the snmpd.cnf.tmpl to snmpd.cnf before your run the config-snmp utility. Users who have upgraded to Release 9.7 from a previous release do not have to perform this procedure. To copy the snmpd.cnf.tmpl to the snmp.cnf, perform the following steps:

1. Log in as root and enter the following commands:cd /opt/CiscoMGC/snmpcp snmpd.cnf.tmpl snmpd.cnf

Running the config-snmp Utility

Perform the following steps to run the config-snmp utility:

Step 1 Make sure your system has the latest Cisco PGW 2200 Softswitch patches on both Host A and Host B. See the Release Notes for the Cisco PGW 2200 Softswitch Release 9.7(3) for detailed information on software patches.

Step 2 On Host A, log in as root user.

Step 3 Check whether the snmpdm or critagt process is running.

Note If snmpdm or critagt are not running, call Cisco TAC or contact your Field Engineer for assistance.

Type one of the following commands and press Enter:

a. To check snmpdm:

ps -ef |grep snmpdm

If the snmpdm process is running, text similar to the following is displayed:

root 12098 27888 0 Jun 16 ?

0:00 /opt/CiscoMGC/snmp/snmpdm -tcplocal -d

b. To check critagt:

ps -ef |grep critagt

If the critagt process is running, text similar to the following is displayed:

root 27888 1 0 May 19 ?

0:15 /opt/CiscoMGC/snmp/critagt -d

Step 4 To start the config-snmp utility, type the following commands and press Enter:

cd /opt/CiscoMGC/local

config-snmp

The following screen is displayed:

Migrating snmpd.cnf into a more secure setting...

=================== SNMPD Configuration Main Menu ===================

1. View Configuration Entries

2. Add an SNMP Community

3. Delete an SNMP Community

4. Add a Trap Destination

5. Delete a Trap Destination

6. Activate the New Settings

Enter a selection (1 through 6) or 'q' to quit:

Step 5 To view the configuration entries, type 1 and press Enter.

The Entries Menu is displayed and you are prompted to make a selection:

The configuration data file, or XECfgParm.dat file (located in /opt/CiscoMGC/etc/XECfgParm.dat), lists all the components in the Cisco PGW 2200 Softswitch and defines how it operates. You must edit the execution environment parameters in the XECfgParm.dat file to initialize and configure the Cisco PGW 2200 Softswitch software application. For a complete list of the parameters found in the XECfgParm.dat file and how they are used by the Cisco PGW 2200 Softswitch, see Appendix A, "XECfgParm.dat File Parameters."

Caution To ensure that your system works as intended,
editonly the XECfgParm.dat file parameters which are listed below, and remember that all parameters are case-sensitive.

Do not modify the
processes.dat file. This XECfgParm.dat file should remain unmodified, as delivered with the Cisco PGW 2200 Softswitch software. If this file is modified, procM may core dump when you start the Cisco PGW 2200 Softswitch software.

Note Do not restart the software yet if you need to configure SCP queries or initialize the call screening database. Complete the instructions in the appropriate sections of this chapter before restarting the software.

Tip If Host Y does not take over call processing after switchover, restart the software on Host X to take over the calls. Check the parameters you changed on Host Y and make sure you have the correct values.

Step 5 Restart the Cisco PGW 2200 Softswitch software on the now standby host, Host X, by entering the following command:

Tip If Host X does not take over call processing after switchover, restart the software on Host Y to take over the calls. Check the parameters you changed on Host X and make sure you have the correct values.

Configuring Basic System Information

To configure basic system information required for your system to function, modify the following parameters in the first section of the XECfgParm.dat file:

Parameter

Modification

*.desiredPlatformState

To determine the desired platform state at initialization, enter one of the following values:

•master—If you have two (active and standby) Cisco PGW 2200 Softswitch hosts, and you are editing the file on the active host

•slave—If you have two (active and standby) Cisco PGW 2200 Softswitch hosts, and you are editing the file on the standby host

•standalone—If you have a simplex system

Note The value used is site specific. For example, use the values master and slave if you have two (active and standby) Cisco PGW 2200 Softswitch hosts. Enter standalone if you have a single-host system.

*.numberOfThreads

Prior to Release 9.4(1), the number of threads generated by multithreaded processes such as the engine and the log master, is specified by entering one of the following values:

•0—Single CPU (default)

•1—Two CPUs

•2—Four CPUs

Note If you have a multi-CPU system, the engine.SysGeneratedCode parameter must be left as true (the default).

For Release 9.4(1) and up, this parameter is set automatically when you specify a Cisco MGC type in the engine.SysVirtualSwitch parameter. Any attempt to modify this parameter is overwritten.

*.ownTranspathId

To identify the local Cisco PGW 2200 Softswitch host in a fault tolerant system, enter the same value that you used for *.transpathID.

Note If you have two Cisco PGW 2200 Softswitch hosts in a fault tolerant system, enter this value in the *.peerTranspathID field in the XECfgParm.dat file on the second host server. If you have a simplex system, leave this value blank.

*.peerTranspathId

To identify the peer Cisco PGW 2200 Softswitch host in a fault tolerant system, enter any one- or two-digit integer. The IDs must be unique in an active and standby pair.

Note If you have two Cisco PGW 2200 Softswitch hosts in a fault tolerant system, enter the same value that you used for *.transpathID in the XECfgParm.dat file of the second host server in this field. If you have a simplex system, leave it blank.

*.sipModeSelectionControl

This parameter is the highest level means of governing SIP actions. This parameter lets you provision one system-level parameter and maintain your proxy mode functionality for SIP-to-SIP calls. If you are using proxy mode for SIP calls, you do not have to provision a dialplan result for all numbers handled simply to maintain your call processing capability.

At this level there is a choice of operating mode, either the B2BUA/optional mode using the dial plan result FACILITY or the default Fixed Proxy Mode working. The parameter has two valid values:

1 (B2BUA/optional mode)—With the parameter set to 1, default processing on SIP-to-SIP calls is B2BUA mode and you can select the proxy mode of operation later with the dial plan (A/B analysis).

2 (Fixed Proxy Mode)—With the parameter set to 2, handling of SIP-to-SIP calls is supported in proxy mode only. Any later selection of B2BUA mode with the dial plan becomes meaningless once you select this value. There is no means to select B2BUA mode in the FACILITY result, only Proxy mode. This means that if you set XECfgParm for proxy mode there is no point in defining FACILITY results for Proxy mode because all SIP-to-SIP calls will already be in proxy mode. This is the default setting for this parameter.

Note If there is no dialplan result FACILITY or if number analysis is not used, then the variable remains set at value 0 and default Fixed Proxy behavior results.

Default: 2

*.stPort

Port number used between peer components or processes.

Enter any unused port number (for example, 7000). If your configuration uses a Cisco SLT, enter the port number on the Cisco SLT.

Note If you have two Cisco PGW 2200 Softswitch hosts in a failover configuration, enter a different number for this value in the XECfgParm.dat file on the secondary host (for example, 7001).

Note On a new configuration, we recommend that this parameter be set to 0. This value allows the SLT port to be defined using the PEERPORT parameter of the SESSIONSET.

Note SESSIONSET reads the port value that is defined. However, if an *.stPort value other than 0 is defined in XECfgParm.dat (for example, *.stPort=7001), the SESSIONSET valuegets overridden by the value in XECfgParm.dat.

*.transpathId

To identify the local Cisco PGW 2200 Softswitch host in a fault tolerant system, enter any one- or two-digit integer.

Note If you have two Cisco PGW 2200 Softswitch hosts in a fault tolerant system, this number must be different in the XECfgParm.dat file for each host.

To indicate whether the Cisco PGW 2200 Softswitch host functions as a signaling controller or a virtual switch controller, enter one of the following values:

•0—Signaling controller (nailed trunks, no auditing is initiated)

•1—Virtual switch controller (switched trunks)

Note During the startup of the Cisco PGW 2200 Softswitch software, this parameter is be set automatically to tune the system for optimal performance.

Note For Release 9.4(1) and up, the values of the parameters listed below are automatically set based on the Cisco MGC type you select, to maximize performance for that configuration. Any attempt to change the values of these parameters is overwritten.

Specifying IP Addresses

To specify IP addresses, modify the following parameters in the first section of the XECfgParm.dat file:

Note If there are two Ethernet interfaces defined on the Cisco PGW 2200 Softswitch, it is mandatory to have these on distinct subnets.

For example, consider the following configuration:

*.IP_AddrLocalA = 172.22.119.108

*.IP_AddrLocalB = 172.22.119.54

This is not a valid combination because they are on the same subnet. The following example illustrates a valid combination:

*.IP_AddrLocalA = 172.22.119.108

*.IP_AddrLocalB = 172.22.120.54

In this example, the subnet mask is 255.255.255.0 (or 255.255.255.128).

If the two Ethernet interfaces are on the same subnet, then one of them must be physically disconnected from the existing subnet and then connected to a different subnet. The new IP address must be appropriately configured on the system. Refer to the manual pages for the UNIX command ifconfig for more information.

Parameter

Modification

*.IP_AddrLocalA

Enter the first local IP address; used for checkpointing and switchover heartbeats.

Caution This address is the same value as *.IP_Addr1, and is the bge0 interface.
Caution No other machine on the network should have
*.IP_AddrLocalA set to 0.0.0.0.

*.IP_AddrPeerA

Enter the first corresponding peer IP address; used for checkpointing and switchover heartbeats.

Note If you have two Cisco PGW 2200 Softswitch hosts in a fault tolerant configuration, this value is set to the IP address of the second host.

*.IP_AddrLocalB

Enter the second local IP address; used for checkpointing and switchover heartbeats. This is the address of the bge1 interface.

Note If your configuration does not use a secondary Ethernet adapter, leave this address set to the default value, 0.0.0.0.

*.IP_AddrPeerB

Enter the second corresponding peer IP address; used for checkpointing and switchover heartbeats. This is the address of the bge1 interface on the second host.

Note If your configuration does not use a secondary Ethernet adapter, leave this address set to the default value, 0.0.0.0.

*.IP_Addr1

Enter the IP address of the bge0 interface.

*.IP_Addr2

Enter the IP address of the bge1 interface (if configured).

*.IP_Addr3

Enter the IP address of the bge2 interface (if configured).

*.IP_Addr4

Enter the IP address of the bge3 interface (if configured).

*.Virtual_IP_Addr1

Enter a virtual IP addresses for the PGW used for SIP Failover Support (optional).

*.Virtual_IP_Addr2

Enter a virtual IP addresses for the PGW used for SIP Failover Support (optional).

Configuring Engine Parameters

For the engine to run correctly, you must modify the following parameters in the Engine section of the XECfgParm.dat file:

Parameter

Modification

engine.CALL_MEM_BLOCK_SIZE

Block of memory allocated per call.

Used by MDL.

Set automatically based on the type of Cisco MGC selected in engine.SysVirtualSwitch. Any attempt to modify this value is overwritten.

engine.CALL_MEM_CHUNK_SIZE

Memory chunks allocated from the block of memory designated with engine.CALL_MEM_BLOCK_SIZE.

Set automatically based on the type of Cisco MGC selected in engine.SysVirtualSwitch. Any attempt to modify this value is overwritten.

engine.SendHardwareBlock

To enable the Cisco PGW 2200 Softswitch to send hardware-oriented blocking messages for any blocks that originate from the media gateways:

•true—Sends hardware-oriented blocking messages for any blocks that originate from the media gateways.

•false—Sends only maintenance-oriented blocking messages for all blocking cases (default).

Note The parameter is automatically added to the XECfgParm.dat file during the patch installation.

engine.SysCdrCollection

Designates the format of CDRs.

Values:

•true—Invalid for Release 7.4 and above.

•false—Generates binary format CDRs (default)

Default: false

Note Do not change this value. Setting this to a value of true for Release 7.4 and higher is not valid and may have deleterious effects on the system.

engine.SysGRSTimerInterval

To specify the interval between blocks of Circuit Group Reset (GRS) messages when the engine.SysGRSBlockSize parameter is used, set to the value required (in milliseconds).

engine.SysGRSBlockSize

Used for flow control of all automatically generated GRS, CGB, and CGU messages which are generated by the Cisco PGW 2200 Softswitch during run time. Typically produced due to propagation of service state changes such as MGCP endpoints changing availability. Specifies the interval, in milliseconds, between blocks of GRS parameters when the engine.SysGRSBlockSize parameter is used. The timer interval runs from the start of sending the first GRS message in each block to the first message in the next block.

To determine whether compiled or interpreted code is used, enter one of the following values:

•true—System uses compiled code (default).

•false—System uses interpreted code (used only for engineering and debugging).

Note Compiled code runs faster than interpreted code. Typically, this value should be true. If your configuration uses multiple CPUs, this value must be true.

*.SysConnectDataAccess

This parameter controls if data access is enabled or disabled and if the engine attempts to connect to the MMDB at startup.

Set this parameter to true for calling scenarios where European LNP, A-number screening, or other features requiring real-time database access are used.

If you do not need real-time database access, set this parameter to false to increase the available system memory that can be used for call processing.

Setting the Call Cutoff Timer

The PGW call cutoff timer is disabled by default. To set the call cutoff timer, modify the following parameter in the XECfgParm.dat file:

Parameter

Modification

*.CallCutoffTimer

Provides a global system-wide timer, which is started when a call is answered and runs for the pre-configured time. When it expires the call is released in both directions and the call is cleared. This parameter is not dynamically reconfigurable. You must restart your system.

Values:

•Hours: 0(default), 1—48 (using hour as the unit)

•Minutes: 0, 1—2880 (using minute as the unit)

•Seconds: 0, 1—1728000 (using second as the unit)

Default: 0—Disables the timer.

Note You can override this value using the first data word of the CALL_CUTOFF_TIMER result type.

Enabling Call Screening

To initialize the database that stores call screening information, modify the following parameter in the Engine section of the XECfgParm.dat file:

Parameter

Modification

*.SysConnectDataAccess

Controls whether data access is enabled or disabled (whether the engine attempts to connect to the MMDB at startup.

Values:

•true = connect to MMDB

•false = do not connect to MMDB

Default: false

Note In calling scenarios where Euro-LNP, A Number Screening, or other features requiring real time database access are required, this parameter must be set to true. Otherwise, it can remain false for an increase in the available system memory usable for call processing.

Note This parameter replaces the SysScreeningCheck parameter.

Configuring Call Detail Record File Output

To configure call detail record (CDR) file output, modify the following parameters in the Data Dumper and Engine sections of the XECfgParm.dat file:

Parameter

Modification

engine.CDRencodingFormat

To specify the call detail record (CDR) file encoding format, enter one of the following values:

•AnsiCDB—North American (default)

•ItuCDB—European

•CustCDB—Custom

engine.CDRmessageTypes

To specify the Call Detail Blocks (CDBs are the accounting records written at various points in a call) that are generated during a call, enter one of the following sets of values (each number represents a point in a call):

•1010, 1020, 1030, 1040, 1050, 1060, 1070, 1080—These are considered the "event-based" set of values. Use this event-based list when you want to receive all CDR records at predefined points in the call. Although each of these CDBs can be specified independently, Cisco suggests that you use the event-based set as a "package" of CDBs for full accounting purposes.

Note The event-based setting is required when operating the Cisco PGW 2200 Softswitch in conjunction with the BAMS adjunct.

•false = Standard data dumper does not open a CDR file and does not log CDBs.

Default: true

Note The default format for CDR files has been changed since release 4 from an ASCII format to a binary format. Use the dmpr.callDetail parameter to convert the files to an ASCII format, if necessary.

Configuring the Clearing Location and Default Location Parameters

The ClearingLocation and DefaultLocation parameters are used to determine a call's location value. If you require a value other than the default to be sent to the switch, use these parameters to override the Clearing Location and Default Location fields in the Call Context. For example, if you need to define a customer-specific default location for your system, set this value in the DefaultLocation parameter, which overrides the default location specified in the protocol type definition.

Parameter

Modification

ClearingLocation

This property overrides the Clearing Location field in Call Context. Change this value if you need a value other than the default to be sent to the switch. Valid values are:

This property overrides the Default Location field in Call Context. Change this value if you need to define a customer-specific default location for your system that can differ from the default location set in the type definition of the protocol. Valid values are:

Configuring Switchover

To configure switchover, modify the following parameters in the foverd section of the XECfgParm.dat file.

Parameter

Modification

foverd.conn1Type

To set the connection type for connection number 1, enter serial or socket.

Note Typically, set this value to socket.

foverd.ipLocalPortA

To define the local port number used for IP communication, enter a unique number, keeping the following in mind:

•Typically, if Type is socket, set this value to 1051.

•If you have two Cisco PGW 2200 Softswitch hosts in a fault tolerant configuration, enter the foverd.ipLocalPortA value in the foverd.ipPeerPortA field in the XECfgParm.dat file on the secondary host.

Caution The value of foverd.ipLocalPortA must be unique for every host on the network. Otherwise, active and standby hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipLocalPortA set to 1051. If that happens, the active and standby hosts cannot perform proper switchover.

foverd.ipPeerPortA

To define the peer port number used for IP communication, enter a unique number, keeping the following in mind:

•Typically, if Type is socket, set this value to 1052.

•If you have two Cisco PGW 2200 Softswitch hosts in a switchover configuration, enter the foverd.ipPeerPortA value in the foverd.ipLocalPortA field in the XECfgParm.dat file on the secondary host.

Caution The value of foverd.ipPeerPortA must be unique for every host on the network. Otherwise, active and standby hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipPeerPortA set to 1052. If that happens, the active and standby hosts cannot perform proper switchover.

foverd.conn2Type

To set the connection type for connection number 2, enter serial or socket.

Note Typically, set this value to socket.

foverd.ipLocalPortB

To define the secondary local port number used for IP communication, enter a unique number, keeping the following in mind:

•Typically, if Type is socket, set this value to 1053.

•If you have two Cisco PGW 2200 Softswitch hosts in a switchover configuration, enter this value in the foverd.ipPeerPortB field in the XECfgParm.dat file on the secondary host.

Caution The value of foverd.ipLocalPortB must be unique for every host on the network. Otherwise, active and standby hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipLocalPortB set to 1053. If that happens, the active and standby hosts cannot perform proper switchover.

foverd.ipPeerPortB

To define the secondary local port number used for IP communication, enter a unique number, keeping the following in mind:

•Typically, if Type is socket, set this value to 1054.

•If you have two Cisco PGW 2200 Softswitch hosts in a switchover configuration, enter this value in the foverd.ipLocalPortB field in the XECfgParm.dat file on the secondary host.

Caution The value of foverd.ipPeerPortB must be unique for every host on the network. Otherwise, master and slave hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipPeerPortB set to 1054. If that happens, the master and slave hosts cannot perform proper switchover.

foverd.conn3Type

To set the connection type for connection number 3, enter serial or socket.

Note Typically, set this value to serial.

foverd.conn3Addr

To specify the address of the peer system, enter a location; for example, /dev/term/a.

If your configuration does not use connection number 3, enter /dev/null (default).

Note If your configuration uses an 8-port connector as a serial connection for switchover, you must modify the read-write permissions for the connection.

foverd.abswitchPort

To specify the port used for communication with the A/B switch, enter a location; for example, /dev/term/a.

Note If your configuration does not use an A/B switch, use the default value (/dev/null).

foverd.heartbeatInterval

Specifies the maximum time in milliseconds between heartbeat messages from the peer switchover daemon. This interval defines the frequency with which the switchover daemon exchanges heartbeat messages with its peer.

Initializing the Provisioning Object Manager

To configure the Provisioning Object Manager (POM), modify the following parameters in the POM section of the XECfgParm.dat file:

Parameter

Modification

pom.dataSync

Used in a fault tolerant system to indicate that the POM should synchronize the provisioning data at startup.

•If you have a standalone system, set this value to false.

•If you have a fault tolerant system, set this value to true.

Caution If pom.dataSync is set to true for a fault tolerant system, you must ensure that you are running the same version of the Cisco PGW 2200 Softswitch software on both active and standby machines. Otherwise, the wrong version of your data files may be copied to the other machine.

Note When the initial Cisco PGW 2200 Softswitch configuration on the active host is deployed, you must change the pom.dataSync parameter to true in the XECfgParm.dat file in the standby host. After setting this parameter to true, you can start the Cisco PGW 2200 Softswitch software on the standby host. As the Cisco PGW 2200 Softswitch software comes up, the data on the standby host is synchronized with the data on the active host and the active host goes into the standby state.

To accommodate failover conditions where the current active host can become the standby host, you must also set the pom.dataSync parameter to true on the current active host.

pom.port

Used in a fault tolerant configuration to indicate the port number that the POM uses to communicate with its peer. Enter any integer from 4001 through 4050, or default.

Note This is a platform-specific value and depends on your system installation. You should modify this value only if the default port (4001) is being used by another process or application.

Configuring SCP Queries

The SCP translates routing information for the Advanced Intelligent Network (AIN) database queries over TCAP. This section provides instructions for selecting the type of translation you use to enable SCP database queries. If your site or network requires changes, you can enable SCP queries using the prov-ed:inservice command or by manually editing the parameters in the trigger.dat file. The trigger.dat file (located in /opt/CiscoMGC/etc) contains the message-sending table that contains translation values.

Before You Start

If you are changing an ANSI query and you need a different Translation Type, you need to know the Translationtype value from the Global Title Translation tables on the Signal Transfer Point (STP). Get this value from the administrator of your STP.

Modifying trigger.dat file parameters with provisioning commands

You can use the prov-ed:inservice command to modify the trigger.dat properties without editing the file directly. The command allows you to modify the service key, global title or subsystem number, global title format, or message sending name.

For more information about the prov-ed:inservice command, refer to the Cisco PGW 2200 Softswitch Release 9 MML Command Reference.

Configuring the trigger.dat File Attributes

Note The trigger.dat file is not overwritten during software installation. All changes to the trigger.dat file are contained in a file called trigger.template that is installed with the new software. If you modify the trigger.dat file after installing a new software release, you need to view the trigger.template file and copy any changes in that file to your trigger.dat file.

b. In the table for your translation type, change the value for translationType to a value from 0 through 255. You can get this information from your network administrator.

Step 8 Save your changes and close the editor.

Step 9 For your changes to take effect you must reboot the Cisco PGW 2200 Softswitch by entering the following command:

# /etc/init.d/CiscoMGC start

Note If you have installed the Solaris DiskSuite package (CSCOh016) on your system, the messages below are displayed during system boot-up. They are normal Solaris DiskSuite start-up messages and do not indicate any problem with your system.

The call screening database is stored in the /opt/TimesTen/datastore directory. The database name is howdydb. The maximum database size, 256 MB, is specified in the .odbc.ini file shown in the .odbc.ini File Information section, below.

Caution Do not change the database name.

.odbc.ini File Information

The .odbc.ini file specifies the location of the database storage. Unless you installed the software to other than the default directory, the .odbc.ini file is located in the /opt/CiscoMGC/local directory. The following is an example of an .odbc.ini file:

[ODBC Data Sources]

howdydb=TimesTen 4.1 Driver

[howdydb]

Driver=/opt/TimesTen4.1/32/lib/libtten.so

DataStore= /opt/TimesTen4.1/datastore/howdydb

DurableCommits=0

ExclAccess=0

ThreadSafe=1

WaitForConnect=0

Size=256

[ODBC]

Trace=0

TraceFile=

Installdir=/opt/TimesTen4.1/32

Setting Up Replication

If you have two Cisco PGW 2200 Softswitch hosts in a fault tolerant system, you must set up database replication between the two hosts. During replication, any updates applied to the database on one host are replicated on the other. Data is transferred real time and does not require committing or deploying a configuration.

Replication copies data changes to either database after the initial setup. If you have data in one database and want to retain it, go to the host that has the data that you want to retain (usually this is the active host), then follow the procedures below, "Initializing Database Replication" section.

Note Before you can initialize the databases, you must install the Cisco PGW 2200 Softswitch software on both machines.

Network Requirements

In most replication schemes, you need to identify the name of the host machine on which your data store resides. The operating system translates this host name to an IP address. This section describes how to configure your host names to ensure they use the correct IP addresses.

Identifying data store hosts (UNIX and VxWorks)

If your Unix or VxWorks host has a single IP address and hostname, you can use the host name returned by the hostname command on UNIX or the hostname() call on VxWorks. If a host contains multiple network interfaces (with different IP addresses), TimesTen replication tries to connect to the IP address in the same order as returned by the gethostbyname() call on UNIX or the hostGetByName() call on VxWorks. It will try to connect using the first address; if a connection cannot be established, it tries the remaining addresses in order until a connection is established. TimesTen replication uses this same sequence each time it establishes a new connection to a host. If a connection to a host fails on one IP address, TimesTen replication attempts to re-connect (or fall back) to another IP address for the host in the same manner described above.

There are two basic ways you can configure a host to use multiple IP addresses on UNIX platforms: DNS or /etc/hosts files. On VxWorks platforms you use the hostAdd() call. For example, the following entry in the /etc/hosts file on a UNIX platform describes a server named Machine1 with two Ethernet IP addresses:

10.10.98.102 Machine1

192.168.1.102 Machine1

To specify the same configuration for DNS, your entry in the domain zone file would look like:

Machine1 IN A 10.10.98.102

IN A 192.168.1.102

In either case, you only need to specify Machine1 as the hostname in your replication scheme and replication will use the first available IP address when establishing a connection. In an environment in which multiple IP addresses are used, you can also assign multiple host names to a single IP address in order to restrict a replication connection to a specific IP address. For example, you might have an entry in your /etc/hosts file that looks like:

10.10.98.102 Machine1

192.168.1.102 Machine1 RepMachine1

Or a DNS zone file that looks like:

Machine1 IN A 10.10.98.102

IN A 192.168.1.102

RepMachine1 IN A 192.168.1.102

Should you want to restrict replication connections to IP address 192.169.1.102 for this host, you can specify RepMachine1 as the hostname in your replication scheme. (Another option is to simply specify the IP address as the hostname in the CREATE REPLICATION statement used to configure your replication scheme.)

The following are example hosts files from an active PGW host and an associated peer PGW host:

Initializing Database Replication

Step 1 Log in to the active host as mgcusr and enter the following command:

setup_replication.shstandbyhostactive

Where standbyhost is the name (not IP address) of your standby host. In the example below, the active host is hostx and the standby host is hosty.

Caution Do not use IP addresses when setting up database replication. If you do, replication will fail.

Note If the machine on which the Cisco PGW 2200 Softswitch software is installed has several different names, make sure the the argument that you supply to the setup_replication.sh script matches the output of the Unix command hostname.

Example 4-1 Initializing Database Replication on the Active Host

hostx% setup_replication.sh hosty active

Setting up replication to node hosty for DSN howdydb

Adding cisco.whitelist_a

Adding cisco.blacklist_a

Adding cisco.whitelist_b

Adding cisco.blacklist_b

Adding cisco.portednumbers

Adding cisco.numberterm

RAM Residence Policy : inUse

RAM Residence Grace (Secs) : 0

Manually Loaded In Ram : False

Purge Logs for Data Store : True

Logging Enabled : True

Replication Manually Started : True

Step 2 Log in to the standby host as the root user and stop the Cisco PGW 2200 Softswitch software by entering the following UNIX command:

/etc/init.d/CiscoMGC stop

Step 3 Log back in to the standby host as mgcusr.

Step 4 At the standby host, enter the following command:

setup_replication.sh activehoststandby

where activehost is the name (not IP address) of your active host. In the example below, the active host is hostx and the standby host is hosty.

Caution Do not use IP addresses when setting up database replication. If you do, replication will fail.

Example 4-2 Initializing Database Replication on the Standby Host

Configuring replication for DSN=howdydb

Restoring file /opt/TimesTen4.1/datastore/howdydb.ds0 from backup

Restoring file /opt/TimesTen4.1/datastore/howdydb.log0 from backup

RAM Residence Policy :inUse

Manually Loaded In Ram :False

Replication Agent Policy :manual

Replication Manually Started :True

Oracle Agent Policy :manual

Oracle Agent Manually Started :False

Replication setup completed.

Note If the replication setup on the standby host fails, you must run delete_replication.sh on both active and standby hosts. Then change the value of the TTREPPORT variable from 2980 to 2981 in the setup_replication.sh script on both active and standby hosts and save your changes. Perform the whole procedure again.

Troubleshooting the Main Memory Database Replication

If you have problems during replication, try stopping and restarting the replication as follows:

Step 1 Stop the replication by entering:

# /etc/init.d/ttreplic stop

Step 2 Restart the replication by entering:

# /etc/init.d/ttreplic start

Displaying the Main Memory Database Replication Status

The script replication_status.sh displays the status of the MMDB replication, if it is configured.

Run the script by typing the following command:

replication_status.sh

The output shows the following replication status:

Peer name Host name Port State Proto

---------------- ------------------------ ------ ------- -----

HOWDYDB VA-DEALE Auto Start 5

Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs

------------- ------------- ------- ------- --------- ----

- - -1.00 -1 -1 1

Note If the value for Last Msg Recv is more than a few seconds, or Logs is more than 1, then this indicates that replication is not occurring.

Verifying Database Synchronization

The script db_count.sh providesthe number of records configured in each of the database tables. This is useful for checking whether two machines have the same database data configured in them.

Run the script by typing the following command:

db_count.sh

The output shows the rows counted in each database table:

Counting the rows in each database table.

CISCO.ANNOUNCEMENT < 0 >

CISCO.A_CHARGE_ORIGIN < 0 >

CISCO.A_NUMBERDIALPLANSELECTION < 0 >

CISCO.BLACKLIST_A < 0 >

CISCO.BLACKLIST_B < 0 >

CISCO.CBBOOKINGINFO < 0 >

CISCO.CBMONITORINGINFO < 0 >

CISCO.CLIIPADDRESS < 0 >

CISCO.CLIPREFIX < 0 >

CISCO.FULLNUMBERTRANSLATION < 0 >

CISCO.H323IDDIVFROM < 0 >

CISCO.LIENTRIES < 0 >

CISCO.NUMBERTERM < 0 >

CISCO.PORTEDNUMBERS < 0 >

CISCO.SCRIPT < 0 >

CISCO.WHITELIST_A < 0 >

CISCO.WHITELIST_B < 0 >

Synchronizing Databases

If you have data in the databases in the active and standby hosts, but both databases are out of synch or do not match, re-synchronize both databases by following the steps listed below. Otherwise, contact Cisco TAC for assistance in merging the databases.

Assuming the active host is the "better" database, do the following on the standby host:

Checking for Installation Errors

If you still have problems, retry the commands listed in the "Verifying Database Replication" section. If your output differs from the example in that section, or if you suspect problems or errors in the database installation, try the following:

Step 1 Ensure that the database is installed in the /opt/TimesTen directory.

Step 2 Check the log file for installation errors. (The log file is in the directory /var/adm/MGC_install.log.)

Reinstalling CSCOga002

If you experience database errors such as an incorrect timestamp after completing the "Checking for Installation Errors" section, you need to reinstall the CSCOga002 package, which contains the PGW database components. Follow these steps to reinstall the CSCOga002 package:

Step 1 Remove the CSCOga002 package using the pkgrm command. To remove the package file, enter the following command:

# pkgrm CSCOga002

Step 2 Reinstall the package using the pkgadd command by entering the following command:

Configuring Cisco ITP-Ls

Configuring Disk Monitor During Initial Software Configuration

The setting of the disk monitor parameters in the XECfgParm.dat file typically occurs while you are performing the initial configuration procedures for your Cisco PGW 2200 Softswitch software. To configure the disk monitor settings in the XECfgParm.dat file during initial software configuration, perform the following steps:

Step 1 While configuring your settings in the XECfgParm.dat file, find the disk monitor parameters in the file (they are near the end of the file).

Step 2 To change the number of days to preserve logged data before trimming is initiated, modify the value of the diskmonitor.Limit parameter. The default value is 7.

Step 3 To change the list of optional file systems that are checked by the disk monitor script, modify the value of the diskmonitor.OptFileSys parameter.

Note Files in optional directories are not trimmed by disk monitor.

Step 4 To change the percentage of disk usage at which alarming and disk trimming is initiated, modify the value of the diskmonitor.Threshold parameter. The default value is 80.

Step 5 To change the number of days that finished CDR files are kept in the log directory, modify the value of the diskmonitor.CdrRmFinished parameter. The default value is 0, which means that finished CDRs are immediately sent to the spool directory.

Step 6 If you want to change what action is taken once the number of days threshold set in the diskmonitor.Limit parameter is reached, change the value of the diskmonitor.SoftLimit parameter. If this parameter is set to true, disk monitor decrements the value in the diskmonitor.Limit parameter one day at a time (that is, from 7 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 true.

Step 7 To change the number of days that core dump files are kept in the log directory, modify the value of the diskmonitor.CoreRmDays parameter. The default value is 1, which means that core dump files are kept for one day before disk monitor removes them automatically.

Step 8 You can control the maximum number of configurations that can be stored in the configuration library using the diskmonitor.CfgRmDirs parameter. 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.

Note If you want to ensure the proper functioning of the prov-sync MML command, set this parameter to a value between 50 and 60.

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

Configuring the Data Dumper

The data dumper is a Cisco PGW 2200 Softswitch software function that controls the destinations for active and archived log files for CDRs, measurements, and alarms, and controls when the active files are archived. The data dumper runs automatically and works correctly with a default configuration. However, you can customize the dumper settings by editing the dmprSink.dat file.

The following is an example of the contents of the dmprSink.dat file:

"callDetail" bin "cdr" "../var/log" "../var/spool" 1000 0 15

"measReport" csv "meas" "../var/log" "../var/spool" 500 0 15

"almState" csv "alm" "../var/log" "../var/spool" 500 0 15

Table 4-7 lists the fields that can be modified depending on your needs.

Table 4-7 Dumper Sink Log File Parameters

Field Name

Default Value

Description

maxRecs

1000

The maximum number of records a file can contain before it is flushed or moved to the spool area. If this value is set to 0, the number of records is unlimited. You can improve system performance by increasing the value of this record to a larger value, such as 50000. This results in fewer log record files being generated during periods of high call volume.

maxSize

0

The maximum size of the file in bytes before it is moved to the spool area. If this value is set to 0, the size of the file is limited only by the disk space available.

maxTime

15

The maximum time, in minutes, the file is allowed to remain open, before it is flushed or moved to the spool area. If there is no data in the file, it will not be flushed when the time limit expires. If this value is set to 0, there is no time limit.

Note One or more of the above fields MUST be set to a value other than zero (0) for each record in the dmprSink.dat file.

Caution Donotmodify or change any of the following log file configuration values.

recordFormat

csv

The translation of the records being placed in the capture file. Valid values are csv (comma-separated values) or bin (binary).

logDirectory

/var/log

The directory where the current dumper logs reside.

logSpoolDir

/var/spool

The directory to which historic logs are copied after being closed.

To configure the dmprSink.dat file fields, use the following procedure:

Step 1 If you are not already logged in, log into a Cisco PGW 2200 Softswitch as root.

Step 2 Change to the /opt/CiscoMGC/etc directory by entering the following UNIX command:

cd /opt/CiscoMGC/etc

Step 3 Use a text editor, such as vi, to open and edit the dmprSink.dat file fields you want to change.