Table Of Contents
DPNSS RouteOptimization
Feature Overview
Restrictions
Related Features and Technologies
Related Documentation
Supported Standards, MIBs, and RFCs
Prerequisites for Using this Feature
XECfgParm.dat Configuration Tasks
Configuring The XECfgParm.dat File For This Feature
Verifying the XECfgParm.dat Changes
Configuration Example
Provisioning Procedures
Provisioning This Feature
Adding DPNSS Connections
Modifying DPNSS Components
Deleting DPNSS Components
Provisioning Example
Troubleshooting Provisioning Errors
Alarm Troubleshooting Procedures
DPNSS Troubleshooting Procedures
Monitoring and Maintaining
Regular Operations
Managing Signaling Channels
Command Reference
New MML Commands
RTRV-CALLINFO_Display Call IDs of EISUP/SIP (Release 9.6(1))
Modified MML Commands
KILL-CALL—Terminate a Call (Release 9.6(1))
PRT-CALL_Print Call (Release 9.6(1))
Deleted MML Commands
Software Changes for this Feature
XECfgParm.dat Parameters
Planning for Provisioning
Collecting External Node Data
Collecting DPNSS Path Data
Collecting IP Route Data (optional)
Collecting SCTP Association Data
Provisioning Basics
Starting a Provisioning Session
Saving and Activating Your Provisioning Changes
Ending a Provisioning Session Without Activating Your Changes
Retrieving Provisioning Data
Measurements
Billing Interface
Route Optimization/Path Replacement Action (Tag: 4227)
Route Optimization/Path Replacement Call Reference (Tag: 4228)
Route Optimization/Path Replacement Trunk Group Info (Tag: 4229)
Route Optimization/Path Replacement Channel Info (Tag: 4230)
Route Optimization Switchover Timestamp (Tag: 4231)
Components
New Components
Modified Components
External Node Types
Properties
Provisioning Worksheets
Obtaining Documentation and Technical Assistance
Glossary
DPNSS RouteOptimization
Document Release History
Publication Date
|
Comments
|
July 13, 2006
|
Revised version of the document..
|
Feature History
Release
|
Modification
|
9.4(1)
|
The DPNSS Transparency feature was introduced on the Cisco MGC software.
|
9.6(1)
|
The DPNSS Route Optimization feature was introduced on the Cisco MGC software.
|
This document describes the DPNSS Route Optimization feature. This feature is described in the following sections:
•
Feature Overview
•Supported Standards, MIBs, and RFCs
•Prerequisites for Using this Feature
•XECfgParm.dat Configuration Tasks
•Provisioning Procedures
•Monitoring and Maintaining
•Command Reference
•Software Changes for this Feature
•Obtaining Documentation and Technical Assistance
•Glossary
Feature Overview
In various call transfer scenarios, an established call through a DPNSS network might not follow the optimum route between two end PBXs. The DPNSS Route Optimization feature enables a DPNSS PBX to obtain a new connection using a preferred route. Either the originating or terminating PBX can be responsible for establishing the new optimized connection. The PGW 2200 enables the DPNSS Route Optimization feature to function between DPNSS PBXs in call transfer scenarios.
On data calls, the use of the Route Optimization service might result in data loss, or corruption, at the moment when optimization takes place. Some PBXs might, therefore, reject requests to optimize data calls, or restrict optimization to calls where it is known that sufficient error detection and recovery procedures exist so that the consequent disruption of the data can be overcome.
An established call through a DPNSS network may follow a nonoptimum route for any of the following reasons:
•The call was established by means of Transfer (Three-Party supplementary service).
•The call was established as a result of a conference reducing to two parties (Three-Party supplementary service).
•An alternative route was used when the call was established because of congestion on the optimum route.
Whenever there is a possibility that a call follows a nonoptimum route (for example, after a transfer), the originating PBX may initiate route optimization. An attempt is made to obtain a new path from the terminating PBX to the originating PBX using the optimum route. Some or the entire existing path may be used if it already follows the optimum route and the PBXs concerned support single-channel working. When a new path has been obtained, the unwanted parts of the original path are released. The whole of the existing path is retained if it already follows the optimum route or if the optimum route is congested. In the latter case, the originating PBX may periodically try again.
Restrictions
The feature restrictions are listed below:
•Route Optimization is invoked only once for a call. Once invoked, if the call is transferred again, subsequent requests are rejected for the same call.
•PGW will invoke Route Optimization as a result of call transfer only.
•Route optimization will not occur on hairpinned calls.
•Route optimization will not occur on Cisco CallManager to Cisco CallManager calls.
Related Features and Technologies
The following documentation is available to describe additional features on the PGW 2200 (MGC) and IOS Gateways that enable interworking between DPNSS PBXs and Cisco CallManager.
•DPNSS Route Optimization
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/96/FMdp_rop.htm
•DPNSS Call Back And Extension Status Interworking with Cisco CallManager
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/96/fmcbk_ex.htm
•DPNSS Feature Transparency
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/941fm/fmdpnss.htm
Related Documentation
This document contains information that is related strictly to this feature. The documents that contain additional information related to the Cisco Media Gateway Controller (MGC) are listed below and can be found at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/index.htm
•Cisco Media Gateway Controller Hardware Installation Guide
•Regulatory Compliance and Safety Information for the Cisco Media Gateway Controller
•Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide
•Release Notes for Cisco Media Gateway Controller Software Release 9.6(1)
•Cisco Media Gateway Controller Software Release 9 Provisioning Guide
•Cisco Media Gateway Controller Software Release 9 Dial Plan Guide
•Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide
•Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide
•Cisco Media Gateway Controller Software Release 9 Messages Reference Guide
•Cisco Media Gateway Controller Software Release 9 Billing Interface Guide
•Cisco Media Gateway Controller Software Release 9 Management Information Base Guide
Supported Standards, MIBs, and RFCs
This section identifies the new or modified standards, MIBs, or RFCs that are supported by this feature.
Standards
Digital Private Network Signaling System DPNSS 189 Issue 4 - Interworking Between DPNSS1 and Other Signaling Protocols
http://www.nicc.org.uk/nicc-public/Public/interconnectstandards/dpnss/nd1302_2001_12.pdf
MIBs
New MIBs are available for this feature. There is a new MIB for each new measurement. You can find a list of the new measurements in
Measurements. For more information on the MIBs used in the Cisco MGC software, see the
Cisco Media Gateway Controller Software Release 9 Management Information Base Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgc_mib/index.htm
RFCs
•SCTP - RFC-2960
•IUA - RFC-3057
Prerequisites for Using this Feature
The Cisco PGW 2200 must be running Cisco MGC software Release 9.7(3). Prerequisites for this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release Cisco MGC Software Release 9.7(3) at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/relnote/rn973.htm.
All PBX's supporting this feature must have a unique routing number associated with each PBX. Each PGW also requires a unique routing number in context with the PBX network.
Property OwnRoutingNumber must be defined against each DPNSS sig path. During route optimization, this routing number is compared by each node being requested to perform route optimization to see if the request is applicable.
In DPNSS, there is no delimiter between Routing Number and Call reference fields of the DPNSS route optimization strings, therefore the length of the OwnRoutingNumber defined is used to determine where the routing number ends and the call reference begins. All PBXs and PGWs should have similar length routing numbers in order for the route optimization to work correctly.
All other PBX routing numbers will be require B digit analysis entries to determine how to reach the destination based on routing number. All the provisioned routing number decodes must select DPNSS routes or the service will be rejected.
XECfgParm.dat Configuration Tasks
You must configure the XECfgParm.dat file in the Cisco MGC software to enable this feature. The following sections describe the tasks related to configuring the XECfgParm.dat file for this feature:
•Configuring The XECfgParm.dat File For This Feature
•Verifying the XECfgParm.dat Changes
•Configuration Example
Configuring The XECfgParm.dat File For This Feature
This section contains the steps necessary for configuration of the next hop IP address in the XECfgParm.dat file to support this feature. If you are installing and configuring the Cisco MGC software on your system for the first time, use the procedures in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm
Come back to this section once you encounter the *.IP_NextHop1 parameter in the XECfgParm.dat file.
Note You need to configure the *.IP_NextHop parameters when the Cisco MGC hosts are on different subnets. If your hosts are on the same subnet, do not perform the procedure below.
Caution Configuration of the Cisco MGC software requires that the system software be shut down. In a simplex system, calls cannot be processed during system shutdown. In a continuous service system, your system loses the ability to maintain calls during a critical event while the system software on one of the PGW hosts is shut down.
Caution Do not modify the other XECfgParm.dat parameters associated with this feature.
To configure the next hop IP addresses, perform the following steps:
Step 1 If you have not already done so, open the /opt/CiscoMGC/etc/XECfgParm.dat file on the active and standby Cisco PGW hosts using a text editor, such as vi.
Step 2 If you have not already done so, ensure that the pom.dataSync parameter is set to false on the active and standby Cisco PGW hosts.
Step 3 Search for the *.IP_NextHop1 parameter and enter the IP address of your first next hop destination on the active and standby Cisco PGW hosts.
Note The IP address should be expressed in dotted decimal notation (for example, 10.25.81.5).
Step 4 Repeat Step 3 for every next hop destination (*.IP_NextHop2, *.IP_NextHop3, etc.) you want to identify on the active and standby Cisco PGW hosts. Up to eight next hop IP addresses can be specified.
Step 5 Return to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm
and continue from where you left off. You will need to go to Adding DPNSS Connections in this document later if you intend to use an IUA interface for data backhaul between your Cisco PGW 2200 and your associated Cisco access gateway(s).
Verifying the XECfgParm.dat Changes
To verify the XECfgParm.dat settings for this feature, perform the following steps:
Caution Do not modify the other XECfgParm.dat parameters associated with this feature.
Step 1 Log in to the standby Cisco MGC as root and change directories to the etc subdirectory by entering the following UNIX command:
Step 2 Open the XECfgParm.dat using a text editor, such as vi.
Step 3 Search for the *.IP_NextHop1 parameter and verify that the IP address of your first next hop destination is correct.
Note The IP address should be expressed in dotted decimal notation (for example, 10.25.81.5).
If the next hop IP address is correct, proceed to Step 4. Otherwise, correct the IP address and then proceed to Step 4.
Step 4 Repeat Step 3 for every next hop destination (*.IP_NextHop2, *.IP_NextHop3, and so forth) that you want to verify. You can specify up to eight next hop IP addresses.
Step 5 If all of your next hop destinations were correct, proceed to Step 9. Otherwise, proceed to Step 6.
If the next hop IP addresses you have entered are incorrect, perform the following steps. For more information on troubleshooting the rest of the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm
To ensure proper functioning of this feature, you must enter next hop IP addresses in the XECfgParm.dat file. These IP addresses are used when the next hop router IP addresses on the Cisco PGW hosts do not match. To enter next hop IP addresses, perform the following steps:
Step 6 Save your changes and close the text editor.
Step 7 Manually stop the Cisco MGC software on the standby Cisco MGC by entering the following UNIX command:
Step 8
/etc/init.d/CiscoMGC start
Step 9 Log in to the active Cisco MGC, start an MML session, and enter the following command:
Site alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state.
Step 10 Repeat steps 2 through 9 for the newly standby Cisco MGC host. Once you have verified the settings on both hosts, the procedure is complete.
Configuration Example
This section provides a configuration example for the XECfgParm.dat parameters associated with this feature. Additional configuration examples for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm
Note Configuration of XECfgParm.dat parameters for this feature is required only when the Cisco MGC hosts are not in the same subnet.
*.IP_NextHop1 = 147.21.135.10
*.IP_NextHop2 = 147.15.170.11
*.IP_NextHop3 = 0.0.0.0
*.IP_NextHop4 = 0.0.0.0
*.IP_NextHop5 = 0.0.0.0
*.IP_NextHop6 = 0.0.0.0
*.IP_NextHop7 = 0.0.0.0
*.IP_NextHop8 = 0.0.0.0
Provisioning Procedures
You must modify the provisioning data of your system to enable this feature. Before you begin provisioning this feature, we recommend that you plan your provisioning changes as described in Planning for Provisioning.
Tip You can find information on starting and ending provisioning sessions and retrieving provisioning data in Provisioning Basics.
The following sections describe the provisioning tasks related to this feature:
•Provisioning This Feature
•Provisioning Example
•Alarm Troubleshooting Procedures
Provisioning This Feature
Provision the transport path for DPNSS data between the Cisco PGW 2200 and the external Cisco access gateway nodes to provide a reliable communication path between the two platforms.
Perform this provisioning when an external node is modified to use an SCTP-based protocol or when a new external node is added to the Cisco PGW 2200. This section covers the following provisioning topics:
The following sections describe the provisioning tasks related to this feature:
•Deleting IP Routes
•Modifying DPNSS Components
•Deleting DPNSS Components
Adding DPNSS Connections
This section contains the procedures that you must perform to support DPNSS connections with your Cisco PGW 2200 provisioning data. When provisioning the components that enable the Cisco PGW 2200 to support DPNSS, perform the procedures in the following order.
•Adding Cisco Access Gateway External Nodes
•Adding IP Routes (Optional)
•Adding SCTP Associations
•Adding DPNSS Signaling Services
Adding Cisco Access Gateway External Nodes
To add Cisco access gateway external nodes, perform the following steps:
Step 1 Start a provisioning session as described in Starting a Provisioning Session.
Step 2 Enter the following command to add a Cisco access gateway external node:
prov-add:extnode:name="name", desc="description", type="as", isdnsigtype="iua"
Where:
•name—The name you want to give to the external node. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.
•description—The long name you assign to the node. It can be as many as 128 alphanumeric characters in length.
•as—The MML name for the type of Cisco access gateway. Valid values can be found in External Node Types.
For example, to add a Cisco access gateway external node named va-3600-36, you would enter the following command:
prov-add:extnode:name="va-3600-36", desc="3600", type="AS3600", isdnsigtype="iua"
Step 3 Repeat Step 2 for each Cisco access gateway external node you want to add to your provisioning data.
Step 4 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Otherwise, proceed to Adding IP Routes (Optional) if your Cisco PGW 2200 is on a different subnet from the associated access gateway, or proceed to Adding SCTP Associations if they are on the same subnet.
Adding IP Routes (Optional)
IP routes are required for your provisioning data if your Cisco PGW hosts are not on the same subnet as the Cisco access gateways. To add IP routes, perform the following steps:
Step 1 If you do not already have an active provisioning session, start one as described in Starting a Provisioning Session.
Step 2 Enter the following command to add an IP route:
prov-add:iproute:name="name", desc="description", netmask="mask", nexthop="nhop",
ipaddr="addr", dest="destination"
Where:
•name—The name you want to give to the IP route. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.
•description—The long name that you assign to the route. It can be as many as 128 alphanumeric characters in length.
•mask—Subnet mask of the destination (optional). The value should be expressed as an IP address in dotted decimal notation (default is 255.255.255.255).
•nhop—Next hop router hostname, IP address, or one of the following property names defined in the XECfgParm.dat file:
–IP_NextHop
–IP_NextHop2
–IP_NextHop3
–IP_NextHop4
–IP_NextHop5
–IP_NextHop6
–IP_NextHop7
–IP_NextHop8
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
The IP address should be in dotted decimal notation, and the host name must be less than or equal to 32 characters.
•addr—Local IP address. IP address should be one of the following property names defined in the XECfgParm.dat file:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
•destination—Destination hostname or IP address. IP address should be in dotted decimal notation and the hostname must be less than or equal to 32 characters.
For example, to add an IP route named iprte1, you would enter the following command:
prov-add:IPROUTE:NAME="iprte1", DESC="IP Route 1", dest="10.82.80.0", ipaddr="IP_Addr1",
netmask="255.255.255.0", nexthop="10.82.82.1"
Step 3 Repeat Step 2 for each IP route you want to add to your provisioning data.
Step 4 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Otherwise, proceed to Adding SCTP Associations.
Adding SCTP Associations
To add SCTP associations, perform the following steps:
Step 1 If you do not already have an active provisioning session, start one as described in Starting a Provisioning Session.
Step 2 Enter the following command to add an SCTP association:
prov-add:association:name="name", desc="description", type="IUA", ipaddr1="addr1",
ipaddr2="addr2", peeraddr1="paddr1", peeraddr2="paddr2", extnode="gway",
iproute1="iprte1", iproute2="iprte2"
Where:
•name—The name you want to give to the SCTP association. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.
•description—The long name that you assign to the association. It can be as many as 128 alphanumeric characters in length.
•addr1—First local IP address, as defined by the following XECfgParm.dat parameters:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
•addr2—Second local IP address, as defined by the following XECfgParm.dat parameters:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
–N/A (default value)
•paddr1—Highest priority destination address, expressed in dotted decimal notation.
•paddr2—Lowest priority destination address, expressed in dotted decimal notation. This parameter is optional. The default value for this parameter is 0.0.0.0.
•gway—MML name of a previously entered Cisco access gateway external node.
•iprte1—MML name of a previously entered IP route (optional).
•iprte2—MML name of a previously entered IP route (optional).
For example, to add an SCTP association named dpnssasassoc1, you would enter the following command:
prov-add:ASSOCIATION:NAME="dpnssassoc1",DESC="DPNSS Association 1", TYPE="IUA",
IPADDR1="IP_Addr1", IPADDR2="IP_Addr2", PEERADDR1="10.82.80.187",
PEERADDR2="10.82.81.164", extnode="va-3600-37, IPROUTE1="iprte1", IPROUTE2="iprte2"
Note The parameters listed above are those you need in order to create an SCTP association for an IUA interface. For a complete list of parameters for this component, see SCTP Association.
Step 3 Repeat Step 2 for each SCTP association you want to add to your provisioning data.
Step 4 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Note The parameters listed above are those you need in order to create an SCTP association for an IUA interface. For a complete list of parameters for this component, see SCTP Association.
Step 5 Repeat Step 2 for each SCTP association you want to add to your provisioning data.
Step 6 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Otherwise, proceed to Adding DPNSS Signaling Services.
Adding DPNSS Signaling Services
To add DPNSS signaling services, perform the following steps:
Step 1 If you do not already have an active provisioning session, start one as described in Starting a Provisioning Session.
Step 2 Enter the following command to add a DPNSS signaling service:
prov-add:dpnsspath:name="name", desc="description", extnode="mgw", abflag="side",
sigport=portnum, sigslot=slotnum
Where:
•name—The name you want to give to the signaling service. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.
•description—The long name you assign to the service. It can be as many as 128 alphanumeric characters in length.
•mgw—MML name of a previously defined external node. Valid types are:
–C2600
–AS3600
–AS3660
•side—DPNSS side for this signaling service (optional). Value values are A (for A side), B (for B side), and N (for not applicable) (N).
•portnum—Number for physical port on the access gateway (optional). Valid values: 0-167 (0).
•slotnum—Number for physical slot on the access gateway (optional). Valid values: 0-63 (0).
For example, to add a DPNSS signaling service named dpnsvc1, you would enter the following command:
prov-add:naspath:NAME="dpnsvc1",DESC="IUA DPNSS path", extnode="va-3660-20", abflag="a",
sigport=45, sigslot=10
Step 3 Repeat Step 2 for each DPNSS signaling service you want to add to your provisioning data.
Step 4 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Modifying DPNSS Components
The following sections contain the procedures you need to follow to modify the various IUA connections in your Cisco PGW 2200 provisioning data:
•Modifying Cisco Access Gateway External Nodes
•Modifying DPNSS Signaling Services
•Modifying IP Routes
•Modifying SCTP Associations
Modifying Cisco Access Gateway External Nodes
Desc is the only parameter that can be modified for an existing Cisco access gateway external node. To edit the description of a Cisco access gateway external node, perform the following steps:
Step 1 Start a provisioning session as described in Starting a Provisioning Session.
Step 2 Enter the following command to edit a Cisco access gateway external node:
prov-ed:extnode:name="name", desc="description"
Where:
•name—MML name of the Cisco access gateway external node to be modified.
•description—The long name you assign to the external nodes. It can be as many as 128 alphanumeric characters in length.
For example, to modify an Cisco access gateway external node named va-3600-37, you would enter the following command:
prov-ed:extnode:name="va-3600-37", desc="3600 supporting DPNSS"
Step 3 Repeat the above steps for each Cisco access gateway external node you want to modify in your provisioning data.
Step 4 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Modifying DPNSS Signaling Services
You can modify the description, DPNSS side identification, signaling port number, and signaling slot number in a DPNSS signaling service. To modify DPNSS signaling services, perform the following steps:
Step 1 Shut down the D-channel(s) on the associated access gateway(s). See the documentation for the access gateway for more information on shutting down D-channels.
Step 2 Set the DPNSS signaling services to be modified to the Out-of-Service (OOS) state by entering the following MML command:
Where sig_srv is the MML name of the DPNSS signaling services to be modified.
Step 3 Repeat Step 2 for each of the DPNSS signaling services to be modified.
Step 4 Start a provisioning session as described in Starting a Provisioning Session.
Step 5 Enter the following command to modify an DPNSS signaling service:
prov-ed:dpnsspath:name="name", desc="description", abflag="side", sigport=portnum,
sigslot=slotnum
Where:
•name—MML name of the component to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•mgw—MML name of a previously defined external node. Valid types are:
–C2600
–AS3600
–AS3660
•side—DPNSS side for this signaling service (optional). Value values are A (for A side), B (for B side), and N (for not applicable) (N)
•portnum—Number for physical port on the access gateway (optional). Valid values: 0-167 (0).
•slotnum—Number for physical slot on the access gateway (optional). Valid values: 0-63 (0).
For example, to modify the DPNSS side identification on a DPNSS signaling service named dpnsvc1, you would enter the following command:
prov-ed:dpnsspath:NAME="dpnsvc1", abflag="n"
Step 6 Repeat Step 5 for each DPNSS signaling service you want to modify in your provisioning data.
Step 7 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Step 8 Set the modified DPNSS signaling services to the In-Service (IS) state by entering the following MML command for each signaling service:
Where sig_srv is the MML name of the modified DPNSS signaling service.
Step 9 Restore the D-channel(s) on the associated access gateway(s). See the documentation for the media gateway for more information on shutting down D-channels.
Modifying IP Routes
The only IP route parameter that cannot be modified is the name. To modify IP routes, perform the following steps:
Step 1 Set the IP route to be modified to the OOS state.
Step 2 Repeat Step 1 for each IP route to be modified.
Step 3 Start a provisioning session as described in Starting a Provisioning Session.
Step 4 Enter the following command to modify an IP route:
prov-ed:iproute:name="name", desc="description", netmask="mask", nexthop="nhop",
ipaddr="addr", dest="destination"
Where:
•name—MML name of the IP route to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•mask—Subnet mask of the destination (optional). The value should be expressed as an IP address in dotted decimal notation (default is 255.255.255.255).
•nhop—Next hop router hostname, IP address, or one of the following property names defined in the XECfgParm.dat file:
–IP_NextHop
–IP_NextHop2
–IP_NextHop3
–IP_NextHop4
–IP_NextHop5
–IP_NextHop6
–IP_NextHop7
–IP_NextHop8
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
The IP address should be in dotted decimal notation and the host name must be less than or equal to 32 characters.
•addr—Local IP address. The IP address should be one of the following property names defined in the XECfgParm.dat file:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
•destination—Destination host name or IP address. The IP address should be in dotted decimal notation and the hostname must be less than or equal to 32 characters.
For example, to modify the destination and local IP address in an IP route named iparte1, you would enter the following command:
prov-ed:IPROUTE:NAME="iprte1", dest="10.82.80.1", ipaddr="IP_Addr2"
Step 5 Repeat the Step 4 for each IP route you want to modify in your provisioning data.
Step 6 If there are no other components that you need to provision, end your provisioning session, as described in Saving and Activating Your Provisioning Changes.
Step 7 Set the IP route to be modified to the IS state.
Modifying SCTP Associations
Only the name, type, and extnode parameters cannot be modified for an SCTP association. To modify SCTP associations, perform the following steps:
Step 1 Set the SCTP association to be modified to the OOS state.
Step 2 Repeat Step 1 for each SCTP association to be modified.
Step 3 Start a provisioning session, as described in Starting a Provisioning Session.
Step 4 Enter the following command to modify an SCTP association:
prov-ed:association:name="name", desc="description", ipaddr1="addr1", ipaddr2="addr2",
peeraddr1="paddr1", peeraddr2="paddr2", iproute1="iprte1", iproute2="iprte2"
Where:
•name—MML name of the SCTP association to be modified.
•description—The long name you assign to the association. It can be as many as 128 alphanumeric characters in length.
•addr1—First local IP address, as defined by the following XECfgParm.dat parameters:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
•addr2—Second local IP address, as defined by the following XECfgParm.dat parameters:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
–N/A (default value)
•paddr1—Highest priority destination address, expressed in dot notation.
•paddr2—Lowest priority destination address, expressed in dot notation. This parameter is optional. The default value for this parameter is 0.0.0.0.
•iprte1—MML name of a previously entered IP route (optional).
•iprte2—MML name of a previously entered IP route (optional).
For example, to modify the local IP addresses for an SCTP association named dpnssassoc1, you would enter the following command:
prov-ed:ASSOCIATION:NAME="dpnssassoc1", IPADDR1="IP_Addr2", IPADDR2="IP_Addr3"
Step 5 Repeat Step 4 for each SCTP association you want to modify in your provisioning data.
Step 6 If there are no other components that you need to provision, end your provisioning session as described in Saving and Activating Your Provisioning Changes.
Step 7 Set the SCTP association to be modified to the IS state.
Deleting DPNSS Components
The following sections contain the procedures for deleting the DPNSS components in your Cisco PGW 2200 provisioning data:
•Deleting Cisco Access Gateway External Nodes
•Deleting DPNSS Signaling Services
•Deleting IP Routes
•Deleting SCTP Associations
Deleting Cisco Access Gateway External Nodes
To delete Cisco access gateway external nodes, perform the following steps:
Step 1 Set the interface on the external node that is associated with the Cisco MGC software to the OOS state. See the documentation for your media gateway for more information on taking interfaces OOS.
Step 2 Delete the signaling service(s) associated with this external node. To delete a DPNSS signaling service, perform the steps in Deleting DPNSS Signaling Services.
Step 3 If your system uses IP routes for this external node, delete the IP routes, as described in Deleting IP Routes.
Step 4 Delete the SCTP associations for this external node, as described in Deleting IP Routes.
Step 5 Enter the following command to delete a Cisco access gateway external node:
prov-dlt:extnode:name="name"
Where name is the MML name of the Cisco access gateway external node to be deleted.
For example, to delete a Cisco access gateway external node named va-3600-37, you would enter the following command:
prov-dlt:extnode:name="va-3600-37"
Step 6 Repeat the above steps for each Cisco access gateway external node you want to delete from your provisioning data.
Deleting DPNSS Signaling Services
To delete DPNSS signaling services, perform the following steps:
Step 1 Log in to the active Cisco MGC, start an MML session, and enter the following command:
Where sig_srv is the MML name of the desired signaling service.
For example, to set the service state of a signaling service called sigsrv1 to OOS, enter the following command:
Step 2 Block all of the CICs associated with this signaling service using the following MML command:
Where sig_svc is the MML name of the signaling service associated with the CICs to be blocked.
Step 3 Delete the bearer channels associated with this signaling service using the following MML command:
prov-dlt:switchtrnk:dstsrv="sig_svc", "all"
Where sig_svc is the MML name of this signaling service.
Step 4 If trunk groups are provisioned for this signaling service, delete the trunk groups using the following MML command:
prov-dlt:trnkgrp:dstsrv="sig_svc", "all"
Where sig_svc is the MML name of this signaling service.
Step 5 Enter the following command to delete a DPNSS signaling service:
prov-dlt:dpnsspath:name="name"
Where name is the MML name of the DPNSS signaling service to be deleted.
For example, to delete a DPNSS signaling service named dpnsvc1, you would enter the following command:
prov-dlt:DPNSSPATH:NAME="dpnsvc1"
Step 6 Repeat the above steps for each DPNSS signaling service you want to delete from your provisioning data.
Deleting IP Routes
To delete IP routes, perform the following steps:
Step 1 Set the service state of the IP route to OOS.
Step 2 Delete any components that used this route as a parameter. To delete SCTP associations, perform the steps found in Deleting SCTP Associations .
Step 3 Enter the following command to delete an IP route:
prov-dlt:iproute:name="name"
Where name is the MML name of the IP route to be deleted.
For example, to delete an IP route named iprte1, you would enter the following command:
prov-dlt:IPROUTE:NAME="iprte1"
Step 4 Repeat the above steps for each IP route you want to delete from your provisioning data.
Deleting SCTP Associations
To delete SCTP associations, perform the following steps:
Step 1 Set the service state of the SCTP association to OOS.
Step 2 Enter the following command to delete an SCTP association:
prov-dlt:association:name="name"
Where name is the MML name of the association you want to delete.
For example, to delete an SCTP association named nasassoc1, you would enter the following command:
prov-dlt:ASSOCIATION:NAME="nasassoc1"
Step 3 Repeat the above steps for each SCTP association you want to delete from your provisioning data.
Provisioning Example
This section provides an example of provisioning for the DPNSS feature. Additional examples of provisioning for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:IPROUTE:NAME="iprte1",DEST="10.82.80.0",NETMASK="255.255.255.0",NEXTHOP="10.82.82
.1",IPADDR="IP_Addr1",DESC="IP Route 1"
prov-add:IPROUTE:NAME="iprte2",DEST="10.82.81.0",NETMASK="255.255.255.0",NEXTHOP="10.82.82
.1",IPADDR="IP_Addr2",DESC="IP Route 2"
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:extnode:NAME="va-2600-165",TYPE="SLT",DESC="2611 SLT RUDP E1"
prov-add:extnode:NAME="va-2600-166",TYPE="SLT",DESC="2611 SLT RUDP E1"
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:OPC:NAME="opc",DESC="Own pointcode",NETADDR="1.1.3",NETIND=2,TYPE="TRUEOPC"
prov-add:DPC:NAME="dpc1",DESC="Destination pointcode1",NETADDR="1.1.1",NETIND=2
prov-add:DPC:NAME="dpc2",DESC="Destination pointcode2",NETADDR="1.1.2",NETIND=2
________________________________________
; Signal Services to Inet via SLT
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7PATH:NAME="ss7svc1",DESC="SS7 to dpc1",DPC="dpc1", OPC="opc", MDO="Q761_BASE"
prov-add:SS7PATH:NAME="ss7svc2",DESC="SS7 to dpc2",DPC="dpc2", OPC="opc", MDO="Q761_BASE"
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:LNKSET:NAME="ls1",DESC="linkset 1 to dpc1",APC="dpc1",PROTO="SS7-ITU",TYPE="IP"
prov-add:LNKSET:NAME="ls2",DESC="linkset 2 to dpc2",APC="dpc2",PROTO="SS7-ITU",TYPE="IP"
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7ROUTE:NAME="rte1",DESC="SS7 Rte
1-dpc1",OPC="opc",DPC="dpc1",LNKSET="ls1",PRI=1
prov-add:SS7ROUTE:NAME="rte2",DESC="SS7 Rte
2-dpc2",OPC="opc",DPC="dpc2",LNKSET="ls2",PRI=1
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:sessionset:NAME="slt1",ipaddr1="IP_Addr1",ipaddr2="IP_Addr2", PORT=7000,
PEERADDR1="10.82.80.188",PEERADDR2="10.82.81.165",PEERPORT=7000,extnode="va-2600-165",
TYPE="BSMV0",IPROUTE1="iprte1", IPROUTE2="iprte2"
prov-add:sessionset:NAME="slt2",ipaddr1="IP_Addr1",ipaddr2="IP_Addr2",
PORT=7000,PEERADDR1="10.82.80.191",PEERADDR2="10.82.81.166",PEERPORT=7000,
extnode="va-2600-166", TYPE="BSMV0",IPROUTE1="iprte1", IPROUTE2="iprte2"
________________________________________
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:C7IPLNK:NAME="ls1lk1",DESC="SS7ANSI", LNKSET="ls1",
sessionset="slt1",SLC=0,PRI=1,TIMESLOT=0
prov-add:C7IPLNK:NAME="ls2lk1",DESC="SS7ANSI",
LNKSET="ls2",sessionset="slt1",SLC=0,PRI=1,TIMESLOT=2
prov-add:C7IPLNK:NAME="ls1lk2",DESC="SS7ANSI", LNKSET="ls1",
sessionset="slt2",SLC=1,PRI=1,TIMESLOT=0
prov-add:C7IPLNK:NAME="ls2lk2",DESC="SS7ANSI",
LNKSET="ls2",sessionset="slt2",SLC=1,PRI=1,TIMESLOT=2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:EXTNODE:NAME="va-3660-20",TYPE="AS3660",DESC="IUA DPNSS", ISDNSIGTYPE="IUA"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:ASSOCIATION:NAME="dpnssassoc2",ipaddr1="IP_Addr3",ipaddr2="IP_Addr4",
PEERADDR1="10.82.80.31",PEERADDR2="10.82.81.31", extnode="va-3660-20",
TYPE="IUA",IPROUTE1="iprte1",IPROUTE2="iprte2"
Troubleshooting Provisioning Errors
The following sections contain troubleshooting procedures related to provisioning:
•Alarm Troubleshooting Procedures
•DPNSS Troubleshooting Procedures
For more information on troubleshooting the rest of the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm
Note The route optimization service is typically associating two distinct calls. During call tracing using sta-sc-trc and prt-call, it is important to note that the entire call flow can only be seen by retrieving and analyzing both calls associated with the optimized call.
Alarm Troubleshooting Procedures
The alarms listed below are the new and modified alarms associated with this feature that require user action. For a complete list of Cisco MGC alarms, see the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/errmsg/index.htm
Note The route optimization service is typically associating two distinct calls. During call tracing using sta-sc-trc it is important to and prt-call, note that the entire call flow will only be seen by retrieving and analyzing both calls associated with the optimized call.
LCM: Invalid destination for RO/PR routing number
RO Request Routing number does not translate to a DPNSS trunk group.
Corrective Action
Verify that the dial-plans associated with the DPNSS incoming trunk group translate to the routing numbers in the PBX network.
LCM: No Response from Call Instance
LCM did not receive a message response within the expected time period.
Corrective Action
Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see Obtaining Documentation and Technical Assistance. If there are multiple occurrences of this alarm (for example:, more than one per day), disable RO/PR and escalate the problem.
DPNSS Troubleshooting Procedures
The following DPNSS troubleshooting procedures are new for this feature:
•Message Waiting Indicator (MWI) not Working On User's Phone
•Problems After Call Transfers
•Call Back Problems Such As "Service Not Available" On The User's Phone
•Call Back When Free or Call Back When Busy Not Working
•Problems with AXL Security Settings
•Problems with AXL Security Settings
Message Waiting Indicator (MWI) not Working On User's Phone
Step 1 Check the MWI String On and MWI Off String configuration. Ensure that they are set to the appropriate MWI on or off string (not Null). The string should match that used on the PBX.
Step 2 Check the dial plan CCM MWI settings to verify that the CCM MWI On Number and CCM MWI Off Number match the numbers defined in Cisco CallManager.
Problems After Call Transfers
There may be a problem with the Route Optimization feature. Ensure that OwnRoutingNumber is configured. Route optimization is enabled only if this property is configured. If it is not, then the service is not enabled for the given signalling path.
Call Back Problems Such As "Service Not Available" On The User's Phone
Check the following:
Step 1 Are there alarms for either the CTI manager or AXL server:
Step 2 If there is an alarm (such as FAIL) for the component, check the Signalling Status for the CTI Manager or AXL Server. If the component is out of service, verify that the CTI Manager or AXL Server User Name and Password match that on the Cisco CallManager
Call Back When Free or Call Back When Busy Not Working
For Cisco PGW to handle Call Back features, you must deactivate the features in Cisco CallManager. How you do this depends on your version of Cisco CallManager.
To Deactivate Call Back in Cisco CallManager 4.1:
Step 1 From the Cisco CallManager Administration window, choose Service > Service Parameters. The Service Parameters Configuration window appears.
Step 2 From the dropdown Server list, choose your server, and from the dropdown Service list, choose Cisco CallManager. The Service Parameters Configuration window displays parameters for Cisco CallManager.
Step 3 Scroll down to Clusterwide Parameters (Feature - Call Back) and ensure that Callback Enabled Flag is set to False. If the current setting is True, select False from the dropdown list.
Step 4 Return to the top of the window (shortcut: Ctrl+Home) and click Update. The updated parameter is applied.
Step 5 When the update is complete, restart Cisco CallManager:
a. From the Windows Start menu, choose Programs > Administrative Tool, then choose Services.
b. From the Services menu, choose Cisco CallManager.
c. Click Action > Restart.
Cisco CallManager restarts with the Call Back Enabled feature disabled.
To Deactivate Call Back in Cisco CallManager 4.0(x)
Follow the steps in "Deactivating Cisco CallManager Services" in the Services Activation chapter of the Cisco CallManager Serviceability Administration Guide. In Step 4, uncheck Cisco Extended Functions (CEF).
Problems with AXL Security Settings
Ensure you have configured the AXL Server properties this way:
•For AXL Server Username, enter the Windows administrator user name (that is, Administrator) as configured on Cisco CallManager.
•For AXL Server Password, enter the Windows administrator user password.
For other problems, refer to the "AXL Troubleshooting " chapter, especially the Post-Installation Checklist, in the Cisco CallManager API Troubleshooting Guide.
Monitoring and Maintaining
The following sections contain the procedures required for proper monitoring and maintenance of this feature. For more information on operational tasks for the rest of the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm
Regular Operations
Introduction of the DPNSS Feature Transparency feature requires new procedures for managing signaling channels.
Managing Signaling Channels
The following sections are new or modified for Release 9.4:
•Retrieving the Service State of an Association
•Retrieving the Service State of an IP Route
Retrieving the Service State of an Association
To retrieve the service state for an individual association, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-association:assoc_name
For example, to retrieve the service state of an association called assoc1, enter the following command:
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 20:26:18
To retrieve attributes for all of the associations, log in to the active Cisco MGC, start an MML session, and enter the following command:
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 19:23:23
The valid service states for an association are described in the following sections. If the association is in any state other than IS, attempt to bring it into service, as described in Message Waiting Indicator (MWI) not Working On User's Phone.
Primary Service State of an Association
The PST field shows the current primary service state of the association. Table 1 lists the valid primary service state values.
Table 1 Primary Service State of an Association
Link State ID
|
Link State
|
Description
|
INB
|
Install busy
|
When a system is first configured, all associations default to this state.
|
IS
|
In-service
|
Association is IS and fully operational. This is its normal operating state.
|
OOS
|
Out-of-service
|
Association is OOS. The system is actively trying to restore the association.
|
Secondary Service State of an Association
The SST field shows the current secondary service state of the specified association. Table 2 lists the valid secondary service state values.
Table 2 Association Secondary Service States of an Association
Link State ID
|
Link State
|
Description
|
COOS
|
Commanded out-of-service
|
Association has been commanded OOS by the operator.
|
STBY
|
Standby
|
Association is on the standby Cisco MGC.
|
CONF
|
Configuration
|
Association is OOS due to a configuration failure.
|
Retrieving the Service State of an IP Route
To retrieve the service state for an individual IP route, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-iproute:iproute_name
For example, to retrieve the service state of an IP route called iprte1, enter the following command:
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 20:26:18
To retrieve attributes for all of the IP routes, log in to the active Cisco MGC, start an MML session, and enter the following command:
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 19:23:23
The valid service states for an IP route are described in the following sections. If the route is in any other state than IS, attempt to bring it into service.
Primary Service State of an IP Route
The PST field shows the current primary service state of the IP route. Table 3 lists the valid primary service state values:
Table 3 IP Route Primary Service States
Link State ID
|
Link State
|
Description
|
IS
|
In-service
|
Route is IS and fully operational. This is its normal operating state.
|
OOS
|
Out-of-service
|
Route is OOS. The system is actively trying to restore the link.
|
Secondary Service State of an IP Route
The SST field shows the current secondary service state of the specified IP route. Table 4 lists the valid secondary service state values:
Table 4 IP Route Secondary Service States
Link State ID
|
Link State
|
Description
|
COOS
|
Commanded out-of-service
|
Route has been commanded OOS by the operator.
|
STBY
|
Standby
|
Routes are on the standby Cisco MGC.
|
OFF_DUTY
|
Off duty
|
Route is available for use, but not currently being used.
|
CONF
|
Configuration
|
Route is OOS due to a configuration failure.
|
Command Reference
This section documents new, modified, or deleted Man-Machine Language (MML) commands. All other MML commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide at the following location:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mmlref/index.htm
New MML Commands
This section contains the MML commands that are new for this feature.
RTRV-CALLINFO_Display Call IDs of EISUP/SIP (Release 9.6(1))
The following new MML command, RTRV-CALLINFO, provides the ability to display the call IDs of all EISUP/SIP calls on the system. Optional parameters provide the ability to display the To and From numbers or to display calls established longer than a specified time period. The PRT-CALL and KILL-CALL commands are updated to support EISUP to EISUP Calling.
Purpose:
|
This MML command displays the EISUP/SIP call IDs of all EISUP/SIP calls on the PGW system.This command replaces rtrv-sip.
|
Syntax:
|
rtrv-callinfo:target:[all|eisup|sip|ip|TDM]| [,calltime=minutes] [,detail]
|
Input Description:
|
•target—MML name of the media gateway controller, gateway, or trunk group associated with the call.
•all—Displays all calls from the target using EISUP/SIP protocols. Half calls can be retrieved with this option.
•eisup—Displays EISUP to EISUP calls from the target.
•sip—Displays SIP to SIP calls from the target.
•ip—Displays SIP, EISUP, or H323 calls from the target.
•TDM—Displays all SIP to TDM protocol calls, including SS7, ISDN, DPNSS, QSIG calls from the target.
•calltime—Displays calls that have been established on the system for the specified period, in minutes. For example, calltime=120 displays all calls established for 2 hours or more.
•detail—Displays the To and From numbers.
|
Examples:
|
mml> rtrv-callinfo:eisup-sigpath:all
mml> rtrv-callinfo:eisup-sigpath:ip
mml> rtrv-callinfo:all:timerperiod=120
mml> rtrv-callinfo:sip:timerperiod=120,detail
|
Modified MML Commands
This section contains the MML commands that were modified for the Route Optimization feature.
KILL-CALL—Terminate a Call (Release 9.6(1))
Purpose:
|
This MML command resolves a stuck or hung CIC associated with a single call instance or a range of calls.
|
Syntax:
|
kill-call:<sigpath>:CID=eisip_callid,nodeid=nodeid,confirm
kill-call:{sigpath|target}:[span=number,]confirm
kill-call:{sigpath|target}:[span=number,][BC=number,][RNG=number,]confirm
kill-call:{sigpath|target}:CIC=number of CIC,[RNG=number,]confirm
kill-call:{sigpath|target}:CID=sip call id,confirm
|
Input Description:
|
•sigpath—MML name of the SS7 or ISDN-PRI signal path associated with the stuck CIC.
•target—MML name of the media gateway controller, gateway, or trunk group associated with the stuck span and bearer channel.
•span—Number of the affected span.
•BC—Number of the affected bearer channel.
•RNG—Number that represents a range of affected bearer channels or CICs.
•CIC—Number of the affected Circuit Identification Code.
•CID—Unique call identifier.
|
Example:
|
mml> KILL-CALL:eisup-sigpath:cid="454545",nodeid=28871553,confirm
mml> KILL-CALL:sip-sigpath:
cid="ccdd33ee-423fdedd-55438954-1@172.22.119.215",confirm
mml> KILL-CALL:ss7svc1:CIC=1,confirm
mml> KILL-CALL:tg-4444:confirm
mml> KILL-CALL:sip-sigpath:CID="ewrtdegdfg-eytergt-dfgd@cisco.com",
confirm
|
PRT-CALL_Print Call (Release 9.6(1))
Purpose:
|
This MML command prints diagnostic information about an active call to a log file.
|
Syntax:
|
prt-call:<sigpath>:CID=<eisup_callid>,nodeid=<nodeid>,LOG=<logname>
prt-call:{sigpath}:[CIC=number,|span=number,][BC=number,|CID=number,]
LOG="log name"
|
Input Description:
|
•sigpath—Name of the EISUP/SIP signal path, the route of a signal channel that carries signaling data.
•CIC—Numeric value that identifies the ISUP circuit identification code number.
•span—16-bit value that identifies an ISDN/PRI physical cable.
•BC—Number that identifies the non-ISUP bearer channel. BC is used for non-ISUP trunks; use CIC for ISUP trunks.
•CID—Unique call identifier.
•LOG—ASCII log file to which the output is written. This entry is used as a prefix to the filename which includes the signal path name, creation date, and time. If no log filename is entered, a default name consisting of the signal path, date, and time is created.
|
Example:
|
mml> prt-call:eisup-sigpath:cid="5954",nodeid=28871553,log="logname"
mml> prt-call:sip-sigpath:cid="ccdd33ee-423fdedd-55438954-1@172.22.119.215"
,log="logname"
mml> PRT-CALL:ss7svc1:cic=1,LOG="log1"
mml> PRT-CALL:pri-sigpath:span=1,BC=2,LOG="log2"
mml> PRT-CALL:sip-sigpath:CID="kjhfqekugher-hdekjfh-fjkreh-ghf@cisco.com",
LOG="logsip"
|
Deleted MML Commands
This section lists the MML commands deleted for this feature.
•rtrv-sip
Software Changes for this Feature
The following sections contain software changes related to this feature:
•XECfgParm.dat Parameters
•Planning for Provisioning
•Provisioning Basics
•Measurements
•Billing Interface
•External Node Types
•Properties
•Provisioning Worksheets
XECfgParm.dat Parameters
The XECfgParm.dat file configuration parameters added for this feature are in the table below.
Configuration Parameter
|
Definition
|
*.IUA.maxNasExtNodes
|
Specifies the maximum number of external nodes that can be defined with an ISDN signaling type of IUA. This number also represents the maximum number of IUA associations that can be provisioned.
Valid value: 256
Note Do not change this value.
|
*.IUA.maxNasPathsPerExtNode
|
Defines the maximum number of NAS signaling services that can be assigned to each external node with an ISDN signaling type of IUA.
Valid value: 112
Note Do not change this value.
|
*.IUA.maxNasPaths
|
Defines the maximum number of IUA signaling services that can be provisioned.
Valid value:1500
Note Do not change this value.
|
*.IP_NextHop1
*.IP_NextHop2
*.IP_NextHop3
*.IP_NextHop4
*.IP_NextHop5
*.IP_NextHop6
*.IP_NextHop7
*.IP_NextHop8
|
Defines the IP addresses of up to eight next hop counters. These IP addresses are used when the next hop router IP addresses on the Cisco PGW hosts do not match.
Default: 0.0.0.0
Valid values: An IP address expressed in dotted decimal notation.
|
For information on the other XECfgParm.dat parameters, see the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm
Planning for Provisioning
This section lists the data that you must gather to successfully provision this feature. For more information on planning the provisioning for the rest of the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
Collecting External Node Data
The external node component type represents another node with which the MGC communicates. You must be ready to enter the following data:
•MML name
•Component description
•Type of the external node
•ISDN signaling type
The parameters for EXTNODE are defined in Table 14.
Collecting DPNSS Path Data
The path data represents an DPNSS signaling service to a particular Cisco access gateway. See Restrictions for more information on the Cisco access gateways that require the use of a DPNSS signaling service. You must be ready to enter the following data:
•Unique ID of this component and component name used in MML commands
•Component description
•MML name of the associated external node
•Customer group ID
•Identification of the DPNSS path as either A side, B side, or neither
•Signaling port number (physical port on the Cisco access gateway)
•Signaling port slot (physical slot on the Cisco access gateway)
The DPNSS signaling service component structure is shown in Table 17.
Collecting IP Route Data (optional)
The IP route represents a static IP route. IP routes are required for this feature only when the Cisco PGW hosts are not on the same subnet as the Cisco access gateways. If your system requires IP routes, you must be ready to enter the following data:
•IP route name
•Component description
•Destination hostname or IP address
•Subnet mask of Destination (optional)
•Next hop router IP address
•Local IP address
•Priority
The IP route component information can be listed in Table 18.
Collecting SCTP Association Data
The Stream Control Transmission Protocol (SCTP) association represents the connection between the Cisco MGC and a Cisco access gateway. You must be ready to enter the following data:
•MML name of the SCTP association.
•Description of this component.
•Signaling type.
•MML name of the signaling gateway process (SGP).
•First local address.
•Second local address (optional).
•Local SCTP port number (optional).
•The highest priority destination address.
•The lowest priority destination address (optional).
•Destination SCTP port number. (optional).
•MML name of the external node.
•MML name of first IPROUTE (optional).
•MML name of second IPROUTE (optional).
•Number of bytes to advertise for the local receive window (optional).
•Maximum number of times to retransmit SCTP INIT message (optional).
•Maximum initial timer retransmission value (optional).
•Maximum number of retransmissions over all destination addresses before the association is declared failed (optional).
•Maximum time after a datagram is received before a SCPT SACK is sent (optional).
•Maximum time SCTP waits for other outgoing datagrams for bundling (optional).
•Minimum value allowed for the retransmission timer (optional).
•Maximum value allowed for the retransmission timer (optional).
•Time between heartbeats. The heartbeat is this value plus the current retransmission timeout value (optional).
•Internet protocol precedence. This value is placed in the IP PRECEDENCE portion of the Type Of Service field for outgoing SCTP datagrams (optional).
•Differential Service Code Point (DSCP). This value is placed in the DSCP portion of the Type Of Service field for outgoing SCTP datagrams (optional).
•Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before it is declared failed (optional).
The SCTP association component structure is shown in Table 19.
Provisioning Basics
Follow these procedures to start a provisioning session, to save, activate and retrieve the provisioning data.
•Starting a Provisioning Session
•Saving and Activating Your Provisioning Changes
•Ending a Provisioning Session Without Activating Your Changes
•Retrieving Provisioning Data
For more detailed information about provisioning your Cisco PGW 2200, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
Starting a Provisioning Session
You may need to start a provisioning session as part of your system operations. To do this, log into the active Cisco MGC, start an MML session, and enter the following command:
prov-sta::srcver="curr_ver",dstver="mod_ver"
Where:
•curr_ver—The name of the current configuration version. In place of the name of the current configuration version, you can also enter
–new—A new default session configuration; no existing source configuration is available.
–active—Selects the active configuration as the source for configuration changes.
Note If you do not know the name of your current configuration session, you can use the procedure in Retrieving Data on the Current Provisioning Session.
•mod_ver—A new configuration version name for a version that contains your provisioning changes.
For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:
prov-sta::srcver="ver1",dstver="ver2"
Once a provisioning session is underway, you may use the prov-add, prov-ed, or prov-dlt MML commands to add, modify, and delete components on your system. This document describes how to add, modify, and delete M3UA and SUA components. For more information on provisioning other components on your Cisco PGW 2200, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
There are two ways to close your provisioning session:
•Saving and activating your provisioning changes, as described in Saving and Activating Your Provisioning Changes
•Ending your provisioning session without saving and activating your changes, as described in Ending a Provisioning Session Without Activating Your Changes.
Saving and Activating Your Provisioning Changes
When you have completed making provisioning changes in your session, you must enter a command to save and activate your changes. There are two different provisioning MML commands that do this: prov-cpy and prov-dply.
Caution Using the
prov-cpy or
prov-dply MML commands can severely impact your system's call processing performance, depending on the extent of your provisioning changes. We recommend that you issue these commands during a maintenance window when traffic is minimal.
Use the prov-cpy MML command to save and activate your changes on the active Cisco MGC. This command is typically used to save and activate changes on a Cisco MGC in a simplex configuration. However, you can use the prov-cpy MML command on Cisco MGCs in high-availability or continuous-service configurations, to save and activate your changes on the active Cisco MGC. If you choose to do this, you should enter the prov-sync MML command immediately afterwards, to have your changes saved and activated on the standby Cisco MGC.
Note When you enter the prov-cpy command, your provisioning session is automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session as described in Starting a Provisioning Session.
Caution Using the
prov-sync MML command can severely impact your system's call processing performance. We recommend that you issue these commands during a maintenance window when traffic is minimal.
Note When the prov-sync MML command is used to synchronize the provisioning settings on the standby MGC host with current settings on the active MGC host, the system does not indicate when the synchronization process has failed.
Use the prov-dply MML command to save and activate your changes on the active and standby Cisco MGCs. This command is typically used to save and activate changes on Cisco MGCs in a high-availability or continuous-service configurations. Do not use this command on a Cisco MGC in a simplex configuration.
Note When you enter the prov-dply command, your provisioning session is automatically ended, unless an error occurs during execution. If you want to make additional provisioning changes, you must start a new provisioning session as described in Starting a Provisioning Session.
Ending a Provisioning Session Without Activating Your Changes
You may want to end a provisioning session without saving and activating the changes you have entered during your session. If this is the case, you can enter the prov-stp MML command. This command ends your current provisioning session and your changes are not entered.
Retrieving Provisioning Data
You can use the prov-rtrv MML command to retrieve information about your current provisioning settings. The ways in which you can use this command to retrieve provisioning data are described in the following sections:
•Retrieving Data for an Individual Component
•Retrieving Data for Select Components
•Retrieving Data for All Components of a Particular Type
•Retrieving Data on the Current Provisioning Session
Retrieving Data for an Individual Component
You can retrieve provisioning data for any individual component on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:component:name=MML_name
Where:
•component—The MML component type associated with the desired component. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
•MML_name—The MML name for the desired component. You can determine the MML names for the various components using the prov-rtrv:all MML command.
For example, to view the provisioning data for an IUA signaling service called iua1, you would enter the following command:
prov-rtrv:sigsvcprop:name="iua1"
The system returns a response similar to the following:
Retrieving Data for Select Components
You can retrieve data on select the components provisioned on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
Note This command returns data on all signaling components, except for signaling service and linkset properties.
The system returns a response similar to the following:
<< get system response >>
Retrieving Data for All Components of a Particular Type
You can retrieve provisioning data on all components of a particular type on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:component:"all"
Where component is the MML component type associated with the desired component group. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
Note You cannot use this command for components that are used to retrieve signaling or routing properties (that is sigsvcprop, lnksetprop, and trnkgrpprop). The properties for only one signaling or routing component can be listed per command instance. Use the following format:
prov-rtrv:propComp:name="compName" | name="ss7famName"
Where:
propComp—MML component name appropriate to the property type you want to retrieve, as listed below:
sigsvcprop—Provides maintenance access to the properties of signaling services
trnkgrpprop—Provides maintenance access to the properties of trunk groups
lnksetprop—Provides maintenance access to the properties of linksets
compName—MML name of a previously provisioned signaling service or trunk group
ss7famName—MML name of the SS7 family associated with the desired linkset
For example, to view the provisioning data for all signaling services, you would enter the following command:
The system returns a response similar to the following:
<< get system response >>
Retrieving Data on the Current Provisioning Session
You can retrieve provisioning data on the current provisioning session. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2003-01-13 13:39:19
Measurements
Table 5 contains the system measurements that are added to support this feature. For information on the other system measurements, see the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm
Table 5 New Operational Measurements
MML Counter Group: Name
|
Description
|
Related Components
|
Logging Interval
|
CALL GROUP
CALL:RoInvokesSent
CALL:RoInvokesReceived
CALL:RoCompleted
CALL:RoDenials Sent
CALL:RoDenialsReceived
CALL:InvalidMsgDestination
|
CALL message statistics
This counter is incremented each time an RO invocation request is internally generated and sent out over the DPNSS interface.
This counter is incremented each time an RO invocation request is received over the DPNSS interface at a point of inter-working.
This counter is incremented each time the RO feature is actioned and concludes successfully.
This counter is incremented each time an RO invocation request is refused by the PGW and sent out over the DPNSS interface.
This counter is incremented each time an RO rejection/refusal is received over the DPNSS interface.
This counter is incremented each time an internal message cannot be delivered because the destination call reference does not exist (or no longer exists).
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
Billing Interface
This section identifies the call detail record (CDR) data added for this feature. For billing interface information for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Billing Interface Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/billinf/index.htm
Route Optimization/Path Replacement Action (Tag: 4227)
Table 6 `Route Optimization/Path Replacement Action (Tag: 4227)
Name: RO/PR EXECUTED
|
Tag: 4227
|
Source: MDL
|
|
Description/Purpose: Indicates that the RO or PR service has resulted in the replacement of media channels.
|
|
Format: Structured variable
|
Length in Octets: 1
|
|
Data Value:
RO/PR operation = 1 indicates RO/PR feature invocation.
RO/PR operation = 2 indicates receipt of RO/PR feature invocation.
RO/PR operation = 3 indicates RO/PR feature loop back call (combined original. and term.).
RO/PR operation = 4 indicates an incoming RO/PR slave half call.
RO/PR operation = 5 indicates an outgoing RO/PR slave half call.
|
|
ANSI/ITU Variations: None.
|
|
Extended Data Value: No extended value.
|
|
General Information:
|
|
MGC Release: Release 9.6(1) and later.
|
|
|
Answered (1010)
|
Deselected (1020)
|
Aborted (1030)
|
Release (1040)
|
Interrupted (1050)
|
Ongoing (1060)
|
Slave Long Duration Call (1061)
|
Maintenance (1070)
|
External DB (1080)
|
End of Call (1110)
|
Slave End of Call (1111)
|
N
|
N
|
N
|
Y
|
N
|
N
|
Y
|
N
|
N
|
Y
|
Y
|
Route Optimization/Path Replacement Call Reference (Tag: 4228)
Table 7 Route Optimization/Path Replacement Call Reference (Tag: 4228)
Name: RO/PR OTHER CALL REF
|
Tag: 4228
|
Source: MDL
|
|
Description/Purpose: Indicates the call reference of the associated call instance.
|
|
Format: Structured variable
|
Length in Octets: 8
|
|
Data Value:
See tag 4002
|
|
ANSI/ITU Variations: None.
|
|
Extended Data Value: No extended value.
|
|
General Information:
|
|
MGC Release: Release 9.6(1) and later.
|
|
|
Answered (1010)
|
Deselected (1020)
|
Aborted (1030)
|
Release (1040)
|
Interrupted (1050)
|
Ongoing (1060)
|
Slave Long Duration Call (1061)
|
Maintenance (1070)
|
External DB (1080)
|
End of Call (1110)
|
Slave End of Call (1111)
|
N
|
N
|
N
|
Y
|
N
|
N
|
Y
|
N
|
N
|
Y
|
Y
|
Route Optimization/Path Replacement Trunk Group Info (Tag: 4229)
Table 8 Route Optimization/Path Replacement Trunk Group Info (Tag: 4229)
Name: RO/PR REPLACEMENT TRK GROUP
|
Tag: 4229
|
Source: MDL
|
|
Description/Purpose: Indicates the trunk group id of the new replaced media channel associated with the other call reference.
|
|
Format: Structured variable
|
Length in Octets: 2
|
|
Data Value:
See tag 4008.
|
|
ANSI/ITU Variations: None.
|
|
Extended Data Value: No extended value.
|
|
General Information:
|
|
MGC Release: Release 9.6(1) and later.
|
|
|
Answered (1010)
|
Deselected (1020)
|
Aborted (1030)
|
Release (1040)
|
Interrupted (1050)
|
Ongoing (1060)
|
Slave Long Duration Call (1061)
|
Maintenance (1070)
|
External DB (1080)
|
End of Call (1110)
|
Slave End of Call (1111)
|
N
|
N
|
N
|
Y
|
N
|
N
|
N
|
N
|
N
|
Y
|
N
|
Route Optimization/Path Replacement Channel Info (Tag: 4230)
Table 9 Route Optimization/Path Replacement Channel Info (Tag: 4230)
Name: RO/PR REPLACEMENT CHAN ID
|
Tag: 4230
|
Source: MDL
|
|
Description/Purpose: Indicates that the channel id of the new media path.
|
|
Format: Structured variable
|
Length in Octets: 2
|
|
Data Value:
See tag 4009.
|
|
ANSI/ITU Variations: None.
|
|
Extended Data Value: No extended value.
|
|
General Information:
|
|
MGC Release: Release 9.6(1) and later.
|
|
|
Answered (1010)
|
Deselected (1020)
|
Aborted (1030)
|
Release (1040)
|
Interrupted (1050)
|
Ongoing (1060)
|
Slave Long Duration Call (1061)
|
Maintenance (1070)
|
External DB (1080)
|
End of Call (1110)
|
Slave End of Call (1111)
|
N
|
N
|
N
|
Y
|
N
|
N
|
N
|
N
|
N
|
Y
|
N
|
Route Optimization Switchover Timestamp (Tag: 4231)
Table 10 Route Optimization Switchover Timestamp (Tag: 4231)
Name: RO/PR SWITCHOVER TIMESTAMP
|
Tag: 4231
|
Source: MDL
|
|
Description/Purpose: Indicates the point in time that media replacement occurred.
|
|
Format: Structured variable
|
Length in Octets: 4
|
|
Data Value:
Time in UNIX format.
|
|
ANSI/ITU Variations: None.
|
|
Extended Data Value: No extended value.
|
|
General Information:
|
|
MGC Release: Release 9.6(1) and later.
|
|
|
Answered (1010)
|
Deselected (1020)
|
Aborted (1030)
|
Release (1040)
|
Interrupted (1050)
|
Ongoing (1060)
|
Slave Long Duration Call (1061)
|
Maintenance (1070)
|
External DB (1080)
|
End of Call (1110)
|
Slave End of Call (1111)
|
N
|
N
|
N
|
Y
|
N
|
N
|
N
|
N
|
N
|
Y
|
N
|
Components
The sections below describe the provisioning components that are added and modified for this feature. For information on the rest of the components in the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
New Components
The provisioning components listed in the following sections are added for this feature.
DPNSS Signaling Service
The DPNSS signaling service component type represents a DPNSS signaling path that is back-hauled over IP to/from a NAS (destination). Its MML name is DPNSSPATH.
Table 11 shows the DPNSS signaling service component structure.
Table 11 DPNSS Signaling Service Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
IP route name
|
The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.
|
DESC
|
Component description
|
The description can be up to any 128 characters.
|
EXTNODE
|
External node MML name
|
MML name of a previously defined external node.
|
CUSTGRPID
|
Customer group ID
|
Four digit ID; (0000).
|
ABFLAG
|
DPNSS Side
|
Valid values are a (for A side), b (for B side), and n (for not applicable); (n).
|
SIGSLOT
|
Physical Slot on the NAS defining the NFAS Group (optional)
|
An integer, 0 through 63; (0).
|
SIGPORT
|
Physical Port on the slot of NAS defining the NFAS Groupl. (optional)
|
An integer, 0 through 167.
|
The following parameters cannot be modified:
•NAME
•EXTNODE
The following rules apply when you create or edit DPNSS signaling paths:
•The maximum number of combined DPNSSPATHs and IUA NASPATHs per IUA external node is 112.
•An ASSOCIATION must be defined with the same EXTNODE attribute as the DPNSSPATH. If this ASSOCIATION has not been defined when the DPNSSPATH is added/edited, a warning is issued. If the ASSOCIATION still has not been defined when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.
•If the ASSOCIATION with the same EXTNODE value as the DPNSSPATH is deleted, a warning message is issued to inform you that the DPNSSPATH must also be deleted. If it has not been deleted when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.
IP Route
The IP route is static and it's MML name is IPROUTE.
Table 12 shows the IP route component structure.
Table 12 IPROUTE Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
IP route name
|
The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.
|
DESC
|
Component description
|
The description can be up to 128 characters in any combination.
|
DEST
|
Destination host name or IP address
|
IP address in decimal notation or a host name that is less than or equal to 32 characters.
|
NETMASK
|
Subnet mask of Destination (optional)
|
IP address in decimal notation. (255.255.255.255).
|
NEXTHOP
|
Next hop router IP address
|
IP address or host name that is less than or equal to 32 characters, or one of the following property names defined in XECfgParm.dat:
IP_NextHop1, IP_NextHop2, IP_NextHop8,
IP_Addr1, IP_Addr2, or IP_Addr4.
|
IPADDR
|
Local IP address
|
IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.
|
PRI
|
Priority
|
1 through 65535; (1).
|
Note NAME is the only parameter for this command that cannot be modified.
To create or edit IP routes, follow these rules:
•The NETMASK attribute is validated by the system. For your provisioning setup to work correctly, its value (when converted to binary) must have at least one leading 1 and cannot have any trailing 1s after the first 0. The values 255.255.0.0 and 255.255.255.128 are valid. The values 0.0.255.255, 255.0.0.255, and 0.0.0.0 are invalid.
•Ensure that the destination resolves to a non-zero address.
•When the resolved destination address is bit ORed with the netmask value, the result is equal to the netmask. For example, a destination of 10.11.12.13 and a netmask of 255.255.0.0 are invalid because the ORed result would be 255.255.12.13, which is not equal to 255.255.0.0.
•The combination of DESTINATION, NETMASK, and IPADDR must be unique for each IP route.
•The combination of DESTINATION, NETMASK, and PRI must be unique for each IP route.
•When an IP route is specified in a link object (for example, IPLNK, SESSIONSET, or ASSOCIATION), the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes to verify that the IPROUTE is valid.
•When an IP route is specified in a link object (for example, IPLNK, SESSIONSET, or ASSOCIATION), the IPADDR must match the IPADDR of the link.
•When an IPROUTE is not specified for a link object (having that option), the IP address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it should not be assigned an IPROUTE. If the PEERADDR is on the same subnet as the DESTINATION (based on the NETMASK), and if the IPADDR matches the IPADDR of the link object, then use IPROUTE.
•If the NEXTHOP attribute is a host name or symbolic name from XECfgParm.dat, it can resolve to the address 0.0.0.0, which indicates that the IPROUTE is not used. The IPROUTE status shows up in the rtrv-iproute:all command output when in the OOS, OFF_DUTY state.
•If the resolved NEXTHOP address is not 0.0.0.0, it must be on the same subnet as the IPADDR.
The commands to retrieve the service state of an IP route can be found in Retrieving the Service State of an IP Route.
SCTP Association
The SCTP association represents the connection between the Cisco MGC and a Cisco access gateway, and its MML name is ASSOCIATION.
Table 13 Association Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
Unique ID of this component and component name used in MML commands.
|
The name can be up to 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with an alphabetic character.
|
DESC
|
Unique ID of this component and component name used in MML commands.
|
The name can be up to 128 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with an alphabetic character.
|
TYPE
|
Signaling type.
|
The type of protocol to be used. Values: M3UA, SUA, and IUA
|
SGP
|
SGP's MML name (optional).
|
MML name of a previously configured SGP. Used for M3UA and SUA interfaces.
|
IPADDR1
|
First local address.
|
IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.
|
IPADDR2
|
Second local address (optional).
|
IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4, or N/A, (N/A).
|
PORT
|
Local SCTP port number (optional).
|
From 1024 through 65535.
Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.
|
PEERADDR1
|
The highest priority destination address.
|
IP address.
|
PEERADDR2
|
The lowest priority destination address (optional).
|
IP address; (0.0.0.0).
|
PEERPORT
|
Destination SCTP port number (optional).
|
From 1024 through 65535.
Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.
|
EXTNODE
|
External Node's MML name (optional).
|
MML name of a previously configured external node. Used in IUA interfaces.
|
IPROUTE1
|
MML Name of first IPROUTE (optional).
|
MML name of a previously configured IPROUTE.
|
IPROUTE2
|
MML Name of second IPROUTE (optional).
|
MML name of a previously configured IPROUTE.
|
RCVWIN
|
Number of bytes to advertise for the local receive window. (optional).
|
From 1500 through 65535; (18000).
|
MAXINITRETRANS
|
Maximum number of times to retransmit SCTP INIT message (optional).
|
0 through 100; (10)
0 means use SCTP internal default.
|
MAXINITRTO
|
Maximum initial timer retransmission value (optional).
|
0, 300 through 3000 (2000).
0 means use SCTP internal default.
|
MAXRETRANS
|
Maximum number of retransmissions over all destination addresses before the association is declared failed (optional).
|
From 1 through 10 (5).
Note This value is not to exceed MAXRETRANSDEST * the number of destinations.
|
CUMSACKTO
|
Maximum time after a datagram is received before a SCPT SACK is sent (optional).
|
From 100 through 500 ms; (300).
|
BUNDLETO
|
Maximum time SCTP waits for other outgoing datagrams for bundling (optional).
|
From 100 through 600 ms; (100).
|
MINRTO
|
Minimum value allowed for the retransmission timer (optional).
|
From 300 through 3000 ms; (300).
|
MAXRTO
|
Maximum value allowed for the retransmission timer (optional).
|
From 1000 through 3000 ms; (3000).
|
HBTO
|
Time between heartbeats. The heartbeat will be this value plus the current retransmission timeout value (optional).
|
The value can be 0, or from 300 through 10000 ms; (2000).
0 means disabled.
|
IPPRECEDENCE
|
Internet Protocol Precedence. This value is placed in the IP PRECEDENCE portion of the Type Service field for outgoing SCTP datagrams (optional).
|
ROUTINE 000
PRIORITY 001
IMMEDIATE 010
FLASH 011
FLASH-OVERRIDE 100
CRITICAL 101
INTERNET 110
NETWORK; (ROUTINE) 111
|
DSCP
|
Differential Service Code Point (DSCP). This value is placed in the DSCP portion of the Type Service field for outgoing SCTP datagrams (optional).
|
EF 101110—Expedited Forwarding
AF11 001010—Assured Forwarding
Class 1 Low Drop Precedence
AF12 001100—Assured Forwarding
Class 1 Medium Drop Precedence
AF13 001110—Assured Forwarding
Class 1 High Drop Precedence
AF21 010010—Assured Forwarding
Class 2 Low Drop Precedence
AF22 010100—Assured Forwarding 2
Medium Drop Precedence
AF23 010110—Assured Forwarding
Class 2 High Drop Precedence
AF31 011010—Assured Forwarding
Class 3 Low Drop Precedence
AF32 011100—Assured Forwarding
Class 3 Medium Drop Precedence
AF33 011110—Assured Forwarding
Class 3 High Drop Precedence
AF41 100010—Assured Forwarding
Class 4 Low Drop Precedence
AF42 100100—Assured Forwarding
Class 4 Medium Drop Precedence
AF43 100110—Assured Forwarding
Class 4 High Drop Precedence
N/A; (N/A)
|
MAXRETRANSDEST
|
Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before it is declared failed (optional).
|
From 1 through 10; (3).
|
Table 13 shows the SCTP association component structure.
The following parameters cannot be modified:
•NAME
•EXTNODE
•TYPE
•SGP
To create or edit SCTP associations, follow these rules:
•Only one association with a type of IUA can be assigned to an external node.
•If the type of the association is IUA, the associated external node must have its ISDN signaling type set to IUA, and that external node must be able to support IUA signaling.
•If two associations have the same port value, the values of IPADDR1 and IPADDR2 must either be the same or both must be different.
•The values of IPADDR1 and IPADDR2 must be different.
•If the value of IPPRECEDENCE is not ROUTINE, the value of DSCP must be N/A.
•If the value of DSCP is not N/A, the value of IPPRECEDENCE must be ROUTINE.
•The value of MAXRTO must be greater than or equal to the value of MINRTO.
•When a peer IP address (PEERADDR1 or PEERADDR2) is not on the local subnet of IPADDR1 or IPADDR2, that peer IP address cannot be on the subnet of any other local interface, even if it is not defined within the Cisco MGC software.
•When a peer IP address (PEERADDR1 or PEERADDR2) is not on the local subnet of IPADDR1 or IPADDR2, an IP route (IPROUTE1 or IPROUTE2, respectively) must be specified.
•When an IP route is specified, the values set in PEERADDR1 and PEERADDR2 are checked against the DESTINATION and NETMASK values of the IP route(s) to verify that the IP route is valid.
•When an IP route is specified, its value for IPADDR must match the related IP address of the association. In other words, IPROUTE1 should have an IPADDR that matches IPADDR1 on the association, and IPROUTE 2 should have an IPADDR that matches IPADDR2 on the association.
•When an IP route is not specified, the IP address resolved from the PEERADDR1 or PEERADDR2 parameter is checked against the defined IP routes to verify that it should not be assigned to one of those IP routes. If the peer address is on the same subnet as an IP route, the link should use that IP route.
•The value of PEERADDR1 cannot be 0.0.0.0 or 255.255.255.255, and the value of PEERADDR2 cannot be 255.255.255.255.
•When a host name is specified for a peer IP address, the host name must resolve to an IP address.
•PEERADDR1 and PEERADDR2 can resolve to the same IP address. If the external node has only one IP address and two IP addresses (IPADDR1 and IPADDR2) are defined, PEERADDR2 should be set to the same value as PEERADDR1.
•Associations, session sets, IP links, SIP links, and SS7 signaling gateway links that share a peer address (that is, PEERADDR, PEERADDR1, or PEERADDR2) must be assigned directly or indirectly to the same external node.
•When you are deleting an association and a NASPATH uses the same external node, a warning message is issued to inform you that the NASPATH must also be deleted. If it has not been deleted when the provisioning session is copied or deployed, an error message is generated and the copy or deployment stops.
•The value of PORT cannot be set to the same value as the PORT attribute of any IP link, session set, SIP link, or SS7 signaling gateway link.
•If a value for IPADDR2 or PEERADDR2 is specified, values for IPADDR1 and PEERADDR1 must also be specified. In other words, you cannot have one local address and two remote addresses, or two local addresses and one remote address.
•An IP link, session set, SS7 signaling gateway link, or another association with a different external or signaling gateway node cannot use the resolved value set in PEERADDR1 or PEERADDR2.
•Only one association can be defined to an SS7 signaling gateway process (SGP).
•A value for EXTNODE can be defined only when the association type is IUA.
•A value for SGP can be defined only when the association type is M3UA or SUA.
•The maximum number of associations with a type of M3UA is defined in the XECfgParm.dat parameter, M3UA.maxSgp.
•The maximum number of associations with a type of SUA is defined in the XECfgParm.dat parameter, SUA.maxSgp.
The commands to retrieve the service state of an IP route can be found in Retrieving the Service State of an IP Route.
Modified Components
The following components are modified for this feature.
External Node
The external node component type represents another node with which the MGC communicates. Its MML name is EXTNODE.
The parameters for EXTNODE are defined in Table 14.
Table 14 External Node Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
MML name
|
The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.
|
DESC
|
Component description
|
The description can be up to 128 characters.
|
TYPE
|
The type of the external node
|
Valid values can be found in External Node Types.
|
ISDNSIGTYPE
|
ISDN Signaling Type
|
Valid values are IUA and N/A (default is N/A). This parameter was added in software Release 9.4(1)T.
|
GROUP
|
M3UA/SUA Group Number
|
Value is 1-100 for M3UA or SUA nodes. Value is 0 for nodes that do not support M3UA or SUA. This parameter was added in software Release 9.4(1)T.
|
Note DESC is the only parameter for this command that can be modified:
The following rules apply when creating/editing external nodes:
•TYPE must be one of the valid external node types.
•The maximum number of external nodes with an ISDNSIGTYPE of IUA is 256.
External Node Types
Table 15 lists the valid external node types for Release 9.6(1)T of the Cisco MGC software.
.
Table 15 External Node Types for Cisco MGC Software Release 9.6(1)
ExtNode MML Type
|
SGCP
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
NAS
|
MGCP
ANNO
|
MGCP
IVR
|
SUA
|
Other
|
AS5200
|
|
|
IPFAS
|
|
|
NAS
|
|
|
|
|
AS5300
|
SGCP
|
MGCP
|
IPFAS
|
IUA
|
|
NAS
|
MGCP
ANNO
|
MGCP
IVR
|
|
|
AS5350
|
SGCP
|
MGCP
|
IPFAS
|
IUA
|
|
NAS
|
MGCP
ANNO
|
MGCP
IVR
|
|
BSMV0
|
AS5400
|
SGCP
|
MGCP
|
IPFAS
|
IUA
|
|
NAS
|
MGCP
ANNO
|
MGCP
IVR
|
|
BSMV0
|
AS5800
|
|
|
IPFAS
|
|
|
NAS
|
MGCP
ANNO
|
|
|
|
AS5850
|
|
MGCP
|
IPFAS
|
IUA
|
|
NAS
|
MGCP
ANNO
|
MGCP
IVR
|
|
|
AS7200
|
SGCP
|
MGCP
|
IPFAS
|
|
|
NAS
|
|
|
|
|
C1751
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C1760
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2600
|
SGCP
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2610XM
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2611XM
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2620XM
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2621XM
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2650XM
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2651XM
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C2691
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C3600
|
SGCP
|
MGCP
|
IPFAS
|
|
|
|
|
|
|
|
C3640
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C3640A
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C3660
|
SGCP
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
NAS
|
|
|
|
|
C3725
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
C3745
|
|
MGCP
|
IPFAS
|
IUA
|
BRI
|
|
|
|
|
|
CAT8510
|
SGCP
|
MGCP
|
|
|
|
|
|
|
|
|
CAT8540
|
SGCP
|
MGCP
|
|
|
|
|
|
|
|
|
CCMCLUSTER
|
|
|
|
|
|
|
|
|
|
|
H323
|
|
|
|
|
|
|
|
|
|
EISUP
|
ITP
|
|
|
|
|
|
|
|
|
SUA
|
M3UA
|
LIMD
|
|
|
|
|
|
|
|
|
|
LI
|
LS1010
|
SGCP
|
MGCP
|
|
|
|
|
|
|
|
|
MC3810
|
|
MGCP
|
IPFAS
|
|
|
|
|
|
|
|
MGC
|
|
|
|
|
|
|
|
|
|
EISUP
|
MGX8260
|
|
MGCP
|
IPFAS
|
|
|
NAS
|
|
|
|
|
MGX8850
|
SGCP
|
MGCP
|
|
|
|
|
|
|
|
|
SCP
|
|
|
|
|
|
|
|
|
|
TCAPIP
|
SLT
|
|
|
|
|
|
|
|
|
|
BSMV0
|
TALISS7
|
|
|
|
|
|
|
|
|
|
SS7SG
|
UNKNOWN
|
|
|
|
|
|
|
|
|
|
UNKNOWN
|
VISM
|
SGCP
|
MGCP
|
IPFAS
|
|
|
|
|
|
|
|
VXSM
|
SGCP
|
MGCP
|
IPFAS
|
|
|
|
|
|
|
|
Properties
New properties have been added to the following MML commands to configure loop avoidance, calling name display, call transfer, message waiting indication, and routing numbers for Route Optimization or Path Replacement:
•prov-add:sigsvcprop
•prov-add:trnkgrpprop
LoopAvoidanceSupport
Purpose:
|
This property enables the support of the loop avoidance feature in DPNSS protocol.
|
Valid Values:
|
0, 1
|
Default Value:
|
0
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssvc2", LoopAvoidanceSupport = "1"
mml>prov-add:trnkgrpprop:name="3333", LoopAvoidanceSupport = "1"
|
LoopAvoidanceCounter
Purpose:
|
This property enables the support of the loop avoidance feature in DPNSS protocol.
|
Valid Values:
|
Any integer
|
Default Value:
|
0
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssvc2", LoopAvoidanceCounter ="3"
mml>prov-add:trnkgrpprop:name="3333", LoopAvoidanceCounter ="3"
|
InhibitIncomingCallingNameDisplay
Purpose:
|
This property enables or disables inhibit incoming calling name display.
|
Valid Values:
|
•0 to enable
•1 to disable
|
Default Value:
|
0, i.e., Enabled
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssv1",
InhibitIncomingCallingNameDisplay ="1"
mml>prov-add:trnkgrpprop:name="2222", InhibitIncomingCallingNameDisplay
="1"
|
InhibitOutgoingCallingNameDisplay
Purpose:
|
This property enables or disables inhibit outgoing calling name display.
|
Valid Values:
|
•0 to enable
•1 to disable
|
Default Value:
|
0, i.e., Enabled
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssv1",
InhibitOutgoingCallingNameDisplay ="1"
mml>prov-add:trnkgrpprop:name="2222", InhibitOutgoingCallingNameDisplay
="1"
|
InhibitIncomingConnectedNameDisplay
Purpose:
|
This property enables or disables inhibit incoming connected name display.
|
Valid Values:
|
•0 to enable
•1 to disable
|
Default Value:
|
0, i.e., Enabled
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssv1",
InhibitIncomingConnectedNameDisplay ="1"
mml>prov-add:trnkgrpprop:name="2222", InhibitIncomingConnectedNameDisplay
="1"
mml>prov-add:sigsvcprop:name="dpnsssv1",
InhibitIncomingConnectedNumberDisplay ="1"
mml>prov-add:trnkgrpprop:name="2222",
InhibitIncomingConnectedNumberDisplay ="1"
mml>prov-add:sigsvcprop:name="dpnsssv1",
|
InhibitOutgoingConnectedNameDisplay
Purpose:
|
This property enables or disables inhibit outgoing connected name display.
|
Valid Values:
|
•0 to enable
•1 to disable
|
Default Value:
|
0, i.e., Enabled
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
InhibitOutgoingConnectedNameDisplay ="1"
mml>prov-add:trnkgrpprop:name="2222", InhibitOutgoingConnectedNameDisplay
="1"
mml>prov-add:sigsvcprop:name="dpnsssv1",
InhibitOutgoingConnectedNumberDisplay ="1"
mml>prov-add:trnkgrpprop:name="2222",
InhibitOutgoingConnectedNumberDisplay ="1"
|
MwiStringON
Purpose:
|
This property enables the support of MWI to the DPNSS protocol to turn on the MWI lamp on a particular extension when this string is encoded in message.
|
Valid Values:
|
Digit string with minimum length=0, maximum length=32
Note The digit string provisioned should be the same MWI string provisioned in Cisco CallManager.
|
Default Value:
|
NULL
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssvc2", MwiStringON = "*58*AN*0#"
mml>numan-add:digmodstring:custgrpid="1111",name="mwion",digstring="40855
56666"
mml>
numan-add:resulttable:custgrpid="1111",name="rtab1t49",resulttype="BNBRMO
DMWI", dw1="mwion",dw2="mwioff", setname="rset1"
|
Comments
|
Note The MwiStringON and MwiStringOFF strings are typically unique for each vendor. The string needs to be provisioned depending on the vendor for DPNSS PBX used.
|
MwiStringOFF
Purpose:
|
This property enables the support of MWI to the DPNSS protocol to turn off the MWI lamp on a particular extension when this string is encoded in message.
|
Valid Values:
|
Digit string with minimum length=0, maximum length=32
Note The digit string provisioned should be the same MWI string provisioned in Cisco CallManager.
|
Default Value:
|
NULL
|
Domain:
|
_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)
|
Example:
|
mml>prov-add:sigsvcprop:name="dpnsssvc2", MwiStringOFF = "*58*AN*1#"
mml>numan-add:digmodstring:custgrpid="1111",name="mwioff",digstring="4085
556667"
|
Comments:
|
Note The MwiStringON and MwiStringOFF strings are typically unique for each vendor. The string needs to be provisioned depending on the vendor for DPNSS PBX used.
|
OwnRoutingNumber
Purpose:
|
Defines the routing or network number of the PGW in a PBX network that requires Route Optimization or Path Replacement capabilities. The presence or absence of this property also acts as an indication of whether this service is enabled/disabled for a signalling path.
|
Valid Values:
|
Digit string with minimum length=0, maximum length=16.
|
Default Value:
|
NULL (indicates that Route Optimization is disabled for that Sigpath)
|
Domain:
|
X_SigPath
|
Syntax:
|
mml>prov-add:sigsvcprop:name="name", ownRoutingNumber="number"
|
Input Description:
|
•name—The MML name of the previously configured sigpath in the system.
•number—Valid property values: string up to 32 characters long. Default value is NULL.
Note If configured NULL, PGW will not invoke this feature on behalf of CCM and will reject any Route Optimization invoke coming from PBXs. However, if the call is a transit call (i.e DPNSS to DPNSS) then the message will be passed through.
|
Example:
|
The MML command shown in the following example defines the routing number of PGW in a PBX network that requires route optimization or path replacement:
mml>prov-add:sigsvcprop:name="dpnsssvc1", ownRoutingNumber="4085556666":
|
Comments:
|
Protocol Family— DPNSS
Dynamically reconfigurable— Y
Note All the DPNSS PBXs must be configured to use a predetermined routing number for itself to invoke this RO feature. A different routing number must be configured against that sigPath in PGW. Please check to ensure the PBX Routing Number is provisioned in the PGW Dial Plan and the PGW Routing Number is in the PBX Dial Plan."
|
Provisioning Worksheets
This section contains worksheets for the provisioning components required for this feature. For worksheets covering the rest of the provisioning components in the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm
Table 16 External Node Worksheet Example
Name
|
Type
|
ISDN Signaling Type
|
Group
|
Description
|
va-3600-37
|
AS3600
|
iua
|
|
DPNSS conn to va-3600-37
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
Table 17 DPNSS Signaling Service Worksheet Example
Name
|
External Node
|
Customer Group ID
|
DPNSS Side
|
Signaling Port
|
Signaling Slot
|
Description
|
dpnsvc2
|
va-3660-20
|
|
A
|
0
|
0
|
IUA DPNSSpath to GW
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
Table 18 IP Route Worksheet Example (optional)
Name
|
Destination
|
Subnet Mask
|
Next Hop
|
IP Address
|
Priority
|
Description
|
iproute1
|
va-3600-37
|
255.255.255.0
|
va-3600-36
|
175.25.211.17
|
1
|
IP route to va-3600-37
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
Table 19 SCTP Association Worksheet Example
Parameter
|
Parameter Value
|
Name
|
nasassoc1
|
|
|
|
|
|
Description
|
DPNSS IUA association 1
|
|
|
|
|
|
Signaling type
|
IUA
|
|
|
|
|
|
SGP name
|
|
|
|
|
|
|
First local address
|
IP_Addr1
|
|
|
|
|
|
Second local address (optional)
|
IP_Addr2
|
|
|
|
|
|
Local SCTP port number (optional)
|
|
|
|
|
|
|
Highest priority destination address
|
10.82.80.30
|
|
|
|
|
|
Lowest priority destination address (optional)
|
10.82.81.30
|
|
|
|
|
|
Destination SCTP port number (optional)
|
|
|
|
|
|
|
External node name
|
va-3600-37
|
|
|
|
|
|
First IP route name (optional)
|
iprte1
|
|
|
|
|
|
Second IP route name (optional)
|
iprte2
|
|
|
|
|
|
Number of bytes to advertise for the local receive window (optional)
|
|
|
|
|
|
|
Maximum number of times to retransmit SCTP INIT message (optional)
|
|
|
|
|
|
|
Maximum initial timer retransmission value (optional)
|
|
|
|
|
|
|
Maximum number of retransmissions over all destination addresses before the association is declared failed (optional)
|
|
|
|
|
|
|
Maximum time after a datagram is received before a SCPT SACK is sent (optional)
|
|
|
|
|
|
|
Maximum time SCTP will wait for other outgoing datagrams for bundling (optional)
|
|
|
|
|
|
|
Minimum value allowed for the retransmission timer (optional)
|
|
|
|
|
|
|
Maximum value allowed for the retransmission timer (optional)
|
|
|
|
|
|
|
Time between heartbeats (optional)
|
|
|
|
|
|
|
IP precedence (optional)
|
|
|
|
|
|
|
Differential Service Code Point (optional)
|
|
|
|
|
|
|
Maximum number of retransmissions to peer address 1 or 2 before it is declared failed (optional)
|
|
|
|
|
|
|
Obtaining Documentation and Technical Assistance
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. To obtain this information, go to What's New in Cisco Product Documentation at:
http://www.cisco.com/univercd/cc/td/doc/abtunicd/136957.htm#wp448038
Glossary
Table 20 contains definitions of acronyms and technical terms used in this feature module.
Table 20 Glossary
Term
|
Definition
|
ANSI
|
American National Standards Institute
|
CIC
|
Carrier Identification Code
|
DPNSS
|
Digital Private Network Signaling System. A PBX standard developed in the United Kingdom.
|
EISUP
|
Extended ISDN User Part. A proprietary protocol used to communicate between Cisco MGC nodes and between a Cisco MGC node and a Cisco H.323 System Interface.
|
I/O
|
Input/Output
|
IOCC
|
Input/Output channel controller
|
IOCM
|
Input/Output Channel Controller Manager
|
ISDN
|
Integrated Services Digital Network
|
ISUP
|
ISDN User Part
|
ITU
|
International Telecommunication Union
|
IUA
|
ISDN Q.921 User Adaptation Layer
|
LNP
|
Local Number Portability
|
M3UA
|
Message Transfer Point Level 3 User Adaptation
|
MGC
|
Media Gateway Controller
|
MGCP
|
Media Gateway Control Protocol
|
MIB
|
Management Information Base
|
MML
|
Man-Machine Language
|
MTP3
|
Message Transfer Part Level 3
|
NAS
|
Network access server
|
NFAS
|
Non-Facility Associated Signaling
|
PR
|
Path Replacement
|
PSTN
|
Public switched telephone network
|
Q.931
|
ITU document that defines the ISDN connection control protocol.
|
Q.921
|
ITU document that defines the data link protocol used on an ISDN D-channel. Also known as Link Access Protocol - D Channel (LAPD).
|
RFC
|
Request For Comments. A proposed standards document. There are RFCs for both IUA and SCTP.
|
RLM
|
Redundant Link Manager. A proprietary protocol used for the transport of Q.931 data between a Cisco MGC host and an associated media gateway.
|
RO
|
Route Optimization
|
SCCP
|
Service Connection Control Part
|
SCTP
|
Stream Controlled Transmission Protocol
|
SIGTRAN
|
Signaling Transport—An IETF working group that addresses the transport of packet-based PSTN signaling over IP networks.
|
SIP
|
Session Initiation Protocol
|
SS7
|
Signaling System 7
|
SUA
|
SCCP User Adaptation
|
TALI
|
Transport Adapter Layer Interface
|
TCAP
|
Transaction Capability Application Part
|
UDP
|
User Datagram Protocol
|
This document is to be used in conjunction with the documents listed in the Related Documentation section.
