Guest

Cisco PGW 2200 Softswitch

Support for M3UA and SUA with SCTP

  • Viewing Options

  • PDF (1.2 MB)
  • Feedback
Support for M3UA and SUA with SCTP

Table Of Contents

Support for M3UA and SUA with SCTP

Feature Overview

Benefits

Restrictions

Related Features and Technologies

Changes to Cisco MGC Software Architecture

Input/Output Subsystem

Related Documentation

Supported Standards, MIBs, and RFCs

Prerequisites

Upgrading

Provisioning Tasks

Planning for Provisioning

Collecting External Node Data

Collecting IP Route Data

Collecting M3UA Key Data

Collecting M3UA Route Data

Collecting SCTP Association Data

Collecting SS7 Signaling Gateway Process Data

Collecting SS7 Signaling Service Data

Collecting SUA Key Data

Collecting SUA Route Data

Collecting SS7 Subsystem Data

Provisioning Procedures

Provisioning Basics

Adding M3UA and SUA Connections

Modifying M3UA and SUA Components

Deleting M3UA and SUA Components

Troubleshooting Tips

Alarm Troubleshooting Procedures

All M3UAKEY Ack Pending

All M3UA Assoc Fail

All SUAKEY Ack Pending

All SUA Assoc Fail

INVALID M3UA RC

INVALID SUA RC

M3UAKEY Ack Pending

SUAKEY Ack Pending

SS7 SIG SRVC UNAVAIL

Signaling Channel Troubleshooting Procedures

Resolving an Association Alarm

Setting the Service State of an Association

Setting the Service State of an IP Route

Monitoring and Maintaining

Regular Operations

Managing Signaling Channels

Provisioning Examples

Command Reference

New MML Commands

RTRV-ASSOCIATION—Display State of SCTP Association

RTRV-IPROUTE—Display Primary and Secondary States of an IP Route

RTRV-SGP—Display the Primary and Secondary States of an SGP

SET-ASSOCIATION—Changing Association Primary State

SET-IPROUTE—Changing IP Route Primary State

Modified MML Commands

PROV-ADD—Add Provisioning Component

PROV-DLT—Delete Components or Parameters

PROV-ED—Modify Provisioned Component

RTRV-DEST—Retrieve Destination

SET-IPLNK—Changing IP Link Primary State

VLD-CIC—Validate a Circuit

Reference Information

XECfgParm.dat Parameters

Alarms

New Alarms

Modified Alarms

Deleted Alarms

Logs

Measurements

Components

New Components

Modified Components

Deleted Components

External Node Types

Properties

Provisioning Worksheets

Glossary

Obtaining Documentation and Submitting a Service Request


Support for M3UA and SUA with SCTP


Document Release History

Publication Date
Comments

September 16, 2003

Initial version of the document.

June 3, 2005

Modified the information concerning the network appearance parameter for the SUAKEY component.

July 11, 2006

Updated the upgrade procedure for the ability to support a single originating point code for a Cisco MGC and Cisco ITP group.


Feature History

Release
Modification

9.4(1)

This feature was introduced on the Cisco MGC software.


This document describes the Support for M3UA and SUA with SCTP Feature. This feature is described in the following sections:

Feature Overview

Supported Standards, MIBs, and RFCs

Prerequisites

Upgrading

Provisioning Tasks

Monitoring and Maintaining

Provisioning Examples

Command Reference

Reference Information

Glossary

Obtaining Documentation and Submitting a Service Request

Feature Overview

This feature enables support on the Cisco MGC of the M3UA and SUA protocols using SCTP. The Cisco MGC can now use M3UA and SUA to communicate with Cisco IP Transfer Points (ITPs). The Cisco ITP is a signaling gateway. In prior releases of the Cisco MGC software, processing of Message Transfer Part (MTP) data was done in two parts: the Cisco Signaling Link Controller (SLT) processed MTP levels 1 and 2. MTP Level 3 (along with the upper layers of SS7) data was passed on to the Cisco MGC for processing. This feature enables you to also use the Cisco ITP to process MTP and SCCP data. The Cisco ITP processes all levels of the MTP and SCCP data, and then passes the upper layers of SS7 data to the Cisco MGC.


Note This version of the Cisco MGC software still supports the use of Cisco SLTs. However, the M3UA and SUA with SCTP feature cannot be used to communicate with Cisco SLTs.


This feature provides the following:

Use of the SIGTRAN standards M3UA and SUA with SCTP to communicate with Cisco ITP signaling gateways

Transport of SCCP, ISUP, BTNUP and TUP messages for the ANSI and ITU protocol families.

Processing of incoming User Part Unavailable (UPU) messages.

The ITU ISUP protocol family supports the ISUP User Part Test (UPT) and User Part Available (UPA) messages. The UPT is sent periodically when an UPU message is received indicating the remote user is inaccessible. The UPA is sent in response to a UPT.

The ANSI ISUP protocol family supports the Circuit Verification Test (CVT) and Circuit Verification Response (CVR) messages. The CVT is sent periodically when an UPU message is received indicating the remote user is inaccessible. The CVR is sent in response to a CVT.

Support upgrading from Cisco SLT-based SS7 signaling to Cisco ITP-based SS7 signaling without losing stable active calls.

Increase the number of measurement counters supported on the Cisco PGW 2200 to allow for the total number of measurements needed for the largest possible configuration to be created.

Benefits

This feature provides the following benefits:

Use of standard protocols

By adding support for the SIGTRAN protocols M3UA, SUA and SCTP, the Cisco MGC can now use standard protocols for communication with the device used to process the Message Transfer Part (MTP) data.

Ability to increase call processing speed

By combining multiple Cisco MGC pairs behind a set of Cisco ITPs with several unique point codes, the number of calls per second is much higher than can be achieved with a single pair of Cisco MGC hosts equipped with Cisco SLTs. This type of Cisco MGC and Cisco ITP configuration is referred to as a Cisco PGW Farm.

Restrictions

This feature can only be used for communication between Cisco MGCs and Cisco ITPs. For information on the restrictions on the Cisco ITPs, refer to the Support for M3UA and SUA with SCTP on Cisco ITPs feature module.

Related Features and Technologies

The following features and technologies are related to this feature:

Support for DPNSS Signaling Backhaul Feature (for the Cisco PGW 2200 and Cisco media gateways)

Support for the IUA with SCTP Feature (for the Cisco MGC and Cisco access servers)

Changes to Cisco MGC Software Architecture

This section describes the changes to Cisco MGC software architecture for this feature.

Input/Output Subsystem

The Input/Output (I/O) subsystem consists of the I/O channel controllers (IOCC) and the I/O channel manager (IOCM), which manages them.

The IOCM manages all IOCCs.

The IOCCs provide

A protocol-specific, message-based interface that allows nodes and platforms external to the Cisco MGC to communicate with the Cisco MGC.

An interface that allows buffering of messages to the call engine's event dispatcher queue.

The Cisco MGC I/O subsystem includes the following IOCCs:

Signaling System 7 (SS7)—Contains MTP3 used for backhauling SS7 signaling to the Cisco MGC from a Cisco SLT.

ISDN Level 3—Provides backhauling of ISDN (standard variants) to the Cisco MGC from a media gateway.

Q.931+—A stateless IOCC, for a Cisco-proprietary protocol (RLM), which a special version of ISDN that enables forwardhauling of Q931+ signaling to a media gateway used in Cisco PGW 2200 configured for signaling environments.

Media Gateway Control Protocol (MGCP)—Enables communication to media gateways and trunking gateways for setting up bearer channel connections used in Cisco PGW 2200 configured for call control environments.

Extended ISDN User Part (E-ISUP)—Cisco-proprietary internal interface that enables the transport of endpoint and media gateway specific information between two (or more) Cisco MGCs. This protocol uses an enhanced ISUP base to support all ANSI and ITU ISUP messaging and elements, as well as additional fields to support transport of service information (such as local number portability (LNP), 800 numbers, and so on).

Session Initiation Protocol (SIP)—Enables the Cisco MGC to receive and send SIP messages using the User Datagram Protocol (UDP).

ISDN Q.921 User Adaptation (IUA)—Added in Release 9.4, this IOCC enables backhauling of ISDN Q.921 User messages over IP using Stream Controlled Transmission Protocol (SCTP). This IOCC is used between the Cisco MGC and media gateways.

Message Transfer Part Level 3 (MTP3) User Adaptation (M3UA)—Added in Release 9.4, this IOCC enables the transport of any SS7 MTP Level 3 User signaling (for example, ISUP and TUP messages) over IP using SCTP. This IOCC is used between the Cisco MGC and Cisco ITP.

Signaling Control Connection Part (SCCP) User Adaptation (SUA)—Added in Release 9.4, this IOCC enables the transport of any SCCP user signaling (for example, TCAP messages) over IP using SCTP. This IOCC is used between the Cisco MGC and Cisco ITP.

Related Documentation

This document contains information that is related strictly to this feature. The documents that contain additional information related to the Cisco Media Gateway Controller (MGC) software are listed below:

Cisco Media Gateway Controller Hardware Installation Guide

Regulatory Compliance and Safety Information for the Cisco Media Gateway Controller

Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide

Release notes for Cisco Media Gateway Controller software Release 9.4(1)

Cisco Media Gateway Controller Software Release 9 Provisioning Guide

Cisco Media Gateway Controller Software Release 9 Dial Plan Guide

Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide

Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide

Cisco Media Gateway Controller Software Release 9 Messages Reference Guide

Cisco Media Gateway Controller Software Release 9 Billing Interface Guide

Cisco Media Gateway Controller Software Release 9 Management Information Base Guide

Supported Standards, MIBs, and RFCs

This section identifies the new or modified standards, MIBs, or RFCs that are supported by this feature.

Standards

M3UA

SUA

SCTP

MIBs

There are MIBs added for each new measurement. The new measurements can be found in the "Measurements" section. For more information on the MIBs used in the Cisco MGC software, refer to the Cisco Media Gateway Controller Release 9 Management Information Base Guide.

RFCs

The following RFCs are supported by this feature:

RFC-3332 (M3UA)

RFC-3057 (SCTP)

Prerequisites

You must have Cisco Media Gateway Controller (MGC) software Release 9.4(1). Prerequisites for this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).

Information on the prerequisites for the implementation of this feature in Cisco IOS software for the Cisco ITPs can be found in the Support for M3UA and SUA with SCTP for Cisco ITPs feature module.

Upgrading

This sections contains the steps necessary for upgrading of the Cisco MGC software to support this feature. If you are installing and configuring the Cisco MGC software on your system for the first time, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide for the required procedures.

Before beginning the upgrade procedure, prepare the information you'll need by following the instructions in the "Planning for Provisioning" section.


Step 1 Upgrade both Cisco MGC hosts to the new software release using the upgrade procedures defined in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.

Step 2 Verify that the existing Cisco SLT configuration is functioning normally by retrieving the alarms on both Cisco MGC hosts. To do this, enter the following MML command:

mml>rtrv-alms

The system returns a list of the active alarms. If there are any alarms associated with the provisioning components that are part of the affected SS7 path, resolve those alarms before continuing with this procedure.


Note More information on alarms can be found in the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide. Procedures for alarms that require corrective action can be found in the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance and Troubleshooting Guide.


Step 3 Configure the Cisco ITP(s) to match the current Cisco MGC provisioning for the following items:

OPC

Number of links

Signaling link code (SLC) values

SS7 routes

Routing keys

Step 4 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 5 Add new Cisco ITP external nodes, as described in the "Adding Cisco ITP External Nodes" section.

Step 6 Add M3UA and SUA SGPs, as described in the "Adding M3UA and SUA Signaling Gateway Processes" section.

Step 7 Add SCTP associations as described in the "Adding SCTP Associations" section.

Step 8 Save your provisioning changes to the active Cisco MGC only by entering the following MML command:

mml>prov-cpy

Step 9 Verify the IP connectivity between the active Cisco MCC and the Cisco ITP(s).

Step 10 Contact the appropriate party to inhibit half of the SS7 links in the linkset at the associated far-end destinations (for example, a signaling transfer point (STP) or remote PSTN switch).

Step 11 Move the cabling for the inhibited SS7 links from the Cisco SLTs to the Cisco ITP(s).

Step 12 Verify on the Cisco ITP(s) that the inhibited links come in service in the inhibited state.

Step 13 Disable any new calls on the Cisco MGC for all of your SS7 destinations using the following MML command:

mml>set-admin-state:dest:lock

Where dest is the MML name of the affected SS7 destination.

Step 14 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 15 Add M3UA and SUA routing keys, as described in the "Adding M3UA and SUA Routing Keys" section.

Step 16 Edit the existing SS7 signaling services to add M3UAKEYs, using the procedure in the "Modifying M3UA and SUA Routing Keys" section.

Step 17 If the Cisco MGC and the Cisco ITP are not on the same subnet, you will need to add an IP route, as described in the "Adding M3UA and SUA Routes" section.

Step 18 Save your provisioning changes to the active Cisco MGC only by entering the following MML command:

mml>prov-cpy


Note If any abnormalities occur in steps 14-18, you can perform a manual switchover using the sw-ovr::confirm MML command to change the active Cisco MGC host and then enable the SS7 destinations using the set-admin-state MML command on the newly active Cisco MGC.


Step 19 Set all of the SS7 links out-of-service using the MML command listed below. This should cause the far-end devices to uninhibit the SS7 links already associated with the Cisco ITP(s).

mml>set-c7lnk:c7link_name:OOS

Where c7link_name is the MML name of the SS7 link you want to set out-of-service.

Step 20 Enable new calls on the Cisco MGC for all of your SS7 destinations using the following MML command:

mml>set-admin-state:dest:unlock

Where dest is the MML name of the affected SS7 destination.

Step 21 Verify that the SS7 connectivity of all the destinations is restored by entering the following MML command:

mml>rtrv-dest:all

Step 22 Propagate your provisioning changes to the standby Cisco MGC by entering the following MML command:

mml>prov-sync

Step 23 Configure any additional links on the Cisco ITP(s), if necessary.

Step 24 Make additional provisioning changes for any additional links on the Cisco MGC. To do this, repeat steps 4 through 17.

Step 25 Delete the IP links associated with the old Cisco SLT external node using the following MML command:

prov-dlt:iplnk:name="link"

Where link is the MML name of the IP link associated with the affected destination.

Step 26 Delete the old Cisco SLT external node using the following MML command:

mml>prov-dlt:extnode:name="slt"

Where slt is the MML name of the Cisco SLT associated with the affected destination.

Step 27 Save your provisioning changes and enable the new links. To do this, repeat steps 19 through 22.


Provisioning Tasks

The following sections describe the provisioning tasks related to this feature:

Planning for Provisioning

Provisioning Procedures

Troubleshooting Tips

Planning for Provisioning

This section lists the data that you must gather to successfully provision this feature. For more information on planning the provisioning for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Collecting External Node Data

The external node component type represents another node with which the Cisco MGC communicates. You must be ready to enter the following data:

MML name

Component description

The type of the external node

ISDN Signaling Type

M3UA/SUA Group Number

The parameters for EXTNODE are defined in Table 21.

Collecting IP Route Data

The IP route represents a static IP route. You must be ready to enter the following data:

IP route name

Component description

Destination hostname or IP address

Subnet mask of Destination (optional)

Next hop router IP address

Local IP address

Priority

The IP route component information can be listed in Table 22.

Collecting M3UA Key Data

This component represents an M3UA routing key. You must be ready to enter the following data:

M3UA key name

Component description

Associated OPC

Associated DPC (optional)

Routing context value

Service indicator

Network appearance (optional)

The M3UA key component information can be listed in Table 23.

Collecting M3UA Route Data

This component represents an M3UA route. You must be ready to enter the following data:

M3UA route name

Component description

Associated DPC

Associated external node

Associated OPC

The M3UA route component information can be listed in Table 24.

Collecting SCTP Association Data

The SCTP association represents the connection between the Cisco MGC and media gateways (IUA) and signaling gateways (M3UA/SUA). The Cisco ITP is a signaling gateway. You must be ready to enter the following data:

MML Name of the SCTP association

Description of this component

Signaling Type

MML name of SGP (required only form M3UA/SUA associations)

First local address

Second local address (optional)

Local SCTP port number (optional)

The highest priority destination address

The lowest priority destination address (optional)

Destination SCTP port number. (optional)

MML Name of first IPROUTE (optional)

MML Name of second IPROUTE (optional)

Number of bytes to advertise for the local receive window. (optional)

Maximum number of times to retransmit SCTP INIT message (optional)

Maximum initial timer retransmission value (optional)

Maximum number of retransmissions over all destination address before the association is declared failed (optional)

Maximum time after a datagram is received before a SCPT SACK is sent (optional)

Maximum time SCTP waits for other outgoing datagrams for bundling (optional)

Minimum value allowed for the retransmission timer (optional)

Maximum value allowed for the retransmission timer (optional)

Time between heartbeats. The heartbeat is this value plus the current retransmission timeout value (optional).

Internet Protocol Precedence. This value is placed in the IP PRECEDENCE portion of the Type Of Service field for outgoing SCTP datagrams (optional)

Differential Service Code Point. This value is placed in the DSCP portion of the Type Of Service field for outgoing SCTP datagrams (optional)

Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before it is declared failed (optional)

The SCTP association component structure is shown in Table 25.

Collecting SS7 Signaling Gateway Process Data

This component represents a SS7 signaling gateway process (SGP). You must be ready to enter the following data:

MML name of SGP

M3UA route name

Component description

External node that is running the SS7 signaling gateway process

The SS7 signaling gateway process component structure is shown in Table 26.

Collecting SS7 Signaling Service Data

This component represents an SS7 signaling service or signaling path to a particular SS7 switch (destination). You must be ready to enter the following data:

Unique ID of this component and component name used in MML commands

Component description

MDO file name

Destination point code MML name

Customer group ID

M3UA Routing key ID MML name

The SS7 signaling service component structure is shown in Table 28.

Collecting SUA Key Data

This component represents a SUA Routing key. You must be ready to enter the following data:

SUA key name

Component description

Associated OPC

Associated APC (optional)

Associated local SSN

Routing context value

Network appearance (optional)

The SUA key component structure is shown in Table 29.

Collecting SUA Route Data

This component represents a SUA route. You must be ready to enter the following data:

SUA route name

Component description

Associated APC

Associated external node

Associated OPC

Associated remote SSN

The SUA route component structure is shown in Table 30.

Collecting SS7 Subsystem Data

The SS7 subsystem component type represents an SS7 subsystem. You must be ready to enter the following data:

MML name of SS7 subsystem

Component description

MML name of Adjacent point code or TCAP/IP service

Protocol family

Adjacent point code of the mated STP

Priority

Local subsystem number

STP/SCP index used for IN triggers

Transport protocol (must be SUA for this feature)

MML name of an SUA key (optional)

Remote subsystem number

The SS7 subsystem component structure is shown in Table 31.

Provisioning Procedures

Provision the transport path between the M3UA and SUA IOCCs of the Cisco PGW 2200 and the external Cisco ITP nodes. Communication between the Cisco PGW 2200 and the Cisco ITPs is provisioned to provide a reliable communication path between the two platforms.

Provisioning procedures can be found in the following sections:

Provisioning Basics

Adding M3UA and SUA Connections

Modifying M3UA and SUA Components

Deleting M3UA and SUA Components

Provisioning Basics

The procedures in this section describe how to start a provisioning session and how to save and activate the changes you have made.

Starting a Provisioning Session

Saving and Activating your Provisioning Changes

Ending a Provisioning Session Without Activating your Changes

Retrieving Provisioning Data

For more detailed information about provisioning your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Starting a Provisioning Session

You may need to start a provisioning session as part of your system operations. To do this, log into the active Cisco MGC, start an MML session, and enter the following command:

prov-sta::srcver="curr_ver",dstver="mod_ver"

Where:

curr_ver—The name of the current configuration version. In place of the name of the current configuration version, you can also enter:

new—A new default session configuration; no existing source configuration is available.

active—Selects the active configuration as the source for configuration changes.


Note If you do not know the name of your current configuration session, you can use the procedure in the "Retrieving Data on the Current Provisioning Session" section.


mod_ver—A new configuration version name that contains your provisioning changes.

For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:

mml>prov-sta::srcver="ver1",dstver="ver2"

Once a provisioning session is underway, you may use the prov-add, prov-ed, or prov-dlt MML commands to add, modify, and delete components on your system. This document describes how to add, modify, and delete M3UA and SUA components. For more information on provisioning other components on your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

There are two ways to close your provisioning session: saving and activating your provisioning changes, as described in the "Saving and Activating your Provisioning Changes" section or ending your provisioning session without saving and activating your changes, as described in the "Ending a Provisioning Session Without Activating your Changes" section.

Saving and Activating your Provisioning Changes

When you have completed making provisioning changes in your session, you must enter a command to save and activate your changes. There are two different provisioning MML commands that do this: prov-cpy and prov-dply.


Caution Using the prov-cpy and prov-dply MML commands can severely impact your system's call processing performance, depending on the extent of your provisioning changes. We recommend that these commands be issued during a maintenance window when traffic is minimal.

The prov-cpy MML command is used to save and activate your changes on the active Cisco MGC. This command is typically used to save and activate changes on a Cisco MGC in a simplex configuration. However, you can use the prov-cpy MML command on Cisco MGCs in high-availability or continuous-service configurations, to save and activate your changes on the active Cisco MGC. If you choose to do this, you should enter the prov-sync MML command immediately afterwards, to have your changes saved and activated on the standby Cisco MGC.


Note When you enter the prov-cpy command, your provisioning session is also automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session as described in the "Starting a Provisioning Session" section.



Caution Using the prov-sync MML command can severely impact your system's call processing performance. We recommend that this command be issued during a maintenance window when traffic is minimal.


Note When the prov-sync MML command is used to synchronize the provisioning settings on the standby MGC host with current settings on the active MGC host, the system does not indicate when the synchronization process has failed.


The prov-dply MML command is used to save and activate your changes on the active and standby
Cisco MGCs. This command is typically used to save and activate changes on Cisco MGCs in high-availability or continuous-service configurations. This command should not be used on a Cisco MGC in a simplex configuration.


Note When you enter the prov-dply command, your provisioning session is also automatically ended, unless an error occurs during execution. If you want to make additional provisioning changes, you must start a new provisioning session as described in the "Starting a Provisioning Session" section.


Ending a Provisioning Session Without Activating your Changes

You may find that you want to end a provisioning session without saving and activating the changes you have entered during your session. If this is the case, you can enter the prov-stp MML command. This command ends your current provisioning session and your changes are not entered.

Retrieving Provisioning Data

You can use the prov-rtrv MML command to retrieve information about your current provisioning settings. The ways in which you can use this command to retrieve provisioning data are described in the following sections:

Retrieving Data for an Individual Component

Retrieving Data for All Components

Retrieving Data for All Components of a Particular Type

Retrieving Data on the Current Provisioning Session

Retrieving Data on Supported Signaling Protocols

Retrieving Data for an Individual Component

You can retrieve provisioning data on any individual component on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>prov-rtrv:component:name=MML_name

Where:

component—The MML component type associated with the desired component. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

MML_name—The MML name for the desired component. You can determine the MML names for the various components using the prov-rtrv:all MML command.

For example, to view the provisioning data for a M3UA signaling service called m3ua1, you would enter the following command:

mml>prov-rtrv:ss7path:name="m3ua1"

Retrieving Data for All Components

You can retrieve data on all of the components provisioned on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>prov-rtrv:all

Retrieving Data for All Components of a Particular Type

You can retrieve provisioning data on all components of a particular type on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>prov-rtrv:component:"all"

Where: component is the MML component type associated with the desired component group. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

For example, to view the provisioning data for all SS7 signaling services, you would enter the following command:

mml>prov-rtrv:ss7path:"all"

Retrieving Data on the Current Provisioning Session

You can retrieve provisioning data on the current provisioning session. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>prov-rtrv:session

The system returns a response similar to the following:

MGC-02 - Media Gateway Controller 2003-01-13 13:39:19
M  RTRV
   "session=jtest:session"
   /*
Session ID = mml1
SRCVER = active
DSTVER = jtest
   */

Retrieving Data on Supported Signaling Protocols

You can retrieve protocol data for the current provisioning session. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>prov-rtrv:variants

Adding M3UA and SUA Connections

This section contains the procedures that you must perform to add M3UA and SUA connections to your Cisco PGW 2200 provisioning data. When provisioning the components that enable the Cisco PGW 2200 to support M3UA and SUA, perform the procedures in the following order.

Adding Cisco ITP External Nodes

Adding Point Codes (OPC, DPC, and APC)

Adding M3UA and SUA Routing Keys

Adding SS7 Signaling Services

Adding M3UA and SUA Routes

Adding SS7 Subsystems

Adding M3UA and SUA Signaling Gateway Processes

Adding IP Routes (optional)

Adding SCTP Associations


Note To begin the provisioning session, perform the steps in the "Starting a Provisioning Session" section. Once you have finished provisioning the M3UA and SUA data, save and activate your provisioning data by performing the steps in the "Saving and Activating your Provisioning Changes" section.


Adding Cisco ITP External Nodes

To add Cisco ITP external nodes, perform the following steps:


Step 1 Enter the following command to add a Cisco ITP external node:

mml>prov-add:extnode:name="name", desc="description", type="itp", group=num

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

num—The M3UA/SUA group number. The valid values are 1 through 100.

For example, to add an Cisco ITP external node named itp1, you would enter the following command:

mml>prov-add:extnode:name="itp1", desc="2651 ITP", type="itp", group=1

Step 2 Repeat Step 1 for each Cisco ITP external node you want to add to your provisioning data.


Adding Point Codes (OPC, DPC, and APC)

To add originating point codes (OPCs), perform the following steps:


Step 1 Enter the following command to add an OPC:

mml>prov-add:opc:name="name", desc="description", netaddr="addr", netind=num, 
type="trueopc"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

addr—The network address in dot notation.

num—The network indicator number. The default value is 0.


Note To support M3UA and SUA interfaces, the value of the type parameter must be set to trueopc.


For example, to add an OPC named opc1, you would enter the following command:

mml>prov-add:opc:name="opc1", desc="Originating PC 1", 
netaddr="2.1.4",netind=2,type="trueopc"

Step 2 Repeat Step 1 for each OPC you want to add to your provisioning data.


To add destination point codes (DPCs), perform the following steps:


Step 1 Enter the following command to add a DPC:

mml>prov-add:dpc:name="name", desc="description", netaddr="addr", netind=num

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

addr—The network address in dot notation.

num—The network indicator number. The default value is 0.

For example, to add an DPC named dpc1, you would enter the following command:

mml>prov-add:DPC:NAME="dpc1",DESC="DPC1",NETADDR="1.1.5",NETIND=2

Step 2 Repeat Step 1 for each DPC you want to add to your provisioning data.


To add adjacent point codes (APCs), perform the following steps:


Step 1 Enter the following command to add an APC:

mml>prov-add:apc:name="name", desc="description", netaddr="addr", netind=num

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

addr—The network address in dot notation.

num—The network indicator number. The default value is 0.

For example, to add an APC named apc1, you would enter the following command:

mml>prov-add:apc:NAME="apc1",DESC="apc1",NETADDR="1.2.4",NETIND=2

Step 2 Repeat Step 1 for each APC you want to add to your provisioning data.


Adding M3UA and SUA Routing Keys

To add M3UA routing keys, perform the following steps:


Step 1 Enter the following command to add an M3UA routing key:

mml>prov-add:m3uakey:name="name", desc="description", opc="opc", [dpc="dpc",] 
routingcontext=rc, [si="serv", networkappearance=na]

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

opc—MML name of a previously assigned OPC. The selected OPC must have a type of trueopc.

dpc—MML name of a previously assigned DPC. This parameter is optional.

rc—Routing context value. To use the routing context, its value must be set to any integer other than 0 (0 indicates that there is no routing context). The routing context value for each M3UA key you create must be unique.

serv—Service indicator value. This parameter is optional. The valid values are ISUP, TUP, and N/A. The default value is N/A.

na—Network appearance value. This parameter is optional. The valid values are integers from 1 through 32767. A value of 0 indicates an invalid network appearance.

For example, to add a M3UA key named m3uakey1, you would enter the following command:

mml>prov-add:M3UAKEY:NAME="m3uakey1",OPC="opc1",DPC="dpc1",si="ISUP", ROUTINGCONTEXT=10

Step 2 Repeat Step 1 for each M3UA key you want to add to your provisioning data.


To add SUA routing keys, perform the following steps:


Step 1 Enter the following command to add an SUA routing key:

mml>prov-add:suakey:name="name", desc="description", opc="opc", [apc="apc", localssn=ssn,] 
routingcontext=rc, networkappearance=na

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

opc—MML name of a previously assigned OPC. The selected OPC must have a type of trueopc.

apc—MML name of a previously assigned APC. This parameter is optional.

ssn—Local SS7 subsystem number value. This parameter is optional. The valid values are integers between 2 and 254.

rc—Routing context value. To use the routing context, its value must be set to any integer other than 0 (0 indicates that there is no routing context). The routing context value for each M3UA key you create must be unique.

na—Network appearance value. The valid values are integers from 1 through 32767. This value must match the network appearance value set in your Cisco ITP.

For example, to add a SUA key named suakey1, you would enter the following command:

mml>prov-add:SUAKEY:NAME="suakey1",OPC="opc1",APC="apc1",localssn=200, ROUTINGCONTEXT=20, 
networkappearance=10

Step 2 Repeat Step 1 for each SUA key you want to add to your provisioning data.


Adding SS7 Signaling Services

To add SS7 signaling services, perform the following steps:


Step 1 Enter the following command to add an SS7 signaling service:

mml>prov-add:ss7path:name="name", desc="description", mdo="protFile", dpc="dpc", 
custgrpid="num", m3uakey="rtkey"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

protFile—MDO file name for the supported SS7 protocol. A list of file names for SS7 protocols supported in this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).

dpc—MML name of a previously provisioned DPC. There can only be one SS7 signaling service per DPC/M3UA pair.

num—Customer group ID number. The valid value is a four-digit number. The default value is 0000.

rtkey—MML name of a previously provisioned M3UA key.

For example, to add an SS7 signaling service named ss7svc1, you would enter the following command:

mml>prov-add:SS7PATH:NAME="ss7svc1", DESC="OPC1 to INET DPC1", M3UAKEY="m3uakey1", 
DPC="dpc1", MDO="Q761_BASE"

Step 2 Repeat Step 1 for each SS7 signaling service you want to add to your provisioning data.


Adding M3UA and SUA Routes

To add M3UA routes, perform the following steps:


Step 1 Enter the following command to add an M3UA route:

mml>prov-add:m3uaroute:name="name", desc="description", dpc="dpc", extnode="itp", 
opc="opc"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

dpc—MML name of a previously provisioned DPC.

itp—MML name of a previously provisioned Cisco ITP external node.

opc—MML name of a previously provisioned OPC.

For example, to add an M3UA route named m3uarte1, you would enter the following command:

mml>prov-add:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Rte 1",OPC="opc1",DPC="dpc1", 
EXTNODE="itp1"

Step 2 Repeat Step 1 for each M3UA route you want to add to your provisioning data.


To add SUA routes, perform the following steps:


Step 1 Enter the following command to add an SUA route:

mml>prov-add:suaroute:name="name", desc="description", apc="apc", extnode="itp", 
opc="opc", remotessn=num

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

apc—MML name of a previously provisioned APC.

itp—MML name of a previously provisioned Cisco ITP external node.

opc—MML name of a previously provisioned OPC.

num—SS7 subsystem number of the destination. The valid values are 2 through 254.

For example, to add an SUA route named suarte1, you would enter the following command:

mml>prov-add:SUAROUTE:NAME="suarte1", DESC="SUA Rte 1", APC="apc1", OPC="opc1", 
EXTNODE="itp1", remotessn=40

Step 2 Repeat Step 1 for each SUA route you want to add to your provisioning data.


Adding SS7 Subsystems

To add SS7 subsystems, perform the following steps:


Step 1 Enter the following command to add an SS7 subsystem:

mml>prov-add:ss7subsys:name="name", desc="description", suakey="key", svc="serv", 
proto="protFam", transproto="protType", remotessn=remssn, localssn=locssn, 
stpscpind="index"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

key—MML name of a previously defined SUA key.

serv—MML name of a previously defined APC.

protFam—MML name of the associated SS7 protocol family. Valid values are:

SS7-ANSI

SS7-ITU

protType—MML name of the transport protocol. Valid values are SCCP and SUA. The default value is SCCP.

remssn—SS7 subsystem number of the destination. This number has to match the SSN value defined in the SUAROUTE.

locssn—Local SS7 subsystem number value. The valid values are integers between 2 and 254. This parameter cannot be used if an M3UA key is provisioned.

stpscpind—STP/SCP index used for Intelligent Network triggers.

For example, to add an SS7 subsystem named prepaid, you would enter the following command:

mml>prov-add:SS7SUBSYS:NAME="prepaid",DESC="prepaid rte-ssn 48",SUAKEY="suakey1", 
SVC="scp", PROTO="SS7-ITU",TRANSPROTO="SUA", stpscpind=2, remotessn=48

Step 2 Repeat Step 1 for each SS7 subsystem you want to add to your provisioning data.


Adding M3UA and SUA Signaling Gateway Processes

To add M3UA and SUA signaling gateway processes, perform the following steps:


Step 1 Enter the following command to add a M3UA or SUA signaling gateway process:

mml>prov-add:sgp:name="name", desc="description", extnode="itp"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

itp—MML name of a previously provisioned Cisco ITP external node.

For example, to add an SGP for an M3UA path named m3ua-sgp1, you would enter the following command:

mml>prov-add:SGP:NAME="m3ua-sgp1",DESC="M3UA SGP 1 - ITP1", EXTNODE="itp1"

For example, to add an SGP for an SUA path named sua-sgp1, you would enter the following command:

mml>prov-add:SGP:NAME="sua-sgp1",DESC="SUA SGP 1 - ITP1", EXTNODE="itp1"

Step 2 Repeat Step 1 for each SGP you want to add to your provisioning data.


Note You must define an SGP for each M3UA/SUA path that you provision.



Adding IP Routes (optional)

IP routes are required for your provisioning data if your Cisco PGW hosts are not on the same subnet as the Cisco access servers. To add IP routes, perform the following steps:


Step 1 If you do not already have an active provisioning session, start one as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to add an IP route:

mml>prov-add:iproute:name="name", desc="description", netmask="mask", nexthop="nhop", 
ipaddr="addr", dest="destination"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

mask—Subnet mask of the destination (optional). The value should be expressed as an IP Address in decimal dot notation (default is 255.255.255.255).

nhop—Next hop router hostname, IP address, or one of the following property names defined in the XECfgParm.dat file:

IP_NextHop

IP_NextHop2

IP_NextHop3

IP_NextHop4

IP_NextHop5

IP_NextHop6

IP_NextHop7

IP_NextHop8

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

IP Address should be in decimal dot notation and the hostname must be less than or equal to 32 characters.

addr—Local IP address. IP Address should be one of the following property names defined in the XECfgParm.dat file:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

destination—Destination hostname or IP address. IP Address should be in decimal dot notation and the hostname must be less than or equal to 32 characters.

For example, to add an IP route named iprte1, you would enter the following command:

mml>prov-add:IPROUTE:NAME="iprte1", DESC="IP Route 1", dest="10.82.80.0", 
ipaddr="IP_Addr1", netmask="255.255.255.0", nexthop="10.82.82.1"

Step 3 Repeat Step 2 for each IP route you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.

Otherwise, proceed to the "Adding M3UA and SUA Signaling Gateway Processes" section.


Adding SCTP Associations

To add SCTP associations, perform the following steps:


Step 1 Enter the following command to add an SCTP association:

mml>prov-add:association:name="name", desc="description", type="sigtype", sgp="sgp", 
ipaddr1="addr1", ipaddr2="addr2", port=num, peeraddr1="paddr1", peeraddr2="paddr2", 
peerport=pnum, iproute1="iprte1", iproute2="iprte2", rcvwin=rcv, maxinittrans=rtxinitmsg, 
maxinitrto=rtxinittim, maxretransdest=prtx, maxretrans=rtx, cumsackto=sacktm, 
bundleto=bundtm, minrto=minrtx, maxrto=maxrtx, hbto=hb, ipprecedence="ipprec", dscp="dscp"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

sigtype—Name of the signaling protocol for this association. Valid values are IUA, M3UA, and SUA.

sgp—MML name of a previously defined signaling gateway process.

addr1—First local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. Valid values are:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

addr2—Second local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. This parameter is optional. Valid values are:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

N/A (default value)

num—Local SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.

paddr1—Highest priority destination address, expressed in dot notation.

paddr2—Lowest priority destination address, expressed in dot notation. This parameter is optional. The default value for this parameter is 0.0.0.0.

pnum—Destination SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.

iprte1—MML name of first IP route (optional). Valid value is the MML name of a previously provisioned IP route.

iprte2—MML name of second IP route (optional). Valid value is the MML name of a previously provisioned IP route.

rcv—Number of bytes to advertise for the local receive window (optional). Valid value is the range from 1500 to 65535. The default value is 18000.

rtxinitmsg—Maximum number of times to retransmit SCTP INIT message (optional). Valid value is the range from 0 to 100. The default value is 10. A value of 0 means that the SCTP internal default value is used.

rtxinittim—Maximum initial time retransmission value (optional). Valid value is the range from 300 to 3000, and 0. The default value is 2000. A value of 0 means that the SCTP internal default value is used.

prtx—Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 3.

rtx—Maximum number of retransmissions over all destination address before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 5.


Note The value of this parameter cannot exceed the value of the MAXRETRANSDEST parameter times the number of destinations.


sacktm—Maximum time after a datagram is received before a SCTP SACK message is sent (optional). Valid value is the range from 100 to 500 ms. The default value is 300 ms.

bundtm—Maximum time SCTP waits for other outgoing datagrams for bundling (optional). Valid value is the range from 100 to 600 ms. The default value is 100 ms.

minrtx—Minimum value allowed for the retransmission timer (optional). Valid value is the range from 300 to 3000 ms. The default value is 300 ms.

maxrtx—Maximum value allowed for the retransmission timer (optional). Valid value is the range from 1000 to 3000 ms. The default value is 3000 ms.

hb—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.

ipprec—IP precedence (optional). The value for this parameter is inserted in place of the IP precedence portion of the Type of Service field in outing SCTP datagrams. Valid values are as follows:

ROUTINE (default) 000

PRIORITY 001

IMMEDIATE 010

FLASH 011

FLASH-OVERRIDE 100

CRITICAL 101

INTERNET 110

NETWORK 111

dscp—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.

EF 101110—Expedited Forwarding

AF11 001010—Assured Forwarding Class 1 Low Drop Precedence

AF12 001100—Assured Forwarding Class 1 Medium Drop Precedence

AF13 001110—Assured Forwarding Class 1 High Drop Precedence

AF21 010010—Assured Forwarding Class 2 Low Drop Precedence

AF22 010100—Assured Forwarding Class 2 Medium Drop Precedence

AF23 010110—Assured Forwarding Class 2 High Drop Precedence

AF31 011010—Assured Forwarding Class 3 Low Drop Precedence

AF32 011100—Assured Forwarding Class 3 Medium Drop Precedence

AF33 011110—Assured Forwarding Class 3 High Drop Precedence

AF41 100010—Assured Forwarding Class 4 Low Drop Precedence

AF42 100100—Assured Forwarding Class 4 Medium Drop Precedence

AF43 100110—Assured Forwarding Class 4 High Drop Precedence

N/A (default)

For example, to add an M3UA association named m3ua-assoc1, you would enter the following command:

mml>prov-add:ASSOCIATION:NAME="m3ua-assoc1",DESC="M3UA Association 1", 
TYPE="M3UA",SGP="m3ua-sgp1", IPADDR1="IP_Addr1", IPADDR2="IP_Addr2", 
PEERADDR1="10.82.80.187", PEERADDR2="10.82.81.164"

For example, to add an SUA association named sua-assoc1, you would enter the following command:

mml>prov-add:ASSOCIATION:NAME="sua-assoc1",DESC="M3UA Association 1", 
TYPE="SUA",SGP="sua-sgp1", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2", 
PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164"

Step 2 Repeat Step 1 for each M3UA or SUA association you want to add to your provisioning data.


Modifying M3UA and SUA Components

This section contains the procedures that you must perform to modify M3UA and SUA connections in your Cisco MGC provisioning data. When modifying the components that enable the Cisco MGC to support M3UA and SUA, perform the procedures in the following order.

Modifying Cisco ITP External Nodes

Modifying Point Codes (OPC, DPC, and APC)

Modifying M3UA and SUA Routing Keys

Modifying M3UA and SUA Routes

Modifying SS7 Signaling Services

Modifying SS7 Subsystems

Modifying M3UA and SUA SGPs

Modifying IP Routes

Modifying SCTP Associations


Note To begin the provisioning session, perform the steps in the "Starting a Provisioning Session" section. Once you have finished provisioning the M3UA and SUA data, save and activate your provisioning data by performing the steps in the "Saving and Activating your Provisioning Changes" section.


Modifying Cisco ITP External Nodes

Desc is the only parameter that can be modified for an existing Cisco ITP external node. To edit the description of a Cisco ITP external node, perform the following steps:


Step 1 Enter the following command to edit a Cisco ITP external node:

mml>prov-ed:extnode:name="name", desc="description"

Where:

name—MML name of the Cisco ITP node to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

For example, to modify an Cisco ITP external node named itp1, you would enter the following command:

mml>prov-ed:extnode:name="itp1", desc="7200 ITP"

Step 2 Repeat the above step for each Cisco ITP external node you want to modify in your provisioning data.


Modifying Point Codes (OPC, DPC, and APC)

An OPC cannot be modified if it is a parent component for an SS7, M3UA, or SUA route. Therefore, OPCs cannot be modified. To change the values for an OPC, you would first have to delete it, and then re-provision it. For more information on deleting OPCs, refer to "Deleting Point Codes (OPC, DPC, and APC)" section.

To modify DPCs, perform the following steps:


Step 1 Enter the following command to modify a DPC:

mml>prov-ed:dpc:name="name", desc="description", netaddr="addr", netind=num

Where:

name—MML name of the DPC to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

addr—The network address in dot notation.

num—The network indicator number. The default value is 0.

For example, to modify an DPC named dpc1, you would enter the following command:

mml>prov-ed:DPC:NAME="dpc1",DESC="Destinatio PC1",NETADDR="1.1.3",NETIND=4

Step 2 Repeat the above step for each DPC you want to modify in your provisioning data.


To modify APCs, perform the following steps:


Step 1 Enter the following command to modify an APC:

mml>prov-ed:apc:name="name", desc="description", netaddr="addr", netind=num

Where:

name—MML name of the APC to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

addr—The network address in dot notation.

num—The network indicator number. The default value is 0.

For example, to modify an APC named apc1, you would enter the following command:

mml>prov-ed:apc:NAME="apc1",DESC="Adjacent PC1",NETADDR="1.2.5",NETIND=3

Step 2 Repeat the above step for each APC you want to modify in your provisioning data.


Modifying M3UA and SUA Routing Keys

M3UA and SUA routing keys cannot be modified. To enter different values for existing M3UA and SUA routing keys, you must first delete them, as described in the "Deleting M3UA and SUA Routing Keys" section, and then provision new M3UA and SUA routing keys, as described in the "Adding M3UA and SUA Routing Keys" section.

Modifying SS7 Signaling Services

To modify SS7 signaling services, perform the following steps:


Step 1 Set the SS7 signaling service to be modified to the OOS state by entering the following MML command:

mml>set-dest:sig_srv:OOS

Where sig_srv is the MML name of the SS7 signaling service to be modified.

Step 2 Repeat Step 2 for each SS7 signaling service to be modified.

Step 3 Start a provisioning session as described in the "Starting a Provisioning Session" section.

Step 4 Enter the following command to modify an SS7 signaling service:

mml>prov-ed:ss7path:name="name", desc="description", side=cmside, mdo="protFile", 
custgrpid=num, m3uakey="rtkey"

Where:

name—MML name of the SS7 signaling service to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

cmside—Q.931 call model side. The valid values are user, for the user side, and network, for the network side. The default value is network.

protFile—MDO file name for the supported SS7 protocol. A list of file names for SS7 protocols supported in this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).

num—Customer group ID number. The valid value is a four-digit number. The default value is 0000.

rtkey—MML name of a previously provisioned M3UA key.

For example, to modify an SS7 signaling service named ss7svc1, you would enter the following command:

mml>prov-ed:SS7PATH:NAME="ss7svc1",DESC="Orig PC1 to INET Dest PC1",M3UAKEY="m3uakey2"

Step 5 Repeat Step 4 for each SS7 signaling service you want to modify in your provisioning data.

Step 6 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.

Step 7 Set the modified SS7 signaling services to the IS state by entering the following MML command for each signaling service:

mml>set-dest:sig_srv:IS

Where sig_srv is the MML name of the modified SS7 signaling service.


Modifying M3UA and SUA Routes

To modify M3UA routes, perform the following steps:


Step 1 Enter the following command to modify an M3UA route:

mml>prov-ed:m3uaroute:name="name", desc="description", dpc="dpc", extnode="itp", opc="opc"

Where:

name—MML name of the M3UA route to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

dpc—MML name of a previously provisioned DPC.

itp—MML name of a previously provisioned Cisco ITP external node.

opc—MML name of a previously provisioned OPC.

For example, to modify an M3UA route named m3uarte1, you would enter the following command:

mml>prov-ed:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Route 1",OPC="opc2",DPC="dpc2", 
EXTNODE="itp2"

Step 2 Repeat the above step for each M3UA route you want to modify in your provisioning data.


To modify SUA routes, perform the following steps:


Step 1 Enter the following command to modify an SUA route:

mml>prov-ed:suaroute:name="name", desc="description", apc="apc", extnode="itp", opc="opc", 
remotessn=num

Where:

name—MML name of the SUA route to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

apc—MML name of a previously provisioned APC.

itp—MML name of a previously provisioned Cisco ITP external node.

opc—MML name of a previously provisioned OPC.

num—SS7 subsystem number of the destination. The valid values are 2 through 254. The default value is 0.

For example, to modify an SUA route named suarte1, you would enter the following command:

mml>prov-ed:SUAROUTE:NAME="suarte1",DESC="SUA Route 1",APC="apc2",OPC="opc2", 
EXTNODE="itp2", remotessn=50

Step 2 Repeat the above step for each SUA route you want to add to your provisioning data.


Modifying SS7 Subsystems

To modify SS7 subsystems, perform the following steps:


Step 1 Enter the following command to modify an SS7 subsystem:

mml>prov-add:ss7subsys:name="name", desc="description", suakey="key", proto="protFam", 
transproto="protType", remotessn=remssn, localssn=locssn, stpscpind="index"

Where:

name—MML name of the SS7 subsystem to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

key—MML name of a previously defined SUA key.

protFam—MML name of the associated SS7 protocol family. Valid values are:

SS7-ANSI

SS7-ITU

SS7-China

SS7-Japan

SS7-UK

protType—MML name of the transport protocol. Valid values are SCCP and SUA. The default value is SCCP.

remssn—SS7 subsystem number of the destination. This number has to match the SSN value defined in the SUAROUTE.

locssn—Local SS7 subsystem number value. The valid values are integers between 2 and 254. This parameter cannot be used if an M3UA key is provisioned.

stpscpind—STP/SCP index used for Intelligent Network triggers.

For example, to modify an SS7 subsystem named ss7subsys1, you would enter the following command:

mml>prov-ed:SS7SUBSYS:NAME="ss7subsys1",DESC="Orig PC1 to APC",SUAKEY="suakey2", 
PROTO="SS7-ANSI"

Step 2 Repeat the above step for each SS7 subsystem you want to modify in your provisioning data.


Modifying M3UA and SUA SGPs

Desc is the only parameter that can be modified in M3UA and SUA signaling gateway processes. To modify the descriptions of M3UA and SUA signaling gateway processes, perform the following steps:


Step 1 Enter the following command to modify a M3UA or SUA signaling gateway process:

mml>prov-ed:sgp:name="name", desc="description"

Where:

name—MML name of the SGP to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

For example, to modify an SGP for an M3UA path named m3ua-sgp1, you would enter the following command:

mml>prov-ed:SGP:NAME="m3ua-sgp1",DESC="M3UA SG Process 1 - ITP1"

Step 2 Repeat the above step for each SGP you want to modify in your provisioning data.


Modifying IP Routes

The only IP route parameter that cannot be modified is the name. To modify IP routes, perform the following steps:


Step 1 Set the IP route to be modified to the OOS state as described in the "Setting the Service State of an IP Route" section.

Step 2 Repeat Step 1 for each IP route to be modified.

Step 3 Start a provisioning session as described in the "Starting a Provisioning Session" section.

Step 4 Enter the following command to modify an IP route:

mml>prov-ed:iproute:name="name", desc="description", netmask="mask", nexthop="nhop", 
ipaddr="addr", dest="destination"

Where:

name—MML name of the IP route to be modified.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

mask—Subnet mask of the destination (optional). The value should be expressed as an IP Address in decimal dot notation (default is 255.255.255.255).

nhop—Next hop router hostname, IP address, or one of the following property names defined in the XECfgParm.dat file:

IP_NextHop

IP_NextHop2

IP_NextHop3

IP_NextHop4

IP_NextHop5

IP_NextHop6

IP_NextHop7

IP_NextHop8

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

IP Address should be in decimal dot notation and the hostname must be less than or equal to 32 characters.

addr—Local IP address. IP Address should be one of the following property names defined in the XECfgParm.dat file:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

destination—Destination hostname or IP address. IP Address should be in decimal dot notation and the hostname must be less than or equal to 32 characters.

For example, to modify the destination and local IP address in an IP route named iparte1, you would enter the following command:

mml>prov-ed:IPROUTE:NAME="iprte1", dest="10.82.80.1", ipaddr="IP_Addr2"

Step 5 Repeat the Step 4 for each IP route you want to modify in your provisioning data.

Step 6 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.

Step 7 Set the IP route to be modified to the IS state as described in the "Setting the Service State of an IP Route" section.


Modifying SCTP Associations

To modify SCTP associations, perform the following steps:


Step 1 Set the SCTP association to be modified to the OOS state as described in the "Setting the Service State of an Association" section.

Step 2 Repeat Step 1 for each SCTP association to be modified.

Step 3 Start a provisioning session as described in the "Starting a Provisioning Session" section.

Step 4 Enter the following command to modify an SCTP association:

mml>prov-ed:association:name="name", desc="description", ipaddr1="addr1", ipaddr2="addr2", 
port=num, peeraddr1="paddr1", peeraddr2="paddr2", peerport=pnum, iproute1="iprte1", 
iproute2="iprte2", rcvwin=rcv, maxinittrans=rtxinitmsg, maxinitrto=rtxinittim, 
maxretransdest=prtx, maxretrans=rtx, cumsackto=sacktm, bundleto=bundtm, minrto=minrtx, 
maxrto=maxrtx, hbto=hb, ipprecedence="ipprec", dscp="dscp"

Where:

name—The name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol. The name should begin with a letter.

description—The long name assigned that can be as many as 128 alphanumeric characters in length.

addr1—First local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. Valid values are:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

addr2—Second local IP address, as defined by the XECfgParm.dat parameters IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4. This parameter is optional. Valid values are:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

N/A (default value)

num—Local SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.

paddr1—Highest priority destination address, expressed in dot notation.

paddr2—Lowest priority destination address, expressed in dot notation. This parameter is optional. The default value for this parameter is 0.0.0.0.

pnum—Destination SCTP port number (optional). Valid value is from 1024 to 65535. Default value varies based on the protocol type selected. Default for IUA is 9900. Default for M3UA is 2905. Default for SUA is 14001.

iprte1—MML name of first IP route (optional). Valid value is the MML name of a previously provisioned IP route.

iprte2—MML name of second IP route (optional). Valid value is the MML name of a previously provisioned IP route.

rcv—Number of bytes to advertise for the local receive window (optional). Valid value is the range from 1500 to 65535. The default value is 18000.

rtxinitmsg—Maximum number of times to retransmit SCTP INIT message (optional). Valid value is the range from 0 to 100. The default value is 10. A value of 0 means that the SCTP internal default value is used.

rtxinittim—Maximum initial time retransmission value (optional). Valid value is the range from 300 to 3000, and 0. The default value is 2000. A value of 0 means that the SCTP internal default value is used.

prtx—Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 3.

rtx—Maximum number of retransmissions over all destination address before the association is declared failed (optional). Valid value is the range from 1 to 10. The default value is 5.


Note The value of this parameter cannot exceed the value of the MAXRETRANSDEST parameter times the number of destinations.


sacktm—Maximum time after a datagram is received before a SCTP SACK message is sent (optional). Valid value is the range from 100 to 500 ms. The default value is 300 ms.

bundtm—Maximum time SCTP waits for other outgoing datagrams for bundling (optional). Valid value is the range from 100 to 600 ms. The default value is 100 ms.

minrtx—Minimum value allowed for the retransmission timer (optional). Valid value is the range from 300 to 3000 ms. The default value is 300 ms.

maxrtx—Maximum value allowed for the retransmission timer (optional). Valid value is the range from 1000 to 3000 ms. The default value is 3000 ms.

hb—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.

ipprec—IP precedence (optional). The value for this parameter is inserted in place of the IP precedence portion of the Type of Service field in outing SCTP datagrams. Valid values are as follows:

ROUTINE (default) 000

PRIORITY 001

IMMEDIATE 010

FLASH 011

FLASH-OVERRIDE 100

CRITICAL 101

INTERNET 110

NETWORK 111

dscp—Time between heartbeats (optional). The heartbeat is this value plus the current retransmission timeout value. Valid value is the range from 300 to 10000 ms, or 0. A value of 0 means that the heartbeat is disabled. The default value is 2000 ms.

EF 101110—Expedited Forwarding

AF11 001010—Assured Forwarding Class 1 Low Drop Precedence

AF12 001100—Assured Forwarding Class 1 Medium Drop Precedence

AF13 001110—Assured Forwarding Class 1 High Drop Precedence

AF21 010010—Assured Forwarding Class 2 Low Drop Precedence

AF22 010100—Assured Forwarding Class 2 Medium Drop Precedence

AF23 010110—Assured Forwarding Class 2 High Drop Precedence

AF31 011010—Assured Forwarding Class 3 Low Drop Precedence

AF32 011100—Assured Forwarding Class 3 Medium Drop Precedence

AF33 011110—Assured Forwarding Class 3 High Drop Precedence

AF41 100010—Assured Forwarding Class 4 Low Drop Precedence

AF42 100100—Assured Forwarding Class 4 Medium Drop Precedence

AF43 100110—Assured Forwarding Class 4 High Drop Precedence

N/A (default)

For example, to modify an M3UA association named m3ua-assoc1, you would enter the following command:

mml>prov-ed:ASSOCIATION:NAME="m3ua-assoc1",DESC="M3UA Association 1", IPADDR1="IP_Addr2", 
IPADDR2="IP_Addr1", PEERADDR1="10.82.80.188", PEERADDR2="10.82.81.165"

Step 5 Repeat Step 4 for each SCTP association you want to modify in your provisioning data.

Step 6 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.

Step 7 Set the SCTP association to be modified to the IS state as described in the "Setting the Service State of an Association" section.


Deleting M3UA and SUA Components

This section contains the procedures that you must perform to delete M3UA and SUA components from your Cisco PGW 2200 provisioning data. When deleting the components that enable the Cisco PGW 2200 to support M3UA and SUA, perform the procedures in the following order.

Deleting Cisco ITP External Nodes

Deleting Point Codes (OPC, DPC, and APC)

Deleting M3UA and SUA Routing Keys

Deleting SS7 Subsystems

Deleting M3UA and SUA Routes

Deleting SS7 Subsystems

Deleting M3UA and SUA SGPs

Deleting IP Routes

Deleting SCTP Associations


Note To begin the provisioning session, perform the steps in the "Starting a Provisioning Session" section. Once you have finished provisioning the M3UA and SUA data, save and activate your provisioning data by performing the steps in the "Saving and Activating your Provisioning Changes" section.


Deleting Cisco ITP External Nodes

To delete Cisco ITP external nodes, perform the following steps:


Step 1 Set the interface on the external node that is associated with the Cisco MGC software to the out-of-service state. Refer to the documentation for your media gateway for more information on taking interfaces out-of-service.

Step 2 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.

Step 3 If your system uses IP routes for this external node, delete the IP routes as described in the "Deleting IP Routes" section.

Step 4 Delete the SCTP associations for this external node, as described in the "Deleting SCTP Associations" section.

Step 5 Enter the following command to delete a Cisco ITP external node:

mml>prov-dlt:extnode:name="name"

Where name is the MML name of the Cisco ITP node to be deleted.

For example, to delete an Cisco ITP external node named itp1, you would enter the following command:

mml>prov-dlt:extnode:name="itp1"

Step 6 Repeat the above steps for each Cisco ITP external node you want to delete from your provisioning data.


Deleting Point Codes (OPC, DPC, and APC)

To delete OPCs, perform the following steps:


Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.

Step 2 Delete the SS7 routes. To do this, enter the following MML command:

mml>prov-dlt:ss7route:name="name"

Where name is the MML name of the SS7 route to be deleted.

For example, to delete an SS7 route named ss7route1, you would enter the following command:

mml>prov-dlt:ss7route:name="ss7route1"

Step 3 Delete the M3UA and SUA routing keys, as described in the "Deleting M3UA and SUA Routing Keys" section.

Step 4 Delete the M3UA and SUA routes, as described in the "Deleting M3UA and SUA Routes" section.

Step 5 Delete the SS7 subsystems, as described in the "Deleting SS7 Subsystems" section.

Step 6 Enter the following command to delete an OPC:

mml>prov-dlt:opc:name="name"

Where name is the MML name of the OPC to be deleted.

For example, to delete an OPC named opc1, you would enter the following command:

mml>prov-dlt:opc:name="opc1"

Step 7 Repeat the above steps for each OPC you want to delete from your provisioning data.


To delete DPCs, perform the following steps:


Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.

Step 2 Delete the SS7 routes. To do this, enter the following MML command:

mml>prov-dlt:ss7route:name="name"

Where name is the MML name of the SS7 route to be deleted.

For example, to delete an SS7 route named ss7route1, you would enter the following command:

mml>prov-dlt:ss7route:name="ss7route1"

Step 3 Delete the M3UA routing keys, as described in the "Deleting M3UA and SUA Routing Keys" section.

Step 4 Delete the M3UA routes, as described in the "Deleting M3UA and SUA Routes" section.

Step 5 Enter the following command to delete a DPC:

mml>prov-dlt:dpc:name="name"

Where name is the MML name of the DPC to be deleted.

For example, to delete an DPC named dpc1, you would enter the following command:

mml>prov-dlt:DPC:NAME="dpc1"

Step 6 Repeat the above steps for each DPC you want to delete from your provisioning data.


To delete APCs, perform the following steps:


Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.

Step 2 Delete the SS7 routes. To do this, enter the following MML command:

mml>prov-dlt:ss7route:name="name"

Where name is the MML name of the SS7 route to be deleted.

For example, to delete an SS7 route named ss7route1, you would enter the following command:

mml>prov-dlt:ss7route:name="ss7route1"

Step 3 Delete the SUA routing keys, as described in the "Deleting M3UA and SUA Routing Keys" section.

Step 4 Delete the SUA routes, as described in the "Deleting M3UA and SUA Routes" section.

Step 5 Enter the following command to delete an APC:

mml>prov-dlt:apc:name="name"

Where name is the MML name of the APC to be deleted.

For example, to delete an APC named apc1, you would enter the following command:

mml>prov-dlt:apc:NAME="apc1"

Step 6 Repeat the above steps for each APC you want to modify in your provisioning data.


Deleting M3UA and SUA Routing Keys

To delete M3UA routing keys, perform the following steps:


Step 1 Delete the SS7 signaling service, as described in the "Deleting SS7 Signaling Services" section.

Step 2 Enter the following command to delete an M3UA routing key:

mml>prov-dlt:m3uakey:name="name"

Where name is the MML name of the M3UA routing key to be deleted.

For example, to delete an M3UA routing key named m3rteky1, you would enter the following command:

mml>prov-dlt:m3uakey:NAME="m3rtekey1"

Step 3 Repeat the above steps for each M3UA routing key you want to delete from your provisioning data.


To delete SUA routing keys, perform the following steps:


Step 1 Delete the SS7 subsystem, as described in the "Deleting SS7 Subsystems" section.

Step 2 Enter the following command to delete an SUA routing key:

mml>prov-dlt:suakey:name="name"

Where name is the MML name of the SUA routing key to be deleted.

For example, to delete an SUA routing key named suakey1, you would enter the following command:

mml>prov-dlt:suakey:NAME="suakey1"

Step 3 Repeat the above steps for each SUA routing key you want to delete from your provisioning data.


Deleting SS7 Signaling Services

To delete SS7 signaling services, perform the following steps:


Step 1 Log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>set-dest:sig_srv:OOS

Where sig_srv is the MML name of the desired signaling service.

For example, to set the service state of a signaling service called sigsrv1 to OOS, enter the following command:

mml>set-dest:sigsrv1:OOS

Step 2 Block all of the CICs associated with this signaling service using the following MML command:

mml>blk-cic:sig_svc:all

Where sig_svc is the MML name of the signaling service associated with the CICs to be blocked.

Step 3 Delete the bearer channels associated with this signaling service using the following MML command:

mml>prov-dlt:nailedtrnk:dstsrv="sig_svc", "all"

Where sig_svc is the MML name of this signaling service.

Step 4 Enter the following command to delete an SS7 signaling service:

mml>prov-dlt:ss7path:name="name"

Where name is the MML name of the SS7 signaling service to be deleted.

For example, to delete an SS7 signaling service named ss7svc1, you would enter the following command:

mml>prov-dlt:SS7PATH:NAME="ss7svc1"

Step 5 Repeat the above steps for each SS7 signaling service you want to delete from your provisioning data.


Deleting M3UA and SUA Routes

To delete M3UA routes, perform the following steps:


Step 1 Enter the following command to delete an M3UA route:

mml>prov-dlt:m3uaroute:name="name"

Where name is the MML name of the M3UA route to be deleted.

For example, to delete an M3UA route named m3uarte1, you would enter the following command:

mml>prov-dlt:M3UAROUTE:NAME="m3uarte1"

Step 2 Repeat the above step for each M3UA route you want to delete from your provisioning data.


To delete SUA routes, perform the following steps:


Step 1 Enter the following command to delete an SUA route:

mml>prov-dlt:suaroute:name="name"

Where name is the MML name of the SUA route to be deleted.

For example, to delete an SUA route named suarte1, you would enter the following command:

mml>prov-dlt:SUAROUTE:NAME="suarte1"

Step 2 Repeat the above step for each SUA route you want to add to your provisioning data.


Deleting SS7 Subsystems

To delete SS7 subsystems, perform the following steps:


Step 1 Enter the following command to delete an SS7 subsystem:

mml>prov-dlt:ss7subsys:name="name"

Where name is the MML name of the SS7 subsystem to be deleted.

For example, to delete an SS7 subsystem named ss7subsys1, you would enter the following command:

mml>prov-dlt:SS7SUBSYS:NAME="ss7subsys1"

Step 2 Repeat the above step for each SS7 subsystem you want to delete from your provisioning data.


Deleting M3UA and SUA SGPs

To delete M3UA and SUA signaling gateway processes, perform the following steps:


Step 1 Delete the SCTP associations, as described in the "Deleting SCTP Associations" section.

Step 2 Enter the following command to delete a M3UA or SUA signaling gateway process:

mml>prov-dlt:sgp:name="name"

Where name is the MML name of the SGP to be deleted.

For example, to delete an SGP for an M3UA path named m3ua-sgp1, you would enter the following command:

mml>prov-dlt:SGP:NAME="m3ua-sgp1"

Step 3 Repeat the above steps for each SGP you want to delete from your provisioning data.


Deleting IP Routes

To delete IP routes, perform the following steps:


Step 1 Set the service state of the IP route to OOS, as described in the "Setting the Service State of an IP Route" section.

Step 2 Delete any components that used this route as a parameter. To delete SCTP associations, perform the steps found in the "Deleting SCTP Associations" section .

Step 3 Enter the following command to delete an IP route:

mml>prov-dlt:iproute:name="name"

Where name is the MML name of the IP route to be deleted.

For example, to delete an IP route named iprte1, you would enter the following command:

mml>prov-dlt:IPROUTE:NAME="iprte1"

Step 4 Repeat the above steps for each IP route you want to delete from your provisioning data.


Deleting SCTP Associations

To delete SCTP associations, perform the following steps:


Step 1 Set the SCTP association to the OOS state as described in the "Setting the Service State of an Association" section.

Step 2 Enter the following command to delete an SCTP association:

mml>prov-dlt:association:name="name"

Where name is the MML name of the association you want to delete.

For example, to delete an SCTP association named m3ua-assoc1, you would enter the following command:

mml>prov-dlt:ASSOCIATION:NAME="m3ua-assoc1"

Step 3 Repeat the above steps for each SCTP association you want to delete from your provisioning data.


Troubleshooting Tips

The following sections contain troubleshooting procedures related to provisioning:

Alarm Troubleshooting Procedures

Signaling Channel Troubleshooting Procedures

For more information on troubleshooting the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.

Alarm Troubleshooting Procedures

The alarms listed below are the new and modified alarms for this feature that require user action to be rectified. For a complete list of Cisco MGC alarms, refer to the Cisco Media Gateway Controller Software Release 9 System Messages Guide.

All M3UAKEY Ack Pending

This alarm occurs when the PGW cannot send or receive traffic for the identified SS7 signaling service.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Compare the routing context of the M3UA routing keys on the PGW with the AS definitions on the Signaling Gateway and reprovision to make them match.

Step 2 Verify that the AS is not shutdown on the Signaling Gateway.

Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


All M3UA Assoc Fail

This alarm occurs when all M3UA associations transporting SS7 signaling have failed.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Verify that the SGs are operating normally.

Step 2 Verify that the Ethernet interfaces between the Cisco MGC and the SGs are working properly.

Step 3 Verify that the configuration for your system is correct.

Step 4 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


All SUAKEY Ack Pending

This alarm occurs when the PGW cannot send or receive traffic for the identified SS7 subsystem.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Compare the routing context of the SUA routing keys on the PGW with the AS definitions on the Signaling Gateway and reprovision to make them match.

Step 2 Verify that the AS is not shutdown on the Signaling Gateway.

Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


All SUA Assoc Fail

This alarm occurs when all SUA associations transporting SS7 signaling have failed.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Verify that the SGs are operating normally.

Step 2 Verify that the Ethernet interfaces between the Cisco MGC and the SGs are working properly.

Step 3 Verify that the configuration for your system is correct.

Step 4 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


INVALID M3UA RC

This alarm occurs when an M3UA message is received from the identified signaling gateway with a routing context that has not been provisioned on the PGW.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Compare the routing context of the M3UA routing keys on the PGW and the Signaling Gateway and reprovision to make them match.

Step 2 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


INVALID SUA RC

This alarm occurs when there is a mismatch between SUA routing keys defined on the MGC and the Signaling Gateway.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Compare the routing context of the SUA routing keys on the MGC and the Signaling Gateway and reprovision to make them match.

Step 2 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


M3UAKEY Ack Pending

This alarm occurs when the MGC cannot send or receive traffic for the identified SS7 signaling service via the signaling gateway that has not acknowledged the M3UAKEY.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Compare the routing context of the M3UA routing keys on the MGC with the AS definitions on the Signaling Gateway and reprovision to make them match.

Step 2 Verify that the AS is not shutdown on the Signaling Gateway.

Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


SUAKEY Ack Pending

This alarm occurs when the PGW cannot send or receive traffic for the identified SS7 subsystem via the signaling gateway that has not acknowledged the SUAKEY.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Compare the routing context of the SUA routing keys on the PGW with the AS definitions on the Signaling Gateway and reprovision to make them match.

Step 2 Verify that the AS is not shutdown on the Signaling Gateway.

Step 3 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


SS7 SIG SRVC UNAVAIL

The identified SS7 signaling service is unavailable.

Corrective Action

To correct the problem identified by this alarm, perform the following steps:


Step 1 Perform the MML command rtrv-dest on the SS7PATH or SS7SUBSYS object.

If the state is OOS,FLD, the signaling service is out of service due to failure of the MTP3 transport. Perform a prov-rtrv:SS7PATH or a prov-rtrv:SS7SUBSYS on the signaling service object.

a. If the object has an OPC attribute defined, the signaling service is using SLTs for SS7 communication. The MTP3 layer is on the PGW. The SS7ROUTEs and LINKSETs need to be examined to determine the cause of the failure.

b. If the object doesn't have an OPC attribute define, the signaling service is using ITPs for SS7 communication. The MTP3 layer is one the ITPs. Examine the M3UAROUTEs that have the same OPC and DPC as SS7PATH or the SUAROUTEs that have the same OPC, APC, and REMOTE SSN to determine which ITP EXTNODEs are being uses by the signaling service. Consult the ITP documentation and debug the problem on the ITPs.

If the state is OOS,FLD&UPU, the signaling service is out of service due to failure of the user part layer at the destination. This remote destination should be examined to determine the cause of the failure.

Step 2 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


Signaling Channel Troubleshooting Procedures

The following signaling channel troubleshooting procedures are new for this feature:

Resolving an Association Alarm

Setting the Service State of an Association

Setting the Service State of an IP Route

Resolving an Association Alarm

When referred here by an alarm indicating a failure on an association, perform the following steps:


Step 1 If this alarm occurs along with the LIF FAIL alarm on the failed destination address, proceed to Step 2. Otherwise, proceed to Step 4.

Step 2 Verify the functioning of the cabling between the Cisco MGC and the destination address.

If the cables are functioning properly, proceed to Step 3.

If bad cable(s) are found, replace them. If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 3.

Step 3 Verify the functioning of the associated LAN switch.

If the LAN switch is functioning properly, proceed to Step 6.

If the LAN switch is not functioning properly, refer to the documentation for your LAN switch for troubleshooting information. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.

Step 4 Debug the IP connectivity between the Cisco MGC and the associated external node.

If the IP connectivity is working correctly, proceed to Step 5.

If the IP connectivity is not working correctly, refer to the documentation for the external node to determine a method to identify and fix the IP connectivity problem. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 5.

Step 5 Determine the health of the associated external node.

If the external node is working correctly, proceed to Step 6.

If the external node is not healthy, refer to the documentation for the external node for troubleshooting information. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.

Step 6 Contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, refer to the "Glossary" section.


Setting the Service State of an Association

To change the service state of an association, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>set-association:assoc_name:serv_state[,confirm]

Where:

assoc_name—MML name of the association you want to modify.

serv_state—Service state to which you want to change. Valid values for IP links are IS, OOS, and FOOS.

confirm—This parameter is required when you are setting the service state to OOS or FOOS.


Note This command cannot be used on the standby Cisco MGC.


For example, to set the service state of the association, assoc1, to OOS, enter the following command:

mml>set-association:assoc1:OOS,confirm

You can verify that the selected association is in the proper service state by performing the procedure in the "Retrieving the Service State for Associations" section.

Setting the Service State of an IP Route

To change the service state of an IP route, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>set-iproute:iproute_name:serv_state[,confirm]

Where:

iproute_name—MML name of the IP route you want to modify.

serv_state—Service state to which you want to change. Valid values for IP links are IS, OOS, and FOOS.

confirm—This parameter is required when you are setting the service state to OOS or FOOS.


Note This command cannot be used on the standby Cisco MGC.


An IP route in any of the following combinations of primary and secondary service states can be set to OOS or FOOS:

IS

OOS, CONF

OOS, OFF_DUTY

OOS, STDBY

For an IP route to be set to IS, it must have a primary service state of OOS and secondary service state of COOS.

For example, you would enter the following command to set the service state of an IP route called iprte1 to OOS:

mml>set-iproute:iprte1:OOS,confirm


Note You can verify that the selected IP route is in the proper service state by performing the procedure in the "Retrieving the Service State for IP Routes" section.


Monitoring and Maintaining

The following sections contain the procedures required for proper monitoring and maintenance of this feature. For more information on operational tasks for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide

Regular Operations

Introduction of this feature requires the new procedures for managing signaling channels.

Managing Signaling Channels

The following sections are new or modified for Release 9.4:

Retrieving the Service State for Associations

Retrieving the Service State for IP Routes

Retrieving the Service State for Associations

To retrieve the service state for an individual association, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>rtrv-association:assoc_name

For example, to retrieve the service state of an association called assoc1, enter the following command:

mml>rtrv-association:assoc1

The system returns a message similar to the following:

   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "assoc1:IS"

To retrieve attributes for all of the associations, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>rtrv-association:all

The system returns a message similar to the following:

   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "assoc1:OOS
   "assoc2:OOS
   "assoc3:OOS
   "assoc4:OOS

The valid service states for an association are described in the following sections. If the association is in any other state than IS, attempt to bring it into service, as described in the "Resolving an Association Alarm" section.

Association Primary Service States

The PST field shows the current primary service state of the association. Table 1 lists the valid primary service state values:

Table 1 Association Primary Service States 

Link State ID
Link State
Description

INB

Install busy

When a system is first configured, all associations default to this state and must be manually set in-service (IS) through the use of the set-iplnk MML command.

IS

In-service

Association is IS and fully operational. This is its normal operating state.

OOS

Out-of-service

Association is OOS. The system is actively trying to restore the association.


Association Secondary Service States

The SST field shows the current secondary service state of the specified association. Table 2 lists the valid secondary service state values:

Table 2 Association Secondary Service States 

Link State ID
Link State
Description

COOS

Commanded out-of-service

Association has been commanded OOS by the operator.

STBY

Standby

Association on the standby Cisco MGC.

CONF

Configuration

Association  is OOS due to a configuration failure.


Retrieving the Service State for IP Routes

To retrieve the service state for an individual IP route, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>rtrv-iproute:iproute_name

For example, to retrieve the service state of an IP route called iprte1, enter the following command:

mml>rtrv-iproute:iprte1

The system returns a message similar to the following:

   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "iprte1:IS"

To retrieve attributes for all of the IP routes, log in to the active Cisco MGC, start an MML session, and enter the following command:

mml>rtrv-iproute:all

The system returns a message similar to the following:

   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "iprte1:IS
   "iprte2:IS

The valid service states for an IP route are described in the following sections. If the route is in any other state than IS, attempt to bring it into service, as described in the "Setting the Service State of an IP Route" section.

IP Route Primary Service States

The PST field shows the current primary service state of the IP route. Table 3 lists the valid primary service state values:

Table 3 IP Route Primary Service States 

Link State ID
Link State
Description

IS

In-service

Route is IS and fully operational. This is its normal operating state.

OOS

Out-of-service

Route is OOS. The system is actively trying to restore the link.


IP Route Secondary Service States

The SST field shows the current secondary service state of the specified IP route. Table 4 lists the valid secondary service state values:

Table 4 IP Route Secondary Service States 

Link State ID
Link State
Description

COOS

Commanded out-of-service

Route has been commanded OOS by the operator.

STBY

Standby

Routes on the standby Cisco MGC.

OFF_DUTY

Off duty

Route is available for use, but not currently being used.

CONF

Configuration

Route is OOS due to a configuration failure.


Provisioning Examples

This section provides the following examples of provisioning for this feature:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7 External Node
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:extnode:name="va-2600-164",type="ITP",desc="2651 ITP",GROUP=1
prov-add:extnode:name="va-2600-165",type="ITP",desc="2651 ITP",GROUP=1

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Point Codes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:opc:name="opc",DESC="Own pointcode",NETADDR="2.1.4",NETIND=2,type="TRUEOPC"
prov-add:opc:name="opc-sua",DESC="Own pointcode for SUA", NETADDR="2.1.5", 
NETIND=2,type="TRUEOPC"
prov-add:DPC:NAME="dpc1",DESC="DPC1",NETADDR="1.1.5",NETIND=2
prov-add:DPC:NAME="dpc2",DESC="DPC2",NETADDR="1.2.2",NETIND=2
prov-add:apc:name="apc1",DESC="APC",NETADDR="1.2.4",NETIND=2
prov-add:apc:name="apc2",DESC="APC",NETADDR="1.2.5",NETIND=2

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA Key
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:M3UAKEY:NAME="m3uakey1",OPC="opc",DPC="dpc1",SI="ISUP", ROUTINGCONTEXT=10
prov-add:M3UAKEY:NAME="m3uakey2",OPC="opc",DPC="dpc2",SI="ISUP", ROUTINGCONTEXT=11

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA Key
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SUAKEY:NAME="suakey1",DESC="SUA Key 1",OPC="opc-sua",APC="apc1", 
LOCALSSN=200,ROUTINGCONTEXT=20
prov-add:SUAKEY:NAME="suakey2",DESC="SUA Key 2",OPC="opc-sua",APC="apc2", 
LOCALSSN=200,ROUTINGCONTEXT=21

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SUAROUTE:NAME="suarte1",DESC="SUA Rte 1",OPC="opc-sua",APC="apc1",
EXTNODE="va-2600-164",REMOTESSN=200
prov-add:SUAROUTE:NAME="suarte2",DESC="SUA Rte 2",OPC="opc-sua",APC="apc1",
EXTNODE="va-2600-165",REMOTESSN=200

prov-add:SUAROUTE:NAME="suarte3",DESC="SUA Rte 1",OPC="opc-sua",APC="apc2",
EXTNODE="va-2600-164",REMOTESSN=200
prov-add:SUAROUTE:NAME="suarte4",DESC="SUA Rte 1",OPC="opc-sua",APC="apc2",
EXTNODE="va-2600-165",REMOTESSN=200


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7PATH
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7PATH:NAME="ss7svc1",DESC="OPC1 to INET DPC1",M3UAKEY="m3uakey1", DPC="dpc1", 
MDO="Q761_BASE"
prov-add:SS7PATH:NAME="ss7svc2",DESC="OPC1 to INET DPC2",M3UAKEY="m3uakey2", DPC="dpc2", 
MDO="Q761_BASE"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7SUBSYS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7SUBSYS:NAME="ss7subsys1",DESC="OPC1 to APC",SUAKEY="suakey1", SVC="apc1", 
PROTO="SS7-ITU",TRANSPROTO="SUA"
prov-add:SS7SUBSYS:NAME="ss7subsys2",DESC="OPC1 to APC2",SUAKEY="suakey2", SVC="apc2", 
PROTO="SS7-ITU",TRANSPROTO="SUA"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Rte 1",OPC="opc",DPC="dpc1", 
EXTNODE="va-2600-164"
prov-add:M3UAROUTE:NAME="m3uarte2",DESC="M3UA Rte 2",OPC="opc",DPC="dpc1", 
EXTNODE="va-2600-165"

prov-add:M3UAROUTE:NAME="m3uarte3",DESC="M3UA Rte 3",OPC="opc",DPC="dpc2", 
EXTNODE="va-2600-164"
prov-add:M3UAROUTE:NAME="m3uarte4",DESC="M3UA Rte 4",OPC="opc",DPC="dpc2", 
EXTNODE="va-2600-165"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA SGP 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SGP:NAME="m3ua-sgp1",DESC="M3UA SGP 1 - va-2600-164 ITP",
EXTNODE="va-2600-164"
prov-add:SGP:NAME="m3ua-sgp2",DESC="M3UA SGP 2 - va-2600-165 ITP",
EXTNODE="va-2600-165"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA SGP 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SGP:NAME="sua-sgp1",DESC="SUA SGP 1 - va-2600-164 ITP",
EXTNODE="va-2600-164"
prov-add:SGP:NAME="sua-sgp2",DESC="SUA SGP 2 - va-2600-165 ITP",
EXTNODE="va-2600-165"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; M3UA ASSOCIATION 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:ASSOCIATION:NAME="m3ua-assoc1",DESC="M3UA Association 1", 
TYPE="M3UA",SGP="m3ua-sgp1", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164"

prov-add:ASSOCIATION:NAME="m3ua-assoc2",DESC="M3UA Association 2", 
TYPE="M3UA",SGP="m3ua-sgp2", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.188",PEERADDR2="10.82.81.165"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SUA ASSOCIATION 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:ASSOCIATION:NAME="sua-assoc1",DESC="M3UA Association 1", 
TYPE="SUA",SGP="sua-sgp1", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164"

prov-add:ASSOCIATION:NAME="sua-assoc2",DESC="M3UA Association 2", 
TYPE="SUA",SGP="sua-sgp2", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",
PEERADDR1="10.82.80.188",PEERADDR2="10.82.81.165"

Additional examples of provisioning for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Command Reference

This section documents new, modified, or deleted Man-Machine Language (MML) commands. All other commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide.

New MML Commands

This section contains the MML commands that are new for this feature.

RTRV-ASSOCIATION—Display State of SCTP Association

Purpose:

This MML command displays the primary and secondary states of an SCTP association.

Syntax:

rtrv-association:assoc_name
rtrv-association:all

Input Description:

Assoc_name—MML name of a previously configured SCTP association.

All—All associations

Output Description:

SCTP Association—MML name of SCTP association specified.

PST—Primary state; valid values are:

INB—Installed busy; association has been created but has not yet been commanded IN or OOS with the set-association command.

IS—In service

OOS—Out of service

SST—Secondary state; valid values are:

COOS—Commanded out of service

STBY—The local platform state is standby

CONF—Out of service due to a configuration failure

Example:

The MML command shown in the following example retrieves the state of all associations:

mml> rtrv-association:all

MGC-01 - Media Gateway Controller 2001-01-01 18:57:26
M RTRV
"assoc1:IS"
"assoc2:OOS,COOS"
;

Comments:

Performance Impact Category: A


RTRV-IPROUTE—Display Primary and Secondary States of an IP Route

Purpose:

This MML command displays the primary and secondary states of an IP route.

Syntax:

rtrv-iproute:ip_route_name
rtrv-iproute:all

Input Description:

Ip_route_name—MML name of a previously configured IP route.

All—Retrieves the primary state of all IP routes.

Output Description:

IP route—MML name of the specified IP route.

PST—Primary state; valid values are:

IS—In service

OOS—Out of service

SST—Secondary state; valid values are:

COOS—Commanded out of service

STBY—The local platform state is standby

OFF_DUTY—The link is available for use but is not currently being used.

CONF—The link is out of service due to a configuration failure.

Example:

The MML command shown in the following example retrieves the state of all IP routes:

mml> rtrv-iproute:all
   MGC-01 - Media Gateway Controller 2002-06-25 15:13:40.983 EST
M  RTRV
   "iproute1:IS"
   "iproute2:IS"

Comments:

Performance Impact Category: A


RTRV-SGP—Display the Primary and Secondary States of an SGP

Purpose:

This MML command displays the primary and secondary states of an SGP.

Syntax:

rtrv-sgp:sgp_name
rtrv-sgp:all

Input Description:

Isgpe_name—MML name of a previously configured SGP.

All—Retrieves the primary state of all SGPs.

Output Description:

IP route—MML name of the specified IP route.

PST—Primary state; valid values are:

INB—Installed busy (resource is being created, its state has not been determined yet)

IS—In service

OOS—Out of service

SST—Secondary state; valid values are:

STBY—The local platform state is standby

CONF—The link is out of service due to a configuration failure.

Example:

The MML command shown in the following example retrieves the state of all SGPs:

mml> rtrv-sgp:all
   MGC-01 - Media Gateway Controller 2003-01-25 15:13:40.983 EST
M  RTRV
   "sgp1:IS"
   "sgp2:IS"

Comments:

Performance Impact Category: A


SET-ASSOCIATION—Changing Association Primary State

Purpose:

This MML command changes the primary state of an SCTP association.

Syntax:

set-association:assoc_name:PST[,confirm]

Input Description:

Assoc_name—MML name of a previously configured SCTP association.

PST—Desired primary state; valid values are IS, OOS, or FOOS

Confirm—Verify desired state. This parameter must be used when the primary state desired is OOS

Example:

The MML command shown in the following example changes the primary state of an association to out of service:

mml> set-association:assoc1:OOS,confirm

Comments:

Performance Impact Category: B


SET-IPROUTE—Changing IP Route Primary State

Purpose:

This MML command changes the primary and secondary states of an IP route.

Syntax:

set-iproute:ip_route_name:pst[,confirm]

Input Description:

IP_rout_name—MML name of a previously configured IP route.

PST—Desired primary state; valid values are IS, OOS, or FOOS

Confirm—Must be used when you set the primary state to OOS to verify the new state. An IP route in any of the following states can be commanded OOS:

IS

OOS,CONF

OOS,OFF_DUTY

OOS,STBY.

Example:

The MML command shown in the following example changes the primary state of an IP route to out of service:

mml> set-iproute:iproute1:oos,confirm

Comments:

Performance Impact Category: B


Modified MML Commands

This section contains the MML commands that were modified for this feature.

PROV-ADD—Add Provisioning Component

Purpose:

This MML command adds a component to the Cisco MGC configuration.

Syntax:

prov-add:<comp>:name="<MML name>",<param name>=<param value>,...
prov-add:lnksetprop:name="<protocol family>",<param name>=<param value>,... 

Input Description:

lnksetprop—MML NE component consisting of parameters for which you can tune linkset communications. See Appendix A of the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a list of linkset property parameters.

comp—MML component type name for the type of configuration you are creating. The component type must match one of the component types listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide. If comp is EXTNODE, then the param_name TYPE must be present and needs to take a set of values (refer to the second example below). New components are added to this command for this feature.

name—MML component name for the new object you are creating (as many as ten characters).

protocol family—Name of the protocol family for which you are provisioning linkset properties. Use PROV-RTRV:VARIANTS for a list of protocol families configured for your system.

param name—The name of a valid configuration parameter for the specified component type. Parameter names are listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

param value—The value you want to assign to the parameter. If the parameter value is a string, it should be surrounded by quotation marks.

To define more than one parameter, enter additional param name=param value descriptions on the command line.

Example:

The MML command shown in the following example adds the origination point code for the MGC configuration:


mml> PROV-ADD:opc:NAME="opc",DESC="Point code of CP1",netaddr="0.0.1", 
netind=2,type="TRUEOPC"
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  COMPLD
"opc"
;

Example:

The MML command shown in the following example adds an external node to the MGC configuration:


mml> PROV-ADD:EXTNODE:NAME="TOTO2",DESC="TATA",TYPE="MGX8260"
Media Gateway Controller - MGC-02 2000-05-08 18:05:55
M COMPLD
"extnode"
;

Comments:

Performance Impact Category: B

Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a description of using the PROV commands for provisioning and for a description of components, parameter names, and parameter values used in provisioning the MGC.


PROV-DLT—Delete Components or Parameters

Purpose:

This MML command deletes a provisioned component.

Syntax:

prov-dlt:<comp>:name="<MML name>"
prov-dlt:lnksetprop:name="<protocol family>"

Input Description:

lnksetprop—MML NE component consisting of parameters for which you can tune linkset communications. See Appendix A of the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a list of linkset property parameters.

comp—MML component type name for the type of configuration you are creating. The component type must match one of the component types listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide. New components are added to this command for this feature.

name—MML name of the component you are modifying.

protocol family—Name of the protocol family for which you are provisioning linkset properties. Use PROV-RTRV:VARIANTS for a list of protocol families configured for your system.

Example:

The MML command shown in the following example deletes the point code component "opc":

mml> PROV-DLT:opc:NAME="opc"
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  COMPLD
   "opc"
   ;

Comments:

Perform PROV-STA—Start Provisioning Session before using this command.

Performance Impact Category: B

Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a description of using the PROV commands for provisioning and for a description of components, parameter names, parameter descriptions, and parameter values used in provisioning.


 

PROV-ED—Modify Provisioned Component

Purpose:

This MML command modifies a provisioned component.


Note Only those parameters that need to be modified must be entered.


Syntax:

prov-ed:<comp>:name="<MML name>",<param name>=<param value>,...
prov-add:lnksetprop:name="<protocol family>",<param name>=<param 
value>,... 

Input Description:

lnksetprop—MML NE component consisting of parameters for which you can tune linkset communications. See Appendix A of the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a list of linkset property parameters.

comp—MML component type name for the type of configuration you are creating. The component type must match one of the component types listed in this document or in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide. New components are added to this command for this feature.

name—MML name for the component you are modifying. You cannot change the component name.

protocol family—Name of the protocol family for which you are provisioning linkset properties. Use PROV-RTRV:VARIANTS for a list of protocol families configured for your system.

param name—The name of each configuration parameter you want to change. The parameter names must be valid for the specified component type. Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for a description of components, parameter names, parameter descriptions, and parameter values.

param value—The new value you want to assign to the parameter. If the parameter value is a string, it should be surrounded by quotation marks.


Note To modify more than one parameter, enter additional param name=value descriptions on the command line.


Example:

The MML command shown in the following example changes the description of the provisioned point code "opc":

mml> PROV-ED:opc:NAME="opc", DESC="Point code for this SSP"
Media Gateway Controller  - MGC-01 2000-01-12 15:19:51 
M  COMPLD
   "opc"
   ;

Comments:

Perform PROV-STA—Start Provisioning Session before using this command.

Performance Impact Category: B

Refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for information on using the PROV commands for provisioning and for a description of components, parameter names, and parameter values used in provisioning.


RTRV-DEST—Retrieve Destination

Purpose:

This MML command retrieves information about one or more destinations.

Syntax:

rtrv-dest:<sig path>
rtrv-dest:all

Input Description:

sig path—The MML name of the logical signal channel for which you want to display information. These should be signal path DSS IP or signal path NAS entities.

all—Displays information about all external point codes and signal paths.

Output Description:

<SIG PATH>—Signal path.

PKG—Protocol family.

ASSOC—Associated channels.

UNK—Unknown.

SWITCHED—The destination is switched, not associated.

<CHANNEL>—The channel with which the destination is associated.

PST—Primary state.

AOOS—The system has taken it out of service.

INB—Installed busy (resource has been created but not yet commanded IS or OOS by means of the SET-DEST command).

IS—In service.

MOOS—Manually taken out of service.

OOS—Out of service.

TRNS—Transient; the state is currently being changed.

UNK—Unknown.

SST—Secondary State.

UND—Undefined.

CRTE—Created.

DLT—Deleted.

CIS—Commanded in service.

COOS—Commanded out of service.

FLD—Failed.

RSTO—Restored.

RST—Reset.

CONG—Congestion.

FOOS—Forced out of service.

CINH—Commanded to the inhibited state.

CUINH—Commanded to the uninhibited state.

CEA—Commanded into emergency alignment.

EIS—Engine in service.

EOOS—Engine out of service.

UPU—User part unavailable (added in Release 9.4(1))

Example:

The MML command shown in the following example retrieves the destination of signal path ss7svc1:

mml> RTRV-DEST:SS7SVC1
   MGC-01 - Media Gateway Controller 2001-02-08 13:06:29
M  RTRV
   "ss7svc1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=RSTO"
   ;

Comments:

Performance Impact Category: C

This command supports wildcarding.


SET-IPLNK—Changing IP Link Primary State

Purpose:

This MML command changes the primary state of an IP link.

Syntax:

set-iplnk:iplnk_name:PST[,confirm]

Input Description:

Iplink_name—MML component name of an existing IP link

PST—Desired primary state; valid values are IS, OOS, or FOOS

Confirm—Verify desired state. This parameter must be used when the primary state desired is OOS

Example:

The MML command shown in the following example changes the primary state of an IP link to out of service:

mml> set-iplnk:iplink1:OOS,confirm

Comments:

.Performance Impact Category: B


VLD-CIC—Validate a Circuit

The VLD-CIC MML command previously could only be used for SS7PATHs in the ANSI protocol family. The VLD-CIC MML command can now also be used for SS7PATHs in the ITU protocol family. An ISUP CVT command is send on the specified CIC for the ANSI protocol family and an ISUP CVR is expected in response. For the ITU protocol family, an ISUP UPT command is send and an ISUP UPA is expected in response.

Purpose:

This MML command validates a circuit on a specified signal path and CIC. As of Release 9.4(1), you can use this command on both ANSI and ITU SS7 signaling services.

Syntax:

vld-cic:<sigpath>:cic=<number>

Input Description:

sigpathMML component name of a signal path associated with the CIC.

number—A valid circuit identification code.

Example:

The MML command shown in the following example validates a circuit on SS7SVC1 CIC-105:


ml> VLD-CIC:SS7SVC1:CIC=105

Media Gateway Controller - MGC-01 2000-03-07 09:35:19
M RTRV
"ss7svc1:CIC=105,PASSED"
;

Example:

The MML command shown in the following example shows the MML response for a circuit that has failed validation:

mml> VLD-CIC:SS7SVC1:CIC=1314
   MGC-01 - Media Gateway Controller 2001-02-08 13:54:04
M  RTRV
   "ss7svc1:CIC=1314,FAIL"
;

Comments:

Performance Impact Category: B

Output Description:

LOC: Values associated with the Cisco MGC.

REM: Values associated with the destination exchange. Valid values for these fields are:

GRP—Circuit group carrier indicator. The values in these fields should be the same in the LOC and REM lines. Valid values are:

UNK—Unknown circuit group carrier type

ANL—Analog circuit group carrier type

DIG—Digital circuit group carrier type

AND—Analog and digital circuit group carrier type

SEIZ—Double seizing indicator. The values for this field in the LOC line should be logically opposite to the value for the REM line. Valid values are:

NONE—No circuit control. When one line is set to NONE, the other should be set to ALL.

ALL— All circuit control. When one line is set to ALL, the other should be set to NONE.

EVEN— Even circuit control. When one line is set to EVEN, the other should be set to ODD.

ODD—Odd circuit control. When one line is set to ODD, the other should be set to EVEN

ALM—Alarm carrier indicator. The values in these fields should be the same in the LOC and REM lines. Valid values for this field are:

UNK—Unknown alarm carrier

SOFT—Software alarm carrier

HARD—Hardware alarm carrier

 

COT—Continuity check requirements indicator. The values in these fields should be the same in the LOC and REM lines. Valid values are:

UNK—Unknown continuity check requirements

NONE—No continuity check requirements

STAT—Statistical continuity check requirements

PERC—Per call continuity check requirements

 

TRK—Trunk number. This field is always displayed in the LOC line. It is only displayed in the REM line when the circuit identification names for the Cisco MGC and the destination exchange do not match.

A_CLLI—Common language location identifier (CLLI) for either the destination exchange or the Cisco MGC. CLLIs for each are sorted alphanumerically, and the A_CLLI field is populated with the CLLI that is first alphanumerically. This field is always displayed in the LOC line. It is only displayed in the REM line when the circuit identification names for the Cisco MGC and the destination exchange do not match.

Z_CLLI—CLLI code assigned to the Cisco MGC for either the destination exchange or the Cisco MGC. CLLIs for each are sorted alphanumerically, and the Z_CLLI field is populated with the CLLI that is last alphanumerically. This field is always displayed in the LOC line. It is only displayed in the REM line when the circuit identification names for the Cisco MGC and the destination exchange do not match.


Reference Information

The following sections contain reference material related to this feature. Information is included on the following areas:

XECfgParm.dat Parameters

Alarms

Logs

Measurements

Components

External Node Types

Properties

Provisioning Worksheets

XECfgParm.dat Parameters

The XECfgParm.dat file configuration parameters added for this feature are in the table below. None of the parameters added for this feature can be modified.

Configuration Parameter
Definition

*.M3UA.maxSigServices

Defines the maximum number of M3UA signaling services. It also defines the maximum number of M3UA routing keys.

Value: 1536


Note Do not change this value.


*.M3UA.maxOPCs

Defines the maximum number of M3UA OPCs.

Value: 64


Note Do not change this value.


*.M3UA.maxRoutesPerOpcDpc

Defines the maximum number of M3UA routes per OPC/DPC pair.

Value: 2


Note Do not change this value.


*.M3UA.maxSgp

Defines the maximum number of M3UA SS7 signaling gateway processes.

Value: 96


Note Do not change this value.


*.SUA.maxSigServices

Defines the maximum number of SUA signaling services. It also defines the maximum number of SUA routing keys.

Value: 256


Note Do not change this value.


*.SUA.maxOPCs

Defines the maximum number of SUA OPCs.

Value: 64


Note Do not change this value.


*.SUA.maxRoutesPerOpcApcSsn

Defines the maximum number of SUA routes per OPC, APC, and SSN set.

Value: 2


Note Do not change this value.


*.SUA.maxSgp

Defines the maximum number of SUA SS7 signaling gateway processes.

Values: 8


Note Do not change this value.



For information on the other XECfgParm.dat parameters, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.

Alarms

This section lists the alarms that have been added, modified or deleted in the Cisco MGC software to support this feature. For information on the other alarms for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.

New Alarms

This section contains the alarms that are added to support this feature.

All M3UAKEY Ack Pending

Description All acknowledgements for an M3UAKEY associated with this SS7PATH have not been received

Severity Minor

Cause The PGW cannot send or receive traffic for the SS7PATH

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

All M3UA Assoc Fail

Description All M3UA Associations transporting SS7 signaling have failed

Severity Critical

Cause All M3UA Associations transporting SS7 signaling have failed

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

All SUAKEY Ack Pending

Description All acknowledgements for an SUAKEY associated with this SS7SUBSYS have not been received

Severity Minor

Cause The PGW cannot send or receive traffic for the SS7SUBSYS

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

All SUA Assoc Fail

Description All SUA Associations transporting SS7 signaling have failed

Severity Critical

Cause All SUA Associations transporting SS7 signaling have failed

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

INVALID M3UA RC

Description Indicates there is mismatch between the M3UA routing keys on the PGW and the Signaling Gateway.

Severity Information

Cause Generated against a signaling gateway external node when an M3UA message is received from the signaling gateway with a routing context that has not been provisioned on the PGW

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

INVALID SUA RC

Description Invalid SUA Routing Context received from the Signaling Gateway

Severity Information

Cause There is a mismatch between SUA routing keys on the PGW and the Signaling Gateway

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

ISUP: T4 Expired

Description The ISUP t4 timer has expired

Severity Information

Cause When MTP STATUS primitive with cause "remote user unavailable" is received, UPT message is sent and T4 timer is started. When T4 timer expires UPT message is sent and T4 timer is started again. Alarm is generated every time T4 expires.

If UPT is requested by MML, UPT message is sent and T4 timer is started. When timer expires UPT message is sent again and T4 timer is started second time. When T4 timer expires a second time alarm is generated and UPT message is not sent anymore.

Type 0

Action No action required

M3UAKEY Ack Pending

Description An acknowledgement for an M3UAKEY associated with this SS7PATH or SG has not been received

Severity Minor

Cause The PGW cannot send or receive traffic for the SS7PATH via the SG that has not acknowledged the M3UAKEY

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

SUAKEY Ack Pending

Description An acknowledgement for an SUAKEY associated with this SS7SUBSYS or SG has not been received

Severity Minor

Cause The PGW cannot send or receive traffic for the SS7SUBSYS via the SG that has not acknowledged the SUAKEY

Type 1

Action Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

Modified Alarms

This section contains the alarm that is modified to support this feature.

SS7 SIG SRVC UNAVAIL

Description SS7 signaling service is unavailable

Severity Major

Cause The identified SS7 signaling service is unavailable

Type 1

Action The recommended action of this alarm is modified to support this feature.

Refer to the "Alarm Troubleshooting Procedures" section for the procedure for resolving this alarm.

Deleted Alarms

The following alarms are deleted to support this feature:

AVM DS1 FAIL

AVM E1 FAIL

AVM DS3 FAIL

AVM STS1 FAIL

AVM OC3 FAIL

Logs

This section lists the logs that are added or deleted to support this feature. For information on the other logs, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.

New Logs

This section contains the logs that are added to support this feature.

TIOS_ERR_INVALID_RC: Invalid %s ROUTING CONTEXT %d for SG %C

This message indicates a mismatch in the configuration of Routing Context between PGW and the Signaling Gateway.

Where:

%s: M3UA or SUA

%d: RC Value

%C: Name of SG.


Deleted Logs

This section contains the logs that are deleted to support this feature.

PROT_ERR_AVM

PROT_ERR_AVM_RSP_AFTER_TO

PROT_INFO_AVM_SIG_CHAN

PROT_INFO_AVM_SIG_PATH

PROT_TRACE_AVM_PDU

PROT_WARN_AVM_CONFIG_FAIL

TIOS_WARN_AVM_SSC_XMIT

TIOS_WARN_XMIT_AVM

PROT_ERR_VSI

PROT_ERR_VSI_ENG_SERVICE

PROT_ERR_VSI_MASTER

PROT_ERR_VSI_RESYNC_BADCKSUMBLK_EXCEEDED

PROT_ERR_VSI_RESYNC_CKSUMBLK_NOTFOUND

PROT_ERR_VSI_RESYNC_CONNID_CMTSTATUSFAIL

PROT_ERR_VSI_RESYNC_CONNID_DELETEFAIL

PROT_ERR_VSI_RESYNC_CONNID_NOTFOUND

PROT_ERR_VSI_RESYNC_PENDLIST_ADDFAIL

PROT_ERR_VSI_RESYNC_PENDLIST_EMPTY

PROT_ERR_VSI_RESYNC_PHYSIF_NOTFOUND

PROT_ERR_VSI_STATUSRESP_SENDFAIL

PROT_ERR_VSI_UNKN_MSGTYPE

PROT_INFO_VSI_CFG_MSG

PROT_INFO_VSI_MASTER

PROT_INFO_VSI_RESP_RCV

PROT_INFO_VSI_SIG_CHAN

PROT_INFO_VSI_SIG_PATH

PROT_TRACE_VSI_MASTER_MSG_SEND

PROT_TRACE_VSI_PDU

PROT_TRACE_VSI_PROCCTRLREQ

PROT_WARN_VSI

PROT_WARN_WRITE_EVT

TIOS_ERR_ASP_MSG

TIOS_WARN_ASP_RESET

TIOS_WARN_ASP_SSC_RCV

CP_CRIT_ASP_TYPE

CP_ERR_CRT_ASP

CP_INFO_RMG_INIT

TIOS_WARN_UNREC_ENUM

TIOS_ERR_CARD_INIT

TIOS_ERR_COLL_ERR

TIOS_ERR_INVALIDCARD

TIOS_ERR_INV_CARD

TIOS_ERR_INV_CARRIER

TIOS_ERR_NOLINE

TIOS_ERR_NOLINECOMP<<LOG TEXT>>

Measurements

The following table contains the system measurements that are added to support this feature.

Table 5 New Operational Measurements  

MML Counter Group:Name
Description
Related Components
Logging Interval

M3UA GROUP

M3UA: ErrorTx

M3UA: ErrorRx

M3UA: NotifyTx

M3UA: NotifyRx

M3UA: DunaRx

M3UA: DavaRx

M3UA message statistics

Number of error messages transmitted.

Number of error messages received

Number of notify messages transmitted

Number of notify messages received

Number of DUNA messages received

Number of DAVA messages received

Association

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

M3UA: DaudTx

M3UA: SconRx

M3UA: DrstRx

M3UA: DupuRx

M3UA: ASPUpTx

M3UA: ASPDnTx

M3UA: ASPUpAckRx

M3UA: ASPDnAckRx

M3UA: ASPActTx

M3UA: ASPInactTx

M3UA: AspActAckRx

M3UA: AspInactAckRx

Number of DAUD messages transmitted

Number of SCON messages received

Number of DRST messages received

Number of DUPU messages transmitted

Number of ASP UP messages transmitted

Number of ASP DOWN messages transmitted

Number of ASP UP acknowledgements received

Number of ASP DOWN acknowledge messages received

Number of ASP ACTIVE messages transmitted

Number of ASP INACTIVE messages transmitted

Number of ASP ACTIVE ACK messages received

Number of ASP INACTIVE ACK messages received

 

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

M3UA: DataXferTx

M3UA: DataXferRx

M3UA: DataBytesTx

M3UA: DataBytesRx

M3UA: InvSctpSig

M3UA: AssocFail

M3UA: AssocTxFail

M3UA: RxVersionErr

M3UA: RxMsgClassErr

M3UA: RxMsgTypeErr

M3UA: RxMsgLenErr

M3UA: RxStrmIdErr



M3UA: RxUnexpMsgErr

Number of DATA transfer messages transmitted

Number of DATA transfer messages received

Number of M3UA data bytes transmitted

Number of M3UA data bytes received

Number of invalid SCTP signals received by M3UA

Number of SCTP association failures

Number of transmit SCTP failures

Number of messages received with an invalid version

Number of received messages with an unexpected or unsupported Message Class

Number of messages received with an unexpected or unsupported Message Type

Number of messages received with length error

Number of messages received with stream ID error, when a message is received on an unexpected SCTP stream (for example, a Management message was received on a stream other than "0")

Number of unexpected messages received - a defined and recognized message is received that is not expected in the current state

 

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24



15, 60, 24

M3UA: RxProtErr


M3UA: RxParmValErr

M3UA: RxParmFieldErr

M3UA: RxUnexpParmErr

M3UA: RxNtwkAppErr

M3UA: RouteCntxErr

M3UA: RxNoMemErr

Number of messages received with protocol errors, for any protocol anomaly (that is, reception of a parameter that is syntactically correct but unexpected in the current state).

Number of messages received with parameter value errors

Number of messages received with a parameter having a wrong length field

Number of messages received that contain one or more invalid parameters

Number of messages received with an invalid (unconfigured) Network Appearance.

Number of messages received with an invalid (unconfigured) Routing Context.

Number of messages that were dumped because memory ran out (buffer overflow).

 

15, 60, 24


15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

SUA GROUP

SUA: ErrorTx

SUA: ErrorRx

SUA: NotifyTx

SUA: NotifyRx

SUA: DunaRx

SUA: DavaRx

SUA: DaudTx

SUA: SconRx

SUA: DrstRx

SUA: DupuRx

SUA: ASPUpTx

SUA: ASPDnTx

SUA message statistics

Number of error messages transmitted

Number of error messages received

Number of notify messages transmitted

Number of notify messages received

Number of DUNA messages received

Number of DAVA messages received

Number of DAUD messages transmitted

Number of SCON messages received

Number of DRST messages received

Number of DUPU messages transmitted

Number of ASP UP messages transmitted

Number of ASP DOWN messages transmitted

Association

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

SUA: ASPUpAckRx

SUA: ASPDnAckRx

SUA: ASPActTx

SUA: ASPInactTx

SUA: AspActAckRx

SUA: AspInactAckRx

SUA: CldtTx

SUA: CldrRx

SUA: DataBytesTx

SUA: DataBytesRx

SUA: InvSctpSig

SUA: AssocFail

SUA: AssocTxFail

Number of ASP UP acknowledgements received

Number of ASP DOWN acknowledge messages received

Number of ASP ACTIVE messages transmitted

Number of ASP INACTIVE messages transmitted

Number of ASP ACTIVE ACK messages received

Number of ASP INACTIVE ACK messages received

Number of Connectionless Data Transfers sent

Number of Connectionless Data Responses received

Number of SUA data bytes transmitted

Number of SUA data bytes received

Number of invalid SCTP signals received by SUA

Number of SCTP association failures

Number of transmit SCTP failures

 

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

SUA: RxVersionErr

SUA: RxMsgClassErr

SUA: RxMsgTypeErr

SUA: RxMsgLenErr

SUA: RxStrmIdErr

Number of messages received with an invalid version.

Number of received messages with an unexpected or unsupported Message Class.

Number of messages received with an unexpected or unsupported Message Type

Number of messages received with length error

Number of messages received with stream ID error, when a message is received on an unexpected SCTP stream (that is, a Management message was received on a stream other than "0")

 

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

SUA: RxUnexpMsgErr

SUA: RxProtErr


SUA: RxParmValErr

SUA: RxParmFieldErr

SUA: RxUnexpParmErr

SUA: RxNtwkAppErr

SUA: RouteCntxErr

SUA: RxNoMemErr

Number of unexpected messages received, a defined and recognized message is received that is not expected in the current state

Number of messages received with protocol errors, for any protocol anomaly (that is, reception of a parameter that is syntactically correct but unexpected in the current state).

Number of messages received with parameter value errors

Number of messages received with a parameter having a wrong length field

Number of messages received that contain one or more invalid parameters

Number of messages received with an invalid (unconfigured) Network Appearance.

Number of messages received with an invalid (unconfigured) Routing Context.

Number of messages that were dumped because memory ran out (buffer overflow).

 

15, 60, 24

15, 60, 24


15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24

ISUP-GROUP

ISUP: XMIT UPA TOT

ISUP: RCV UPA TOT

ISUP: XMIT UPT TOT

ISUP: RCV UPT TOT

ISUP message traffic statistics

Number of UPA messages sent

Number of UPA messages received

Number of UPT messages sent

Number of UPT messages received

MGC NE

15, 60, 24

15, 60, 24

15, 60, 24

15, 60, 24


For information on the other system measurements, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.

Components

The sections below contain the provisioning components that are added, modified, or deleted for this feature. For information on the rest of the components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

New Components

The following provisioning components are added for this feature.

IP Route

The IP route represents a static IP route. Its MML name is as follows:

MML Name—IPROUTE

The IP route component structure is shown in Table 6.

Table 6 IPROUTE Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

IP route name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

DEST

Destination hostname or IP address

IP Address in decimal dot notation or hostname that is less than or equal to 32 characters.

NETMASK

Subnet mask of Destination (optional)

IP Address in decimal dot notation. (255.255.255.255)

NEXTHOP

Next hop router IP address

IP Address or hostname that is less than or equal to 32 characters, or one of the following property names defined in XECfgParm.dat:

IP_NextHop1, IP_NextHop2, IP_NextHop8,
IP_Addr1, IP_Addr2, or IP_Addr4.

IPADDR

Local IP address

IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.

PRI

Priority

1 through 65535; (1)



Note NAME is the only parameter for this command that cannot be modified.


The following rules apply when creating or editing IP Routes:

The NETMASK attribute is validated by the system. For your provisioning set-up to work correctly, its value (when converted to binary) must have at least one leading 1 and cannot have any trailing 1s after the first 0. The values 255.255.0.0 and 255.255.255.128 are valid. The values 0.0.255.255, 255.0.0.255, and 0.0.0.0 are invalid.

Ensure the destination resolves to a non-zero address.

When the resolved destination address is bit ORed with the netmask value, the result is equal to the netmask (for example, a destination of 10.11.12.13 and a netmask of 255.255.0.0 would be invalid because the ORed result would be 255.255.12.13, which is not equal to 255.255.0.0).

The combination of DESTINATION, NETMASK, and IPADDR must be unique for each IP Route.

The combination of DESTINATION, NETMASK, and PRI must be unique for each IP Route.

When an IP Route is specified in a link object (for example, IPLNK, SESSIONSET, or ASSOCIATION), the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes to verify the IPROUTE is valid.

When an IP Route is specified in a link object (for example, IPLNK, SESSIONSET, or ASSOCIATION), the IPADDR must match the IPADDR of the link.

When an IPROUTE is not specified for a link object (having that option), the IP Address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it should not be assigned an IPROUTE. If the PEERADDR is on the same subnet as the DESTINATION (based on the NETMASK), and if the IPADDR matches the IPADDR of the link object, then use IPROUTE.

If the NEXTHOP attribute is a hostname or symbolic name from XECfgParm.dat, it can resolve to the address 0.0.0.0, which indicates the IPROUTE is not used. The IPROUTE status shows up in the rtrv-iproute:all command output when in the OOS, OFF_DUTY state.

If the resolved NEXTHOP address is not 0.0.0.0, it must be on the same subnet of the IPADDR.

The commands to retrieve and set the service state of an IP route can be found in the "Retrieving the Service State for IP Routes" section and the "Setting the Service State of an IP Route" section, respectively.

M3UA Key

This component represents an M3UA routing key. The parent component of the M3UAKEY is the OPC.

MML Name—M3UAKEY

The M3UA key component structure is shown in Table 7.

Table 7 M3UAKEY Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

M3UA key name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

OPC

Associated OPC

MML name of a previously configured OPC.

DPC

Associated DPC (optional)

MML name of a previously configured DPC.

ROUTING CONTEXT

Routing context value

Any integer except 0 (0 indicates no routing context). Each M3UA key must have a unique routing context.

SI

Service indicator

Service type, values are ISUP, TUP, and N/A (N/A).

NETWORK APPEARNCE

Network appearance (optional)

This parameter is optional. The valid values are integers from 1 through 32767. A value of 0 indicates an invalid network appearance.)



Note None of the parameters for this command can be modified.


The following rules apply when creating M3UA keys:

You can provision a maximum of 1536 M3UA keys

Up to 64 OPCs can use M3UA signaling services.

Parent OPC must be a true OPC

Cannot be deleted if it is being used by an SS7 signaling service

Two M3UA keys or SUA keys cannot have the same routing context value

M3UA Route

This component represents an M3UA route. It is used to determine how to get an SS7 message to a particular destination using M3UA.

MML Name—M3UAROUTE

The M3UA route component structure is shown in Table 8.

Table 8 M3UAROUTE Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

M3UA route name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

DPC

Associated DPC

MML name of a previously configured DPC.

EXTNODE

Associated external node

MML name of a previously configured external node.

OPC

Associated OPC

MML name of a previously configured OPC.



Note NAME is the only parameter for this command that cannot be modified.


The following rules apply when creating/editing M3UA routes:

The associated DPC must have an SS7 signaling service with an M3UA key defined (matches DPC attribute). If an M3UA key does not exist when the M3UA route is added/edited, a warning is issued. If an M3UA key is still not defined when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.

Multiple DPCs with the same NETADDR cannot be routed to the same OPC

The associated OPC must be a true OPC

For a given OPC/DPC only one route can be defined through a given external node.

Up to two M3UA routes can be defined per OPC-DPC pair

The associated external node must support M3UA signaling

M3UA routes for the same OPC-DPC pair must have external nodes in the same group

When the provisioning session is saved and activated, there must be an ASSOCIATION of type M3UA using an SGP that is using the EXTNODE of each M3UAROUTE.

SCTP Association

The SCTP association represents the connection between the Cisco MGC and a media gateway. Its MML name is as follows:

MML Name—ASSOCIATION

Table 9 Association Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

Unique ID of this component and component name used in MML commands

The name can be up to 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with an alphabetic character.

DESC

Unique ID of this component and component name used in MML commands

The name can be up to 128 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with an alphabetic character.

TYPE

Signaling Type

The type of protocol to be used. Values: M3UA, SUA, and IUA

SGP

MML name of SGP (optional)

MML name of a previously configured SGP. Used for M3UA and SUA interfaces.

IPADDR1

First local address

IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.

IPADDR2

Second local address (optional)

IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4, or N/A.

(N/A)

PORT

Local SCTP port number (optional)

From 1024 through 65535.

Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.

PEERADDR1

The highest priority destination address

IP address

PEERADDR2

The lowest priority destination address (optional)

IP address; (0.0.0.0).

PEERPORT

Destination SCTP port number. (optional)

From 1024 through 65535.

Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.

EXTNODE

External Node's MML name (optional)

MML name of a previously configured external node. Used in IUA interfaces.

IPROUTE1

MML Name of first IPROUTE (optional)

MML name of a previously configured IPROUTE.

IPROUTE2

MML Name of second IPROUTE (optional)

MML name of a previously configured IPROUTE.

RCVWIN

Number of bytes to advertise for the local receive window. (optional)

From 1500 through 65535 (18000).

MAXINITRETRANS

Maximum number of times to retransmit SCTP INIT message (optional)

0 through 100;(10)

0 means use SCTP internal default

MAXINITRTO

Maximum initial timer retransmission value (optional)

0, 300 through 3000 (2000)

0 means use SCTP internal default.

MAXRETRANS

Maximum number of retransmissions over all destination address before the association is declared failed (optional)

From 1 through 10 (5).

Note This value is not to exceed MAXRETRANSDEST * the number of destinations.

CUMSACKTO

Maximum time after a datagram is received before a SCPT SACK is sent (optional)

From 100 through 500 ms; (300).

BUNDLETO

Maximum time SCTP will wait for other outgoing datagrams for bundling (optional)

From 100 through 600 ms; (100).

MINRTO

Minimum value allowed for the retransmission timer (optional)

From 300 through 3000 ms; (300).

MAXRTO

Maximum value allowed for the retransmission timer (optional)

From 1000 through 3000 ms; (3000).

HBTO

Time between heartbeats. The heartbeat will be this value plus the current retransmission timeout value (optional).

The value can be 0, or from 300 through 10000 ms; (2000).

0 means disabled.

IPPRECEDENCE

Internet Protocol Precedence. This value will be place in the IP PRECEDENCE portion of the Type Of Service field for outgoing SCTP datagrams (optional)

Refer to the right column.

ROUTINE 000
PRIORITY 001
IMMEDIATE 010
FLASH 011
FLASH-OVERRIDE 100
CRITICAL 101
INTERNET 110
NETWORK; (ROUTINE) 111

DSCP

Differential Service Code Point. This value is place in the DSCP portion of the Type Of Service field for outgoing SCTP datagrams (optional)

EF 101110—Expedited Forwarding
AF11 001010—Assured Forwarding
Class 1 Low Drop Precedence
AF12 001100—Assured Forwarding
Class 1 Medium Drop Precedence
AF13 001110—Assured Forwarding
Class 1 High Drop Precedence
AF21 010010—Assured Forwarding
Class 2 Low Drop Precedence
AF22 010100—Assured Forwarding 2
Medium Drop Precedence
AF23 010110—Assured Forwarding
Class 2 High Drop Precedence
AF31 011010—Assured Forwarding
Class 3 Low Drop Precedence
AF32 011100—Assured Forwarding
Class 3 Medium Drop Precedence
AF33 011110—Assured Forwarding
Class 3 High Drop Precedence
AF41 100010—Assured Forwarding
Class 4 Low Drop Precedence
AF42 100100—Assured Forwarding
Class 4 Medium Drop Precedence
AF43 100110—Assured Forwarding
Class 4 High Drop Precedence
N/A; (N/A)

MAXRETRANSDEST

Maximum number of retransmissions to either PEERADDR1 or PEERADDR2 before it is declared failed (optional)

From 1 through 10; (3).


The SCTP association component structure is shown in Table 9.

The following parameters cannot be modified:

NAME

EXTNODE

TYPE

SGP

The following rules apply when creating/editing SCTP associations:

Only one association with a type of IUA can be assigned to an external node

If the type of the association is IUA, the associated external node must have its ISDN signaling type set to IUA, and that external node must be able to support IUA signaling.

If two associations have the same port value, the values of IPADDR1 and IPADDR2 must either be the same or both different.

The values of IPADDR1 and IPADDR2 must be different

If the value of IPPRECEDENCE is not ROUTINE, the value of DSCP must be N/A

If the value of DSCP is not N/A, the value of IPPRECEDENCE must be ROUTINE

The value of MAXRTO must be greater than or equal to the value of MINRTO

When a peer IP address (PEERADDR1 or PEERADDR2) is not on the local subnet of IPADDR1 or IPADDR2, that peer IP address cannot be on the subnet of any other local interface, even if it is not defined within the Cisco MGC software

When a peer IP address (PEERADDR1 or PEERADDR2) is not on the local subnet of IPADDR1 or IPADDR2, an IP route (IPROUTE1 or IPROUTE2, respectively) must be specified

When an IP route is specified, the values set in PEERADDR1 and PEERADDR2 are checked against the DESTINATION and NETMASK values of the IP route(s) to verify that the IP route is valid.

When an IP route is specified, its value for IPADDR must match the related IP address of the association. In other words, IPROUTE1 should have an IPADDR that matches IPADDR1 on the association, and IPROUTE 2 should have an IPADDR that matches IPADDR2 on the association.

When an IP route is not specified, the IP address resolved from the PEERADDR1 or PEERADDR2 parameter is checked against the defined IP routes to verify that it should not be assigned to one of those IP routes. If the peer address is on the same subnet as an IP route, the link should use that IP route.

The value of PEERADDR1 cannot be 0.0.0.0 or 255.255.255.255, and the value of PEERADDR2 cannot be 255.255.255.255

When a hostname is specified for a peer IP address, the hostname must resolve to an IP address.

PEERADDR1 and PEERADDR2 can resolve to the same IP Address. If the external node only has one IP address and two IP addresses (IPADDR1 and IPADDR2) are defined, PEERADDR2 should be set to the same value as PEERADDR1.

Associations, session sets, IP links, SIP links, and SS7 signaling gateway links that share a peer address (that is, PEERADDR, PEERADDR1, or PEERADDR2) must be assigned directly or indirectly to the same external node

When you are deleting an association, and a NASPATH uses the same external node, a warning message is issued to inform the you that the NASPATH must also be deleted. If it hasn't when the provisioning session is saved and activated, an error message is generated and the operation is stopped.

The value of PORT cannot be set to the same value as the PORT attribute of any IP link, session set, SIP link, or SS7 signaling gateway link

If a value for IPADDR2 or PEERADDR2 is specified, values for IPADDR1 or PEERADDR1 must also be specified. In other words, you cannot have one local address and two remote addresses, or two local addresses and one remote address.

An IP link, session set, SS7 signaling gateway link, or another association with a different external or signaling gateway node cannot use the resolved value set in PEERADDR1 or PEERADDR2.

Only one association can be defined to an SS7 signaling gateway process (SGP)

A value for EXTNODE can be defined only when the association type is IUA

A value for SGP can be defined only when the association type is M3UA or SUA

You can provision up to 96 associations with a type of M3UA.

You can provision up to 8 associations with a type of SUA.

The commands to retrieve and set the service state of an association can be found in the "Retrieving the Service State for Associations" section and the "Setting the Service State of an Association" section, respectively.

SS7 Signaling Gateway Process

This component represents a SS7 signaling gateway process.

MML Name—SGP

The SS7 signaling gateway process component structure is shown in Table 10.

Table 10 SGP Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

M3UA route name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

EXTNODE

External node that is running the SS7 signaling gateway process

MML name of a previously defined external node



Note DESC is the only parameter for this command that can be modified.


The following rules apply when creating/editing SS7 signaling gateway processes:

You can provision up to 96 M3UA SS7 signaling gateway processes.

You can provision up to 8 SUA SS7 signaling gateway processes.

For the provisioning session to be copied or deployed without error, an SCTP association must be using the SS7 signaling gateway process.

SUA Key

This component represents a SUA Routing key. The parent component for the SUAKEY is the OPC.

MML Name—SUAKEY

The SUA key component structure is shown in Table 11.

Table 11 SUAKEY Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

M3UA key name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

OPC

Associated OPC

MML name of a previously configured OPC.

APC

Associated APC (optional)

MML name of a previously configured APC.

LOCAL SSN

Associated local SSN

Number of a local SSN. Values are 0, 2-254 (0).

ROUTING CONTEXT

Routing context value

Any integer except 0 (0 indicates no routing context). Each SUA key must have a unique routing context.

NETWORK APPEARNCE

Network appearance

The valid values are integers from 1 through 32767. The value must match the network appearance value set on your Cisco ITP.



Note None of the parameters for this command can be modified.


The following rules apply when creating SUA keys:

You can provision up to 256 SUA keys.

Up to 64 OPCs can use SUA signaling services.

Parent OPC must be a true OPC

Cannot be deleted if it is being used by an SS7 signaling service

Two M3UA keys or SUA keys cannot have the same routing context value

SUA Route

This component represents a SUA route. It is used to determine how to get an SS7 message to a particular destination using SUA.

MML Name—SUAROUTE

The SUA route component structure is shown in Table 12.

Table 12 SUAROUTE Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

SUA route name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

APC

Associated APC

MML name of a previously configured APC.

EXTNODE

Associated external node

MML name of a previously configured external node.

OPC

Associated OPC

MML name of a previously configured OPC.

REMOTESSN

Associated remote SSN

Number of a remote SSN. Values are 0, 2-254 (0).



Note NAME is the only parameter for this command that cannot be modified.


The following rules apply when creating/editing SUA routes:

The associated APC must have an SS7 subsystem with an SUA key defined. If an SUA key is not defined when the provisioning session is saved and activated, an error message is generated and the operation is stopped.

Multiple APCs with the same NETADDR cannot be routed to the same OPC.

The associated OPC must be a true OPC.

For a given OPC, DPC, and remote SSN set, only one route can be defined through a given external node.

Up to two SUA routes can be defined per OPC, APC, and remote SSN set.

The associated external node must support SUA signaling.

SUA routes for the same OPC-APC pair must have external nodes in the same group.

When the provisioning session is saved and activated, there must be an ASSOCIATION of type SUA using an SGP that is using the EXTNODE of each SUAROUTE.

Modified Components

The following components are modified for this feature.

External Node

The external node component type represents another node with which the MGC communicates. Its MML name is as follows:

MML Name—EXTNODE

The parameters for EXTNODE are defined in Table 13.

Table 13 External Node Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)
NAME

MML name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to 128 characters.

TYPE

The type of the external node

Valid values can be found in the "External Node Types" section.

ISDNSIGTYPE

ISDN Signaling Type

Valid values are IUA or N/A (default is N/A). Added this parameter in software Release 9.4(1)T.

GROUP

M3UA/SUA Group Number

Value is 1-100 for M3UA or SUA nodes. Value is 0 for nodes that do not support M3UA or SUA. Added this parameter in software Release 9.4(1)T.



Note DESC is the only parameter for this command that can be modified:


The following rules apply when creating/editing external nodes:

TYPE must be one of the valid external node types.

You can provision up to 256 external nodes with an ISDNSIGTYPE of IUA.

IP Link

The IP link component type represents an IP link used on the CIsco MGC. IP links are used to communicate with the access control devices, such as a NAS. Its MML name is as follows:

MML Name—IPLNK

The IP link service component structure is shown in Table 14.

Table 14 IP Link Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

Unique ID of this component and component name used in MML commands

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to 128 characters.

IF

Ethernet interface MML name

MML name of a previously defined ENETIF or index of the ENETIF for SNMP. Removed this parameter in software Release 9.4(1).

PORT

Local port number

Any valid IP port number greater than 1024 (Recommended setting of 2427 for MGCP and SGCP).

PRI

Priority

Integer greater than 0; (1).

PEERADDR

Remote IP address

IP address; (0.0.0.0). This may also be specified as a hostname or a DNS name.

PEERPORT

Remote port

Any valid IP port number greater than 1024 (Recommended setting of 2427 for MGCP and SGCP)

IPADDR

Local logical IP address

IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4.

SVC

Signaling service this IP supports

MML name of a previously defined signal service or index of the signal service for SNMP.

NEXTHOP

Next hop address

IP address or hostname of the next hop; (0.0.0.0). Removed this parameter in software Release 9.3(2).

NETMASK

Subnet mask address

Subnet mask address; (255.255.255.255). Removed this parameter in software Release 9.3(2).

IPROUTE

IP route MML name

MML name of a previously defined IPROUTE. Added this parameter in software Release 9.4(1)T.



Note Only the NAME and SVC parameters cannot be modified.


The following rules apply when creating or editing IP links:

If the SVC is a NASPATH, then the ISDNSIGTYPE of the EXTNODE must be N/A.

If the SVC is a NASPATH, then the port number must be an odd number.

If the SVC is a NASPATH, then the local and remote port must be the same.

The maximum number of links per port is defined by the XECfgParm.dat parameter, maxNumLinks.

Links using the same SVC must have the same port number.

Links using the same SVC must have the same peer port number.

Cannot have more than two links using the same SVC and port number.

Peer address is unique per external node.

When an IPROUTE is specified, the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes of the IPROUTE to verify the IPROUTE is valid.

When IPROUTE is specified, the IPADDR must match the IPADDR of the IP link.

When an IPROUTE is not specified, the IP Address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it is not assigned to one of the IPROUTEs. If the PEERADDR is on the same subnet as an IPROUTE, then the link uses that IPROUTE.

The PORT attribute cannot be the same value as the PORT attribute of any ASSOCIATION, SESSIONSET, SIPLNK, or SS7SGLNK.

The PORT attribute cannot be set to the same value as the PORT attribute of an IPLNK with an SVC type different then the IPLNK SVC type. That is, the PORT value of an IPLNK supporting an NASPATH SVC cannot be the same as the PORT value of an IPLNK support an MGCPPATH, or EISUPPATH SVC.

Another IPLNK, SESSIONSET, SS7SGLNK, or ASSOCIATION with a different EXTNODE or SGNODE cannot use the resolved value of PEERADDR.

SIP IP Link

This is the MGC NE component type and represents a SIP IP link used on the MGC NE. These links are used to communicate with the SIP proxy servers. Its MML name is as follows:

MML Name—SIPLNK

The SIP link component structure is shown in Table 15.

Table 15 SIP Link Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

Unique ID of this component and component name used in MML commands

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

IF

Ethernet interface MML name

MML name of a previously defined Ethernet interface. Removed this parameter in software Release 9.4(1)T

PORT

Local port number

Any valid IP port number greater than 1024 (Recommended setting of 5060 for SIP).

PRI

Priority

Integer greater than 0; (1).

IPADDR

Local logical IP address

IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4.

SVC

Signaling service this IP supports

MML name of a previously defined signal service.

NEXTHOP

Next hop address

IP address or hostname of the next hop; (0.0.0.0). Removed this parameter in software Release 9.4(1)T.

NETMASK

Subnet mask address

Subnet mask address; (255.255.255.255). Removed this parameter in software Release 9.4(1)T.



Note Only the NAME and SVC parameters cannot be modified.


SS7 SG IP Link

This is the MGC NE component type and represents an IP link between the SS7 signaling gateway and the Cisco MGC. Its MML name is as follows:

MML Name—SS7SGIPLNK

The SS7 SG IP link component structure is shown in Table 16.

Table 16 SS7 SG IP Link Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

Unique ID of this component and component name used in MML commands

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

IF

Ethernet interface MML name

MML name of a previously defined Ethernet interface. Removed this parameter in software Release 9.4(1)T

PORT

Local port number

Any valid IP port number greater than 1024.

PRI

Priority

Integer greater than 0: (1)

PEERADDR

Remote IP address

IP address; (0.0.0.0). This may also be specified as a hostname or a DNS name.

PEERPORT

Remote port

Any valid IP port number
greater than 1024.

Note This field is ignored by the TIOS subsystems at this time.

The peerport value is contained in the XECfgParm field stPort. Currently set to 32767.

IPADDR

Local logical IP address

IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4;

SLC

Signaling link code

0 through 15; (1)

SGNODE

SG node MML name

MML name of a previously defined SG Node.

NEXTHOP

Next hop address

IP address or hostname of the next hop; (0.0.0.0). Removed this parameter in software Release 9.4(1)T.

NETMASK

Subnet mask address

Subnet mask address; (255.255.255.255). Removed this parameter in software Release 9.4(1)T.

IPROUTE

IP route MML name

MML name of a previously configured IPROUTE. Added this parameter in software Release 9.4(1)T.



Note Only the NAME and SGNODE parameters cannot be modified.


The following rules apply when creating or editing SS7 SG IPLNKs:

When an IPROUTE is specified, the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes of the IPROUTE to verify that the IPROUTE is valid.

When an IPROUTE is specified, the IPADDR must match the IPADDR of the link.

When an IPROUTE is not specified, the IP Address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it should not be assigned to one of the IPROUTEs. If the PEERADDR is on the same subnet as an IPROUTE, then the link should use that IPROUTE.

The PORT attribute cannot be set to the same value as the PORT attribute of any ASSOCIATION, IPLNK, SESSIONSET, or SS7SGLNK.

There is a maximum of 2 links allowed per SGNODE.

SS7 Signaling Service (sigpath)

The SS7 Signaling Service (sigpath) component type represents an SS7 signaling service or signaling path to a particular SS7 switch (destination). Its name is as follows:

MML Name—SS7PATH

The SS7 signaling service component structure is shown in Table 17.

Table 17 SS7 Signaling Service Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

Unique ID of this component and component name used in MML commands

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

SIDE

Q.931 call model side

String user for user side and network for network side; (network).

MDO

MDO file name

Valid protocol name from variants.dat. (This is limited to any MDO SS7 protocol variant.)

DPC

Destination point code MML name

MML name of a previously defined point code.

CUSTGRPID

Customer group ID

Four digit ID; (0000).

OPC

Originating Point Code MML name

MML name of a previously defined point code. Not allowed if M3UAKEY is specified.

M3UAKEY

M3UA Routing key MML name

MML name of a previously defined M3UA routing key. Not allowed if OPC is specified. This property added in software Release 9.4(1)T.



Note Only the NAME and DPC parameters cannot be modified.


The following rules apply when creating or editing SS7 signaling services:

If OPC is specified then M3UAKEY cannot be specified.

If M3UKAEY is specified then OPC cannot be specified.

If M3UAKEY has a DPC, it must match with the DPC parameter.

An OPC/DPC pair cannot use both M3UA (M3UAKEY specified) and SS7 signaling services (OPC specified).

Can only have one SS7 service for an OPC/DPC pair.

Can only have one M3UA service for a DPC/M3UAKEY pair.

A maximum of 1536 M3UA signaling services can be defined.

A M3UAROUTE must be defined when M3UAKEY is specified. This check is done when a provisioning session is saved and activated.

A SS7ROUTE must be defined when OPC is specified. This check is done when a provisioning session is saved and activated.

When editing an existing SS7 signaling service and specifying an OPC, if an M3UAKEY is set the OPC value must match the OPC of the M3UAKEY and the M3UAKEY value is then set to NULL.


Note This scenario is for falling back from an upgrade for the Support for M3UA and SUA with SCTP Feature.


When editing an existing SS7 signaling service and specifying a M3UAKEY, if an OPC is set the OPC value must match the OPC of the M3UAKEY and the OPC is then set to NULL.


Note This scenario is for upgrading for the Support for M3UA and SUA with SCTP Feature.


SS7 Route

The SS7 route component type represents an SS7 route. It is used in systems using Cisco SLTs to determine how to get an SS7 message to a particular destination. Its MML name is as follows:

MML Name—SS7ROUTE

The SS7 route component structure is shown in Table 18.

Table 18 SS7 Route Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

DPC

Destination point code MML name

MML name of a previously defined point code.

LNKSET

Linkset MML name

MML name of a previously defined linkset.

OPC

Originating point code MML name

MML name of a previously defined point code.

PRI

Priority

Integer greater than 0; (1).


The validation rules for this component are modified to allow an SS7ROUTE to be defined using a DPC that is not being used by a SS7PATH.

SS7 Subsystem

The SS7 subsystem component type represents an SS7 subsystem. It is used for specifying mated STPs and to provide LNP support through a SCP. Its MML name is as follows:

MML Name—SS7SUBSYS

The SS7 subsystem component structure is shown in Table 19.

Table 19 SS7 Subsystem Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

SVC

MML name of Adjacent point code or TCAP/IP service

MML name of a previously defined adjacent point code, or MML name of a previously defined TCAP/IP service.

PROTO

Protocol family

SS7-ANSI or SS7-ITU when creating an AIN subsystem.

MATEDAPC

Adjacent point code of the mated STP

MML name of a previously defined adjacent point code used when mating STPs. Not used when creating an AIN subsystem.

PRI

Priority

Integer greater than 0; (1). Not used when mating STP pairs.

LOCALSSN

Subsystem number

Integer from 2 through 254;(0) Can be set to non-zero only for SS7-ANSI, SS7-ETSI, or SS7-ITU. If set to 0, the subsystem is used for mating two STPs. Not allowed if M3UAKEY is specified.

STPSCPIND

STP/SCP index used for IN triggers

Integer greater than 0; (0). Not used when mating STP pairs.

TRANSPROTO

Transport protocol

SCCP, TCPIP, or SUA. If SVC is an APC, SCCP should be used. If SVC is a TCAP over IP service then TCPIP should be used; (SCCP). Not used when mating STP pairs.

OPC

Originating point code MML name of the mated STP

MML name of a previously defined originating point code. Either OPC, M3UAKEY, or SUAKEY can be specified.

SUAKEY

MML name of an SUA key (optional)

MML name of a previously defined routing key ID. Only used in support of SUA. Not allowed if OPC is specified. Added this parameter in software Release 9.4(1)T.

REMOTESSN

Remote subsystem number

Integer from 2 through 254;(0). Can be set to non-zero only for SS7-ANSI, SS7-ETSI, or SS7-ITU. If set to 0, the subsystem is used for mating two STPs. Use LOCALSSN if not specified.



Note Only the SVC parameter cannot be modified.


Keep the following in mind when creating or editing SS7 subsystems:

OPC must be a true OPC

An SS7 route cannot be defined to SVC(APC) if SUAKEY is specified.

At least one SUA route must be defined to SVC(APC) if SUAKEY is specified

If the APC is specified in the SUAKEY then it must be the same as SVC(APC)

SSN is not allowed if SUAKEY is specified.

If the TRANSPROTO is SUA, then SUAKEY must be specified, and MATEDAPC and OPC cannot be specified.

If the TRANSPROTO is SCCP, then OPC must be specified, and SUAKEY cannot be specified.

Remote SSN of the SUARoute must match the RemoteSSN of the SS7Subsystem.

Deleted Components

The following provisioning components are obsolete as of Release 9.4(1):

CARD

ENETIF

FASPATH

TDMIF

TDMLNK

External Node Types

Table 20 lists the valid external node types for this release of Cisco MGC software.

Table 20 External Node Types  

External Node MML Name
Release
Supported Signaling Service Types

AS3600

Release 9.1(5) and up

MGCP IPFAS NAS IUA

AS3660

Release 9.1(5) and up

MGCP IPFAS NAS IUA

AS5200

Release 9.1(5) and up

IPFAS NAS

AS5300

Release 9.1(5) and up

MGCP IPFAS NAS IUA

AS5350

Release 9.2(2) and up

MGCP IPFAS NAS BSMV0 IUA

AS5400

Release 9.2(2) and up

MGCP IPFAS NAS BSMV0 IUA

AS5800

Release 9.1(5) and up

IPFAS NAS

AS5850

Release 9.1(5) and up

IPFAS NAS

AS7200

Release 9.1(5) and up

MGCP IPFAS NAS

CAT8510

Release 9.1(5) and up

MGCP

CAT8540

Release 9.1(5) and up

MGCP

C2600

Release 9.4(1) and up

MGCP IPFAS IUA

H323

Release 9.1(5) and up

EISUP

ITP

Release 9.4(1) and up

M3UA SUA

LS1010

Release 9.1(5) and up

MGCP

MC3810

Release 9.1(5) and up

MGCP IPFAS

MGC

Release 9.1(5) and up

EISUP

MGX8260

Release 9.1(5) and up

MGCP IPFAS NAS

MGX8850

Release 9.1(5) and up

MGCP SGCP IPFAS

SLT

Release 9.2(2) and up

BSMV0

TALISS7

Release 9.1(5) and up

SS7SG

UNKNOWN

Release 9.1(5) and up

UNKNOWN


Properties

The following property is added for this feature.

Property
Definition

*.t4

When an MTP status primitive with a cause of remote user unavailable is received, an UPT message is sent and the T4 timer is started. When the T4 timer expires, another UPT message is sent and the T4 timer is started again. The ISUP: T4 Expired alarm is generated every time the T4 timer expires.

If you request UPT using MML, an UPT message is sent and the T4 timer is started. When the T4 timer expires, another UPT message is sent and T4 timer is started again. When the T4 timer expires second time alarm is generated and UPT message is not sent anymore.

Values range from 300,000 to 900,000. All timer values are represented in ms (1 minute = 60 seconds, 1 second = 1000 ms, 300,000 ms = 5 minutes, 900,000 ms = 15 minutes)

Default: 300000


This property is associated with the following parent objects:

Property Name
Parent Objects and Protocols
SS7-China
SS7-ITU

T4

Q761_CHINA Q761_CHINA_C2

ISUPV2_FRENCH ISUPV2_AUSTRIAN ISUPV2_SWISS ISUPV2_SWISS_C2 ISUPV2_FINNISH96 Q761_BASE ISUPV2_CZECH ISUPV2_32DIG ISUPV2_SPANISH_C2 ISUPV2_DUTCH ISUPV2_NORWEGIAN ETS_300_356


For information on other properties for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Provisioning Worksheets

This section contains worksheets for the provisioning components required for this feature.

Table 21 External Node Worksheet Example  

Name
Type
ISDN Signaling Type
Group
Description

itp1

itp

n/a

25

Cisco ITP number 1

         
         
         
         
         
         
         
         
         

Table 22 IP Route Worksheet Example  

Name
Destination
Subnet Mask
Next Hop
IP Address
Priority
Description

iproute1

itp1

255.255.255.0

itp2

175.25.211.17

1

IP route to itp1

             
             
             
             
             
             
             
             
             

Table 23 M3UA Key Worksheet Example  

Name
OPC
DPC
Routing Context
Service Indicator
Network Appearance
Description

m3key1

opc1

dpc1

14

ISUP

700

M3UA key 1

             
             
             
             
             
             
             
             
             

Table 24 M3UA Route Worksheet Example  

Name
DPC
External Node
OPC
Description

m3rte1

dpc1

itp1

opc1

M3UA route 1

         
         
         
         
         
         
         
         
         

Table 25 SCTP Association Worksheet Example 

Parameter
Parameter Value

Name

assoc1

         

Description

association 1

         

Signaling Type

M3UA

         

SGP name

sgp1

         

First local address

175.23.211.15

         

Second local address (optional)

n/a

         

Local SCTP port number (optional)

2905

         

Highest priority destination address

117.52.16.20

         

Lowest priority destination address (optional)

           

Destination SCTP port number (optional)

           

External node name

itp1

         

First IP route name (optional)

iproute1

         

Second IP route name (optional)

iproute2

         

Number of bytes to advertise for the local receive window. (optional)

           

Maximum number of times to retransmit SCTP INIT message (optional)

           

Maximum initial timer retransmission value (optional)

           

Maximum number of retransmissions over all destination address before the association is declared failed (optional)

           

Maximum time after a datagram is received before a SCPT SACK is sent (optional)

           

Maximum time SCTP will wait for other outgoing datagrams for bundling (optional)

           

Minimum value allowed for the retransmission timer (optional)

           

Maximum value allowed for the retransmission timer (optional)

           

Time between heartbeats (optional).

           

IP Precedence (optional)

           

Differential Service Code Point (optional)

           

Maximum number of retransmissions to either peer address 1 or 2 before it is declared failed (optional)

           

Table 26 SGP Worksheet Example  

Name
External Node
Description

sgp1

itp1

SGP for itp1

     
     
     
     
     
     
     
     
     

Table 27 SS7 Route Worksheet Example  

DPC
Linkset
OPC
Priority

dpc1

lnkset1

opc1

1

       
       
       
       
       
       
       
       
       

Table 28 SS7 Signaling Service Worksheet Example  

Name
Q.931 Call Model Side
MDO File Name
DPC
Customer Group ID
OPC or Route Key ID
Description

ss7svc1

network

ansi_ss7

dpc1

0000

m3rtkey1

SS7 signaling service 1

             
             
             
             
             
             
             
             
             

Table 29 SUA Key Worksheet Example  

Name
OPC
APC
Local SSN
Routing Context
Network Appearance
Description

suakey1

opc1

apc1

70

ISUP

7000

SUA key 1

             
             
             
             
             
             
             
             
             

Table 30 SUA Route Worksheet Example  

Name
APC
External Node
OPC
Remote SSN
Description

suarte1

apc1

itp1

opc1

100

SUA route 1

           
           
           
           
           
           
           
           
           

Table 31 SS7 Subsystem Worksheet Example 

Parameter
Parameter Value

Name of APC or TCAP/IP service

apc1

   

Protocol family

     

APC of the mated STP

apc2

   

Priority

     

Local SSN

     

STP/SCP Index

     

Transport protocol

SCCP

   

OPC

ROUTING_KEY_ID

   

Routing Key

rtkey1

   

SUA Key

     

Remote SSN

5

   

For worksheets covering the rest of the provisioning components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Glossary

Table 32 contains definitions of acronyms and technical terms used in this feature module.

Table 32 Glossary  

Term
Definition

ANSI

American National Standards Institute

CIC

Carrier Identification Code

DPNSS

Digital Private Network Signaling System—A PBX standard developed in the United Kingdom.

EISUP

Extended ISDN User Part—A proprietary protocol used to communicate between Cisco MGC nodes and between a Cisco MGC node and a Cisco H.323 System Interface.

I/O

Input/Output

IOCC

Input/Output Channel Controller

IOCM

Input/Output Channel Controller Manager

ISDN

Integrated Services Digital Network

ISUP

ISDN User Part

ITU

International Telecommunication Union

IUA

ISDN Q.921 User Adaptation Layer

LNP

Local Number Portability

M3UA

Message Transfer Point Level 3 User Adaptation

MGC

Media Gateway Controller

MGCP

Media Gateway Control Protocol

MIB

Managed Information Base

MML

Man-Machine Language

MTP3

Message Transfer Point Level 3

NAS

Network Access Server

NFAS

Non-Facility Associated Signaling

PSTN

Public Switched Telephone Network

Q.931

ITU Document that defines the ISDN connection control protocol.

Q.921

ITU Document that defines the data link protocol used on an ISDN D-channel. Also known as Link Access Protocol - D Channel (LAPD)

RFC

Return For Comment—A proposed standards document. There are RFCs for both IUA and SCTP.

RLM

Redundant Link Manager—A proprietary protocol used for the transport of Q.931 data between a Cisco MGC host and an associated media gateway.

SCCP

Service Connection Control Part

SCTP

Stream Controlled Transmission Protocol

SIGTRAN

Signaling Transport—An IETF working group that addresses the transport of packet-based PSTN signaling over IP networks.

SIP

Session Initiation Protocol

SS7

Signaling System 7

SUA

SCCP User Adaptation

TALI

Transport Adapter Layer Interface

TCAP

Transaction Capability Application Part

UDP

User Datagram Protocol


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.