|
|
This chapter describes how to plan for system configuration. Before you can configure the system, you must determine the following:
The software release version installed in the Cisco MGC will determine the steps that you will take for the tasks described in this chapter. Currently software Release 7.3(x), also called Drop 3, and software Release 7.4(x), also called Drop 4, are discussed in this chapter. Differences in the software release version are described in the text where they occur. These differences include the number of characters used to define a MML name. You can use as many as 10 alphanumeric characters for software Release 7.3(x) and as many as 20 alphanumeric characters for software Release 7.4(x).
The majority of the software release version differences involve the dial plan. You will find a separate section describing the software Release 7.3(x) dial plan ("Creating a Dial Plan for Release 7.3(x)" section) and a separate section describing the software Release 7.4(x) dial plan ("Creating a Dial Plan for Release 7.4(x)" section).
Differences in the software release versions affecting provisioning for the TCM operation, the CMM operation, and the MML operation are described respectively in "TCM Provisioning Procedures for Release 7.3(x)," "CMM Provisioning Procedures for Release 7.4(x)," and "Configuring with MML."
This chapter describes the following tasks:
The order in which you configure components is important. Many components refer to other components that must be defined first. When you create the components described in this chapter, be sure to create them in the order described in this chapter.
 |
Note The virtual switch node can use two Cisco MGC hosts for maximum availability. The differences in the active and standby media gateway controllers (MGC) are defined in the XECfgParm.dat file, which is configured during software installation. The configuration planned in this chapter applies to both of the Cisco MGC hosts. You create one configuration for one exchange and apply that configuration to both Cisco MGC hosts. |
 |
Tips This chapter provides blank tables you can use to plan the configuration components. While some tables provide room to define many components, other tables allow you to plan just one component. Before you start your planning, copy the tables and write on the copies. This way, you can make additional copies later if you need them. |
Figure 2-1 shows the software components that must be configured to connect the Cisco MGC to an external switch.
Figure 2-2 shows the order in which the components shown in Figure 2-1 must be configured.
To configure routes between the Cisco MGC and a destination device (for example, a switch), you must do the following:
Step 2 Define linksets.
Step 3 Override linkset properties (if necessary).
Step 4 Define an SS7 subsystem for each pair of STPs.
Step 5 Define an SS7 signaling service to support the signaling route.
Step 6 Override the SS7 signaling service properties (if necessary).
Step 7 Define the SS7 signaling route.
The first step in planning signaling routes is to identify the SS7 network devices that link the Cisco MGC to remote switches. To identify these network devices, you must configure the point codes (see Table 2-1 for a list of point code parameter descriptions), which serve as SS7 network addresses. The point codes must be unique within the SS7 network. You must get these point codes from your SS7 network administrator.
Point codes are necessary for the following network devices:
When configuring a Cisco MGC, you must enter a point code and a point code type for each Cisco MGC, along with the network address and the network indicator. The point code type is OPC and the point code address is a value in the format x.x.x. For example, 8.232.72. The two periods separating the three numeric labels are required, and the numeric labels must be entered in decimal values. If your service provider issues these numbers using binary or hexadecimal values, you must convert them to decimal.
|
Note The point code examples used in this document follow the ANSI SS7 point code format. |
For configuring point codes for remote switches, the point code type is DPC. Each point code for an STP is an APC, and the STP point code type is APC. The point code values for DPCs and APCs use the same format (x.x.x) as for OPCs.
To define SS7 network addresses, you must configure the following component types:
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | MML Name | Unique name for this point code. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
NETADDR | Network Address | SS7 network address in dotted notation. |
NETIND | Network Indicator | The network indicator assigned by the network administrator. |
DESC | Description | Text description of this point code. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | NETADDR | NETIND | DESC |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| NAME | NETADDR | NETIND | DESC |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After you determine the point codes for your network devices, you must define the linksets that connect each MGC node directly to a remote switch or indirectly through an STP. A linkset is the group of all communication links connecting an MGC node to a specific SSP or STP. When two STPs are defined as mates within the Cisco MGC Software, the Cisco MGC can use either linkset to connect to the SS7 signaling network.
Table 2-4 lists the configuration parameters you must define for each linkset, and Table 2-5 serves as a form that you can use to define linksets.
To define linksets, you must configure the following component types:
|
Note When configuring linksets for STP connections, you will usually configure two linksets for each pair of STPs. |
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | MML Name | Unique name for this linkset. Enter as many as 10 characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
APC | Adjacent Point Code/Point Code | Adjacent point code or destination point code. For linksets that connect directly to an SSP, enter the MML name of a previously defined destination point code. For linksets that connect to a Cisco SLT, enter the MML name of a previously defined adjacent point code. |
TYPE | Transport Type | Enter TDM for linksets that connect directly to an SSP, or enter IP for linksets that connect to Cisco SLTs. The default is TDM. |
PROTO | Protocol Family | Enter one of the following:
|
DESC | Description | Text description of this linkset. Enter as many as 128 characters and enclose in straight quotes. |
| Name | APC or DPC | Type | Proto | Desc |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Linkset properties serve as additional configuration parameters you can use to tune linkset communications. Table 2-6 lists the default properties assigned to linksets. These properties apply to all linksets you create. You do not have to enter these values.
To change linkset properties, you must configure the following component types:
| MML Parameter Name | Default Value | Units | Description | ||
|---|---|---|---|---|---|
mtp2AermEmgThr | 1 | messages | Alignment error rate monitor threshold duration for emergency operation. Value: 1 message. | ||
mtp2AermNrmThr | 4 | messages | Alignment error rate monitor threshold duration for normal operation. Value range: 1 through 4 messages. | ||
mtp2CongDiscard | false |
| Discard frames upon entering congestion at MTP2. Set to true or false. | ||
mtp2LssuLen | SS7-ANSI=1 | octets | Link status signal unit, status field length. Specify either 1 or 2. | ||
mtp2MaxAlignRetries | 5 | attempts | Maximum number of attempts to align link before declaring it Out-of-Service (OOS). Value range: 1 through 10 attempts.
| ||
mtp2MaxMsuFrmLen | 272 or 62 | octets | Maximum frame length of a C7 message signal unit. Specify 62 or 272. | ||
mtp2MaxOutsFrames | 127 | frames | The maximum outstanding frames that can be sent without receiving acknowledgment. Value range: 1 through 127. | ||
mtp2ProvingEmgT4 | SS7-ANSI=6 | tenths of a second | Emergency proving period. Value range: 5 through 7 tenths of a second. | ||
mtp2ProvingNormalT4 | SS7-ANSI=23 | tenths of a second | Normal proving period. Value range: 1 through 3 seconds. | ||
mtp2SuermThr | 127 | frames | Signal unit error rate monitor threshold for emergency operation. Value range: 1 through 127. | ||
| |||||
mtp2T1 | SS7-ANSI=130 | tenths of a second | Maximum period in Aligned/Ready state before return to Out-of-Service state. Value range: 12 through 16 seconds (for ANSI) or 40 through 50 seconds (for BT, CHINA, and ITU). | ||
mtp2T2 | SS7-ANSI=115 | tenths of a second | Maximum period in Not Aligned state before return to Out-of-Service state. Value range: 5 through 30 seconds. | ||
mtp2T3 | SS7-ANSI=115 | tenths of a second | Maximum period in Aligned state before return to Out-of-Service state. Value range: 5 through 14 seconds (for ANSI) or 1 through 2 seconds (for BT, CHINA, and ITU). | ||
mtp2T5 | 1 | thousandths of a second | Period for sending a SIB1 message to far-end. | ||
mtp2T6 | SS7-ANSI=30 | tenths of a second | Remote congestion timer. If congestion is not cleared before expiration of this timer, the link fails. Value range: 1 through 6 seconds (for ANSI) or 3 through 6 seconds (for BT, CHINA, and ITU). | ||
mtp2T7 | SS7-ANSI=24 | tenths of a second | MTP2 acknowledgment timer. On expiration, the link fails and an "excessive delay of acknowledgment" management message is generated. Value range: 0.5 through 2 seconds (for BT, CHINA, and ITU). | ||
| |||||
mtp3ApcMtpRstrtT28 | SS7-ANSI=50 | tenths of a second | Overall restart timer for signaling point adjacent to one whose MTP restarts. Value range: 3 through 35 seconds (for ANSI only). | ||
mtp3DlnkConnAckT7 | SS7-ANSI=10 | tenths of a second | Waiting for signaling data link connection acknowledgment. | ||
mtp3FrcUnhT13 | SS7-ANSI=10 | tenths of a second | Waiting for force uninhibited. Value range: 0.8 through 1.5 seconds. | ||
mtp3InhAckT14 | SS7-ANSI=20 | tenths of a second | Waiting for inhibit acknowledgment. Value range: 2 through 3 seconds. | ||
mtp3LocInhTstT20 | SS7-ANSI=900 | tenths of a second | Waiting to repeat local inhibit test. | ||
mtp3MaxSltTries | SS7-ANSI=2 | messages | Maximum number of retries of signaling link test message. If MTP3 does not receive a response after two signaling link test messages, the system fails the link. Value range: 1 through 5. | ||
mtp3MsgPriority | SS7-ANSI=2 |
| Message priority of management messages for congestion periods. | ||
mtp3MtpRstrtT20 | SS7-UK=900 | tenths of a second | Overall MTP restart timer at the signaling point whose MTP restarts. Value range: 59 through 61 seconds.
| ||
mtp3ApcMtpRstrtT21 | SS7-UK=640 | tenths of a second | Overall MTP restart timer at an SP adjacent to an SP whose MTP restarts. Value range: 63 through 65 seconds.
| ||
mtp3LocInhTstT22 | SS7-UK=3000 | tenths of a second | Waiting to repeat local inhibit test. | ||
mtp3MtpRstrtT24 | SS7-ANSI=60 | tenths of a second | Overall MTP restart timer for local MTP restart. Value range is network-dependent. | ||
mtp3RepeatRstrtT26 | SS7-ANSI=150 | tenths of a second | Traffic restart waiting message at local MTP restart. | ||
mtp3TfrUsed | SS7-ANSI=false | true/false | Transfer restricted procedure is enabled (true) or disabled (false). Set to true or false. | ||
mtp3TraSnT29 | SS7-ANSI=600 | tenths of a second | Timer started when traffic restart allowed is sent in response to unexpected traffic restart allowed or traffic restart waiting. | ||
mtp3tstSltmT1 | SS7-ANSI=60 | tenths of a second | Waiting for signaling link test acknowledgment message. This must be greater than the value in mtp2T6. Value range: 4 through 12 seconds. | ||
mtp3tstSltmT2 | SS7-ANSI=600 | tenths of a second | Interval for sending signaling link test message. | ||
mtp3UnhAckTl2 | SS7-ANSI=10 | tenths of a second | Waiting for uninhibited acknowledgment. | ||
mtp3T0 | SS7-NTT (or SS7-Japan)=200 | tenths of a second | Not used. | ||
mtp3T7 | SS7-NTT (or SS7-Japan)=20 | tenths of a second | Waiting for signaling data link connection acknowledgement. Value range: 1 through 20 seconds. | ||
mtp3T12 | SS7-NTT (or SS7-Japan)=0 | tenths of a second | Waiting for signaling data link connection acknowledgement. Value range: 500 through 1500 milliseconds. | ||
mtp3T13 | SS7-NTT (or SS7-Japan)=0 | tenths of a second | Same as mtp3FrcUnhT13. | ||
mtp3T14 | SS7-NTT (or SS7-Japan)=0 | tenths of a second | Same as mtp3InhAckT14. | ||
mtp3T20 | SS7-NTT (or SS7-Japan)=0 | tenths of a second | Same as mtp3MtpRstrtT20. | ||
mtp3T21 | SS7-NTT (or SS7-Japan)=0 | tenths of a second | Same as mtp3ApcMtpRstrtT21. | ||
mtp3T22 | SS7-NTT (or SS7-Japan)=0 | tenths of a second | Same as mtp3LocInhTstT22 | ||
reference | SS7-ANSI=ANSI96 |
| Denotes versions for protocol standards supported for MTP. | ||
rudpAck | enable |
| Not used. | ||
rudpKeepAlives | enable |
| Not used. | ||
rudpNumRetx | 2 |
| The maximum number for Retransmission count. | ||
rudpWindowSz | 32 |
| The maximum number for Unacknowledged Segments in the RUDP window. | ||
rudpRetxTimer | 6 | tenths of a second | The Retransmission timeout. Value range: 2 through 100. | ||
rudpSdm | enable |
| Not used. | ||
| 1SIB = Status indication busy |
In the Cisco MGC, an SS7 subsystem is used to mate two STPs or to define SS7 subsystems that access IN services. When two STPs are defined as mates within the Cisco MGC Software, the software can use either STP for communications with an external switch. Table 2-7 lists the configuration parameters you can use to configure an SS7 subsystem, and Table 2-8 serves as a form that you can use to plan for the SS7 subsystems.
|
Note You must define one SS7 subsystem for each STP to which the MGC node connects. |
To define an SS7 subsystem, you must configure the following component types:
For mated STPs, the subsystem defined for each STP defines the other STP as the mate using the MATEDAPC parameter.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | MML Name | Unique name for this subsystem. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
SVC | Adjacent Point Code | Adjacent point code for an STP. The MML name or index of the APC if TRANSPROTO is SCCP. Or the MML name or index of TCAPOverIP service for IN trigger services if TRANSPROTO is TCPIP. Enter the MML name of a previously defined APC. |
MATEDAPC | Mated Adjacent Point Code | Adjacent point code for an STP mate. Enter the MML name of previously defined APC. Only used when mating STPs, not when creating AIN subsystems. |
PRI | Priority | Priority. Enter an integer that is greater than 0 and less than 4. One (1) is the highest priority level. When two subsystems share the same priority level, traffic is shared by both subsystems. Not used when mating STPs. Default = 1. |
PROTO | Protocol Family | Protocol family. When mating STPs, only the SS7 variant is allowed.
If the SVC is an APC, SCCP should not be used (SCCP is not used when mating STP pairs. If the SVC is a TCAPoverIP service, then TCPIP should be used |
SSN | Sub System Number | Subsystem number. Enter an integer from 0 to 255. When mating STPs, SSN = 0. When using IN services, SSN can be set to a value greater than 0. |
STPSCPIND | STP-SCP Index | STP/SCP index. Enter an integer greater than 0. When mating STPs = 0. Default = 0. Not used when mating STPs. |
TRANSPROTO | Transport Protocol | Transport protocol. Enter the transport protocol of this subsystem. When mating STPs = SCCP. Values: SCCP or TCPIP. Not used when mating STPs. |
| Name | APC | Mated APC | Pri | Proto | SSN | Desc |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The final step in planning routes is to define the SS7 routes themselves. Routes are defined in terms of the point codes along the path and the linksets that lead from the MGC node through the STPs to each DPC. Table 2-9 describes the configuration parameters you can use to configure routes, and Table 2-10 serves as a form for you to define your routes. It is a good practice to define two routes to each remote switch. Each route should pass through a different STP in a mated pair. The linkset parameter, LNKSET, defines which STP a route will follow.
To define an SS7 route, you must configure the following component types:
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | MML Name | Unique name for this route. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
OPC | Originating Point Code | Origination point code. Enter the MML name of a previously defined origination point code for this MGC node. |
DPC | Destination Point Code | Destination point code. Enter the MML name of a previously defined destination point code for a remote switch. |
LNKSET | Link Set | Linkset that leads to the destination device. Enter the MML name of a previously defined linkset. |
PRI | Priority | SS7 route priority. Enter an integer that is greater than 0. One (1) is the highest priority level. When two SS7 routes share the same priority level, traffic is shared by both routes. Default = 1. |
DESC | Description | Text description of this route. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | OPC | DPC | LINKSET | PRI | DESC |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The SS7 signaling service is the Cisco MGC Software service that communicates over the route with a remote switch. You must define a separate service for each remote switch. Table 2-11 describes each of the SS7 signaling service parameters and provides space for you to plan the configuration of one service. Table 2-12 serves as a form for you to define your signaling services.
To define an SS7 signaling service, you must configure the following component types:
| MML Parameter Name | CMM Parameter Name | Value | Description |
|---|---|---|---|
NAME | MML Name |
| Unique name for this signaling service. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
DESC | Description |
| Text description of this signaling service. Enter as many as 128 characters and enclose in straight quotes. |
DPC | Point Code |
| Destination point code. Enter the MML name of a previously defined destination point code. |
MDO | MDO File Name |
| Message definition object file name. Choose a valid protocol name. The list contained in Table 2-13 is only a sample. Refer to the release notes for the Cisco MGC Software Release 7 for a current list of MDO file names. |
SIDE | Side | network | Q.931 call model side. Enter user for user side or network for network side. |
CUSTGRPID | Customer Group ID | 0000 | Customer Group ID. Virtual network identification characters (formerly called the Closed User Group). Values accepted for this field depend on the use of the D channel. Used to retrieve information about this signaling service and which dial plan to use. Enter the four-digit ID. Default = 0000. |
CUSTGRP | Customer Group Table | NA | Reserved for future use. |
| NAME | DPC | MDO | Side | CUSTGRPID |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| MDO File Name | Protocol Family |
|---|---|
DPNSS_BTNR188 | DPNSS |
ETSI_300_102 | ISDNPRI |
ETSI_300_102_C1 | ISDNPRI |
ATT_41459 | ISDNPRI |
ATT_41459_C2 | ISDNPRI |
BELL_1268 | ISDNPRI |
ETSI_300_172 | ISDNPRI |
BELL_1268_C3 | ISDNPRI |
NTT_INS_1500 | ISDNPRI |
T113_BELL | SS7-ANSI |
NORTEL_IBN7 | SS7-ANSI |
ANSISS7_SPRINT | SS7-ANSI |
ANSISS7_STANDARD | SS7-ANSI |
Q721_CHINA | SS7-CHINA |
Q721_BASE | SS7-CHINA |
Q767_BASE | SS7-ITU |
ETSI_300_356 | SS7-ITU |
BTNUP_BTNR167 | SS7-ITU |
BTNUP_NRC | SS7-ITU |
Q767_SPAN | SS7-ITU |
Q761_BASE | SS7-ITU |
HKTA_2202 | SS7-ITU |
ISUPV2_FRENCH | SS7-ITU |
ETS_300_121 | ISDNPRI |
ISUPV2_SWISS | SS7-ITU |
ISUPV2_GERMAN | SS7-ITU |
FINLAND_5779 | SS7-ITU |
Q761_AUSTRL | SS7-ITU |
ISUPV1_POLI | SS7-ITU |
ISUPV2_KPNPB | SS7-ITU |
ISUPV2_JAPAN | SS7-NTT (or SS7-Japan) |
ISUPV3_UK | SS7-UK |
Q761_BELG_MOBI | SS7-ITU |
Q767_ITAL | SS7-ITU |
Q767_RUSS | SS7-ITU |
EISUP | EISUP |
SS7 signaling service properties serve as additional configuration parameters that you can use to tune signaling service communications. Table 2-14 lists the default properties assigned to an SS7 signaling service. These properties apply to all SS7 signaling services you create. You do not have to enter these values.
To change SS7 signaling service properties, you must configure the following component types:
| MML Parameter Name | Default Value | Description | ||||||
|---|---|---|---|---|---|---|---|---|
adjDestinations | 16 | Number of adjacent destination point codes. Value range: 1 through 256. | ||||||
BOrigStartIndex | 0 | Specifies the starting number analysis digit index for call originations. Value range: 0 or 1. | ||||||
BTermStartIndex | 0 | Specifies the starting number analysis digit index for call terminations. Value range: 0 or 2. | ||||||
BothwayWorking | 1 | Set to 0 to disable both way release / circuit free handling for BTNUP protocol. Value range: 0 or 1. | ||||||
CGBA2 | 0 | Determines if paired 0 or single 1 circuit group blocking acknowledgments (CGBAs) are required before the blocking is considered successful. Only applicable to ANSI SS7, IBN7, and CTUP protocols.Value range: 0 or 1. | ||||||
CLIDefaultAllowed | false | Adjusts the presentation restricted field in the calling line identity to presentation allowed if set to true. Takes the mapped value from the OCC or TCC protocol side or the default value from the map for this field if false. Value range: true or false. | ||||||
CLIPEss | 0 | Set to 1 to force request of calling line identity if not automatically provided. Value range: 0 or 1. | ||||||
COLDefaultAllowed | false | Adjusts the presentation restricted field in the Connected Line ID to presentation allowed if set to true. Takes the mapped value from the OCC or TCC protocol side or the default value from the map for this field if false. Value range: true or false. | ||||||
CotInTone | 2000 ±20 | Receive tone for continuity test (COT) hardware. The tone to listen for when doing a COT. Enter value in Hz. | ||||||
CotListenDuration | 60 | Maximum period to listen for a COT. | ||||||
CotOutTone | 2000 ±20 | Transmit tone for COT hardware. The tone that is produced. Enter value in Hz. Value: 1780 or 2010. | ||||||
CotPercentage | 0 | Statistical COT. Value range: 0 through 100%. | ||||||
CotPlayDuration | 60 | Maximum period in not aligned state before return to Out-of-Service state (should be less than or equal to the CotListenDuration). | ||||||
dialogRange | 0 | TCAP transaction ID range (for example, 1 through 10000) for a specific subsystem. 0 = entire range. | ||||||
ExtCOT | Loop | Determines the type of COT handling for the specified destination. Values: 0—no COT, loop, or transponder. | ||||||
ForwardCLIinIAM | 0 | Set to 1 if outgoing IAM should contain the calling line identity, if available. Only applicable for BTNUP when interworking from other protocols. Value range: 0 or 1. | ||||||
ForwardSegmentedNEED | 1 | Set to 0 to disable the forwarding of segmented NEED messages within the BTNUP_NRC protocol. If segmenting is disabled, all mandatory DPNSS information elements will be packed into a single BTNUP NEED message. Value range: 0 or 1. | ||||||
GLARE | 0 | Call Collision Handling. Valid values are:
| ||||||
GLARE (continued) | 0 |
| ||||||
GRA2 | 0 | Determines if paired (0) or single (1) group reset acknowledgments (GRAs) are required before the reset is considered successful. Only applicable to ANSI SS7, IBN7, and CTUP protocols. | ||||||
GRSEnabled | false | This property is assigned to an SS7 point code type signal path. Enables Group Reset and Blocking procedure at point code initialization. Synchronizes the Cisco MGC bearer channel blocking state with that of the end office. If True, GRS messages are sent for all CICs associated with the point code. | ||||||
hopCount | 1 | Default hop count. Value range: 0 or 15 (this indicates the maximum number of hops allowed for SCCP messages). | ||||||
InternationalPrefix | 0 | International prefix string to be added to the international dialed number when normalization is enabled. Value range: a numeric string. | ||||||
layerRetries | 2 | Number of times to resend request to adjacent layer without getting a response. Value range: 0 through 5. 0 = No retries. | ||||||
layerTimer | 10 | Time (in tenths of a second) to wait for a response from adjacent layer (SS7 controller, TCAP to SCCP); tailor when layers are not resident on same processor. Value range: 0 through 10. 0 = Disabled, 10 = 1 second. | ||||||
maxMessageLength | 250 | Maximum length of message to MTP3. This value must be less than the value for mtp2MaxMsuFrmLen. | ||||||
NationalPrefix | 0 | National prefix string to be added to the national dialed number when normalization is enabled. | ||||||
NatureOfAddrHandling | 0 | Determines whether or not to do pre-analysis. Value range: 0 or 1. | ||||||
Normalization | 0 | Normalization of dialed number to unknown. Set to 0 for disabled and 1 for enabled. Value range: 0 or 1. | ||||||
OMaxDigits | 24 | Specifies maximum number of digits to receive for overlap digit processing for call origination from this traffic path. | ||||||
OMinDigits | 0 | Specifies minimum number of digits to receive for overlap digit processing for call origination from this traffic path. | ||||||
OOverlap | 0 | Set to 1 to enable overlap signaling for call origination from this traffic path. | ||||||
OverlapDigitTime | 6 | Overlap interdigit timer. The time to wait for the rest of the digits.
| ||||||
OwnClli | na | Specifies the common language location identifier (CLLI). | ||||||
RedirMax | 3 | Specifies the maximum allowable value of the redirection counter parameter available in some C7 signaling systems before the call is force-released. Used to prevent routing loops in certain applications. | ||||||
restartTimer | 10 | Time (in tenths of a second) to pause before sending next group of messages to MTP3 after restart. Value range: 0 through 100. 0 = Disabled, 10 = 1 second. | ||||||
RoutePref | 0 | Determines the preferred route. Value range: 0 through 9. 0 = No Preference (default) 5 = IP Preferred 1 = ATM Essential 6 = IP Excluded 2 = ATM Preferred 7 = TDM Essential 3 = ATM Excluded 8 = TDM Preferred 4 = IP Essential 9 = TDM Excluded | ||||||
sendAfterRestart | SS7-ANSI=16 | Number of queued messages to send (in one group) to MTP3 after restart end. This value, combined with the sendTimer, controls the amount of data sent to MTP3 after restart ends. If too much data is sent to MTP3 after restart, MTP3 could be flooded. Value range: 0 through 256. | ||||||
slsTimer | SS7-ANSI=300 | Time (in tenths of a second) to maintain the same signal linkset in class 1 (connectionless) messages. This is the type of service provided by the SCCP layer. Value range: 0 through 600. 0 = Disabled, 300 = 30 seconds. | ||||||
srtTimer | SS7-ANSI=300 | Time (in tenths of a second) between sending Subsystem Route Test message (SRT) to remote subsystems. Value range: 0 through 3000. 0 = disabled, 300 = 30 seconds. | ||||||
sstTimer | SS7-ANSI=300 | Time (in tenths of a second) between sending Subsystem Status Test (SST) messages to an unavailable remote subsystem. 0 = Disabled, 300 = 30 seconds. | ||||||
standard | SS7-ANSI=ANSI96, ANSI96, | Version of protocol standard supported for this STP/SCP. | ||||||
TMaxDigits | 24 | Specifies maximum number of digits to receive for overlap digit processing for call termination to this traffic path. | ||||||
TMinDigits | 0 | Specifies minimum number of digits to receive for overlap digit processing for call termination to this traffic path. | ||||||
TOverlap | 0 | Set to 1 to enable overlap signaling for call termination to this traffic path. | ||||||
variant | SS7-ANSI=SS7-ANSI,SS7-ITU | SS7 protocol variants supported by local subsystem. | ||||||
VOIPPrefix | 0 | A numeric string. |
Once you have planned your SS7 routes (as described in the "Planning Routes to Other Switches" section), it is time to plan the communication links between the MGC node and the SS7 SPs. SPs are SS7 network nodes, such as STPs and SSPs, with which the Cisco MGC communicates. The Cisco MGC supports two types of SP links: Cisco SLT links and direct SP links. Cisco SLT links use the Cisco SLT to offload MTP 1 and MTP 2 processing to Cisco SLTs. Direct SP links directly link the Cisco MGC to an SP; the Cisco MGC performs all signal processing including MTP 1 and MTP 2 processing.
While linksets define which SP a given route uses, it is the links that carry the communications traffic. Figure 2-3 shows the components you must configure to enable communications with the SPs.
Figure 2-4 shows the order in which the signaling link components must be configured.
This section describes how to plan for provisioning the signaling link components:
1. Create point codes (APC or DPC)
2. Create linkset
3. Override linkset properties (if necessary)
4. Create adapter
5. Create interface
6. Create TDM link
It is best to plan SS7 routes before you configure links, because you define APCs and linksets when defining routes, and these components must be planned and configured before you can configure links. Because the planning of these components is described in the "Planning Routes to Other Switches" section, these procedures are not repeated here. This section describes how to plan for provisioning the following components:
The following sections describe how to plan for each of these components.
Cards are the hardware cards that are installed on the host computer and provide the network interfaces that communicate with other devices. When planning STP links, you define cards that will communicate with the MGC node Cisco SLTs.
|
Note In the MGC node, the same cards and interfaces can be used for communication with the Cisco SLTs and media gateways. When this type of configuration is used, separate links are assigned for the Cisco SLT and media gateway communications. |
Configuring the Cisco MGC can be performed using either the Cisco Media Gateway Controller Manager (CMM), with its graphical user interface, or the Man-Machine Language (MML), with its command-line interface. In many of the tables, you will see both the MML parameter name and the corresponding CMM parameter name. Refer to "Provisioning Tools" section for a brief explanation of each provisioning tool.
Table 2-1 lists the Cisco MGC interface card parameter definitions. Table 2-16 serves as a form where you can enter the configuration information for the network interface cards installed in your Cisco MGC. For Ethernet cards, the system variable is required for configuration, but the IP address and card slot are not required. The IP address column is provided for convenience.
To provision network cards, you must configure the following component types:
Table 2-15 describes configuration parameters you can use to configure cards, and Table 2-16 serves as a form on which you can plan card configurations.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for this component. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
SLOT | Slot | None | Location of card or adapter within the host machine. Acceptable values depend on the host machine. The first slot is usually 0. Enter a value from 0 through 15. |
TYPE | Type | None | The interface card type. Acceptable values are:
|
DESC | Description | None | Text description of this component point code. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | SLOT | TYPE | DESC |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each SS7 link in the MGC node must be associated with an interface component, which must be associated with a network card. The interface represents a physical network connection on the network card.
|
Note In the MGC node, the same cards and interfaces can be used for communication with the Cisco SLTs and media gateways. When configured this way, separate links are assigned for the Cisco SLT and media gateway communications. |
To provision Ethernet interfaces, you must configure the following component types:
Table 2-17 describes the configuration parameters that define an Ethernet interface. Table 2-18 serves as a form for you to plan the Ethernet interfaces on your Cisco MGC.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | MML Name | Unique name for this interface. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
CARD | Ethernet Adapter | Identifies the card that supports this interface. Set this to the MML name of a card that has already been defined. |
DESC | Description | Text description of this interface. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | CARD | DESC |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Each SS7 link in the MGC node must be associated with an interface component, which must be associated with a network card. The interface represents a physical network connection on the network card.
|
Note In the MGC node, the same cards and interfaces can be used for communication with the Cisco SLTs and media gateways. When configured this way, separate links are assigned for the Cisco SLT and media gateway communications. |
To provision a TDM interface for the ITK (T1/E1) or V.35 card, you must configure the following component types:
Table 2-19 lists and describes the configuration parameters that define the TDM interface. Table 2-20 serves as a form for you to plan a TDM interface.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML name | None | Unique name for this link. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
CARD | TDM Line Interface | None | Identifies the card that supports this interface. Set this to the MML name of a card that has already been defined. |
LIFNUM | Line Interface Number | None | Selects the line interface number. Choose 1 through 4 for V.35; otherwise, choose1. |
RESIST | Resistance | 0 | Selects the line resistance, in ohms. Choose 75 (T1) or 120 (E1) for an ITK card; otherwise, choose 0. |
DATARATE | Data Rate | 0 | Selects the data rate for only the V.35 card. Choose 48, 56, or 64 (kbps). |
CLOCK | Clock | EXT | Selects the clock source for only the V.35 card. Choose EXT (external) or INT (internal). |
DTEDCE | DTE or DCE | DTE | Selects the device type for only the V.35 card. Choose DTE (data terminal equipment) or DCE (data communications equipment). |
CODING | Coding | NA | Selects the line coding type on the link. Choose either AMI (alternate mark inversion) or B8ZS (bipolar with 8 zero substitution) for T1. Choose HDB3 (high-density bipolar with 3 zero replacement) for E1. |
FORMAT | Format |
| Selects the link framing format. Choose ESF (extended superframe) or D4 (superframe) for T1. Choose CRC4 (cyclic redundancy check 4) or CCS (common channel signaling) for E1. Choose NA (not applicable) for V.35. |
SIGTYPE | Signal Type | T1 | Selects the type of signaling on the link. Choose T1 for ANSI (American National Standards Institute) DS1 (digital signal level 1). Choose CEPT (Conference Europeenne des Postes et des Telecommunications) for E1. Choose V.35 for 64KBPS digital. |
HDLC | Control | HDLC | Selects the HDLC (High-Level Data Link Control) for the ITU link layer protocol standard. Choose IHDLC (Inverted HDLC) for an ITK card; otherwise HDLC (not used). |
DESC | Description | None | Text description of this link. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | CARD | DESC |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
After you have planned your cards and interfaces, you are ready to plan the SS7 signaling links. When you configure C7 IP links, you can configure a maximum of two of these links for every Cisco SLT. Within the MGC node, the ends of each link are identified as follows:
The portion of the link between the Cisco SLT and the STP is identified by the TIMESLOT configuration parameter. The TIMESLOT configuration parameter identifies the physical port on the Cisco SLT.
To provision the Cisco SLT links, you must configure the following component types:
Table 2-21 lists and describes the C7 IP link configuration parameters that define each link. Table 2-22 serves as a form for planning a single C7 IP link.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for this link. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
DESC | Description | None | Text description of this link. Enter as many as 128 characters and enclose in straight quotes. |
IF | Enet Line Interface | None | Ethernet interface to which this link connects. Enter the MML name of a previously defined Ethernet interface, or enter the SNMP index number for the interface. |
IPADDR | IP Address | None | Cisco MGC IP address for interface. Enter the IP address variable defined in the XECfgParm.dat file during the installation of the Cisco MGC. Valid entries are IP_Addr1, IP_Addr2, IP_Addr3, and IP_Addr4. |
LNKSET | Link Set | None | Linkset to which this link belongs. Enter the MML name of a previously defined linkset. |
PORT | Port | 1 | Cisco MGC port number to which this link connects. Enter any valid IP port number. Value range: any valid IP port number >1024. |
PEERADDR | Peer Address | None | Remote IP address (in dot notation) of the Cisco SLT interface to which this link connects. (May also be specified as a host name or a DNS name.) |
PRI | Priority | 1 | Priority. Enter an integer greater than 0. Value range: 1 through 16. |
SLC | Link Code | 1 | SS7 Signaling link code. Value range: 0 through 15. |
TIMESLOT | Time Slot | 0 | Time slot field for the C7 IP link. Identifies the physical WAN interface card (WIC) slot, that is the SS7 serial port, of the Cisco SLT. |
| MML Parameter Name | Configuration Setting |
|---|---|
DESC |
|
IF |
|
IPADDR |
|
LNKSET |
|
NAME |
|
PORT |
|
PEERADDR |
|
PRI |
|
SLC |
|
TIMESLOT |
|
After you have planned your cards and interfaces, you are ready to plan the SS7 signaling links. When you configure time-division multiplexing (TDM) links, you must configure two of these links for every ITK or PTI card. Within the MGC node, the ends of each link are identified as follows:
The portion of the link between the ITK or PTI card and the STP is identified by the TIMESLOT configuration parameter. The TIMESLOT configuration parameter identifies the physical port on the Cisco SLT.
To provision TDM links, you must configure the following component types:
Table 2-23 lists and describes the TDM link configuration parameters that define each link. Table 2-24 serves as a form for planning a single TDM link.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
DESC | Description | None | Text description of this link. Enter as many as 128 characters and enclose in straight quotes. |
IF | TDM Line Interface | None | Enter the MML name of a previously defined TDM interface to which this link connects. |
NAME | MML Name | None | Unique name for this link. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
PRI | Priority | 1 | Priority. Enter an integer. Value range: 0 through 15. |
SLC | Link Code | 1 | SS7 signaling link code. Enter an integer greater than 0. |
SVC | Link Set | None | Enter the MML name of a previously defined signaling service or linkset. |
TIMESLOT | Time Slot | 1 | Time slot this link uses. |
| MML Parameter Name | Configuration Setting |
|---|---|
DESC |
|
IF |
|
NAME |
|
PRI |
|
SLC |
|
SVC |
|
TIMESLOT |
|
After you have planned your cards and interfaces, you are ready to plan the SS7 signaling links. When you configure F-links, you must configure one of these links for every Cisco SLT. Within the MGC node, the ends of each link are identified from the Cisco SLT to the specific DPC.
After you have planned your cards and interfaces, you are ready to plan the SS7 signaling links. When you configure F-links, you must configure one of these links for every ITK or PTI card. Within the MGC node, the ends of each link are identified from the Cisco MGC to the specific DPC.
After you have planned your cards and interfaces, you are ready to plan the SS7 signaling links. When you configure PRI backhaul links, you must configure one of these links for every Ethernet card to the media gateway (MGW). Within the MGC node, the ends of each link are identified from the Cisco MGC to the MGW.
The MGW control links provide the communication path the Cisco MGC uses to control the bearer traffic that passes through each MGW. Planning MGW control links is similar to planning the other components described earlier in this chapter. Figure 2-5 shows the MGW control link components.
Figure 2-6 shows the order in which the MGW control link components must be configured.
The cards and interfaces shown in Figure 2-5 are configured in the same way as the cards and interfaces used for SS7 signaling links. In fact, you might be able to use the same cards and interfaces previously planned for your MGW control links. You must define IP link components for MGW communications; you cannot use C7 IP links or TDM links.
|
Tips Links are logical connections between a Cisco MGC physical interface and another device. You can assign multiple links to any interface. When assigning links, be sure to consider fault tolerance. For example, placing all four links between the Cisco MGC and one MGW on the same interface results in a useless MGW if that interface fails. |
This section describes how to plan for provisioning the following component types:
1. External nodes
2. Cisco MGC cards
3. Cisco MGC interfaces
4. Media gateway signaling services
5. Override properties (if necessary)
6. IP links
The following sections describe how to plan for each of these components.
An external node is another device, such as a media gateway, with which the Cisco MGC communicates. Within the Cisco MGC Software, an external node is a system component that describes another device. The Cisco MGC can connect to a maximum of eight media gateways, and you must configure an external node for each MGW.
To provision media gateway external nodes, you must configure the following component types:
Table 2-25 describes the external node configuration parameters, and Table 2-26 serves as a form for you to plan a unique name for each media gateway.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for an external device. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
DESC | Description | None | Text description of an external device. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | DESC |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A media gateway signaling service must be defined for each media gateway. As shown in Table 2-27, each media gateway signaling service defines the parent media gateway external node and assigns a media gateway ID to that device. Table 2-28 provides space to plan a single media gateway signaling service.
To provision a media gateway signaling service, you must configure the following component types:
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for this signaling service. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
MDO | MDO File Name | None | Enter a valid message definition object (MDO) file protocol name by using the PROV-RTRV:VARIANTS MML command. |
EXTNODE | External Node | None | Enter the external node name assigned to the media gateway you are configuring. |
SIDE | Side | Network | Q.931 call model side. Enter user for user side or network for network side. |
CUSTGRPID | Customer Group ID | 0000 | Customer Group ID. Virtual network identification characters (formerly called the VNET ID). Values accepted for this field depend on the use of the D channel. Enter the four-digit ID. (Used only for IP FAS transport service.) |
CUSTGRP | Customer Group Table | NA | Reserved for future use. |
ABFLAG | A/B flag | N | A/B flag. Specifies digital private network signaling system (DPNSS) a or b side. Enter A for a side, B for b side, or N for not applicable. (Used only for IP FAS transport service.) |
CRLEN | Call Reference Length | 2 | Call reference length. Enter 0 for DPNSS, 1 for one-byte call reference, or 2 for two-byte call reference. Default = 2. (Used only for IP FAS transport service.) |
DESC | Description | None | Text description of this signaling service. Enter as many as 128 characters and enclose in straight quotes. |
| MML Parameter Name | Configuration Setting |
|---|---|
NAME |
|
MDO |
|
EXTNODE |
|
DESC |
|
Network cards are the hardware cards installed on the host computer providing the network interfaces that communicate with other devices. When planning media gateway control links, you define the cards that will communicate with the media gateways.
|
Note In the MGC node system, the same cards and interfaces can be used for communication with Cisco SLTs and media gateways. When configured this way, separate links are assigned for Cisco SLT and media gateway communications. |
To provision cards, you must configure the following component types:
Table 2-29 describes configuration parameters you can use to configure network cards, and Table 2-30 serves as a form on which you can plan network card configurations.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for this component. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
SLOT | Slot | None | Location of card or adapter within the host machine. Acceptable values depend on the host machine. The first slot is usually 0. |
TYPE | Type | None | Type of card or adapter. Acceptable values are:
|
DESC | Description | None | Description of this component. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | SLOT | TYPE | DESC |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each SS7 link in the MGC node must be associated with an Ethernet interface component, which must be associated with a network card. The Ethernet interface represents a physical network connection on the network card.
|
Note In the MGC node, the same cards and interfaces can be used for communication with Cisco SLTs and media gateways. When configured this way, separate links are assigned for Cisco SLT and media gateway communications. |
To provision an Ethernet interface, you must configure the following component types:
Table 2-31 describes the configuration parameters that define an Ethernet interface. Table 2-32 serves as a form for you to plan the Ethernet interfaces on your Cisco MGC.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for this interface. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
CARD | Ethernet Adapter | None | Identifies the card that supports this interface. Set this to the MML name of a card that has already been defined. |
DESC | Description | None | Text description of this interface. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | CARD | DESC |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Each SS7 link in the MGC node must be associated with an interface component, which must be associated with a network card. The interface represents a physical network connection on the network card.
|
Note In the MGC node, the same cards and interfaces can be used for communication with the Cisco SLTs and media gateways. When configured this way, separate links are assigned for the Cisco SLT and media gateway communications. |
To provision a TDM interface for the ITK (T1/E1) or V.35 card, you must configure the following component types:
Table 2-33 lists and describes the configuration parameters that define the TDM interface. Table 2-34 serves as a form for you to plan a TDM interface.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML name | None | Unique name for this link. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
CARD | Ethernet Adapter | None | Identifies the card that supports this interface. Set this to the MML name of a card that has already been defined. |
LIFNUM | Line Interface Number | None | Selects the line interface number. Choose 1 through 4 for V.35; otherwise, enter 1. |
RESIST | Resistance | 0 | Selects the line resistance. Choose 75 or 120 for an ITK card; otherwise, enter 0. |
DATARATE | Data Rate | 0 | Selects the data rate for only the V.35 card. Choose 48, 56, or 64 (kbps). |
CLOCK | Clock | INT | Selects the clock source for only the V.35 card. Choose EXT (external) or INT (internal). |
DTEDCE | DTE or DCE | DTE | Selects the device type for only the V.35 card. Choose DTE (data terminal equipment) or DCE (data communications equipment). |
CODING | Coding | B8ZS | Selects the line coding type on the link. Choose either AMI (alternate mark inversion) or B8ZS (bipolar with 8 zero substitution) for T1. Choose HDB3 (high-density bipolar with 3 zero replacement) for E1. Or or choose NA (not applicable) for V.35 |
FORMAT | Format | ESF | Selects the link framing format. Choose ESF (extended superframe) or D4 (superframe) for T1. Choose CRC4 (cyclic redundancy check 4), CCS (common channel signaling), or NA (not applicable) for V.35. |
SIGTYPE | Signal Type | T1 | Selects the type of signaling on the link. Choose T1 for ANSI (American National Standards Institute) or DS1 (digital signal level 1). Choose CEPT (Conference Europeenne des Postes et des Telecommunications) for E1. |
HDLC | Control | HDLC | Selects the HDLC (High-Level Data Link Control) for the ITU link layer protocol standard. Choose IHDLC (Inverted HDLC) for an ITK card; otherwise, choose HDLC. |
DESC | Description | None | Text description of this link. Enter as many as 128 characters and enclose in straight quotes. |
| NAME | CARD | DESC |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
The last step in planning media gateway control links is the planning of the links themselves. You must identify each end of each link as follows:
To provision a media gateway IP link, you must configure the following component types:
Table 2-35 lists and describes the configuration parameters that define each link. Table 2-36 serves as a form for planning a single IP link.
| MML Parameter Name | CMM Parameter Name | Default Value | Description |
|---|---|---|---|
NAME | MML Name | None | Unique name for this link. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
IF | Enet Line Interface | None | Ethernet interface to which this link connects. Enter the MML name of a previously defined Ethernet interface. |
DESC | Description | None | Text description of this link. Enter as many as 128 characters and enclose in straight quotes. |
IPADDR | IP Address | None | Cisco MGC IP address for interface. Enter the IP address variable defined in the XECfgParm.dat file during the installation of the Cisco MGC. Valid entries ar: IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. |
PEERADDR | Peer Address | None | Remote IP address of link interface on media gateway. |
PEERPORT | Peer Port | None | Port number of link interface on remote device. |
PORT | Port | None | Local port number of link interface on the Cisco MGC. Enter any valid IP port number greater than 1024. |
PRI | Priority | 1 | Priority. Enter an integer that is greater than 0. |
SIGPORT | Signal Port | 0 | Physical port on the gateway on the slot.Value range: 0 through 168. (Used only to support IPFAS.) |
SIGSLOT | Signal Slot | 0 | Physical slot on the gateway where the T1/E1 is plugged into. |
SVC | IP Signaling Services | None | Signaling service this IP supports. Enter the MML name of a previously defined signal service. |
SIGPORTSKIP |
| 0 | Signal port skip. The number of SIGPORT values to be skipped before using the next value. (Used only for NFAS signaling type.) |
| MML Parameter Name | Value |
|---|---|
NAME |
|
IF |
|
DESC |
|
IPADDR |
|
PEERADDR |
|
PEERPORT |
|
PORT |
|
PRI |
|
SIGPORT |
|
SIGSLOT |
|
SVC |
|
There are two different methods that can be used to provision trunk groups and trunks. Provisioning can be performed individually creating each trunk group and trunk by using MML commands. Or provisioning can be performed by importing a customer-created file.
Provisioning trunk groups and trunks can be performed using MML commands. Examples of the provisioning MML commands are contained in this chapter. More extensive MML command examples are listed in "Adding System Components with MML."
When provisioning using MML commands, it is important to realize that the MML commands are used to add to existing components. Therefore, MML commands are very useful when modifying existing trunk groups and trunks. However, if you have to create large trunk group or trunk files, importing a file can greatly speed the provisioning effort.
Importing a customer-created file is another way to provision trunk groups and trunks. The customer file can be created using CMM or a text editor. MML commands cannot be used to create the customer file. After the file is created, you must import it into the Cisco MGC. When importing this file, you can use either MML commands or the CMM.
When provisioning using an imported customer-created file, it is important to realize that the imported file overwrites the existing file.For example, if a customer-created trunk group file is imported, the existing trunk group file is overwritten.
You need to add trunks for each connection between the MGW and a destination switch. These trunks can be either nailed or switched. For nailed trunks, the Cisco MGC does not perform switching of trunks. To create a nailed trunk, you can use an MML command to create a single trunk, use the CMM to create a trunk, or use the MML command to import a trunk file created using a text editor. To add multiple nailed trunks, refer to "Adding Multiple Nailed Trunks (Release 7.4)" section.
The MML command format used to create one nailed trunk is:
prov-add:nailedtrnk:name="1910",srcsvc="ss7svc1",srctimeslot=101,dstsvc="nassrv1",
dstspan=3,dsttimeslot=1,spansize=1
Table 2-37 lists the nailed trunk MML command parameter definitions and their associated values.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | Name | Trunk group ID. A numeric identifier for the trunk group. Value range: an integer from 1 through 65535. |
SRCSVC | Source Service | Used to look up the source service component ID. The MML name of a previously defined signaling service. |
SRCSPAN | Source Span ID | Corresponds to the source span ID. Value range: an integer from 1 through 65535. This value is converted from decimal to hexadecimal, except when the value is ffff. |
SRCTIMESLOT | Source Time Slot | Corresponds to the source time slot. Value range: an integer from 1 through 65535. This value is converted from decimal to hexadecimal, except when the value is ffff. |
DSTSVC | Destination Service Name | Used to look up the destination service component ID. The MML name of a previously defined signaling service. |
DSTSPAN | Destination Span ID | Corresponds to the destination span ID. Value range: an integer from 1 through 65535. This value is converted from decimal to hexadecimal, except when the value is ffff. |
DSTTIMESLOT | Destination Time Slot | Corresponds to the destination time slot. Value range: an integer from 1 through 65535. This value is converted from decimal to hexadecimal, except when the value is ffff. |
SPANSIZE | Span Size | Span size. Indicates the number of trunks per span. Value: 1 (default) through 24 for T1, or 1 through 31 for E1. |
The MML command format used to import a customer-created nailed trunk file is:
prov-add:files:name="BCFile",file="trunkCust.dat",action="import"
This imports the customer-created file that uses #format2. The imported file format would appear as:
Trunk Src Src Src Dest Dest Dest ID cmp-id Span Time slot cmp-id Span Time slot 101 00130002 ffff 65 00140001 3 1 102 00130002 ffff 66 00140001 3 2
The #format2 fields are: Trunk ID, Source Service CompId, Source Span, Source Time slot, Destination Service CompId, Destination Span, and Destination Time slot.
Before switched trunk groups and trunks can be created, the following two files need to be created:
In Release 7.3(x), the following MML commands can be used to create and import a trunk group file and a trunk (bearer channel) file:
prov-add:files:name="TKGFile",file="trunkgroupCust.dat",action="import" prov-add:files:name="BCFile",file="trunkCust.dat",action="import"
This imports the customer-created bearer channel switched file using #format3.
Once these files are created, you can use the MML command to import a trunk group file created using a text editor. Create the trunk group file and bearer channel file using a text editor and then importing the files.
In Release 7.4(x), you can either use the MML commands, listed above, to import a trunk group file, or you can use the following MML command to populate a trunk group one line at a time.
After you create a trunk group file, you need to populate that file. Trunk group information is used to populate the trunkGroup file and spawns information for the Properties file and the SigPath file.
The MML command format used to create a trunk group row in the trunk group file is:
prov-add:trnkgrp:name="1910",clli="tg1910",svc="bh-path-33",type="TDM_PRI",
selseq="ASC",qable="N"
Table 2-38 lists the trunk group parameter definitions and their associated values.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | Name | Trunk group ID. A numeric identifier for the trunk group. An integer from 1 through 65535. |
CLLI | CLLI | Common language location identifier that identifies the trunk group. |
SVC | Signal Service | The MML name of the signaling service associated with or controlling the trunk group. |
TYPE | Type | Identifies the trunk group type. Value range: 0 through 8. 0 = TDM_GEN - used with SS7 signaling services with switch types not equal to 0, 5, or 20. |
SELSEQ | Selection Sequence | Determines the trunk selection sequence. It is used to eliminate or reduce the chance of glare when selecting a trunk. Values: ASC = Ascending (default) |
QABLE | Queuable | Determines if queuing is used on the trunk during call processing. Value range: Y for yes or N for no (default). |
In addition to the trunk group parameters listed in Table 2-38, there are additional properties that can be set or changed in the text file. To add multiple trunk groups, refer to "Adding Multiple Trunk Groups and Bearer Channels (Release 7.4)" section. Table 2-39 lists the trunk group property MML parameter definitions and their associated values.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
RingNoAnswer | RNA | Ring no answer. Indicates the time, in seconds, ringing is allowed to occur. Value range: 0 through 255, which is converted to milliseconds. |
GLARE | Glare Control | Glare control. Glare is a collision that occurs when two network nodes simultaneously attempt to reserve the same channel. Values are: 1 (always), 2 (even/odd), or 3 (never) (default). |
CotPercentage | Cot Percentage | Determines the percentage of calls on the trunk upon which a continuity test is performed. Value range: 0 through 100. |
VSF | VSF Priority | Virtual switch fabric priority. Determines if the gateway attempts to find a trunk on the same gateway as the incoming trunk or on any available trunk. Values are: 0 (no) (default) or 1 (yes). |
SatelliteInd | Satellite | Satellite indicator. Indicates if the trunk is going over a satellite. Values are: 0 (no) (default) or 1 (yes). |
Npa |
| Numbering plan area. Indicates the NPA code associated with the incoming trunk group. Value range: 0 (none), or 200 through 999. |
CarrierIdentity |
| Carrier identity. Indicates the carrier ID to which users on this trunk group are associated. Value range: 0 (if not defined) or 1 through 9999. |
ScreenFailAction |
| Screen fail action. Indicates if an action is to be performed when a screening failure occurs. Values are: 0 (no) or rejectCall. |
CustGrpId |
| Customer group ID. The ID of the customer associated with this trunk group. Value range: 0 (if not defined) or any 4-character alphanumeric string. |
BOrigStartIndex |
| B originating start index. Identifies the entry point into the originating side of the dial plan. Values are: 0 (no dial plan) or 1 (for the first node in the originating digit tree). |
BTermStartIndex |
| B terminating start index. Identifies the entry point into the terminating side of the dial plan. Values are: 0 (no dial plan) or 2 (for the first node in the terminating digit tree). |
CompressionType |
| Compression type. Indicates the G.711 compression type used on the trunk. Values are: 0 (none), 1 (mu-law), or 2 (A-law). |
Echo Cancellation |
| Echo cancellation. Indicates if echo cancellation is required. Values are: 0 (not required) or 1 (required). |
After you have populated the trunk group file, if you want to change any properties in that file, make the property changes using the text editor. Then use the MML add command to add the trunk group file and the bearer channel file, even though you have not made any changes to the bearer channel file.
The following is an example of a trunk group file #format3 text format:
#format3 1910 TG1910 bh-path-33 TDM_PRI N 180 2 100 ASC 0 0 501 0333 0 cujo 1 0 1 1 2744 TG2744 ss7-135033 TDM_ISUP N 180 2 0 ASC 0 0 502 0333 0 cujo 1 0 1 1 3913 TG3913 bh-pth-332 TDM_PRI N 180 2 100 ASC 0 0 503 0333 0 cujo 1 0 1 1 4714 TG4714 ss7-135033 TDM_ISUP N 180 2 0 ASC 0 0 504 0333 0 cujo 1 0 1 1 1910 TG1910 bh-path-34 TDM_PRI N 180 2 0 ASC 0 0 511 0333 0 cujo 1 0 1 1
After you have finished creating a trunk file, you need to populate that file. Trunk information is used to populate the trunk file. Create a trunk row entry in the trunk file using a text editor. Then use the MML command to import the trunk file (trunkCust.txt).
Table 2-40 lists the trunk MML parameter definitions and their associated values.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | Trunk Group Member Number | Identifies the trunk group member number. A numeric identifier for the trunk group member. An integer from 1 through 65535. |
TRNKGRPNUM | Trunk Group Number | Identifies the trunk group number. Value range: an integer from 1 through 65535. Not used for ISDN. |
SPAN | Span ID | Identifies the span. Value range: an integer from 1 through 65535 or ffff. (Not required for TDM.) |
CIC | Circuit Identifier Code | Identifies the trunk time slot or circuit identification code. Value range: an integer from 1 through 65535. |
CU | Coding Unit | Identifies the coding unit MML name that was previously defined for the VISM card (this is the external node created for MGCP or SGCP). |
ENDPOINT | End Point | Text description of the trunk end point (typically a VISM card). Enter as many as 128 characters and enclose in straight quotes. |
SPANSIZE | Span Size | Span size. Indicates the number of trunks per span. |
The following is an example of a trunk file text format:
#format3 1910 191001 0 1 as5300-33 S0/DS1-0/1@as5300-33 1910 191002 0 2 as5300-33 S0/DS1-0/2@as5300-33 1910 191003 0 3 as5300-33 S0/DS1-0/3@as5300-33 1910 191004 0 4 as5300-33 S0/DS1-0/4@as5300-33 1910 191005 0 5 as5300-33 S0/DS1-0/5@as5300-33
Routing analysis is necessary to identify the path for bearer traffic from the Cisco MGC to the adjacent switch.
You need to create a routing trunk group. You can use either the MML command to create a routing trunk group or use the CMM to import a routing file.
Provisioning routing trunk groups can be performed using MML commands. Examples of the provisioning MML commands are contained in this chapter. More extensive MML command examples are listed in "Adding System Components with MML."
When provisioning using MML commands, it is important to realize that the MML commands are used to add to existing components. Therefore, MML commands are very useful when modifying existing a routing trunk groups. However, if you have to create large routing trunk group, importing a file can greatly speed the provisioning effort.
The MML command format used to create a row in the routing trunk group file is:
prov-add:rttrnkgrp:name="1910",type=7,reattempts=1,queuing=0,cutthrough=2
Table 2-41 lists the routing trunk group MML command parameter definitions and their associated values.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | Name | Unique name for this routing trunk group number. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
TYPE | Type | Identifies the trunk group type. Value range: 0 through 8. 0 = TDM_GEN - used with SS7 signaling services with switch types not equal to 0, 5, or 20. |
REATTEMPTS | Reattempts | Identifies the number of times the system reattempts to select a trunk group. |
QUEUING | Queuing | Identifies the duration (in seconds) the call will be queued. |
CUTTHROUGH | Cutthrough | Identifies the point in the call process where the trunk is seized from end point to end point. Value range: 0 (default) through 65535. |
Importing a customer-created file is another way to provision routing trunk groups. The customer file can be created using CMM or a text editor. MML commands cannot be used to create the customer file. After the file is created, you must import it into the Cisco MGC. When importing this file, you can use either MML commands or the CMM.
When provisioning using an imported customer-created file, it is important to realize that the imported file overwrites the existing file.For example, if a customer-created routing trunk group file is imported, the existing routing trunk group file is overwritten.
After the routing trunk group file has been created, you need to asociate a route with a trunk group.
You need to create a route to connect to a trunk group. You can use either the MML commands to associate a route with a trunk group or use the CMM to import a routing file.
The MML command format used to create a row in the route trunk file is:
prov-add:rttrnk:name="rt1910",trnkgrpnum=501910
Table 2-42 lists the route trunk MML command parameter definitions.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
NAME | Name | Unique name for this routing trunk group. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
TRNKGRPNUM | Trunk Group Number | Identifies the trunk group number. |
NEXTNAME | Next Route | Identifies the next route name. |
Each line entry in the route trunk file is one entry in the route list file.
After you have finished creating a route trunk, you need to create a route list. You can use either the MML command to create a route list, use the CMM, or import a routing file.
The MML command format used to create the route list is:
prov-add:rtlist:name="rtlist1910",rtname="rt1910",carrierid=333
Table 2-42 lists the route list MML command parameter definitions and their associated values.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
LISTINDEX | List Index | Indicates the index value. (Not used in Release 7.4) |
NAME | Name | Unique name for this route trunk. Enter as many as 10 alphanumeric characters (or 20 alphanumeric characters for Release 7.4) and enclose in straight quotes. Dashes (-) can be used. |
RTNAME | Route Name | Used to look up the source service component ID. |
CARRIERID | Carrier ID | Carrier identity. Indicates the carrier ID. Value range: 0 (if not defined) or 1 through 9999. |
|
Note What is called route listin MML is called a route group in CMM. |
The following MML commands provide a sample routing file.
prov-add:rttrnkgrp:name="1910",type=7,reattempts=1,queuing=0,cutthrough=2 prov-add:rttrnkgrp:name="2744",type=1,reattempts=1,queuing=0,cutthrough=2 prov-add:rttrnkgrp:name="3913",type=7,reattempts=1,queuing=0,cutthrough=2 prov-add:rttrnkgrp:name="3914",type=1,reattempts=1,queuing=0,cutthrough=2 prov-add:rttrnk:name="rt1910",trnkgrpnum=1910 prov-add:rttrnk:name="rt2744",trnkgrpnum=2744 prov-add:rttrnk:name="rt3913",trnkgrpnum=3913 prov-add:rttrnk:name="rt3914",trnkgrpnum=3914 prov-add:rtlist:name="rtlist1910",rtname="rt1910",carrierid=333 prov-add:rtlist:name="rtlist2744",rtname="rt2744",carrierid=333 prov-add:rtlist:name="rtlist3913",rtname="rt3913",carrierid=333 prov-add:rtlist:name="rtlist3914",rtname="rt3914",carrierid=333
The version of software used determines how you will implement your dial plan. Refer to the following paragraphs for an explanation of how the dial plan is implemented in software Release 7.3 and software Release 7.4.
The dial plan allows the Cisco MGC to perform pre-analysis, calling (A) numbers analysis, called (B) numbers analysis, and cause analysis. Analysis can be performed on each digit of the A or B number to determine if further processing is necessary and if any resulting action is required.
The dial plan includes a list of all the numbers, digit strings, supported by your network. In addition to listing all the numbers in your system, the dial plan also lists any resulting action to be taken after the number analysis is complete.
The number analysis utility uses a variety of tables that store the dial plan numbers. Dial plan worksheets are provided for you to copy and fill in to document your dial plan, result types, preanalysis, and cause analysis. Use Figure 2-26 through Figure 2-33 for Release 7.3(x), and use Figure 2-45 through Figure 2-52 for Release 7.4(x)
Creating an efficient and complete dial plan requires thorough planning and foresight. Organization can simplify your dial plan implementation. The following sections describe recommended rules and practices to help you in creating your dial plan. Examples are provided in this chapter to give you an idea of how to implement your dial plan.
Basically, a dial plan consists of all the numbers, digit strings, that require analysis. All these digit strings will be assigned to either the A-digit tree or assigned to the B-digit tree.
Dial plan worksheets, located after the end of each release version discussion can be copied and filled in to list all the digit strings in your network. The digit tree in which you enter the digit string is determined by whether the digit string is a calling number (entered in the A-digit tree) or a called number (entered in the B-digit tree). In addition to the dial plan worksheets, other worksheets are provided that you can copy and fill in to identify the other elements of your dial plan.
The following paragraphs describe how to create a dial plan for software Release 7.3(x) (Drop 3) and for software Release 7.4(x) (Drop 4). Creating a dial plan in Release 7.3(x) is discussed first, then creating a dial plan in Release 7.4(x) is discussed.
The following sections describe how to create a dial plan for software Release 7.3(x).
The dial plan is used to identify unique calling or called number strings. Keep in mind the following issues when creating your dial plan:
These issues will be discussed and examples provided in the following sections. For purposes of example only, as many as six digits of any string will be analyzed. In your dial plan implementation, you might want to analyze additional digits.
The following numbers are examples of digit strings that will be used in the dial plan discussion:
703
703 484
301 555
301 684
40555
Refer to Figure 2-7 to view a sample of an A-digit tree digit string and the information required for each digit string used in your dial plan.
The first entry in the dial plan worksheet will be either an A (calling) or a B (called) to identify the type of digit tree. The next block identifies the starting node for the digit string. A node is conceptually a decision point. It is at the node that the path to the next number in the digit string is determined. The nodes are the links in the path between the numbers in the digit string.
The starting node is a special node and is either a 1 (for originating) or a 2 (for terminating). In the example shown in Figure 2-7, the first digit string is in the A-digit tree and is an originating number. Therefore, the starting node for the digit string is 1. All of the originating digit strings in the A-digit tree will share the starting node (1). Since node 2 is reserved for terminating digit strings, the first node available for use in this dial plan is node 3.
From node 3, there are 10 possible paths (0 through 9) through the node. The path from node 3 is determined by the next digit in the digit string. With 10 possible paths (or branches) from node 3, it is possible to take any branch for the path to the next digit.
In Figure 2-7, the arrows going from the node number to the digit number indicate the sequence of events for the digit string analysis. From node 1, the first digit in the digit string is a 7. From digit 7, the first available node is 3. From node 3, the next digit is 0. Again, instead of the 0 used in our example, the next digit could just as easily be any digit from 0 through 9. However, since the digit is 0, the next node is 4. From node 4, the next digit is 3. Again, the next digit could be any digit from 0 through 9. From 3, the next node is 5. This sequence of events continues until the entire digit string is analyzed.
Table 2-43 lists the parameters you must fill in on your dial plan worksheet.
|
Tips Use sequentially numbered nodes to make tracking the nodes used an easier task. Record the numbers of the nodes used on your dial plan worksheet. |
| Parameter | Value | Definition |
|---|---|---|
Digit Tree Type | A or B | Enter A for the calling number, or |
Digit String | 0 through 9 | Enter all the digits of the dial plan digit string. If necessary, use two rows to display all the digits in the digit string. |
Starting Node | 1 or 2 | Enter 1 for an originating (A) digit string for calls originating outside the Cisco MGC network. Enter 2 for a terminating (B) digit string that originates within the Cisco MGC network. |
Nodes | 3 through last node | Enter a unique node number for each digit in the digit string. |
Nodes Used | 1 through last node | Identifies the nodes used for digit analysis. |
Figure 2-8 displays all the possible paths from node 1. The next digit (0 through 9) in the digit string determines the path, or branch, to the next node. From that node, the next digit (0 through 9) determines the path to the next node. This sequence continues until the last analyzed digit in the string is reached. The thicker line in Figure 2-8 shows the path for the first three digits (7, 0, and 3) of the digit string in Figure 2-7, up to the fourth node (node 5). The number of digits analyzed in your dial plan determines the total number of branches you will have.
|
Note Due to its branching nature, it is very important to carefully construct your dial plan. It is important to thoroughly plan the mapping of your existing dial plan, and to consider future growth. |
Figure 2-9 is an example of a worksheet used when creating a dial plan with the previous list of numbers. For the purpose of simplicity, the examples shown in Figure 2-9 present analysis only on the first several calling digits.
The dial plan number examples listed in Figure 2-9 are presented in graphic form in Figure 2-10 in a tree format. The tree representation provides a visual indication of the calling digit string and the adjacent node to which each digit is directed in the digit string.
The dial plan numbers shown in Figure 2-9 also list the node associated with each digit. The first digit string is a three-digit string (703). Since it is the first string and there are no overlapping numbers, all the nodes for that digit string are unique numbers. However, the second digit string does have overlapping numbers. An overlapping number is a number that is shared by two or more digit strings. When digit string numbers do overlap, the node numbers for the overlapping numbers are the same. When the node numbers are the same, the path is the same for the overlapping digits. So, in Figure 2-10, the first and second digit strings have the following overlapping digits: 7, 0, and 3.
The node numbers, shown in Figure 2-10, for the first and second digit strings in Figure 2-9 show that nodes 3 and 4 are the same. This indicates that the path for these two digit strings is the same up until node 5. It is at node 5 that the paths split into two different paths. This path split can be seen in Figure 2-10. The paths split at node 5. Because the next number in the second digit string is different (that is, 4) and the first string has no other numbers, the second digit string takes a different path than the first digit string.
The next two digit strings in Figure 2-9 again show overlapping numbers (3, 0, and 1), and both of these digit strings have nodes 8, 9, and 10 in common, as shown in Figure 2-10. Because the next three digits are different, the digit tree paths are also different, see Figure 2-10.
The fifth digit string shown in Figure 2-9 begins with a unique number (4) and thus is also assigned the next unused node number (15). However, the last three digits in the fifth digit string (555) appear identical to the last three digits (555) in the third digit string. Yet, as shown in Figure 2-10, the nodes are not shared. The reason the nodes are not shared is that even though the numbers in the digit strings are the same (555), the numbers are in different paths and thus must have unique node numbers.
When creating your dial plan, copy and fill in the worksheet (Figure 2-26) to reflect the dial plan for your system. By listing the nodes used, it is easy to know what the next unused node number that can be used for unique numbers in digit string.
Before creating a result table, you must create some other tables first. These other tables define parameter values used by the result table. The other tables that must be created before the result table are:
In addition, a route group must be created before the ROUTE result type can be defined.
The digit modification table is the table in which the user defines the digit string for the selected index value. Figure 2-11 is an example of a digit modification table. The digit modification string in the table is used to insert numbers into either the calling or called party number at the application point specified in either the AMODDIG or BMODDIG result type. Figure 2-11, located at the end of this chapter, can be copied and filled in to document the digit modification index and the associated digit modification string in your dial plan.
The service names in the service name table are defined by the user to indicate services for screening that are available to the customer. Figure 2-12 is an example of a service name table. A service must be defined before a result-type screening (described in the next four sections) can be connected to a B-digit string. Figure 2-29, located at the end of this chapter, can be copied and filled in to document the service index and the associated service names supported in your dial plan.
Call screening is a type of analysis done on the digit string to determine if the call is accepted or rejected. Refer to "Result Type Definitions," for more information about call screening.
In Figure 2-9, the last number in each digit string does not have a node number associated with it. When there is no next node associated with the last number in a digit string, an action must be taken. The action taken is in the form of a result. A result defines the action that must be taken. Refer to Table 2-44 for a list of the result types and their data words. Refer to "Result Type Definitions" for a definition of the result types and their associated data words.
| Result Value | Result Type | Data Word 1 | Data Word 2 | Data Word 3 | Data Word 4 | Analysis Point | Valid For | Definition Reference |
|---|---|---|---|---|---|---|---|---|
1 | DIGIT_REQ | No Of Digits | 0 (not used) | 0 (not used) | 0 (not used) | Int | B | |
2 | ROUTE | Route List ID | 0 (not used) | 0 (not used) | 0 (not used) | Int | B, C, P | |
3 | INC_NUMBERING | Numbering Type | Minimum Digits | Maximum Digits | 0 (not used) | Int | B, P | |
4 | BMODDIG | Application Point | Number of digits to remove | Modification Index | 0 (not used) | Int | B, C, | |
5 | AMODDIG | Application Point | Number of digits to remove | Modification Index | 0 (not used) | Int | A | |
6 | CAUSE | Cause Code | 0 (not used) | 0 (not used) | 0 (not used) | EP | B, C | |
8 | ANNOUNCEMENT | Announcement ID | Local/Remote | Route List ID | Announcement Data | EP | B, C | |
11 | CPC_REQ | 0 (not used) | 0 (not used) | 0 (not used) | 0 (not used) | Int | A, B | |
12 | CLI_REQ | 0 (not used) | 0 (not used) | 0 (not used) | 0 (not used) | Int | A, B | |
13 | BSM_REQ | 0 (not used) | 0 (not used) | 0 (not used) | 0 (not used) | Int | A, B | |
14 | FSM_REQ | 0 (not used) | 0 (not used) | 0 (not used) | 0 (not used) | Int | A, B | |
15 | A_NUMBER_TYPE | A-Number Type | 0 (not used) | 0 (not used) | 0 (not used) | Int | A, B | |
16 | B_NUMBER_TYPE | B-Number Type | 0 (not used) | 0 (not used) | 0 (not used) | Int | A, B, | |
17 | OTG_NUMBERING | Numbering Type | Minimum Digits | Maximum Digits | 0 (not used) | Int | B | |
18 | BLACKLIST | Screening Criteria | 0 (not used) | 0 (not used) | 0 (not used) | EP | A, B | |
19 | CLI_NBR_LENGTH | Numbering Type | Minimum Digits | Maximum Digits | 0 (not used) | Int | A | |
21 | ROUTE_ | Route Pref | 0 (not used) | 0 (not used) | 0 (not used) | Int | A | |
22 | IN_TRIGGER | Service Type | SCP/STP Index | 0 (not used) | 0 (not used) | Int | B | |
23 | SCREENING | Screen Type | Service ID | 0 (not used) | 0 (not used) | Int | A, B | |
24 | DATA_EXCHANGE | ActionId | 0 (not used) | 0 (not used) | 0 (not used) | Int | B | |
Int = Intermediate EP = End Point A = A-digit tree B = B-digit tree | ||||||||
Using the second digit strings shown in Figure 2-9, we will only deal with the last number in that digit string. Because the last digit (4) in the digit string has no node associated with it, a result listed in Table 2-44 must occur. In order to keep track of the result type for each digit string, record the result type on the dial plan worksheet (Figure 2-27). The result that must occur after the last digit in the string is shown in Figure 2-13. The result that does occur is determined by the result table shown in Figure 2-14. For each digit string in your dial plan, there must be a corresponding result and row in the result table.
The result table example shown in Figure 2-14 shows the relationship between the last digit of a digit string and the corresponding result for each digit string. Figure 2-15 shows the concept of a result (shown by a triangle) occurring after the last digit in a digit string.
The result table example shown in Figure 2-14 lists the six values (Result Index, Result Type, Data Word 1, Data Word 2, Data Word 3, Data Word 4, and Next Result) that are included for each digit string in the result table. The data word values in the result table are determined by the values of the result type.
In Figure 2-15, Result Index 1 is for the Screening result type. The value for Data Word 1 is 1, indicating that a white list screening will be performed on the first digit string. The value for Data Word 2 is 1, indicating an index entry for the service name table from which a provisioned service name can be obtained.
Figure 2-16 shows the dial plan tables and accompanying MML commands used to create the tables.
Figure 2-17 is an example of the digit modification table and the accompanying MML command.
Figure 2-18 is an example of a service name table and the accompanying MML command.
Figure 2-19 is an example of a result table and the accompanying MML command. In the example shown in Figure 2-19, two of the results have been connected together by using the nextresult parameter to create a result set. When the MML session is run, the last result in the result set has to be created first. If the last result in a result set is not created first, an error is generated because a next result cannot also be connected because it does not exist.
Figure 2-20 is an example of digit strings for an B-digit tree and the accompanying MML commands.
Once you have created the previously described tables, you can create a dial plan text file containing all the MML commands, as shown in Figure 2-21. The first two lines in the text file are to start a provisioning session and to create a dial plan.
|
Note The digit string MML commands are entered in the reverse order in which they were created. |
Once you have filled in the dial plan worksheets (from Figure 2-26 through Figure 2-36) you must configure the Cisco MGC to implement your dial plan. When configuring the Cisco MGC, you will use the dial plan worksheets and either the MML commands listed in Table 2-44 or the available TCM parameters.
Table 2-45 describes the configuration parameters that apply to each dial plan you define.
| MML Component Name | MML Parameter Name | Description |
|---|---|---|
DIALPLAN |
| Selects the customer-created dial plan. |
ADIGTREE |
| Selects the A-digit tree table in the dial plan. |
BDIGTREE |
| Selects the B-digit tree table in the dial plan. |
| NEXTNODE | Selects the next node in the dial plan. |
| SETNAME | MML name of the result set |
| DIGIT | The individual number in a digit string. |
| DIGITTOPRESENT | Indicates the number of digits to skip (forward or backward) during analysis, if not set to 0. If set to 0, it is the next digit. |
| CALLSIDE | Indicates if the call side is originating or terminating. |
| DIGITSTRING | All the digits in a calling or called number. Not used with NEXTNODE, DIGIT, or INDEX. |
RESULTTABLE |
| Selects the result table in the dial plan. |
| NAME | MML name of the result. |
| RESULTTYPE | Indicates the type of result. Valid result types are: 1 through 6, 11 through 19, and 21 through 24. |
| DW1 | First data word. |
| DW2 | Second data word. |
| DW3 | Third data word. |
| DW4 | Fourth data word. |
| NEXTRESULT | Next result name. |
| SETNAME | MML name of the result set. |
DIGMODSTRING |
| Selects the digit string modification table in the dial plan. |
| DIGSTRING | Selects the digit string. |
ROUTING |
| Selects the route group. |
| ROUTEGRP | MML name of the previously defined route group. |
NOA |
| Selects the nature of address (NOA) table in the dial plan. |
| NPIINDEX | Indicates the NPI index value. |
| SETNAME | MML name of the result set. |
NPI |
| Selects the numbering plan indicator (NPI) table in the dial plan. |
| BLOCKVALUE | Selects the block value (0 through 15) of the current NPI index. |
| SETNAME | MML name of the result set. |
CAUSE |
| Selects the cause table in the dial plan. |
| LOCATIONINDEX | Selects the location index. |
| SETNAME | MML name of the result set. |
LOCATION |
| Indicates the location. |
| SETNAME | MML name of the result set. |
| BLOCKVALUE | Selects the block value (0 through 15) of the current Location index. |
SERVICE |
| Selects the service index table in the dial plan. |
| SVCNAME | MML name of the service. |
RESULTSET |
| Sets the result type in the result table in the dial plan. |
AWHITE |
| Selects the A-digit tree white list. |
| CLI | Sets the calling line identity (CLI) for the A-digit tree white list. |
ABLACK |
| Selects the A-digit tree black list. |
| CLI | Sets the calling line identity (CLI) for the A-digit tree black list. |
BWHITE |
| Selects the B-digit tree white list. |
| CLI | Sets the calling line identity (CLI) for the B-digit tree white list. |
| SVCNAME | MML name of the previously defined service. |
BBLACK |
| Selects the B-digit tree black list. |
| CLI | Sets the calling line identity (CLI) for the B-digit tree black list. |
| SVCNAME | MML name of the previously defined service. |
Table 2-46 lists the major MML commands used to implement the dial plan in Release 7.3(x).
| MML Parameter Name | TCM Parameter Name | Description |
|---|---|---|
numan-add | Number Analysis Add | Adds an element to the dial plan table. |
numan-dlt | Number Analysis Delete | Deletes an element from the dial plan table. |
numan-ed | Number Analysis Edit | Edits an element in the dial plan table. |
numan-rtrv | Number Analysis Retrieve | Retrieves an element from the dial plan table. |
prov-dply |
| Deploys the provisioning data. |
prov-cpy |
| Commits the provisioning data. |
Pre-analysis is used to perform number analysis that is based on the nature of address (NOA) or the numbering plan indicator (NPI). The incoming values for the NOA and the NPI are contained in the message transfer part level 2 (MTP2) initial address message (IAM).
The NOA table is used to define actions to be taken, based on the incoming NOA. Figure 2-22 is an example of a NOA table. The two fields in the NOA table are the NPI index and the result index. The NPI index is used to identify the analysis into the unique NPI block. If the NPI index is set to 0, no analysis is performed based on the NPI. The result index in the NOA table is used to associate a result set. If the result index is set to 0, then no action is to be taken at this time.
It is possible to have a result index on the NOA table configured and also to have an NPI index. However, if both the NPI index and the result index are set to 0, no analysis is performed.
Refer to "NOA and NPI Codes," for a list of the NOA codes for the protocol variants.
The NPI table is used to identify an associated result set. Figure 2-23 is an example of the NPI table. This table is accessed from the NOA table through the NPI index. The NPI index is used to refer to a block of 16 entries in the NPI table. The NPI value contained in the IAM is used as an offset into the NPI block. An action can be associated with a specific NPI value by associating a result set with the value in the NPI block.
Refer to "NOA and NPI Codes," for a list of the NPI codes for the protocol variants.
The cause table lists the cause codes generated when a call is either rejected or cleared by the system. The cause for release can be from either a result type (from either B-number analysis or cause analysis) or a failure (generated during call processing).
Figure 2-24 is an example of a cause table. The two fields in the cause table are the location index and the result index. The location index is used to identify the analysis into the location block. If the location index is set to 0, no analysis is performed based on the location. The result index in the cause table is used to associate a result set. If the result index is set to 0, then no action is to be taken at this time.
It is possible to have a location index on the cause table configured and have a result index. However, if both the location index and the result index are set to 0, no analysis is performed.
Refer to "Cause and Location Codes," for a list of the cause codes for the protocol variants. The cause codes are used as the release message for internal causes.
The location table is used to identify an associated result set. Figure 2-25 is an example of the location table. This table is accessed from the cause table through the location index. The location index is used to refer to a block of 16 entries in the location table. The location value is used as an offset into the location block. An action can be associated with a specific location value by associating a result set with the value in the location block.
The following information is intended to provide you with some tips and rules of thumb to follow when using the dial plan and number analysis program:
The following sections describe how you would create a dial plan for software Release 7.4(x).
The dial plan is used to identify unique calling or called number strings. Keep in mind the following issues when creating your dial plan:
These issues will be discussed and examples provided in the following sections. For purposes of example only, as many as six digits of any string will be analyzed. In your dial plan implementation, you might want to analyze additional digits.
The following numbers are examples of digit strings that will be used in the dial plan discussion:
703
703 484
301 555
301 684
40555
The starting node is a special node and is either a 1 (for originating) or a 2 (for terminating). All of the originating digit strings in the A-digit tree will share the starting node (1). Since node 2 is reserved for terminating digit strings, the first node available for use in this dial plan is node 3.
Before creating a result table, you must create some other tables first. These other tables define parameter values used by the result table. The other tables that must be created before the result table are:
In addition, a route group must be created before the ROUTE result type can be defined.
The digit modification table is the table in which the user defines the digit string for the selected digit modification name. Figure 2-34 is an example of a digit modification table. The digit modification string in the table is used to insert numbers into either the calling or called party number at the application point specified in either the AMODDIG or BMODDIG result type. Figure 2-47, located at the end of this chapter, can be copied and filled in to document the digit modification name and the associated digit modification string in your dial plan.
Call screening is a type of analysis done on the digit string to determine if the call is accepted or rejected. Refer to "Result Type Definitions," for more information on call screening.
A result action is the action that must be taken when the last digit in a digit string is reached. Refer to Table 2-47 for a list of the result types and their data words. Refer to "Result Type Definitions" for a definition of the result types and their associated data words.
The following figures show the dial plan tables and accompanying MML commands used to create the tables.
Figure 2-35 is an example of the digit modification table and the accompanying MML command.
Figure 2-36 is an example of a service name table and the accompanying MML command.
A result set is a grouping of results that can be connected to an A-digit tree, a B-digit tree, preanalysis, and cause analysis. Each result set consists of a grouping of one or more results. Each result set requires a unique name, and each result within a result set requires a unique name. The result set name can be as many as 20 alphanumeric characters in length. However, the result names do not need to be unique across result sets. It is the combination of the result set name and the result name that must be unique.
You can have only one result set for each digit string; however, you can have multiple results in a result set. When determining the result types for a result set, enter them in logical order; for example, from screening to route. The reason for this is that once a result set has result type with an endpoint analysis point, that is the end of the result set. You can have as many intermediate analysis point result types in a result set as you want. The result set table is used only for the purpose of configuration.
Figure 2-38 is an example of a result table and the accompanying MML commands. In the example shown in Figure 2-38, two of the result types (A_NUMBER_TYPE and BLACKLIST) have been connected together by using the same set name (set4) to create a result set. When the MML session is run, the last result in the result set has to be created first. If the last result in a result set is not created first, an error is generated because a next result cannot also be connected, because it does not exist.
The result table example shown in Figure 2-37 shows the relationship between the last digit of a digit string (703484) and the corresponding result (1) for this digit string. The result occurs on the last digit of a digit string. If more than one result is required for a digit string, a result set is used.
The result table example shown in Figure 2-38 lists the six values (Result Name, Result Type, Data Word 1, Data Word 2, Data Word 3, Data Word 4, and Next Result) that are included for each digit string in the result table. The data word values in the result table are determined by the values of the result type.
In Figure 2-38, the Result name for Result set1 is for the Screening result type. The value for Data Word 1 is 1, indicating a white list screening will be performed on the first digit string. The value for Data Word 2 is 1, indicating an index entry (called Washington) for the service name table from which a provisioned service name can be obtained.
Figure 2-39 is an example of digit strings for a B-digit tree and the accompanying MML commands.
Once you have created the previously described tables, you can create a dial plan text file containing all the MML commands, as shown in Figure 2-40. The first two lines in the text file are to start a provisioning session and to create a dial plan.
|
Note The digit string MML commands are entered in the reverse order in which they were created. |
Once you have filled in the dial plan worksheets (from Figure 2-45 through Figure 2-52) you must configure the Cisco MGC to implement your dial plan. When configuring the Cisco MGC, you will use the dial plan worksheets and either the MML commands listed in Table 2-47 or the available CMM parameters.
Table 2-48 describes the configuration parameters that apply to each dial plan you define.
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
DIALPLAN |
| Selects the customer-created dial plan. |
ADIGTREE |
| Selects the A-digit tree table in the dial plan. |
BDIGTREE |
| Selects the B-digit tree table in the dial plan. |
| SETNAME | MML name of the result set. |
| DIGIT | The individual number in a digit string. |
| DIGITTOPRESENT | Indicates the number of digits to skip (forward or backward) during analysis, if not set to 0. |
| CALLSIDE | Indicates if the call side is originating or terminating. |
| DIGITSTRING | All the digits in a calling or called number. |
RESULTTABLE |
| Selects the result table in the dial plan. |
| NAME | MML name of the result. |
| RESULTTYPE | Indicates the type of result. |
| DW1 | First data word. |
| DW2 | Second data word. |
| DW3 | Third data word. |
| DW4 | Fourth data word. |
| NEXTRESULT | Next result name. |
| SETNAME | MML name of the result set. |
DIGMODSTRING |
| Selects the digit string modification table in the dial plan. |
| NAME | MML name of the digit modification string |
| DIGSTRING | The digit string. |
NOA |
| Selects the nature of address (NOA) table in the dial plan. |
| NOAVALUE | The NOA value. |
| NPIBLOCK | The NPI block value. |
| SETNAME | MML name of the result set. |
NPI |
| Selects the numbering plan indicator (NPI) table in the dial plan. |
| NPIBLOCK | The NPI block. |
| BLOCKVALUE | The NPI block value. |
| SETNAME | MML name of the result set. |
CAUSE |
| Selects the cause table in the dial plan. |
| CAUSEVALUE | The cause value. |
| LOCATIONBLOCK | The cause location block. |
| SETNAME | MML name of the result set. |
LOCATION |
| Selects the location table in the dial plan. |
| LOCATIONBLOCK | The location block. |
| SETNAME | MML name of the result set. |
| BLOCKVALUE | The location block value. |
SERVICE |
| Selects the service index table in the dial plan. |
| NAME | MML name of the service. |
RESULTSET |
| Sets the result type in the result table in the dial plan. |
| NAME | MML name of the result set. |
AWHITE |
| Selects the A-digit tree white list. |
| CLI | Sets the calling line identity (CLI) for the A-digit tree white list. |
ABLACK |
| Selects the A-digit tree black list. |
| CLI | Sets the CLI for the A-digit tree black list. |
BWHITE |
| Selects the B-digit tree white list. |
| CLI | Sets the CLI for the B-digit tree white list. |
| SVCNAME | MML name of the previously defined service. |
BBLACK |
| Selects the B-digit tree black list. |
| CLI | Sets the calling line identity CLI for the B-digit tree black list. |
| SVCNAME | MML name of the previously defined service. |
Table 2-49 lists the major MML commands used to implement the dial plan in Release 7.4(x).
| MML Parameter Name | CMM Parameter Name | Description |
|---|---|---|
numan-add | Number Analysis Add | Adds an element to the dial plan table. |
numan-dlt | Number Analysis Delete | Deletes an element from the dial plan table. |
numan-ed | Number Analysis Edit | Edits an element in the dial plan table. |
numan-rtv | Number Analysis Retrieve | Retrieves an element from the dial plan table. |
prov-dply |
| Deploys the provisioning data. |
prov-cpy |
| Commits the provisioning data. |
prov-exp |
| Creates a dial plan export file in MML format for each configured dial plan. |
Pre-analysis is used to perform number analysis that is based on the nature of address (NOA) or the numbering plan indicator (NPI). The incoming values for the NOA and the NPI are contained in the message transfer part level 2 (MTP2) initial address message (IAM).
The NOA table is used to define actions to be taken, based on the incoming NOA. Figure 2-41 is an example of a NOA table. The two fields in the NOA table are the NPI index and the result index. The NPI index is used to identify the analysis into the unique NPI block. If the NPI index is set to 0, no analysis is performed based on the NPI. The result index in the NOA table is used to associate a result set. If the result index is set to 0, then no action is to be taken at this time.
It is only possible to have a result index on the NOA table configured or have an NPI index. However, if both the NPI index and the result index are set to 0, no analysis is performed.
Refer to "NOA and NPI Codes," for a list of the NOA codes for the protocol variants.
The NPI table is used to identify an associated result set. Figure 2-42 is an example of the NPI table. This table is accessed from the NOA table through the NPI index. The NPI index is used to refer to a block of 16 entries in the NPI table. The NPI value contained in the IAM is used as an offset into the NPI block. An action can be associated with a specific NPI value by associating a result set with the value in the NPI block.
Refer to "NOA and NPI Codes," for a list of the NPI codes for the protocol variants.
The cause table lists the cause codes generated when a call is either rejected or cleared by the system. The cause for release can be from either a result type (from either B-number analysis or cause analysis) or a failure (generated during call processing).
Figure 2-43 is an example of a cause table. The two fields in the cause table are the location index and the result index. The location index is used to identify the analysis into the location block. If the location index is set to 0, no analysis is performed based on the location. The result index in the cause table is used to associate a result set. If the result index is set to 0, then no action is to be taken at this time.
It is only possible to have a location index on the cause table configured or have a result index. However, if both the location index and the result index are set to 0, no analysis is performed.
Refer to "Cause and Location Codes," for a list of the cause codes for the protocol variants. The cause codes are used as the release message for internal causes.
The location table is used to identify an associated result set. Figure 2-44 is an example of the location table. This table is accessed from the cause table through the location index. The location index is used to refer to a block of 16 entries in the location table. The location value is used as an offset into the location block. An action can be associated with a specific location value by associating a result set with the value in the location block.
The following information is intended to provide you with some tips and rules of thumb to follow when using the dial plan and number analysis program:
Posted: Wed Sep 27 12:59:44 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.