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, page 2
•
Supported Standards, MIBs, and RFCs, page 4
•
Prerequisites, page 5
•
Upgrading, page 5
•
Provisioning Tasks, page 7
•
Monitoring and Maintaining, page 45
•
Provisioning Examples, page 48
•
Command Reference, page 50
•
Reference Information, page 60
•
Glossary, page 95
•
Obtaining Documentation and Submitting a Service Request, page 97
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Feature Overview
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.
Support for M3UA and SUA with SCTP
2
Feature Overview
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).
Support for M3UA and SUA with SCTP
3
Supported Standards, MIBs, and RFCs
– 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 on page 66. 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.
Support for M3UA and SUA with SCTP
4
Prerequisites
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 on page 7.
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
Step 3
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.
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
Support for M3UA and SUA with SCTP
5
Upgrading
Step 4
Start a provisioning session, as described in the “Starting a Provisioning Session” section on page 12.
Step 5
Add new Cisco ITP external nodes, as described in the “Adding Cisco ITP External Nodes” section on
page 15.
Step 6
Add M3UA and SUA SGPs, as described in the “Adding M3UA and SUA Signaling Gateway Processes”
section on page 20.
Step 7
Add SCTP associations as described in the “Adding SCTP Associations” section on page 22.
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 on page 12.
Step 15
Add M3UA and SUA routing keys, as described in the “Adding M3UA and SUA Routing Keys” section
on page 17.
Step 16
Edit the existing SS7 signaling services to add M3UAKEYs, using the procedure in the “Modifying
M3UA and SUA Routing Keys” section on page 27.
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 on page 19.
Step 18
Save your provisioning changes to the active Cisco MGC only by entering the following MML
command:
mml>prov-cpy
Note
Step 19
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.
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.
Support for M3UA and SUA with SCTP
6
Provisioning Tasks
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, page 7
•
Provisioning Procedures, page 11
•
Troubleshooting Tips, page 40
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
Support for M3UA and SUA with SCTP
7
Provisioning Tasks
•
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.
Support for M3UA and SUA with SCTP
8
Provisioning Tasks
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
Support for M3UA and SUA with SCTP
9
Provisioning Tasks
•
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.
Support for M3UA and SUA with SCTP
10
Provisioning Tasks
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, page 11
•
Adding M3UA and SUA Connections, page 15
•
Modifying M3UA and SUA Components, page 25
•
Deleting M3UA and SUA Components, page 34
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, page 12
•
Saving and Activating your Provisioning Changes, page 12
•
Ending a Provisioning Session Without Activating your Changes, page 13
•
Retrieving Provisioning Data, page 13
For more detailed information about provisioning your Cisco PGW 2200, refer to the Cisco Media
Gateway Controller Software Release 9 Provisioning Guide.
Support for M3UA and SUA with SCTP
11
Provisioning Tasks
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 on page 14.
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 on page 12 or ending
your provisioning session without saving and activating your changes, as described in the “Ending a
Provisioning Session Without Activating your Changes” section on page 13.
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.
Support for M3UA and SUA with SCTP
12
Provisioning Tasks
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 on page 12.
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 on page 12.
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, page 13
•
Retrieving Data for All Components, page 14
•
Retrieving Data for All Components of a Particular Type, page 14
•
Retrieving Data on the Current Provisioning Session, page 14
•
Retrieving Data on Supported Signaling Protocols, page 14
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:
Support for M3UA and SUA with SCTP
13
Provisioning Tasks
•
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
Support for M3UA and SUA with SCTP
14
Provisioning Tasks
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.
Note
•
Adding Cisco ITP External Nodes, page 15
•
Adding Point Codes (OPC, DPC, and APC), page 16
•
Adding M3UA and SUA Routing Keys, page 17
•
Adding SS7 Signaling Services, page 18
•
Adding M3UA and SUA Routes, page 19
•
Adding SS7 Subsystems, page 20
•
Adding M3UA and SUA Signaling Gateway Processes, page 20
•
Adding IP Routes (optional), page 21
•
Adding SCTP Associations, page 22
To begin the provisioning session, perform the steps in the “Starting a Provisioning Session” section on
page 12. 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 on page 12.
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.
Support for M3UA and SUA with SCTP
15
Provisioning Tasks
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.
To support M3UA and SUA interfaces, the value of the type parameter must be set to trueopc.
Note
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.
Support for M3UA and SUA with SCTP
16
Provisioning Tasks
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.
Support for M3UA and SUA with SCTP
17
Provisioning Tasks
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.
Support for M3UA and SUA with SCTP
18
Provisioning Tasks
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
Support for M3UA and SUA with SCTP
19
Provisioning Tasks
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.
Support for M3UA and SUA with SCTP
20
Provisioning Tasks
•
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.
You must define an SGP for each M3UA/SUA path that you provision.
Note
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 on page 12.
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
Support for M3UA and SUA with SCTP
21
Provisioning Tasks
– 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 on page 12.
Otherwise, proceed to the “Adding M3UA and SUA Signaling Gateway Processes” section on page 20.
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
Support for M3UA and SUA with SCTP
22
Provisioning Tasks
– 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.
Support for M3UA and SUA with SCTP
23
Provisioning Tasks
•
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"
Support for M3UA and SUA with SCTP
24
Provisioning Tasks
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.
Note
•
Modifying Cisco ITP External Nodes, page 25
•
Modifying Point Codes (OPC, DPC, and APC), page 26
•
Modifying M3UA and SUA Routing Keys, page 27
•
Modifying M3UA and SUA Routes, page 28
•
Modifying SS7 Signaling Services, page 27
•
Modifying SS7 Subsystems, page 29
•
Modifying M3UA and SUA SGPs, page 29
•
Modifying IP Routes, page 30
•
Modifying SCTP Associations, page 31
To begin the provisioning session, perform the steps in the “Starting a Provisioning Session” section on
page 12. 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 on page 12.
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"
Support for M3UA and SUA with SCTP
25
Provisioning Tasks
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 on page 35.
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.
Support for M3UA and SUA with SCTP
26
Provisioning Tasks
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 on page 36, and then provision new M3UA and SUA routing keys, as described in the “Adding
M3UA and SUA Routing Keys” section on page 17.
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 on page 12.
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 on page 12.
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.
Support for M3UA and SUA with SCTP
27
Provisioning Tasks
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.
Support for M3UA and SUA with SCTP
28
Provisioning Tasks
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.
Support for M3UA and SUA with SCTP
29
Provisioning Tasks
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 on page 44.
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 on page 12.
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:
Support for M3UA and SUA with SCTP
30
Provisioning Tasks
– 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 on page 12.
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 on page 44.
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 on page 44.
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 on page 12.
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:
Support for M3UA and SUA with SCTP
31
Provisioning Tasks
– 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.
Support for M3UA and SUA with SCTP
32
Provisioning Tasks
•
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 on page 12.
Support for M3UA and SUA with SCTP
33
Provisioning Tasks
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 on page 44.
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.
Note
•
Deleting Cisco ITP External Nodes, page 34
•
Deleting Point Codes (OPC, DPC, and APC), page 35
•
Deleting M3UA and SUA Routing Keys, page 36
•
Deleting SS7 Subsystems, page 38
•
Deleting M3UA and SUA Routes, page 38
•
Deleting SS7 Subsystems, page 38
•
Deleting M3UA and SUA SGPs, page 38
•
Deleting IP Routes, page 39
•
Deleting SCTP Associations, page 39
To begin the provisioning session, perform the steps in the “Starting a Provisioning Session” section on
page 12. 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 on page 12.
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 on
page 37.
Step 3
If your system uses IP routes for this external node, delete the IP routes as described in the “Deleting IP
Routes” section on page 39.
Step 4
Delete the SCTP associations for this external node, as described in the “Deleting SCTP Associations”
section on page 39.
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"
Support for M3UA and SUA with SCTP
34
Provisioning Tasks
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 on
page 37.
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 on page 36.
Step 4
Delete the M3UA and SUA routes, as described in the “Deleting M3UA and SUA Routes” section on
page 38.
Step 5
Delete the SS7 subsystems, as described in the “Deleting SS7 Subsystems” section on page 38.
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 on
page 37.
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 on
page 36.
Step 4
Delete the M3UA routes, as described in the “Deleting M3UA and SUA Routes” section on page 38.
Step 5
Enter the following command to delete a DPC:
Support for M3UA and SUA with SCTP
35
Provisioning Tasks
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 on
page 37.
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 on
page 36.
Step 4
Delete the SUA routes, as described in the “Deleting M3UA and SUA Routes” section on page 38.
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 on
page 37.
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"
Support for M3UA and SUA with SCTP
36
Provisioning Tasks
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 on page 38.
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.
Support for M3UA and SUA with SCTP
37
Provisioning Tasks
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 on page 39.
Step 2
Enter the following command to delete a M3UA or SUA signaling gateway process:
mml>prov-dlt:sgp:name="name"
Support for M3UA and SUA with SCTP
38
Provisioning Tasks
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 on page 44.
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 on page 39.
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 on page 44.
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.
Support for M3UA and SUA with SCTP
39
Provisioning Tasks
Troubleshooting Tips
The following sections contain troubleshooting procedures related to provisioning:
•
Alarm Troubleshooting Procedures, page 40
•
Signaling Channel Troubleshooting Procedures, page 43
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 on page 95.
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 on page 95.
Support for M3UA and SUA with SCTP
40
Provisioning Tasks
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 on page 95.
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 on page 95.
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 on page 95.
Support for M3UA and SUA with SCTP
41
Provisioning Tasks
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 on page 95.
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 on page 95.
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 on page 95.
Support for M3UA and SUA with SCTP
42
Provisioning Tasks
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 on page 95.
Signaling Channel Troubleshooting Procedures
The following signaling channel troubleshooting procedures are new for this feature:
•
Resolving an Association Alarm, page 43
•
Setting the Service State of an Association, page 44
•
Setting the Service State of an IP Route, page 44
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.
Support for M3UA and SUA with SCTP
43
Provisioning Tasks
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 on page 95.
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:
Note
•
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.
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 on page 45.
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.
Support for M3UA and SUA with SCTP
44
Monitoring and Maintaining
Note
•
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.
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 on page 47.
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, page 45
•
Retrieving the Service State for IP Routes, page 47
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
Support for M3UA and SUA with SCTP
45
Monitoring and Maintaining
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:
M
Media Gateway Controller 2000-03-26 20:26:18
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:
M
Media Gateway Controller 2000-03-26 19:23:23
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 on page 43.
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.
Support for M3UA and SUA with SCTP
46
Monitoring and Maintaining
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:
M
Media Gateway Controller 2000-03-26 20:26:18
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:
M
Media Gateway Controller 2000-03-26 19:23:23
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 on page 44.
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.
Support for M3UA and SUA with SCTP
47
Provisioning Examples
Table 4
IP Route Secondary Service States (continued)
Link State ID
Link State
Description
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
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Support for M3UA and SUA with SCTP
48
Provisioning Examples
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"
Support for M3UA and SUA with SCTP
49
Command Reference
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:
Output
Description:
•
Assoc_name—MML name of a previously configured SCTP association.
•
All—All associations
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
Support for M3UA and SUA with SCTP
50
Command Reference
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:
Output
Description:
•
Ip_route_name—MML name of a previously configured IP route.
•
All—Retrieves the primary state of all IP routes.
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
Support for M3UA and SUA with SCTP
51
Command Reference
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:
Output
Description:
•
Isgpe_name—MML name of a previously configured SGP.
•
All—Retrieves the primary state of all SGPs.
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
Support for M3UA and SUA with SCTP
52
Command Reference
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>,...
Support for M3UA and SUA with SCTP
53
Command Reference
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.
Support for M3UA and SUA with SCTP
54
Command Reference
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:
Example:
•
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.
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
Syntax:
Only those parameters that need to be modified must be
entered.
prov-ed:<comp>:name=”<MML name>”,<param name>=<param value>,...
prov-add:lnksetprop:name=”<protocol family>”,<param name>=<param
value>,...
Support for M3UA and SUA with SCTP
55
Command Reference
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
Example:
To modify more than one parameter, enter additional param
name=value descriptions on the command line.
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
Support for M3UA and SUA with SCTP
56
Command Reference
Input
Description:
Output
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.
•
<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))
Support for M3UA and SUA with SCTP
57
Command Reference
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:
Example:
•
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
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.
Support for M3UA and SUA with SCTP
58
Command Reference
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
Support for M3UA and SUA with SCTP
59
Reference Information
•
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, page 60
•
Alarms, page 62
•
Logs, page 65
•
Measurements, page 66
•
Components, page 71
•
External Node Types, page 88
•
Properties, page 89
•
Provisioning Worksheets, page 90
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.
Support for M3UA and SUA with SCTP
60
Reference Information
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
*.M3UA.maxOPCs
Do not change this value.
Defines the maximum number of M3UA OPCs.
Value: 64
Note
*.M3UA.maxRoutesPerOpcDpc
Do not change this value.
Defines the maximum number of M3UA routes per
OPC/DPC pair.
Value: 2
Note
*.M3UA.maxSgp
Do not change this value.
Defines the maximum number of M3UA SS7 signaling
gateway processes.
Value: 96
Note
*.SUA.maxSigServices
Do not change this value.
Defines the maximum number of SUA signaling services. It
also defines the maximum number of SUA routing keys.
Value: 256
Note
*.SUA.maxOPCs
Do not change this value.
Defines the maximum number of SUA OPCs.
Value: 64
Note
Do not change this value.
Support for M3UA and SUA with SCTP
61
Reference Information
Configuration Parameter
Definition
*.SUA.maxRoutesPerOpcApcSsn
Defines the maximum number of SUA routes per OPC, APC,
and SSN set.
Value: 2
Note
*.SUA.maxSgp
Do not change this value.
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
Severity
Cause
Type
Action
All acknowledgements for an M3UAKEY associated with this SS7PATH have not been received
Minor
The PGW cannot send or receive traffic for the SS7PATH
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
All M3UA Assoc Fail
Description
Severity
Cause
Type
Action
All M3UA Associations transporting SS7 signaling have failed
Critical
All M3UA Associations transporting SS7 signaling have failed
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
Support for M3UA and SUA with SCTP
62
Reference Information
All SUAKEY Ack Pending
Description
Severity
Cause
Type
Action
All acknowledgements for an SUAKEY associated with this SS7SUBSYS have not been received
Minor
The PGW cannot send or receive traffic for the SS7SUBSYS
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
All SUA Assoc Fail
Description
Severity
Cause
Type
Action
All SUA Associations transporting SS7 signaling have failed
Critical
All SUA Associations transporting SS7 signaling have failed
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
INVALID M3UA RC
Description
Severity
Cause
Type
Action
Indicates there is mismatch between the M3UA routing keys on the PGW and the Signaling Gateway.
Information
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
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
INVALID SUA RC
Description
Severity
Cause
Type
Action
Invalid SUA Routing Context received from the Signaling Gateway
Information
There is a mismatch between SUA routing keys on the PGW and the Signaling Gateway
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
ISUP: T4 Expired
Description
Severity
Cause
The ISUP t4 timer has expired
Information
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.
Support for M3UA and SUA with SCTP
63
Reference Information
Type
Action
0
No action required
M3UAKEY Ack Pending
Description
Severity
Cause
Type
Action
An acknowledgement for an M3UAKEY associated with this SS7PATH or SG has not been received
Minor
The PGW cannot send or receive traffic for the SS7PATH via the SG that has not acknowledged the
M3UAKEY
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 for the procedure for resolving this
alarm.
SUAKEY Ack Pending
Description
Severity
Cause
Type
Action
An acknowledgement for an SUAKEY associated with this SS7SUBSYS or SG has not been received
Minor
The PGW cannot send or receive traffic for the SS7SUBSYS via the SG that has not acknowledged the
SUAKEY
1
Refer to the “Alarm Troubleshooting Procedures” section on page 40 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
Severity
Cause
Type
Action
SS7 signaling service is unavailable
Major
The identified SS7 signaling service is unavailable
1
The recommended action of this alarm is modified to support this feature.
Refer to the “Alarm Troubleshooting Procedures” section on page 40 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
Support for M3UA and SUA with SCTP
64
Reference Information
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
Support for M3UA and SUA with SCTP
65
Reference Information
•
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.
Support for M3UA and SUA with SCTP
66
Reference Information
Table 5
New Operational Measurements
MML Counter Group:Name
Description
Related
Components
M3UA GROUP
M3UA message statistics
Association
Logging
Interval
M3UA: ErrorTx
Number of error messages transmitted.
15, 60, 24
M3UA: ErrorRx
Number of error messages received
15, 60, 24
M3UA: NotifyTx
Number of notify messages transmitted
15, 60, 24
M3UA: NotifyRx
Number of notify messages received
15, 60, 24
M3UA: DunaRx
Number of DUNA messages received
15, 60, 24
M3UA: DavaRx
Number of DAVA messages received
15, 60, 24
M3UA: DaudTx
Number of DAUD messages transmitted
15, 60, 24
M3UA: SconRx
Number of SCON messages received
15, 60, 24
M3UA: DrstRx
Number of DRST messages received
15, 60, 24
M3UA: DupuRx
Number of DUPU messages transmitted
15, 60, 24
M3UA: ASPUpTx
Number of ASP UP messages transmitted
15, 60, 24
M3UA: ASPDnTx
Number of ASP DOWN messages transmitted
15, 60, 24
M3UA: ASPUpAckRx
Number of ASP UP acknowledgements received
15, 60, 24
M3UA: ASPDnAckRx
Number of ASP DOWN acknowledge messages
received
15, 60, 24
M3UA: ASPActTx
Number of ASP ACTIVE messages transmitted
15, 60, 24
M3UA: ASPInactTx
Number of ASP INACTIVE messages
transmitted
15, 60, 24
M3UA: AspActAckRx
Number of ASP ACTIVE ACK messages
received
15, 60, 24
M3UA: AspInactAckRx
Number of ASP INACTIVE ACK messages
received
15, 60, 24
Support for M3UA and SUA with SCTP
67
Reference Information
Table 5
New Operational Measurements (continued)
MML Counter Group:Name
Description
Related
Components
Logging
Interval
M3UA: DataXferTx
Number of DATA transfer messages transmitted
15, 60, 24
M3UA: DataXferRx
Number of DATA transfer messages received
15, 60, 24
M3UA: DataBytesTx
Number of M3UA data bytes transmitted
15, 60, 24
M3UA: DataBytesRx
Number of M3UA data bytes received
15, 60, 24
M3UA: InvSctpSig
Number of invalid SCTP signals received by
M3UA
15, 60, 24
M3UA: AssocFail
Number of SCTP association failures
M3UA: AssocTxFail
Number of transmit SCTP failures
M3UA: RxVersionErr
Number of messages received with an invalid
version
M3UA: RxMsgClassErr
Number of received messages with an
unexpected or unsupported Message Class
M3UA: RxMsgTypeErr
Number of messages received with an
unexpected or unsupported Message Type
M3UA: RxMsgLenErr
Number of messages received with length error
M3UA: RxStrmIdErr
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")
M3UA: RxUnexpMsgErr
Number of unexpected messages received - a
defined and recognized message is received that
is not expected in the current state
M3UA: RxProtErr
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).
15, 60, 24
M3UA: RxParmValErr
Number of messages received with parameter
value errors
15, 60, 24
M3UA: RxParmFieldErr
Number of messages received with a parameter
having a wrong length field
15, 60, 24
M3UA: RxUnexpParmErr
Number of messages received that contain one or
more invalid parameters
15, 60, 24
M3UA: RxNtwkAppErr
Number of messages received with an invalid
(unconfigured) Network Appearance.
15, 60, 24
M3UA: RouteCntxErr
Number of messages received with an invalid
(unconfigured) Routing Context.
15, 60, 24
M3UA: RxNoMemErr
Number of messages that were dumped because
memory ran out (buffer overflow).
15, 60, 24
Support for M3UA and SUA with SCTP
68
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
15, 60, 24
Reference Information
Table 5
New Operational Measurements (continued)
MML Counter Group:Name
Description
Related
Components
SUA GROUP
SUA message statistics
Association
Logging
Interval
SUA: ErrorTx
Number of error messages transmitted
15, 60, 24
SUA: ErrorRx
Number of error messages received
15, 60, 24
SUA: NotifyTx
Number of notify messages transmitted
15, 60, 24
SUA: NotifyRx
Number of notify messages received
15, 60, 24
SUA: DunaRx
Number of DUNA messages received
15, 60, 24
SUA: DavaRx
Number of DAVA messages received
15, 60, 24
SUA: DaudTx
Number of DAUD messages transmitted
15, 60, 24
SUA: SconRx
Number of SCON messages received
15, 60, 24
SUA: DrstRx
Number of DRST messages received
15, 60, 24
SUA: DupuRx
Number of DUPU messages transmitted
15, 60, 24
SUA: ASPUpTx
Number of ASP UP messages transmitted
15, 60, 24
SUA: ASPDnTx
Number of ASP DOWN messages transmitted
15, 60, 24
SUA: ASPUpAckRx
Number of ASP UP acknowledgements received
15, 60, 24
SUA: ASPDnAckRx
Number of ASP DOWN acknowledge messages
received
15, 60, 24
SUA: ASPActTx
Number of ASP ACTIVE messages transmitted
15, 60, 24
SUA: ASPInactTx
Number of ASP INACTIVE messages
transmitted
15, 60, 24
SUA: AspActAckRx
Number of ASP ACTIVE ACK messages
received
15, 60, 24
SUA: AspInactAckRx
Number of ASP INACTIVE ACK messages
received
15, 60, 24
SUA: CldtTx
Number of Connectionless Data Transfers sent
15, 60, 24
SUA: CldrRx
Number of Connectionless Data Responses
received
15, 60, 24
SUA: DataBytesTx
Number of SUA data bytes transmitted
15, 60, 24
SUA: DataBytesRx
Number of SUA data bytes received
15, 60, 24
SUA: InvSctpSig
Number of invalid SCTP signals received by
SUA
15, 60, 24
SUA: AssocFail
Number of SCTP association failures
15, 60, 24
SUA: AssocTxFail
Number of transmit SCTP failures
15, 60, 24
Support for M3UA and SUA with SCTP
69
Reference Information
Table 5
New Operational Measurements (continued)
MML Counter Group:Name
Description
Related
Components
Logging
Interval
SUA: RxVersionErr
Number of messages received with an invalid
version.
15, 60, 24
SUA: RxMsgClassErr
Number of received messages with an
unexpected or unsupported Message Class.
15, 60, 24
SUA: RxMsgTypeErr
Number of messages received with an
unexpected or unsupported Message Type
15, 60, 24
SUA: RxMsgLenErr
Number of messages received with length error
15, 60, 24
SUA: RxStrmIdErr
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
SUA: RxUnexpMsgErr
Number of unexpected messages received, a
defined and recognized message is received that
is not expected in the current state
15, 60, 24
SUA: RxProtErr
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).
15, 60, 24
SUA: RxParmValErr
Number of messages received with parameter
value errors
15, 60, 24
SUA: RxParmFieldErr
Number of messages received with a parameter
having a wrong length field
15, 60, 24
SUA: RxUnexpParmErr
Number of messages received that contain one or
more invalid parameters
15, 60, 24
SUA: RxNtwkAppErr
Number of messages received with an invalid
(unconfigured) Network Appearance.
15, 60, 24
SUA: RouteCntxErr
Number of messages received with an invalid
(unconfigured) Routing Context.
15, 60, 24
SUA: RxNoMemErr
Number of messages that were dumped because
memory ran out (buffer overflow).
15, 60, 24
ISUP message traffic statistics
ISUP-GROUP
MGC NE
ISUP: XMIT UPA TOT
Number of UPA messages sent
15, 60, 24
ISUP: RCV UPA TOT
Number of UPA messages received
15, 60, 24
ISUP: XMIT UPT TOT
Number of UPT messages sent
15, 60, 24
ISUP: RCV UPT TOT
Number of UPT messages received
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.
Support for M3UA and SUA with SCTP
70
Reference Information
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 in decimal dot notation or hostname
IP address
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.
Note
IPADDR
Local IP address
IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.
PRI
Priority
1 through 65535; (1)
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.
Support for M3UA and SUA with SCTP
71
Reference Information
•
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 on page 47 and the “Setting the Service State of an IP Route” section
on page 44, 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.
Support for M3UA and SUA with SCTP
72
Reference Information
Table 7
Note
M3UAKEY Component Structure (continued)
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.)
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
Note
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.
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.
Support for M3UA and SUA with SCTP
73
Reference Information
•
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
The SCTP association component structure is shown in Table 9.
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.
PEERADDR1
The highest priority
destination address
IP address
PEERADDR2
The lowest priority
destination address
(optional)
IP address; (0.0.0.0).
Support for M3UA and SUA with SCTP
74
Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.
Reference Information
Table 9
Association Component Structure (continued)
Parameter MML Name
Parameter Description
Parameter Values (Default)
PEERPORT
Destination SCTP port
number. (optional)
From 1024 through 65535.
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)
Maximum initial timer
retransmission value
(optional)
0, 300 through 3000 (2000)
MAXINITRTO
Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.
0 means use SCTP internal default
0 means use SCTP internal default.
MAXRETRANS
From 1 through 10 (5).
Maximum number of
retransmissions over all
Note
This value is not to exceed
destination address
MAXRETRANSDEST * the number of
before the association is
destinations.
declared failed
(optional)
CUMSACKTO
Maximum time after a From 100 through 500 ms; (300).
datagram is received
before a SCPT SACK is
sent (optional)
BUNDLETO
Maximum time SCTP
will wait for other
outgoing datagrams for
bundling (optional)
MINRTO
Minimum value allowed From 300 through 3000 ms; (300).
for the retransmission
timer (optional)
MAXRTO
Maximum value
allowed for the
retransmission timer
(optional)
From 100 through 600 ms; (100).
From 1000 through 3000 ms; (3000).
Support for M3UA and SUA with SCTP
75
Reference Information
Table 9
Association Component Structure (continued)
Parameter MML Name
Parameter Description
Parameter Values (Default)
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).
Internet Protocol
Precedence. This value
will be place in the IP
PRECEDENCE portion
of the Type Of Service
field for outgoing SCTP
datagrams (optional)
ROUTINE
PRIORITY
IMMEDIATE
FLASH
FLASH-OVERRIDE
CRITICAL
INTERNET
NETWORK; (ROUTINE)
IPPRECEDENCE
Refer to the right
column.
DSCP
Differential Service
Code Point. This value
is place in the DSCP
portion of the Type Of
Service field for
outgoing SCTP
datagrams (optional)
0 means disabled.
EF
AF11
AF12
AF13
AF21
AF22
AF23
AF31
AF32
AF33
AF41
AF42
AF43
101110—Expedited Forwarding
001010—Assured Forwarding
Class 1 Low Drop Precedence
001100—Assured Forwarding
Class 1 Medium Drop Precedence
001110—Assured Forwarding
Class 1 High Drop Precedence
010010—Assured Forwarding
Class 2 Low Drop Precedence
010100—Assured Forwarding 2
Medium Drop Precedence
010110—Assured Forwarding
Class 2 High Drop Precedence
011010—Assured Forwarding
Class 3 Low Drop Precedence
011100—Assured Forwarding
Class 3 Medium Drop Precedence
011110—Assured Forwarding
Class 3 High Drop Precedence
100010—Assured Forwarding
Class 4 Low Drop Precedence
100100—Assured Forwarding
Class 4 Medium Drop Precedence
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)
Support for M3UA and SUA with SCTP
76
000
001
010
011
100
101
110
111
From 1 through 10; (3).
Reference Information
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.
Support for M3UA and SUA with SCTP
77
Reference Information
•
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 on page 45 and the “Setting the Service State of an Association”
section on page 44, 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
Note
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
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.
Support for M3UA and SUA with SCTP
78
Reference Information
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
Note
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.
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
Support for M3UA and SUA with SCTP
79
Reference Information
The SUA route component structure is shown in Table 12.
Table 12
Note
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).
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.
Support for M3UA and SUA with SCTP
80
Reference Information
Table 13
Note
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 on page 88.
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.
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).
Support for M3UA and SUA with SCTP
81
Reference Information
Table 14
Note
IP Link Component Structure (continued)
Parameter MML
Name
Parameter Description
Parameter Values (Default)
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.
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.
Support for M3UA and SUA with SCTP
82
Reference Information
•
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
Note
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.
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
Support for M3UA and SUA with SCTP
83
Reference Information
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.
Note
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.
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.
Support for M3UA and SUA with SCTP
84
Reference Information
•
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
Note
Parameter Description
Parameter Values (Default)
NAME
The name can be as many as 20 alphanumeric
Unique ID of this
component and component characters. No special characters other than “-”
are allowed. The name should begin with a letter.
name used in MML
commands
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.
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).
Support for M3UA and SUA with SCTP
85
Reference Information
•
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.
Support for M3UA and SUA with SCTP
86
Reference Information
Table 19
Note
SS7 Subsystem Component Structure
Parameter MML Name
Parameter Description
Parameter Values (Default)
SVC
MML name of Adjacent MML name of a previously defined adjacent point
point code or TCAP/IP code, or MML name of a previously defined
service
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 Integer greater than 0; (0). Not used when mating
IN triggers
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.
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)
Support for M3UA and SUA with SCTP
87
Reference Information
•
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
Support for M3UA and SUA with SCTP
88
Reference Information
Table 20
External Node Types (continued)
External Node MML Name
Release
Supported Signaling Service Types
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:
Parent Objects and Protocols
Property Name
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.
Support for M3UA and SUA with SCTP
89
Reference Information
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
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
Network
Service Indicator Appearance
Description
m3key1
opc1
dpc1
14
ISUP
M3UA key 1
Support for M3UA and SUA with SCTP
90
25
700
Reference Information
Table 23
Name
M3UA Key Worksheet Example (continued)
OPC
Table 24
DPC
Routing
Context
Network
Service Indicator Appearance
Description
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
Support for M3UA and SUA with SCTP
91
Reference Information
Table 25
SCTP Association Worksheet Example (continued)
Parameter
Parameter Value
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).
Support for M3UA and SUA with SCTP
92
Reference Information
Table 25
SCTP Association Worksheet Example (continued)
Parameter
Parameter Value
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
Support for M3UA and SUA with SCTP
93
Reference Information
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
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
Support for M3UA and SUA with SCTP
94
SS7 signaling
service 1
Glossary
Table 30
Name
SUA Route Worksheet Example (continued)
APC
Table 31
External Node
OPC
Remote SSN
Description
SS7 Subsystem Worksheet Example
Parameter
Parameter Value
Name of APC or apc1
TCAP/IP
service
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.
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.
Support for M3UA and SUA with SCTP
95
Glossary
Table 32
Glossary (continued)
Term
Definition
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
Support for M3UA and SUA with SCTP
96
Obtaining Documentation and Submitting a Service Request
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional
information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and
revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed
and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free
service and Cisco currently supports RSS version 2.0.
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence,
Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are
service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP,
CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo,
Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive,
HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace,
MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare,
SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo
are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0812R)
Support for M3UA and SUA with SCTP
97
Obtaining Documentation and Submitting a Service Request
Support for M3UA and SUA with SCTP
98