Table Of Contents
Redirection Number Modification and Advanced A-Number(s) Normalization
Document Release History
The Redirection Number Modification and Advanced A-Number(s) Normalization feature is described in the following sections:
Note The Cisco PGW 2200 PSTN Gateway (hereafter referred to as Cisco PGW 2200) is the new name for the Cisco VSC 3000 and the Cisco SC 2200. Some parts of this document may use these older names.
The Redirection Number Modification and Advanced A-Number(s) Normalization feature is implemented only for the European region—the property actions of this feature are based on European national and international prefix numbers.
This feature provides the Cisco PGW 2200 the following capabilities:
•The ability to modify the Redirecting Number and its associated NOA as a result of any analysis phase such as Pre-analysis, A/B number analysis or Cause analysis. If an analysis phase provokes such a result and the Redirecting Number does not exist, it creates the parameter information that is sent in an outgoing message.
•The ability to format the A/B numbers according to the properties either at ingress or egress, or at both, if so provisioned.
•The function of the existing outgoing number formatting properties not only applies to National/International /Country code prefixes to the Calling Party number, but also to other originating numbers (GN_CgPn, Redirecting number and OCN), if present.
•Delivers the capability to perform number normalization (removal or addition of European national or international prefix digits) on the following:
–All originating number parameters (CgPn, GN_CgPn, Redirecting Number and OCN).
–The B-number before any analysis is started.
•Enhances pre-analysis to encompass an initial stage that precedes all other stages. This initial stage carries out NOA/NPI analysis against the Calling party number and provides access to all available pre-analysis results. A new set of NOA/NPI tables is provided so that actions can be individually configured for both A and B number NOA/NPI values.
Modification of the A-Number and B-Number is supported in the Cisco PGW 2200. When the Cisco PGW 2200 interfaces to SIP and H.323 networks, the service provider may want to modify certain parameters of the A-Number, B-Number and Redirecting Number, among others. This feature enables the Cisco PGW 2200 to do the following:
•Modify both the Redirecting Number and its corresponding nature of address (NOA).
•Analyze the CgPN NOA to do appropriate modification of CgPN. For example, detect a national NOA and change to subscriber or international number.
This document contains information that is related strictly to the Redirection Number Modification and Advanced A-Number(s) Normalization feature. The documents that contain additional information related to the Cisco Media Gateway Controller (MGC) are listed below:
•Cisco Media Gateway Controller Software Release 9 Dial Plan Guide
Note This Feature Module is designed to be used closely with the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•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 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
•Cisco Billing and Measurements Server (BAMS), Release 3.x
•H.323 Signaling Interface Guide
The hardware platforms supported for the Cisco MGC software are described in the Cisco Media Gateway Controller Hardware Installation Guide.
You must have the following installed on your system:
•Solaris 8 Operating System
•Latest Cisco MGC software release and patches
•An understanding of the principles of creating a dial plan
You must install the latest patches from CCO when upgrading your Cisco MGC software version. The migration scripts will update the .dat files and add the new dial plan tables, but it will not update MML batch files to reflect the new MML parameters anoa, bnoa, anpi and bnpi.
Creating the Dial Plan with Redirecting Number Modification and Advanced A-Number(s) Normalization
A dial plan provides the flexibility to perform Pre-analysis, A-number analysis, and B-number analysis for either nailed (signaling) or switched (call control) call routing.
The service provider can modify parameters at the A-Number, B-Number and Redirecting Number, as well as analyze the CgPN NOA to do appropriate modification of CgPN. For example, detect a national NOA and change to subscriber or international number
Note Normalization will be dependent on the European National and International prefix digits (0 and 00, respectively).
By defining result types, you can modify the Redirecting Number from any of the following:
•Cause areas of analysis
Create a new result type R_NUMBER_TYPE to modify the NOA of the Redirecting Number in the same places.
The following are the Analysis Result Types (open to A, B, pre-analysis and Cause analysis):
•RMODDIG [Data words: Application point, number of digits to remove, Modification Name, 0 (not used)]
•R_NUMBER_TYPE (Data words: Redirecting Number type, 0, 0, 0)
If Redirecting Number is not present and RMODDIG adds digits by modification string, then the system will automatically create the parameter during analysis call processing, ready for sending on the outgoing side. The following are the default parameters:
•NOA = national
•NPI = E.164
Trunk Group Properties for Calling Party Numbers
The following properties are used after analysis to model the final outgoing number appropriately. They apply to all originating A numbers, such as CgPN, GN-AcgPN, Redirecting Number and OCN:
Note The following are INGRESS properties and only apply to calls coming in (not calls going out). These properties must be acted upon before entering Number Analysis.
Ingress trunk group properties, applicable to both VoIP (SIP/EISUP) trunk groups and TDM trunk groups, are required.
Call Processing Actions of Anumnormalise and Bnumnormalise Properties
Described below are the required call processing actions prior to analysis if properties Anumnormalise or Bnumnormalise are provisioned.
The following are the behavior of the properties:
•If the NOA of the affected numbers is either unknown or subscriber, then the initial digits of the address are checked to see if the initial digits are 0 or 00.
•If the initial digit is a single zero, then this digit is removed and the NOA for the number is set to national.
•If the initial digits are double zeros, then these digits are removed and the associated NOA is set to international.
Anumnormalize indicates that A-number (CgPn) normalization is appropriate based on the NOA value and the leading digits of the A-number. Leading digits '0' or '00' are the only relevant values.
Default Value: 0
When this property is provisioned, any normalization action is applied to the Calling Party number in addition to any of the following numbers, if they are present (stored internally):
•GN_AcgPn—Generic number parameter containing additional Calling Party number
•Redirecting Number (all if more than one)
•OCN—Original Called Number
The actions apply only if the NOA of the particular number (as listed above, in addition to CgPn) is set to UNKNOWN or SUBSCRIBER. In this case, you must check the initial digits of the number to see if they are '0' or '00'. The following applies:
•If the leading digit is '0', remove the zero and set the NOA to NATIONAL.
•If the leading digit is '00', remove the double zero and set the NOA to INTERNATIONAL.
The following table illustrates the behavior for the Anumnormalise property:
Example of Use of Ingress Trunk Group Properties
Following is an example that illustrates how the ingress trunk group properties are used in actual call situations:
Bnumnormalise is used to normalize the Called Party Number (CdPN). Although this can be done in B-Number pre-analysis, it is administratively easier to set up a general property on trunk groups which modify the CdPN from unk/sub to nat/int NOA without having to set up an analysis function in every incoming dialplan (for example, VoIP network). The properties are either set to enabled or disabled (default).
The following table illustrates the behavior for the Bnumnormalise property:
Note The SIP protocol defaults NOA to unknown because SIP addresses do not contain the concept of NOA.
When this property is provisioned, any normalization action must be applied only to the Called Party number.
The actions only apply if the NOA of the Called Party number is set to UNKNOWN or SUBSCRIBER. In either case, the initial digits of the number must be checked to see if they are '0' or '00.' If this is the case, the following applies:
•If the leading digit is '0', remove the zero and set the NOA to NATIONAL.
•If the leading digit is '00', remove the double zero and set the NOA to INTERNATIONAL.
Bnumnormalise indicates that B-number (CdPn) normalization is appropriate based on the NOA value and the leading digits of the B-number. Leading digits '0' or '00' are the only relevant values.
Default Value: 0
A-Number Indicator Pre-Analysis
To perform modifications with complete flexibility, the CgPN number indicators, NOA and NPI must be available in pre-analysis with all the current result types available, in addition to the RMODDIG and R_NUMBER_TYPE.
The properties 'Anumnormalise' and 'Bnumnormalise' are implemented only for the European region. The properties provoke actions according to National and International number prefixes which have been limited to the European versions ('0' and '00' respectively).
A new stage of Pre-analysis has been added to allow NOA/NPI analysis of the calling number. This means that Pre-analysis now comprises the following stages which are processed in the order shown below:
1. NOAcg/NPIcg analysis (calling number)
2. CPC analysis
3. TMR analysis
4. NOA/NPI analysis (called number)
5. TNS analysis
6. NANP number normalization
Accessing the Calling Party NOA/NPI Tables
The reading of the new calling party NOA/NPI tables constitutes the same functionality as the existing Called number NOA/NPI table reading. Another input parameter indicating whether to read the NOA/NPI tables or the NOAcg/NPIcg tables has been added, modifying the existing functional interface.
When reading the NOA/NOAcg or NPI/NPIcg tables, the system allows for default empty tables (created when the dial plan is created) and, in this case, ignores them. Consequently there is no need to populate these tables if the functionality is not required.
The following conditions apply to any call received via the SIP protocol:
Note In the following statements, "number" applies to CdPn, CgPn, Redirecting number, and the OCN.
•If the number is without a plus (+) character prefix, the call is processed as normal, but the NOA parameter data in the data store (call context) is set to "Unknown."
•If the number has a plus (+) character prefix, the call is processed as normal but the NOA parameter data in the data store (call context) is set to "International."
•The number's NPI value defaults to E164.
Note There is only one incoming Trunk Group for SIP, so whatever Trunk Group properties are provisioned, those values will apply to all calls received from SIP.
Ingress Trunk Group properties
There are two new Trunk Group properties that will provide the indication to Analysis as to whether the numbers should be normalized before starting any analysis. The Generic Analysis module will read these properties and any normalization will be applied prior to the start of the Pre-analysis stage.
•Anumnormalise—used to normalize the CgPn, GN-ACgPN, Redirecting Number (all if more than one), and OCN numbers.
•Bnumnormalise—used to normalize CdPN number.
These properties only apply actions if the NOA of the A or B number presented is either "NOA_SUBSCRIBER", (internal PGW value 3) or "NOA_UNKNOWN" (internal PGW value 2); all other NOA settings will be ignored.
Providing that the presented numbers have their NOA set to either "NOA_SUBSCRIBER" or "NOA_UNKNOWN," the actions detailed in the following table will be applied:
At this point only a zero (0) or double zero (00) can be removed from the presented number, and no digits will be added. If digits are removed, the NOA will be set accordingly to reflect the removal of digits.
Normal number analysis and Routing analysis take place during which further modifications can be made to A, B or Redirecting number. Analysis will respond to the Call control subsystem delivering a Trunk Group on which circuit selection should be attempted. If circuit selection is successful, the TCC side of the PGW will be created and seized and Call control will prepare to send the call forward by provoking message construction in the TCC protocol.
The last thing Call control does before invoking message construction in the TCC side is to run a series of routines which apply the outgoing number formatting to the A and B numbers. These routines decide whether a Country code will be removed or applied and also whether an International or National prefix should be added before the number. This is determined by setting other properties, such as Anumnormalise and Bnumnormalise (refer to the "Dial Plan Result Types" section and "Bnumnormalise indicates that B-number (CdPn) normalization is appropriate based on the NOA value and the leading digits of the B-number. Leading digits '0' or '00' are the only relevant values." section). This is a separate activity performed post-analysis at a very late stage of the PGW call processing and is independent of the ingress property actions described here.
Once this is done, the call is forwarded via the TCC protocol with the numbers adjusted, as required by the provisioned settings.
The Generic Analysis module (GA) has three functions:
•Read new ingress properties A/Bnumnormalise and apply number normalization prior to starting any analysis (if required).
•A new stage of Pre-analysis was added to analyze the calling Party number NOA/NPI. In order for the NOA/NPI actions to be individually configured for A and B numbers two new dialplan tables NOAcg and NPIcg will be required. To support the reading of these tables from GA module, a new functional interface to the engine will need to be introduced.
•Support and process two new result types RMODDIG and R_NUMBER_TYPE from Pre-analysis, A-number, B-number and Cause analysis stages. If these results are retrieved and the Redirecting number is not present, then the appropriate data store (call context) fields must be populated and default populated to ensure the creation of this parameter at the protocol level.
Ingress Trunk Group Property Values
With the introduction of the new Pre-analysis stage to read the NOAcg and NPIcg tables, the Transver tool has been enhanced.
The trace stage is called Profile Analysis. The existing NOA_TABLE and NPI_TABLE identifiers remain the same. The following are identifiers for use with the new types of table reading:
•NOA_A_TABLE and NPI_A_TABLE (new identifier for reading NOAcg and NPIcg)
•NOA_TABLE and NPI_TABLE (existing identifier for reading NOA and NPI)
Note The treatment of these properties applies to the European region only. This means that normalization is dependent on the European National and International prefix digits ('0' and '00' respectively).
Dial Plan Result Types
There are two result types for the Dial Plan data:
These results should be configured when changes are required to the Redirecting number and its associated NOA value. The following table details the result type with respect to new analysis results:
Table 5 New Analysis Result Types
<Option> Example Dataword Types Analysis Point Valid for A/B/P/C
Key to Table 5:
I - Integer
S - String
P - Pre-Analysis
A - A-Number analysis
B - B-Number analysis
C - Cause Analysis
Note The Dataword Types column indicates the type for each of the datawords for that result. Validation is performed based upon the type.
For the AMODDIG, BMODDIG, and RMODDIG results, the following rules apply:
•dw1 must be 1 - 32 or 98
•dw2 must be 0 - 32 or 99
•dw3 must be 0 or an existing digname
•dw4 must be 0
NOAcg and NPIcg Dial Plan Tables
A set of NOA/NPI tables are required so that independent actions can be provisioned for the Calling Party Number (CgPn or A-number) according to NOA and NPI values.
The table structure and functionality are the same as for the existing NOA and NPI tables which define actions for the B-number (CdPn). From a provisioning point of view, the actions required to define and populate the tables are exactly the same as for the existing NOA and NPI tables.
Note Although the provisioning of the NOAcg and NPIcg dial plan tables are similar in concept and table structure, they do differ in terms of MML commands syntax where the specific NOA/NOAcg must be identified.
Table Structures and Examples
The following table structures and corresponding examples are exactly the same as the NOA/NPI tables.
The Nature of Address (Calling) table is entered by an implied NOA index that gives access either to an index into the NPI table, or to an index into the result table. As the NPI Index always points to the start of a block, the value is always (16(n-1)+1), because each block contains 16 values.
Note The result index refers to the same result table to which the digit trees point. The format of the NOA table generated by the DPP is shown below.$NOAcg# Customer:<VCHAR(4)>#NPIIndex resultIndex<NPIIdx> <ResultIdx>(N entries)
The customer identifier is CustGrpId. The first line in the NOA table is used by the Cisco PGW 2200 to determine the beginning of the NOACalling table. The third line contains the name of the columns in this table.
This table is accessed from the NOA table using the NPI Index. The NPI table is separated into blocks to aid the configuration of the table. As noted above, the NPI Index used to access the table must point to the start of a block. The blocks are configured into groups of 16 to reflect the maximum number of NPI values that can be defined. The NPI index is used to find the start of a block, and the NPI value is used to access the block. The number plan indicator table contains a single column that is an index into the single result table. The format of the NOA table generated by the DPP is shown below.$NPIcg# Customer:<VCHAR(4)># resultIndex# block<number><ResultIdx>(N entries)
The customer identifier is CustGrpId. The first line in the NPI table is used by the Cisco PGW 2200 to determine the beginning of the NPI table. The third line contains the name of the column in this table.
Note Blocknumber is a comment that shows the start of the block of 16 entries. The only data in this single column table is resultIndex.
Provisioning the NOA and NPI Tables
To make provisioning of the NOA/NPI tables clearer, the existing MML parameter names have been changed to indicate whether they are used for provisioning the A-number tables (NOAcg/NPIcg) or the B-number tables (NOA/NPI).
The following new target identifiers have been added to the number analysis command syntax:
•ANOA and ANPI (for provisioning NOAcg and NPIcg)
•BNOA and BNPI (for provisioning NOA and NPI)
MML Dial Plan Commands Format
The following is the generic format of the MML dial plan commands:NUMAN-<VERB>:<TID>:CUSTGRPID=<customer group ID>, INDEX=<index>, <PARAM_NAME> = <param value>
•NUMAN indicates number analysis
•<VERB> can be one of the following:
–ADD for adding number analysis data
–ED for editing number analysis data
–DLT for deleting number analysis data
–RTRV for retrieving number analysis data
The new TID (Target identifier) parameter data for the two new tables is provided in the table below:
Provisioning the NOA, NPI, NOAcg and NPIcg Tables
You can provision the NOA, NPI, NOAcg and NPIcg tables at any time by using standard MML commands.
You must configure the setname prior to adding any NOA, NPI, NOAcg or NPIcg entry. The range of valid NOA and NPI values is already documented for the NOA and NPI tables, so any validation will be in accordance with that applied on the existing tables.
Saving the NOA, NPI, NOAcg and NPIcg Tables
Save the NOA, NPI, NOAcg and NPIcg tables in the dial plan.
Provisioning the new NOAcg and NPIcg Tables
Provision the NOAcg and NPIcg with the following MML commands:mml>numan-add:dialplan:custgrpid="T002"mml>numan-add:resulttable: mml>custgrpid="T002",name="result1",resulttype="A_NUMBER_TYPE",dw1="3",setname="setfour"mml>numan-add:anpi: custgrpid="T002",npiblock=1,setname="setfour"mml>numan-add:anoa: custgrpid="T002",noavalue=1,npiblock=1
Similarly, modify or delete an NPIcg entry with the following MML commands:mml>numan-ed: anpi: custgrpid ="T002", npiblock=3, setname=" setfour"mml>numan-dlt: anpi: custgrpid ="T002", npiblock=3
Provisioning the existing NOA and NPI tables
Provision the existing NOA and NPI with the following MML commands:mml>numan-add:dialplan:custgrpid="T002"mml>numan-add:resulttable: mml>custgrpid="T002",name="result1",resulttype="A_NUMBER_TYPE",dw1="3",setname="setfour"mml>numan-add:bnpi: custgrpid="T002",npiblock=1,setname="setfour"mml>numan-add:bnoa: custgrpid="T002",noavalue=1,npiblock=1
Similarly, modify or delete an NPIcg entry with the following MML commands:mml>numan-ed: bnpi: custgrpid ="T002", npiblock=3, setname=" setfour"mml>numan-dlt: bnpi: custgrpid ="T002", npiblock=3
MML Provisioning for New Result Types
Provision the two new results types within the result table. The following MML examples explain how to provision these results types.
Validation of Incoming data
The two result types have exactly the same data word construction as the ones relating to A/B Number modification and Number-type results (A_NUMBER_TYPE, B_NUMBER_TYPE, AMODDIG, BMODDIG). Consequently, the incoming data should be validated in exactly the same way, using existing mechanisms.
If there are to be modifications made to the Redirecting number or to its associated NOA value, then you must provision these result types.
When to provision
The RMODDIG and R_NUMBER_TYPE results may be provisioned at any time using standard MML commands.
The following MML commands are used to provide the RMODDIG and R_NUMBER_TYPE results in the result table within the Dial Plan.
The following examples are optional and are used only if performing pre-analysis:
Example Case 1: Provisioning the digit tree to use the resultsnuman-add:bddigtree:custgrpid="T002",digitstring="0800",callside="originating",setname="settwo"
Example Case 2: Provisioning pre-analysis to use the resultsnuman-add:bnpi: custgrpid="T002",npiblock=1,setname="settwo"numan-add:bnoa: custgrpid="T002",noavalue=1,npiblock=1
Example case 3: Provisioning cause-analysis to use the resultsnuman-add:location: custgrpid="T002",locationblock=1,setname="settwo"numan-add:cause: custgrpid="T002",causevalue=1,locationblock=1
Alarm Logging Information
If the reading of the new NOAcg or NPIcg tables fails during call processing, then an alarm is set and a log is created. In addition, a further alarm is issued if the failure occurs due to errors such as provisioning.
It is important to differentiate the alarm occurring from the new NOAcg or NPIcg tables as opposed to an error in the NOA or NPI tables, so three new alarms are used specific to the Calling Party number tables. The data and template information for these logs are described in Table 8, below.
Table 9 View of the New ResultTypes
ResultType DataWord1 DataWord2 DataWord3 DataWord4
Number of digits to remove
0 (not used)
0 (not used)
0 (not used)
0 (not used)
General Functionality and Operation of New Result Types
The following table lists the functions of the new result types:
Functionality and Operation of New Result Types in Pre-Analysis
Within pre-analysis, the new results for modifying the Redirecting number and its NOA conform to the current rules for results of that type in this processing stage, as shown in the following list:
•Any RMODDIG result type will modify the Redirecting number by overwriting the data store (call context) data. If a further stage of pre-analysis processing provokes another RMODDIG result type, it is applied to the previously modified Redirecting number. This means that this modification result is cumulative through the pre-analysis stages in line with the AMODDIG and BMODDIG operation.
•Any R_NBR_TYPE result will be directly applied to the data store (call context) data, any occurrence of this result in a subsequent Pre-analysis phase overwrites this data with the new and latest value.
Functionality and Operation of New Result Types in A/B Number Analysis
Within A/B Number analysis (Digit Tree Analysis), the new results for modifying the Redirecting number and its NOA conform to the current rules for results of that type in this processing stage, as shown in the following list:
•Before A/B number processing is started, the current Redirecting number is saved. When an RMODDIG result type is retrieved as the analysis is carried out in the respective digit tree, the previously saved number is modified and locally stored.
•If, further down the digit tree decode, another RMODDIG resulttype is retrieved, the new modification is applied to the original number saved at the beginning of this stage of analysis and is locally stored (over-writing any previous modification of this type). Once analysis is completed for this stage, the local store is written to the data store (call context).This means that in number analysis, only the last retrieved RMODDIG is applied and written to data store, according to the existing functionality for AMODDIG and BMODDIG in the A/B Number digit trees.
Note Any R_NBR_TYPE result will be directly applied to the data store (call context) data. Any later occurrence of this result in a subsequent Number analysis phase will overwrite this data with the new and latest value.
Functionality and Operation of New Result Types in Cause Analysis
Within Cause analysis (digit tree analysis), the new results for modifying the Redirecting number and its NOA have been implemented to provide maximum flexibility. The following is possible from Cause analysis:
•If a RETRY_ACTION result is retrieved, the result is used to generate the required parameter information, including a Redirecting number. When the Redirecting number is created, the RMODDIG and R_NBR_TYPE results can be used to further modify it, if required.
•If no RETRY_ACTION result is retrieved, the RMODDIG is processed and creates a Redirecting number, if none exists. If a Redirecting number is present, the RMODDIG or R_NBR_TYPE will modify this accordingly, thus allowing the RMODDIG and R_NBR_TYPE to be used in conjunction with other results available to Cause analysis, if necessary.
The following table contains definitions of abbreviations, acronyms, and terms used in this document.