cc/td/doc/product/access/sc/rel7/soln/das
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Upgrading Cisco SC2200 Software

Identifying the Active Configuration

Removing a Previous Version of the Cisco Telephony Controller Software (Release 4 and Release 7.3(x))

Removing a Previous Version of the Cisco MGC Software (Release 7.4(x))

Installing SC Software Release 7.3(x)

Installing SC Software Release 7.4(x)

Installing Patches for the SC Software

Installing a GUI Provisioning Tool on a Separate Server

Installing the CMM

Installing the Voice Service Provisioning Tool

Configuring SNMP Support Resources

Configuring the Execution Environment

Opening the XECfgParm.dat File

Configuring Basic System Information

Specifying IP Addresses

Configuring Engine Parameters

Configuring Automatic Congestion Control

Enabling Call Screening

Configuring Call Detail Record File Output

Configuring the System Type

Configuring the Clearing Location and Default Location Parameters

Configuring *.GWClearChannelAlgorithm Parameter

Configuring Switchover

Initializing the Provisioning Object Manager (POM)

Saving the XECfgParm.dat File

Configuring SCP Queries

Before You Start

Configuring the trigger.dat File Attributes

Initializing the Call Screening Database

.odbc.ini File Information

Setting Up Replication

Verifying Database Replication

Troubleshooting

Restarting the SC Software

Terminating Signaling Links

Verifying SC Software is Running Properly

Perform a Test Call and Switchover

Verifying the Platform State of the SC Hosts

Verifying the Status of all Signaling Channels

Verifying the Status of all Traffic Channels

Verifying the Status of all Destinations

Checking for Active Alarms

Verifying Proper Migration of Data

Migrating Inactive SC Host Configurations

Backout Procedures

Resetting the Configuration

Provisioning the Configuration

Upgrading Cisco SC2200 Software


Before beginning the upgrade, verify that you have the Cisco Media Gateway Controller Software Release 7 CD-ROM. (For Software Release 7.3(x), this is called the Cisco Telephony Controller Software Release 7 CD-ROM.)

Use the instructions in this section to install new software. If you have a simplex configuration, install the software on your server. If you have a high-availability configuration, install the software on the standby first.


Note Procedures for installing Software Release 7.3(x) differ from Software Release 7.4(x). Follow the instructions for the version you are installing.


This chapter contains the following sections:

Identifying the Active Configuration

Removing a Previous Version of the Cisco Telephony Controller Software (Release 4 and Release 7.3(x))

Removing a Previous Version of the Cisco MGC Software (Release 7.4(x))

Installing SC Software Release 7.3(x)

Installing SC Software Release 7.4(x)

Installing Patches for the SC Software

Installing a GUI Provisioning Tool on a Separate Server

Configuring SNMP Support Resources

Configuring the Execution Environment

Configuring SCP Queries

Initializing the Call Screening Database

Restarting the SC Software

Terminating Signaling Links

Verifying SC Software is Running Properly

Resetting the Configuration

Provisioning the Configuration


Note Always consult the latest Release Notes for Cisco Media Gateway Controller Software Release 7 (available from your Cisco representative) to make sure that you have the most current release of software and that no additional patches are required. If patches are required, consult the release notes for patch installation procedures.



Tip Many of the procedures in this chapter require using an editor such as vi to make changes to files. If you experience screen viewing problems, try the following:


If you are not sure which shell you are using, enter the following commands:

TERM=xterm export TERM stty rows 24

If you are using a Bourne shell, enter the TERM=vt100; export TERM command.

If you are using a C shell, enter the setenv TERM vt100 command.

Identifying the Active Configuration

Identify and make note of the name of the active configuration by performing the following steps:


Step 1 Log in to the SC host to be upgraded and enter the following UNIX command to access the configuration library:

config-lib

The system returns a response similar to the following.

The Configuration File Library Main Menu

1. List Configuration Versions in Library 2. Save Production to a new Library Version 3. Copy Library Version to Production 4. Remove Configuration Library Version Enter Selection or 'q' to quit>

Step 2 Enter 1 at the prompt to list the configuration versions in the library.

At the bottom of the list, a configuration is identified as being the current production version. This is the name of your active configuration.


Removing a Previous Version of the Cisco Telephony Controller Software (Release 4 and Release 7.3(x))


Note If you are removing Software Release or 7.4, follow the instructions in the "Removing a Previous Version of the Cisco MGC Software (Release 7.4(x))" section.


Before upgrading the SC software, you must first uninstall the previous software version. To remove the Cisco telephony controller software, complete the following steps:


Step 1 Log in at the console as the root user.

Step 2 Insert the SC host software Version 7.3 CD-ROM into the CD-ROM drive and enter the following commands:

# cd /cdrom/cdrom0 # ./uninstall.sh

Step 3 The system asks if you want to use the supplied administrative file to perform an unattended package removal. This process removes all the packages automatically.


Timesaver If you do not accept the unattended removal, the system prompts you before removing each package individually.


Step 4 Type y (yes) and press Enter to accept unattended package removal. The system displays a list of packages as it removes them.

When package removal is finished, the following message appears:

Uninstallation log can be found in /tmp/uninstall.log.

Step 5 Enter the following command:

cd /etc

Step 6 Open the group file with your editor.

Step 7 Make sure that the "transpath" group is removed. This group must be removed in order to accept default software installation later.

Step 8 Save any changes to the group file and close it.


This completes the removal of the previous version of the telephony controller software. If you have questions or need assistance, see the "Obtaining Technical Assistance" section on page xviii.

Removing a Previous Version of the Cisco MGC Software (Release 7.4(x))

Before upgrading an existing release of the SC host software, you must first uninstall the previous software version.


Note If you are removing Software Release 4 or 7.3, follow the instructions in the "Removing a Previous Version of the Cisco Telephony Controller Software (Release 4 and Release 7.3(x))" section.


To remove the SC host software, complete the following steps:


Step 1 Log in at the console as the root user.

Step 2 Insert the SC host Software Version 7.4 CD-ROM into the CD-ROM drive and enter the following commands:

# ./uninstall.sh

Step 3 If you are upgrading from a previous version of software Release 7, answer y to the following prompt. If this is an initial installation, answer n:

If you answer no to the following question you will lose all new provisioning work. Is the uninstall being done in order to upgrade to a new version of the software? [y] [y,n,?,q]

Step 4 The system asks if you want to use the supplied administrative file to perform an unattended package removal. This process removes all the packages automatically.


Timesaver If you do not accept the unattended removal, the system prompts you before removing each package individually.


Step 5 Type y (yes) and press Enter to accept unattended package removal. The system displays a list of packages as it removes them.

When package removal is finished, the following message appears:

Uninstallation log can be found in /tmp/uninstall.log.

Step 6 Enter the following command:

cd /etc

Step 7 Open the group file with your editor.

Step 8 Make sure that the "transpath" and "mgcgrp" groups are removed. These groups must be removed in order to accept default software installation later.

Step 9 Save any changes to the group file and close it.


This completes the removal of the previous version of the SC host software. If you have questions or need assistance, see the "Obtaining Technical Assistance" section on page xviii.

Installing SC Software Release 7.3(x)

To install Software Release 7.3(x), follow these steps:


Note You must be logged in as root. Do not log in as another user and enter su to become root. Logging in as root might require use of a console connected to the SC host.



Step 1 Insert the SC host software Release 7.3(x) CD into the CD-ROM drive.

Step 2 To install the Release 7.3(x) software, enter the following commands:

# cd /cdrom/cdrom0 # ./install.sh

Step 3 The following prompt appears:

Use supplied admin file for unattended install? [n] [y,n,?,q]

Answer y to perform an unattended installation. If you answer n, you must answer prompts and press Enter for each package that is installed.


Note The initial installation takes approximately 1 hour.


Step 4 The following prompt appears:

Install Telephony Configuration Manager (TCM) package? [n] [y,n,?,q]

Answer y if you want to install the CMM on this host.


Tips To install the CMM on a separate host, follow the steps in "Installing the CMM" section.


Step 5 The following prompt appears:

Base directory for CMM (default /opt/VSCprov) [?,q]

Press Enter to accept the default directory, /opt/VSCprov. We recommend that you not change the directory.

Step 6 The following prompt appears:

The CSCOgu000 utilities package must be installed prior to other components but has not been detected on your system. Would you like to install it now? [y] [y,n,?,q]

Answer y to install the utilities package. This package must be installed before you install the rest of the software.


Caution Before accepting the default user ID and group ID as recommended in the step below, you must make sure old transpath IDs are deleted in the /etc/group directory. We recommend that the group directory itself be deleted.

Step 7 The following prompts appear:

Enter transpath user name [transpath] Enter transpath UID [20000] Enter transpath group name [transpath]

We recommend that you accept the default values (by pressing Enter).

You can, however, specify a different user ID and a group ID. If the ID you specify already exists on the system, the corresponding ID is determined and reused, or you are prompted to enter another ID.


Caution No validation is performed on the IDs you enter. If you enter an invalid ID, the utilities package does not add any accounts.

The system returns a message that the CSCOgu000 utilities package was successfully installed.

Step 8 Rebooting after a successful utilities package installation might or might not be necessary, based on your system configuration.

If a reboot is not required, the installation continues uninterrupted. When the installation is finished, continue to Step 9.

If a reboot is required, perform the following steps when prompted:

a. Type the command displayed on the screen and press Enter.


Note If the command shown on the screen does not work, you can enter the /usr/sbin/reboot command to reboot the system.


b. After the reboot finishes, restart install.sh to install the remaining packages. To restart install.sh, type each of the following commands at the # prompt and press Enter:

# cd /cdrom/cdrom0 # ./install.sh

c. When the package installation is finished, continue to Step 9.

Step 9 Press Enter to install the selected package. The installation script installs the drivers and reboots the host.


This completes installing the SC software.


Note When installing the software, only the active configuration files (located in /opt/TransPath/etc) are migrated. If you have older configurations you need to migrate, see the "Migrating Inactive SC Host Configurations" section.



Tip If you did not review your MML names in the components.dat and properties.dat files before beginning the upgrade, and your MML names did not conform to the new standards, you received a migration error. To correct the situation:



Step 1 Uninstall the failed package CSCOgc001 by entering the pkgrm CSCOgc001.pkg command. Answer Y to the prompts.

Step 2 Refer to the "Reviewing Your Components.dat and Properties.dat Files for Potential Problems" section on page 1-3 for instructions on editing your MML names.

Step 3 Reinstall the package by changing to the /cdrom/cdrom0/APPLICATIONS directory and entering the pkgadd -d CSCOgc001.pkg command.


Installing SC Software Release 7.4(x)

To install Software Release 7.4(x), follow these steps:


Note You must be logged in as root. Do not log in as another user and enter su to become root. Logging in as root might require use of a console connected to the SC host.



Step 1 Log in as root and go to the # prompt.

Step 2 Enter the following command:

cd /etc

Step 3 Open the password file with your editor.

Step 4 Check that /opt/TransPath does not appear in the path of any user; if it does, change the path to /opt/CiscoMGC.

Step 5 Save any changes to the password file.

Step 6 Close the password file.

Step 7 Insert the SC host Software Release 7.4(x) CD into the CD-ROM drive.


Caution If you are upgrading to a new software release, you must first copy the new software from the CD-ROM to an appropriate directory in your system (for example, create a directory as root user under /opt), then perform the installation from that directory. This step prevents possible CD-ROM ejection problems.

When the upgrade has successfully completed, it is strongly recommended that you delete the software you copied from the CD-ROM to your directory, to avoid running out of disk space.

Step 8 To install the Release 7.4(x) SC host software, enter the following command:

# ./install.sh

Step 9 The following prompt appears:

Use supplied admin file for unattended install? [n] [y,n,?,q]

Answer y to perform an unattended installation. If you answer n, you must answer prompts and press Enter for each package that is installed.


Note The initial installation takes approximately 1 hour.


Step 10 The following prompt appears:

Install Cisco Media Gateway Controller Manager (CMM/Toolkit) package? [n] [y,n,?,q]

Answer y if you want to install the CMM and the Toolkit applications on this host.


Tips To install the CMM on a separate host, follow the steps in the "Installing the CMM" section.


Step 11 The following prompt appears:

Base directory for CMM/Toolkit (default /opt/CMM) [?,q]

Press Enter to accept the default directory, /opt/CMM. We recommend that you not change the directory.

Step 12 The following prompt appears:

The CSCOgu000 utilities package must be installed prior to other components but has not been detected on your system. Would you like to install it now? [y] [y,n,?,q]

Answer y to install the utilities package. This package must be installed before you install the rest of the software.


Caution Before accepting the default user ID and group ID as recommended in the step below, you must make sure old transpath IDs are deleted in the /etc/group directory. We recommend that the group directory itself be deleted.

Step 13 The following prompts appear:

Base directory for CiscoMGC (default /opt/CiscoMGC) [?,q] Enter CiscoMGC user name [mgcusr] Enter CiscoMGC UID [20000] Enter CiscoMGC group name [mgcgrp] Enter CiscoMGC GID [2000]

We recommend that you accept the default values for each of the prompts (by pressing Enter).

You can, however, specify a different user ID and a group ID. If the ID you specify already exists on the system, the corresponding ID will be determined and reused, or you will be prompted to enter another ID.


Caution No validation is performed on the IDs you enter. If you enter an invalid ID, the utilities package does not add any accounts.

The system returns a message that the CSCOgu000 utilities package was successfully installed.

Step 14 Rebooting after a successful utilities package installation might or might not be necessary, based on your system configuration.


Note Rebooting may take about 5 minutes.


If a reboot is not required, the installation continues uninterrupted. When the installation is finished, continue to Step 15.

If a reboot is required, perform the following steps when prompted:

a. Type the command displayed on the screen and press Enter.


Note If the command shown on the screen does not work, you can enter the /usr/sbin/reboot command to reboot the system.


b. After the reboot finishes, restart install.sh to install the remaining packages. To restart install.sh, type each of the following commands at the # prompt and press Enter:

# ./install.sh

c. The following prompts display:

Use supplied admin file for unattended install? [n] [y,n,?,q]
Install Cisco Media Gateway Controller Manager (CMM/Toolkit) package? [n] [y,n,?,q]

d. Type y for each of the prompts and press Enter.

e. When the package installation is finished, continue to Step 15.

Step 15 The system checks the memory and CPUs in the host. If you do not have enough memory or CPUs, a caution appears. You will get the Maximum Sustained/High Calls prompt, but it is possible that you will not get a warning on host resources.

After the check is complete, the following prompt appears:

Configure System for (1) Maximum Sustained Calls (2) High Call Throughput Enter 1 or 2 or q to quit


Note Options 1 and 2 are performance tuning options that allow optimizing certain parameters and settings on the system for better performance, based on your system requirements. This choice should have been resolved when Cisco analyzed your system requirements.


Enter 1 or 2 to choose the option you want and press Enter.

Step 16 Press Enter to install the selected package. The installation script installs the drivers and reboots the host.


This completes installing the SC software.


Note When installing the software, only the active configuration files (located in /opt/CiscoMGC/etc) are migrated. If you have older configurations you need to migrate, see the "Migrating Inactive SC Host Configurations" section.



Tip If you did not review your MML names in the components.dat and properties.dat files before beginning the upgrade, and your MML names did not conform to the new standards, you received a migration error. To correct the situation:



Step 1 Uninstall the failed package CSCOgc001 by entering the pkgrm CSCOgc001.pkg command. Answer Y to the prompts.

Step 2 Refer to the "Reviewing Your Components.dat and Properties.dat Files for Potential Problems" section on page 1-3 for instructions on editing your MML names.

Step 3 Reinstall the package by changing to the /cdrom/cdrom0/APPLICATIONS directory and entering the pkgadd -d CSCOgc001.pkg command.


Installing Patches for the SC Software

There may be new patches available for your new SC software. Check the following URL for the latest patches:

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

Click on the link for the software version of the Cisco Media Gateway Controller software that you just installed. The README files contain information about installing the patches. Download the files you need and follow the README file instructions.

For more information on patches for your release of the SC software, refer to the Release Notes for the Cisco Media Gateway Controller Software Release 7.

Installing a GUI Provisioning Tool on a Separate Server

You can install the GUI provisioning tools for the Cisco SC2200 on separate servers. The procedures to install the various GUI provisioning tools are described in the following sections:

Installing the CMM

Installing the Voice Service Provisioning Tool


Note The Voice Services Provisioning Tool (VSPT) must be installed on a separate server than the SC software.


Installing the CMM

You can install the CMM on a separate server than the SC software. To install only the CMM, perform the following steps:


Step 1 Insert the Cisco Media Gateway Controller Release 7 CD-ROM into the CD-ROM drive of the separate server.

Step 2 Change to the directory containing the CD-ROM by entering the following:

cd /cdrom/cdrom0

Step 3 Enter the following command:

./install-cmm-tool.sh

Answer yes to the onscreen prompts.


This completes installing the CMM on a separate host. Proceed to the "Configuring SNMP Support Resources" section.

Installing the Voice Service Provisioning Tool

The Voice Service Provisioning Tool (VSPT) is a graphical configuration/provisioning tool that enables you to create or modify configuration files across multiple devices such as MGCs and Cisco Media Gateways. If you are a registered Cisco.com user, you can download the VSPT from the Cisco website. For more information on VSPT, see Cisco Voice Services Provisioning Tool Users Guide.

The following files are located on the VSPT:

Table 7-1 Voice Service Provisioning Tool Installation CD Files

File
Description

setup

Installation script

setup.class

Install Shield installation class file

classes/

Voice Service Provisioning Tool class and property files

jre/

Java Runtime Environment


Prerequisites

To install the VSPT, you must have the following:

Sun Sparc station running Solaris 2.6 or greater

Note Running the VSPT on the same host as the MGC can adversely impact performance. Cisco recommends using a separate server.

Root user access

Disk Space:

Approximately 20 MBs of disk space for installation

Directory /var/opt/data/:

Approximately 1 MB for each configuration

Approximately 1 MB for each configuration snapshot

Directory /var/opt/log/:

Approximately 0.5 MB for each deployment

RAM:

Minimum: 128 MBs

Recommended: 256 MBs or greater

Swap space:

Minimum: 128 MBs

Recommended: 256 MBs or greater

Upgrading VSPT Software

If you have an older version of VSPT already installed (such as VSPT Version 1.1) and you are upgrading to VSPT Version 1.5, the existing VSPT data is automatically migrated to VSPT version 1.5; you do not need to uninstall the older version. However, if an incremental version is detected during the installation you will be prompted to uninstall the older version (for example, Version 1.5.1 cannot co-exist with Version 1.5.2 and must first be uninstalled).

To uninstall the software:


Note Since the uninstall directory and files are removed during uninstall, do not run the uninstall script from within the /opt/CSCOspgw directory.



Step 1 Enter the following commands:

su -root

cd /

/opt/CSCOspgw/uninstall/uninstall

The uninstallation process removes all files and directories created by the installation process. If a directory contains a file that was not created during the installation process, it is not removed and is logged in the uninstall.log file. This might occur in the data and logs directories.

Step 2 Proceed with the VSPT software installation (see Installing the VSPT Software).


Installing the VSPT Software

To install VSPT, follow the procedures listed below:


Step 1 Download the software from the following Cisco website:

http:/www/cisco.com/cgi-bin/tablebuild.pl/vspt


Note You must be a registered Cisco.com user to download this software.


Step 2 You will be prompted through the installation process.


This completes the VSPT software installation. If you have questions or need assistance, see the "Obtaining Technical Assistance" section on page xviii.

Configuring SNMP Support Resources

The Cisco MGC software includes a Simple Network Management Protocol (SNMP) agent subsystem that provides an alarm management interface on the SC host. It uses SNMP to report events, or traps (such as alarms), to your SNMP Manager and to provide access to the Cisco MGC Management Information Base (MIB).

The SNMP agent subsystem reports the following event categories to your SNMP Manager:

1. Communications

2. Quality of Service

3. Processing

4. Equipment

5. Environment

In a continuous-service or high-availability configuration, the SNMP agent subsystem runs on both the active and standby Cisco MGCs.


Note SNMP MIB measurements are only valid only on the active Cisco MGC. They are not replicated on the standby Cisco MGC.


To configure the SNMP resources, complete the following steps:


Step 1 Log in to the active Cisco MGC as root and change to the /etc directory using the following UNIX command:

cd /etc

Step 2 Verify that the name in the nodename file (using the more nodename UNIX command) matches a host name or nickname in the hosts file.


Note Entries in the hosts file are in the following format: IP_address host_name nickname.


If the names match, proceed to Step 4. Otherwise, proceed to Step 3.

Step 3 Use a text editing utility, such as vi, to edit the nodename file and enter the host name of this Cisco MGC.

Save your changes and exit the utility when you are finished.

Step 4 Verify that the services file lists the following default SNMP ports using the following UNIX command:

more services

The following lines should display among other port entries:

snmp 161/udp snmp-trap 162/udp

If the ports for SNMP are listed, proceed to Step 9. Otherwise, continue to Step 3.

Step 5 Edit the services file using a text editor such as vi to add these two lines for snmp and snmp-trap port information.

vi services snmp 161/udp snmp-trap 162/udp

Save your changes and exit the editor when you are finished.

Step 6 Verify that the file is properly edited using the following UNIX command:

more services

The following lines should display among other port entries (otherwise, repeat Step 3):

snmp 161/udp snmp-trap 162/udp

Step 7 Verify that the SNMP process is running using the following UNIX command:

ps -ef | grep snmpd

Step 8 Stop the existing SNMP process using the following UNIX command. This command automatically restarts the SNMP process with a new ID.

kill -HUP process_ID

Where process_ID is the process ID number for the SNMP process, as identified in Step 5.

Step 9 Verify that the SNMP process is running using the following UNIX command:

ps -ef | grep snmpd

Step 10 Verify that the SNMP process is no longer generating errors by checking the snmpd.log. To do this, enter the following command:

more/tmp/snmpd.log

If no errors are found, this means the process is working and you can use the ports for SNMP configuration and trap generation.

Step 11 Using FTP, transfer the following MIBs (located in /opt/CiscoMGC/snmp) from the Cisco SC host to the machine on which the SNMP manager runs:

CISCO-SMI.my

v3-tgt.my

tp.my

provisioning.my

measurement.my

Step 12 Load the MIBs into the SNMP manager (for example, you can use the xnmnloadmib -load command from HP OpenView).


Note See your SNMP manager documentation for more information. Cisco does not recommend a specific SNMP manager; however, this chapter gives examples using the Hewlett-Packard (HP) OpenView Network Node Manager.


HP OpenView Example: If you are using HP OpenView Network Node Manager as your SNMP manager, follow these procedures to load your MIB: (a) Select Options from the File Menu and choose Load/Unload MIBs:SNMP. (b) From the Load/Unload MIBs: SNMP window (on the lower left of your screen). (c) Click the Load... button. (d) From the "Load/Unload MIBs:SNMP /Load MIB from File" window, select the MIB to load (for example, tp.my). (e) Click OK.

Tip For more detailed information about configuring HP OpenView, see Appendix A, "HP OpenView Sample SNMP Configuration," in Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.


Step 13 Connect the SNMP events to an event category to display the event. As Cisco MGC events are connected, you can alter the format of the event messages for easier viewing.


Note On many SNMP managers, event categories can be added so that customer-specific events can be mapped to corresponding categories.


HP OpenView Event Configuration Example: If you are using HP OpenView Network Node Manager, follow these procedures to configure an event: (a) Select Options from the File Menu and choose Event Configuration. (b) From the Event Configuration window, in the Enterprise Identification list, select transpath. (c) In the Event Identification list, double click on each of the event types, one at a time. (d) If desired, change the event information display. To change the format of an event, from the Event Configurator / Modify Event window, enter a format in the Event Log Message Box to change the format and labels for received events of this type.

The following example shows how an event can be reformatted using the HP OpenView Network Node Manager. ID# $13 Name $12 Set $10 MMLname $4 CatDesc $11 \nCompDesc $3 Severity $8 CompID $6 CompType $5 CatID $14\nAlarmNotify $9 AlarmTime$1 ParentID $2 AlarmReported $7\n$o

Tip For more detailed information about configuring HP OpenView, see Appendix A, "HP OpenView Sample SNMP Configuration," in Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.


Step 14 Verify that SNMP is working by performing the following steps:

a. Begin monitoring an Ethernet interface for SNMP trap traffic by opening a telnet session, logging in to the active Cisco MGC host as root and entering the following UNIX command:

snoop -d eth_int port 162

Where eth_int is the name of the Ethernet interface.

For example, to execute this command on an Ethernet interface called hme1, you would enter the following command:

snoop -d hme1 port 162

b. Open a second telnet session on the active Cisco MGC, start an MML session and enter a command that causes an alarm to be generated. For example, changing the state of a destination causes an alarm to be generated. To take a destination called dpc1 out-of-service, enter the following MML command:

set-dest-state:dpc1:OOS

Entering a command like this should cause an trap notification to appear in the first telnet session. For example, the following trap information is displayed in the first telnet session when a destination is taken out-of-service and then returned to service:

Using device /dev/hme (promiscuous mode) va-perch -> nssuramb4.cisco.com UDP D=162 S=46842 LEN=446 va-perch -> nssuramb4.cisco.com UDP D=162 S=46842 LEN=446

If trap information appears in the first telnet session, the procedure is complete.

If nothing appears in the first telnet session, re-enter the snoop command for the other Ethernet interface and repeat the above step. If trap information fails to appear in either Ethernet interface, proceed to Step 15.

Step 15 Contact the Cisco TAC for assistance in resolving this problem. Refer to "Obtaining Technical Assistance" section on page xviii for more information on contacting the Cisco TAC.


Sample Configured snmpd.cf File

The following shows a sample snmpd.cnf file.


Note This sample configuration enables both snmpv1 and snmpv2 traps. Therefore, you will see two coldStart traps when the software is initialized—one for version1 and one for version2.


# Entry type: sysDescr # Entry format: octetString sysDescr "SNMPv3 agent from Cisco Systems, Inc."

# Entry type: sysObjectID # Entry format: OID sysObjectID transpath

# Entry type: sysLocation # Entry format: octetString sysLocation "Herndon, Virginia"

# Entry type: sysContact # Entry format: octetString sysContact "Cisco Systems, Inc. +1 703 484 3000"

# Entry type: sysName # Entry format: octetString sysName "NSSU - MGC"

# Entry type: snmpEnableAuthenTraps # Entry format: integer snmpEnableAuthenTraps 1


# Entry type: MAX_THREADS # Entry format: integer MAX_THREADS 25


# Entry type: MAX_PDU_TIME # Entry format: integer MAX_PDU_TIME 80000

# Entry type: MAX_OUTPUT_WAITING # Entry format: integer MAX_OUTPUT_WAITING 65536

# Entry type: MAX_SUBAGENTS # Entry format: integer MAX_SUBAGENTS 15

# Entry type: subagent # Entry format: octetString

#Entry type: snmpCommunityEntry #Format: snmpCommunityIndex (text) # snmpCommunityName (text) # snmpCommunitySecurityName (text) # snmpCommunityContextEngineID (octetString) # snmpCommunityContextName (text) # snmpCommunityTransportTag (text) # snmpCommunityStorageType (nonVolatile, permanent, readOnly) snmpCommunityEntry admin mgcusr mgcusr localSnmpID - - nonVolatile snmpCommunityEntry readonly public public localSnmpID - - nonVolatile snmpCommunityEntry user private private localSnmpID - - nonVolatile

# Entry type: communityEntry # Entry format: srCommunityAuthSnmpID (snmpID) # srCommunityName (textOctetString) # srCommunityGroupName (textOctetString) # srCommunityContextSnmpID (snmpID) # srCommunityContextName (textOctetString) # srCommunityTransportLabel (textOctetString) # srCommunityMemoryType (integer)

# Entry type: snmpEngineBoots # Entry format: integer snmpEngineBoots 3

#Entry type: usmUserEntry #Format: usmUserEngineID (octetString) # usmUserName (text) # usmUserAuthProtocol (OID) # usmUserPrivProtocol (OID) # usmUserStorageType (nonVolatile, permanent, readOnly) # usmTargetTag (text) # AuthKey (octetString) # PrivKey (octetString)

#Entry type: vacmAccessEntry #Format: vacmGroupName (text) # vacmAccessContextPrefix (text) # vacmAccessSecurityModel (snmpv1, snmpv2c, snmpv2s, usm, http) # vacmAccessSecurityLevel (noAuthNoPriv, authNoPriv, authPriv) # vacmAccessContextMatch (exact, prefix) # vacmAccessReadViewName (text) # vacmAccessWriteViewName (text) # vacmAccessNotifyViewName (text) # vacmAccessStorageType (nonVolatile, permanent, readOnly) vacmAccessEntry User - snmpv1 noAuthNoPriv exact All RemoteWrite All \ nonVolatile vacmAccessEntry User - snmpv2c noAuthNoPriv exact All RemoteWrite All \ nonVolatile vacmAccessEntry Guest - snmpv1 noAuthNoPriv exact All - All nonVolatile vacmAccessEntry Guest - snmpv2c noAuthNoPriv exact All - All nonVolatile vacmAccessEntry SuperUser - snmpv1 noAuthNoPriv exact All Write All \ nonVolatile vacmAccessEntry SuperUser - snmpv2c noAuthNoPriv exact All Write All \ nonVolatile

#Entry type: vacmSecurityToGroupEntry #Format: vacmSecurityModel (snmpv1, snmpv2c, snmpv2s, usm, http) # vacmSecurityName (text) # vacmGroupName (text) # vacmSecurityToGroupStorageType (nonVolatile, permanent, readOnly) vacmSecurityToGroupEntry snmpv1 mgcusr SuperUser nonVolatile vacmSecurityToGroupEntry snmpv1 public Guest nonVolatile vacmSecurityToGroupEntry snmpv1 private User nonVolatile vacmSecurityToGroupEntry snmpv2c mgcusr SuperUser nonVolatile vacmSecurityToGroupEntry snmpv2c public Guest nonVolatile vacmSecurityToGroupEntry snmpv2c private User nonVolatile

#Entry type: vacmViewTreeFamilyEntry #Format: vacmViewTreeFamilyViewName (text) # vacmViewTreeFamilySubtree (OID) # vacmViewTreeFamilyMask (octetString) # vacmViewTreeFamilyType (included, excluded) # vacmViewTreeFamilyStorageType (nonVolatile, permanent, readOnly) vacmViewTreeFamilyEntry All iso - included nonVolatile vacmViewTreeFamilyEntry All 0.0 - included nonVolatile vacmViewTreeFamilyEntry All hrSWRunEntry.0.2147483647 ff:df excluded \ nonVolatile vacmViewTreeFamilyEntry All hrSWRunPerfEntry.0.2147483647 ff:df excluded \ nonVolatile vacmViewTreeFamilyEntry Write iso - included nonVolatile vacmViewTreeFamilyEntry Write mib_2 - excluded nonVolatile vacmViewTreeFamilyEntry RemoteWrite iso - included nonVolatile vacmViewTreeFamilyEntry RemoteWrite mib_2 - excluded nonVolatile vacmViewTreeFamilyEntry RemoteWrite critAppProcEntry.0.1 ff:f7 excluded \ nonVolatile vacmViewTreeFamilyEntry RemoteWrite critAppProcEntry.0.2 ff:f7 excluded \ nonVolatile vacmViewTreeFamilyEntry RemoteWrite critAppProcEntry.0.3 ff:f7 excluded \ nonVolatile vacmViewTreeFamilyEntry RemoteWrite critAppProcEntry.0.4 ff:f7 excluded \ nonVolatile

#Entry type: snmpNotifyEntry #Format: snmpNotifyName (text) # snmpNotifyTag (text) # snmpNotifyType (trap(1), inform(2)) # snmpNotifyStorageType (nonVolatile, permanent, readOnly) snmpNotifyEntry 32 TrapSink trap nonVolatile

#Entry type: snmpTargetAddrEntry #Format: snmpTargetAddrName (text) # snmpTargetAddrTDomain (snmpUDPDomain, snmpIPXDomain, etc.) # snmpTargetAddrTAddress (transport address,i.e. 192.147.142.254:0) # snmpTargetAddrTimeout (integer) # snmpTargetAddrRetryCount (integer) # snmpTargetAddrTagList (text) # snmpTargetAddrParams (text) # snmpTargetAddrStorageType (nonVolatile, permanent, readOnly) # snmpTargetAddrTMask (transport mask, i.e. 255.255.255.255:0) # snmpTargetAddrMMS (integer) snmpTargetAddrEntry 34 snmpUDPDomain 127.0.0.1:0 100 3 TrapSink \ v2cExampleParams nonVolatile 255.255.255.255:0 2048

#Entry type: snmpTargetParamsEntry #Format: snmpTargetParamsName (text) # snmpTargetParamsMPModel (integer) # snmpTargetParamsSecurityModel (snmpv1, snmpv2c, snmpv2s, usm) # snmpTargetParamsSecurityName (text) # snmpTargetParamsSecurityLevel (noAuthNoPriv,authNoPriv,authPriv) # snmpTargetParamsStorageType (nonVolatile, permanent, readOnly) snmpTargetParamsEntry v1ExampleParams 0 snmpv1 public noAuthNoPriv \ nonVolatile snmpTargetParamsEntry v2cExampleParams 1 snmpv2c public noAuthNoPriv \ nonVolatile

#Entry type: snmpNotifyFilterProfileEntry #Format: snmpTargetParamsName (text) # snmpNotifyFilterProfileName (text) # snmpNotifyFilterProfileStorageType (nonVolatile,permanent,readOnly)

#Entry type: snmpNotifyFilterEntry #Format: snmpNotifyFilterProfileName (text) # snmpNotifyFilterSubtree (OID) # snmpNotifyFilterMask (octetString) # snmpNotifyFilterType (included, excluded) # snmpNotifyFilterStorageType (nonVolatile, permanent, readOnly)

#Entry type: httpUserNameEntry #Format: httpUserName (text) # httpUserGroupName (text) # httpUserTransportLabel (text) # httpUserStorageType (nonVolatile, permanent, readOnly) # Password (octetString)

Configuring the Execution Environment

This section provides instructions for configuring the SC host execution environment, and contains the following topics:

Opening the XECfgParm.dat File

Configuring Basic System Information

Specifying IP Addresses

Configuring Engine Parameters

Configuring Automatic Congestion Control

Enabling Call Screening

Configuring Call Detail Record File Output

Configuring the System Type

Configuring the Clearing Location and Default Location Parameters

Configuring *.GWClearChannelAlgorithm Parameter

Configuring Switchover

Initializing the Provisioning Object Manager (POM)

Saving the XECfgParm.dat File

The configuration data file, or XECfgParm.dat file (located in /opt/CiscoMGC/etc), lists all the components in the SC host and defines how it operates. The software automatically migrates your data for the previous release in the XECfgParm.dat file to current Release 7 format. The XECfgParm.dat file contains your execution environment parameters. However, only the default logging levels are migrated for the log priority parameters, including the foverd.logPrio parameter. Therefore, if you have set up specialized logging, you need to reset the parameters after software installation by editing the XECfgParm.dat file.

For more information on the XECfgParm.dat file, including sample files, see the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.

You must manually edit the execution environment parameters in the XECfgParm.dat file to initialize and configure the SC host software application.


Caution Do not edit any XECfgParm.dat file parameters not listed below, and remember that all parameters are case-sensitive. Otherwise, your system might not work as intended.

Opening the XECfgParm.dat File

To access and edit the XECfgParm.dat file, complete the following steps:


Note If you have two SC host in a continuous-service configuration, the XECfgParm.dat files will be different for each host.



Step 1 Log in to the SC host as root and change to the /opt/CiscoMGC/etc directory, which contains the XECfgParm.dat file used by your system.

Step 2 Open the XECfgParm.dat file with any text editor, such as vi



Tip Migrated parameters are identified in the XECfgParm.dat file. You should verify these parameters; however, you should concentrate on the new parameters when editing the file.


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:


Note If a parameter is identified as migrated, the previously configured value was saved during the upgrade and used in the new XECfgParm.dat file after migration.


Parameter
Modification

*.transpathId

To identify the local SC host host in a continuous-service or high-availability system, enter any one- or two-digit integer.

Note If you have two SC host hosts in a continuous-service or high-availability system, this number must be different in the XECfgParm.dat file for each host.

*.ownTranspathId

To identify the local SC host host in a continuous-service or high-availability system, enter the same value that you used for *.transpathID.

Note If you have two SC host hosts in a continuous-service or high-availability 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 field blank.

*.peerTranspathId

To identify the peer SC host host in a continuous-service or high-availability system, enter any one- or two-digit integer. The IDs must be unique in an active and a standby pair.

Note If you have two SC host hosts in a continuous-service or high-availability 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.

*.desiredPlatformState

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

master—If you have two (active and standby) SC host hosts, and you are editing the file on the active host

slave—If you have two (active and standby) SC host hosts, and you are editing the file on the standby host

standalone—If you have a simplex system

Note If you have two SC host hosts in a continuous-service or high-availability system, make sure that the active SC host is set to master and the standby host is set to slave.

*.SysCheckpointEnabled

To enable or disable checkpointing, enter one of the following values:

falseDisables checkpointing. Calls are not preserved during a switchover, and status messages are not sent to the replicator (default).

trueEnables checkpointing. Calls that are in the talking state are preserved and survive a control switchover. All status checkpointing information is sent to the replicator on the active side.

Note If you have two SC host hosts in a switchover configuration, enter true. If you have a standalone configuration, enter false.

*.numberOfThreads

To specify the number of threads generated by multithreaded processes such as the engine and the log master, enter 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).

*.stPort

Port number used between peer components or processes.

Enter any unused port number greater than 1024; for example, 7000.

Note If you have two SC host hosts in a continuous-service or high-availability configuration, enter a different number for this value in the XECfgParm.dat file on the secondary host; for example, 7001.

*.OwnClli

Common language location identifier. To initiate circuit query validation if circuit queries are supported, enter an alphanumeric string of as many as 24 characters.

Default: TTT-SS-BB-XXX

Example: 1-22-33-444


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 MGC, it is mandatory to have these on distinct subnets.


For example, consider the following configuration:

*.ipAddrLocalA = 172.22.119.108 *.ipAddrLocalB = 172.22.119.54

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

*.ipAddrLocalA = 172.22.119.108 *.ipAddrLocalB = 172.22.120.54

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

*.ipAddrLocalA

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

Note This address is the same value as *.IP_Addr1, and is the hme0 interface.


Caution No other machine on the network should have *.ipAddrLocalA set to 0.0.0.0.

*.ipAddrPeerA

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

Note If you have two SC host hosts in a continuous-service or high-availability configuration, this value is set to the IP address of the second host.

*.ipAddrLocalB

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

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

*.ipAddrPeerB

Enter the second corresponding peer IP address; used for checkpointing and switchover heartbeats. This is the address of the hme1 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 hme0 interface.

*.IP_Addr2

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

*.IP_Addr3

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

*.IP_Addr4

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


Configuring Engine Parameters

In order 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.

Default: 0

For memory-critical configurations, use the default value.

For performance-critical configurations, set this value to 110000.

engine.CALL_MEM_CHUNK_SIZE

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

Default: 0

For memory-critical configurations, use the default value.

For performance-critical configurations, set this value to 110000.

engine.SysCdrCollection

To designate the format of call detail records (CDRs), enter one of the following values:

trueGenerates fold-style nontagged CDRs

false—Generates new tag, length, and value (TLV) format CDRs (default)

Note Typically, this value should be false.

engine.SysVirtualSwitch

To indicate whether the SC host 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)

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

Many GRS messages can become due for sending at the same time. This situation occurs if you have set the *.GRSEnabled parameter to true during provisioning. The *.GRSEnabled parameter is a property that is set on an SS7 signaling service (in the CMM) or an SS7 path (in MML).

GRS messages can be staggered if you send them in blocks. Set the engine.SysGRSBlockSize parameter to the number of messages to be sent in each block. Use the engine.SysGRSTimerInterval parameter to set the time from the start of one block to the start of the next.

Default: 0

Note This parameter operates independently for each SS7 route (each OPC/DPC pair).

engine.SysGeneratedCode

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.


Configuring Automatic Congestion Control

As of release 7.4(11), the Cisco SC2200 supports Automatic Congestion Control (ACC). ACC regulates traffic to levels that can be handled effectively by the network by rejecting traffic when the system is congested. This increases the throughput of completed calls through the telephone network during periods of overload.

When the Cisco MGC is congested, an Automatic Congestion Level (ACL) indication is sent to adjacent signaling points using SS7 ISUP. Until the congestion abates, a certain percentage of calls are rejected. Detection of congestion is based on the measurement of the Cisco MGC's CPU utilization level.

ACC is controlled by parameters that are found in the XECfgParm.dat file and by a property associated with the signaling service, which are described in the following sections:

Overload Level Percentage Parameters

CPU Timer Interval Parameter

Maximum ACL Value

Overload Level Percentage Parameters

Use the following XECfgParm.dat parameters to set the overload level percentages:

Parameter
Description
Default Value
Valid Range

Ovl1OnsetThresh

Percentage of total CPU utilization at which overload level 1 is reached.

82

0 through 100

Ovl1AbateThresh

Percentage of total CPU utilization at which overload level 1 abates.

75

0 through 100

Ovl1RejectPercent

Percentage of calls that are rejected while overload level 1 is active.

25

0 through 100

Ovl2OnsetThresh

Percentage of total CPU utilization at which overload level 2 is reached.

90

0 through 100

Ovl2AbateThresh

Percentage of total CPU utilization at which overload level 2 abates.

77

0 through 100

Ovl2RejectPercent

Percentage of calls that are rejected while overload level 2 is active.

50

0 through 100

Ovl2OnsetThresh

Percentage of total CPU utilization at which overload level 2 is reached.

93

0 through 100

Ovl2AbateThresh

Percentage of total CPU utilization at which overload level 2 abates.

85

0 through 100

Ovl2RejectPercent

Percentage of calls that are rejected while overload level 2 is active.

100

0 through 100


CPU Timer Interval Parameter

The CPUTimerInterval parameter is used to specify the interval, in milliseconds, at which the CPU utilization level of the Cisco MGC is sampled. The default value is 1000. We recommend that you stay within the range of 500 to 2000 milliseconds.

Maximum ACL Value

Another component in ACC is the maximum ACL value. Since ANSI- and ITU-based signaling points have different maximum ACL values, the Cisco MGC uses a property, MaxACL, associated with an SS7 signaling service or trunk group to map the internal maximum ACL value to the value used by the adjacent signaling point.

When the Cisco MGC is congested, its congestion level can be reported to adjacent signaling points by the ACL value in the release message. ANSI-based signaling points use a range of 0 through 3 to define congestion and ITU-based signaling points use a range of 0 through 2 to define congestion. When MaxACL is set to 3, the internal maximum ACL value is mapped to the ANSI standard (the default value for MaxACL is 3). When MaxACL is set to 2, the internal maximum ACL value is mapped to the ITU standard. MaxACL also has a third possible setting, 0, which disables the sending of ACL indications in the Release message.

The procedure to set this property can be found in the Cisco MGC Software Release 7 Operations, Maintenance, and Troubleshooting Guide.

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

engine.SysScreeningCheck

To enable or disable the A-number and B-number analysis in the call screening database, enter one of the following values:

If you do not have the database environment set with all the required data populated, set this value to false (default).

If you have the database and want the system to access it, set this value to true.


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

engine.CDRtimeStamp

To specify the CDR file time-stamp unit, enter one of the following values:

S—Seconds (default).

M—Milliseconds; use this parameter if your configuration uses TCAP.


Note If you use 1110 in the engine.CDRmessageTypes parameter (for TCAP), you must specify milliseconds for the CDRtimeStamp value.


engine.CDRmessageTypes

To specify which call detail blocks (CDBs, statistics taken at various points in a call) are recorded during a call, enter one of the two following sets of values (each number represents a point in a call):

1010, 1020, 1030, 1040, 1050, 1060, 1070, 1080—Use this value if your CDR files will be read by a measurement server or by another CDR reader.

1060, 1110—Use this value if you will use the TLV converter to view CDR files.

1110Generates a CDR file containing all CDBs for a call (end of call). If you choose 1110, you must specify milliseconds in the CDRtimeStamp parameter.

1060—Required.

1080—An external value, used for TCAP.

CDRDmpr.CDR

To indicate whether the standard data dumper writes out CDR files, enter one of the following values:

true—Standard data dumper opens a CDR file and logs call detail blocks (CDBs).

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

Note The default CDR file format has been changed from an ASCII format in Release 4 to a binary format in Release 7. Use the dmpr.callDetail parameter to convert the files to an ASCII format, if necessary.

CDRDmpr.callDetail

If your configuration requires ASCII-formatted CDR files, enter /opt/CiscoMGC/bin/converter.

Default: /opt/CiscoMGC/local/cdbscript.sh

Use this value if you have created a script to process CDRs; this script is stored as cdbscript.sh.

Optional: /opt/CiscoMGC/bin/converter

Use this value if binary CDR files need to be converted to ASCII.

For maximum performance, change this value to none, as follows:

cdrDmpr.callDetail = #

Note The default CDR file format is binary format. The command above automatically generates CDR files in an ASCII, comma-delimited format in addition to the default, binary format. The ASCII file has a .csv extension. For more information on generating and viewing CDR files, see Cisco Media Gateway Controller Software Release 7 Operations, Maintenance, and Troubleshooting Guide.



Note For a detailed description of CDR files, see Cisco Media Gateway Controller Software Release 7 Billing Interface Guide.


Configuring the System Type

To configure system alarm information, modify the following parameter in the XE section of the XECfgParm.dat file:

Parameter
Modification

XE.systemType

To specify the system type for alarm LEDs, enter one of the following values:

NETRA—Sun Solaris Netra t 1100, t 1120 (internal LEDs, alarm relays)

SPARC—Generic box (no alarm relays)

SPARC-ARU—Generic box (external alarm relays)

Default: SPARC


Configuring the Clearing Location and Default Location Parameters

This property overrides the Clearing Location and Default Location fields in Call Context. Change the clearing location value if you need a value other than the default to be sent to the switch. Change the default location 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.

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:

0—The Cisco MGC software uses the default Clearing Location in Call Context.

1—The Cisco MGC software overrides the Clearing Location in Call Context with LOCATION_USER.

2—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PRIVATE_LOCAL.

3—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PUBLIC_LOCAL.

4—The Cisco MGC software overrides the Clearing Location in Call Context with LOCATION_TRANSIT.

5—The Cisco MGC software overrides the Clearing Location in Call Context with LOCATION_ PUBLIC_REMOTE.

6—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PRIVATE_REMOTE.

7—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ INTERNATIONAL.

8—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ INTERWORKING.

9—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ LOCAL_INTERFACE.

10—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ LOCAL_LOCAL.

11—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ LOCAL_REMOTE.

12—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PACKET_MANAGER.

13—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ UNKNOWN.

DefaultLocation

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:

0—The Cisco MGC software uses the Default Location in Call Context.

1—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_USER.

2—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PRIVATE_LOCAL.

3—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PUBLIC_LOCAL.

4—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_TRANSIT.

5—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PUBLIC_REMOTE.

6—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PRIVATE_REMOTE.

7—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ INTERNATIONAL.

8—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ INTERWORKING.

9—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ LOCAL_INTERFACE.

10—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ LOCAL_LOCAL.

11—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ LOCAL_REMOTE.

12—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PACKET_MANAGER.

13—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ UNKNOWN.


Configuring *.GWClearChannelAlgorithm Parameter

Clear channel calls get through only if you set the *.GWClearChannelAlgorithm parameter to a value other than null. This parameter is sent to the Cisco MGC when the connection is created and matches the Cisco MGC's clear channel parameter.

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 SC host hosts in a continuous-service or high-availability 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 another machine does have that value, 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 SC host 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 another machine does have that value, 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 SC host 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 another machine does have that value, 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 SC host 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 another machine does have that value, 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. For more information, see Release Notes for Cisco Media Gateway Controller Software Release 7.

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.

Default: 4000 milliseconds (4 seconds).


:


Note For more information on switchover, see the Cisco Media Gateway Controller Software Release 7 Operations, Maintenance, and Troubleshooting Guide.


Initializing the Provisioning Object Manager (POM)

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

Parameter
Information
Modification

pom.dataSync

New parameter

Used in a continuous-service configuration to indicate that the POM should synchronize the provisioning data at startup. If you have a standalone system, set this value to false.

Note In the upgrade, if you have a continuous-service or high-availability configuration, you must initially set this value on the second host server you are upgrading to false. After you upgrade the second SC host and both hosts are running the same version of software, you must change this value to true.

pom.port

New parameter

Used in a continuous-service configuration to indicate the port number 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 only modify this value if the default port (4001) is being used by another process or application.


Saving the XECfgParm.dat File

Save your changes and close the editor.



Note For a complete list of parameters, their function, definition, and example values, see the Cisco Media Gateway Controller Software Release 7 Reference Guide.


This completes the XE configuration. Continue the upgrade process as described in your chosen upgrade procedure.

Configuring SCP Queries

The Signal Control Point (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 will use to enable SCP database queries. The trigger.dat file (located in /opt/CiscoMGC/etc/trigger.dat), contains the message sending table that contains translation values. You must manually edit the parameters in the trigger.dat file to enable SCP queries.

This section contains the following topics:

Before You Start

Configuring the trigger.dat File Attributes


Caution Do not edit any trigger.dat file parameters not listed below, and remember that all parameters are case-sensitive. Otherwise, your system might not work as intended.

For more information on the trigger.dat file, including a sample configured file, see Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.

Before You Start

You will need to know the translationType value from the Global Title Translation tables on the STP. Get this value from the administrator of your STP.

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.



Caution Improper editing of the trigger.dat file can cause service interruption and prevent the Cisco MGC from correctly performing SCP database queries.

You can configure the following Cisco MGC trigger.dat file attributes to perform a Transaction Capabilities Application Part (TCAP) query:

Global Title Translation

Service Key Value

Translation Type

Configuring the Global Title Translation Attribute

Perform the following steps to configure the Global Title Translation attribute:


Step 1 Back up the trigger.dat file.

Step 2 Determine the Trigger Number that you need to edit. You can get this information from your network administrator.

Step 3 Navigate to directory /opt/CiscoMGC/etc.

Step 4 Open the trigger definition file in an ASCII text editor and search for the string $TriggerTable.

Step 5 Starting after the $TriggerTable line, count the number of rows equal to the TriggerType beginning from the number 1.


Note Do not count any row that is blank or that begins with a pound sign (#).


Step 6 When you find your row, note down the second number in that row. This number is the index to the $MessageSending table.

Step 7 Edit the file as follows:

a. In the $MessageSending table, select column 9, gtSsn (see Table 7-2).

b. In the table for your translation type, change the Global Title Translation value (column F9) to either 0 or 1. You can get this information from your network administrator. If the number is 0, use GTT. If the number is 1, use PC/SSN.

c. If you change the gtSsn value to 0, you must go to gtFormat in column 16 and reset the value to 0. If you set the value to 1, you must also set column 16 to a non-zero value.


Note See Table 7-2 for table values.


Step 8 Save your changes and close the editor.

Step 9 For your changes to take effect you must reboot the SC host by entering the following command:

# /etc/init.d/CiscoMGC start

Configuring the Service Key Value Attribute

Perform the following steps to configure the Service Key Value (tcv_sk) attribute:


Step 1 Back up the trigger.dat file.

Step 2 Determine the Trigger Number that you need to edit. You can get this information from your network administrator.

Step 3 Navigate to directory /opt/CiscoMGC/etc.

Step 4 Open the trigger definition file in an ASCII text editor and search for the string $TriggerTable.

Step 5 Starting after the $TriggerTable line, count the number of rows equal to the TriggerType beginning from the number 1.


Note Do not count any row that is blank or that begins with a pound sign (#).


Step 6 When you find your row, note down the second number in that row. This number is the index to the $MessageSending table.


Caution Do not change TCVs. You must verify that column 2 is equal to 1 before changing tcv_sk. If column 2 is not equal to 1, this is not an ETSI trigger and column 6 is a TCV, not an SK.

Step 7 Edit the file as follows:

a. In the $MessageSending table, select tcv_sk, in column 6 (see Table 7-2).

b. In the table, change the value for tcv_sk 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 Restart the SC host software by entering the following command:

# /etc/init.d/CiscoMGC start

Configuring the Translation Type Attribute

Perform the following steps to configure the Translation Type (translationType) attribute:


Step 1 Back up the trigger.dat file.

Step 2 Determine the Trigger Number that you need to edit. You can get this information from your network administrator.

Step 3 Navigate to directory /opt/CiscoMGC/etc.

Step 4 Open the trigger definition file in an ASCII text editor and search for the string $TriggerTable.

Step 5 Starting after the $TriggerTable line, count the number of rows equal to the TriggerType beginning from the number 1.


Note Do not count any row that is blank or that begins with a pound sign (#).


Step 6 When you find your row, note down the second number in that row. This number is the index to the $MessageSending table.


Caution You must verify that column 2 is equal to 2 or 3 before changing Translation Type. If column 2 is not equal to 2 or 3, this is not an ANSI trigger and Translation Type is not used.

Step 7 Edit the file as follows:

a. In the $MessageSending table, select translationType, in column 7 (see Table 7-2).

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 SC host by entering the following command:

# /etc/init.d/CiscoMGC start

Table 7-2

F1

F2

F3

F4

F5

F6

F7

F8

F9

F10

F11

F12

F13

F14

F15

F16

F17

F18

F19

F20

F21

Transport
tcapType
stpScpGroupIndex
msg
asn1Encoding
tcv_sk
translationType
tcapBodyType
gtSsn
dpcPres
ssnPres
dpcNetwork
dpcCluster
dpcMember
ssn
gtFormat
OS1
OS2
OS3
OS4
OS5

# MS 1: xxxxxx LNP

1 2 0 6 0 0 255 1 0 0 1 0 0 0 0 2 1 0 0 0 0

# MS 2: Generic LNP

1 2 0 6 0 37 255 1 0 0 1 0 0 0 0 2 2 0 0 0 0

# MS 3: xxxxxxx 800

2 1 1 1 0 0 0 1 0 0 1 0 0 0 0 2 3 0 0 0 0

# MS 4: ANSI AIN 800 NPA

1 2 0 6 0 4 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0

# MS 5: ANSI AIN 800 NPA-NXX

1 2 0 6 0 5 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0

# MS 6: ANSI AIN 800 NPA-NXX-XXX

1 2 0 6 0 8 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0

# MS 7: ANSI AIN 800 Termination information

1 2 0 5 0 0 255 1 0 0 1 0 0 0 0 2 5 0 0 0 0

# MS 8: ANSI PRE AIN 800

1 3 0 6 0 0 254 2 0 0 1 0 0 0 0 2 6 0 0 0 0

# MS 9: ANSI PRE AIN 800 Termination information

1 3 0 5 0 0 254 2 0 0 1 0 0 0 0 2 7 0 0 0 0

$MessageSending Table Values


Sample trigger.dat File

#--//****************************************************************************** #--//* Table_9.trigger * #--//* * #--//* TRIGGER TABLES * #--//* * #--//* (c) 1999-2000 CISCO SYSTEMS, INC.. ALL RIGHTS RESERVED. * #--//* THIS SOFTWARE CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF * #--//* CISCO SYSTEMS, INC.. USE, DISCLOSURE, OR REPRODUCTION IS PROHIBITED * #--//* WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF THE CISCO SYSTEMS, INC.. * #--//* * #--//****************************************************************************** # "$Id: Table_9.trigger,v 1.11.2.3 1999/09/20 18:20:51 xxxxxxxx Exp $"; # "(c) 1999-2000 Cisco Systems, Inc.. All Rights Reserved."


############# $TriggerTable ############# # All fields are pointers to records of other types # F1 F2 F3 F4 F5 F6 F7 # MA MS RR1 RR2 RR3 RR4 RR5

#---------------------------------- # TT 1: xxxxxx LNP #---------------------------------- 1 1 1 2 0 0 0

#---------------------------------- # TT 2: Generic LNP #---------------------------------- 2 2 1 3 0 0 0

#---------------------------------- # TT 3: xxxxxxx 800 #---------------------------------- 3 3 10 4 5 0 0

#---------------------------------- # TT 4: ANSI AIN 800 NPA #---------------------------------- 4 4 10 6 7 0 0

#---------------------------------- # TT 5: ANSI AIN 800 NPA-NXX #---------------------------------- 4 5 10 6 7 0 0

#---------------------------------- # TT 6: ANSI AIN 800 NPA-NXX-XXXX #---------------------------------- 4 6 10 6 7 0 0

#---------------------------------- # TT 7: ANSI AIN 800 Termination Information #---------------------------------- 5 7 10 0 0 0 0

#---------------------------------- # TT 8: ANSI PRE AIN AIN 800 #---------------------------------- 4 8 10 8 9 0 0

#---------------------------------- # TT 9: ANSI PRE AIN 800 Termination Information #---------------------------------- 5 9 10 0 0 0 0


############## $MessageAction ############## # # F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 # ACT1 REQ ACT2 REQ ACT3 REQ ACT4 REQ ACT5 REQ

#------------------------------------------------- # MA 1: xxxxxx LNP #------------------------------------------------- 1 1 3 0 0 0 0 0 0 0

#------------------------------------------------- # MA 2: Generic LNP #------------------------------------------------- 1 1 2 1 3 0 0 0 0 0

#------------------------------------------------- # MA 3: xxxxxxx 800 #------------------------------------------------- 1 1 3 0 0 0 0 0 0 0

#------------------------------------------------- # MA 4: ANSI AIN 800 / ANSI PRE AIN 800 #------------------------------------------------- 1 1 3 0 0 0 0 0 0 0

#------------------------------------------------- # MA 5: ANSI AIN 800 Termination Information / PRE AIN 800 Termination Information #------------------------------------------------- 4 1 0 0 0 0 0 0 0 0


############### $MessageSending ############### # # gtFormat Values # GTFORMAT_DO_NOT_USE_GLOBAL_TITLE := 0 # GTFORMAT_USE_GLOBAL_TITLE_TRANSLATION_TYPE_NUMBERING_SCHEME_ENCODING_SCHEME := 1 # GTFORMAT_USE_GLOBAL_TITLE_TRANSLATION_TYPE := 2 # GTFORMAT_USE_GLOBAL_TITLE_ONLY := 3 # GTFORMAT_UNKNOWN := 4 #

Note To see proper formatting for the table below, see Table 7-2.


# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 F17 F18 F19 F20 F21 # transport tcapType stpScpGroupIndex msg asn1Encoding tcv_sk translationType tcapBodyType gtSsn dpcPres ssnPres dpcNetwork dpcCluster dpcMember ssn gtFormat OS1 OS2 OS3 OS4 OS5

#---------------------------------------------------------------------------------------- # MS 1: xxxxxx LNP #---------------------------------------------------------------------------------------- 1 2 0 6 0 0 255 1 0 0 1 0 0 0 0 2 1 0 0 0 0

#---------------------------------------------------------------------------------------- # MS 2: Generic LNP #---------------------------------------------------------------------------------------- 1 2 6 37 255 0 1 0 0 2 0 0 0 0

#---------------------------------------------------------------------------------------- # MS 3: xxxxxxx 800 #---------------------------------------------------------------------------------------- 2 1 1 0 1 0 0 0 2 0 0

#---------------------------------------------------------------------------------------- # MS 4: ANSI AIN 800 NPA #---------------------------------------------------------------------------------------- 1 2 0 6 0 4 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0

#---------------------------------------------------------------------------------------- # MS 5: ANSI AIN 800 NPA-NXX #---------------------------------------------------------------------------------------- 1 2 0 0 255 0 1 0 0 4 0 0

#---------------------------------------------------------------------------------------- # MS 6: ANSI AIN 800 NPA-NXX-XXX #---------------------------------------------------------------------------------------- 1 2 0 6 0 8 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0

#---------------------------------------------------------------------------------------- # MS 7: ANSI AIN 800 Termination information #---------------------------------------------------------------------------------------- 1 2 0 5 0 0 255 1 0 0 1 0 0 0 0 2 5 0 0 0 0

#---------------------------------------------------------------------------------------- # MS 8: ANSI PRE AIN 800 #---------------------------------------------------------------------------------------- 1 3 0 6 0 0 254 2 0 0 1 0 0 0 0 2 6 0 0 0 0

#---------------------------------------------------------------------------------------- # MS 9: ANSI PRE AIN 800 Termination information #---------------------------------------------------------------------------------------- 1 3 0 5 0 0 254 2 0 0 1 0 0 0 0 2 7 0 0 0 0

################ $OperationSending ################# # # F1 F2 F3 F4 F5 # componentType opClass opCodeFamily opCodeSpecifier opCodeFlag # F6 F7 # correlationRequired PS

#---------------------------------------------------------------------------------------- # OS 1: xxxxxx LNP #---------------------------------------------------------------------------------------- 6 1 3 0

#---------------------------------------------------------------------------------------- # OS 2: Generic LNP #---------------------------------------------------------------------------------------- 6 100 4 2

#---------------------------------------------------------------------------------------- # OS 3: xxxxxxx 800 #---------------------------------------------------------------------------------------- 1 0 4 3

#---------------------------------------------------------------------------------------- # OS 4: ANSI AIN 800 #---------------------------------------------------------------------------------------- 6 100 4 0 4

#---------------------------------------------------------------------------------------- # OS 5: ANSI AIN 800 Termination Information Should have correlationRequired = 1 #---------------------------------------------------------------------------------------- 6 1 103 4 4 0 5

#---------------------------------------------------------------------------------------- # OS 6: ANSI PRE AIN 800 #---------------------------------------------------------------------------------------- 6 1 3 1 3 0 6

#---------------------------------------------------------------------------------------- # OS 7: ANSI PRE AIN 800 Termination Information #---------------------------------------------------------------------------------------- 2 1 0 0 0 0 7


################ $ParameterSending ################# # # F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 F17 F18 # PA1 REQ PA2 REQ PA3 REQ PA4 REQ PA5 REQ PA6 REQ PA7 REQ PA8 REQ PA9 REQ # F19 F20 # PA10 REQ

#---------------------------------------------------------------------------------------- # PS 1: xxxxxx LNP #---------------------------------------------------------------------------------------- 100 1 101 1 102 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PS 2: Generic LNP #---------------------------------------------------------------------------------------- 100 1 101 1 102 1 103 1 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PS 3: xxxxxxx 800 #---------------------------------------------------------------------------------------- 200 1 201 1 202 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PS 4: ANSI AIN 800 (All types) #---------------------------------------------------------------------------------------- 100 1 101 1 102 1 103 1 104 1 109 0 110 0 111 0 112 0 113 0

#---------------------------------------------------------------------------------------- # PS 5: ANSI AIN 800 Termination Information #---------------------------------------------------------------------------------------- 105 1 106 1 107 0 108 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PS 6: ANSI PRE AIN 800 #---------------------------------------------------------------------------------------- 17 1 2 1 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PS 7: ANSI PRE AIN 800 Termination Information #---------------------------------------------------------------------------------------- 21 1 20 1 22 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


################# $ReceivedResponse ################# # # F1 F2 # MR RA

#---------------------------------------------------------------------------------------- # RR 1: xxxxxx LNP / Generic LNP Default #---------------------------------------------------------------------------------------- 0 1

#---------------------------------------------------------------------------------------- # RR 2: xxxxxx LNP 1st expected #---------------------------------------------------------------------------------------- 1 2

#---------------------------------------------------------------------------------------- # RR 3: Generic LNP 1st expected #---------------------------------------------------------------------------------------- 1 3

#---------------------------------------------------------------------------------------- # RR 4: xxxxxxx 800 1st expected (Result) #---------------------------------------------------------------------------------------- 2 1

#---------------------------------------------------------------------------------------- # RR 5: xxxxxxx 800 2st expected (Error) #---------------------------------------------------------------------------------------- 3 4

#---------------------------------------------------------------------------------------- # RR 6: ANSI AIN 800 With termination status notification #---------------------------------------------------------------------------------------- 4 5

#---------------------------------------------------------------------------------------- # RR 7: ANSI AIN 800 #---------------------------------------------------------------------------------------- 5 6

#---------------------------------------------------------------------------------------- # RR 8: ANSI PRE AIN 800 With termination status notification #---------------------------------------------------------------------------------------- 6 7

#---------------------------------------------------------------------------------------- # RR 9: ANSI PRE AIN 800 #---------------------------------------------------------------------------------------- 7 8

#---------------------------------------------------------------------------------------- # RR 10: ANSI AIN 800 / PRE AIN 800 Default #---------------------------------------------------------------------------------------- 0 9


################# $MessageReceiving ################# # # F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 # MSG OR1 REQ OR2 REQ OR3 REQ OR4 REQ OR5 REQ

#------------------------------------------------------ # MR 1: xxxxxx LNP / Generic LNP #------------------------------------------------------ 8 1 1 0 0 0 0 0 0 0 0

#------------------------------------------------------ # MR 2: xxxxxxx 800 (Result) #------------------------------------------------------ 3 2 1 0 0 0 0 0 0 0 0

#------------------------------------------------------ # MR 3: xxxxxxx 800 (Error) #------------------------------------------------------ 3 3 1 0 0 0 0 0 0 0 0

#------------------------------------------------------ # MR 4: ANSI AIN 800 with termination status notification #------------------------------------------------------ 8 4 1 5 1 0 0 0 0 0 0

#------------------------------------------------------ # MR 5: ANSI AIN 800 #------------------------------------------------------ 8 4 1 0 0 0 0 0 0 0 0

#------------------------------------------------------ # MR 6: ANSI PRE AIN 800 with termination status notification #------------------------------------------------------ 8 6 1 7 1 0 0 0 0 0 0

#------------------------------------------------------ # MR 7: ANSI PRE AIN 800 #------------------------------------------------------ 8 6 1 0 0 0 0 0 0 0 0


################### $OperationReceiving ################### # # F1 F2 F3 F4 F5 F6 # componentType opClass opCodeFamily opCodeSpecifier opCodeFlag PR

#---------------------------------------------------------------------- # OR 1: xxxxxx LNP / Generic LNP #---------------------------------------------------------------------- 6 1 101 1 4 1

#---------------------------------------------------------------------- # OR 2: xxxxxxx 800 (Result) #---------------------------------------------------------------------- 1 1 0 20 4 2

#---------------------------------------------------------------------- # OR 3: xxxxxxx 800 (Error) #---------------------------------------------------------------------- 3 1 0 0 4 3

#---------------------------------------------------------------------- # OR 4: ANSI AIN 800 #---------------------------------------------------------------------- 6 1 101 1 4 4

#---------------------------------------------------------------------- # OR 5: ANSI AIN 800 Request for status notification #---------------------------------------------------------------------- 6 1 103 5 4 5

#---------------------------------------------------------------------- # OR 6: ANSI PRE AIN 800 #---------------------------------------------------------------------- 6 1 4 1 3 6

#---------------------------------------------------------------------- # OR 7: ANSI PRE AIN 800 Request for status notification #---------------------------------------------------------------------- 6 1 6 1 4 7


################### $ParameterReceiving ###################

# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 # PA1 REQ ACT PA2 REQ ACT PA3 REQ ACT PA4 REQ ACT PA5 REQ ACT PA6   REQ  F17 F18 F19 F20 F21 F22 F23 F24 F25 F26 F27 F28 F29 F30   ACT PA7 REQ ACT PA8 REQ ACT PA9 REQ ACT PA10 REQ ACT

#---------------------------------------------------------------------------------------- # PR 1: xxxxxx LNP / Generic LNP #---------------------------------------------------------------------------------------- 102 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PR 2: xxxxxxx 800 (Result) #---------------------------------------------------------------------------------------- 205 1 1 206 1 1 204 1 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PR 3: xxxxxxx 800 (Error) #---------------------------------------------------------------------------------------- 205 1 1 206 1 1 204 1 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PR 4: ANSI AIN 800 Result #---------------------------------------------------------------------------------------- 102 1 1 110 0 2 113 0 2 114 1 2 115 1 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PR 5: ANSI AIN 800 Status request #----------------------------------------------------------------------------------------- ------------------------------------------------------------ 105 1 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#----------------------------------------------------------------------------------------- ------------------------------------------------------------ # PR 6: ANSI PRE AIN 800 Result #----------------------------------------------------------------------------------------- ------------------------------------------------------------ 8 0 2 4 1 1 18 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#---------------------------------------------------------------------------------------- # PR 7: ANSI PRE AIN 800 Status request #---------------------------------------------------------------------------------------- 20 1 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


############### $ResponseAction ############### # # F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 # ACT1 REQ DAT ACT2 REQ DAT ACT3 REQ DAT ACT4 REQ DAT ACT5 REQ DAT

#-------------------------------------------------------------------------- # RA 1: xxxxxx LNP Default & Generic LNP Default #-------------------------------------------------------------------------- 4 1 2 0 0 0 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 2: xxxxxx LNP 1st Expected #-------------------------------------------------------------------------- 4 1 2 0 0 0 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 3: Generic LNP 1st Expected #-------------------------------------------------------------------------- 1 1 0 4 1 2 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 4: xxxxxxx (Error) #-------------------------------------------------------------------------- 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 5: ANSI AIN 800 with termination status notification #-------------------------------------------------------------------------- 2 0 1 4 1 3 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 6: ANSI AIN AIN 800 #-------------------------------------------------------------------------- 4 1 3 0 0 0 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 7: ANSI PRE AIN 800 with termination status notification #-------------------------------------------------------------------------- 2 0 4 4 1 3 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 8: ANSI PRE AIN 800 #-------------------------------------------------------------------------- 4 1 3 0 0 0 0 0 0 0 0 0 0 0 0

#-------------------------------------------------------------------------- # RA 9: 800 Default #-------------------------------------------------------------------------- 4 1 3 0 0 0 0 0 0 0 0 0 0 0 0

########### $ActionData ########### # # F1 F2 F3 F4 F5 #-----------------------

# AD 1: ANSI AIN 800 Data for RESULT_ACTION_RE_TRIGGER_VIA_LCM (to send termination information) # Trg Pic Null Null Null #-------------------------- 7 13 0 0 0

# AD 2: ANSI LNP Data for RESULT_ACTION_SEND_ACTION_TO_LCM # Act Null Null Null NULL #-------------------------- 1 0 0 0 0

# AD 3: ANSI AIN / PRE AIN 800 Data for RESULT_ACTION_SEND_ACTION_TO_LCM # Act Null Null Null NULL #-------------------------- 2 0 0 0 0

# AD 4: ANSI PRE AIN 800 Data for RESULT_ACTION_RE_TRIGGER_VIA_LCM (to send termination information) # Trg Pic Null Null Null #-------------------------- 9 13 0 0 0


This completes the SCP configuration. Continue to the next section to initialize the call-screening database. If you have questions or need assistance, see the "Obtaining Technical Assistance" section on page xviii.

Initializing the Call Screening Database

During installation, the installation script (install.sh) installs and initializes a database that the SC host can use to store call screening information for number analysis.

You might want to perform white and black list screening to include or exclude calls from certain numbers. You can provision white lists that specify allowed A-numbers (calling numbers) or B-numbers (called numbers). Black lists block specified A-numbers (calling numbers) or B-numbers (called numbers).

The call screening database is stored in the /opt/TimesTen32/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.

This section contains the following topics:

.odbc.ini File Information

Setting Up Replication

Troubleshooting


Note You cannot change the database name.


.odbc.ini File Information

The .odbc.ini file specifies the location of the database storage, and it is located in the /opt/CiscoMGC/local directory.

Following is an example of an .odbc.ini file.

[ODBC Data Sources] howdydb=TimesTen 3.2 Driver

[howdydb] Driver=/opt/TimesTen32/32/lib/libtten.so DataStore= /opt/TimesTen32/datastore/howdydb DurableCommits=0 ExclAccess=0 ThreadSafe=1 WaitForConnect=0 Size=256

[ODBC] Trace=0 TraceFile= Installdir=/opt/TimesTen32/32

Setting Up Replication

If you have two telephony controller hosts in a continuous-service or high-availability system, you must set up database replication between the two hosts. During replication, any updates applied to the database on one host are replicated in the database on the other. Data is transferred real time and does not require the committing or deploying of a configuration.

Replication copies data changes to either database after the initial setup. However, if you have data on one host, and you want the same data on another host, you must back up and move the data over, in addition to configuring replication.

If this is the initial installation of the software, and you do not have any data in the database, perform the following steps. If you do have data in one database and want to copy it to the other host, proceed to the "Initializing Replication and Copying the Database to Another Host" section.


Note Before you can initialize the databases, you must install the SC software on both machines.


If you have data in both databases, and the databases do not match, contact the TAC for assistance in merging the databases.

Initializing Database Replication

To set up the initial replication, perform the following steps:


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

setup_replication.sh standbyhost howdydb

Where standbyhost is the name (not IP address) of your standby host. In Example 7-1, 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 fails.

Example 7-1 Initializing Database Replication on the Active Host

hostx% setup_replication.sh hosty howdydb

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

setup_replication.sh activehost howdydb

Where activehost is the name (not IP address) of your active host. In the Example 7-2, 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 fails.

Example 7-2 Initializing Database Replication on the Standby Host

hosty% setup_replication.sh hostx howdydb

Setting up replication to node hostx 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


Proceed to the "Verifying Database Replication" section.

Initializing Replication and Copying the Database to Another Host

If you have existing data in one database and want to copy the data to another machine—for example, from the active to standby machine—perform the following steps:


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

setup_replication.sh standbyhost howdydb

Where standbyhost is the name (not IP address) of your standby host. In Example 7-3, 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 fails.

Example 7-3 Initializing Database Replication on the Active Host

hostx% setup_replication.sh hosty howdydb

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 Create a directory for the database backup files using the mkdir command. For example:

mkdir /backupdb

Step 3 Create the backup files by entering the following command:

ttRepAdmin -dsn howdydb -receiver -name standbyhost -backup dirname

Where standbyhost is the name (not IP address) of the standby host and dirname is the name of the directory you created in Step 2.

For example:

ttRepAdmin -dsn howdydb -receiver -name hosty -backup backupdb

Step 4 Transfer the backup files from the active host to the standby host (for example, use FTP to transfer the directory).

Step 5 Log in to the standby host as the root user and destroy the database that has been created during the initial setup of replication. Enter the following command:

ttDestroy /opt/TimesTen32/datastore/howdydb

Step 6 Restore using the backed-up files from the active host that you transferred. Enter the following command:

ttRestore -fname replica -dir dirname DSN=howdydb

where dirname is the name of the directory you created. For example:

ttRestore -fname replica -dir backupdb DSN=howdydb The restore process is being initiated Restore complete

Step 7 To set up replication of the standby host, enter the following commands:

ttRepAdmin -dsn howdydb -self -restored dirname ttRepAdmin -dsn howdydb -self -swap standbyhost

For example:

hosty% ttRepAdmin -dsn howdydb -self -restored backupdb hosty% ttRepAdmin -dsn howdydb -self -swap hosty Self swap with peer hosty successful

Step 8 Enter the following commands to complete the restoration:

ttRepAdmin -dsn howdydb -table cisco.whitelist_a -sendto activehost ttRepAdmin -dsn howdydb -table cisco.whitelist_b -sendto activehost ttRepAdmin -dsn howdydb -table cisco.blacklist_b -sendto activehost ttRepAdmin -dsn howdydb -table cisco.blacklist_a -sendto activehost ttAdmin -repPolicy manual howdydb ttAdmin -repStart howdydb

For example:

hosty% ttRepAdmin -dsn howdydb -table cisco.whitelist_a -sendto hostx hosty% ttRepAdmin -dsn howdydb -table cisco.whitelist_b -sendto hostx hosty% ttRepAdmin -dsn howdydb -table cisco.blacklist_b -sendto hostx hosty% ttRepAdmin -dsn howdydb -table cisco.blacklist_a -sendto hostx hosty% ttAdmin -repPolicy manual howdydb 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 : False hosty% ttAdmin -repStart howdydb 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 9 Verify the database replication is working. See the "Verifying Database Replication" section.


Verifying Database Replication

To verify that replication is working, perform the following steps:


Step 1 Log in to the active host and start an MML session by entering mml.

Step 2 Enter the prov-sta MML command to begin a provisioning session. For example:

hostx mml> prov-sta::srcver="new",dstver="test",confirm VSC-01 - Media Gateway Controller 2000-08-30 11:31:15 M COMPLD "PROV-STA" ;

Step 3 Add an entry into the B white list database using the numan-add MML command. For example:

hostx mml> numan-add:bwhite:custgrpid="S018",svcname="testsvc",cli="9998" VSC-01 - Media Gateway Controller 2000-08-30 11:31:25 M COMPLD "bwhite" ;

Step 4 Enter the prov-stp MML command to end the provisioning session.

Step 5 Log in to the standby host and start an MML session by entering mml.

Step 6 Enter the prov-sta MML command to begin a provisioning session. For example:

hosty mml> prov-sta::srcver="new",dstver="test",confirm

Step 7 Enter the numan-rtrv MML command to verify that the entry you added in Step 3 was replicated to the database on the standby host. For example:

hosty mml> numan-rtrv:bwhite:custgrpid="S018",svcname="testsvc",cli="9998" VSC-01 - Media Gateway Controller 2000-08-30 11:33:52 M RTRV "session=test:bwhite" /* The cli :9998: exists. */ ;

Step 8 Enter the prov-stp MML command to end the provisioning session.


Troubleshooting

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


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/TimesTen32 directory.

Step 2 Check the log file for installation errors. (The log file is in the directory /opt/TimesTen32/datastore.)


If you find installation errors in the log file, remove and reinstall the CSCOga002 package, as follows:


Step 1 Remove the CSCOga002 package using the pkgrm command. To remove the package file, type the following command and press Enter:

# pkgrm CSCOga002

Step 2 Reinstall the package using the pkgadd command by typing the following command and pressing Enter:

# pkgadd -d CSCOga002.pkg


If you have questions or need assistance, see the "Obtaining Technical Assistance" section on page xviii.

Restarting the SC Software

After configuring the SC software, you must stop and start the SC software.


Tip If you installed ITK or PTI drivers, the system rebooted and the SC software will be running. If you did not install the drivers, your SC software has not yet been started.


To stop the SC software:


Step 1 As the root user, enter the /etc/init.d/transpath stop command.

Step 2 Enter ps -ef | grep procM to ensure the software is not running. If you receive no response, the software is stopped.



Note For Software Release 7.4(x), enter /etc/init.d/CiscoMGC stop to stop the software.


To start the SC software:


Step 1 As the root user, enter the /etc/init.d/transpath start command.

Step 2 Enter ps -ef | grep procM to ensure the software is running.



Note For Software Release 7.4(x), enter the /etc/init.d/CiscoMGC start command.


Terminating Signaling Links

The SS7 signaling links connect the SC host running Cisco SC software to an SS7 switch. These SS7 signaling links are connected to the Cisco SLT, which connects to the SC host over IP.

If you are upgrading a standalone machine, you can remove the links from your machine and connect them to the Cisco SLTs now.

If you have a high-availability or continuous service configuration, perform these steps:


Step 1 Log in as root to the second SC host that is currently processing calls.

Step 2 Enter the /etc/init.d/CiscoMGC stop command to shut down the software. Leave the SC software on the newly upgraded host running.



Caution When you remove the signaling links from the host and terminate them into the Cisco SLT, the host will stop processing calls. Your host will be down until you start the software on the newly upgraded host. You should plan to connect the signaling links during a maintenance window or a low traffic period to minimize call attempt losses.

Note You should coordinate with your SS7 link service provider to let them know that your links will go out of service. Your provider should have on-site support staff available to assist you should there be problems reestablishing the links.


The Cisco SLT requires the Cisco 2611 modular access router with T1 or E1 interfaces running a special release of Cisco IOS software. The Cisco SLT has the following restrictions:

Only the following Interface Cards are supported. No other cards, or Cisco 2600 or Cisco 3600 series network modules, are supported:

1-port T1 multiflex trunk interface (VWIC-1MFT-T1)

1-port E1 multiflex trunk interface (VWIC-1MFT-E1)

2-port T1 multiflex trunk interface (VWIC-2MFT-T1)

2-port E1 multiflex trunk interface (VWIC-2MFT-E1)

2-port T1 multiflex trunk interface with Drop and Insert (VWIC-2MFT-T1-DI)

2-port E1 multiflex trunk interface with Drop and Insert (VWIC-2MFT-E1-DI)

1-port high-speed serial interface (WIC-1T)

2-port high-speed serial interface (WIC-2T)

Only SS7 serial interfaces and protocols are supported. There is no support for HDLC, PPP, Frame Relay, ATM, X.25, or other non-SS7 serial WAN protocols.

Only two SS7 signaling links are supported per Cisco SLT.

Only one SS7 signaling link is supported per T1 or E1 port.

Moving the Signaling Links in a Standalone Configuration

To move the signaling links, follow these steps:


Step 1 Verify that the Cisco SLT has the WIC that matches your signaling links (either E1 or T1).

Step 2 Connect the Cisco SLT to the Ethernet interface. How you connect to the Cisco SLT will depend on how many SS7 signaling links you have.

If you have one SS7 signaling link, unplug the SS7 signaling link from the ITK card on the SC host and plug it into the WIC on the Cisco SLT.

If you have two SS7 signaling links, follow these steps:

a. Connect Cisco SLT-1 to Ethernet segment 1.

b. Connect Cisco SLT-2 to Ethernet segment 2.

c. Unplug SS7 signaling link #1 from the ITK card on the SC host, and plug it into the WIC on Cisco SLT-1.

d. Unplug SS7 signaling link #2 from the ITK card on the SC host, and plug it into the WIC on Cisco SLT-2.

Step 3 After plugging the links into the Cisco SLT, the carrier detect (CD) light on the back of the Cisco SLT should be green.

Step 4 Stop and start the SC software as described in the "Restarting the SC Software" section.

Step 5 Log in to the SC host, start an MML session, and set the signaling links into service by entering the following MML command:

set-sc-state:linkname:IS

Where linkname is the name you provisioned in the "Terminating Signaling Links" section.

If the signaling links cannot go in-service, back out the new SC software installation using the procedures in the "Migrating Inactive SC Host Configurations" section.


Moving the Signaling Links in a Continuous-Service Configuration

To move the signaling links, follow these steps:


Step 1 Verify that the Cisco SLT has the WIC that matches your signaling links (either E1 or T1).

Step 2 Connect the Cisco SLT to the Ethernet interface. How you connect to the Cisco SLT will depend on how many SS7 signaling links you have.

If you have one SS7 signaling link, unplug the SS7 signaling link from the ITK card on the SC host and plug it into the WIC on the Cisco SLT.

If you have two SS7 signaling links, follow these steps:

a. Connect Cisco SLT-1 to Ethernet segment 1.

b. Connect Cisco SLT-2 to Ethernet segment 2.

c. Unplug SS7 signaling link #1 from the ITK card on the SC host, and plug it into the WIC on Cisco SLT-1.

d. Unplug SS7 signaling link #2 from the ITK card on the SC host, and plug it into the WIC on Cisco SLT-2.


Tip If you have more than 1 link in a linkset, only move 1 link at first to test the functionality. If that link comes up, you can move the other links. If the test link does not come up, move it back to the machine that has not been upgraded and restart the SC software on that machine.


Step 3 After plugging the links into the Cisco SLT, the carrier detect (CD) light on the back of the Cisco SLT should be green.

Step 4 Stop and start the SC software as described in the "Restarting the SC Software" section.

Step 5 Log in to the SC host, start an MML session, and set the signaling links into service by entering the following MML command:

set-sc-state:linkname:IS

Where linkname is the name you provisioned in the "Terminating Signaling Links" section.

If the signaling links cannot go in-service, back out the new SC software installation using the procedures in the "Migrating Inactive SC Host Configurations" section.


Verifying SC Software is Running Properly

To verify that the SC software is running properly you should perform the tests described in the following sections:

Perform a Test Call and Switchover

Verifying the Platform State of the SC Hosts

Verifying the Status of all Signaling Channels

Verifying the Status of all Traffic Channels

Verifying the Status of all Destinations

Checking for Active Alarms

Verifying Proper Migration of Data

Perform a Test Call and Switchover

Perform the following procedure to test the ability of the software installed on the upgraded SC host to handle a switchover operation:


Note This procedure does not have to be performed on systems with a standalone SC host.



Step 1 Place a test call on your system and hold the call

Step 2 Log in to the other SC host, open an MML session, and enter the following command to perform a manual switchover:

sw-over::confirm

If the call is sustained, the procedure is complete. Otherwise, proceed to Step 3.

Step 3 Back out the installation of the new SC software, as described in the "Backout Procedures" section.


Verifying the Platform State of the SC Hosts

Ensure that the recently upgraded SC hosts is in the active platform state and that the other SC host is in the standby platform state. If your system uses an SC host in a simplex configuration, the single SC host is always active. To do this, complete the following steps:


Step 1 Log into the upgraded SC host, 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 SC host:

   Media Gateway Controller 2001-10-10 14:15:22 M RTRV "Type:SC" "Hardware platform:sun4u sparc SUNW,Ultra-5_10" "Vendor:"Cisco Systems, Inc."" "Location:Signaling Controller" "Version:"7.4(12)"" "Platform State:ACTIVE"

The valid values for the Platform State field are ACTIVE, STANDBY, or OOS.

Step 2 Log into the other SC host, 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 the standby platform state.

If the platform state of either SC host is not correct, check for alarms as described in the "Checking for Active Alarms" section, and take the actions necessary to correct the condition that caused the associated alarm(s).

If the platform state of both SC hosts is active, proceed to Step 3.

Step 3 Contact the Cisco Technical Assistance Center (TAC) for assistance. Refer to the "Obtaining Technical Assistance" section on page xviii for more information on contacting the Cisco TAC.


Verifying the Status of all Signaling Channels

To verify the status of all of the signaling channels and linksets, enter the following command at the active SC host:

rtrv-sc:all

The system returns a response similar to the following, which shows the signaling links to and from the SC hosts and the associated media gateways.

   Media Gateway Controller 2000-03-26 19:23:23 M RTRV "iplink1:nassvc1,LID=0:IS" /* IP Link 1 for NAS 1 */ "iplink2:nassvc2,LID=0:IS" /* IP Link 1 for NAS 2 */ "iplink3:nassvc3,LID=0:IS" /* IP Link 1 for NAS 3 */ "iplink4:nassvc1,LID=0:IS" /* IP Link 2 for NAS 1 */ "iplink5:nassvc2,LID=0:IS" /* IP Link 2 for NAS 2 */ "iplink6:nassvc3,LID=0:IS" /* IP Link 2 for NAS 3 */ "c7iplink1:ls01,LID=0:IS"  /* Link 1 in Linkset 1 */ "c7iplink2:ls01,LID=1:IS"  /* Link 2 in Linkset 1 */ "c7iplink3:ls02,LID=0:IS"  /* Link 1 in Linkset 2 */ "c7iplink4:ls02,LID=1:IS"  /* Link 2 in Linkset 2 */

If any of the signaling channels are not in-service, check for alarms as described in the "Checking for Active Alarms" section, and take the actions necessary to correct the condition that caused the associated alarm(s).

Verifying the Status of all Traffic Channels

To verify the status of all of the traffic channels, enter the following command at the active SC host:

rtrv-tc:all

The system returns a response similar to the following:

   Media Gateway Controller - MGC-01 2000-04-05 08:26:36 M RTRV "dpc1:CIC=1,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=2,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=3,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=4,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=5,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=6,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=7,PST=IS,CALL=IDLE,BLK=NONE"    "dpc1:CIC=8,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=9,PST=IS,CALL=IDLE,BLK=NONE"

If any of the traffic channels are not in-service, check for alarms as described in the "Checking for Active Alarms" section, and take the actions necessary to correct the condition that caused the associated alarm(s).

Verifying the Status of all Destinations

To verify the status of all of the destination point codes (DPCs) provisioned on your SC host, enter the following command at the active SC host:

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 "dpc1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND" "dpc2:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND" "dpc3:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND" "dpc4:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND" "dpc5:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND" "dpc6:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=UND"


Note If the rtrv-dest:all MML command is entered soon after a switchover has occurred, the state of some of the destinations might be listed as undefined (UND). UND is the default state for a destination when the system starts. In this instance, UND states indicate that the SC host has not received a service state message from the associated destination since the switchover occurred. No user action is required.


If any of the DPCs are not in-service, check for alarms as described in the "Checking for Active Alarms" section, and take the actions necessary to correct the condition that caused the associated alarm(s).

Checking for Active Alarms

To retrieve all active alarms, enter the following command at the active SC host:

rtrv-alms

The system returns a response that shows all active alarms, in a format similar to the following:

Media Gateway Controller 2000-02-26 11:41:01 M RTRV "LPC-01: 2000-02-26 09:16:07.806," "LPC-01:ALM=\"SCMGC MTP3 COMM FAIL\",SEV=MJ" "IOCM-01: 2000-02-26 09:17:00.690," "IOCM-01:ALM=\"Config Fail\",SEV=MN" "MGC1alink2: 2000-02-26 09:17:47.224,ALM=\"SC FAIL\",SEV=MJ" "MGC1alink3: 2000-02-26 09:17:47.225,ALM=\"SC FAIL\",SEV=MJ" "MGC1alink4: 2000-02-26 09:17:47.226,ALM=\"SC FAIL\",SEV=MJ" "MGC2alink1: 2000-02-26 09:17:47.227,ALM=\"SC FAIL\",SEV=MJ" "MGC2alink2: 2000-02-26 09:17:47.227,ALM=\"SC FAIL\",SEV=MJ" "MGC2alink4: 2000-02-26 09:17:47.229,ALM=\"SC FAIL\",SEV=MJ" "dpc5: 2000-02-26 09:17:47.271,ALM=\"PC UNAVAIL\",SEV=MJ" "ls3link1: 2000-02-26 09:16:28.174," "ls3link1:ALM=\"Config Fail\",SEV=MN" "ls3link1: 2000-02-26 09:18:59.844,ALM=\"SC FAIL\",SEV=MJ"

If any alarms are present, determine whether you need to take corrective action to resolve the alarm condition. The alarms that require corrective action are listed in the Alarm Troubleshooting Procedures section of the Cisco MGC Node Troubleshooting chapter in the Cisco Media Gateway Controller Software Release 7 Operations, Maintenance, and Troubleshooting Guide. Information on all alarms can be found in the Cisco Media Gateway Controller Software Release 7 Messages Reference Guide.

Verifying Proper Migration of Data

Verify that the contents of the XECfgParm.dat file and the active configuration file have successfully migrated by performing the following steps:


Step 1 Verify the contents of the XECfpParm.dat file in the upgraded SC host, using the procedure in the Opening the XECfgParm.dat File, ensuring that the parameter settings from your previous release of the SC software have migrated properly (migrated properties are indicated by the comment "migrated" after the parameter).

If the parameter settings have not migrated properly, correct the value of the parameters and save the file, as described in the "Saving the XECfgParm.dat File" section. Otherwise, proceed to Step 2.


Note For more information on the settings for the XECfgParm.dat parameters, refer to the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.


Step 2 Enter the following UNIX commands to launch the Cisco MGC toolbar:

cd /opt/CMM/bin

./start.sh tool

The MGC Toolbar window is displayed.

Step 3 Click CONFIG-LIB on the Cisco MGC toolbar to open the Config-Lib viewer window.

Step 4 Enter 1 at the prompt to list the configuration versions in the library.

If the configuration identified in the Config-Lib viewer window as the current production version matches the name of your active configuration, the procedure is complete.

If the configuration identified in the Config-Lib viewer window as the current production version does not match the name of your active configuration, proceed to Step 5.

Step 5 Check the list of configurations in the Config-Lib viewer window to determine whether the name of your active configuration is listed.

If your active configuration is not listed in the Config-Lib viewer window, proceed to Step 6.

If your active configuration is listed in the Config-Lib viewer window, proceed to Step 8.

Step 6 Manually migrate the old SC host configurations using the procedure described in the "Migrating Inactive SC Host Configurations" section.

Step 7 Exit and re-open the Config-Lib viewer window to load the retrieved configurations into the viewer window.

Step 8 Stop the SC software using the following UNIX command:

etc/init.d/CiscoMGC stop

Step 9 Once the SC software has stopped completely, return to the Config-Lib viewer window and enter 3 at the prompt and enter the number of the library version to be set as the active configuration.

Step 10 Restart the SC software using the following UNIX command:

etc/init.d/CiscoMGC start

Step 11 Exit and re-open the Config-Lib viewer window. Ensure that the active configuration is now correct. If the active configuration is still not correct, proceed to Step 12. Otherwise, the procedure is complete.

Step 12 Contact the Cisco TAC for assistance. Refer to the "Obtaining Technical Assistance" section on page xviii for more information on contacting the Cisco TAC.


Migrating Inactive SC Host Configurations

When installing the SC software, only the active configuration files (located in /opt/CiscoMGC/etc) are migrated. You can use the migrate script to migrate old configurations to a new version. To use the migrate script:


Step 1 Log in to the SC host.

Step 2 Enter the following command:

migrate top-leveldirectory sourcedirectory destinationdirectory

Top-leveldirectory is the software directory. For Software Release 7.3(x), it is /opt/TransPath; for Software Release 7.4(x), it is /opt/CiscoMGC. Sourcedirectory is the relative path of the directory that you want to migrate. Destinationdirectory is the relative path of the directory into which the migrated files are copied. If the directory does not exist, the migrate script creates it. If the directory exists, you are prompted to overwrite it.


Backout Procedures

If the SC software upgrade did not work properly, perform the following steps:


Step 1 If you are upgrading a Cisco SS7 DAS Release 2.0 system in a high-availability configuration, remove the signaling links from the Cisco SLTs. Terminate them back into the ITK cards in your standby SC host (that has not been upgraded).

Step 2 Log in as root to the standby SC host and restart the software by entering /etc/init.d/transpath start.


Note Enter /etc/init.d/CiscoMGC start on an SC host running Release 7.4(x).


Step 3 In a simplex configuration, perform the following steps:

a. Uninstall the new SC software.

b. If you are upgrading a Cisco SS7 DAS Release 2.0 system, uninstall the Solaris 2.6 software and then reinstall Solaris 2.5.

c. Reinstall the previous version of SC software.

d. Restore your backed up files, as described in the "Restoring Your SC Host Data" section.

e. If you are upgrading a Cisco SS7 DAS Release 2.0 system, remove the signaling links from the Cisco SLTs and terminate them into the SC host.


Restoring Your SC Host Data

Use the procedures in these sections to restore the SC data you previously backed up. If you backed up your data to tape, see the "Restoring Your Data from a Local Tape Drive" section. If you backed up your data to a remote machine using the IP network, see the "Restoring Your Data from a Remote Machine" section.

Restoring Your Data from a Local Tape Drive

This procedure restores everything on a tape installed in the local tape drive to the SC software base directory. This procedure assumes the operating system has just been installed and no SC software has been loaded. This procedure returns the etc and dialPlan subdirectories from a tape in the local tape drive to the /opt/TransPath directory. When the new SC software is later installed, it detects these files and uses them to migrate to the new configuration.


Step 1 Log in to the system as root and enter the following UNIX command at the affected Cisco MGC to run the restore script:

# ./restore.sh

The system returns a response similar to the following:

MGC restore utility ----------------------------- Source currently set to Local tape (/dev/rmt/0h) Enter: <N> set source to remote NFS server <L> set source to Local tape (/dev/rmt/0h) <R> for Restore <Q> to quit Select restore mode:

Step 2 Select R and press Enter to start the restore. The system then prompts you as listed below:

Are you sure you want to restore a backup. Current data in the MGC directory will be overwritten and lost.

Answer(Y/N):

Step 3 Select y and press Enter if you are sure you want to restore from the tape. The system begins the restoration and returns a response similar to the following:

Answer(Y/N): y x ., 0 bytes, 0 tape blocks x ./var, 0 bytes, 0 tape blocks x ./var/log, 0 bytes, 0 tape blocks x ./var/log/platform.log, 117 bytes, 1 tape blocks x ./var/log/mml.log, 187 bytes, 1 tape blocks. . . . #

Step 4 When the restore has finished, remove the tape from the tape drive.

Step 5 If your system does not have a dial plan configured, the procedure is complete. Otherwise, restore the contents of your dial plan as described in the "Restoring Data to the Main Memory Database" section.


This completes restoring your SC host data from a local tape drive.

Restoring Your Data from a Remote Machine

This procedure restore files from the etc and dialPlan subdirectories to the /opt/CiscoMGC directory from a file on an NFS mountable directory on remote machine. The remote machine must be set up with an NFS mountable directory that is writable by machine being backed up. The NFS set up of the remote machine is beyond the scope of this procedure. When the new SC software is later installed, it detects these files and uses them to migrate to the new configuration.


Step 1 Log in to the system as root and enter the following UNIX command on the affected Cisco MGC to run the restore script:

# ./restore.sh

The system returns a response similar to the following:

MGC restore utility ----------------------------- Source currently set to Local tape (/dev/rmt/0h) Enter: <N> set source to remote NFS server <L> set source to Local tape (/dev/rmt/0h) <R> for Restore <Q> to quit Select restore mode:

Step 2 Select N and press Enter to define the remote NFS server. The system then prompts you to provide the name of the remote server.

Step 3 Enter the name of the remote NFS server:

Enter server name: remote_hostname

Where: remote_hostname—Name of the remote server where the backups are stored.

The system then prompts you to enter the name of the associated directory on the remote server.

Step 4 Enter the directory name on the remote NFS server:

Enter remote directory : remote_directory_name

Where: remote_directory_name—Name of the directory path on the remote server where the backups are stored.

The system returns a response similar to the following:

Enter server name: va-panthers Enter remote directory : /backup

MGC restore utility -----------------------------

Source currently set to remote NFS server (va-panthers:/backup) Enter:

<N> set source to remote NFS server <L> set source to Local tape (/dev/rmt/0h) <R> for Restore <Q> to quit

The system then prompts you to select the restore mode.

Select restore mode:

Step 5 Select R and press Enter to start the restore. The system returns a response similar to the following:

mount -F nfs -o retry=3 va-panthers:/backup /mnt

Available files: va-blade20000317105201P.tar va-blade20000317105337.tar

The system then prompts you to enter the filename to be restored.

Enter filename to restore from:

Step 6 Enter the filename for the most recent full backup performed on your system.


Note Full backups have a file name consisting of the name of the host and the timestamp with a .tar designation. Partial backups have a file name consisting of the name of the host, timestamp, and the letter "P" with a .tar designation.


The system then asks you if you really want to restore a backup:

Are you sure you want to restore a backup. Current data in the MGC directory will be overwritten and lost.

Answer(Y/N):

Step 7 Enter y and press Enter if you are sure that you want to restore the Cisco MGC directory. The system returns a response similar to the following:

x etc, 0 bytes, 0 tape blocks x etc/Copyright, 545 bytes, 2 tape blocks x etc/CONFIG_LIB, 0 bytes, 0 tape blocks x etc/CONFIG_LIB/new, 0 bytes, 0 tape blocks . . restore from va-panthers:/backup/va-blade20000317105337.tar complete #

Step 8 If your system does not have a dial plan configured, the procedure is complete. Otherwise, restore the contents of your dial plan as described in the "Restoring Data to the Main Memory Database" section.


Restoring Data to the Main Memory Database

Use this procedure to restore your dial plan data.


Step 1 Change directories to a local subdirectory under the base directory.

For example, enter the following UNIX command to change to the /opt/CiscoMGC/local directory:

cd /opt/CiscoMGC/local

Step 2 Run the MMDB restore script by entering the following UNIX command:

./restoreDb.sh filename

Where filename is the name of the database backup file.

For example, to restore the contents of a file called dplan to the MMDB, you would enter the following command:

./restoreDb.sh dplan

The system returns a response similar to the following:

Restoring database contents for DSN=howdydb into dplan The Restore process is being initiated for the datastore howdydb Files for /opt/TimesTen32/datastore/howdydb are being restored up onto standard output Restore Complete


Resetting the Configuration

Once the upgrade is complete on the second SC host, you must return to the first SC host you upgraded and reset its configuration to enable it to synchronize with the second SC host. To do this, perform the following steps:


Step 1 Open the XECfgParm.dat file on the first SC host, as described in the "Opening the XECfgParm.dat File" section, and change the value of pom.dataSync to true.

Step 2 Save your changes and exit the file.

Step 3 Stop the SC software using the following UNIX command:

etc/init.d/CiscoMGC stop

Step 4 Once the SC software has stopped completely, restart the SC software using the following UNIX command:

etc/init.d/CiscoMGC start


Provisioning the Configuration


Note If you are upgrading from the Cisco SS7 DAS Release 2.0, you should provision your configuration again. Although provisioning data is migrated from Software Release 4 to Software Release 7.x, it is likely that your old configuration will not work with the new software. You must provision your configuration again and commit or deploy it to the active SC host.


After installing the new software on the SC host, you may need to add provisioning information to your configuration using MML or your GUI provisioning tool. If you added Cisco SLTs, you must provision these into the configuration. You should have the names of the components in your solution available. For more information, see the "Gathering Provisioning Data" section on page 1-4.

For an overview of provisioning and instructions to assist you, see Cisco Media Gateway Controller Software Release 7 Provisioning Guide. For instructions on provisioning a sample Cisco SS7 Interconnect for Access Servers Solution, see the appropriate provisioning guide for your solution.


Timesaver To save time, you can use an MML batch file to provision your system. This requires that you enter all MML commands to provision your system into an ASCII text file and import the file. See the see the appropriate provisioning guide for your solution for more information and a sample batch file.



Tip The SC software must be running in order to provision the system. If you encounter problems, make sure the software is running. Refer to the "Restarting the SC Software" section.



hometocprevnextglossaryfeedbacksearchhelp

Posted: Wed Oct 20 13:28:20 PDT 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.