Table Of Contents
Support for M3UA and SUA with SCTP
Feature Overview
Benefits
Restrictions
Related Features and Technologies
Changes to Cisco MGC Software Architecture
Related Documentation
Supported Standards, MIBs, and RFCs
Prerequisites
Upgrading
Provisioning Tasks
Planning for Provisioning
Provisioning Procedures
Troubleshooting Tips
Alarm Troubleshooting Procedures
Signaling Channel Troubleshooting Procedures
Monitoring and Maintaining
Regular Operations
Provisioning Examples
Command Reference
New MML Commands
Modified MML Commands
Reference Information
XECfgParm.dat Parameters
Alarms
Logs
Measurements
Components
External Node Types
Properties
Provisioning Worksheets
Obtaining Documentation
Cisco.com
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco Technical Support Website
Submitting a Service Request
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Glossary
Support for M3UA and SUA with SCTP
Document Release History
Publication Date
|
Comments
|
September 16, 2003
|
Initial version of the document.
|
June 3, 2005
|
Modified the information concerning the network appearance parameter for the SUAKEY component.
|
July 11, 2006
|
Updated the upgrade procedure for the ability to support a single originating point code for a Cisco MGC and Cisco ITP group.
|
Feature History
Release
|
Modification
|
9.4(1)
|
This feature was introduced on the Cisco MGC software.
|
This document describes the Support for M3UA and SUA with SCTP Feature. This feature is described in the following sections:
•
Feature Overview
• Supported Standards, MIBs, and RFCs
• Prerequisites
• Upgrading
• Provisioning Tasks
• Monitoring and Maintaining
• Provisioning Examples
• Command Reference
• Reference Information
• Obtaining Documentation
• Documentation Feedback
• Obtaining Technical Assistance
• Obtaining Additional Publications and Information
• Glossary
Feature Overview
This feature enables support on the Cisco MGC of the M3UA and SUA protocols using SCTP. The Cisco MGC can now use M3UA and SUA to communicate with Cisco IP Transfer Points (ITPs). The Cisco ITP is a signaling gateway. In prior releases of the Cisco MGC software, processing of Message Transfer Part (MTP) data was done in two parts: the Cisco Signaling Link Controller (SLT) processed MTP levels 1 and 2. MTP Level 3 (along with the upper layers of SS7) data was passed on to the Cisco MGC for processing. This feature enables you to also use the Cisco ITP to process MTP and SCCP data. The Cisco ITP processes all levels of the MTP and SCCP data, and then passes the upper layers of SS7 data to the Cisco MGC.
Note This version of the Cisco MGC software still supports the use of Cisco SLTs. However, the M3UA and SUA with SCTP feature cannot be used to communicate with Cisco SLTs.
This feature provides the following:
•Use of the SIGTRAN standards M3UA and SUA with SCTP to communicate with Cisco ITP signaling gateways
•Transport of SCCP, ISUP, BTNUP and TUP messages for the ANSI and ITU protocol families.
•Processing of incoming User Part Unavailable (UPU) messages.
•The ITU ISUP protocol family supports the ISUP User Part Test (UPT) and User Part Available (UPA) messages. The UPT is sent periodically when an UPU message is received indicating the remote user is inaccessible. The UPA is sent in response to a UPT.
•The ANSI ISUP protocol family supports the Circuit Verification Test (CVT) and Circuit Verification Response (CVR) messages. The CVT is sent periodically when an UPU message is received indicating the remote user is inaccessible. The CVR is sent in response to a CVT.
•Support upgrading from Cisco SLT-based SS7 signaling to Cisco ITP-based SS7 signaling without losing stable active calls.
•Increase the number of measurement counters supported on the Cisco PGW 2200 to allow for the total number of measurements needed for the largest possible configuration to be created.
Benefits
This feature provides the following benefits:
Use of standard protocols
By adding support for the SIGTRAN protocols M3UA, SUA and SCTP, the Cisco MGC can now use standard protocols for communication with the device used to process the Message Transfer Part (MTP) data.
Ability to increase call processing speed
By combining multiple Cisco MGC pairs behind a set of Cisco ITPs with several unique point codes, the number of calls per second is much higher than can be achieved with a single pair of Cisco MGC hosts equipped with Cisco SLTs. This type of Cisco MGC and Cisco ITP configuration is referred to as a Cisco PGW Farm.
Restrictions
This feature can only be used for communication between Cisco MGCs and Cisco ITPs. For information on the restrictions on the Cisco ITPs, refer to the Support for M3UA and SUA with SCTP on Cisco ITPs feature module.
Related Features and Technologies
The following features and technologies are related to this feature:
•Support for DPNSS Signaling Backhaul Feature (for the Cisco PGW 2200 and Cisco media gateways)
•Support for the IUA with SCTP Feature (for the Cisco MGC and Cisco access servers)
Changes to Cisco MGC Software Architecture
This section describes the changes to Cisco MGC software architecture for this feature.
Input/Output Subsystem
The Input/Output (I/O) subsystem consists of the I/O channel controllers (IOCC) and the I/O channel manager (IOCM), which manages them.
•The IOCM manages all IOCCs.
•The IOCCs provide
–A protocol-specific, message-based interface that allows nodes and platforms external to the Cisco MGC to communicate with the Cisco MGC.
–An interface that allows buffering of messages to the call engine's event dispatcher queue.
•The Cisco MGC I/O subsystem includes the following IOCCs:
–Signaling System 7 (SS7)—Contains MTP3 used for backhauling SS7 signaling to the Cisco MGC from a Cisco SLT.
–ISDN Level 3—Provides backhauling of ISDN (standard variants) to the Cisco MGC from a media gateway.
–Q.931+—A stateless IOCC, for a Cisco-proprietary protocol (RLM), which a special version of ISDN that enables forwardhauling of Q931+ signaling to a media gateway used in Cisco PGW 2200 configured for signaling environments.
–Media Gateway Control Protocol (MGCP)—Enables communication to media gateways and trunking gateways for setting up bearer channel connections used in Cisco PGW 2200 configured for call control environments.
–Extended ISDN User Part (E-ISUP)—Cisco-proprietary internal interface that enables the transport of endpoint and media gateway specific information between two (or more) Cisco MGCs. This protocol uses an enhanced ISUP base to support all ANSI and ITU ISUP messaging and elements, as well as additional fields to support transport of service information (such as local number portability (LNP), 800 numbers, and so on).
–Session Initiation Protocol (SIP)—Enables the Cisco MGC to receive and send SIP messages using the User Datagram Protocol (UDP).
–ISDN Q.921 User Adaptation (IUA)—Added in Release 9.4, this IOCC enables backhauling of ISDN Q.921 User messages over IP using Stream Controlled Transmission Protocol (SCTP). This IOCC is used between the Cisco MGC and media gateways.
–Message Transfer Part Level 3 (MTP3) User Adaptation (M3UA)—Added in Release 9.4, this IOCC enables the transport of any SS7 MTP Level 3 User signaling (for example, ISUP and TUP messages) over IP using SCTP. This IOCC is used between the Cisco MGC and Cisco ITP.
–Signaling Control Connection Part (SCCP) User Adaptation (SUA)—Added in Release 9.4, this IOCC enables the transport of any SCCP user signaling (for example, TCAP messages) over IP using SCTP. This IOCC is used between the Cisco MGC and Cisco ITP.
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) software are listed below:
•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.4(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
•M3UA
•SUA
•SCTP
MIBs
There are MIBs added for each new measurement. The new measurements can be found in the
"Measurements" section. For more information on the MIBs used in the Cisco MGC software, refer to the
Cisco Media Gateway Controller Release 9 Management Information Base Guide.
RFCs
The following RFCs are supported by this feature:
•RFC-3332 (M3UA)
•RFC-3057 (SCTP)
Prerequisites
You must have Cisco Media Gateway Controller (MGC) software Release 9.4(1). Prerequisites for this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).
Information on the prerequisites for the implementation of this feature in Cisco IOS software for the Cisco ITPs can be found in the Support for M3UA and SUA with SCTP for Cisco ITPs feature module.
Upgrading
This sections contains the steps necessary for upgrading of the Cisco MGC software to support this feature. If you are installing and configuring the Cisco MGC software on your system for the first time, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide for the required procedures.
Before beginning the upgrade procedure, prepare the information you'll need by following the instructions in the "Planning for Provisioning" section.
Step 1 Upgrade both Cisco MGC hosts to the new software release using the upgrade procedures defined in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Step 2 Verify that the existing Cisco SLT configuration is functioning normally by retrieving the alarms on both Cisco MGC hosts. To do this, enter the following MML command:
mml>rtrv-alms
The system returns a list of the active alarms. If there are any alarms associated with the provisioning components that are part of the affected SS7 path, resolve those alarms before continuing with this procedure.
Note More information on alarms can be found in the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide. Procedures for alarms that require corrective action can be found in the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance and Troubleshooting Guide.
Step 3 Configure the Cisco ITP(s) to match the current Cisco MGC provisioning for the following items:
•OPC
•Number of links
•Signaling link code (SLC) values
•SS7 routes
•Routing keys
Step 4 Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 5 Add new Cisco ITP external nodes, as described in the "Adding Cisco ITP External Nodes" section.
Step 6 Add M3UA and SUA SGPs, as described in the "Adding M3UA and SUA Signaling Gateway Processes" section.
Step 7 Add SCTP associations as described in the "Adding SCTP Associations" section.
Step 8 Save your provisioning changes to the active Cisco MGC only by entering the following MML command:
mml>prov-cpy
Step 9 Verify the IP connectivity between the active Cisco MCC and the Cisco ITP(s).
Step 10 Contact the appropriate party to inhibit half of the SS7 links in the linkset at the associated far-end destinations (for example, a signaling transfer point (STP) or remote PSTN switch).
Step 11 Move the cabling for the inhibited SS7 links from the Cisco SLTs to the Cisco ITP(s).
Step 12 Verify on the Cisco ITP(s) that the inhibited links come in service in the inhibited state.
Step 13 Disable any new calls on the Cisco MGC for all of your SS7 destinations using the following MML command:
mml>set-admin-state:dest:lock
Where dest is the MML name of the affected SS7 destination.
Step 14 Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 15 Add M3UA and SUA routing keys, as described in the "Adding M3UA and SUA Routing Keys" section.
Step 16 Edit the existing SS7 signaling services to add M3UAKEYs, using the procedure in the "Modifying M3UA and SUA Routing Keys" section.
Step 17 If the Cisco MGC and the Cisco ITP are not on the same subnet, you will need to add an IP route, as described in the "Adding M3UA and SUA Routes" section.
Step 18 Save your provisioning changes to the active Cisco MGC only by entering the following MML command:
mml>prov-cpy
Note If any abnormalities occur in steps 14-18, you can perform a manual switchover using the sw-ovr::confirm MML command to change the active Cisco MGC host and then enable the SS7 destinations using the set-admin-state MML command on the newly active Cisco MGC.
Step 19 Set all of the SS7 links out-of-service using the MML command listed below. This should cause the far-end devices to uninhibit the SS7 links already associated with the Cisco ITP(s).
mml>set-c7lnk:c7link_name:OOS
Where c7link_name is the MML name of the SS7 link you want to set out-of-service.
Step 20 Enable new calls on the Cisco MGC for all of your SS7 destinations using the following MML command:
mml>set-admin-state:dest:unlock
Where dest is the MML name of the affected SS7 destination.
Step 21 Verify that the SS7 connectivity of all the destinations is restored by entering the following MML command:
mml>rtrv-dest:all
Step 22 Propagate your provisioning changes to the standby Cisco MGC by entering the following MML command:
mml>prov-sync
Step 23 Configure any additional links on the Cisco ITP(s), if necessary.
Step 24 Make additional provisioning changes for any additional links on the Cisco MGC. To do this, repeat steps 4 through 17.
Step 25 Delete the IP links associated with the old Cisco SLT external node using the following MML command:
prov-dlt:iplnk:name="link"
Where link is the MML name of the IP link associated with the affected destination.
Step 26 Delete the old Cisco SLT external node using the following MML command:
mml>prov-dlt:extnode:name="slt"
Where slt is the MML name of the Cisco SLT associated with the affected destination.
Step 27 Save your provisioning changes and enable the new links. To do this, repeat steps 19 through 22.
Provisioning Tasks
The following sections describe the provisioning tasks related to this feature:
• Planning for Provisioning
• Provisioning Procedures
• Troubleshooting Tips
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, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Collecting External Node Data
The external node component type represents another node with which the Cisco MGC communicates. You must be ready to enter the following data:
•MML name
•Component description
•The type of the external node
•ISDN Signaling Type
•M3UA/SUA Group Number
The parameters for EXTNODE are defined in Table 21.
Collecting IP Route Data
The IP route represents a static IP route. 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 22.
Collecting M3UA Key Data
This component represents an M3UA routing key. You must be ready to enter the following data:
•M3UA key name
•Component description
•Associated OPC
•Associated DPC (optional)
•Routing context value
•Service indicator
•Network appearance (optional)
The M3UA key component information can be listed in Table 23.
Collecting M3UA Route Data
This component represents an M3UA route. You must be ready to enter the following data:
•M3UA route name
•Component description
•Associated DPC
•Associated external node
•Associated OPC
The M3UA route component information can be listed in Table 24.
Collecting SCTP Association Data
The SCTP association represents the connection between the Cisco MGC and media gateways (IUA) and signaling gateways (M3UA/SUA). The Cisco ITP is a signaling 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 SGP (required only form M3UA/SUA associations)
•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 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 address 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. 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 25.
Collecting SS7 Signaling Gateway Process Data
This component represents a SS7 signaling gateway process (SGP). You must be ready to enter the following data:
•MML name of SGP
•M3UA route name
•Component description
•External node that is running the SS7 signaling gateway process
The SS7 signaling gateway process component structure is shown in Table 26.
Collecting SS7 Signaling Service Data
This component represents an SS7 signaling service or signaling path to a particular SS7 switch (destination). You must be ready to enter the following data:
•Unique ID of this component and component name used in MML commands
•Component description
•MDO file name
•Destination point code MML name
•Customer group ID
•M3UA Routing key ID MML name
The SS7 signaling service component structure is shown in Table 28.
Collecting SUA Key Data
This component represents a SUA Routing key. You must be ready to enter the following data:
•SUA key name
•Component description
•Associated OPC
•Associated APC (optional)
•Associated local SSN
•Routing context value
•Network appearance (optional)
The SUA key component structure is shown in Table 29.
Collecting SUA Route Data
This component represents a SUA route. You must be ready to enter the following data:
•SUA route name
•Component description
•Associated APC
•Associated external node
•Associated OPC
•Associated remote SSN
The SUA route component structure is shown in Table 30.
Collecting SS7 Subsystem Data
The SS7 subsystem component type represents an SS7 subsystem. You must be ready to enter the following data:
•MML name of SS7 subsystem
•Component description
•MML name of Adjacent point code or TCAP/IP service
•Protocol family
•Adjacent point code of the mated STP
•Priority
•Local subsystem number
•STP/SCP index used for IN triggers
•Transport protocol (must be SUA for this feature)
•MML name of an SUA key (optional)
•Remote subsystem number
The SS7 subsystem component structure is shown in Table 31.
Provisioning Procedures
Provision the transport path between the M3UA and SUA IOCCs of the Cisco PGW 2200 and the external Cisco ITP nodes. Communication between the Cisco PGW 2200 and the Cisco ITPs is provisioned to provide a reliable communication path between the two platforms.
Provisioning procedures can be found in the following sections:
• Provisioning Basics
• Adding M3UA and SUA Connections
• Modifying M3UA and SUA Components
• Deleting M3UA and SUA Components
Provisioning Basics
The procedures in this section describe how to start a provisioning session and how to save and activate the changes you have made.
• 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, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
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 the "Retrieving Data on the Current Provisioning Session" section.
•mod_ver—A new configuration version name 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:
mml>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, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
There are two ways to close your provisioning session: saving and activating your provisioning changes, as described in the "Saving and Activating your Provisioning Changes" section or ending your provisioning session without saving and activating your changes, as described in the "Ending a Provisioning Session Without Activating your Changes" section.
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 and
prov-dply MML commands can severely impact your system's call processing performance, depending on the extent of your provisioning changes. We recommend that these commands be issued during a maintenance window when traffic is minimal.
The prov-cpy MML command is used 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 also automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session as described in the "Starting a Provisioning Session" section.
Caution Using the
prov-sync MML command can severely impact your system's call processing performance. We recommend that this command be issued 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.
The prov-dply MML command is used 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 high-availability or continuous-service configurations. This command should not be used on a Cisco MGC in a simplex configuration.
Note When you enter the prov-dply command, your provisioning session is also 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 the "Starting a Provisioning Session" section.
Ending a Provisioning Session Without Activating your Changes
You may find that you 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 All Components
• Retrieving Data for All Components of a Particular Type
• Retrieving Data on the Current Provisioning Session
• Retrieving Data on Supported Signaling Protocols
Retrieving Data for an Individual Component
You can retrieve provisioning data on 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:
mml>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.
•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 a M3UA signaling service called m3ua1, you would enter the following command:
mml>prov-rtrv:ss7path:name="m3ua1"
Retrieving Data for All Components
You can retrieve data on all of 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:
mml>prov-rtrv:all
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:
mml>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.
For example, to view the provisioning data for all SS7 signaling services, you would enter the following command:
mml>prov-rtrv:ss7path:"all"
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:
mml>prov-rtrv:session
The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2003-01-13 13:39:19
M RTRV
"session=jtest:session"
/*
Session ID = mml1
SRCVER = active
DSTVER = jtest
*/
Retrieving Data on Supported Signaling Protocols
You can retrieve protocol data for the current provisioning session. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml>prov-rtrv:variants
Adding M3UA and SUA Connections
This section contains the procedures that you must perform to add M3UA and SUA connections to your Cisco PGW 2200 provisioning data. When provisioning the components that enable the Cisco PGW 2200 to support M3UA and SUA, perform the procedures in the following order.
• Adding Cisco ITP External Nodes
• Adding Point Codes (OPC, DPC, and APC)
• Adding M3UA and SUA Routing Keys
• Adding SS7 Signaling Services
• Adding M3UA and SUA Routes
• Adding SS7 Subsystems
• Adding M3UA and SUA Signaling Gateway Processes
• Adding IP Routes (optional)
• Adding SCTP Associations
Note To begin the provisioning session, perform the steps in the "Starting a Provisioning Session" section. Once you have finished provisioning the M3UA and SUA data, save and activate your provisioning data by performing the steps in the "Saving and Activating your Provisioning Changes" section.
Adding Cisco ITP External Nodes
To add Cisco ITP external nodes, perform the following steps:
Step 1 Enter the following command to add a Cisco ITP external node:
mml>prov-add:extnode:name="name", desc="description", type="itp", group=num
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•num—The M3UA/SUA group number. The valid values are 1 through 100.
For example, to add an Cisco ITP external node named itp1, you would enter the following command:
mml>prov-add:extnode:name="itp1", desc="2651 ITP", type="itp", group=1
Step 2 Repeat Step 1 for each Cisco ITP external node you want to add to your provisioning data.
Adding Point Codes (OPC, DPC, and APC)
To add originating point codes (OPCs), perform the following steps:
Step 1 Enter the following command to add an OPC:
mml>prov-add:opc:name="name", desc="description", netaddr="addr", netind=num,
type="trueopc"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•addr—The network address in dot notation.
•num—The network indicator number. The default value is 0.
Note To support M3UA and SUA interfaces, the value of the type parameter must be set to trueopc.
For example, to add an OPC named opc1, you would enter the following command:
mml>prov-add:opc:name="opc1", desc="Originating PC 1",
netaddr="2.1.4",netind=2,type="trueopc"
Step 2 Repeat Step 1 for each OPC you want to add to your provisioning data.
To add destination point codes (DPCs), perform the following steps:
Step 1 Enter the following command to add a DPC:
mml>prov-add:dpc:name="name", desc="description", netaddr="addr", netind=num
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•addr—The network address in dot notation.
•num—The network indicator number. The default value is 0.
For example, to add an DPC named dpc1, you would enter the following command:
mml>prov-add:DPC:NAME="dpc1",DESC="DPC1",NETADDR="1.1.5",NETIND=2
Step 2 Repeat Step 1 for each DPC you want to add to your provisioning data.
To add adjacent point codes (APCs), perform the following steps:
Step 1 Enter the following command to add an APC:
mml>prov-add:apc:name="name", desc="description", netaddr="addr", netind=num
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•addr—The network address in dot notation.
•num—The network indicator number. The default value is 0.
For example, to add an APC named apc1, you would enter the following command:
mml>prov-add:apc:NAME="apc1",DESC="apc1",NETADDR="1.2.4",NETIND=2
Step 2 Repeat Step 1 for each APC you want to add to your provisioning data.
Adding M3UA and SUA Routing Keys
To add M3UA routing keys, perform the following steps:
Step 1 Enter the following command to add an M3UA routing key:
mml>prov-add:m3uakey:name="name", desc="description", opc="opc", [dpc="dpc",]
routingcontext=rc, [si="serv", networkappearance=na]
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•opc—MML name of a previously assigned OPC. The selected OPC must have a type of trueopc.
•dpc—MML name of a previously assigned DPC. This parameter is optional.
•rc—Routing context value. To use the routing context, its value must be set to any integer other than 0 (0 indicates that there is no routing context). The routing context value for each M3UA key you create must be unique.
•serv—Service indicator value. This parameter is optional. The valid values are ISUP, TUP, and N/A. The default value is N/A.
•na—Network appearance value. This parameter is optional. The valid values are integers from 1 through 32767. A value of 0 indicates an invalid network appearance.
For example, to add a M3UA key named m3uakey1, you would enter the following command:
mml>prov-add:M3UAKEY:NAME="m3uakey1",OPC="opc1",DPC="dpc1",si="ISUP", ROUTINGCONTEXT=10
Step 2 Repeat Step 1 for each M3UA key you want to add to your provisioning data.
To add SUA routing keys, perform the following steps:
Step 1 Enter the following command to add an SUA routing key:
mml>prov-add:suakey:name="name", desc="description", opc="opc", [apc="apc", localssn=ssn,]
routingcontext=rc, networkappearance=na
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•opc—MML name of a previously assigned OPC. The selected OPC must have a type of trueopc.
•apc—MML name of a previously assigned APC. This parameter is optional.
•ssn—Local SS7 subsystem number value. This parameter is optional. The valid values are integers between 2 and 254.
•rc—Routing context value. To use the routing context, its value must be set to any integer other than 0 (0 indicates that there is no routing context). The routing context value for each M3UA key you create must be unique.
•na—Network appearance value. The valid values are integers from 1 through 32767. This value must match the network appearance value set in your Cisco ITP.
For example, to add a SUA key named suakey1, you would enter the following command:
mml>prov-add:SUAKEY:NAME="suakey1",OPC="opc1",APC="apc1",localssn=200, ROUTINGCONTEXT=20,
networkappearance=10
Step 2 Repeat Step 1 for each SUA key you want to add to your provisioning data.
Adding SS7 Signaling Services
To add SS7 signaling services, perform the following steps:
Step 1 Enter the following command to add an SS7 signaling service:
mml>prov-add:ss7path:name="name", desc="description", mdo="protFile", dpc="dpc",
custgrpid="num", m3uakey="rtkey"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•protFile—MDO file name for the supported SS7 protocol. A list of file names for SS7 protocols supported in this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).
•dpc—MML name of a previously provisioned DPC. There can only be one SS7 signaling service per DPC/M3UA pair.
•num—Customer group ID number. The valid value is a four-digit number. The default value is 0000.
•rtkey—MML name of a previously provisioned M3UA key.
For example, to add an SS7 signaling service named ss7svc1, you would enter the following command:
mml>prov-add:SS7PATH:NAME="ss7svc1", DESC="OPC1 to INET DPC1", M3UAKEY="m3uakey1",
DPC="dpc1", MDO="Q761_BASE"
Step 2 Repeat Step 1 for each SS7 signaling service you want to add to your provisioning data.
Adding M3UA and SUA Routes
To add M3UA routes, perform the following steps:
Step 1 Enter the following command to add an M3UA route:
mml>prov-add:m3uaroute:name="name", desc="description", dpc="dpc", extnode="itp",
opc="opc"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•dpc—MML name of a previously provisioned DPC.
•itp—MML name of a previously provisioned Cisco ITP external node.
•opc—MML name of a previously provisioned OPC.
For example, to add an M3UA route named m3uarte1, you would enter the following command:
mml>prov-add:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Rte 1",OPC="opc1",DPC="dpc1",
EXTNODE="itp1"
Step 2 Repeat Step 1 for each M3UA route you want to add to your provisioning data.
To add SUA routes, perform the following steps:
Step 1 Enter the following command to add an SUA route:
mml>prov-add:suaroute:name="name", desc="description", apc="apc", extnode="itp",
opc="opc", remotessn=num
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•apc—MML name of a previously provisioned APC.
•itp—MML name of a previously provisioned Cisco ITP external node.
•opc—MML name of a previously provisioned OPC.
•num—SS7 subsystem number of the destination. The valid values are 2 through 254.
For example, to add an SUA route named suarte1, you would enter the following command:
mml>prov-add:SUAROUTE:NAME="suarte1", DESC="SUA Rte 1", APC="apc1", OPC="opc1",
EXTNODE="itp1", remotessn=40
Step 2 Repeat Step 1 for each SUA route you want to add to your provisioning data.
Adding SS7 Subsystems
To add SS7 subsystems, perform the following steps:
Step 1 Enter the following command to add an SS7 subsystem:
mml>prov-add:ss7subsys:name="name", desc="description", suakey="key", svc="serv",
proto="protFam", transproto="protType", remotessn=remssn, localssn=locssn,
stpscpind="index"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•key—MML name of a previously defined SUA key.
•serv—MML name of a previously defined APC.
•protFam—MML name of the associated SS7 protocol family. Valid values are:
–SS7-ANSI
–SS7-ITU
•protType—MML name of the transport protocol. Valid values are SCCP and SUA. The default value is SCCP.
•remssn—SS7 subsystem number of the destination. This number has to match the SSN value defined in the SUAROUTE.
•locssn—Local SS7 subsystem number value. The valid values are integers between 2 and 254. This parameter cannot be used if an M3UA key is provisioned.
•stpscpind—STP/SCP index used for Intelligent Network triggers.
For example, to add an SS7 subsystem named prepaid, you would enter the following command:
mml>prov-add:SS7SUBSYS:NAME="prepaid",DESC="prepaid rte-ssn 48",SUAKEY="suakey1",
SVC="scp", PROTO="SS7-ITU",TRANSPROTO="SUA", stpscpind=2, remotessn=48
Step 2 Repeat Step 1 for each SS7 subsystem you want to add to your provisioning data.
Adding M3UA and SUA Signaling Gateway Processes
To add M3UA and SUA signaling gateway processes, perform the following steps:
Step 1 Enter the following command to add a M3UA or SUA signaling gateway process:
mml>prov-add:sgp:name="name", desc="description", extnode="itp"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•itp—MML name of a previously provisioned Cisco ITP external node.
For example, to add an SGP for an M3UA path named m3ua-sgp1, you would enter the following command:
mml>prov-add:SGP:NAME="m3ua-sgp1",DESC="M3UA SGP 1 - ITP1", EXTNODE="itp1"
For example, to add an SGP for an SUA path named sua-sgp1, you would enter the following command:
mml>prov-add:SGP:NAME="sua-sgp1",DESC="SUA SGP 1 - ITP1", EXTNODE="itp1"
Step 2 Repeat Step 1 for each SGP you want to add to your provisioning data.
Note You must define an SGP for each M3UA/SUA path that you provision.
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 servers. 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 the "Starting a Provisioning Session" section.
Step 2 Enter the following command to add an IP route:
mml>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 component. 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 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 decimal dot 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
IP Address should be in decimal dot notation and the hostname 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 decimal dot 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:
mml>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 the "Saving and Activating your Provisioning Changes" section.
Otherwise, proceed to the "Adding M3UA and SUA Signaling Gateway Processes" section.
Adding SCTP Associations
To add SCTP associations, perform the following steps:
Step 1 Enter the following command to add an SCTP association:
mml>prov-add:association:name="name", desc="description", type="sigtype", sgp="sgp",
ipaddr1="addr1", ipaddr2="addr2", port=num, peeraddr1="paddr1", peeraddr2="paddr2",
peerport=pnum, iproute1="iprte1", iproute2="iprte2", rcvwin=rcv, maxinittrans=rtxinitmsg,
maxinitrto=rtxinittim, maxretransdest=prtx, maxretrans=rtx, cumsackto=sacktm,
bundleto=bundtm, minrto=minrtx, maxrto=maxrtx, hbto=hb, ipprecedence="ipprec", dscp="dscp"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•sigtype—Name of the signaling protocol for this association. Valid values are IUA, M3UA, and SUA.
•sgp—MML name of a previously defined signaling gateway process.
•addr1—First local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. Valid values are:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
•addr2—Second local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. This parameter is optional. Valid values are:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
–N/A (default value)
•num—Local SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.
•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.
•pnum—Destination SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.
•iprte1—MML name of first IP route (optional). Valid value is the MML name of a previously provisioned IP route.
•iprte2—MML name of second IP route (optional). Valid value is the MML name of a previously provisioned IP route.
•rcv—Number of bytes to advertise for the local receive window (optional). Valid value is the range from 1500 to 65535. The default value is 18000.
•rtxinitmsg—Maximum number of times to retransmit SCTP INIT message (optional). Valid value is the range from 0 to 100. The default value is 10. A value of 0 means that the SCTP internal default value is used.
•rtxinittim—Maximum initial time retransmission value (optional). Valid value is the range from 300 to 3000, and 0. The default value is 2000. A value of 0 means that the SCTP internal default value is used.
•prtx—Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 3.
•rtx—Maximum number of retransmissions over all destination address before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 5.
Note The value of this parameter cannot exceed the value of the MAXRETRANSDEST parameter times the number of destinations.
•sacktm—Maximum time after a datagram is received before a SCTP SACK message is sent (optional). Valid value is the range from 100 to 500 ms. The default value is 300 ms.
•bundtm—Maximum time SCTP waits for other outgoing datagrams for bundling (optional). Valid value is the range from 100 to 600 ms. The default value is 100 ms.
•minrtx—Minimum value allowed for the retransmission timer (optional). Valid value is the range from 300 to 3000 ms. The default value is 300 ms.
•maxrtx—Maximum value allowed for the retransmission timer (optional). Valid value is the range from 1000 to 3000 ms. The default value is 3000 ms.
•hb—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.
•ipprec—IP precedence (optional). The value for this parameter is inserted in place of the IP precedence portion of the Type of Service field in outing SCTP datagrams. Valid values are as follows:
–ROUTINE (default) 000
–PRIORITY 001
–IMMEDIATE 010
–FLASH 011
–FLASH-OVERRIDE 100
–CRITICAL 101
–INTERNET 110
–NETWORK 111
•dscp—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.
–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 Class 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 (default)
For example, to add an M3UA association named m3ua-assoc1, you would enter the following command:
mml>prov-add:ASSOCIATION:NAME="m3ua-assoc1",DESC="M3UA Association 1",
TYPE="M3UA",SGP="m3ua-sgp1", IPADDR1="IP_Addr1", IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.187", PEERADDR2="10.82.81.164"
For example, to add an SUA association named sua-assoc1, you would enter the following command:
mml>prov-add:ASSOCIATION:NAME="sua-assoc1",DESC="M3UA Association 1",
TYPE="SUA",SGP="sua-sgp1", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164"
Step 2 Repeat Step 1 for each M3UA or SUA association you want to add to your provisioning data.
Modifying M3UA and SUA Components
This section contains the procedures that you must perform to modify M3UA and SUA connections in your Cisco MGC provisioning data. When modifying the components that enable the Cisco MGC to support M3UA and SUA, perform the procedures in the following order.
• Modifying Cisco ITP External Nodes
• Modifying Point Codes (OPC, DPC, and APC)
• Modifying M3UA and SUA Routing Keys
• Modifying M3UA and SUA Routes
• Modifying SS7 Signaling Services
• Modifying SS7 Subsystems
• Modifying M3UA and SUA SGPs
• Modifying IP Routes
• Modifying SCTP Associations
Note To begin the provisioning session, perform the steps in the "Starting a Provisioning Session" section. Once you have finished provisioning the M3UA and SUA data, save and activate your provisioning data by performing the steps in the "Saving and Activating your Provisioning Changes" section.
Modifying Cisco ITP External Nodes
Desc is the only parameter that can be modified for an existing Cisco ITP external node. To edit the description of a Cisco ITP external node, perform the following steps:
Step 1 Enter the following command to edit a Cisco ITP external node:
mml>prov-ed:extnode:name="name", desc="description"
Where:
•name—MML name of the Cisco ITP node to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
For example, to modify an Cisco ITP external node named itp1, you would enter the following command:
mml>prov-ed:extnode:name="itp1", desc="7200 ITP"
Step 2 Repeat the above step for each Cisco ITP external node you want to modify in your provisioning data.
Modifying Point Codes (OPC, DPC, and APC)
An OPC cannot be modified if it is a parent component for an SS7, M3UA, or SUA route. Therefore, OPCs cannot be modified. To change the values for an OPC, you would first have to delete it, and then re-provision it. For more information on deleting OPCs, refer to "Deleting Point Codes (OPC, DPC, and APC)" section.
To modify DPCs, perform the following steps:
Step 1 Enter the following command to modify a DPC:
mml>prov-ed:dpc:name="name", desc="description", netaddr="addr", netind=num
Where:
•name—MML name of the DPC to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•addr—The network address in dot notation.
•num—The network indicator number. The default value is 0.
For example, to modify an DPC named dpc1, you would enter the following command:
mml>prov-ed:DPC:NAME="dpc1",DESC="Destinatio PC1",NETADDR="1.1.3",NETIND=4
Step 2 Repeat the above step for each DPC you want to modify in your provisioning data.
To modify APCs, perform the following steps:
Step 1 Enter the following command to modify an APC:
mml>prov-ed:apc:name="name", desc="description", netaddr="addr", netind=num
Where:
•name—MML name of the APC to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•addr—The network address in dot notation.
•num—The network indicator number. The default value is 0.
For example, to modify an APC named apc1, you would enter the following command:
mml>prov-ed:apc:NAME="apc1",DESC="Adjacent PC1",NETADDR="1.2.5",NETIND=3
Step 2 Repeat the above step for each APC you want to modify in your provisioning data.
Modifying M3UA and SUA Routing Keys
M3UA and SUA routing keys cannot be modified. To enter different values for existing M3UA and SUA routing keys, you must first delete them, as described in the "Deleting M3UA and SUA Routing Keys" section, and then provision new M3UA and SUA routing keys, as described in the "Adding M3UA and SUA Routing Keys" section.
Modifying SS7 Signaling Services
To modify SS7 signaling services, perform the following steps:
Step 1 Set the SS7 signaling service to be modified to the OOS state by entering the following MML command:
mml>set-dest:sig_srv:OOS
Where sig_srv is the MML name of the SS7 signaling service to be modified.
Step 2 Repeat Step 2 for each SS7 signaling service to be modified.
Step 3 Start a provisioning session as described in the "Starting a Provisioning Session" section.
Step 4 Enter the following command to modify an SS7 signaling service:
mml>prov-ed:ss7path:name="name", desc="description", side=cmside, mdo="protFile",
custgrpid=num, m3uakey="rtkey"
Where:
•name—MML name of the SS7 signaling service to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•cmside—Q.931 call model side. The valid values are user, for the user side, and network, for the network side. The default value is network.
•protFile—MDO file name for the supported SS7 protocol. A list of file names for SS7 protocols supported in this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).
•num—Customer group ID number. The valid value is a four-digit number. The default value is 0000.
•rtkey—MML name of a previously provisioned M3UA key.
For example, to modify an SS7 signaling service named ss7svc1, you would enter the following command:
mml>prov-ed:SS7PATH:NAME="ss7svc1",DESC="Orig PC1 to INET Dest PC1",M3UAKEY="m3uakey2"
Step 5 Repeat Step 4 for each SS7 signaling service 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 the "Saving and Activating your Provisioning Changes" section.
Step 7 Set the modified SS7 signaling services to the IS state by entering the following MML command for each signaling service:
mml>set-dest:sig_srv:IS
Where sig_srv is the MML name of the modified SS7 signaling service.
Modifying M3UA and SUA Routes
To modify M3UA routes, perform the following steps:
Step 1 Enter the following command to modify an M3UA route:
mml>prov-ed:m3uaroute:name="name", desc="description", dpc="dpc", extnode="itp", opc="opc"
Where:
•name—MML name of the M3UA route to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•dpc—MML name of a previously provisioned DPC.
•itp—MML name of a previously provisioned Cisco ITP external node.
•opc—MML name of a previously provisioned OPC.
For example, to modify an M3UA route named m3uarte1, you would enter the following command:
mml>prov-ed:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Route 1",OPC="opc2",DPC="dpc2",
EXTNODE="itp2"
Step 2 Repeat the above step for each M3UA route you want to modify in your provisioning data.
To modify SUA routes, perform the following steps:
Step 1 Enter the following command to modify an SUA route:
mml>prov-ed:suaroute:name="name", desc="description", apc="apc", extnode="itp", opc="opc",
remotessn=num
Where:
•name—MML name of the SUA route to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•apc—MML name of a previously provisioned APC.
•itp—MML name of a previously provisioned Cisco ITP external node.
•opc—MML name of a previously provisioned OPC.
•num—SS7 subsystem number of the destination. The valid values are 2 through 254. The default value is 0.
For example, to modify an SUA route named suarte1, you would enter the following command:
mml>prov-ed:SUAROUTE:NAME="suarte1",DESC="SUA Route 1",APC="apc2",OPC="opc2",
EXTNODE="itp2", remotessn=50
Step 2 Repeat the above step for each SUA route you want to add to your provisioning data.
Modifying SS7 Subsystems
To modify SS7 subsystems, perform the following steps:
Step 1 Enter the following command to modify an SS7 subsystem:
mml>prov-add:ss7subsys:name="name", desc="description", suakey="key", proto="protFam",
transproto="protType", remotessn=remssn, localssn=locssn, stpscpind="index"
Where:
•name—MML name of the SS7 subsystem to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
•key—MML name of a previously defined SUA key.
•protFam—MML name of the associated SS7 protocol family. Valid values are:
–SS7-ANSI
–SS7-ITU
–SS7-China
–SS7-Japan
–SS7-UK
•protType—MML name of the transport protocol. Valid values are SCCP and SUA. The default value is SCCP.
•remssn—SS7 subsystem number of the destination. This number has to match the SSN value defined in the SUAROUTE.
•locssn—Local SS7 subsystem number value. The valid values are integers between 2 and 254. This parameter cannot be used if an M3UA key is provisioned.
•stpscpind—STP/SCP index used for Intelligent Network triggers.
For example, to modify an SS7 subsystem named ss7subsys1, you would enter the following command:
mml>prov-ed:SS7SUBSYS:NAME="ss7subsys1",DESC="Orig PC1 to APC",SUAKEY="suakey2",
PROTO="SS7-ANSI"
Step 2 Repeat the above step for each SS7 subsystem you want to modify in your provisioning data.
Modifying M3UA and SUA SGPs
Desc is the only parameter that can be modified in M3UA and SUA signaling gateway processes. To modify the descriptions of M3UA and SUA signaling gateway processes, perform the following steps:
Step 1 Enter the following command to modify a M3UA or SUA signaling gateway process:
mml>prov-ed:sgp:name="name", desc="description"
Where:
•name—MML name of the SGP to be modified.
•description—The long name assigned that can be as many as 128 alphanumeric characters in length.
For example, to modify an SGP for an M3UA path named m3ua-sgp1, you would enter the following command:
mml>prov-ed:SGP:NAME="m3ua-sgp1",DESC="M3UA SG Process 1 - ITP1"
Step 2 Repeat the above step for each SGP you want to modify in your provisioning data.
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 as described in the "Setting the Service State of an IP Route" section.
Step 2 Repeat Step 1 for each IP route to be modified.
Step 3 Start a provisioning session as described in the "Starting a Provisioning Session" section.
Step 4 Enter the following command to modify an IP route:
mml>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 decimal dot 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
IP Address should be in decimal dot notation and the hostname 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 decimal dot 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:
mml>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 the "Saving and Activating your Provisioning Changes" section.
Step 7 Set the IP route to be modified to the IS state as described in the "Setting the Service State of an IP Route" section.
Modifying SCTP Associations
To modify SCTP associations, perform the following steps:
Step 1 Set the SCTP association to be modified to the OOS state as described in the "Setting the Service State of an Association" section.
Step 2 Repeat Step 1 for each SCTP association to be modified.
Step 3 Start a provisioning session as described in the "Starting a Provisioning Session" section.
Step 4 Enter the following command to modify an SCTP association:
mml>prov-ed:association:name="name", desc="description", ipaddr1="addr1", ipaddr2="addr2",
port=num, peeraddr1="paddr1", peeraddr2="paddr2", peerport=pnum, iproute1="iprte1",
iproute2="iprte2", rcvwin=rcv, maxinittrans=rtxinitmsg, maxinitrto=rtxinittim,
maxretransdest=prtx, maxretrans=rtx, cumsackto=sacktm, bundleto=bundtm, minrto=minrtx,
maxrto=maxrtx, hbto=hb, ipprecedence="ipprec", dscp="dscp"
Where:
•name—The name you want to give to the component. 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 assigned that can be as many as 128 alphanumeric characters in length.
•addr1—First local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. Valid values are:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
•addr2—Second local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. This parameter is optional. Valid values are:
–IP_Addr1
–IP_Addr2
–IP_Addr3
–IP_Addr4
–N/A (default value)
•num—Local SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.
•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.
•pnum—Destination SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.
•iprte1—MML name of first IP route (optional). Valid value is the MML name of a previously provisioned IP route.
•iprte2—MML name of second IP route (optional). Valid value is the MML name of a previously provisioned IP route.
•rcv—Number of bytes to advertise for the local receive window (optional). Valid value is the range from 1500 to 65535. The default value is 18000.
•rtxinitmsg—Maximum number of times to retransmit SCTP INIT message (optional). Valid value is the range from 0 to 100. The default value is 10. A value of 0 means that the SCTP internal default value is used.
•rtxinittim—Maximum initial time retransmission value (optional). Valid value is the range from 300 to 3000, and 0. The default value is 2000. A value of 0 means that the SCTP internal default value is used.
•prtx—Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 3.
•rtx—Maximum number of retransmissions over all destination address before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 5.
Note The value of this parameter cannot exceed the value of the MAXRETRANSDEST parameter times the number of destinations.
•sacktm—Maximum time after a datagram is received before a SCTP SACK message is sent (optional). Valid value is the range from 100 to 500 ms. The default value is 300 ms.
•bundtm—Maximum time SCTP waits for other outgoing datagrams for bundling (optional). Valid value is the range from 100 to 600 ms. The default value is 100 ms.
•minrtx—Minimum value allowed for the retransmission timer (optional). Valid value is the range from 300 to 3000 ms. The default value is 300 ms.
•maxrtx—Maximum value allowed for the retransmission timer (optional). Valid value is the range from 1000 to 3000 ms. The default value is 3000 ms.
•hb—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.
•ipprec—IP precedence (optional). The value for this parameter is inserted in place of the IP precedence portion of the Type of Service field in outing SCTP datagrams. Valid values are as follows:
–ROUTINE (default) 000
–PRIORITY 001
–IMMEDIATE 010
–FLASH 011
–FLASH-OVERRIDE 100
–CRITICAL 101
–INTERNET 110
–NETWORK 111
•dscp—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.
–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 Class 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 (default)
For example, to modify an M3UA association named m3ua-assoc1, you would enter the following command:
mml>prov-ed:ASSOCIATION:NAME="m3ua-assoc1",DESC="M3UA Association 1", IPADDR1="IP_Addr2",
IPADDR2="IP_Addr1", PEERADDR1="10.82.80.188", PEERADDR2="10.82.81.165"
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 the "Saving and Activating your Provisioning Changes" section.
Step 7 Set the SCTP association to be modified to the IS state as described in the "Setting the Service State of an Association" section.
Deleting M3UA and SUA Components
This section contains the procedures that you must perform to delete M3UA and SUA components from your Cisco PGW 2200 provisioning data. When deleting the components that enable the Cisco PGW 2200 to support M3UA and SUA, perform the procedures in the following order.
• Deleting Cisco ITP External Nodes
• Deleting Point Codes (OPC, DPC, and APC)
• Deleting M3UA and SUA Routing Keys
• Deleting SS7 Subsystems
• Deleting M3UA and SUA Routes
• Deleting SS7 Subsystems
• Deleting M3UA and SUA SGPs
• Deleting IP Routes
• Deleting SCTP Associations
Note To begin the provisioning session, perform the steps in the "Starting a Provisioning Session" section. Once you have finished provisioning the M3UA and SUA data, save and activate your provisioning data by performing the steps in the "Saving and Activating your Provisioning Changes" section.
Deleting Cisco ITP External Nodes
To delete Cisco ITP 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 out-of-service state. Refer to the documentation for your media gateway for more information on taking interfaces out-of-service.
Step 2 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.
Step 3 If your system uses IP routes for this external node, delete the IP routes as described in the "Deleting IP Routes" section.
Step 4 Delete the SCTP associations for this external node, as described in the "Deleting SCTP Associations" section.
Step 5 Enter the following command to delete a Cisco ITP external node:
mml>prov-dlt:extnode:name="name"
Where name is the MML name of the Cisco ITP node to be deleted.
For example, to delete an Cisco ITP external node named itp1, you would enter the following command:
mml>prov-dlt:extnode:name="itp1"
Step 6 Repeat the above steps for each Cisco ITP external node you want to delete from your provisioning data.
Deleting Point Codes (OPC, DPC, and APC)
To delete OPCs, perform the following steps:
Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.
Step 2 Delete the SS7 routes. To do this, enter the following MML command:
mml>prov-dlt:ss7route:name="name"
Where name is the MML name of the SS7 route to be deleted.
For example, to delete an SS7 route named ss7route1, you would enter the following command:
mml>prov-dlt:ss7route:name="ss7route1"
Step 3 Delete the M3UA and SUA routing keys, as described in the "Deleting M3UA and SUA Routing Keys" section.
Step 4 Delete the M3UA and SUA routes, as described in the "Deleting M3UA and SUA Routes" section.
Step 5 Delete the SS7 subsystems, as described in the "Deleting SS7 Subsystems" section.
Step 6 Enter the following command to delete an OPC:
mml>prov-dlt:opc:name="name"
Where name is the MML name of the OPC to be deleted.
For example, to delete an OPC named opc1, you would enter the following command:
mml>prov-dlt:opc:name="opc1"
Step 7 Repeat the above steps for each OPC you want to delete from your provisioning data.
To delete DPCs, perform the following steps:
Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.
Step 2 Delete the SS7 routes. To do this, enter the following MML command:
mml>prov-dlt:ss7route:name="name"
Where name is the MML name of the SS7 route to be deleted.
For example, to delete an SS7 route named ss7route1, you would enter the following command:
mml>prov-dlt:ss7route:name="ss7route1"
Step 3 Delete the M3UA routing keys, as described in the "Deleting M3UA and SUA Routing Keys" section.
Step 4 Delete the M3UA routes, as described in the "Deleting M3UA and SUA Routes" section.
Step 5 Enter the following command to delete a DPC:
mml>prov-dlt:dpc:name="name"
Where name is the MML name of the DPC to be deleted.
For example, to delete an DPC named dpc1, you would enter the following command:
mml>prov-dlt:DPC:NAME="dpc1"
Step 6 Repeat the above steps for each DPC you want to delete from your provisioning data.
To delete APCs, perform the following steps:
Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.
Step 2 Delete the SS7 routes. To do this, enter the following MML command:
mml>prov-dlt:ss7route:name="name"
Where name is the MML name of the SS7 route to be deleted.
For example, to delete an SS7 route named ss7route1, you would enter the following command:
mml>prov-dlt:ss7route:name="ss7route1"
Step 3 Delete the SUA routing keys, as described in the "Deleting M3UA and SUA Routing Keys" section.
Step 4 Delete the SUA routes, as described in the "Deleting M3UA and SUA Routes" section.
Step 5 Enter the following command to delete an APC:
mml>prov-dlt:apc:name="name"
Where name is the MML name of the APC to be deleted.
For example, to delete an APC named apc1, you would enter the following command:
mml>prov-dlt:apc:NAME="apc1"
Step 6 Repeat the above steps for each APC you want to modify in your provisioning data.
Deleting M3UA and SUA Routing Keys
To delete M3UA routing keys, perform the following steps:
Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.
Step 2 Enter the following command to delete an M3UA routing key:
mml>prov-dlt:m3uakey:name="name"
Where name is the MML name of the M3UA routing key to be deleted.
For example, to delete an M3UA routing key named m3rteky1, you would enter the following command:
mml>prov-dlt:m3uakey:NAME="m3rtekey1"
Step 3 Repeat the above steps for each M3UA routing key you want to delete from your provisioning data.
To delete SUA routing keys, perform the following steps:
Step 1 Delete the SS7 subsystem, as described in the "Deleting SS7 Subsystems" section.
Step 2 Enter the following command to delete an SUA routing key:
mml>prov-dlt:suakey:name="name"
Where name is the MML name of the SUA routing key to be deleted.
For example, to delete an SUA routing key named suakey1, you would enter the following command:
mml>prov-dlt:suakey:NAME="suakey1"
Step 3 Repeat the above steps for each SUA routing key you want to delete from your provisioning data.
Deleting SS7 Signaling Services
To delete SS7 signaling services, perform the following steps:
Step 1 Log in to the active Cisco MGC, start an MML session, and enter the following command:
mml>set-dest:sig_srv:OOS
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:
mml>set-dest:sigsrv1:OOS
Step 2 Block all of the CICs associated with this signaling service using the following MML command:
mml>blk-cic:sig_svc:all
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:
mml>prov-dlt:nailedtrnk:dstsrv="sig_svc", "all"
Where sig_svc is the MML name of this signaling service.
Step 4 Enter the following command to delete an SS7 signaling service:
mml>prov-dlt:ss7path:name="name"
Where name is the MML name of the SS7 signaling service to be deleted.
For example, to delete an SS7 signaling service named ss7svc1, you would enter the following command:
mml>prov-dlt:SS7PATH:NAME="ss7svc1"
Step 5 Repeat the above steps for each SS7 signaling service you want to delete from your provisioning data.
Deleting M3UA and SUA Routes
To delete M3UA routes, perform the following steps:
Step 1 Enter the following command to delete an M3UA route:
mml>prov-dlt:m3uaroute:name="name"
Where name is the MML name of the M3UA route to be deleted.
For example, to delete an M3UA route named m3uarte1, you would enter the following command:
mml>prov-dlt:M3UAROUTE:NAME="m3uarte1"
Step 2 Repeat the above step for each M3UA route you want to delete from your provisioning data.
To delete SUA routes, perform the following steps:
Step 1 Enter the following command to delete an SUA route:
mml>prov-dlt:suaroute:name="name"
Where name is the MML name of the SUA route to be deleted.
For example, to delete an SUA route named suarte1, you would enter the following command:
mml>prov-dlt:SUAROUTE:NAME="suarte1"
Step 2 Repeat the above step for each SUA route you want to add to your provisioning data.
Deleting SS7 Subsystems
To delete SS7 subsystems, perform the following steps:
Step 1 Enter the following command to delete an SS7 subsystem:
mml>prov-dlt:ss7subsys:name="name"
Where name is the MML name of the SS7 subsystem to be deleted.
For example, to delete an SS7 subsystem named ss7subsys1, you would enter the following command:
mml>prov-dlt:SS7SUBSYS:NAME="ss7subsys1"
Step 2 Repeat the above step for each SS7 subsystem you want to delete from your provisioning data.
Deleting M3UA and SUA SGPs
To delete M3UA and SUA signaling gateway processes, perform the following steps:
Step 1 Delete the SCTP associations, as described in the "Deleting SCTP Associations" section.
Step 2 Enter the following command to delete a M3UA or SUA signaling gateway process:
mml>prov-dlt:sgp:name="name"
Where name is the MML name of the SGP to be deleted.
For example, to delete an SGP for an M3UA path named m3ua-sgp1, you would enter the following command:
mml>prov-dlt:SGP:NAME="m3ua-sgp1"
Step 3 Repeat the above steps for each SGP 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, as described in the "Setting the Service State of an IP Route" section.
Step 2 Delete any components that used this route as a parameter. To delete SCTP associations, perform the steps found in the "Deleting SCTP Associations" section .
Step 3 Enter the following command to delete an IP route:
mml>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:
mml>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 SCTP association to the OOS state as described in the "Setting the Service State of an Association" section.
Step 2 Enter the following command to delete an SCTP association:
mml>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 m3ua-assoc1, you would enter the following command:
mml>prov-dlt:ASSOCIATION:NAME="m3ua-assoc1"
Step 3 Repeat the above steps for each SCTP association you want to delete from your provisioning data.
Troubleshooting Tips
The following sections contain troubleshooting procedures related to provisioning:
• Alarm Troubleshooting Procedures
• Signaling Channel Troubleshooting Procedures
For more information on troubleshooting the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Alarm Troubleshooting Procedures
The alarms listed below are the new and modified alarms for this feature that require user action to be rectified. For a complete list of Cisco MGC alarms, refer to the Cisco Media Gateway Controller Software Release 9 System Messages Guide.
All M3UAKEY Ack Pending
This alarm occurs when the PGW cannot send or receive traffic for the identified SS7 signaling service.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Compare the routing context of the M3UA routing keys on the PGW with the AS definitions on the Signaling Gateway and reprovision to make them match.
Step 2 Verify that the AS is not shutdown on the Signaling Gateway.
Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
All M3UA Assoc Fail
This alarm occurs when all M3UA associations transporting SS7 signaling have failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Verify that the SGs are operating normally.
Step 2 Verify that the Ethernet interfaces between the Cisco MGC and the SGs are working properly.
Step 3 Verify that the configuration for your system is correct.
Step 4 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
All SUAKEY Ack Pending
This alarm occurs when the PGW cannot send or receive traffic for the identified SS7 subsystem.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Compare the routing context of the SUA routing keys on the PGW with the AS definitions on the Signaling Gateway and reprovision to make them match.
Step 2 Verify that the AS is not shutdown on the Signaling Gateway.
Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
All SUA Assoc Fail
This alarm occurs when all SUA associations transporting SS7 signaling have failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Verify that the SGs are operating normally.
Step 2 Verify that the Ethernet interfaces between the Cisco MGC and the SGs are working properly.
Step 3 Verify that the configuration for your system is correct.
Step 4 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
INVALID M3UA RC
This alarm occurs when an M3UA message is received from the identified signaling gateway with a routing context that has not been provisioned on the PGW.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Compare the routing context of the M3UA routing keys on the PGW and the Signaling Gateway and reprovision to make them match.
Step 2 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
INVALID SUA RC
This alarm occurs when there is a mismatch between SUA routing keys defined on the MGC and the Signaling Gateway.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Compare the routing context of the SUA routing keys on the MGC and the Signaling Gateway and reprovision to make them match.
Step 2 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
M3UAKEY Ack Pending
This alarm occurs when the MGC cannot send or receive traffic for the identified SS7 signaling service via the signaling gateway that has not acknowledged the M3UAKEY.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Compare the routing context of the M3UA routing keys on the MGC with the AS definitions on the Signaling Gateway and reprovision to make them match.
Step 2 Verify that the AS is not shutdown on the Signaling Gateway.
Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
SUAKEY Ack Pending
This alarm occurs when the PGW cannot send or receive traffic for the identified SS7 subsystem via the signaling gateway that has not acknowledged the SUAKEY.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Compare the routing context of the SUA routing keys on the PGW with the AS definitions on the Signaling Gateway and reprovision to make them match.
Step 2 Verify that the AS is not shutdown on the Signaling Gateway.
Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
SS7 SIG SRVC UNAVAIL
The identified SS7 signaling service is unavailable.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1 Perform the MML command rtrv-dest on the SS7PATH or SS7SUBSYS object.
If the state is OOS,FLD, the signaling service is out of service due to failure of the MTP3 transport. Perform a prov-rtrv:SS7PATH or a prov-rtrv:SS7SUBSYS on the signaling service object.
a. If the object has an OPC attribute defined, the signaling service is using SLTs for SS7 communication. The MTP3 layer is on the PGW. The SS7ROUTEs and LINKSETs need to be examined to determine the cause of the failure.
b. If the object doesn't have an OPC attribute define, the signaling service is using ITPs for SS7 communication. The MTP3 layer is one the ITPs. Examine the M3UAROUTEs that have the same OPC and DPC as SS7PATH or the SUAROUTEs that have the same OPC, APC, and REMOTE SSN to determine which ITP EXTNODEs are being uses by the signaling service. Consult the ITP documentation and debug the problem on the ITPs.
If the state is OOS,FLD&UPU, the signaling service is out of service due to failure of the user part layer at the destination. This remote destination should be examined to determine the cause of the failure.
Step 2 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
Signaling Channel Troubleshooting Procedures
The following signaling channel troubleshooting procedures are new for this feature:
• Resolving an Association Alarm
• Setting the Service State of an Association
• Setting the Service State of an IP Route
Resolving an Association Alarm
When referred here by an alarm indicating a failure on an association, perform the following steps:
Step 1 If this alarm occurs along with the LIF FAIL alarm on the failed destination address, proceed to Step 2. Otherwise, proceed to Step 4.
Step 2 Verify the functioning of the cabling between the Cisco MGC and the destination address.
If the cables are functioning properly, proceed to Step 3.
If bad cable(s) are found, replace them. If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 3.
Step 3 Verify the functioning of the associated LAN switch.
If the LAN switch is functioning properly, proceed to Step 6.
If the LAN switch is not functioning properly, refer to the documentation for your LAN switch for troubleshooting information. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 4 Debug the IP connectivity between the Cisco MGC and the associated external node.
If the IP connectivity is working correctly, proceed to Step 5.
If the IP connectivity is not working correctly, refer to the documentation for the external node to determine a method to identify and fix the IP connectivity problem. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 5.
Step 5 Determine the health of the associated external node.
If the external node is working correctly, proceed to Step 6.
If the external node is not healthy, refer to the documentation for the external node for troubleshooting information. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.
Setting the Service State of an Association
To change the service state of an association, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml>set-association:assoc_name:serv_state[,confirm]
Where:
•assoc_name—MML name of the association you want to modify.
•serv_state—Service state to which you want to change. Valid values for IP links are IS, OOS, and FOOS.
•confirm—This parameter is required when you are setting the service state to OOS or FOOS.
Note This command cannot be used on the standby Cisco MGC.
For example, to set the service state of the association, assoc1, to OOS, enter the following command:
mml>set-association:assoc1:OOS,confirm
You can verify that the selected association is in the proper service state by performing the procedure in the "Retrieving the Service State for Associations" section.
Setting the Service State of an IP Route
To change the service state of an IP route, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml>set-iproute:iproute_name:serv_state[,confirm]
Where:
•iproute_name—MML name of the IP route you want to modify.
•serv_state—Service state to which you want to change. Valid values for IP links are IS, OOS, and FOOS.
•confirm—This parameter is required when you are setting the service state to OOS or FOOS.
Note This command cannot be used on the standby Cisco MGC.
An IP route in any of the following combinations of primary and secondary service states can be set to OOS or FOOS:
•IS
•OOS, CONF
•OOS, OFF_DUTY
•OOS, STDBY
For an IP route to be set to IS, it must have a primary service state of OOS and secondary service state of COOS.
For example, you would enter the following command to set the service state of an IP route called iprte1 to OOS:
mml>set-iproute:iprte1:OOS,confirm
Note You can verify that the selected IP route is in the proper service state by performing the procedure in the "Retrieving the Service State for IP Routes" section.
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, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide
Regular Operations
Introduction of this feature requires the new procedures for managing signaling channels.
Managing Signaling Channels
The following sections are new or modified for Release 9.4:
• Retrieving the Service State for Associations
• Retrieving the Service State for IP Routes
Retrieving the Service State for Associations
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:
mml>rtrv-association:assoc_name
For example, to retrieve the service state of an association called assoc1, enter the following command:
mml>rtrv-association:assoc1
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 20:26:18
M RTRV
"assoc1:IS"
To retrieve attributes for all of the associations, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml>rtrv-association:all
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 19:23:23
M RTRV
"assoc1:OOS
"assoc2:OOS
"assoc3:OOS
"assoc4:OOS
The valid service states for an association are described in the following sections. If the association is in any other state than IS, attempt to bring it into service, as described in the "Resolving an Association Alarm" section.
Association Primary Service States
The PST field shows the current primary service state of the association. Table 1 lists the valid primary service state values:
Table 1 Association Primary Service States
Link State ID
|
Link State
|
Description
|
INB
|
Install busy
|
When a system is first configured, all associations default to this state and must be manually set in-service (IS) through the use of the set-iplnk MML command.
|
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.
|
Association Secondary Service States
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
Link State ID
|
Link State
|
Description
|
COOS
|
Commanded out-of-service
|
Association has been commanded OOS by the operator.
|
STBY
|
Standby
|
Association on the standby Cisco MGC.
|
CONF
|
Configuration
|
Association is OOS due to a configuration failure.
|
Retrieving the Service State for IP Routes
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:
mml>rtrv-iproute:iproute_name
For example, to retrieve the service state of an IP route called iprte1, enter the following command:
mml>rtrv-iproute:iprte1
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 20:26:18
M RTRV
"iprte1:IS"
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:
mml>rtrv-iproute:all
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 19:23:23
M RTRV
"iprte1:IS
"iprte2:IS
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, as described in the "Setting the Service State of an IP Route" section.
IP Route Primary Service States
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.
|
IP Route Secondary Service States
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 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.
|
Provisioning Examples
This section provides the following examples of provisioning for this feature:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7 External Node
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:extnode:name="va-2600-164",type="ITP",desc="2651 ITP",GROUP=1
prov-add:extnode:name="va-2600-165",type="ITP",desc="2651 ITP",GROUP=1
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Point Codes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:opc:name="opc",DESC="Own pointcode",NETADDR="2.1.4",NETIND=2,type="TRUEOPC"
prov-add:opc:name="opc-sua",DESC="Own pointcode for SUA", NETADDR="2.1.5",
NETIND=2,type="TRUEOPC"
prov-add:DPC:NAME="dpc1",DESC="DPC1",NETADDR="1.1.5",NETIND=2
prov-add:DPC:NAME="dpc2",DESC="DPC2",NETADDR="1.2.2",NETIND=2
prov-add:apc:name="apc1",DESC="APC",NETADDR="1.2.4",NETIND=2
prov-add:apc:name="apc2",DESC="APC",NETADDR="1.2.5",NETIND=2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA Key
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:M3UAKEY:NAME="m3uakey1",OPC="opc",DPC="dpc1",SI="ISUP", ROUTINGCONTEXT=10
prov-add:M3UAKEY:NAME="m3uakey2",OPC="opc",DPC="dpc2",SI="ISUP", ROUTINGCONTEXT=11
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA Key
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SUAKEY:NAME="suakey1",DESC="SUA Key 1",OPC="opc-sua",APC="apc1",
LOCALSSN=200,ROUTINGCONTEXT=20
prov-add:SUAKEY:NAME="suakey2",DESC="SUA Key 2",OPC="opc-sua",APC="apc2",
LOCALSSN=200,ROUTINGCONTEXT=21
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SUAROUTE:NAME="suarte1",DESC="SUA Rte 1",OPC="opc-sua",APC="apc1",
EXTNODE="va-2600-164",REMOTESSN=200
prov-add:SUAROUTE:NAME="suarte2",DESC="SUA Rte 2",OPC="opc-sua",APC="apc1",
EXTNODE="va-2600-165",REMOTESSN=200
prov-add:SUAROUTE:NAME="suarte3",DESC="SUA Rte 1",OPC="opc-sua",APC="apc2",
EXTNODE="va-2600-164",REMOTESSN=200
prov-add:SUAROUTE:NAME="suarte4",DESC="SUA Rte 1",OPC="opc-sua",APC="apc2",
EXTNODE="va-2600-165",REMOTESSN=200
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7PATH
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7PATH:NAME="ss7svc1",DESC="OPC1 to INET DPC1",M3UAKEY="m3uakey1", DPC="dpc1",
MDO="Q761_BASE"
prov-add:SS7PATH:NAME="ss7svc2",DESC="OPC1 to INET DPC2",M3UAKEY="m3uakey2", DPC="dpc2",
MDO="Q761_BASE"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7SUBSYS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7SUBSYS:NAME="ss7subsys1",DESC="OPC1 to APC",SUAKEY="suakey1", SVC="apc1",
PROTO="SS7-ITU",TRANSPROTO="SUA"
prov-add:SS7SUBSYS:NAME="ss7subsys2",DESC="OPC1 to APC2",SUAKEY="suakey2", SVC="apc2",
PROTO="SS7-ITU",TRANSPROTO="SUA"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Rte 1",OPC="opc",DPC="dpc1",
EXTNODE="va-2600-164"
prov-add:M3UAROUTE:NAME="m3uarte2",DESC="M3UA Rte 2",OPC="opc",DPC="dpc1",
EXTNODE="va-2600-165"
prov-add:M3UAROUTE:NAME="m3uarte3",DESC="M3UA Rte 3",OPC="opc",DPC="dpc2",
EXTNODE="va-2600-164"
prov-add:M3UAROUTE:NAME="m3uarte4",DESC="M3UA Rte 4",OPC="opc",DPC="dpc2",
EXTNODE="va-2600-165"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA SGP
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SGP:NAME="m3ua-sgp1",DESC="M3UA SGP 1 - va-2600-164 ITP",
EXTNODE="va-2600-164"
prov-add:SGP:NAME="m3ua-sgp2",DESC="M3UA SGP 2 - va-2600-165 ITP",
EXTNODE="va-2600-165"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA SGP
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SGP:NAME="sua-sgp1",DESC="SUA SGP 1 - va-2600-164 ITP",
EXTNODE="va-2600-164"
prov-add:SGP:NAME="sua-sgp2",DESC="SUA SGP 2 - va-2600-165 ITP",
EXTNODE="va-2600-165"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA ASSOCIATION
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:ASSOCIATION:NAME="m3ua-assoc1",DESC="M3UA Association 1",
TYPE="M3UA",SGP="m3ua-sgp1", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164"
prov-add:ASSOCIATION:NAME="m3ua-assoc2",DESC="M3UA Association 2",
TYPE="M3UA",SGP="m3ua-sgp2", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.188",PEERADDR2="10.82.81.165"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA ASSOCIATION
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:ASSOCIATION:NAME="sua-assoc1",DESC="M3UA Association 1",
TYPE="SUA",SGP="sua-sgp1", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164"
prov-add:ASSOCIATION:NAME="sua-assoc2",DESC="M3UA Association 2",
TYPE="SUA",SGP="sua-sgp2", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.188",PEERADDR2="10.82.81.165"
Additional examples of provisioning for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Command Reference
This section documents new, modified, or deleted Man-Machine Language (MML) commands. All other commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide.
New MML Commands
This section contains the MML commands that are new for this feature.
RTRV-ASSOCIATION—Display State of SCTP Association
Purpose:
|
This MML command displays the primary and secondary states of an SCTP association.
|
Syntax:
|
rtrv-association:assoc_name
rtrv-association:all
|
Input Description:
|
•Assoc_name—MML name of a previously configured SCTP association.
•All—All associations
|
Output Description:
|
SCTP Association—MML name of SCTP association specified.
PST—Primary state; valid values are:
–INB—Installed busy; association has been created but has not yet been commanded IN or OOS with the set-association command.
–IS—In service
–OOS—Out of service
SST—Secondary state; valid values are:
–COOS—Commanded out of service
–STBY—The local platform state is standby
–CONF—Out of service due to a configuration failure
|
Example:
|
The MML command shown in the following example retrieves the state of all associations:
mml> rtrv-association:all
MGC-01 - Media Gateway Controller 2001-01-01 18:57:26
M RTRV
"assoc1:IS"
"assoc2:OOS,COOS"
;
|
Comments:
|
Performance Impact Category: A
|
RTRV-IPROUTE—Display Primary and Secondary States of an IP Route
Purpose:
|
This MML command displays the primary and secondary states of an IP route.
|
Syntax:
|
rtrv-iproute:ip_route_name
rtrv-iproute:all
|
Input Description:
|
•Ip_route_name—MML name of a previously configured IP route.
•All—Retrieves the primary state of all IP routes.
|
Output Description:
|
IP route—MML name of the specified IP route.
PST—Primary state; valid values are:
–IS—In service
–OOS—Out of service
SST—Secondary state; valid values are:
–COOS—Commanded out of service
–STBY—The local platform state is standby
–OFF_DUTY—The link is available for use but is not currently being used.
–CONF—The link is out of service due to a configuration failure.
|
Example:
|
The MML command shown in the following example retrieves the state of all IP routes:
mml> rtrv-iproute:all
MGC-01 - Media Gateway Controller 2002-06-25 15:13:40.983 EST
M RTRV
"iproute1:IS"
"iproute2:IS"
|
Comments:
|
Performance Impact Category: A
|
RTRV-SGP—Display the Primary and Secondary States of an SGP
Purpose:
|
This MML command displays the primary and secondary states of an SGP.
|
Syntax:
|
rtrv-sgp:sgp_name
rtrv-sgp:all
|
Input Description:
|
•Isgpe_name—MML name of a previously configured SGP.
•All—Retrieves the primary state of all SGPs.
|
Output Description:
|
IP route—MML name of the specified IP route.
PST—Primary state; valid values are:
–INB—Installed busy (resource is being created, its state has not been determined yet)
–IS—In service
–OOS—Out of service
SST—Secondary state; valid values are:
–STBY—The local platform state is standby
–CONF—The link is out of service due to a configuration failure.
|
Example:
|
The MML command shown in the following example retrieves the state of all SGPs:
mml> rtrv-sgp:all
MGC-01 - Media Gateway Controller 2003-01-25 15:13:40.983 EST
M RTRV
"sgp1:IS"
"sgp2:IS"
|
Comments:
|
Performance Impact Category: A
|
SET-ASSOCIATION—Changing Association Primary State
Purpose:
|
This MML command changes the primary state of an SCTP association.
|
Syntax:
|
set-association:assoc_name:PST[,confirm]
|
Input Description:
|
•Assoc_name—MML name of a previously configured SCTP association.
•PST—Desired primary state; valid values are IS, OOS, or FOOS
•Confirm—Verify desired state. This parameter must be used when the primary state desired is OOS
|
Example:
|
The MML command shown in the following example changes the primary state of an association to out of service:
mml> set-association:assoc1:OOS,confirm
|
Comments:
|
Performance Impact Category: B
|
SET-IPROUTE—Changing IP Route Primary State
Purpose:
|
This MML command changes the primary and secondary states of an IP route.
|
Syntax:
|
set-iproute:ip_route_name:pst[,confirm]
|
Input Description:
|
•IP_rout_name—MML name of a previously configured IP route.
•PST—Desired primary state; valid values are IS, OOS, or FOOS
•Confirm—Must be used when you set the primary state to OOS to verify the new state. An IP route in any of the following states can be commanded OOS:
–IS
–OOS,CONF
–OOS,OFF_DUTY
–OOS,STBY.
|
Example:
|
The MML command shown in the following example changes the primary state of an IP route to out of service:
mml> set-iproute:iproute1:oos,confirm
|
Comments:
|
Performance Impact Category: B
|
Modified MML Commands
This section contains the MML commands that were modified for this feature.
PROV-ADD—Add Provisioning Component
Purpose:
|
This MML command adds a component to the Cisco MGC configuration.
|
Syntax:
|
prov-add:<comp>:name="<MML name>",<param name>=<param value>,...
prov-add:lnksetprop:name="<protocol family>",<param name>=<param value>,...
|
Input Description:
|
•lnksetprop—MML NE component consisting of parameters for which you can tune linkset communications. See Appendix A of the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a list of linkset property parameters.
•comp—MML component type name for the type of configuration you are creating. The component type must match one of the component types listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide. If comp is EXTNODE, then the param_name TYPE must be present and needs to take a set of values (refer to the second example below). New components are added to this command for this feature.
•name—MML component name for the new object you are creating (as many as ten characters).
•protocol family—Name of the protocol family for which you are provisioning linkset properties. Use PROV-RTRV:VARIANTS for a list of protocol families configured for your system.
•param name—The name of a valid configuration parameter for the specified component type. Parameter names are listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
•param value—The value you want to assign to the parameter. If the parameter value is a string, it should be surrounded by quotation marks.
To define more than one parameter, enter additional param name=param value descriptions on the command line.
|
Example:
|
The MML command shown in the following example adds the origination point code for the MGC configuration:
mml> PROV-ADD:opc:NAME="opc",DESC="Point code of CP1",netaddr="0.0.1",
netind=2,type="TRUEOPC"
Media Gateway Controller - MGC-01 2000-01-12 15:19:51
M COMPLD
"opc"
;
|
Example:
|
The MML command shown in the following example adds an external node to the MGC configuration:
mml> PROV-ADD:EXTNODE:NAME="TOTO2",DESC="TATA",TYPE="MGX8260"
Media Gateway Controller - MGC-02 2000-05-08 18:05:55
M COMPLD
"extnode"
;
|
Comments:
|
Performance Impact Category: B
Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a description of using the PROV commands for provisioning and for a description of components, parameter names, and parameter values used in provisioning the MGC.
|
PROV-DLT—Delete Components or Parameters
Purpose:
|
This MML command deletes a provisioned component.
|
Syntax:
|
prov-dlt:<comp>:name="<MML name>"
prov-dlt:lnksetprop:name="<protocol family>"
|
Input Description:
|
•lnksetprop—MML NE component consisting of parameters for which you can tune linkset communications. See Appendix A of the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a list of linkset property parameters.
•comp—MML component type name for the type of configuration you are creating. The component type must match one of the component types listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide. New components are added to this command for this feature.
•name—MML name of the component you are modifying.
•protocol family—Name of the protocol family for which you are provisioning linkset properties. Use PROV-RTRV:VARIANTS for a list of protocol families configured for your system.
|
Example:
|
The MML command shown in the following example deletes the point code component "opc":
mml> PROV-DLT:opc:NAME="opc"
Media Gateway Controller - MGC-01 2000-01-12 15:19:51
M COMPLD
"opc"
;
|
Comments:
|
Perform PROV-STA—Start Provisioning Session before using this command.
Performance Impact Category: B
Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a description of using the PROV commands for provisioning and for a description of components, parameter names, parameter descriptions, and parameter values used in provisioning.
|
PROV-ED—Modify Provisioned Component
Purpose:
|
This MML command modifies a provisioned component.
Note Only those parameters that need to be modified must be entered.
|
Syntax:
|
prov-ed:<comp>:name="<MML name>",<param name>=<param value>,...
prov-add:lnksetprop:name="<protocol family>",<param name>=<param
value>,...
|
Input Description:
|
•lnksetprop—MML NE component consisting of parameters for which you can tune linkset communications. See Appendix A of the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a list of linkset property parameters.
•comp—MML component type name for the type of configuration you are creating. The component type must match one of the component types listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide. New components are added to this command for this feature.
•name—MML name for the component you are modifying. You cannot change the component name.
•protocol family—Name of the protocol family for which you are provisioning linkset properties. Use PROV-RTRV:VARIANTS for a list of protocol families configured for your system.
•param name—The name of each configuration parameter you want to change. The parameter names must be valid for the specified component type. Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a description of components, parameter names, parameter descriptions, and parameter values.
•param value—The new value you want to assign to the parameter. If the parameter value is a string, it should be surrounded by quotation marks.
Note To modify more than one parameter, enter additional param name=value descriptions on the command line.
|
Example:
|
The MML command shown in the following example changes the description of the provisioned point code "opc":
mml> PROV-ED:opc:NAME="opc", DESC="Point code for this SSP"
Media Gateway Controller - MGC-01 2000-01-12 15:19:51
M COMPLD
"opc"
;
|
Comments:
|
Perform PROV-STA—Start Provisioning Session before using this command.
Performance Impact Category: B
Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for information on using the PROV commands for provisioning and for a description of components, parameter names, and parameter values used in provisioning.
|
RTRV-DEST—Retrieve Destination
Purpose:
|
This MML command retrieves information about one or more destinations.
|
Syntax:
|
rtrv-dest:<sig path>
rtrv-dest:all
|
Input Description:
|
•sig path—The MML name of the logical signal channel for which you want to display information. These should be signal path DSS IP or signal path NAS entities.
•all—Displays information about all external point codes and signal paths.
|
Output Description:
|
•<SIG PATH>—Signal path.
•PKG—Protocol family.
•ASSOC—Associated channels.
–UNK—Unknown.
–SWITCHED—The destination is switched, not associated.
–<CHANNEL>—The channel with which the destination is associated.
•PST—Primary state.
–AOOS—The system has taken it out of service.
–INB—Installed busy (resource has been created but not yet commanded IS or OOS by means of the SET-DEST command).
–IS—In service.
–MOOS—Manually taken out of service.
–OOS—Out of service.
–TRNS—Transient; the state is currently being changed.
–UNK—Unknown.
•SST—Secondary State.
–UND—Undefined.
–CRTE—Created.
–DLT—Deleted.
–CIS—Commanded in service.
–COOS—Commanded out of service.
–FLD—Failed.
–RSTO—Restored.
–RST—Reset.
–CONG—Congestion.
–FOOS—Forced out of service.
–CINH—Commanded to the inhibited state.
–CUINH—Commanded to the uninhibited state.
–CEA—Commanded into emergency alignment.
–EIS—Engine in service.
–EOOS—Engine out of service.
–UPU—User part unavailable (added in Release 9.4(1))
|
Example:
|
The MML command shown in the following example retrieves the destination of signal path ss7svc1:
mml> RTRV-DEST:SS7SVC1
MGC-01 - Media Gateway Controller 2001-02-08 13:06:29
M RTRV
"ss7svc1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=RSTO"
;
|
Comments:
|
Performance Impact Category: C
This command supports wildcarding.
|
SET-IPLNK—Changing IP Link Primary State
Purpose:
|
This MML command changes the primary state of an IP link.
|
Syntax:
|
set-iplnk:iplnk_name:PST[,confirm]
|
Input Description:
|
•Iplink_name—MML component name of an existing IP link
•PST—Desired primary state; valid values are IS, OOS, or FOOS
•Confirm—Verify desired state. This parameter must be used when the primary state desired is OOS
|
Example:
|
The MML command shown in the following example changes the primary state of an IP link to out of service:
mml> set-iplnk:iplink1:OOS,confirm
|
Comments:
|
.Performance Impact Category: B
|
VLD-CIC—Validate a Circuit
The VLD-CIC MML command previously could only be used for SS7PATHs in the ANSI protocol family. The VLD-CIC MML command can now also be used for SS7PATHs in the ITU protocol family. An ISUP CVT command is send on the specified CIC for the ANSI protocol family and an ISUP CVR is expected in response. For the ITU protocol family, an ISUP UPT command is send and an ISUP UPA is expected in response.
Purpose:
|
This MML command validates a circuit on a specified signal path and CIC. As of Release 9.4(1), you can use this command on both ANSI and ITU SS7 signaling services.
|
Syntax:
|
vld-cic:<sigpath>:cic=<number>
|
Input Description:
|
•sigpath—MML component name of a signal path associated with the CIC.
•number—A valid circuit identification code.
|
Example:
|
The MML command shown in the following example validates a circuit on SS7SVC1 CIC-105:
ml> VLD-CIC:SS7SVC1:CIC=105
Media Gateway Controller - MGC-01 2000-03-07 09:35:19
M RTRV
"ss7svc1:CIC=105,PASSED"
;
|
Example:
|
The MML command shown in the following example shows the MML response for a circuit that has failed validation:
mml> VLD-CIC:SS7SVC1:CIC=1314
MGC-01 - Media Gateway Controller 2001-02-08 13:54:04
M RTRV
"ss7svc1:CIC=1314,FAIL"
;
|
Comments:
|
Performance Impact Category: B
|
Output Description:
|
LOC: Values associated with the Cisco MGC.
REM: Values associated with the destination exchange. Valid values for these fields are:
•GRP—Circuit group carrier indicator. The values in these fields should be the same in the LOC and REM lines. Valid values are:
–UNK—Unknown circuit group carrier type
–ANL—Analog circuit group carrier type
–DIG—Digital circuit group carrier type
–AND—Analog and digital circuit group carrier type
•SEIZ—Double seizing indicator. The values for this field in the LOC line should be logically opposite to the value for the REM line. Valid values are:
–NONE—No circuit control. When one line is set to NONE, the other should be set to ALL.
–ALL— All circuit control. When one line is set to ALL, the other should be set to NONE.
–EVEN— Even circuit control. When one line is set to EVEN, the other should be set to ODD.
–ODD—Odd circuit control. When one line is set to ODD, the other should be set to EVEN
•ALM—Alarm carrier indicator. The values in these fields should be the same in the LOC and REM lines. Valid values for this field are:
–UNK—Unknown alarm carrier
–SOFT—Software alarm carrier
–HARD—Hardware alarm carrier
|
| |
•COT—Continuity check requirements indicator. The values in these fields should be the same in the LOC and REM lines. Valid values are:
–UNK—Unknown continuity check requirements
–NONE—No continuity check requirements
–STAT—Statistical continuity check requirements
–PERC—Per call continuity check requirements
|
| |
•TRK—Trunk number. This field is always displayed in the LOC line. It is only displayed in the REM line when the circuit identification names for the Cisco MGC and the destination exchange do not match.
•A_CLLI—Common language location identifier (CLLI) for either the destination exchange or the Cisco MGC. CLLIs for each are sorted alphanumerically, and the A_CLLI field is populated with the CLLI that is first alphanumerically. This field is always displayed in the LOC line. It is only displayed in the REM line when the circuit identification names for the Cisco MGC and the destination exchange do not match.
•Z_CLLI—CLLI code assigned to the Cisco MGC for either the destination exchange or the Cisco MGC. CLLIs for each are sorted alphanumerically, and the Z_CLLI field is populated with the CLLI that is last alphanumerically. This field is always displayed in the LOC line. It is only displayed in the REM line when the circuit identification names for the Cisco MGC and the destination exchange do not match.
|
Reference Information
The following sections contain reference material related to this feature. Information is included on the following areas:
• XECfgParm.dat Parameters
• Alarms
• Logs
• Measurements
• Components
• External Node Types
• Properties
• Provisioning Worksheets
XECfgParm.dat Parameters
The XECfgParm.dat file configuration parameters added for this feature are in the table below. None of the parameters added for this feature can be modified.
Configuration Parameter
|
Definition
|
*.M3UA.maxSigServices
|
Defines the maximum number of M3UA signaling services. It also defines the maximum number of M3UA routing keys.
Value: 1536
Note Do not change this value.
|
*.M3UA.maxOPCs
|
Defines the maximum number of M3UA OPCs.
Value: 64
Note Do not change this value.
|
*.M3UA.maxRoutesPerOpcDpc
|
Defines the maximum number of M3UA routes per OPC/DPC pair.
Value: 2
Note Do not change this value.
|
*.M3UA.maxSgp
|
Defines the maximum number of M3UA SS7 signaling gateway processes.
Value: 96
Note Do not change this value.
|
*.SUA.maxSigServices
|
Defines the maximum number of SUA signaling services. It also defines the maximum number of SUA routing keys.
Value: 256
Note Do not change this value.
|
*.SUA.maxOPCs
|
Defines the maximum number of SUA OPCs.
Value: 64
Note Do not change this value.
|
*.SUA.maxRoutesPerOpcApcSsn
|
Defines the maximum number of SUA routes per OPC, APC, and SSN set.
Value: 2
Note Do not change this value.
|
*.SUA.maxSgp
|
Defines the maximum number of SUA SS7 signaling gateway processes.
Values: 8
Note Do not change this value.
|
For information on the other XECfgParm.dat parameters, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Alarms
This section lists the alarms that have been added, modified or deleted in the Cisco MGC software to support this feature. For information on the other alarms for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.
New Alarms
This section contains the alarms that are added to support this feature.
All M3UAKEY Ack Pending
Description All acknowledgements for an M3UAKEY associated with this SS7PATH have not been received
Severity Minor
Cause The PGW cannot send or receive traffic for the SS7PATH
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
All M3UA Assoc Fail
Description All M3UA Associations transporting SS7 signaling have failed
Severity Critical
Cause All M3UA Associations transporting SS7 signaling have failed
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
All SUAKEY Ack Pending
Description All acknowledgements for an SUAKEY associated with this SS7SUBSYS have not been received
Severity Minor
Cause The PGW cannot send or receive traffic for the SS7SUBSYS
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
All SUA Assoc Fail
Description All SUA Associations transporting SS7 signaling have failed
Severity Critical
Cause All SUA Associations transporting SS7 signaling have failed
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
INVALID M3UA RC
Description Indicates there is mismatch between the M3UA routing keys on the PGW and the Signaling Gateway.
Severity Information
Cause Generated against a signaling gateway external node when an M3UA message is received from the signaling gateway with a routing context that has not been provisioned on the PGW
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
INVALID SUA RC
Description Invalid SUA Routing Context received from the Signaling Gateway
Severity Information
Cause There is a mismatch between SUA routing keys on the PGW and the Signaling Gateway
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
ISUP: T4 Expired
Description The ISUP t4 timer has expired
Severity Information
Cause When MTP STATUS primitive with cause "remote user unavailable" is received, UPT message is sent and T4 timer is started. When T4 timer expires UPT message is sent and T4 timer is started again. Alarm is generated every time T4 expires.
If UPT is requested by MML, UPT message is sent and T4 timer is started. When timer expires UPT message is sent again and T4 timer is started second time. When T4 timer expires a second time alarm is generated and UPT message is not sent anymore.
Type 0
Action No action required
M3UAKEY Ack Pending
Description An acknowledgement for an M3UAKEY associated with this SS7PATH or SG has not been received
Severity Minor
Cause The PGW cannot send or receive traffic for the SS7PATH via the SG that has not acknowledged the M3UAKEY
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
SUAKEY Ack Pending
Description An acknowledgement for an SUAKEY associated with this SS7SUBSYS or SG has not been received
Severity Minor
Cause The PGW cannot send or receive traffic for the SS7SUBSYS via the SG that has not acknowledged the SUAKEY
Type 1
Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
Modified Alarms
This section contains the alarm that is modified to support this feature.
SS7 SIG SRVC UNAVAIL
Description SS7 signaling service is unavailable
Severity Major
Cause The identified SS7 signaling service is unavailable
Type 1
Action The recommended action of this alarm is modified to support this feature.
Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.
Deleted Alarms
The following alarms are deleted to support this feature:
•AVM DS1 FAIL
•AVM E1 FAIL
•AVM DS3 FAIL
•AVM STS1 FAIL
•AVM OC3 FAIL
Logs
This section lists the logs that are added or deleted to support this feature. For information on the other logs, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.
New Logs
This section contains the logs that are added to support this feature.
TIOS_ERR_INVALID_RC: Invalid %s ROUTING CONTEXT %d for SG %C
This message indicates a mismatch in the configuration of Routing Context between PGW and the Signaling Gateway.
Where:
•%s: M3UA or SUA
•%d: RC Value
•%C: Name of SG.
Deleted Logs
This section contains the logs that are deleted to support this feature.
•PROT_ERR_AVM
•PROT_ERR_AVM_RSP_AFTER_TO
•PROT_INFO_AVM_SIG_CHAN
•PROT_INFO_AVM_SIG_PATH
•PROT_TRACE_AVM_PDU
•PROT_WARN_AVM_CONFIG_FAIL
•TIOS_WARN_AVM_SSC_XMIT
•TIOS_WARN_XMIT_AVM
•PROT_ERR_VSI
•PROT_ERR_VSI_ENG_SERVICE
•PROT_ERR_VSI_MASTER
•PROT_ERR_VSI_RESYNC_BADCKSUMBLK_EXCEEDED
•PROT_ERR_VSI_RESYNC_CKSUMBLK_NOTFOUND
•PROT_ERR_VSI_RESYNC_CONNID_CMTSTATUSFAIL
•PROT_ERR_VSI_RESYNC_CONNID_DELETEFAIL
•PROT_ERR_VSI_RESYNC_CONNID_NOTFOUND
•PROT_ERR_VSI_RESYNC_PENDLIST_ADDFAIL
•PROT_ERR_VSI_RESYNC_PENDLIST_EMPTY
•PROT_ERR_VSI_RESYNC_PHYSIF_NOTFOUND
•PROT_ERR_VSI_STATUSRESP_SENDFAIL
•PROT_ERR_VSI_UNKN_MSGTYPE
•PROT_INFO_VSI_CFG_MSG
•PROT_INFO_VSI_MASTER
•PROT_INFO_VSI_RESP_RCV
•PROT_INFO_VSI_SIG_CHAN
•PROT_INFO_VSI_SIG_PATH
•PROT_TRACE_VSI_MASTER_MSG_SEND
•PROT_TRACE_VSI_PDU
•PROT_TRACE_VSI_PROCCTRLREQ
•PROT_WARN_VSI
•PROT_WARN_WRITE_EVT
•TIOS_ERR_ASP_MSG
•TIOS_WARN_ASP_RESET
•TIOS_WARN_ASP_SSC_RCV
•CP_CRIT_ASP_TYPE
•CP_ERR_CRT_ASP
•CP_INFO_RMG_INIT
•TIOS_WARN_UNREC_ENUM
•TIOS_ERR_CARD_INIT
•TIOS_ERR_COLL_ERR
•TIOS_ERR_INVALIDCARD
•TIOS_ERR_INV_CARD
•TIOS_ERR_INV_CARRIER
•TIOS_ERR_NOLINE
•TIOS_ERR_NOLINECOMP<<LOG TEXT>>
Measurements
The following table contains the system measurements that are added to support this feature.
Table 5 New Operational Measurements
MML Counter Group:Name
|
Description
|
Related Components
|
Logging Interval
|
M3UA GROUP
M3UA: ErrorTx
M3UA: ErrorRx
M3UA: NotifyTx
M3UA: NotifyRx
M3UA: DunaRx
M3UA: DavaRx
|
M3UA message statistics
Number of error messages transmitted.
Number of error messages received
Number of notify messages transmitted
Number of notify messages received
Number of DUNA messages received
Number of DAVA messages received
|
Association
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
M3UA: DaudTx
M3UA: SconRx
M3UA: DrstRx
M3UA: DupuRx
M3UA: ASPUpTx
M3UA: ASPDnTx
M3UA: ASPUpAckRx
M3UA: ASPDnAckRx
M3UA: ASPActTx
M3UA: ASPInactTx
M3UA: AspActAckRx
M3UA: AspInactAckRx
|
Number of DAUD messages transmitted
Number of SCON messages received
Number of DRST messages received
Number of DUPU messages transmitted
Number of ASP UP messages transmitted
Number of ASP DOWN messages transmitted
Number of ASP UP acknowledgements received
Number of ASP DOWN acknowledge messages received
Number of ASP ACTIVE messages transmitted
Number of ASP INACTIVE messages transmitted
Number of ASP ACTIVE ACK messages received
Number of ASP INACTIVE ACK messages received
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
M3UA: DataXferTx
M3UA: DataXferRx
M3UA: DataBytesTx
M3UA: DataBytesRx
M3UA: InvSctpSig
M3UA: AssocFail
M3UA: AssocTxFail
M3UA: RxVersionErr
M3UA: RxMsgClassErr
M3UA: RxMsgTypeErr
M3UA: RxMsgLenErr
M3UA: RxStrmIdErr
M3UA: RxUnexpMsgErr
|
Number of DATA transfer messages transmitted
Number of DATA transfer messages received
Number of M3UA data bytes transmitted
Number of M3UA data bytes received
Number of invalid SCTP signals received by M3UA
Number of SCTP association failures
Number of transmit SCTP failures
Number of messages received with an invalid version
Number of received messages with an unexpected or unsupported Message Class
Number of messages received with an unexpected or unsupported Message Type
Number of messages received with length error
Number of messages received with stream ID error, when a message is received on an unexpected SCTP stream (for example, a Management message was received on a stream other than "0")
Number of unexpected messages received - a defined and recognized message is received that is not expected in the current state
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
M3UA: RxProtErr
M3UA: RxParmValErr
M3UA: RxParmFieldErr
M3UA: RxUnexpParmErr
M3UA: RxNtwkAppErr
M3UA: RouteCntxErr
M3UA: RxNoMemErr
|
Number of messages received with protocol errors, for any protocol anomaly (that is, reception of a parameter that is syntactically correct but unexpected in the current state).
Number of messages received with parameter value errors
Number of messages received with a parameter having a wrong length field
Number of messages received that contain one or more invalid parameters
Number of messages received with an invalid (unconfigured) Network Appearance.
Number of messages received with an invalid (unconfigured) Routing Context.
Number of messages that were dumped because memory ran out (buffer overflow).
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
SUA GROUP
SUA: ErrorTx
SUA: ErrorRx
SUA: NotifyTx
SUA: NotifyRx
SUA: DunaRx
SUA: DavaRx
SUA: DaudTx
SUA: SconRx
SUA: DrstRx
SUA: DupuRx
SUA: ASPUpTx
SUA: ASPDnTx
|
SUA message statistics
Number of error messages transmitted
Number of error messages received
Number of notify messages transmitted
Number of notify messages received
Number of DUNA messages received
Number of DAVA messages received
Number of DAUD messages transmitted
Number of SCON messages received
Number of DRST messages received
Number of DUPU messages transmitted
Number of ASP UP messages transmitted
Number of ASP DOWN messages transmitted
|
Association
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
SUA: ASPUpAckRx
SUA: ASPDnAckRx
SUA: ASPActTx
SUA: ASPInactTx
SUA: AspActAckRx
SUA: AspInactAckRx
SUA: CldtTx
SUA: CldrRx
SUA: DataBytesTx
SUA: DataBytesRx
SUA: InvSctpSig
SUA: AssocFail
SUA: AssocTxFail
|
Number of ASP UP acknowledgements received
Number of ASP DOWN acknowledge messages received
Number of ASP ACTIVE messages transmitted
Number of ASP INACTIVE messages transmitted
Number of ASP ACTIVE ACK messages received
Number of ASP INACTIVE ACK messages received
Number of Connectionless Data Transfers sent
Number of Connectionless Data Responses received
Number of SUA data bytes transmitted
Number of SUA data bytes received
Number of invalid SCTP signals received by SUA
Number of SCTP association failures
Number of transmit SCTP failures
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
SUA: RxVersionErr
SUA: RxMsgClassErr
SUA: RxMsgTypeErr
SUA: RxMsgLenErr
SUA: RxStrmIdErr
|
Number of messages received with an invalid version.
Number of received messages with an unexpected or unsupported Message Class.
Number of messages received with an unexpected or unsupported Message Type
Number of messages received with length error
Number of messages received with stream ID error, when a message is received on an unexpected SCTP stream (that is, a Management message was received on a stream other than "0")
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
SUA: RxUnexpMsgErr
SUA: RxProtErr
SUA: RxParmValErr
SUA: RxParmFieldErr
SUA: RxUnexpParmErr
SUA: RxNtwkAppErr
SUA: RouteCntxErr
SUA: RxNoMemErr
|
Number of unexpected messages received, a defined and recognized message is received that is not expected in the current state
Number of messages received with protocol errors, for any protocol anomaly (that is, reception of a parameter that is syntactically correct but unexpected in the current state).
Number of messages received with parameter value errors
Number of messages received with a parameter having a wrong length field
Number of messages received that contain one or more invalid parameters
Number of messages received with an invalid (unconfigured) Network Appearance.
Number of messages received with an invalid (unconfigured) Routing Context.
Number of messages that were dumped because memory ran out (buffer overflow).
|
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
ISUP-GROUP
ISUP: XMIT UPA TOT
ISUP: RCV UPA TOT
ISUP: XMIT UPT TOT
ISUP: RCV UPT TOT
|
ISUP message traffic statistics
Number of UPA messages sent
Number of UPA messages received
Number of UPT messages sent
Number of UPT messages received
|
MGC NE
|
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
|
For information on the other system measurements, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Components
The sections below contain the provisioning components that are added, modified, or deleted for this feature. For information on the rest of the components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
New Components
The following provisioning components are added for this feature.
IP Route
The IP route represents a static IP route. Its MML name is as follows:
• MML Name—IPROUTE
The IP route component structure is shown in Table 6.
Table 6 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 any 128 characters.
|
DEST
|
Destination hostname or IP address
|
IP Address in decimal dot notation or hostname that is less than or equal to 32 characters.
|
NETMASK
|
Subnet mask of Destination (optional)
|
IP Address in decimal dot notation. (255.255.255.255)
|
NEXTHOP
|
Next hop router IP address
|
IP Address or hostname 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.
The following rules apply when creating or editing IP Routes:
•The NETMASK attribute is validated by the system. For your provisioning set-up 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 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 would be 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 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 hostname or symbolic name from XECfgParm.dat, it can resolve to the address 0.0.0.0, which indicates 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 of the IPADDR.
The commands to retrieve and set the service state of an IP route can be found in the "Retrieving the Service State for IP Routes" section and the "Setting the Service State of an IP Route" section, respectively.
M3UA Key
This component represents an M3UA routing key. The parent component of the M3UAKEY is the OPC.
• MML Name—M3UAKEY
The M3UA key component structure is shown in Table 7.
Table 7 M3UAKEY Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
M3UA key 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.
|
OPC
|
Associated OPC
|
MML name of a previously configured OPC.
|
DPC
|
Associated DPC (optional)
|
MML name of a previously configured DPC.
|
ROUTING CONTEXT
|
Routing context value
|
Any integer except 0 (0 indicates no routing context). Each M3UA key must have a unique routing context.
|
SI
|
Service indicator
|
Service type, values are ISUP, TUP, and N/A (N/A).
|
NETWORK APPEARNCE
|
Network appearance (optional)
|
This parameter is optional. The valid values are integers from 1 through 32767. A value of 0 indicates an invalid network appearance.)
|
Note None of the parameters for this command can be modified.
The following rules apply when creating M3UA keys:
•You can provision a maximum of 1536 M3UA keys
•Up to 64 OPCs can use M3UA signaling services.
•Parent OPC must be a true OPC
•Cannot be deleted if it is being used by an SS7 signaling service
•Two M3UA keys or SUA keys cannot have the same routing context value
M3UA Route
This component represents an M3UA route. It is used to determine how to get an SS7 message to a particular destination using M3UA.
• MML Name—M3UAROUTE
The M3UA route component structure is shown in Table 8.
Table 8 M3UAROUTE Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
M3UA 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.
|
DPC
|
Associated DPC
|
MML name of a previously configured DPC.
|
EXTNODE
|
Associated external node
|
MML name of a previously configured external node.
|
OPC
|
Associated OPC
|
MML name of a previously configured OPC.
|
Note NAME is the only parameter for this command that cannot be modified.
The following rules apply when creating/editing M3UA routes:
•The associated DPC must have an SS7 signaling service with an M3UA key defined (matches DPC attribute). If an M3UA key does not exist when the M3UA route is added/edited, a warning is issued. If an M3UA key is still not defined when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.
•Multiple DPCs with the same NETADDR cannot be routed to the same OPC
•The associated OPC must be a true OPC
•For a given OPC/DPC only one route can be defined through a given external node.
•Up to two M3UA routes can be defined per OPC-DPC pair
•The associated external node must support M3UA signaling
•M3UA routes for the same OPC-DPC pair must have external nodes in the same group
•When the provisioning session is saved and activated, there must be an ASSOCIATION of type M3UA using an SGP that is using the EXTNODE of each M3UAROUTE.
SCTP Association
The SCTP association represents the connection between the Cisco MGC and a media gateway. Its MML name is as follows:
• MML Name—ASSOCIATION
Table 9 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
|
MML name of SGP (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 address 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 will wait 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 will be place in the IP PRECEDENCE portion of the Type Of Service field for outgoing SCTP datagrams (optional)
Refer to the right column.
|
ROUTINE 000
PRIORITY 001
IMMEDIATE 010
FLASH 011
FLASH-OVERRIDE 100
CRITICAL 101
INTERNET 110
NETWORK; (ROUTINE) 111
|
DSCP
|
Differential Service Code Point. This value is place in the DSCP portion of the Type Of 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).
|
The SCTP association component structure is shown in Table 9.
The following parameters cannot be modified:
•NAME
•EXTNODE
•TYPE
•SGP
The following rules apply when creating/editing SCTP associations:
•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 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 hostname is specified for a peer IP address, the hostname must resolve to an IP address.
•PEERADDR1 and PEERADDR2 can resolve to the same IP Address. If the external node only has 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 the you that the NASPATH must also be deleted. If it hasn't when the provisioning session is saved and activated, an error message is generated and the operation is stopped.
•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 or 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
•You can provision up to 96 associations with a type of M3UA.
•You can provision up to 8 associations with a type of SUA.
The commands to retrieve and set the service state of an association can be found in the "Retrieving the Service State for Associations" section and the "Setting the Service State of an Association" section, respectively.
SS7 Signaling Gateway Process
This component represents a SS7 signaling gateway process.
• MML Name—SGP
The SS7 signaling gateway process component structure is shown in Table 10.
Table 10 SGP Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
M3UA 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 that is running the SS7 signaling gateway process
|
MML name of a previously defined external node
|
Note DESC is the only parameter for this command that can be modified.
The following rules apply when creating/editing SS7 signaling gateway processes:
•You can provision up to 96 M3UA SS7 signaling gateway processes.
•You can provision up to 8 SUA SS7 signaling gateway processes.
•For the provisioning session to be copied or deployed without error, an SCTP association must be using the SS7 signaling gateway process.
SUA Key
This component represents a SUA Routing key. The parent component for the SUAKEY is the OPC.
• MML Name—SUAKEY
The SUA key component structure is shown in Table 11.
Table 11 SUAKEY Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
M3UA key 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.
|
OPC
|
Associated OPC
|
MML name of a previously configured OPC.
|
APC
|
Associated APC (optional)
|
MML name of a previously configured APC.
|
LOCAL SSN
|
Associated local SSN
|
Number of a local SSN. Values are 0, 2-254 (0).
|
ROUTING CONTEXT
|
Routing context value
|
Any integer except 0 (0 indicates no routing context). Each SUA key must have a unique routing context.
|
NETWORK APPEARNCE
|
Network appearance
|
The valid values are integers from 1 through 32767. The value must match the network appearance value set on your Cisco ITP.
|
Note None of the parameters for this command can be modified.
The following rules apply when creating SUA keys:
•You can provision up to 256 SUA keys.
•Up to 64 OPCs can use SUA signaling services.
•Parent OPC must be a true OPC
•Cannot be deleted if it is being used by an SS7 signaling service
•Two M3UA keys or SUA keys cannot have the same routing context value
SUA Route
This component represents a SUA route. It is used to determine how to get an SS7 message to a particular destination using SUA.
• MML Name—SUAROUTE
The SUA route component structure is shown in Table 12.
Table 12 SUAROUTE Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
NAME
|
SUA 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.
|
APC
|
Associated APC
|
MML name of a previously configured APC.
|
EXTNODE
|
Associated external node
|
MML name of a previously configured external node.
|
OPC
|
Associated OPC
|
MML name of a previously configured OPC.
|
REMOTESSN
|
Associated remote SSN
|
Number of a remote SSN. Values are 0, 2-254 (0).
|
Note NAME is the only parameter for this command that cannot be modified.
The following rules apply when creating/editing SUA routes:
•The associated APC must have an SS7 subsystem with an SUA key defined. If an SUA key is not defined when the provisioning session is saved and activated, an error message is generated and the operation is stopped.
•Multiple APCs with the same NETADDR cannot be routed to the same OPC.
•The associated OPC must be a true OPC.
•For a given OPC, DPC, and remote SSN set, only one route can be defined through a given external node.
•Up to two SUA routes can be defined per OPC, APC, and remote SSN set.
•The associated external node must support SUA signaling.
•SUA routes for the same OPC-APC pair must have external nodes in the same group.
•When the provisioning session is saved and activated, there must be an ASSOCIATION of type SUA using an SGP that is using the EXTNODE of each SUAROUTE.
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 as follows:
•MML Name—EXTNODE
The parameters for EXTNODE are defined in Table 13.
Table 13 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 the "External Node Types" section.
|
ISDNSIGTYPE
|
ISDN Signaling Type
|
Valid values are IUA or N/A (default is N/A). Added this parameter 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. Added this parameter 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.
•You can provision up to 256 external nodes with an ISDNSIGTYPE of IUA.
IP Link
The IP link component type represents an IP link used on the CIsco MGC. IP links are used to communicate with the access control devices, such as a NAS. Its MML name is as follows:
•MML Name—IPLNK
The IP link service component structure is shown in Table 14.
Table 14 IP Link 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 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.
|
IF
|
Ethernet interface MML name
|
MML name of a previously defined ENETIF or index of the ENETIF for SNMP. Removed this parameter in software Release 9.4(1).
|
PORT
|
Local port number
|
Any valid IP port number greater than 1024 (Recommended setting of 2427 for MGCP and SGCP).
|
PRI
|
Priority
|
Integer greater than 0; (1).
|
PEERADDR
|
Remote IP address
|
IP address; (0.0.0.0). This may also be specified as a hostname or a DNS name.
|
PEERPORT
|
Remote port
|
Any valid IP port number greater than 1024 (Recommended setting of 2427 for MGCP and SGCP)
|
IPADDR
|
Local logical IP address
|
IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4.
|
SVC
|
Signaling service this IP supports
|
MML name of a previously defined signal service or index of the signal service for SNMP.
|
NEXTHOP
|
Next hop address
|
IP address or hostname of the next hop; (0.0.0.0). Removed this parameter in software Release 9.3(2).
|
NETMASK
|
Subnet mask address
|
Subnet mask address; (255.255.255.255). Removed this parameter in software Release 9.3(2).
|
IPROUTE
|
IP route MML name
|
MML name of a previously defined IPROUTE. Added this parameter in software Release 9.4(1)T.
|
Note Only the NAME and SVC parameters cannot be modified.
The following rules apply when creating or editing IP links:
•If the SVC is a NASPATH, then the ISDNSIGTYPE of the EXTNODE must be N/A.
•If the SVC is a NASPATH, then the port number must be an odd number.
•If the SVC is a NASPATH, then the local and remote port must be the same.
•The maximum number of links per port is defined by the XECfgParm.dat parameter, maxNumLinks.
•Links using the same SVC must have the same port number.
•Links using the same SVC must have the same peer port number.
•Cannot have more than two links using the same SVC and port number.
•Peer address is unique per external node.
•When an IPROUTE is specified, the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes of the IPROUTE to verify the IPROUTE is valid.
•When IPROUTE is specified, the IPADDR must match the IPADDR of the IP link.
•When an IPROUTE is not specified, the IP Address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it is not assigned to one of the IPROUTEs. If the PEERADDR is on the same subnet as an IPROUTE, then the link uses that IPROUTE.
•The PORT attribute cannot be the same value as the PORT attribute of any ASSOCIATION, SESSIONSET, SIPLNK, or SS7SGLNK.
•The PORT attribute cannot be set to the same value as the PORT attribute of an IPLNK with an SVC type different then the IPLNK SVC type. That is, the PORT value of an IPLNK supporting an NASPATH SVC cannot be the same as the PORT value of an IPLNK support an MGCPPATH, or EISUPPATH SVC.
•Another IPLNK, SESSIONSET, SS7SGLNK, or ASSOCIATION with a different EXTNODE or SGNODE cannot use the resolved value of PEERADDR.
SIP IP Link
This is the MGC NE component type and represents a SIP IP link used on the MGC NE. These links are used to communicate with the SIP proxy servers. Its MML name is as follows:
•MML Name—SIPLNK
The SIP link component structure is shown in Table 15.
Table 15 SIP Link 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 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.
|
IF
|
Ethernet interface MML name
|
MML name of a previously defined Ethernet interface. Removed this parameter in software Release 9.4(1)T
|
PORT
|
Local port number
|
Any valid IP port number greater than 1024 (Recommended setting of 5060 for SIP).
|
PRI
|
Priority
|
Integer greater than 0; (1).
|
IPADDR
|
Local logical IP address
|
IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4.
|
SVC
|
Signaling service this IP supports
|
MML name of a previously defined signal service.
|
NEXTHOP
|
Next hop address
|
IP address or hostname of the next hop; (0.0.0.0). Removed this parameter in software Release 9.4(1)T.
|
NETMASK
|
Subnet mask address
|
Subnet mask address; (255.255.255.255). Removed this parameter in software Release 9.4(1)T.
|
Note Only the NAME and SVC parameters cannot be modified.
SS7 SG IP Link
This is the MGC NE component type and represents an IP link between the SS7 signaling gateway and the Cisco MGC. Its MML name is as follows:
•MML Name—SS7SGIPLNK
The SS7 SG IP link component structure is shown in Table 16.
Table 16 SS7 SG IP Link 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 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.
|
IF
|
Ethernet interface MML name
|
MML name of a previously defined Ethernet interface. Removed this parameter in software Release 9.4(1)T
|
PORT
|
Local port number
|
Any valid IP port number greater than 1024.
|
PRI
|
Priority
|
Integer greater than 0: (1)
|
PEERADDR
|
Remote IP address
|
IP address; (0.0.0.0). This may also be specified as a hostname or a DNS name.
|
PEERPORT
|
Remote port
|
Any valid IP port number
greater than 1024.
Note This field is ignored by the TIOS subsystems at this time.
The peerport value is contained in the XECfgParm field stPort. Currently set to 32767.
|
IPADDR
|
Local logical IP address
|
IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4;
|
SLC
|
Signaling link code
|
0 through 15; (1)
|
SGNODE
|
SG node MML name
|
MML name of a previously defined SG Node.
|
NEXTHOP
|
Next hop address
|
IP address or hostname of the next hop; (0.0.0.0). Removed this parameter in software Release 9.4(1)T.
|
NETMASK
|
Subnet mask address
|
Subnet mask address; (255.255.255.255). Removed this parameter in software Release 9.4(1)T.
|
IPROUTE
|
IP route MML name
|
MML name of a previously configured IPROUTE. Added this parameter in software Release 9.4(1)T.
|
Note Only the NAME and SGNODE parameters cannot be modified.
The following rules apply when creating or editing SS7 SG IPLNKs:
•When an IPROUTE is specified, the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes of the IPROUTE to verify that the IPROUTE is valid.
•When an IPROUTE is specified, the IPADDR must match the IPADDR of the link.
•When an IPROUTE is not specified, the IP Address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it should not be assigned to one of the IPROUTEs. If the PEERADDR is on the same subnet as an IPROUTE, then the link should use that IPROUTE.
•The PORT attribute cannot be set to the same value as the PORT attribute of any ASSOCIATION, IPLNK, SESSIONSET, or SS7SGLNK.
•There is a maximum of 2 links allowed per SGNODE.
SS7 Signaling Service (sigpath)
The SS7 Signaling Service (sigpath) component type represents an SS7 signaling service or signaling path to a particular SS7 switch (destination). Its name is as follows:
•MML Name—SS7PATH
The SS7 signaling service component structure is shown in Table 17.
Table 17 SS7 Signaling Service 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 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.
|
SIDE
|
Q.931 call model side
|
String user for user side and network for network side; (network).
|
MDO
|
MDO file name
|
Valid protocol name from variants.dat. (This is limited to any MDO SS7 protocol variant.)
|
DPC
|
Destination point code MML name
|
MML name of a previously defined point code.
|
CUSTGRPID
|
Customer group ID
|
Four digit ID; (0000).
|
OPC
|
Originating Point Code MML name
|
MML name of a previously defined point code. Not allowed if M3UAKEY is specified.
|
M3UAKEY
|
M3UA Routing key MML name
|
MML name of a previously defined M3UA routing key. Not allowed if OPC is specified. This property added in software Release 9.4(1)T.
|
Note Only the NAME and DPC parameters cannot be modified.
The following rules apply when creating or editing SS7 signaling services:
•If OPC is specified then M3UAKEY cannot be specified.
•If M3UKAEY is specified then OPC cannot be specified.
•If M3UAKEY has a DPC, it must match with the DPC parameter.
•An OPC/DPC pair cannot use both M3UA (M3UAKEY specified) and SS7 signaling services (OPC specified).
•Can only have one SS7 service for an OPC/DPC pair.
•Can only have one M3UA service for a DPC/M3UAKEY pair.
•A maximum of 1536 M3UA signaling services can be defined.
•A M3UAROUTE must be defined when M3UAKEY is specified. This check is done when a provisioning session is saved and activated.
•A SS7ROUTE must be defined when OPC is specified. This check is done when a provisioning session is saved and activated.
•When editing an existing SS7 signaling service and specifying an OPC, if an M3UAKEY is set the OPC value must match the OPC of the M3UAKEY and the M3UAKEY value is then set to NULL.
Note This scenario is for falling back from an upgrade for the Support for M3UA and SUA with SCTP Feature.
•When editing an existing SS7 signaling service and specifying a M3UAKEY, if an OPC is set the OPC value must match the OPC of the M3UAKEY and the OPC is then set to NULL.
Note This scenario is for upgrading for the Support for M3UA and SUA with SCTP Feature.
SS7 Route
The SS7 route component type represents an SS7 route. It is used in systems using Cisco SLTs to determine how to get an SS7 message to a particular destination. Its MML name is as follows:
•MML Name—SS7ROUTE
The SS7 route component structure is shown in Table 18.
Table 18 SS7 Route Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
DPC
|
Destination point code MML name
|
MML name of a previously defined point code.
|
LNKSET
|
Linkset MML name
|
MML name of a previously defined linkset.
|
OPC
|
Originating point code MML name
|
MML name of a previously defined point code.
|
PRI
|
Priority
|
Integer greater than 0; (1).
|
The validation rules for this component are modified to allow an SS7ROUTE to be defined using a DPC that is not being used by a SS7PATH.
SS7 Subsystem
The SS7 subsystem component type represents an SS7 subsystem. It is used for specifying mated STPs and to provide LNP support through a SCP. Its MML name is as follows:
•MML Name—SS7SUBSYS
The SS7 subsystem component structure is shown in Table 19.
Table 19 SS7 Subsystem Component Structure
Parameter MML Name
|
Parameter Description
|
Parameter Values (Default)
|
SVC
|
MML name of Adjacent point code or TCAP/IP service
|
MML name of a previously defined adjacent point code, or MML name of a previously defined TCAP/IP service.
|
PROTO
|
Protocol family
|
SS7-ANSI or SS7-ITU when creating an AIN subsystem.
|
MATEDAPC
|
Adjacent point code of the mated STP
|
MML name of a previously defined adjacent point code used when mating STPs. Not used when creating an AIN subsystem.
|
PRI
|
Priority
|
Integer greater than 0; (1). Not used when mating STP pairs.
|
LOCALSSN
|
Subsystem number
|
Integer from 2 through 254;(0) Can be set to non-zero only for SS7-ANSI, SS7-ETSI, or SS7-ITU. If set to 0, the subsystem is used for mating two STPs. Not allowed if M3UAKEY is specified.
|
STPSCPIND
|
STP/SCP index used for IN triggers
|
Integer greater than 0; (0). Not used when mating STP pairs.
|
TRANSPROTO
|
Transport protocol
|
SCCP, TCPIP, or SUA. If SVC is an APC, SCCP should be used. If SVC is a TCAP over IP service then TCPIP should be used; (SCCP). Not used when mating STP pairs.
|
OPC
|
Originating point code MML name of the mated STP
|
MML name of a previously defined originating point code. Either OPC, M3UAKEY, or SUAKEY can be specified.
|
SUAKEY
|
MML name of an SUA key (optional)
|
MML name of a previously defined routing key ID. Only used in support of SUA. Not allowed if OPC is specified. Added this parameter in software Release 9.4(1)T.
|
REMOTESSN
|
Remote subsystem number
|
Integer from 2 through 254;(0). Can be set to non-zero only for SS7-ANSI, SS7-ETSI, or SS7-ITU. If set to 0, the subsystem is used for mating two STPs. Use LOCALSSN if not specified.
|
Note Only the SVC parameter cannot be modified.
Keep the following in mind when creating or editing SS7 subsystems:
•OPC must be a true OPC
•An SS7 route cannot be defined to SVC(APC) if SUAKEY is specified.
•At least one SUA route must be defined to SVC(APC) if SUAKEY is specified
•If the APC is specified in the SUAKEY then it must be the same as SVC(APC)
•SSN is not allowed if SUAKEY is specified.
•If the TRANSPROTO is SUA, then SUAKEY must be specified, and MATEDAPC and OPC cannot be specified.
•If the TRANSPROTO is SCCP, then OPC must be specified, and SUAKEY cannot be specified.
•Remote SSN of the SUARoute must match the RemoteSSN of the SS7Subsystem.
Deleted Components
The following provisioning components are obsolete as of Release 9.4(1):
•CARD
•ENETIF
•FASPATH
•TDMIF
•TDMLNK
External Node Types
Table 20 lists the valid external node types for this release of Cisco MGC software.
Table 20 External Node Types
External Node MML Name
|
Release
|
Supported Signaling Service Types
|
AS3600
|
Release 9.1(5) and up
|
MGCP IPFAS NAS IUA
|
AS3660
|
Release 9.1(5) and up
|
MGCP IPFAS NAS IUA
|
AS5200
|
Release 9.1(5) and up
|
IPFAS NAS
|
AS5300
|
Release 9.1(5) and up
|
MGCP IPFAS NAS IUA
|
AS5350
|
Release 9.2(2) and up
|
MGCP IPFAS NAS BSMV0 IUA
|
AS5400
|
Release 9.2(2) and up
|
MGCP IPFAS NAS BSMV0 IUA
|
AS5800
|
Release 9.1(5) and up
|
IPFAS NAS
|
AS5850
|
Release 9.1(5) and up
|
IPFAS NAS
|
AS7200
|
Release 9.1(5) and up
|
MGCP IPFAS NAS
|
CAT8510
|
Release 9.1(5) and up
|
MGCP
|
CAT8540
|
Release 9.1(5) and up
|
MGCP
|
C2600
|
Release 9.4(1) and up
|
MGCP IPFAS IUA
|
H323
|
Release 9.1(5) and up
|
EISUP
|
ITP
|
Release 9.4(1) and up
|
M3UA SUA
|
LS1010
|
Release 9.1(5) and up
|
MGCP
|
MC3810
|
Release 9.1(5) and up
|
MGCP IPFAS
|
MGC
|
Release 9.1(5) and up
|
EISUP
|
MGX8260
|
Release 9.1(5) and up
|
MGCP IPFAS NAS
|
MGX8850
|
Release 9.1(5) and up
|
MGCP SGCP IPFAS
|
SLT
|
Release 9.2(2) and up
|
BSMV0
|
TALISS7
|
Release 9.1(5) and up
|
SS7SG
|
UNKNOWN
|
Release 9.1(5) and up
|
UNKNOWN
|
Properties
The following property is added for this feature.
Property
|
Definition
|
*.t4
|
When an MTP status primitive with a cause of remote user unavailable is received, an UPT message is sent and the T4 timer is started. When the T4 timer expires, another UPT message is sent and the T4 timer is started again. The ISUP: T4 Expired alarm is generated every time the T4 timer expires.
If you request UPT using MML, an UPT message is sent and the T4 timer is started. When the T4 timer expires, another UPT message is sent and T4 timer is started again. When the T4 timer expires second time alarm is generated and UPT message is not sent anymore.
Values range from 300,000 to 900,000. All timer values are represented in ms (1 minute = 60 seconds, 1 second = 1000 ms, 300,000 ms = 5 minutes, 900,000 ms = 15 minutes)
Default: 300000
|
This property is associated with the following parent objects:
Property Name
|
Parent Objects and Protocols
|
SS7-China
|
SS7-ITU
|
T4
|
Q761_CHINA Q761_CHINA_C2
|
ISUPV2_FRENCH ISUPV2_AUSTRIAN ISUPV2_SWISS ISUPV2_SWISS_C2 ISUPV2_FINNISH96 Q761_BASE ISUPV2_CZECH ISUPV2_32DIG ISUPV2_SPANISH_C2 ISUPV2_DUTCH ISUPV2_NORWEGIAN ETS_300_356
|
For information on other properties for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Provisioning Worksheets
This section contains worksheets for the provisioning components required for this feature.
Table 21 External Node Worksheet Example
Name
|
Type
|
ISDN Signaling Type
|
Group
|
Description
|
itp1
|
itp
|
n/a
|
25
|
Cisco ITP number 1
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
Table 22 IP Route Worksheet Example
Name
|
Destination
|
Subnet Mask
|
Next Hop
|
IP Address
|
Priority
|
Description
|
iproute1
|
itp1
|
255.255.255.0
|
itp2
|
175.25.211.17
|
1
|
IP route to itp1
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
Table 23 M3UA Key Worksheet Example
Name
|
OPC
|
DPC
|
Routing Context
|
Service Indicator
|
Network Appearance
|
Description
|
m3key1
|
opc1
|
dpc1
|
14
|
ISUP
|
700
|
M3UA key 1
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
Table 24 M3UA Route Worksheet Example
Name
|
DPC
|
External Node
|
OPC
|
Description
|
m3rte1
|
dpc1
|
itp1
|
opc1
|
M3UA route 1
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
Table 25 SCTP Association Worksheet Example
Parameter
|
Parameter Value
|
Name
|
assoc1
|
|
|
|
|
|
Description
|
association 1
|
|
|
|
|
|
Signaling Type
|
M3UA
|
|
|
|
|
|
SGP name
|
sgp1
|
|
|
|
|
|
First local address
|
175.23.211.15
|
|
|
|
|
|
Second local address (optional)
|
n/a
|
|
|
|
|
|
Local SCTP port number (optional)
|
2905
|
|
|
|
|
|
Highest priority destination address
|
117.52.16.20
|
|
|
|
|
|
Lowest priority destination address (optional)
|
|
|
|
|
|
|
Destination SCTP port number (optional)
|
|
|
|
|
|
|
External node name
|
itp1
|
|
|
|
|
|
First IP route name (optional)
|
iproute1
|
|
|
|
|
|
Second IP route name (optional)
|
iproute2
|
|
|
|
|
|
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 address 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 either peer address 1 or 2 before it is declared failed (optional)
|
|
|
|
|
|
|
Table 26 SGP Worksheet Example
Name
|
External Node
|
Description
|
sgp1
|
itp1
|
SGP for itp1
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
Table 27 SS7 Route Worksheet Example
DPC
|
Linkset
|
OPC
|
Priority
|
dpc1
|
lnkset1
|
opc1
|
1
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
Table 28 SS7 Signaling Service Worksheet Example
Name
|
Q.931 Call Model Side
|
MDO File Name
|
DPC
|
Customer Group ID
|
OPC or Route Key ID
|
Description
|
ss7svc1
|
network
|
ansi_ss7
|
dpc1
|
0000
|
m3rtkey1
|
SS7 signaling service 1
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
Table 29 SUA Key Worksheet Example
Name
|
OPC
|
APC
|
Local SSN
|
Routing Context
|
Network Appearance
|
Description
|
suakey1
|
opc1
|
apc1
|
70
|
ISUP
|
7000
|
SUA key 1
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
Table 30 SUA Route Worksheet Example
Name
|
APC
|
External Node
|
OPC
|
Remote SSN
|
Description
|
suarte1
|
apc1
|
itp1
|
opc1
|
100
|
SUA route 1
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
Table 31 SS7 Subsystem Worksheet Example
Parameter
|
Parameter Value
|
Name of APC or TCAP/IP service
|
apc1
|
|
|
Protocol family
|
|
|
|
APC of the mated STP
|
apc2
|
|
|
Priority
|
|
|
|
Local SSN
|
|
|
|
STP/SCP Index
|
|
|
|
Transport protocol
|
SCCP
|
|
|
OPC
|
ROUTING_KEY_ID
|
|
|
Routing Key
|
rtkey1
|
|
|
SUA Key
|
|
|
|
Remote SSN
|
5
|
|
|
For worksheets covering the rest of the provisioning components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:
http://www.cisco.com/en/US/partner/ordering/index.shtml
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 1 800 553-NETS (6387).
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.
Cisco Technical Support Website
The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447
For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:
http://www.cisco.com/go/marketplace/
•The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
http://cisco.com/univercd/cc/td/doc/pcat/
•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:
http://www.ciscopress.com
•Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:
http://www.cisco.com/packet
•iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:
http://www.cisco.com/go/iqmagazine
•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
•World-class networking training is available from Cisco. You can view current offerings at this URL:
http://www.cisco.com/en/US/learning/index.html
Glossary
Table 32 contains definitions of acronyms and technical terms used in this feature module.
Table 32 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
|
Managed Information Base
|
MML
|
Man-Machine Language
|
MTP3
|
Message Transfer Point Level 3
|
NAS
|
Network Access Server
|
NFAS
|
Non-Facility Associated Signaling
|
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
|
Return For Comment—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.
|
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
|
