Feature Description

The Full Number Translations feature provides a large-scale, number translation function on the Cisco PGW 2200 Softswitch. This feature enhances the current Cisco PGW 2200 Softswitch database query mode, which is used for local number portability (LNP) and CLI screening, by handling contiguous ranges of numbers with analysis and modification capabilities. The Full Number Translations feature supports large-scale changes of individual numbers. This feature adds the NUM_TRANS result type that is implemented in analysis where the existing Times Ten database is used to store the dial plan numbers.

The full number replacement mechanism adds a general number replacement result type, NUM_TRANS, available for A-number and B-number analysis. In addition, a Times Ten query and full number translation table are also added.

The purpose of this result is to indicate one of a possible enumerated list of numbers which require full replacement.

Result Handling Logic

The NUM_TRANS result type is available for A-number analysis or B-number analysis.

The dial plan result type returns a numeric ServiceKey that is used to look up the ServiceName in the dial plan. During provisioning, only a previously provisioned ServiceName can be used, to access numbers in the database requiring full number translation.

The ServiceKey to ServiceName is resolved in the dial plan service table.

You can use the ServiceNames as an index to identify, compare, and re-use particular areas of the full number translation table based on your requirements (such as from where a call originated, or to deal with National/International number lookups).

The Number Type dataword is returned to indicate the type of number to be replaced. This refers to the called, calling, and redirecting numbers.

Because this result causes an entire number replacement to occur, the Nature of Address (NOA) may also be replaced and optionally a change of dial plan can be specified. This change of NOA can optionally be returned in the NUM_TRANS result type and is updated against the numbers being replaced.

If a successful database look up occurs, both the NOA changes and dial plan changes provisioned against the NUM_TRANS result type are acted on by the Cisco PGW 2200 Softswitch.

If a successful number translation occurs, then continuation of analysis from the existing point may no longer be logical. Any or all of the called party, calling party, and redirecting number values may be fully replaced requiring a complete re-analysis of the B number or A number. If the number translation fails, the other number modifications will take effect.

In the Cisco PGW 2200 Softswitch Release 9.7(3) patch 25, a new parameter, *.FNTBehaviourOptions, is added to the XECfgParm.dat file. You can use this parameter to control the behavior of the full number translations function. This parameter has two valid values, 0 and 1. When *.FNTBehaviourOptions is enabled (set to value 1), if a successful number translation occurs, A/B/Redirecting number modifications through AMODDIG/BMODDIG/RMODDIG configured in the same result set with NUM_TRANS will get dropped.

If you are going to use this feature for the first time, you are recommended to set the value of *.FNTBehaviourOptions to 1. The value 0 is used for consistency with the existing behavior of the full number translations function.

Note•To ensure that the analysis is completed correctly, a return to Pre-analysis is required in all cases. If there is a dial plan change, then the analysis begins again at the Pre-analysis stage in the new dial plan.

•The NUM_TRANS result is given priority with respect to the handling of all results and causes analysis to begin again when it finds a successful result.

•If a successful full number translation occurs, other result types encountered during digit analysis, such as Nature of Address changes, dial plan changes, routes, number modifications, and so on, may not execute, as they are overridden by a successful NUM_TRANS lookup result.

Longest matching is performed when more than one NUM_TRANS result type is encountered during analysis. This means that the last successful database lookup against a specific number type is matched, and any previous results against this number type are overwritten. It is possible that an earlier NUM_TRANS result would find a successful match and a later NUM_TRANS result could fail, because of longest matching only the last NUM_TRANS result encountered for this number type is performed.

For more details on longest matching, see the Dial Plan Longest Match feature (Release 9.6(1)) at the following URL:

If full number translation database lookups are not successful at any digit depth, then any other digit modifications and result types will be acted on as normal.

Although a NUM_TRANS result can be declared at any number of digits, the number stored for comparison purposes is the entire dialed number. For overlap sending, any NUM_TRANS result encountered causes a wait for all digits to be received before database comparisons are performed in order to present the full number.

If more than one NUM_TRANS result type is chained together with different number types, but all result types indicate a dial plan change, then a longest match on the dial plan change occurs. Thus the dial plan change specified in the last successful database lookup of any number type is used.

Note Any successful database lookup indicating a dial plan change overrides all explicit dial plan change results which may also be present in a set of results.

Table 1 shows the effects of full number translation results within a dial plan. The example given is for the dialed number 123456.

As each digit is analyzed, additional results are encountered and collected to create a complete result set. No analysis action takes place until all results have been collected. However, Table 1 shows the final action of each result, based on the order it was encountered and the success or failure of lookups in the Times Ten database.

A normal B-number modification within the result set is shown to demonstrate how and when the NUM_TRANS result type is overridden.

The third column (NUM_TRANS Comparison Number) shows the digits presented to the Times Ten database as a match criteria.

The fourth column (Outgoing B-number with All NUM_TRANS Successful) shows how the B-number is modified if a match to the comparison number is successful. The fifth column (Outgoing B-number with No Successful Lookups) shows the B-number without modification from the NUM_TRANS result type.

Keep the following in mind when using the NUM_TRANS result type:

•The BDIGMOD result type is not effective if any NUM_TRANS result type is successful, but is effective when the last NUM_TRANS result type fails to match.

•Both NUM_TRANS result types enter the same originally dialed digit string (without number modifications).

It is the success or failure of the second NUM_TRANS result type that overrides the first NUM_TRANS result type (all the previous result types). Therefore, failure of the second NUM_TRANS result type means that all NUM_TRANS results (for B-number translation) succeeded or failed and only the last NUM_TRANS result type is acted on.

As a result, a successful NUM_TRANS lookup in row 3 is not effective in this dial plan. If the NUM_TRANS result type 2 in row 5 fails, then all the B-number lookups fail. Therefore, the B-number digit modification, the remaining result type, is acted on.

B Digit Being Analyzed

Result

NUM_TRANS Comparison Number

Outgoing B-number with All NUM_TRANS Successful

Outgoing B-number with No Successful Lookups

1

123456

123456

2

123456

123456

3

NUM_TRANS B-number (successful - replace with 654321)

123456

654321

123456

4

BDIGMOD (remove two digits)

654321

3456

5

NUM_TRANS B-number (successful - replace with 98765)

123456

98765

3456

6

98765

3456

Note The NUM_TRANS result type is extremely powerful and flexible in its implementation. Take extreme care when constructing dial plans using the NUM_TRANS result type, as it can produce some unexpected results if the methodology of this result is not well understood. It is recommended that dial plan changes occur on successful A-number and B-number translations, as it is possible to cause a loop behavior in the dial plan. However, the dial plan loop is trapped after some iterations of analysis. It can also be extremely difficult to determine the expected outcome of the dial plan, especially if re-analysis causes the same NUM_TRANS result types to be encountered again. Changing the dial plan allows a more maintainable and manageable infrastructure for dial plans.

Benefits

This feature allows support of a full number replacement mechanism using a database and makes it possible to cater to large numbers of individual numbers rather than contiguous numbers.

Restrictions

Related Features and Technologies

The following features and technologies are related to this feature:

• Dial Plan Longest Match (Release 9.6(1))

•Support of Location Mapping

Software Structural Changes

This section describes the structural changes to the Cisco PGW 2200 Softswitch software for this feature. For information on the software structure of the rest of the Cisco PGW 2200 Softswitch software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.

Related Documents

This document contains information that is related to this feature. The documents that contain additional information related to the Cisco PGW 2200 Softswitch are at the following url:

Supported Platforms

The hardware platforms supported for the Cisco PGW 2200 Softswitch software are described in the Cisco PGW 2200 Softswitch Hardware Installation Guide.

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 PGW 2200 Softswitch software, refer to the Cisco Media Gateway Controller Release 9 Management Information Base Guide.

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites for Using this Feature

The Cisco PGW 2200 Softswitch must be running Cisco PGW 2200 Softswitch software Release 9.7(3). Prerequisites for this release can be found in the Release Notes for the Cisco PGW 2200 Softswitch Release 9.7(3) at:

XECfgParm.dat Configuration Tasks

Configuring the XECfgParm.dat File for This Feature

In the Cisco PGW 2200 Softswitch Release 9.7(3) patch 25, you can configure the *.FNTBehaviourOptions parameter of the XECfgParm.dat file to control the full number translation behavior.

•When *.FNTBehaviourOptions is set to 0, the existing analysis behavior is maintained.

•When *.FNTBehaviourOptions is set to 1, the analysis drops all the other number modifications in the same result set when full number translation is successful. If the full number translation fails, the other number modifications will take effect.

If you are going to use this feature for the first time, we strongly recommend that you set the value of this parameter to 1.

Note Any changes of the XECfgParm.dat file require a restart of the Cisco PGW 2200 Softswitch software.

Provisioning Tasks

You must start a provisioning session to enable this feature. See the Cisco MGCP Provisioning Guide for details on how to start a provisioning session.

Provisioning Basics

The procedures in this section describe how to start a provisioning session and how to save and activate the changes you have made.

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

For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:

prov-sta::srcver="ver1",dstver="ver2"

Once a provisioning session is underway, you may use the prov-add, prov-ed, or prov-dlt MML commands to add, modify, and delete components on your system. This document describes how to provision this feature. For more information on provisioning other components on your Cisco PGW 2200 Softswitch, refer to the Cisco PGW 2200 Softswitch Release 9 Provisioning Guide (through Release 9.7).

Saving and Activating your Provisioning Changes

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

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

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

Caution Do not use the
prov-cpy command to save and activate your changes on a continuous-service Cisco PGW 2200 Softswitch (active and standby hosts) system. Saving and activating using
prov-cpy on such a system would require using the
prov-sync MML command to synchronize the provisioning data on the active and standby hosts. The system does not indicate when the synchronization process fails, which would cause problems when a switchover operation occurs.

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

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

Ending a Provisioning Session Without Activating your Changes

If you want to end a provisioning session without saving and activating the changes you have entered, enter the prov-stp MML command. This command ends your current provisioning session and your changes are not committed.

Retrieving Provisioning Data

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

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

For example, to view the provisioning data for a SS7 signaling service called ss7svc1, you would enter the following command:

prov-rtrv:ss7path:name="ss7svc1"

The response to the command is dependent upon the component type associated with the desired component. For example, to view the properties for an SUA routing key called suakey1, you would enter the following command:

prov-rtrv:suakey:name="suakey1"

Retrieving Data for All Components

You can retrieve data on all of the components provisioned on your system. To do this, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:

prov-rtrv:all

Retrieving Data for All Components of a Particular Type

You can retrieve provisioning data on all components of a particular type on your system. To do this, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:

Adding a Service to the Dial Plan

Placing the Results in the B Digit Tree

Provisioning Example With FNTBehaviourOptions Enabled

Figure 1 shows how the Cisco PGW 2200 Softswitch processes number analysis when the *.FNTBehaviourOptions parameter is enabled (effective for release 9.7(3) patch 25 and later). The Cisco PGW 2200 Softswitch configuration for this example is as following:

1. NUM_TRANS for A number is successful. Since the FNTBehaviourOptions is enabled, the A_NUMBER_TYPE, B_NUMBER_TYPE, and R_NUMBER_TYPE results will be dropped. Dial plan will be changed from DP00 to DP01 according to the value configured for DW4 of the NUM_TRANS result type.

2. NUM_TRANS for A number is failed. BMODDIG, AMODDIG, and RMODDIG results will take effect.

Software Changes for This Feature

XECfgParm.dat Parameters

The XECfgParm.dat file configuration parameters added for this feature are in the following table. For information on the other XECfgParm.dat parameters, see the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.

Specifies the full number translations behavior of the Cisco PGW 2200 Softswitch number analysis function.

Valid values:

•0—to be consistent with the existing full number translation behavior

•1—to drop all the other number modifications in the same result set when full number translation is successful

Default value: 0.

Result Type Definitions

Result analysis provides the capability to group actions into result sets that can be attached at different points of analysis. The main attachment points are: Pre-analysis, A-number analysis, B-number analysis, and Cause analysis.

The following result type definitions are added, modified, or deleted for this feature. For information on other result type definitions for the Cisco PGW 2200 Softswitch, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

The following paragraphs contain definitions of the result type listed in Table 1.

NUM_TRANS

The NUM_TRANS result type is returned from A-number (the calling number) or B-number analysis (the called number) indicating that one or more numbers encountered require full replacement. The NUM_TRANS result type has the following datawords:

•Dataword1—ServiceKey. An integer representing the previously provisioned Service Name in the Service table. This is a user-controlled key into the Times Ten query, full number translation table. Digit strings stored in the full number translation table are case insensitive. That is to say, if digit strings that you provisioned contain alphabetic characters, the TimesTen database saves them as uppercase characters in the full number translation table.

Note The service key must reference a previously provisioned service name.

•Dataword2—Number Type. An integer indicating the number type being translated. Dataword2 values are:

–1. CdPn—Called party number.

–2. CgPn—Calling party number.

–3. Rdn—Redirecting number.

–4. Rdn and CgPn—Calling party number and Redirecting number. Both numbers are replaced if the calling party number is found in the Times Ten database.

•Dataword3 (Optional)—Nature of Address (NOA). This is an integer value that indicates the NOA value for the number type being translated. Dataword3 values are: 0 through 55.

Note This field is updated only if a successful match is found in the full number translation table.

•Dataword4 (Optional)—Dial plan. This is a 4-digit integer that represents the previously provisioned dial plan(s) in the Cisco PGW 2200 Softswitch. Valid values for this dataword are existing dial plan indexes, which are 0001 through 9999.

Note The dial plan changes only if a successful lookup occurs in the full number translation table. The dial plan must reference a previously provisioned dial plan name.

Note When a successful NUM_TRANS a lookup occurs, it takes precedence over all other results in the result set, but if the NUM_TRANS result is not successful; then all the remaining results in the result set are performed. Thus it may be advisable to perform a dial plan change before resuming number analysis. Because after a successful number replacement, the flexibility of this result can cause confusion in cases where A-number replacements are successful in B-number Analysis and B-number replacements are successful in A-number Analysis. By changing dial plans, it becomes more obvious and logical to the user that a replacement occurred.

Provisioning Rules

XECfgParm.dat file provisioning rules:

•When you are using this feature for the first time, set *.FNTBehaviourOptions = 1 in the XECfgParm.dat file.

•The value 0 of the *.FNTBehaviourOptions parameter is for backward compatibility.

NUM_TRANS result type provisioning rules:

•NUM_TRANS result types can be present in both A-number analysis or B-number analysis.

•Because the NUM_TRANS result type causes an entire number replacement to occur, the nature of address may also be replaced.

•Both the NOA changes and dial plan changes provisioned against the NUM_TRANS result type are only acted on when a successful database lookup occurs.

•When a successful number translation occurs, a return to Pre-analysis is required.

• When a dial plan change is encountered, analysis begins at the Pre-analysis stage in the new dial plan

•The NUM_TRANS result has priority in terms of the handling of all results and causes analysis to resume when a successful result is found.

•When multiple NUM_TRANS result types are encountered, longest matching is performed. As a result, the last successful database lookup against a specific number type is acted on, and any previous NUM_TRANS results against the same number are overwritten. As a result, a previous NUM_TRANS result may have successfully matched and a later NUM_TRANS result may fail; due of longest matching, only the last NUM_TRANS result encountered for the number type is effective.

•If a full number translation database lookup is not successful at any digit length, then any other digit modifications and result types are acted on.

•Although a NUM_TRANS result can be declared at any digit length, the number used for comparison purposes is the entire dialed number.

•For overlap sending, any NUM_TRANS result encountered causes a wait until all digits are received before a database comparison is performed.

•The number presented to the full number translation database is the full dialed number, without any other digit modifications that may have been encountered in other result types.

•If multiple NUM_TRANS result types, with different number types, are contained in a result set; but all NUM_TRANS result types indicate a dial plan change, then the longest match on the dial plan change occurs. Thus the dial plan change indicated in the last successful database lookup of a number type is used.

•A successful database lookup indicating a dial plan change overrides explicit dial plan change results that may also be present in a result set.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation at

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

Glossary

Table 2 contains expansions of technical terms used in this feature module.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0907R)