Telephony Signaling

Document ID: 46281

PDF Downloads PGW 2200 Dial Plan

Feedback

Introduction

This document provides a brief description of the routing capabilities provided by the PGW 2200 routing sub-system in call-control mode.

Acronyms

These are the acronyms related to this document.

• CPC - Calling Party Category

• NOA - Nature of Address

• NPI - Numbering Plan Indicator

• OGW - Originating Gateway

• TGW - Terminating Gateway

• TMR - Transmission Medium Requirements

• TNS - Transit Network Selection

PGW 2200 Routing

The PGW 2200 provides a routing capability when it is used in the call-control mode. The PGW 2200 routing sub-system consists of number analysis followed by routing analysis. Number analysis is very flexible. It allows a large suite of result options to be performed with every digit analyzed.

Number Analysis

Number analysis is performed in t these four phases:

1. Pre-analysis – Analyzes the information in the received call establishment message.

2. A-number analysis – Analyzes the calling number.

3. B-number analysis – Analyzes the called number.

4. Cause analysis

Result Processing

Each digit analyzed in the number analysis is associated with one or more results that are applied to the call. Result sets are groups of results that are applied together. The result types include:

• Routing results provide links to the routing analysis stage. For example, ROUTE, COND_ROUTE, and PERC_ROUTE link to Route Lists, Time-dependent routing tables, and percentage routing tables respectively.

• A-number and B-number digit modification (for example, AMODDIG and BMODDIG).

• A-number and B-number field processing. For example, they provide the ability to process and modify number fields such as NOA, NPI, screening and presentation indicator (for example A_NUMBER_TYPE, B_NUMBER_TYPE, and CG_PRES_IND).

• Number length check (for example, CLI_NBR_LENGTH). This verifies that the correct number of A-number digits is present.

• Message parameter modification (for example, CPCMOD).

• More information requests allows the PGW 2200 to request additional information from the calling party (for example, DIGIT_REQD, CLI_REQ, CPC_REQ, BSM_REQ, FSM_REQ, and FACILITY).

• Overlap/enbloc signaling control (for example, INC_NUMBERING and OTG_NUMBERING).

• Screening results (for example, SCREENING, BLACKLIST and WHITELIST).

• Call treatment results (for example, ANNOUNCEMENT, and TESTCALLDETECTED).

• Cause treatment (for example, CAUSE and RETRY_ACTION).

• Dial plan control (for example, NEW_DIALPLAN and A_NUM_DP_TABLE). This provides the ability to switch dial-plans.

• IN processing results (for example, IN_TRIGGER, DATA_EXCHANGE, E_PORTED_NUM, and E_ROUTE_NUM).

Route Selection

Route selection offers these capabilities:

• Routing hierarchy that consists of route lists, routes, and trunk groups.

• Time conditional routing.

• Percentage routing.

• Overflow routing at percentage routing, route list, and route levels.

• Trunk group weighting.

• Carrier translation.

Figure 1: PGW 2200 Routing

Number Analysis

Number analysis is performed in these phases:

1. Pre-analysis.

2. A-number analysis.

3. B-number analysis.

4. Cause analysis.

Pre-analysis

Pre-analysis is the analysis of information in the received call establishment message. Pre-analysis is divided into these stages:

1. CPC analysis. A CPC table is configured so that CPC values received from the incoming IAM are linked to a Result.

2. TMR analysis.

3. B-number NOA and NPI analysis. NOA and NPI tables are configured so that NOA and NPI from incoming B-numbers are linked to a Result. The NOA entry can link directly to a Result or can link to a block in the NPI table.

4. TNS/carrier selection.

5. B-number normalization.

6. Result type resolution.

The results from each stage are accumulated and then performed at the end of pre-analysis. If there are duplicate results, for instance, more than one result having the same result type, then the latest result always overwrites the previous result. However, number modification results (AMODDIG and BMODDIG) are applied cumulatively at each stage of pre-analysis.

Pre-analysis results in a direct transition to route analysis if a ROUTE, COND_ROUTE, or PERC_ROUTE result is obtained.

A-number Analysis

A-number analysis includes:

• A-number digit tree analysis.

• A-number screening.

• A-number request.

B-number Analysis

B-number analysis includes:

• B-number digit tree analysis.

• B-number triggers to A-number screening.

• IN triggers.

Result Processing

Each digit that is analyzed in A-number and B-number analysis is associated with a Result Set. Each Result Set consists of one or more Results. A Result is defined by a Result Type and up to four parameters or datawords.

Result Categories

Routing

Routing results provide links to the routing analysis stage. For example, ROUTE, COND_ROUTE, and PERC_ROUTE link to Route Lists, Time-dependent routing tables, and percentage routing tables respectively.

Number Modification

Digit modification allows digits to be deleted from and inserted into A-number and B-numbers. AMODDIG and BMODDIG allow digits to be inserted or removed from any point in the A-number and B-number respectively. In pre-analysis, the digit modification is applied cumulatively. In A- and B-number analysis, digit modification is applied to the initial number input to this analysis stage.

Number Field Processing

A-number and B-number field processing provides the ability to process and modify number fields such as NOA, NPI, screening, and presentation indicator (for example, A_NUMBER_TYPE, B_NUMBER_TYPE, and CG_PRES_IND).

Number Length Check

Number length check (for example, CLI_NBR_LENGTH). This verifies that the correct number of A-number digits is present.

Message Parameter Modification

Message parameter modification (for example, CPCMOD).

More Information Request

More information requests allow the PGW 2200 to request additional information from the calling party (for example, DIGIT_REQD, CLI_REQ, CPC_REQ, BSM_REQ, FSM_REQ, and FACILITY).

Overlap Signaling

Overlap/enbloc signaling result types INC_NUMBERING and OTG_NUMBERING control whether enbloc or overlap signaling is to be used on the incoming and outgoing trunk groups. The minimum and the maximum expected number lengths is also specified.

Screening

Screening results (for example, SCREENING, BLACKLIST, and WHITELIST).

Call Treatment

Call treatment results (for example,ANNOUNCEMENT and TESTCALLDETECTED).

Cause Treatment

Cause treatment (for example, CAUSE and RETRY_ACTION).

Dial Plan Control

Dial plan control (for example, NEW_DIALPLAN and A_NUM_DP_TABLE). This provides the ability to switch dial-plans.

IN Processing

IN processing results (for example, IN_TRIGGER, DATA_EXCHANGE, E_PORTED_NUM, and E_ROUTE_NUM).

Result Types

This table shows the Result Types. The letters in the 'Valid for' column are A = A-analysis, B = B-analysis, P = Pre-analysis and C = Cause analysis.

Table 1: Result Types and Analysis

Each Result Type requires zero or more parameters or datawords as shown in this table:

Table 2: Result Types

A result entry cannot be deleted if its index is associated with any other table. In this version, this table is referenced from the NOA, NPI, Cause, Location, and Digit Tree tables. When a result is not assigned, it is defaulted to zeros in every column. A result type of NONE means that the result is not set.

MML Command

This is a list of MML commands:

• resultset – Used to add a result set.

• resulttable – Used to add a result.

Dial Plan Provisioning Example

The Dial Plan provisioning example given here creates these result types:

Table 3: Dial Plan Provisioning Example

prov-sta:srcver="new",dstver="session1"
numan-add:dialplan:custgrpid="t1"
numan-add:service:custgrpid="t1",name="Washington"
numan-add:service:custgrpid="t1",name="FreePhone"
numan-add:service:custgrpid="t1",name="TollLine"
numan add:digmodstring:custgrpid="t001",name="mod1",digitstring="703484"

numan-add:resultset:custgrpid="t1",name="set1"
numan-add:resulttable:custgrpid="t1",name="r1",resulttype="SCREENING",
dw1="1",dw2="Washington",setname="set1"

numan-add:resultset:custgrpid="t1",name="set2"
numan add:resulttable:custgrpid:"t1",name="r1",resulttype="ANNOUNCEMENT",
dw1="100",dw2="1",dw3="rtlist1",setname="set2"

numan-add:resultset:custgrpid="t1",name="set3"
numan-add:resulttable:custgrpid="t1",name="r1",resulttype="IN_TRIGGER",
dw1="1",dw2="1",setname="set3"

numan-add:resultset:custgrpid="t1",name="set4"
numan-add:resulttable:custgrpid="t1",name="r1",resulttype="A_NUMBER_TYPE",
dw1="5",setname="set4"
numan-add:resulttable:custgrpid="t1",name="r2",resulttype="BLACKLIST",
dw1="1",setname="set4"

numan-add:resultset:custgrpid="t1",name="set5"
numan-add:resulttable:custgrpid="t1",name="r1",resulttype="BMODDIG",
dw1="1",dw2="1",dw3="digmod1",setname="set5"

numan-add:resultset:custgrpid="t1",name="set6"
numan-add:resulttable:custgrpid="t1",name="r1",resulttype="B_NUMBER_TYPE",
dw1="3",setname="set6"

numan-add:resultset:custgrpid="t1",name="set7"
numan-add:resulttable:custgrpid="t1",name="r1",resulttype="INC_NUMBERING",
dw1="0",dw2="4",dw3="4",setname="set7"

numan-add:npi:custgrpid="t1",npiblock=1,setname="set3"
numan-add:noa:custgrpid="t1",noavalue=1,npiblock=1
numan-add:location:custgrpid="t1",locationblock=1,setname="set5"
numan-add:cause:custgrpid="t1",causevalue=1,locationblock=1

numan-add:bdigtree:custgrpid="t1",callside="originating",
digitstring="703484",setname="set1"
numan-add:bdigtree:custgrpid="t1",callside="originating",
digitstring="301555",setname="set2"
numan-add:bdigtree:custgrpid="t1",callside="originating",
digitstring="301684",setname="set3"
numan-add:bdigtree:custgrpid="t1",callside="originating",
digitstring="40555", setname="set4"

Route Analysis

Route Analysis is entered when these Result types are encountered:

• ROUTE

• COND_ROUTE

• PERC_ROUTE

• TERM_INFO

The routing process is based on a hierarchy that consists of these entities:

1. Percentage routing tables

2. Conditional routing tables

3. Route lists

4. Routes

5. Trunk Groups

Figure 2: Route Analysis

Route Lists

A Route List is a group of one or more routes. The routes in the list can be accessed sequentially or randomly based on a distribution parameter associated with the Route List. Each Route entry in a Route List includes these:

• Indexes into the Route table.

• Indexes to the next route in the Route List. This defines the order in which routes are selected . It is only used for sequential access.

• Route distribution control: sequential or random.

MDL Tables

The MDL Table is $routeList.

MML Command

The MML command is rtlist.

Routes

Trunk routes are a group of Trunk Groups. Each Route includes these attributes:

• A list of Trunk Groups in the Route that consists of indexes into the Trunk Group table.

• An index to the next Trunk Group in the Route. This defines the order of Trunk Groups in the Route. This is not used if Trunk Group weighting is enabled.

• Trunk Group weighting.

A form of percentage based routing is implemented at the route level by adding the same Trunk Group to a Route multiple times. Trunk weighting is enabled if Trunk Group weighting is on. The associated Route List must have random distribution on. The maximum number of Trunk Groups in a Route is 100 if Trunk Group weighting is enabled.

MDL Tables

• $routeName – Defines the Routes.

• $trunkRoute – Defines the Trunk Groups in the Route.

MML Command

The MML command is rttrnk.

Trunk Groups

Trunk Groups define a set of PSTN trunks or an IP trunk. A Trunk Group is defined by several tables:

• Trunk Group table.

• TDM attributes table.

• SIP attributes table.

MDL Tables

• $trunkGroup

• $TDMAttributes

• $SIPAttributes

MML Command

The MML command is rttrnkgrp.

Time Conditional Routing Table

Time Conditional Routing tables are used to control time-dependent routing. Time Conditional Routing is defined by several tables:

• Conditional Route Name table – Defines conditional routes. There is one entry for each time conditional route which has an index to a block in the Conditional Route table.

• Conditional Route table – Defines Day of Week (DoW) blocks for each conditional route. Each block has 10 entries (default, Monday-Sunday, HOL1-HOL3). This is an index to the Conditional Route Descriptor table.

• Conditional Route Descriptor Name table – Defines sets of time bands. Each entry is an index into the start of a set of time bands in the Conditional Route Descriptor table.

• Conditional Route Descriptor table – Defines time bands and associated routes. Each entry is a single time band with its associated route (to either a Route List or a Percentage Route table).

The Conditional Route table is used to retrieve indexes into the Conditional Route Descriptor tables. These are used for days of the week and three holidays: default, Monday-Sunday, HOL1 – HOL3. The Conditional Route table is indexed with the DoW index or a Holiday index (HOL1 – HOL3). The Holiday index is obtained from the Route Holiday table which associates dates with three Holidays (HOL1 – HOL3).

The Conditional Route Descriptor table defines time bands that are active for each associated route. Each route entry in a Conditional Route Descriptor table has these:

• StartTime: This specifies the start of the time band for the route.

• NextIdentityType: The route entries are 1 = RouteList index and 2 = Percentage Route Table index.

• NextIdentifyIndex: Index into the Route List or Percentage Route table.

• NextIndex: The next index into this table – link to the next route in the Conditional Route Descriptor table.

MDL Tables

• $condRte

• $condRteDesc

Figure 3: Time Conditional Routing

MML Commands

• condrte

• condrtedesc

• rteholiday

Conditional Routing Provisioning Example

Add entries to the Route Holiday table:

numan-add: rteholiday: custgrpid=”t2”, date=”2001.12.25”, hday=”hol1”
numan-add: rteholiday: custgrpid=”t2”, date=”2001.01.01”, hday=”hol1 ”
numan-add: rteholiday: custgrpid=”t2”, date=”2001.07.04”, hday=”hol2 ”
numan-add: rteholiday: custgrpid=”t2”, date=”2001.09.03”, hday=”hol3”

The Conditional Routing Processing actions that derive from the above MML commands are:

• For Christmas Day and New Years Day, Conditional Routing uses the HOL1 day of the week.

• For Independence Day, the Conditional Routing uses the HOL2 day of the week.

• For Labor Day the Conditional Routing uses the HOL3 day of the week.

Add conditional routes and conditional route descriptions as seen here:

prov-add:condrtedesc:name="desc1", rtlistname=” set22”
prov-add: condrte: name =”cond20”, dow=”default”, condrtedesc=”desc1”
prov-add:condrtedesc:name="desc2", rtlistname=” set21”
prov-ed:condrtedesc:name="desc2", starttime=”0800”,endtime=”1800”, rtlistname=”set22”
prov-ed:condrtedesc:name="desc2", starttime=”1800”,endtime=”2345”, rtlistname=”set24”

prov-ed: condrte: name =”cond20”, dow=”monday”, condrtedesc =”desc2”
prov-ed: condrte: name =”cond20”, dow=”tuesday”, condrtedesc =”desc2”
prov-ed: condrte: name =”cond20”, dow=”wednesday”, condrtedesc =”desc2”

prov-add:condrtedesc:name="desc3", rtlistname=” set23”
prov-ed: condrte: name =”cond20”, dow=”hol1”, condrtedesc =”desc3”
prov-ed: condrte: name =”cond20”, dow=”hol2”, condrtedesc =”desc1”

prov-add:condrtedesc:name="desc4", rtlistname=” set22”
prov-ed:condrtedesc:name="desc4", starttime=”1200”,endtime=”1800”, rtlistname=”set55”
prov-ed:condrtedesc:name="desc4", starttime=”1800”,endtime=”2345”, rtlistname=”set22”
prov-ed:condrte: name =”cond20”, dow=”hol3”, condrtedesc =”desc4”

This shows how to configure the COND_ROUTE results making the association with the data in the Conditional Routing table previously defined:

numan-add:resulttable: custgrpid="t2", name="result39",
 resulttype="cond_route", dw1=" cond20", setname="condsetname"

Conditional Routing Processing actions that derive from the above MML commands are :

• On Monday, Tuesday and Wednesday

  From 0000-0800 the Routing option is a result set "set21". This provides RouteList21 as the entry point into Routing analysis. From 0800-1800 the Routing option is result set "set22". This provides Routelist22 as the entry point for Routing analysis. From 1800-2345 the Routing option is result set "set24". This provides RouteList24 as the entry point into Routing analysis.

• On a Holiday of type "HOL1"

  From 0000-2345, the Routing option is "set23". This provides RouteList23 as the entry point into Routing analysis.

• On a Holiday of type "HOL2"

  From 0000-2345, the Routing option is "set22". This provides RouteList22 as the entry point into Routing analysis.

• On a Holiday of type "HOL3"

  From 0000-1200, the Routing option is result set "set22". This provides RouteList22 as the entry point into Routing analysis. From 1200-1800, the Routing option is result set "set55". This provides Routelist55 as the entry point for Routing analysis. From 1800-2345, the Routing option is result set "set22". This provides RouteList22 as the entry point into Routing analysis.

• On a Default case

  The Routing for any undefined Days is Thursday, Friday, Saturday, and Sunday. From 0000 – 0800, the Routing option is result set "set22". This provides Routelist22 as the entry point for Routing analysis. From 0800-2345, the Routing option is result set "set55". This provides Routelist55 as the entry point for Routing analysis.

Percentage Routing Table

Percentage routing is defined by two tables:

• Percentage Route Name table – Defines the percentage routes. There is one entry for each percentage route. It has an index into the Percentage Route table.

• Percentage Route table – Defines the percentage load quota for each Route List or Conditional Route table.

Each route entry in a Percentage Route table has these:

• Percentage load – Quota for this route.

• Overflow enabled (ovflwset) – If the route is unavailable, this indicates whether overflow to the next route is allowed.

• Overflow only (overflow) – Indicates that the route is only used for overflow if all other routes in the percent route are unavailable.

• NextIdentityType - The variables for this are 1 = RouteList index and 3 = Conditional Route Table index.

• NextIdentifyIndex - The index into the Route List or Conditional Route table.

• NextIndex - The next index into this table. – This is a link to the next route in the Percentage Route table.

MDL Tables

• $percRteName

• $percRteTable

MML Command

The MML command is percrte.

Percentage Based Routing Examples

When the first entry is added to a percentage based route name, the load parameter is not provisioned as the percentage is defaulted to 100 percent. As other entries are added, the value is adjusted to accommodate the new percentage values that are added. The maximum value can be 100 percent and the minimum value is 0 percent. When the second command is entered, the primary entry is modified to 75 percent. When the third command is entered, the primary entry is modified to 50 percent.

prov-add:percrte:name="one", rtlistname=”one”, ovrflwset=”ON”, primary=”ON”
prov-ed:percrte:name="one", rtlistname=”three” ,load=25
prov-ed:percrte:name="one", condrtename=”todtwo” ,load=25
prov-ed:percrte:name="one", condrtename=”todthree” ,overflow=”ON”

This results in 50 percent traffic load allocated to Route List 'one', 25 percent to Route List 'three', and 25 percent to Conditional Route name 'todtwo'. Conditional Route 'todthree' is used only as an overflow route.

Overflow Routing

Overflow routing is applied at the Percentage Route, Route List, and the Route levels.

Percentage Route Overflow

Overflow routing is enabled or disabled at the percentage routing level. Overflow at the percentage route level is configured in one of these two ways:

• Overflow between routes (Route Lists or Conditional Route tables) that are part of the normal percentage routing. This is enabled with the help of the 'ovflwset' flag.

• Overflow to a separate route (Route List or a Conditional Route table) that is reserved exclusively for overflow. This is enabled with the help of the 'overflow' flag.

An example configuration is shown here. Route List 1 and the Conditional Route table are used for normal percentage routing and overflow conditions. Route List 2 is only used when both Route List 1 and the Conditional Route table are unavailable.

Figure 4: Percentage Route Table Overflow

North American LNP

Note: There are result types that support North American All Calls Query (ACQ), LNP procedures, and also European Onward Routing (OR) procedures.

The PGW 2200 supports the donor network, transit network, and recipient network procedures.

Figure 5: North American LNP All Calls Query

Originating/Transit Network Procedures

North American ACQ at the origination or transit network is supported with the help of the IN_TRIGGER result type. This causes an LNP Query to be sent to Number Portability Database (NPDB) to determine if it is a number that has been ported. If the number has been ported, then the LNP response contains a routing number (RN) that is placed in the Called Party Number parameter. The original dialed number (DN) is stored in the Generic Number parameter.

Recipient Network Procedures

Recipient network procedures are supported with the help of the DATA_EXCHANGE result type. This uses the contents of the Generic number parameter to be copied to the B-number. The B-number analysis is then re-entered to route the call to the destination switch. The Home RN for the destination network is configured to have a DATA_EXCHANGE result type.

European LNP

Note: There are result types that support North American ACQ LNP procedures and also European OR procedures.

The PGW 2200 supports the donor network, transit network, and recipient network procedures.

Figure 6: European LNP Onward Routing

Donor Network Procedures

The result type E_PORTED_NUM triggers an access to a local number portability database to retrieve the routing number (RN). The PGW uses the Q.769.1 Concatenated Address method to prepend the RN to the Called Party Number. The PGW then sets the NOA of the Called Party Number parameter to the 'Concatenated number' and re-enters B-number analysis to route the call to the recipient network with the help of the RN.

Recipient Network Procedures

The result type E_ROUTE_NUM causes the PGW 2200 to remove the leading RN digits from the called number. It sets the NOA to 'national number,' and then reads the number termination table to retrieve the route to the destination switch.

Dial Plan File

This section explains the format of the digit modification, results, digit trees and routing MGC dial plan tables. In this version there are two files for a set of customer plans generated. This file contains the digit modification, resultTable, and the two digitTree tables. The naming convention of this file is <CustomerGroupID>.dialplan. The CustomerGroupID is a four alphanumeric string that is defined for each set of dial plan files.

Field Formats

digitTree

This table always gets generated as blocks of ten to represent the digits 0-9.

Table 4: digitTree

resultTable

Table 5: resultTree

DigModString

Table 6: digModString

NOA

Table 7: NOA

NPI

Table 8: NPI

Cause

Table 9: Cause

Location

Table 10: Location

Service

Table 11: Service

ResultSet

Table 12: ResultSet

DefaultResultSet

Table 13: DefaultResultSet

dpselection

Table 14: dpselection

dpBase

Table 15: dpBase

NotypeNodes

Table 16: NotypeNodes

routeHoliday

Table 17: routeHoliday

Examples

#format4
$version 2

$dpbasebb
10

$digModStrings
# Customer: T002
#digString
#digMod1  digname
9

$resultTable
# Customer: T002
#type       dw1    dw2    dw3    dw4    nextResult
# result1      result2
2           1      0      0      0      2
# result2      result1
23          1      1      0      0      0
# result3      result1
4           1      3      1      0      0
# result4      result1
4           1      2      0      0      0
# result5      result1
16          3      0      0      0      0
# result6      result1
8           100    1      1      0      0

$resultSet
# Customer: T002
#set                startIndex
setone              1
settwo              3
setthree            4
setfour             5
setfive             6

$defaultResultSet
# Customer: T001
#resultType  dw1  dw2  dw3  dw4
2            1    0    0    0  

$NoBNodes
16

$BdigitTree
# Customer: T002
#digitsToPresent      nextNode   resultIndex
# node1
0	0	0
0	0	0
0	0	0
0	2	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
# node2
0	0	0
0	0	0
0	0	0
0	3	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
# node3
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	4	0
0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
# node4
0	0	0
0	0	0
0	0	0
0	0	1
0	0	2
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0

$routing
# Customer: T002
#routeGroup

$NPI
# Customer: T002
#resultIndex
# block1
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5

$NOA
# Customer: T002
#NPIIndex  resultIndex
0

$routeHoliday
# Customer: T002
# Date      Holiday_Index
20011225    8
20010101    8
20010704    8
20010903    10

$location
# Customer: T002
#resultIndex
# block1
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6

$cause
# Customer: T002
#locationIndex  resultIndex
0

$service
# Customer: T002
#serviceName
TollFree

$dpselection
# Customer: 001
#CustomerGroupId
T001
T002

MML Provisioning Components

Routing

This section is used to configure the routing file. This section is subdivided into Routing Trunk Group (RTTRNKGRP), Trunk Route (RTTRNK), and Route List (RTLIST) .

Please note that the .dat file affected is routeAnalysis.dat.

• To add/modify/delete the contents of a routing table, an active provisioning session is required. (refer to the EMS High-Level Design document for provisioning session MML commands). At the time of deploy/copy, routing files from the provisioning directory are copied to the active directory. The active directory for the routing file is /opt/CiscoMGC/etc.

• All the TIDs except CARRIERTBL and ROUTING need a name. It is only possible (at present) to retrieve against a name.

• All the Carrier table, Route lists, Route trunks, and Route trunk groups information are retrieved with the help of the prov:rtrv :rtlist:"ALL" command. The ALL option is not used with other parameters.

• The NEXTRTNAME parameter is used to change the order of Routes in the Route list. If it is not specified when a Route is added to a Route list, the routes are added in the order they are entered. It is only valid for use when modifying the Route list.

• The NEXTRKGRP parameter is used to change the order of Trunk Groups in the Route. If it is not specified when a Trunk Group is added to a Route, the Trunk Groups are added in the order they are entered. It is only valid for use when modifying the Route list.

• The CARRIERID is removed from the RTLIST in Esprit.

• The ROUTING TID provides the functionality to add and delete a routing file. When performing adds, if there is currently no routing file, it creates one, otherwise it creates an error. During a delete, if a routing file exists, it deletes it, otherwise it creates an error. Edits are not supported for this TID. For CARRIERTBL, it is only valid to use the RTLISTNAME with the RTOPTION "CARRIER".

• It is mandatory that the first entry added to a conditional route has the day of week as default so that a default value is always set for all conditional Routes. For all days of the week, the user enters as the first value in the set a conditional Route name. This is followed optionally by up to four pairs of time change and conditional route names. The time changes are configured in the range 0015 to 2345 and must be divisible by 15 minutes. There is a check to ensure that the times are only added in ascending order.

Routing Trunk Group

This section is used to configure the Routing Trunk group. The MML Component Name is RTTRNKGRP.

Table 18: rtTrnkGrp

SIP Routing Trunk Group

This command is used to configure the SIP Routing Trunk Group. The MML Component Name is SIPRTTRNKGRP.

Table 19: SIPrtTrnkGrp

Bearer Capability

This section is used to configure the Bearer Capability. The MML Component Name is BEARERCAP.

Table 20: bearerCap

Codec String

This section is used to configure the codec string . The MML Component Name is CODECSTRING.

Table 21: codecString

Route

This section is used to configure the Trunk Route. The MML Component Name is RTTRNK.

Table 22: rtTrnk

Route List

This section is used to configure the Route List. The MML Component Name is RTLIST.

Table 23: rtList

Carrier Table

This section is used to configure the carrier translation table. The MML Component Name is CARRIERTBL.

Table 24: carrierTbl

Time Conditional Routing Table

The MML Component Name is CONDRTE.

Table 25: condRte

The MML Component Name is CONDRTEDESC.

Table 26: condRteDesc

Percentage Based Route Table

This section is used to configure the percentage route table. The MML Component Name is PERCRTE.

Table 27: PERCRTE

Dial Plan

All components have a name parameter, which is the MML name, and a description, which is a text description. The dial plan provisioning is contained in the file <customer group ID>.dialPlan where the customer group ID is four alphanumeric characters.

This is the generic format of the MML dial plan commands: NUMAN-<VERB>:<TID>:CUSTGRPID=<customer group ID>, INDEX=<index>, <PARAM_NAME> = <param value>

Table 28: Dial Plan

• To add/modify/delete the contents of a dial plan table, an active provisioning session is required (refer to the EMS High-Level Design document for provisioning session MML commands). At the time of deploy/copy, dial plan files from the provisioning directory are copied to the active directory. The active directory for dial plan files is /opt/Transpath/dialPlan.

• All the TIDs except DIALPLAN need customer group ID and a name. DIALPLAN needs customer group ID only. The verb ED is not used with the DIALPLAN. The verb RTRV is used with DIALPLAN to determine all of the Dial Plans currently configured. In the Elan drop 4 time frame, the result table and the result set supports the name only, and not the index to refer to the entry.

• The routes and digit modification string table should be provisioned before the result and digit tree tables.

• When an index is added to a table, the missing indices are also added with default values. For example, if index 10 is added to a digit tree table, and indices 4-9 are missing, they are added with default values.

• When an index is deleted from a result or digit tree table, all the elements in the index are made zero. When an index is deleted from routes or the digit modification string table, all the elements in the index are made 'x'. When an index is deleted from any table and if there are no indices with non-default values that follow this index, all the indices that follow this index are deleted.

• The modify command is not supported for result sets as modifications are done at the result table level.

• The modify command is not supported for the service table.

• When an entry is added to the result table, the corresponding entry is added to the result set table.

• When an entry is deleted from the result set table, the corresponding entries are deleted from the result table.

• The index is no longer required to perform any operations on the result table, service table, or digit modification table.

• The result set is not modified for a result table.

• The TIDs Dial Plan, RESULTTABLE, DIGMODSTRING, NOA, NPI, CAUSE, LOCATION, SERVICE, and RESULTSET support the ability to retrieve all entries in the table by specifying ALL. For example, numan-rtrv:resultset:custgrpid="T001","all".

• The TIDs ADIGTREE and BDIGTREE support the ability to retrieve all entries in the table by either not specifying a digit string or specifying an empty digit string. For example, numan-rtrv:adigtree:custgrpid="T001",digitstring=""

• Configuring a result set as the default result set replaces the previous one.

• The default result set has only one of the following result types: BLACKLIST, ROUTE, or CAUSE.

Cisco Support Community - Featured Conversations

Related Information

• Voice Technology Support
• Voice and Unified Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support - Cisco Systems