|
Table Of Contents
Supported Standards, MIBs, and RFCs
Record Type Message Sending (MS) Table
Initializing the Call Screening Database
Simple INAP
Document Release History
Feature History
Release ModificationInitial release
This feature was introduced on the PGW 2200 (MGC) in software Release 9.4(1).
The Simple INAP Feature is described in the following sections.
• Supported Standards, MIBs, and RFCs
• Glossary
Feature Overview
Simple INAP is required to support functionality within MML that allows for the simple provisioning of some of the message sending parameters within the trigger.dat table that mainly affect Signaling Connection Control Part (SCCP).
The Service Key value is not standard in EMEA and depends on the SCP and the defined services.
For EMEA, the SCCP default values for routing for should be set to be SSN and not set to Global Title.
Benefits
Customizing the trigger.dat Entries
The generic customizable trigger.dat entry is added with a simple EMEA format for sending and receiving. For example, for a generic translation type service that is similar to TT17.
Configuring Fields within the Message Sending Table
This feature allows the user to configure the parameters F6 Service Key or Trigger Criteria value, F9 gtSSN, and F16 gtFormat within the Message Sending (MS) table data in the additional IN Service table in the trigger.dat file.
Removed Unused Fields from the Message Sending.dat File
Table 1 lists the previous Message Sending.dat fields, the fields that have migrated to the STP.dat file, and the fields that exist in the current Message Sending.dat file.
Restrictions
Support for Field 15 SSN is now moved to the STP.dat file, which is currently configurable. If Field 11 SSNPRES is enabled, data from Field 15 is migrated to the STP.dat file.
Caution Improperly editing the trigger.dat file can cause service interruption and prevent the Cisco MGC from correctly performing SCP database queries.
Related Documents
This document contains information that is related strictly to the <feature> Feature. The documents that contain additional information related to the Cisco Media Gateway Controller (MGC) are listed below:
•Release notes for Cisco Media Gateway Controller Software Release 9.4(1)
•Cisco Media Gateway Controller Hardware Installation Guide
•Regulatory Compliance and Safety Information for the Cisco Media Gateway Controller
•Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide
•Cisco Media Gateway Controller Software Release 9 Provisioning Guide
•Cisco Media Gateway Controller Software Release 9 Dial Plan Guide
•Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide
•Cisco Media Gateway Controller Software Release 9 Messages Reference Guide
•Cisco Media Gateway Controller Software Release 9 Billing Interface Guide
•Cisco Media Gateway Controller Software Release 9 MIB Guide
•Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide
Supported Platforms
The hardware platforms supported for the Cisco MGC software are described in the Release Notes for Cisco Media Gateway Controller Software Release 9.4(1).
Supported Standards, MIBs, and RFCs
Standards
No new or modified standards are supported by this feature.MIBs
No new or modified MIBs are supported by this feature.For more information on the MIBs used in the Cisco MGC software, refer to the Cisco Media Gateway Controller Release 9 MIB Guide.
RFCs
No new or modified RFCs are supported by this feature.Reference Information
The following sections contain reference material related to this feature. Information is included on the following areas:
Components
The following components are added for this feature.
Intelligent Network Service (INSERVICE) Table
This section is used to show the configurable components of the INSERVICE table. Its MML name is as follows:
•MML Name - INSERVICE
The structure of this component is shown in the following table.
Validation Intelligent Network Service Table
The following rules are used to support INSERVICE table provisioning.
•Global title format (GTFORMAT) must be set to NOGT if the GTORSSN parameter is set to ROUTEBYSSN. Otherwise, GTFORMAT must be set to a value other that NOGT.
•The MSNAME must exist in the MessageSendingName table in trigger.dat.
•Only one entry can exist in the INSERVICE table for each MSNAME.
The following components are modified for this feature.
RemoteSSN Added To SS7SUBSYS
SS7SUBSYS represents an SS7 subsystem. It is used for specifying mated STPs and provides LNP support through an SCP. The ssn property is now called LOCALSSN and REMOTESSN has been added. Its MML name is as follows:
•MML Name - SS7SUBSYS
The structure of this component is shown in the following table.
Note SSN has been renamed LOCALSSN to clarify the intent of the parameter. There is continued support of SSN for the MML command line. If both SSN and LOCALSSN are specified, LOCALSSN is used. When using the prov-exp command, LOCALSSN is used.
For information on the rest of the components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Saving
The data is available for call processing after the session that the messaging sending information is configured in has been made active using either prov-cpy or prov-dply.
Provisioning Example
The intelligent network service can be changed at any time, as it is dynamically re-configurable.
The following MML commands allow you to add, retrieve, edit, and delete information related to the to intelligent network service functionality.
Intelligent Network Service Creating Example
Example of creating intelligent network service entries:
prov-add:inservice:name="serviceone",skortcv=37,gtorssn="routebygt",gtformat="gttt",msname ="generic_lnp"
prov-add:inservice:name="servicetwo",skortcv=0,gtorssn="routebyssn",gtformat="nogt"
Intelligent Network Service Editing Example
To add a entry for intelligent network service one:
prov-ed:inservice:name="serviceone",skortcv=255
Intelligent Network Service Deleting Example
To delete the intelligent network service:
prov-dlt:inservice:name="serviceone"
Intelligent Network Service Retrieving Example
To retrieve all of the intelligent network services:
prov-rtrv:inservice:"all"
To retrieve the intelligent network service one:
prov-rtrv:inservice:name="serviceone"
Record Type Message Sending (MS) Table
The Message Sending table is a collection of data necessary to send a TCAP message. The previous fields are listed in the first column, the migrated fields are listed in the second column, and the current table fields are listed in the third column of Table 1.
The MDL parameter for ssnPres is always passed to the TCAP with a value of false.
The Message Sending table exists in the trigger.dat file. The Message Sending table has been modified to support the current 11 parameters instead of the 21 parameters it previously supported.
Packaging and Installation Scripts
Currently the trigger.template is installed onto the system during installation. If there is a trigger.dat file currently in the /<BASEDIR>/etc directory then it is left. However, if a trigger.dat file is not present, the trigger.template file is copied to trigger.dat. In the clearcase repository the file is stored as /vobs/NSSU_Main/callproc/Tables.trigger.
To support this feature, information in the trigger.dat file, which is now configurable, is moved to the inService.dat file. The inService.dat file is handled the same as other *.dat files in the system, which is installed into the file /<BASEDIR>/etc/CONFIG_LIB/new/inService.dat.
Migration
When migrating to a software release that supports INAP provisioning, the trigger.dat file is migrated and the inService.dat file is created. Also, the file stp.dat has three more columns added to it.
During installation, the trigger file treatment remains unchanged and is copied from the /<BASEDIR>/etc directory to the /<BASEDIR>/etc/CONFIG_LIB/INSTALL-<version>/previous directory. For example, if the BASEDIR was opt/CiscoMGC and the version was 9.2.2, the directory would be /opt/CiscoMGC/etc/CONFIG_LIB/new/INSTALL-<version>/previous 9.2.2, and the migrated contents of this directory are placed in /<BASEDIR>/etc/CONFIG_LIB/new/INSTALL-<version>/migrated.
When this feature is installed onto the MGC, the trigger.dat message-sending table is migrated to the new format at this time. If the data is migrated successfully, then the directory /<BASEDIR>/etc/CONFIG_LIB/CFG_Migrated becomes the active link with the files from the migrated directory.
When migrating to a software release that supports INAP provisioning, the trigger.dat file is installed in <BASEDIR>/etc as trigger.dat.new. If you do not want to use the migrated trigger.dat and inService.dat files, you can do the following:
•Copy trigger.dat.new to trigger.dat in <BASEDIR>/etc
•Delete all of the entries in the inService.dat file using prov-dlt
•Reprovision the entries in the inService.dat file using prov-add
You can choose to do this if you would like to use the more meaningful names in the trigger.dat file and in the inService.dat file.
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 you are to edit. 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 that equal to the TriggerType beginning from the number 1.
Note Do not count any row that is blank or begins with a # (pound sign).
Step 6 When you find your row, write down the second number in that row, which is the index to the $MessageSending table.
Caution You must verify that column 1 is equal to 2 or 3 before changing Translation Type. If column 1 is not equal to 2 or 3, it 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 5 (see Table 3).
b. In the table for your translation type, change the value (from 0 through 255) for your translationType, which you can get from your network administrator.
Step 8 Save your changes and close the editor.
Step 9 For your changes to take effect you must reboot the Cisco MGC by entering the following command:
# /etc/init.d/CiscoMGC start
Table 2
Software Release 9.3(2) Message Sending Table Values
Initializing the Call Screening Database
Caution Cisco does not support the direct use of TimesTen commands (files found in /opt/TimesTen/32/bin). Incorrect use of these commands can cause database corruption.
During installation, the installation script (install.sh) installs and initializes the Main Memory Database (MMDB) that the Cisco MGC can use for the following:
•Store call-screening information for calling- and called-number analysis
•Ported Numbers
•Number Termination
•Multiple Dial Plan
•Advice of Charge II
You can perform whitelist 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).
Note When provisioning dial plans, the *.SysConnectDataAccess property (in XECfgParm.dat) must be set to true to allow database access for A-number screening, LNP, and other dial plan functions. Refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide for more information on software configuration settings.
The call screening database is stored in the /opt/TimesTen/datastore directory. The database name is howdydb. The maximum database size, 256 MB, is specified in the .odbc.ini file.
Caution Do not change the database name.
Glossary
Table 4 contains acronym definitions and technical terms used in this feature module.
Posted: Mon Mar 12 16:36:14 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.