|
|
This appendix describes the Dial Plan Provisioning (DPP) output files required by the open packet telephony controller application.
When it is generated, a dial plan creates five tables that produce two output files:
These tables are sent to the data repository by the telephony controller application.
The telephony controller runs through a series of look-ups in these tables each time a number in your dial plan comes through it. These look-ups access the following information:
| Look-up Descriptions | |
|---|---|
Customer ID | VNET ID |
Minimum or maximum digits | Indexes: start, modification, next result |
Result type | Screening criteria |
A/B number type | Number of digits to remove |
Application point | Trunk location, name, ID, route type, route name |
Two files, dialPlan and routing, will be provisioned per customer using the following file name conventions:
<VnetID>.<version>.<dialplan>
<VnetID>.<version>.<routing>
The file formats consist of one entry per line, and spaces separate parameters. Comments can be added to the file and are preceded by a #. Comments may only appear on lines that do not contain table data.
These files are in the C:\Lightspeed\TransPathCM\DialPlan\output directory.
The dial plan system can process two types of number analysis, A and B.
Number analysis is available on both the incoming and outgoing sides of the call.
The A-Digit Tree table and B-Digit Tree table are generated based on the A-number and B-number entries specified in your dial plan. These tables consist of a series of nodes.
To view your output tables, open the output directory C:/Lightspeed/TransPathCM/DialPlan (see Figure A-1) and select the table you want to view, dial plan or routing.
The process for analyzing the called number (B-Number) only is described below. The process for analyzing the A-number is the same except that the A-Digit Tree is accessed instead of the B-Digit Tree. Tree selection is made by the gen_analysis function call to read the dial plan.
In the dial plan analysis tables, the start index determines the starting location in the table. This is usually 1 for an originating call control (OCC) query and 2 for a terminating call control (TCC) query.
The start index points to the first Tree position at which to start analyzing, so if we have startindex 1, then we begin with Tree 1 in $BdigitTree.The received called number digits are then input one at a time to read the table, so if we have digit 2 we will read line3 of Tree1 (the counting is 0,1,2,3,4,5,6,7,8,9). For clarity these are noted as follows:
column 4 | column 3 | column 2 | column 1 |
x | x | x | x |
Columns 4 and 3 are not used.
Column 2 indicates a "next pointer" that is, the next digit Tree to go to after this, If this is a Zero then analysis completes at this stage. Column 1 indicates a result pointer, which is used as a location pointer to access data from the $resultTable.
If we have a next pointer, that indicates the next Tree to go to and to read that table the next digit of the called number is input as a location pointer.
This continues until the next pointer is 0, analysis complete.
If there are no problems with your analysis, you should receive a result of Route_ID in a VSC2700 configuration. This is a route list pointer to use to analyses for Routes and Trunk Groups.
Work is now complete with the dial plan, and the code will now action the Routing analysis by reading of the Routing Plan flat file.
Each option could require up to four data words. Data words are number coded.
For routing tables, with two telephony controllers, use the IPROUTE option. IPROUTE requires a route type and name:
You can perform number analysis on either incoming or outgoing numbers.
Because all routing information is coming from the PBX (contained in PRI messages) into the telephony controller, routing number analysis is performed on outgoing numbers.
Set the following property overrides in the Signal Path on the configuration tool:
For more information about data words, see "Dial Plan Table Information."
The VSC application goes through each table until it locates the end point of each set of digits in your dial plan. The table fields are described in Table A-1.
| Column Number | Data Type | Description |
|---|---|---|
1 | ResultType | Identifies the result action that is required. |
2-5 | Data words 1 to 4 | Contents vary depending on the result type. |
6 | NextRsltIdx |
|
Example A-1 provides an output file based on the example dial plan used in this document.
$version 0 $digModStrings # Customer: TR01 # Version: 0 # Trunks: loc11, truck11, 1; loc11, truck11, 1; loc11, truck11, 1; $resultTable # Customer: TR01 # Version: 0 # Trunks: loc11, truck11, 1; loc11, truck11, 1; loc11, truck11, 1; # Results Table 20 1 1 0 0 0 20 2 2 0 0 0 20 1 3 0 0 0 20 2 2 0 0 0 20 2 2 0 0 0 20 2 2 0 0 0
For an explanation of this particular example, see Table A-2.
| Column | Number | Description |
|---|---|---|
1 | 20 is the Result Type. | 20 is IP route, which is a B-number with a Point Type of End of analysis. |
2 | 1 is Route Type. | 1 is local ATM switch (2 would be another telephony controller in your network, which would be extended ISUP) |
3 | 1 is Route Name. | The signal path for this particular telephone number (the x in the SC-x number). |
5 | 0 is the Next Result Index. | 0 indicates end of result. 1 indicates there are more results. |
6 | 0 is the Final Result Index. | This indicates the end of the analysis. |
The following table lists all available options, an example of how each option is implemented, the analysis point for each option (Intermediate/End Point), and an indication of whether the option is available for A-numbers or B-numbers or both. (See Table A-3.)
| Result Type Options (Example) | A or B or Both (AB) | Point Type1 |
|---|---|---|
0, NONE () | AB | Intermediate |
1, DIGIT_REQ (2) | B | Intermediate |
3, INC_NUMBERING (0,4,4) | B | Intermediate |
4, MODDIG (144xx) | A | Intermediate |
5, MODDIG | B | Intermediate |
6, CAUSE | B | End point |
11,CPC_REQ | AB | Intermediate |
12, CLI_REQ () | AB | Intermediate |
13, BSM_REQ () | AB | Intermediate |
14, FSM_REQ () | AB | Intermediate |
15, A_NUMBER_TYPE (1) | AB | Intermediate |
16, B_NUMBER_TYPE (1) | AB | Intermediate |
17, OTG_NUMBERING (1,4,4) | B | Intermediate |
18, BLACKLIST (1) | A | End of analysis |
19, CLI_NBR_LENGTH (1,4,4) | A | Intermediate |
20, IPROUTE (1, traffic 1) | B | End of analysis |
1Point Type refers to the point in the call flow at which this information is captured for analysis. | ||
A result table is a list of result entries indexed by VNET ID and the result index obtained from the digit tree tables. The table has six values per entry, all integers. (See Figure A-2.)
The dial plan output file contains the Results Table, A Digit Tree Table, and B Digit Tree Table as one long table. The result table is a list of result entries indexed by VNET ID and the result index obtained from the first table.
NUMBERING_PLAN_OUTGOING section.
NUMBERING_PLAN_INCOMING section.
Each node contains 10 rows and 4 columns (one column for each possible data word). Columns one and two are currently unused and are filled with 0s. An explanation of how to read these tables follows the example.
$AdigitTree # Customer: TR01 # Version: 0 # Trunks: loc11, truck11, 1; loc11, truck11, 1; loc11, truck11, 1; # node1 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 0 0 0 0 0 0 0 0 0 # node2 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 0 0 0 0 0 0 0 0 0 $BdigitTree # Customer: TR01 # Version: 0 # Trunks: loc11, truck11, 1; loc11, truck11, 1; loc11, truck11, 1; # node1 0 0 0 0 0 0 0 0 0 0 5 0 0 0 11 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0 # node2 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 0 0 0 0 0 0 0 0 0 # node3 0 0 9 0 0 0 10 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 0 0 0 0 0 # node4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 # node5 0 0 0 0 0 0 0 0 0 0 6 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 # node6 0 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 # node7 0 0 0 0 0 0 0 0 0 0 8 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 # node8 0 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 # node9 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 # node10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 # node11 0 0 0 0 0 0 0 0 0 0 12 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 # node12 0 0 0 0 0 0 0 0 0 0 0 6 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
The routing portion of the output file is shown next, followed by an explanation of how to read it.
$routing # Customer: TR01 # Version: 0 # Trunks: loc11, truck11, 1; loc11, truck11, 1; loc11, truck11, 1; 00070001 00190001 00070002
The routing portion of this output file is read as follows:
00070001 is SC-1.
00190001 is extended ISUP.
00070002 is SC-2.
Table A-4 explains the digit tree tables.
| Location | Column 1 | Column 2 | Column 3 | Column 4 |
|---|---|---|---|---|
Row Row count, row designation Does not display | Reserved | DigitToPresent: 0=Go to next digit 1=Digit application point Default is 0 | NextIdx: Index to the next node 0=End of analysis | ResultIdx: Index into a Result table 0=No result |
Row 1, #0 | Always 0 | 0 | 1 = Row 10 (Node 1) | 1 (first Result table) |
Row 2, #1 | Always 0 | 0 | 2 = Row 20 (Node 2) | 2 (second Result table) |
Row 3, #2 | Always 0 | 0 | 3 = Node 3 | 0 |
Row 4, #3 | Always 0 | 0 | 21 = Node 21 | 0 |
Row 5, #4 | Always 0 | 0 | 0 | 0 |
Row 6, #5 | Always 0 | 0 | 0 | 0 |
Row 7, #6 | Always 0 | 0 | 0 | 0 |
Row 8, #7 | Always 0 | 0 | 0 | 0 |
Row 9, #8 | Always 0 | 0 | 0 | 0 |
Row 10, #9 | Always 0 | 0 | 0 | 0 |
The VNET ID and the originating or terminating start index are used to identify a particular customer's A-Digit Tree or B-Digit Tree table and dialed digits to access. The result of this access process is to create a new index into the table for the A-Digit Tree or B-Digit Tree. This access process continues until no further A-Digit Tree or B-Digit Tree indexes are received.
If, during the process of repeatedly accessing the indexes, a result index is defined, this will cause an access to the results table where a variety of result types may be defined. If the result type indicates digit modification, then an index may be present to access the third table for digit modification strings.
All of the results obtained by accessing the A-Digit Tree or B-Digit Tree are returned by the B number analysis MDL (Message Definition Language) to the Universal Call Model for processing.
After number analysis is complete, the "RouteID" that is output from that stage is received by The Routing analysis stage. This RouteID is used as a start index to read a Route List Index table.
Step 1 The Index value is used as a location pointer to access the Route List table from which a "List of Route Indexes" is generated and saved within the gen_analysis module.
Step 2 The first Route index value is then used as a location pointer to read the Route table.
Step 3 Output from the Route table is a "List of Trunk Group Index" for the selected route.
Step 4 All Trunk Group Indexes are then selected one at a time and using this value as a pointer to the Trunk Group data table, all data is read for that Trunk group (including any Attribute data).
Step 5 The Trunk Group is interrogated against both Customer preferences (requirements for certain types of circuits) and IAM bearer preferences (also requirements for certain types of circuits).
If preferences exist but are not essential, then the Trunk Groups are sorted according to the preference criteria and are saved in a Primary or secondary list. If there are no preferences or they are essential-marked then all Trunk Group data is saved in a single Primary list. All this data is saved within the gen_analysis module.
Step 6 The first Trunk Group is now recalled (and removed from storage) and is returned to the UCM as a result from A-number, B-number, and Routing analysis. The UCM then activates the routing manager to select a circuit on this Trunk Group.
If circuit selection is successful the call continues as normal.
If there is Trunk Group congestion, the UCM will signal back to gen_analysis indicating this and gen_analysis will retrieve the next Trunk Group ID & data (and remove it from storage) and return that for circuit selection.
If the call still cannot continue, this process continues until all Trunk groups in Primary and Secondary lists have been exhausted. At the next call from the UCM, gen_analysis will find no Trunk groups stored and will go back and retrieve the next Route index (as previously stored), then repeat the earlier process for this Route to develop a new list/s of Primary/Secondary Trunk Groups and data. Then again the first one will be returned to the UCM (and removed from storage).
If all Routes have been tried and there is nothing further to offer, gen_analysis will return a result "No_Trunk_Groups_Available" to the UCM, which will clear the call with congestion indication.
The Routing analysis input is with a Route ID (or Route List ID) obtained as a result from B-number analysis. A Route List is a collection of routing alternatives that can be used to transport a call between origin and destination. Individual Routes in the list provide routing to the same destination but via different physical paths.
Routing follows a hierarchy:
1. Route list---A collection of routing alternatives (a list of Routes).
2. Route---A collection of Trunk Groups.
3. Trunk Group---A collection of circuits.
The contents of the flat file Routing Plan are described below:
For routing tables, when you have two Cisco VSC2700s, use the IPROUTE option. IPROUTE requires a route type and name.
Posted: Fri May 28 15:25:18 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.