Redirection Number Modification and Advanced A-Number(s) Normalization

Table Of Contents

Redirection Number Modification and Advanced A-Number(s) Normalization

Feature Overview

Benefits

Related Documents

Supported Platforms

Prerequisites

Upgrade Requirements

Creating the Dial Plan with Redirecting Number Modification and Advanced A-Number(s) Normalization

Result Types

Trunk Group Properties for Calling Party Numbers

Call Processing Actions of Anumnormalise and Bnumnormalise Properties

Anumnormalise

Bnumnormalise Property

A-Number Indicator Pre-Analysis

Pre-analysis Stage

Accessing the Calling Party NOA/NPI Tables

SIP Protocol

Generic Analysis

Ingress Trunk Group Property Values

Dial Plan Result Types

NOAcg and NPIcg Dial Plan Tables

Table Structures and Examples

Provisioning the NOA and NPI Tables

MML Dial Plan Commands Format

Provisioning the NOA, NPI, NOAcg and NPIcg Tables

Data input

Saving the NOA, NPI, NOAcg and NPIcg Tables

Provisioning Examples

MML Provisioning for New Result Types

Validation of Incoming data

When to provision

Provisioning Tasks

Alarm Logging Information

General Functionality and Operation of New Result Types

Glossary

Redirection Number Modification and Advanced A-Number(s) Normalization

Document Release History

Publication Date

Comments

September 11, 2003

Final draft of this document.

August 5, 2003

Final draft of this document.

July 29, 2003

Beta draft of this document.

May 29, 2003

Alpha draft of this document.

The Redirection Number Modification and Advanced A-Number(s) Normalization feature is described in the following sections:

• Feature Overview

• Related Documents

• Supported Platforms

• Prerequisites

• Creating the Dial Plan with Redirecting Number Modification and Advanced A-Number(s) Normalization

• Dial Plan Result Types

• NOAcg and NPIcg Dial Plan Tables

• Provisioning the NOA and NPI Tables

• Provisioning the NOA, NPI, NOAcg and NPIcg Tables

• MML Provisioning for New Result Types

• Alarm Logging Information

• Accessing the Calling Party NOA/NPI Tables

• Glossary

Feature Overview

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.

Benefits

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.

Related Documents

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

Supported Platforms

The hardware platforms supported for the Cisco MGC software are described in the Cisco Media Gateway Controller Hardware Installation Guide.

Prerequisites

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

Upgrade Requirements

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

Result Types

By defining result types, you can modify the Redirecting Number from any of the following:

•Pre-analysis

•A-Number

•B-Number

•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:

•AdigitCCPrefix

•AnationalPrefix

•AinternationalPrefix

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.

Anumnormalise

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.

Valid Values:

0=Disabled

1=Enabled

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:

Table 1 Anumnormalise Property Behavior

Incoming

Resulting Format

I/p to Analysis

Originating Number

NOA

Anumnormalise

NOA

1844 260330

Nat

Enable

1844 260330

NAT

44 1844 250330

Int

Enable

44 1844 260330

Int

260330

Sub

Enable

1844 260330

NAT

01844 260330

Sub

Enable

1844 260330

Sub

01844 260330

Unk

Enable

1844 260330

NAT

00441844 260330

Unk

Enable

441844 260330

Int

xyz

a

Disabled

xyz

a

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:

Table 2 Use of Ingress Trunk Group Properties Example Description

For AB

PSTN From A

PGW setup

Outgoing to B

CgPN = 1844 260330; NOA=nat

GN ACgPN = 800800800; NOA=nat

RN = N/A

OCN = N/A

CdPN = 307 1001003; NOA=nat

O-TG2:

CLISelect=GENERICNUM

AnationalPrefix=0

BnationalPrefix=0

CgPN = 0800800800; NOA=unk

GN ACgPN = 0800800800

RN = N/A

OCN = N/A

CdPN = 0307 1001003; NOA=unk

For BF (call forwarded to +34619345678)

VoIP from A

PGW setup

Outgoing to F

CgPN = 0800800800; NOA=unk

GN ACgPN = N/A

RN = 48566; NOA = unk

OCN = N/A

CdPN = 34 619 345678; NOA = Int

I-TG3:

TG_CC_ORIGIN = 44

A digit tree:

Detect 08, strip leading zero and set change NOA = nat Also use result type,

RMODDIG (1,0, '20882')

R_number_type (nat.)

O-TG4:

AdigCCprefix=enable

[this affects all related A numbers]

CgPN = 44800800800; NOA= Int

GN ACgPN = N/A

RN = 442088248566; NOA = Int

OCN = N/A

CdPN = 34 619 345678; NOA = Int.

MULTI CALL FORWARD

For AE

From A

PGW Setup

CgPN = 1844 260330; NOA=nat

GN ACgPN = 800800800; NOA=nat

RN = N/A

OCN = N/A

CdPN = 1473 225789

N/A

For EC (call forwarded to 0310 1234567)

From E

PGW Setup

Outgoing to C

CgPN = 1844 260330; NOA=nat

GN ACgPN = 800800800; NOA=nat

RN = 1473 225789; NOA = nat

OCN = N/A

CdPN = 3101 1234567; NOA = nat.

I-TG5:

O-TG6:

AnationalPrefix=0

[This affects all related A numbers]

BnationalPrefix=0

CgPN = 01844 260330; NOA=unk

GN ACgPN = 0800800800; NOA=unk

RN = 01473 225789; NOA = unk

OCN = N/A

CdPN = 03101 1234567; NOA = unk

For CD (call forwarded to 01928 724953)

VOIP from C

PGW Setup

Outgoing to D

CgPN = 01844 260330; NOA=unk

GN ACgPN = 0800800800; NOA=unk

RN = 03101 1234567; NOA = unk

OCN = N/A

CdPN = 01928 724953; NOA = unk

I-TG7:

Anumnormalise=national

[this affects all related A nos]

Bdigit:

Modify CdPN to national format

CgPN = 1844 260330; NOA=nat

GN ACgPN = 800800800; NOA=nat

RN = 1473 225789; NOA = nat

OCN = N/A

CdPN = 1928 724953; NOA = nat

Bnumnormalise Property

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:

Table 3 Bnumnormalise Property Behavior

Incoming

Resulting Format

I/p to Analysis

CdPN

NOA

Bnumnormalise

NOA

1844 260330

Nat

Enable

1844 260330

Nat

44 1844 250330

Int.

Enable

44 1844 260330

Int.

260330

Sub

Enable

260330

Sub

01844 260330

Sub

Enable

1844 260330

Nat

01844 260330

Unk

Enable

1844 260330

Nat

00441844 260330

Unk

Enable

441844 260330

Int

xyz

a

Disabled

xyz

a

Note The SIP protocol defaults NOA to unknown because SIP addresses do not contain the concept of NOA.

Bnumnormalise Actions

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.

Valid Values:

0=Disabled

1=Enabled

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

Pre-analysis Stage

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.

SIP Protocol

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:

Table 4 Ingress Property Actions When NOA= NOA_SUBSCRIBER or NOA_UNKNOWN

Presented Number Has a Leading Zero Digit

Presented Number Has Leading Double Zero Digits

Remove Zero Prefix and Set NOA to NAT

Remove Double Zero Prefix and Set NOA to INT

Yes

No

Yes

No

No

Yes

No

Yes

No

No

No

No

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.

Generic Analysis

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:

•RMODDIG

•R_NUMBER_TYPE

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

RMODDIG(<Point>,<noDigits>,
<modName>)

RMODDIG(1,3,digname)

I,I,S

Intermediate

PABC

R_NUMBER_TYPE(<RNumberType>)

R_NUMBER_TYPE(1)

I

Intermediate

PABC

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.

NOAcg Table

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.

NPIcg 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>

Where:

•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:

Table 6 New Target Identifier Parameter Data

Component's MML Name

Parameter's MML Name

Parameter's Description

Parameter's Values (Default)

ANOA

NOAVALUE

NOA VALUE (CgPn)

;(0)

NPIBLOCK

NPI block

;(0)

SETNAME

Result Set Name

MML name of the result set; (x)

ANPI

NPIBLOCK

NPI block (CgPn)

;(0)

BLOCKVALUE

Block value

0 - 15; (I) If the block value is not specified, the result index is applied to all block values (0 - 15).

SETNAME

Result Set Name

MML name of the result set; (x)

BNOA

NOAVALUE

NOA Value (CdPn)

;(0)

NPIBLOCK

NPI block

;(0)

SETNAME

Result Set Name

MML name of the result set; (x)

BNPI

NPIBLOCK

NPI block (CdPn)

;(0)

BLOCKVALUE

Block value

0 - 15; (I) If the block value is not specified, the result index is applied to all block values (0 - 15).

SETNAME

Result Set Name

MML name of the result set; (x)

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.

Data input

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 Examples

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.

Provisioning Tasks

The following MML commands are used to provide the RMODDIG and R_NUMBER_TYPE results in the result table within the Dial Plan.

Table 7 MML Commands for the RMODDIG and R_NUMBER_TYPE Results in the Result Table

Task

MML Commands

Creating the Dial Plan

numan-add:dialplan:custgrpid="T002"

Setting the digModstring Table and the Result Table

numan-add:digmodstring: custgrpid="T002",name="digname",digstring="208"
numan-add:resulttable:

Setting the NPI Table

custgrpid="T002",name="result1",resulttype="RMODDIG",dw1="1",dw2="3",dw3="digname",setname="settwo"

Setting the NOA Table

numan-add:resulttable:
custgrpid="T002",name="result1",resulttype="R_NUMBER-TYPE",dw1="3",setname="settwo"

Examples

The following examples are optional and are used only if performing pre-analysis:

Example Case 1: Provisioning the digit tree to use the results

numan-add:bddigtree:
custgrpid="T002",digitstring="0800",callside="originating",setname="settwo"

Example Case 2: Provisioning pre-analysis to use the results

numan-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 results

numan-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 8 Alarm Template Information for Calling Party Number Tables

Alarm Name

Description

Severity

Reporting

Recommended Action

< ANAL: Prof_GetFail_NOATbl_A>

Profile analysis was unable to read the A-number NOAcg table.

This error occurs during Profile analysis when the NOA table is unreadable. This can be due either to the NOA table being corrupted, or to a failure in the underlying software.

0

Y

This alarm typically points to an internal processing error. Capture traces and provisioning data, contact your Cisco support representative and provide this information.

<ANAL: Prof_InvRslts_NOATbl_A>

The values returned to Profile analysis from the NOA table are logically invalid.

This error occurs when Profile analysis successfully reads the NOA table but the value returned is logically invalid. Profile analysis gets two values from the NOA table—an immediate result index and an NPI index.

The immediate result index indicates that analysis should start reading results now but the NPI index indicates that another table read is required to find the correct result table index. These results are logically incompatible. Most likely, this alarm results from a failure of the underlying software or a corruption of the NOA table.

0

Y

This alarm typically points to an internal processing error. Capture traces and provisioning data, contact your Cisco support representative and provide this information.

< ANAL: Prof_GetFail_NPITbl_A >

Profile analysis was unable to read the A-number NPIcg table.

This error occurs during Profile analysis when the NPI table is unreadable. This can be due either to the NOA table being corrupted, or to a failure in the underlying software.

0

Y

This alarm typically points to an internal processing error. Capture traces and provisioning data, contact your Cisco support representative and provide this information.

Table 9 View of the New ResultTypes

ResultType

DataWord1

DataWord2

DataWord3

DataWord4

57 RMODDIG

Application point

Number of digits to remove

Modification index

0 (not used)

58 R_NUMBER_TYPE

RNumberType

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:

Table 10 New Result Types Functions

Condition

Function

If the Redirecting number exists...

The NOA result (R_NBR_TYPE) will only be processed if the Redirecting Number exists in data store (call context). If there is no existing number, then the R_NBR_TYPE result will be ignored.

If the Redirecting number exists...

If the Redirecting number exists, then it will be modified according to the RMODDIG result type data.

If there is no Redirecting number existing in data store (call context), then one will be created with default settings (such as NOA).

When configuring Result-sets...

It is recommended that, if you intend to create a Redirecting number and then further modify its NOA, the RMODDIG result must be defined in the Result set before the R_NBR_TYPE.

If the results are defined in the reverse order then the R_NBR_TYPE result will be ignored and a Redirecting number with default settings will be created by the RMODDIG result. However, if a Redirecting number is expected to be present, then the order of defining the results will not matter.

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.

Glossary

The following table contains definitions of abbreviations, acronyms, and terms used in this document.

Term

Definition

CdPn

Called Party Number (B-Number)

CgPN

Calling Party Number (A-Number)

GA

Short term for the Generic Analysis module

GN_CgPn

Generic Number_Calling Party Number

LCM

Basic Call Model Module (Also referred to as UCM or Universal Call Model)

NOA

Nature of Address

NPI

Number Plan Indicator

OCN

Original Called Number

Cisco PGW 2200

Cisco PGW 2200 PSTN Gateway (formerly called Cisco VSC 3000 and Cisco SC 2200)

SC

Signaling Controller

SW

Software

TG

Trunk Group

UCM

Universal Call Model

VSC

Virtual Switch Controller (previous name for the Cisco PGW 2200)

Publication Date	Comments
September 11, 2003	Final draft of this document.
August 5, 2003	Final draft of this document.
July 29, 2003	Beta draft of this document.
May 29, 2003	Alpha draft of this document.

Incoming			Resulting Format I/p to Analysis
Originating Number	NOA	Anumnormalise		NOA
1844 260330	Nat	Enable	1844 260330	NAT
44 1844 250330	Int	Enable	44 1844 260330	Int
260330	Sub	Enable	1844 260330	NAT
01844 260330	Sub	Enable	1844 260330	Sub
01844 260330	Unk	Enable	1844 260330	NAT
00441844 260330	Unk	Enable	441844 260330	Int
xyz	a	Disabled	xyz	a

For AB
PSTN From A	PGW setup	Outgoing to B
CgPN = 1844 260330; NOA=nat GN ACgPN = 800800800; NOA=nat RN = N/A OCN = N/A CdPN = 307 1001003; NOA=nat	O-TG2: CLISelect=GENERICNUM AnationalPrefix=0 BnationalPrefix=0	CgPN = 0800800800; NOA=unk GN ACgPN = 0800800800 RN = N/A OCN = N/A CdPN = 0307 1001003; NOA=unk
For BF (call forwarded to +34619345678)
VoIP from A	PGW setup	Outgoing to F
CgPN = 0800800800; NOA=unk GN ACgPN = N/A RN = 48566; NOA = unk OCN = N/A CdPN = 34 619 345678; NOA = Int	I-TG3: TG_CC_ORIGIN = 44 A digit tree: Detect 08, strip leading zero and set change NOA = nat Also use result type, RMODDIG (1,0, '20882') R_number_type (nat.) O-TG4: AdigCCprefix=enable [this affects all related A numbers]	CgPN = 44800800800; NOA= Int GN ACgPN = N/A RN = 442088248566; NOA = Int OCN = N/A CdPN = 34 619 345678; NOA = Int.
MULTI CALL FORWARD
For AE
From A	PGW Setup
CgPN = 1844 260330; NOA=nat GN ACgPN = 800800800; NOA=nat RN = N/A OCN = N/A CdPN = 1473 225789	N/A
For EC (call forwarded to 0310 1234567)
From E	PGW Setup	Outgoing to C
CgPN = 1844 260330; NOA=nat GN ACgPN = 800800800; NOA=nat RN = 1473 225789; NOA = nat OCN = N/A CdPN = 3101 1234567; NOA = nat.	I-TG5: O-TG6: AnationalPrefix=0 [This affects all related A numbers] BnationalPrefix=0	CgPN = 01844 260330; NOA=unk GN ACgPN = 0800800800; NOA=unk RN = 01473 225789; NOA = unk OCN = N/A CdPN = 03101 1234567; NOA = unk
For CD (call forwarded to 01928 724953)
VOIP from C	PGW Setup	Outgoing to D
CgPN = 01844 260330; NOA=unk GN ACgPN = 0800800800; NOA=unk RN = 03101 1234567; NOA = unk OCN = N/A CdPN = 01928 724953; NOA = unk	I-TG7: Anumnormalise=national [this affects all related A nos] Bdigit: Modify CdPN to national format	CgPN = 1844 260330; NOA=nat GN ACgPN = 800800800; NOA=nat RN = 1473 225789; NOA = nat OCN = N/A CdPN = 1928 724953; NOA = nat

Incoming			Resulting Format I/p to Analysis
CdPN	NOA	Bnumnormalise		NOA
1844 260330	Nat	Enable	1844 260330	Nat
44 1844 250330	Int.	Enable	44 1844 260330	Int.
260330	Sub	Enable	260330	Sub
01844 260330	Sub	Enable	1844 260330	Nat
01844 260330	Unk	Enable	1844 260330	Nat
00441844 260330	Unk	Enable	441844 260330	Int
xyz	a	Disabled	xyz	a

<Option>	Example	Dataword Types	Analysis Point	Valid for A/B/P/C
RMODDIG(<Point>,<noDigits>, <modName>)	RMODDIG(1,3,digname)	I,I,S	Intermediate	PABC
R_NUMBER_TYPE(<RNumberType>)	R_NUMBER_TYPE(1)	I	Intermediate	PABC

Component's MML Name	Parameter's MML Name	Parameter's Description	Parameter's Values (Default)
ANOA	NOAVALUE	NOA VALUE (CgPn)	;(0)
	NPIBLOCK	NPI block	;(0)
	SETNAME	Result Set Name	MML name of the result set; (x)
ANPI	NPIBLOCK	NPI block (CgPn)	;(0)
	BLOCKVALUE	Block value	0 - 15; (I) If the block value is not specified, the result index is applied to all block values (0 - 15).
	SETNAME	Result Set Name	MML name of the result set; (x)
BNOA	NOAVALUE	NOA Value (CdPn)	;(0)
	NPIBLOCK	NPI block	;(0)
	SETNAME	Result Set Name	MML name of the result set; (x)
BNPI	NPIBLOCK	NPI block (CdPn)	;(0)
	BLOCKVALUE	Block value	0 - 15; (I) If the block value is not specified, the result index is applied to all block values (0 - 15).
	SETNAME	Result Set Name	MML name of the result set; (x)

Task	MML Commands
Creating the Dial Plan	`numan-add:dialplan:custgrpid="T002"`
Setting the digModstring Table and the Result Table	`numan-add:digmodstring: custgrpid="T002",name="digname",digstring="208"` numan-add:resulttable:
Setting the NPI Table	custgrpid="T002",name="result1",resulttype="RMODDIG",dw1="1",dw2="3",dw3="digname",setname="settwo"
Setting the NOA Table	`numan-add:resulttable:` custgrpid="T002",name="result1",resulttype="R_NUMBER-TYPE",dw1="3",setname="settwo"

Alarm Name	Description	Reporting	Recommended Action
< ANAL: Prof_GetFail_NOATbl_A>	Profile analysis was unable to read the A-number NOAcg table. This error occurs during Profile analysis when the NOA table is unreadable. This can be due either to the NOA table being corrupted, or to a failure in the underlying software.	Y	This alarm typically points to an internal processing error. Capture traces and provisioning data, contact your Cisco support representative and provide this information.
<ANAL: Prof_InvRslts_NOATbl_A>	The values returned to Profile analysis from the NOA table are logically invalid. This error occurs when Profile analysis successfully reads the NOA table but the value returned is logically invalid. Profile analysis gets two values from the NOA table—an immediate result index and an NPI index. The immediate result index indicates that analysis should start reading results now but the NPI index indicates that another table read is required to find the correct result table index. These results are logically incompatible. Most likely, this alarm results from a failure of the underlying software or a corruption of the NOA table.	Y	This alarm typically points to an internal processing error. Capture traces and provisioning data, contact your Cisco support representative and provide this information.
< ANAL: Prof_GetFail_NPITbl_A >	Profile analysis was unable to read the A-number NPIcg table. This error occurs during Profile analysis when the NPI table is unreadable. This can be due either to the NOA table being corrupted, or to a failure in the underlying software.	Y	This alarm typically points to an internal processing error. Capture traces and provisioning data, contact your Cisco support representative and provide this information.

ResultType	DataWord1	DataWord2	DataWord3	DataWord4
57 RMODDIG	Application point	Number of digits to remove	Modification index	0 (not used)
58 R_NUMBER_TYPE	RNumberType	0 (not used)	0 (not used)	0 (not used)

Condition	Function
If the Redirecting number exists...	The NOA result (R_NBR_TYPE) will only be processed if the Redirecting Number exists in data store (call context). If there is no existing number, then the R_NBR_TYPE result will be ignored.
If the Redirecting number exists...	If the Redirecting number exists, then it will be modified according to the RMODDIG result type data. If there is no Redirecting number existing in data store (call context), then one will be created with default settings (such as NOA).
When configuring Result-sets...	It is recommended that, if you intend to create a Redirecting number and then further modify its NOA, the RMODDIG result must be defined in the Result set before the R_NBR_TYPE. If the results are defined in the reverse order then the R_NBR_TYPE result will be ignored and a Redirecting number with default settings will be created by the RMODDIG result. However, if a Redirecting number is expected to be present, then the order of defining the results will not matter.

Term	Definition
CdPn	Called Party Number (B-Number)
CgPN	Calling Party Number (A-Number)
GA	Short term for the Generic Analysis module
GN_CgPn	Generic Number_Calling Party Number
LCM	Basic Call Model Module (Also referred to as UCM or Universal Call Model)
NOA	Nature of Address
NPI	Number Plan Indicator
OCN	Original Called Number
Cisco PGW 2200	Cisco PGW 2200 PSTN Gateway (formerly called Cisco VSC 3000 and Cisco SC 2200)
SC	Signaling Controller
SW	Software
TG	Trunk Group
UCM	Universal Call Model
VSC	Virtual Switch Controller (previous name for the Cisco PGW 2200)