Guest

Cisco PGW 2200 Softswitch

DPNSS Call Back And Extension Status

  • Viewing Options

  • PDF (796.6 KB)
  • Feedback
DPNSS Call Back And Extension Status Interworking with Cisco CallManager

Table Of Contents

DPNSS Call Back And Extension Status Interworking with Cisco CallManager

Feature Overview

Call Back When Free

Call Back When Next Used

Extension Status

Support for Up to 8 Call Manager Clusters

Restrictions

Related Features and Technologies

Related Documentation

Supported Standards, MIBs, and RFCs

Prerequisites for Using this Feature

XECfgParm.dat Configuration Tasks

Configuring The XECfgParm.dat File For This Feature

Verifying the XECfgParm.dat Changes

Configuration Example

Provisioning Procedures

Provisioning This Feature

Adding DPNSS Connections

Modifying DPNSS Components

Deleting DPNSS Components

Provisioning Example

Troubleshooting Provisioning Errors

Alarm Troubleshooting Procedures

Signaling Channel Troubleshooting Procedures

Monitoring and Maintaining

Regular Operations

Managing Signaling Channels

Command Reference

New MML Commands

PROV-ADD-axlserver (Release 9.6(1))

PROV-ADD-ctimgr (Release 9.6(1))

PROV-ADD-ctipath (Release 9.6(1))

PROV-DLT-axlserver (Release 9.6(1))

PROV-DLT-ctimgr (Release 9.6(1))

PROV-DLT-ctipath (Release 9.6(1)

PROV-ED-axlserver (Release 9.6(1))

PROV-ED-ctimgr (Release 9.6(1))

PROV-ED-ctipath (Release 9.6(1)

PROV-RTRV-axlserver (Release 9.6(1))

PROV-RTRV-ctimgr (Release 9.6(1))

PROV-RTRV-ctipath (Release 9.6(1)

Reference Information

XECfgParm.dat Parameters

Planning for Provisioning

Collecting External Node Data

Collecting DPNSS Path Data

Collecting IP Route Data (optional)

Collecting SCTP Association Data

Provisioning Basics

Starting a Provisioning Session

Saving and Activating Your Provisioning Changes

Ending a Provisioning Session Without Activating Your Changes

Retrieving Provisioning Data

Measurements

Billing Interface

Service ID (Tag: 4221)

Components

New Components

Modified Components

External Node Types

Properties

CallBackDBCleanUpTimer

MaxCBRequest

TimeOutCBNU

TimeOutCBWF

Provisioning Worksheets

Obtaining Documentation

Cisco.com

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco TAC Website

Opening a TAC Case

TAC Case Priority Definitions

Obtaining Additional Publications and Information

Glossary


DPNSS Call Back And Extension Status Interworking with Cisco CallManager


Document Release History

Publication Date
Comments

January 20, 2006

Initial version of the document.


Feature History

Release
Modification

9.4(1)

The DPNSS Transparency feature was introduced on the Cisco MGC software.

9.6(1)

The DPNSS Call Back and Extension Status feature was introduced on the Cisco MGC software.


This document describes the DPNSS Call Back and Extension Status feature. This feature is described in the following sections:

Feature Overview

Supported Standards, MIBs, and RFCs

Prerequisites for Using this Feature

XECfgParm.dat Configuration Tasks

Provisioning Procedures

Monitoring and Maintaining

Command Reference

Reference Information

Obtaining Documentation

Documentation Feedback

Obtaining Technical Assistance

Obtaining Additional Publications and Information

Glossary

Feature Overview

This feature enables the PGW 2200 to support interworking between a DPNSS PBX and Cisco CallManager for DPNSS Call Back When Free (CBWF), Call Back When Next Used (CBWNU), and Extension Status supplementary service features. This feature is supported across up to eight Cisco CallManager clusters.

Call Back When Free

The Call Back When Free (CBWF) feature allows a user who receives a busy signal (i.e. extension busy or network congestion) when trying to establish a call in the Private Network to request an automatic call back. The calling party can register the feature with the originating PBX which requests the terminating PBX to monitor the called extension. When the called extension and a transmission path across the network become free, the user who invoked the feature is notified by an audible and visual alert that the called extension is available. The user has the option at that time to accept the call back and a call will be set up from the user to the extension that becomes free.


Note Cisco PGW supports this feature for DPNSS to CCM calls, CCM to DPNSS calls, and calls within a CCM cluster.


Call Back When Next Used

The Call Back When Next Used (CBWNU) feature allows a user who receives no reply when trying to establish a call in the Private Network to request an automatic call back. The calling party can clear the call and invoke Call Back When Next Used. When the called extension becomes free after having been used, the user that invoked the feature is notified by an audible and visual alert. The user has an option at that time to accept the call back and a call will be set up from the user to the extension that becomes free.


Note Cisco PGW supports this feature for DPNSS to CCM calls, CCM to DPNSS calls, and calls within a CCM cluster.


Extension Status

The Extension Status feature allows the user to determine, on request, the status of an extension. This service permits the establishment of a Virtual Call to an extension to determine its state (free, busy, out of service, call waiting on, call forward all on) without calling the extension.

The PGW supports this feature for DPNSS PBX to CCM calls.

Support for Up to 8 Call Manager Clusters

This feature adds support for up to eight call manager clusters. It is used with features such as DPNSS CallBack and Extension Status.

Restrictions

CBWF and CBWNU features will not be supported under the following conditions:

For non XML-enabled IP phones connected to Cisco CallManager

For analog (non-IP phones) connected to Cisco CallManager

For DNs with multiple or shared lines

For same DN occurrence across multiple devices

For partitions on Cisco CallManager

For calls from DPNSS PBX phone to Cisco CallManager IP phone and being forwarded to DPNSS phones

For calls to or from CCM phones and DPNSS, or using CCM phones going through Cisco PGW

There are some additional limitations with the interworking of the Call Diversion feature with CCM, explained in the following two scenarios:

Scenario 1: There is a PBX phone A which registered a Call Diversion on-busy service and the forwarded-to party is PBX phone B in another PBX. A CCM IP phone calls PBX phone A, but phone A busy, so this call is forwarded to phone B. But phone B does not answer. The CCM IP phone invokes the Call Back When Next Used (CBWNF) feature. The expected result is that the CBWNU should target the phone A and CBWNU should be converted to Call Back When Free (CBWF). The actual result is that the CBWNU feature is targeted on phone A, not the CBWF.

Scenario 2: A CCM IP phone calls PBX phone A. Since PBX phone A has call forward immediate, this call is forwarded to phone B in another PBX, but phone B happens to be busy. So the CCM IP phone invokes the Call Back When Free feature. This Call Back When Free should be sent to PBX phone B. But the actual result is that it is sent to PBX phone A.

Related Features and Technologies

The following documentation is available to describe additional features on the PGW 2200 (MGC) and IOS Gateways that enable interworking between DPNSS PBXs and Cisco CallManager.

DPNSS Route Optimization

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/96/FMdp_rop.htm

DPNSS Call Back And Extension Status Interworking with Cisco CallManager

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/96/fmcbk_ex.htm

DPNSS Feature Transparency

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgcfm/941fm/fmdpnss.htm

Related Documentation

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/index.htm

Cisco Media Gateway Controller Hardware Installation Guide

Regulatory Compliance and Safety Information for the Cisco Media Gateway Controller

Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide

Release Notes for Cisco Media Gateway Controller Software Release 9.6(1)

Cisco Media Gateway Controller Software Release 9 Provisioning Guide

Cisco Media Gateway Controller Software Release 9 Dial Plan Guide

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

Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide

Cisco Media Gateway Controller Software Release 9 Messages Reference Guide

Cisco Media Gateway Controller Software Release 9 Billing Interface Guide

Cisco Media Gateway Controller Software Release 9 Management Information Base Guide

Supported Standards, MIBs, and RFCs

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

Standards

Digital Private Network Signaling System DPNSS 189 Issue 4 - Interworking Between DPNSS1 and Other Signaling Protocols

http://www.nicc.org.uk/nicc-public/Public/interconnectstandards/dpnss/nd1302_2001_12.pdf

MIBs

New MIBs are available for this feature. There is a new MIB for each new measurement. You can find a list of the new measurements in Measurements. For more information on the MIBs used in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Management Information Base Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mgc_mib/index.htm

RFCs

SCTP - RFC-2960

IUA - RFC-3057

Prerequisites for Using this Feature

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/relnote/rn961.htm

XECfgParm.dat Configuration Tasks

You must configure the XECfgParm.dat file in the Cisco MGC software to enable this feature. The following sections describe the tasks related to configuring the XECfgParm.dat file for this feature:

Configuring The XECfgParm.dat File For This Feature

Verifying the XECfgParm.dat Changes

Verifying the XECfgParm.dat Changes

Configuring The XECfgParm.dat File For This Feature

This section contains the steps necessary for configuration of the next hop IP address in the XECfgParm.dat file to support this feature. If you are installing and configuring the Cisco MGC software on your system for the first time, use the procedures in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm

Come back to this section once you encounter the *.IP_NextHop1 parameter in the XECfgParm.dat file.


Note You need to configure the *.IP_NextHop parameters when the Cisco MGC hosts are on different subnets. If your hosts are on the same subnet, do not perform the procedure below.



Caution Configuration of the Cisco MGC software requires that the system software be shut down. In a simplex system, calls cannot be processed during system shutdown. In a continuous service system, your system loses the ability to maintain calls during a critical event while the system software on one of the PGW hosts is shut down.


Caution Do not modify the other XECfgParm.dat parameters associated with this feature.

To configure the next hop IP addresses, perform the following steps:


Step 1 If you have not already done so, open the /opt/CiscoMGC/etc/XECfgParm.dat file on the active and standby Cisco PGW hosts using a text editor, such as vi.

Step 2 If you have not already done so, ensure that the pom.dataSync parameter is set to false on the active and standby Cisco PGW hosts.

Step 3 Search for the *.IP_NextHop1 parameter and enter the IP address of your first next hop destination on the active and standby Cisco PGW hosts.


Note The IP address should be expressed in dotted decimal notation (for example, 10.25.81.5).


Step 4 Repeat Step 3 for every next hop destination (*.IP_NextHop2, *.IP_NextHop3, etc.) you want to identify on the active and standby Cisco PGW hosts. Up to eight next hop IP addresses can be specified.

Step 5 Return to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm

and continue from where you left off. You will need to go to Adding DPNSS Connections in this document later if you intend to use an IUA interface for data backhaul between your Cisco PGW 2200 and your associated Cisco access gateway(s).


Verifying the XECfgParm.dat Changes

To verify the XECfgParm.dat settings for this feature, perform the following steps:


Caution Do not modify the other XECfgParm.dat parameters associated with this feature.


Step 1 Log in to the standby Cisco MGC as root and change directories to the etc subdirectory by entering the following UNIX command:

cd /opt/CiscoMGC/etc

Step 2 Open the XECfgParm.dat using a text editor, such as vi.

Step 3 Search for the *.IP_NextHop1 parameter and verify that the IP address of your first next hop destination is correct.


Note The IP address should be expressed in dotted decimal notation (for example, 10.25.81.5).


If the next hop IP address is correct, proceed to Step 4. Otherwise, correct the IP address and then proceed to Step 4.

Step 4 Repeat Step 3 for every next hop destination (*.IP_NextHop2, *.IP_NextHop3, and so forth) that you want to verify. You can specify up to eight next hop IP addresses.

Step 5 If all of your next hop destinations were correct, proceed to Step 9. Otherwise, proceed to Step 6.

If the next hop IP addresses you have entered are incorrect, perform the following steps. For more information on troubleshooting the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm

To ensure proper functioning of this feature, you must enter next hop IP addresses in the XECfgParm.dat file. These IP addresses are used when the next hop router IP addresses on the Cisco PGW hosts do not match. To enter next hop IP addresses, perform the following steps:

Step 6 Save your changes and close the text editor.

Step 7 Manually stop the Cisco MGC software on the standby Cisco MGC by entering the following UNIX command:

/etc/init.d/CiscoMGC stop

Step 8 Once the software shutdown is complete, manually start the Cisco MGC software on the standby Cisco MGC by entering the following command:

/etc/init.d/CiscoMGC start

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

mml>sw-over::confirm

Site alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state.

Step 10 Repeat steps 2 through 9 for the newly standby Cisco MGC host. Once you have verified the settings on both hosts, the procedure is complete.


Configuration Example

This section provides a configuration example for the XECfgParm.dat parameters associated with this feature. Additional configuration examples for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm


Note Configuration of XECfgParm.dat parameters for this feature is required only when the Cisco MGC hosts are not in the same subnet.


*.IP_NextHop1 = 147.21.135.10 
*.IP_NextHop2 = 147.15.170.11 
*.IP_NextHop3 = 0.0.0.0 
*.IP_NextHop4 = 0.0.0.0 
*.IP_NextHop5 = 0.0.0.0 
*.IP_NextHop6 = 0.0.0.0 
*.IP_NextHop7 = 0.0.0.0 
*.IP_NextHop8 = 0.0.0.0

Provisioning Procedures

You must modify the provisioning data of your system to enable this feature. Before you begin provisioning this feature, we recommend that you plan your provisioning changes as described in Planning for Provisioning.


Tip You can find information on starting and ending provisioning sessions and retrieving provisioning data in Provisioning Basics.


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

Provisioning This Feature

Provisioning Example

Troubleshooting Provisioning Errors

Provisioning This Feature

Provision the transport path for DPNSS data between the Cisco PGW 2200 and the external Cisco access gateway nodes to provide a reliable communication path between the two platforms.

Perform this provisioning when an external node is modified to use an SCTP-based protocol or when a new external node is added to the Cisco PGW 2200. This section covers the following provisioning topics:

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

Adding DPNSS Connections

Modifying DPNSS Components

Deleting DPNSS Components

Adding DPNSS Connections

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

Adding Cisco Access Gateway External Nodes

Adding IP Routes (Optional)

Adding SCTP Associations

Adding DPNSS Signaling Services

Adding Cisco Access Gateway External Nodes

To add Cisco access gateway external nodes, perform the following steps:


Step 1 Start a provisioning session as described in Starting a Provisioning Session.

Step 2 Enter the following command to add a Cisco access gateway external node:

prov-add:extnode:name="name", desc="description", type="as", isdnsigtype="iua"

Where:

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

description—The long name you assign to the node. It can be as many as 128 alphanumeric characters in length.

as—The MML name for the type of Cisco access gateway. Valid values can be found in External Node Types.

For example, to add a CCM cluster as an external node enter the following command:

mml>prov-add:extnode:name="<MML name>", desc="<MML description>", type="CCMCLUSTER"

Step 3 Repeat Step 2 for each Cisco media gateway external node you want to add to your provisioning data.

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

Otherwise, proceed to Adding IP Routes (Optional) if your Cisco PGW 2200 is on a different subnet from the associated access gateway, or proceed to the "Adding SCTP Associations" section if they are on the same subnet..

Step 5 Repeat Step 2 for each Cisco access gateway external node you want to add to your provisioning data.

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

Otherwise, proceed to the "Adding IP Routes (Optional)" section if your Cisco PGW 2200 is on a different subnet from the associated access gateway, or proceed to Adding SCTP Associations if they are on the same subnet.


Adding IP Routes (Optional)

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


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

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

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

Where:

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

description—The long name that you assign to the route. It can be as many as 128 alphanumeric characters in length.

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

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

IP_NextHop

IP_NextHop2

IP_NextHop3

IP_NextHop4

IP_NextHop5

IP_NextHop6

IP_NextHop7

IP_NextHop8

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

The IP address should be in dotted decimal notation, and the host name must be less than or equal to 32 characters.

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

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

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

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

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

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

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

Otherwise, proceed to Adding SCTP Associations.


Adding SCTP Associations

To add SCTP associations, perform the following steps:


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

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

prov-add:association:name="name", desc="description", type="IUA", ipaddr1="addr1", 
ipaddr2="addr2", peeraddr1="paddr1", peeraddr2="paddr2", extnode="gway", 
iproute1="iprte1", iproute2="iprte2"

Where:

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

description—The long name that you assign to the association. It can be as many as 128 alphanumeric characters in length.

addr1—First local IP address, as defined by the following XECfgParm.dat parameters:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

addr2—Second local IP address, as defined by the following XECfgParm.dat parameters:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

N/A (default value)

paddr1—Highest priority destination address, expressed in dotted decimal notation.

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

gway—MML name of a previously entered Cisco access gateway external node.

iprte1—MML name of a previously entered IP route (optional).

iprte2—MML name of a previously entered IP route (optional).

For example, to add an SCTP association named dpnssasassoc1, you would enter the following command:

prov-add:ASSOCIATION:NAME="dpnssassoc1",DESC="DPNSS Association 1", TYPE="IUA", 
IPADDR1="IP_Addr1", IPADDR2="IP_Addr2", PEERADDR1="10.82.80.187", 
PEERADDR2="10.82.81.164", extnode="gway-3600-37", IPROUTE1="iprte1", IPROUTE2="iprte2"


Note The parameters listed above are those you need in order to create an SCTP association for an IUA interface. For a complete list of parameters for this component, refer to SCTP Association.


Step 3 Repeat Step 2 for each SCTP association you want to add to your provisioning data.

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

Otherwise, proceed to Adding DPNSS Signaling Services.


Adding DPNSS Signaling Services

To add DPNSS signaling services, perform the following steps:


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

Step 2 Enter the following command to add a DPNSS signaling service:

prov-add:dpnsspath:name="name", desc="description", extnode="gway", abflag="side", 
sigport=portnum, sigslot=slotnum

Where:

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

description—The long name you assign to the service. It can be as many as 128 alphanumeric characters in length.

mgw—MML name of a previously defined external node. Valid types are:

C2600

AS3600

AS3660

side—DPNSS side for this signaling service (optional). Value values are A (for A side), B (for B side), and N (for not applicable) (N).

portnum—Number for physical port on the access gateway (optional). Valid values: 0-167 (0).

slotnum—Number for physical slot on the access gateway (optional). Valid values: 0-63 (0).

For example, to add a DPNSS signaling service named dpnsvc1, you would enter the following command:

prov-add:naspath:NAME="dpnsvc1",DESC="IUA DPNSS path", extnode="va-3660-20", abflag="a", 
sigport=45, sigslot=10

Step 3 Repeat Step 2 for each DPNSS signaling service you want to add to your provisioning data.

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


Modifying DPNSS Components

The following sections contain the procedures you need to follow to modify the various IUA connections in your Cisco PGW 2200 provisioning data:

Modifying Cisco Access Gateway External Nodes

Modifying DPNSS Signaling Services

Modifying IP Routes

Modifying SCTP Associations

Modifying Cisco Access Gateway External Nodes

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


Step 1 Start a provisioning session as described in Starting a Provisioning Session.

Step 2 Enter the following command to edit a Cisco access gateway external node:

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

Where:

name—MML name of the Cisco access gateway external node to be modified.

description—The long name you assign to the external nodes. It can be as many as 128 alphanumeric characters in length.

For example, to modify an Cisco access gateway external node named va-3600-37, you would enter the following command:

prov-ed:extnode:name="name-3600-37", desc="3600 supporting DPNSS"

Step 3 Repeat the above steps for each Cisco access gateway external node you want to modify in your provisioning data.

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


Modifying DPNSS Signaling Services

You can modify the description, DPNSS side identification, signaling port number, and signaling slot number in a DPNSS signaling service. To modify DPNSS signaling services, perform the following steps:


Step 1 Shut down the D-channel(s) on the associated access gateway(s). See the documentation for the access gateway for more information on shutting down D-channels.

Step 2 Set the DPNSS signaling services to be modified to the Out-of-Service (OOS) state by entering the following MML command:

set-dest:sig_srv:OOS

Where sig_srv is the MML name of the DPNSS signaling services to be modified.

Step 3 Repeat Step 2 for each of the DPNSS signaling services to be modified.

Step 4 Start a provisioning session as described in Starting a Provisioning Session.

Step 5 Enter the following command to modify an DPNSS signaling service:

prov-add:dpnsspath:name="name", desc="description", abflag="side", sigport=portnum, 
sigslot=slotnum

Where:

name—MML name of the component to be modified.

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

mgw—MML name of a previously defined external node. Valid types are:

C2600

AS3600

AS3660

side—DPNSS side for this signaling service (optional). Value values are A (for A side), B (for B side), and N (for not applicable) (N)

portnum—Number for physical port on the access gateway (optional). Valid values: 0-167 (0).

slotnum—Number for physical slot on the access gateway (optional). Valid values: 0-63 (0).

For example, to modify the DPNSS side identification on a DPNSS signaling service named dpnsvc1, you would enter the following command:

prov-ed:dpnsspath:NAME="dpnsvc1", abflag="a"

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

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

Step 8 Set the modified DPNSS signaling services to the In-Service (IS) state by entering the following MML command for each signaling service:

set-dest:sig_srv:IS

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

Step 9 Restore the D-channel(s) on the associated access gateway(s). See the documentation for the media gateway for more information on shutting down D-channels.


Modifying IP Routes

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


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

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

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

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

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

Where:

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

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

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

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

IP_NextHop

IP_NextHop2

IP_NextHop3

IP_NextHop4

IP_NextHop5

IP_NextHop6

IP_NextHop7

IP_NextHop8

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

The IP address should be in dotted decimal notation and the host name must be less than or equal to 32 characters.

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

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

destination—Destination host name or IP address. The IP address should be in dotted decimal notation and the hostname must be less than or equal to 32 characters.

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

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

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

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

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


Modifying SCTP Associations

Only the name, type, and extnode parameters cannot be modified for an SCTP association. To modify SCTP associations, perform the following steps:


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

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

Step 3 Start a provisioning session, as described in Starting a Provisioning Session.

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

prov-ed:association:name="name", desc="description", ipaddr1="addr1", ipaddr2="addr2", 
peeraddr1="paddr1", peeraddr2="paddr2", iproute1="iprte1", iproute2="iprte2"

Where:

name—MML name of the SCTP association to be modified.

description—The long name you assign to the association. It can be as many as 128 alphanumeric characters in length.

addr1—First local IP address, as defined by the following XECfgParm.dat parameters:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

addr2—Second local IP address, as defined by the following XECfgParm.dat parameters:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4

N/A (default value)

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

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

iprte1—MML name of a previously entered IP route (optional).

iprte2—MML name of a previously entered IP route (optional).

For example, to modify the local IP addresses for an SCTP association named dpnssassoc1, you would enter the following command:

prov-ed:ASSOCIATION:NAME="dpnssassoc1", IPADDR1="IP_Addr2", IPADDR2="IP_Addr3"

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

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

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


Deleting DPNSS Components

The following sections contain the procedures for deleting the DPNSS components in your Cisco PGW 2200 provisioning data:

Deleting Cisco Access Gateway External Nodes

Deleting DPNSS Signaling Services

Deleting IP Routes

Deleting SCTP Associations

Deleting Cisco Access Gateway External Nodes

To delete Cisco access gateway external nodes, perform the following steps:


Step 1 Set the interface on the external node that is associated with the Cisco MGC software to the OOS state. See the documentation for your media gateway for more information on taking interfaces OOS.

Step 2 Delete the signaling service(s) associated with this external node. To delete a DPNSS signaling service, perform the steps in Deleting DPNSS Signaling Services.

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

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

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

prov-dlt:extnode:name="name"

Where name is the MML name of the Cisco access gateway external node to be deleted.

For example, to delete a Cisco access gateway external node named va-3600-37, you would enter the following command:

prov-dlt:extnode:name="va-3600-37"

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


Deleting DPNSS Signaling Services

To delete DPNSS signaling services, perform the following steps:


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

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:

set-dest:sigsrv1:OOS

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

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:

prov-dlt:switchtrnk:dstsrv="sig_svc", "all"

Where sig_svc is the MML name of this signaling service.

Step 4 If trunk groups are provisioned for this signaling service, delete the trunk groups using the following MML command:

prov-dlt:trnkgrp:dstsrv="sig_svc", "all"

Where sig_svc is the MML name of this signaling service.

Step 5 Enter the following command to delete a DPNSS signaling service:

prov-dlt:dpnsspath:name="name"

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

For example, to delete a DPNSS signaling service named dpnsvc1, you would enter the following command:

prov-dlt:DPNSSPATH:NAME="dpnsvc1"

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


Deleting IP Routes

To delete IP routes, perform the following steps:


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

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

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

prov-dlt:iproute:name="name"

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

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

prov-dlt:IPROUTE:NAME="iprte1"

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


Deleting SCTP Associations

To delete SCTP associations, perform the following steps:


Step 1 Set the service state of the SCTP association to OOS, as described in Changing the Service State of an Association.

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

prov-dlt:association:name="name"

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

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

prov-dlt:ASSOCIATION:NAME="nasassoc1"

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


Provisioning Example

This section provides an examples of provisioning for the DPNSS feature. Additional examples of provisioning for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

________________________________________
; IP Route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:IPROUTE:NAME="iprte1",DEST="10.82.80.0",NETMASK="255.255.255.0",NEXTHOP="10.82.82
.1",IPADDR="IP_Addr1",DESC="IP Route 1"
prov-add:IPROUTE:NAME="iprte2",DEST="10.82.81.0",NETMASK="255.255.255.0",NEXTHOP="10.82.82
.1",IPADDR="IP_Addr2",DESC="IP Route 2"

________________________________________
; SS7 External Node
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:extnode:NAME="va-2600-165",TYPE="SLT",DESC="2611 SLT RUDP E1"
prov-add:extnode:NAME="va-2600-166",TYPE="SLT",DESC="2611 SLT RUDP E1"

________________________________________
; Point Codes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:OPC:NAME="opc",DESC="Own pointcode",NETADDR="1.1.3",NETIND=2,TYPE="TRUEOPC"
prov-add:DPC:NAME="dpc1",DESC="Destination pointcode1",NETADDR="1.1.1",NETIND=2
prov-add:DPC:NAME="dpc2",DESC="Destination pointcode2",NETADDR="1.1.2",NETIND=2

________________________________________
; Signal Services to Inet via SLT
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7PATH:NAME="ss7svc1",DESC="SS7 to dpc1",DPC="dpc1", OPC="opc", MDO="Q761_BASE"
prov-add:SS7PATH:NAME="ss7svc2",DESC="SS7 to dpc2",DPC="dpc2", OPC="opc", MDO="Q761_BASE"


________________________________________
; SS7 linksets
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:LNKSET:NAME="ls1",DESC="linkset 1 to dpc1",APC="dpc1",PROTO="SS7-ITU",TYPE="IP"
prov-add:LNKSET:NAME="ls2",DESC="linkset 2 to dpc2",APC="dpc2",PROTO="SS7-ITU",TYPE="IP"

________________________________________
; SS7 route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7ROUTE:NAME="rte1",DESC="SS7 Rte 
1-dpc1",OPC="opc",DPC="dpc1",LNKSET="ls1",PRI=1
prov-add:SS7ROUTE:NAME="rte2",DESC="SS7 Rte 
2-dpc2",OPC="opc",DPC="dpc2",LNKSET="ls2",PRI=1

________________________________________
; Sessionset
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:sessionset:NAME="slt1",ipaddr1="IP_Addr1",ipaddr2="IP_Addr2", PORT=7000, 
PEERADDR1="10.82.80.188",PEERADDR2="10.82.81.165",PEERPORT=7000,extnode="va-2600-165", 
TYPE="BSMV0",IPROUTE1="iprte1", IPROUTE2="iprte2"

prov-add:sessionset:NAME="slt2",ipaddr1="IP_Addr1",ipaddr2="IP_Addr2", 
PORT=7000,PEERADDR1="10.82.80.191",PEERADDR2="10.82.81.166",PEERPORT=7000, 
extnode="va-2600-166", TYPE="BSMV0",IPROUTE1="iprte1", IPROUTE2="iprte2"

________________________________________
; C7IPLinks
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:C7IPLNK:NAME="ls1lk1",DESC="SS7ANSI", LNKSET="ls1", 
sessionset="slt1",SLC=0,PRI=1,TIMESLOT=0

prov-add:C7IPLNK:NAME="ls2lk1",DESC="SS7ANSI", 
LNKSET="ls2",sessionset="slt1",SLC=0,PRI=1,TIMESLOT=2


prov-add:C7IPLNK:NAME="ls1lk2",DESC="SS7ANSI", LNKSET="ls1", 
sessionset="slt2",SLC=1,PRI=1,TIMESLOT=0

prov-add:C7IPLNK:NAME="ls2lk2",DESC="SS7ANSI", 
LNKSET="ls2",sessionset="slt2",SLC=1,PRI=1,TIMESLOT=2

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; External Node
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:EXTNODE:NAME="va-3660-20",TYPE="AS3660",DESC="IUA DPNSS", ISDNSIGTYPE="IUA"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SCTP Association
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:ASSOCIATION:NAME="dpnssassoc2",ipaddr1="IP_Addr3",ipaddr2="IP_Addr4", 
PEERADDR1="10.82.80.31",PEERADDR2="10.82.81.31", extnode="va-3660-20", 
TYPE="IUA",IPROUTE1="iprte1",IPROUTE2="iprte2"

Troubleshooting Provisioning Errors

The following sections contain troubleshooting procedures related to provisioning:

Alarm Troubleshooting Procedures

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 at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm

Alarm Troubleshooting Procedures

The alarms listed below are the new and modified alarms associated with this feature that require user action.


Note For a complete list of Cisco MGC alarms, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/errmsg/index.htm


CTI connections failed

CTI Connection to the cluster has failed. PGW tries to establish CTI link to CTI Manager in a call manager cluster. If CTI link to a CTI manager fails, PGW automatically tries to establish the CTI link to an alternate CTI Manager in the cluster. This alarm indicates that PGW has not established a CTI link to any CTI Manager in the cluster.


Note Only one CTI Manager can be active (IS) at one time. Other CTI Managers are set in state OOS. In this case, OOS does not mean that the CTI Manager is Out Of Service, it means that it is not currently used.


Corrective Action

You might see this alarm while PGW is trying to connect to an alternate CTI Manager. If you have configured more than one CTI Managers for the cluster wait for few minutes to see if PGW can re-establish the CTI connection automatically.


Step 1 Verify that all the configured CTI Managers in the CCM cluster are operating normally.

Step 2 Verify that Ethernet interfaces between PGW and CTI Managers are working properly.

Step 3 Check if there is "CTI Version mismatch" alarms for the CTI Managers. If so, fix that problem.

Step 4 Contact the Cisco TAC for further analysis of the problem.


CTI version mismatch

The CTI version of the CTI Manager component configured on the PGW is not compatible with the version on the CTI Manager. PGW uses a CTI protocol to communicate with the CTI Manager. CTI protocol version is checked during establishing the CTI connection. The CTI connection can not be established if the versions are not compatible.

Corrective Action

Check the version of CTI Manager and install the appropriate patches on the PGW to make it compatible with the version on CTI Manager.

MDL Call Back feature insertion failure

MDL failed to insert Call Back feature entry to the times ten data base. MDL inserts entries to the times ten data base to keep track of the lists of users requesting Call Back service on a particular DN. If the insertion fails, the Call Back feature will not work.

Corrective Action

Check to see if the times ten data base is functioning correctly.

MDL Call Back feature deletion failure

MDL failed to delete the Call Back feature entry from the times ten data base. MDL deletes entries from the times ten data base when the Call Back request is fulfilled; after notifying the requesting user the called extension becomes free. If the deletion fails, the Call Back feature will not function correctly.

Corrective Action

Check to see if the times ten data base is functioning correctly.

Signaling Channel Troubleshooting Procedures

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

Resolving an Association Alarm

Changing the Service State of an Association

Changing the Service State of an IP Route

Resolving an Association Alarm

When you are referred to this section by an alarm indicating a failure on an association, perform the following steps:


Step 1 If this alarm occurs along with a LIF FAIL alarm on the local IP address (ADDR1 and ADDR2), proceed to Step 2. Otherwise, proceed to Step 4.

Step 2 Check the functioning of the cabling between the Cisco MGC and the LAN switch.

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

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

Step 3 Check the functioning of the associated LAN switch. See the documentation for your LAN switch for the steps necessary to verify its proper functioning.

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

If the LAN switch is not functioning properly, refer to documentation for the LAN switch for the appropriate troubleshooting procedures. 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 access gateway.

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

If the IP connectivity is not working correctly, make the necessary repairs. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 5.

Step 5 Determine the health of the associated access gateway.

If the access gateway is working correctly, proceed to Step 6.

If the access gateway is not healthy, fix it using the procedures in the user documentation for the access gateway. 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, see Obtaining Technical Assistance.


Changing 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:

set-association:assoc_name:serv_state[,confirm]

Where:

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

serv_state— The 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:

set-association:assoc1:OOS,confirm

You can verify that the selected association is in the proper service state by performing the procedure in Retrieving the Service State of an Association.

Changing 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:

set-iproute:iproute_name:serv_state[,confirm]

Where:

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

serv_state—The 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 a 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:

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 Retrieving the Service State of an IP Route.


Monitoring and Maintaining

Step 7 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 at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm

Regular Operations

Introduction of the DPNSS Feature Transparency feature requires new procedures for managing signaling channels.

Managing Signaling Channels

The following sections are new or modified for Release 9.4:

Retrieving the Service State of an Association

Retrieving the Service State of an IP Route

Retrieving the Service State of an Association

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

rtrv-association:assoc_name

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

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:

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 state other than IS, attempt to bring it into service, as described in Resolving an Association Alarm.

Primary Service State of an Association

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

Table 1 Primary Service State of an Association 

Link State ID
Link State
Description

INB

Install busy

When a system is first configured, all associations default to this state.

IS

In-service

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

OOS

Out-of-service

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


Secondary Service State of an Association

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

Table 2 Association Secondary Service States of an Association 

Link State ID
Link State
Description

COOS

Commanded out-of-service

Association has been commanded OOS by the operator.

STBY

Standby

Association is on the standby Cisco MGC.

CONF

Configuration

Association  is OOS due to a configuration failure.


Retrieving the Service State of an IP Route

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

rtrv-iproute:iproute_name

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

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:

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 Changing the Service State of an IP Route.

Primary Service State of an IP Route

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

Table 3 IP Route Primary Service States 

Link State ID
Link State
Description

IS

In-service

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

OOS

Out-of-service

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


Secondary Service State of an IP Route

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

Table 4 IP Route Secondary Service States 

Link State ID
Link State
Description

COOS

Commanded out-of-service

Route has been commanded OOS by the operator.

STBY

Standby

Routes are on the standby Cisco MGC.

OFF_DUTY

Off duty

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

CONF

Configuration

Route is OOS due to a configuration failure.


Command Reference

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/mmlref/index.htm

New MML Commands

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

PROV-ADD-axlserver (Release 9.6(1))

Purpose:

This MML command sets the AXL server on the PGW to IS/OS.

Note A ctipath cannot have more than two AXL servers.

Syntax:

prov-add:axlserver:name="name", desc ="description", ctipath 
="ctisigpath", ipaddr1 = "localipaddr", peeraddr1 ="ipaddress", iproute1 
="iproute1", username ="username", password ="password"

Input

Description:

name—The MML name of the AXL server.

description—The description of the AXL server.

ctisigpath—The name of an existing CTI sigpath.

ipaddr1—The local IP address of the CTI Manager.

peeraddr1—The first peer address of the CTI Manager.

peeraddr2—The second peer address of the CTI Manager.

peerport—Peer CTI Manager Port.

iproute1—The name of the first IP Route.

username—The name of the user. Can be a string up to 128 characters.

password—The password used by the user. Can be a string up to 128 characters.

Example:

The MML command shown in the following example enables the AXL server:

mml> prov-add:axlserver:name="axlserver", desc ="AXL server", ctipath 
="ctisigpath", ipaddr1 = "IP_addr1", peeraddr1 ="161.44.1.1", iproute1 
="ip1", username ="admin", password ="cisco"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-ADD-ctimgr (Release 9.6(1))

Purpose:

This MML command sets the CTI Manager on the PGW to IS/OS.

Note A CTI path cannot have more than two CTI managers.

Syntax:

prov-add:ctimgr:name="name", desc ="description", ctipath ="ctisigpath", 
ipaddr1 = "localipaddr", peeraddr1 ="ipaddress", iproute1 ="iproute1", 
username ="username", password ="password", ctiversion ="version"

Input

Description:

name—The MML name of the CTI Manager.

description—The description of the CTI Manager.

ctisigpath—The name of an existing CTI sigpath.

ipaddr1—The local IP address of the CTI Manager.

peeraddr1—The first peer address of the CTI Manager.

peeraddr2—The second peer address of the CTI Manager.

peerport—Peer CTI Manager Port.

iproute1—The name of the first IP Route.

username—The name of the user. Can be a string up to 128 characters.

password—The password used by the user. Can be a string up to 128 characters.

ctiversion—The version of the CTI Manager. Can be a string up to 20 characters.

Example:

The MML command shown in the following example enables the CTI Manager on the PGW:

mml> prov-add:ctimgr:name="ctimgr", desc ="CTI manager 1", ctipath 
="ctisigpath", ipaddr1 = "IP_addr1", peeraddr1 ="161.44.1.1", iproute1 
="ip1", username ="admin", password ="cisco", ctiversion ="5"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI



Note This command is for Cisco MGC software Release 9.6(1) only.


PROV-ADD-ctipath (Release 9.6(1))

Purpose:

This MML command is used to provision the CTI sigPath.

Note The CTI sigPath can have up to eight CTI paths. Only one CTI path is allowed per CCM cluster.

Syntax:

prov-add:ctipath:name ="name", desc ="description", 
extnode="clustername", MDO="QBE"

Input

Description:

name—The MML name of the CTI Path.

description—The description of the CTI Path.

clustername—The MML name of a previously defined external node.

QBE—The QBE sigpath. QBE is the default. PGW creates a QBE channel controller per CTI path.

Example:

The MML command shown in the following example enables the CTI Manager on the PGW:

mml> prov-add:ctipath:name ="ctipath", desc ="CTI path", 
extnode="CCMCLUSTER", MDO="QBE"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-DLT-axlserver (Release 9.6(1))

Purpose:

This MML command lets you delete the AXL server on the PGW.

Syntax:

prov-dlt:axlserver:name="name"

Input

Description:

name—The MML name of the previously configured AXL server.

Example:

The MML command shown in the following example deletes the AXL server:

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

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-DLT-ctimgr (Release 9.6(1))

Purpose:

This MML command lets you delete the CTI Manager on the PGW.

Syntax:

prov-dlt:ctimgr:name="name"

Input

Description:

name—The MML name of the previously configured CTI Manager.

Example:

The MML command shown in the following example deletes the CTI Manager on the PGW:

mml> prov-dlt:ctimgr:name="axlserver"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-DLT-ctipath (Release 9.6(1)

Purpose:

This MML command lets you delete the CTI sigPath on the PGW.

Syntax:

prov-dlt:ctipath:name ="name"

Input

Description:

name—The MML name of the CTI Path.

Example:

The MML command shown in the following example deletes the CTI Manager on the PGW:

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

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-ED-axlserver (Release 9.6(1))

Purpose:

This MML command lets you change the state of the AXL server on the PGW.

Syntax:

prov-ed:axlserver:name="name", desc ="description", username ="username", 
password ="password"

Input

Description:

name—The MML name of the previously configured AXL server.

description—The description of the AXL server.

username—The name of the user. Can be a string up to 128 characters.

password—The password used by the user. Can be a string up to 128 characters.

Example:

The MML command shown in the following example modifies the AXL server:

mml> prov-ed:axlserver:name="axlserver", desc ="AXL server", username 
="admin", password ="cisco"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-ED-ctimgr (Release 9.6(1))

Purpose:

This MML command changes the CTI Manager on the PGW to IS/OS.

Syntax:

prov-ed:ctimgr:name="name", desc ="description", ctipath ="ctisigpath", 
ipaddr1 = "localipaddr", peeraddr1 ="ipaddress", iproute1 ="iproute1", 
username ="username", password ="password", ctiversion = "version"

Input

Description:

name—The MML name of the CTI Manager.

description—The description of the CTI Manager.

ctisigpath—The name of an existing CTI sigpath.

ipaddr1—The local IP address of the CTI Manager.

peeraddr1—The first peer address of the CTI Manager.

peeraddr2—The second peer address of the CTI Manager.

peerport—Peer CTI Manager Port.

iproute1—The name of the first IP Route.

username—The name of the user. Can be a string up to 128 characters.

password—The password used by the user. Can be a string up to 128 characters.

ctiversion—The version of the CTI Manager. Can be a string up to 128 characters.

Example:

The MML command shown in the following example enables the CTI Manager on the PGW:

mml> prov-ed:ctimgr:name="ctimgr", desc ="CTI manager 1", ctipath 
="ctisigpath", ipaddr1 = "IP_addr1", peeraddr1 ="161.44.1.1", iproute1 
="ip1", username ="admin", password ="cisco", ctiversion ="5"


Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-ED-ctipath (Release 9.6(1)

Purpose:

This MML command lets you modify the CTI sigPath on the PGW.

Syntax:

prov-dlt:ctipath:name ="name"

Input

Description:

name—The MML name of the CTI Path.

Example:

The MML command shown in the following example modifies the CTI sigPath on the PGW:

mml> prov-ed:ctipath:name ="ctipath"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-RTRV-axlserver (Release 9.6(1))

Purpose:

This MML command lets you retrieve the state of the AXL server on the PGW.

Syntax:

prov-rtrv:axlserver:name="name"

Input
Description:

name—The MML name of the previously configured AXL server.

Example:

The MML command shown in the following example retrieves the state of the AXL server:

mml> prov-rtrv:axlserver:name="axlserver"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-RTRV-ctimgr (Release 9.6(1))

Purpose:

This MML command lets you retrieve the state of the CTI Manager on the PGW.

Syntax:

prov-rtrv:ctimgr:name="name"

Input
Description:

name—The MML name of the previously configured CTI Manager.

Example:

The MML command shown in the following example retrieves the state of the CTI Manager:

mml> prov-rtrv:ctimgr:name="axlserver"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


PROV-RTRV-ctipath (Release 9.6(1)

Purpose:

This MML command lets you retrieve information of an existing CTI sigpath on the PGW.

Syntax:

prov-rtrv:ctipath:name ="name", extnode="clustername", ALL

Input

Description:

name—The MML name of the CTI Path.

clustername—The MML name of a previously defined external node.

Example:

The MML command shown in the following example retrieves information on an existing CTI sigpath on the PGW:

mml> prov-rtrv:ctipath:name ="ctipath"

Command History

Introduced in Release 9.6(1).

Comments:

Property Domain—SIGPATH

Protocol Family—CTI


Reference Information

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

XECfgParm.dat Parameters

Planning for Provisioning

Provisioning Basics

Measurements

Billing Interface

External Node Types

Properties

Provisioning Worksheets

XECfgParm.dat Parameters

The XECfgParm.dat file configuration parameters added for this feature are in the table below.

Configuration Parameter
Definition

*.IUA.maxNasExtNodes

Specifies the maximum number of external nodes that can be defined with an ISDN signaling type of IUA. This number also represents the maximum number of IUA associations that can be provisioned.

Valid value: 256


Note Do not change this value.


*.IUA.maxNasPathsPerExtNode

Defines the maximum number of NAS signaling services that can be assigned to each external node with an ISDN signaling type of IUA.

Valid value: 112


Note Do not change this value.


*.IUA.maxNasPaths

Defines the maximum number of IUA signaling services that can be provisioned.

Valid value:1500


Note Do not change this value.


*.IP_NextHop1
*.IP_NextHop2
*.IP_NextHop3
*.IP_NextHop4
*.IP_NextHop5
*.IP_NextHop6
*.IP_NextHop7
*.IP_NextHop8

Defines the IP addresses of up to eight next hop counters. These IP addresses are used when the next hop router IP addresses on the Cisco PGW hosts do not match.

Default: 0.0.0.0

Valid values: An IP address expressed in dotted decimal notation.


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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/swinstl/index.htm

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 at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

Collecting External Node Data

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

MML name

Component description

Type of the external node

ISDN signaling type

The parameters for EXTNODE are defined in Table 10.

Collecting DPNSS Path Data

The path data represents an DPNSS signaling service to a particular Cisco access gateway. See Restrictions for more information on the Cisco access gateways that require the use of a DPNSS signaling service. You must be ready to enter the following data:

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

Component description

MML name of the associated external node

Customer group ID

Identification of the DPNSS path as either A side, B side, or neither

Signaling port number (physical port on the Cisco access gateway)

Signaling port slot (physical slot on the Cisco access gateway)

The DPNSS signaling service component structure is shown in Table 13.

Collecting IP Route Data (optional)

The IP route represents a static IP route. IP routes are required for this feature only when the Cisco PGW hosts are not on the same subnet as the Cisco access gateways. If your system requires IP routes, you must be ready to enter the following data:

IP route name

Component description

Destination hostname or IP address

Subnet mask of Destination (optional)

Next hop router IP address

Local IP address

Priority

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

Collecting SCTP Association Data

The Stream Control Transmission Protocol (SCTP) association represents the connection between the Cisco MGC and a Cisco access gateway. You must be ready to enter the following data:

MML name of the SCTP association.

Description of this component.

Signaling type.

MML name of the signaling gateway process (SGP).

First local address.

Second local address (optional).

Local SCTP port number (optional).

The highest priority destination address.

The lowest priority destination address (optional).

Destination SCTP port number. (optional).

MML name of the external node.

MML name of first IPROUTE (optional).

MML name of second IPROUTE (optional).

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

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

Maximum initial timer retransmission value (optional).

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

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

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

Minimum value allowed for the retransmission timer (optional).

Maximum value allowed for the retransmission timer (optional).

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

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

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

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

The SCTP association component structure is shown in Table 15.

Provisioning Basics

Follow these procedures to start a provisioning session, to save, activate and retrieve the provisioning data.

Starting a Provisioning Session

Saving and Activating Your Provisioning Changes

Ending a Provisioning Session Without Activating Your Changes

Retrieving Provisioning Data

For more detailed information about provisioning your Cisco PGW 2200, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

Starting a Provisioning Session

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

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

Where:

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

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

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


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


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

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

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

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

There are two ways to close your provisioning session:

Saving and activating your provisioning changes, as described in Saving and Activating Your Provisioning Changes

Ending your provisioning session without saving and activating your changes, as described in Ending a Provisioning Session Without Activating Your Changes.

Saving and Activating Your Provisioning Changes

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

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

There are two ways to close your provisioning session:

Saving and activating your provisioning changes, as described in Saving and Activating Your Provisioning Changes

Ending your provisioning session without saving and activating your changes, as described in Ending a Provisioning Session Without Activating Your Changes.

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.

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

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


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


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


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


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


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


Ending a Provisioning Session Without Activating Your Changes

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

Retrieving Provisioning Data

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

Retrieving Data for an Individual Component

Retrieving Data for Select Components

Retrieving Data for All Components of a Particular Type

Retrieving Data on the Current Provisioning Session

Retrieving Data on Supported Signaling Protocols

Retrieving Data for an Individual Component

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

prov-rtrv:component:name=MML_name

Where:

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

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

For example, to view the provisioning data for an IUA signaling service called iua1, you would enter the following command:

prov-rtrv:sigsvcprop:name="iua1"

The system returns a response similar to the following:

<<get system response>>

Retrieving Data for Select Components

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

prov-rtrv:all


Note This command returns data on all signaling components, except for signaling service and linkset properties.


The system returns a response similar to the following:

<< get system response >>

Retrieving Data for All Components of a Particular Type

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

prov-rtrv:component:"all"

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

You cannot use this command for components that are used to retrieve signaling or routing properties (that is sigsvcprop, lnksetprop, and trnkgrpprop). The properties for only one signaling or routing component can be listed per command instance. Use the following format:

prov-rtrv:propComp:name="compName" | name="ss7famName"

Where:

propComp—MML component name appropriate to the property type you want to retrieve, as listed below:

sigsvcprop—Provides maintenance access to the properties of signaling services
trnkgrpprop—Provides maintenance access to the properties of trunk groups
lnksetprop—Provides maintenance access to the properties of linksets

compName—MML name of a previously provisioned signaling service or trunk group
ss7famName—MML name of the SS7 family associated with the desired linkset

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

prov-rtrv:naspath:"all"

The system returns a response similar to the following:

<< get system response >>

Retrieving Data for All Components of a Particular Type

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

prov-rtrv:component:"all"

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

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm


Note You cannot use this command for components that are used to retrieve signaling or routing properties (that is sigsvcprop, lnksetprop, and trnkgrpprop). The properties for only one signaling or routing component can be listed per command instance. Use the following format:

prov-rtrv:propComp:name="compName" | name="ss7famName"

Where:

propComp—MML component name appropriate to the property type you want to retrieve, as listed below:

sigsvcprop—Provides maintenance access to the properties of signaling services
trnkgrpprop—Provides maintenance access to the properties of trunk groups
lnksetprop—Provides maintenance access to the properties of linksets

compName—MML name of a previously provisioned signaling service or trunk group
ss7famName—MML name of the SS7 family associated with the desired linkset


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

prov-rtrv:naspath:"all"

The system returns a response similar to the following:

<< get system response >>

Retrieving Data on the Current Provisioning Session

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

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:

prov-rtrv:variants

The system returns a response similar to the following:

<< get system response >>

Measurements

Table 5 contains the system measurements that are added to support this feature. For information on the other system measurements, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/omts/index.htm

Table 5 New Operational Measurements

MML Counter Group: Name
Description
Related Components
Logging Interval

CALL:CTICBCancel

This counter is incremented each time a Call Back request cancellation comes to PGW from DPNSS or the Cisco CallManager.

 

15, 60, 24

CALL:CTICBReq

This counter is incremented each time an Call Back request comes to PGW from DPNSS or the Cisco CallManager.

 

15, 60, 24

SP:CBReqExpired

This counter is incremented each time a Call Back request from the Cisco CallManager expires from its time to live value.

 

15, 60, 24


Billing Interface

This section identifies the call detail record (CDR) data added for this feature. For billing interface information for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Billing Interface Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/billinf/index.htm

Service ID (Tag: 4221)

Table 6 `Service Activation (Tag: 4221) 

Name: SERVICE ACTIVATION

Tag: 4221

Source: MDL

 

Description/Purpose: Indicates the feature id for the supplementary service.

 

Format: Integer

Length in Octets: 1

 

Data Value:

CAll Back Request = 8

Call Back Cancellation = -9

Call Back Notification = 10

Extension Status = 11

 

ANSI/ITU Variations: None.

 

Extended Data Value: No extended value.

 

General Information: This id is the enumeration of the supplementary service performed for the call.

 

MGC Release: Release 9.6(1) and later.

 

 

Answered (1010)

Deselected (1020)

Aborted (1030)

Release (1040)

Interrupted (1050)

Ongoing (1060)

Slave Long Duration Call (1061)

Maintenance (1070)

External DB (1080)

End of Call (1110)

Slave End of Call (1111)

N

N

N

Y

N

N

N

N

N

Y

N


Components

The sections below describe the provisioning components that are added and modified for this feature. For information on the rest of the components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

New Components

The provisioning components listed in the following sections are added for this feature.

DPNSS Signaling Service

The DPNSS signaling service component type represents a DPNSS signaling path that is back-hauled over IP to/from a NAS (destination). Its MML name is DPNSSPATH.

Table 7 shows the DPNSS signaling service component structure.

Table 7 DPNSS Signaling Service Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

IP route name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to any 128 characters.

EXTNODE

External node MML name

MML name of a previously defined external node.

CUSTGRPID

Customer group ID

Four digit ID; (0000).

ABFLAG

DPNSS Side

Valid values are a (for A side), b (for B side), and n (for not applicable); (n).

SIGSLOT

Physical Slot on the NAS defining the NFAS Group (optional)

An integer, 0 through 63; (0).

SIGPORT

Physical Port on the slot of NAS defining the NFAS Groupl. (optional)

An integer, 0 through 167.


The following parameters cannot be modified:

NAME

EXTNODE

The following rules apply when you create or edit DPNSS signaling paths:

The maximum number of combined DPNSSPATHs and IUA NASPATHs per IUA external node is 112.

An ASSOCIATION must be defined with the same EXTNODE attribute as the DPNSSPATH. If this ASSOCIATION has not been defined when the DPNSSPATH is added/edited, a warning is issued. If the ASSOCIATION still has not been defined when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.

If the ASSOCIATION with the same EXTNODE value as the DPNSSPATH is deleted, a warning message is issued to inform you that the DPNSSPATH must also be deleted. If it has not been deleted when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.

IP Route

The IP route is static and it's MML name is IPROUTE.

Table 8 shows the IP route component structure.

Table 8 IPROUTE Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)

NAME

IP route name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to 128 characters in any combination.

DEST

Destination host name or IP address

IP address in decimal notation or a host name that is less than or equal to 32 characters.

NETMASK

Subnet mask of Destination (optional)

IP address in decimal notation. (255.255.255.255).

NEXTHOP

Next hop router IP address

IP address or host name that is less than or equal to 32 characters, or one of the following property names defined in XECfgParm.dat:

IP_NextHop1, IP_NextHop2, IP_NextHop8,
IP_Addr1, IP_Addr2, or IP_Addr4.

IPADDR

Local IP address

IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.

PRI

Priority

1 through 65535; (1).



Note NAME is the only parameter for this command that cannot be modified.


To create or edit IP routes, follow these rules:

The NETMASK attribute is validated by the system. For your provisioning setup to work correctly, its value (when converted to binary) must have at least one leading 1 and cannot have any trailing 1s after the first 0. The values 255.255.0.0 and 255.255.255.128 are valid. The values 0.0.255.255, 255.0.0.255, and 0.0.0.0 are invalid.

Ensure that the destination resolves to a non-zero address.

When the resolved destination address is bit ORed with the netmask value, the result is equal to the netmask. For example, a destination of 10.11.12.13 and a netmask of 255.255.0.0 are invalid because the ORed result would be 255.255.12.13, which is not equal to 255.255.0.0.

The combination of DESTINATION, NETMASK, and IPADDR must be unique for each IP route.

The combination of DESTINATION, NETMASK, and PRI must be unique for each IP route.

When an IP route is specified in a link object (for example, IPLNK, SESSIONSET, or ASSOCIATION), the IP address resolved from the PEERADDR attribute must be checked against the DESTINATION and NETMASK attributes to verify that the IPROUTE is valid.

When an IP route is specified in a link object (for example, IPLNK, SESSIONSET, or ASSOCIATION), the IPADDR must match the IPADDR of the link.

When an IPROUTE is not specified for a link object (having that option), the IP address resolved from the PEERADDR attribute must be checked against the defined IPROUTES to verify that it should not be assigned an IPROUTE. If the PEERADDR is on the same subnet as the DESTINATION (based on the NETMASK), and if the IPADDR matches the IPADDR of the link object, then use IPROUTE.

If the NEXTHOP attribute is a host name or symbolic name from XECfgParm.dat, it can resolve to the address 0.0.0.0, which indicates that the IPROUTE is not used. The IPROUTE status shows up in the rtrv-iproute:all command output when in the OOS, OFF_DUTY state.

If the resolved NEXTHOP address is not 0.0.0.0, it must be on the same subnet as the IPADDR.

The commands to retrieve the service state of an IP route can be found in Retrieving the Service State of an IP Route. The commands to set the service state of an IP route can be found in Changing the Service State of an IP Route.

SCTP Association

The SCTP association represents the connection between the Cisco MGC and a Cisco access gateway, and its MML name is ASSOCIATION.

Table 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

SGP's MML name (optional).

MML name of a previously configured SGP. Used for M3UA and SUA interfaces.

IPADDR1

First local address.

IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.

IPADDR2

Second local address (optional).

IP_Addr1, IP_Addr2, IP_Addr3, IP_Addr4, or N/A, (N/A).

PORT

Local SCTP port number (optional).

From 1024 through 65535.

Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.

PEERADDR1

The highest priority destination address.

IP address.

PEERADDR2

The lowest priority destination address (optional).

IP address; (0.0.0.0).

PEERPORT

Destination SCTP port number (optional).

From 1024 through 65535.

Defaults to 9900 for IUA.
Defaults to 2905 for M3UA.
Defaults to 14001 for SUA.

EXTNODE

External Node's MML name (optional).

MML name of a previously configured external node. Used in IUA interfaces.

IPROUTE1

MML Name of first IPROUTE (optional).

MML name of a previously configured IPROUTE.

IPROUTE2

MML Name of second IPROUTE (optional).

MML name of a previously configured IPROUTE.

RCVWIN

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

From 1500 through 65535; (18000).

MAXINITRETRANS

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

0 through 100; (10)

0 means use SCTP internal default.

MAXINITRTO

Maximum initial timer retransmission value (optional).

0, 300 through 3000 (2000).

0 means use SCTP internal default.

MAXRETRANS

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

From 1 through 10 (5).

Note This value is not to exceed MAXRETRANSDEST * the number of destinations.

CUMSACKTO

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

From 100 through 500 ms; (300).

BUNDLETO

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

From 100 through 600 ms; (100).

MINRTO

Minimum value allowed for the retransmission timer (optional).

From 300 through 3000 ms; (300).

MAXRTO

Maximum value allowed for the retransmission timer (optional).

From 1000 through 3000 ms; (3000).

HBTO

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

The value can be 0, or from 300 through 10000 ms; (2000).

0 means disabled.

IPPRECEDENCE

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

ROUTINE 000
PRIORITY 001
IMMEDIATE 010
FLASH 011
FLASH-OVERRIDE 100
CRITICAL 101
INTERNET 110
NETWORK; (ROUTINE) 111

DSCP

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

EF 101110—Expedited Forwarding


AF11 001010—Assured Forwarding
Class 1 Low Drop Precedence


AF12 001100—Assured Forwarding
Class 1 Medium Drop Precedence


AF13 001110—Assured Forwarding
Class 1 High Drop Precedence


AF21 010010—Assured Forwarding
Class 2 Low Drop Precedence


AF22 010100—Assured Forwarding 2
Medium Drop Precedence


AF23 010110—Assured Forwarding
Class 2 High Drop Precedence


AF31 011010—Assured Forwarding
Class 3 Low Drop Precedence


AF32 011100—Assured Forwarding
Class 3 Medium Drop Precedence


AF33 011110—Assured Forwarding
Class 3 High Drop Precedence


AF41 100010—Assured Forwarding
Class 4 Low Drop Precedence


AF42 100100—Assured Forwarding
Class 4 Medium Drop Precedence


AF43 100110—Assured Forwarding
Class 4 High Drop Precedence
N/A; (N/A)

MAXRETRANSDEST

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

From 1 through 10; (3).


Table 9 shows the SCTP association component structure.

The following parameters cannot be modified:

NAME

EXTNODE

TYPE

SGP

To create or edit SCTP associations, follow these rules:

Only one association with a type of IUA can be assigned to an external node.

If the type of the association is IUA, the associated external node must have its ISDN signaling type set to IUA, and that external node must be able to support IUA signaling.

If two associations have the same port value, the values of IPADDR1 and IPADDR2 must either be the same or both must be different.

The values of IPADDR1 and IPADDR2 must be different.

If the value of IPPRECEDENCE is not ROUTINE, the value of DSCP must be N/A.

If the value of DSCP is not N/A, the value of IPPRECEDENCE must be ROUTINE.

The value of MAXRTO must be greater than or equal to the value of MINRTO.

When a peer IP address (PEERADDR1 or PEERADDR2) is not on the local subnet of IPADDR1 or IPADDR2, that peer IP address cannot be on the subnet of any other local interface, even if it is not defined within the Cisco MGC software.

When a peer IP address (PEERADDR1 or PEERADDR2) is not on the local subnet of IPADDR1 or IPADDR2, an IP route (IPROUTE1 or IPROUTE2, respectively) must be specified.

When an IP route is specified, the values set in PEERADDR1 and PEERADDR2 are checked against the DESTINATION and NETMASK values of the IP route(s) to verify that the IP route is valid.

When an IP route is specified, its value for IPADDR must match the related IP address of the association. In other words, IPROUTE1 should have an IPADDR that matches IPADDR1 on the association, and IPROUTE 2 should have an IPADDR that matches IPADDR2 on the association.

When an IP route is not specified, the IP address resolved from the PEERADDR1 or PEERADDR2 parameter is checked against the defined IP routes to verify that it should not be assigned to one of those IP routes. If the peer address is on the same subnet as an IP route, the link should use that IP route.

The value of PEERADDR1 cannot be 0.0.0.0 or 255.255.255.255, and the value of PEERADDR2 cannot be 255.255.255.255.

When a host name is specified for a peer IP address, the host name must resolve to an IP address.

PEERADDR1 and PEERADDR2 can resolve to the same IP address. If the external node has only one IP address and two IP addresses (IPADDR1 and IPADDR2) are defined, PEERADDR2 should be set to the same value as PEERADDR1.

Associations, session sets, IP links, SIP links, and SS7 signaling gateway links that share a peer address (that is, PEERADDR, PEERADDR1, or PEERADDR2) must be assigned directly or indirectly to the same external node.

When you are deleting an association and a NASPATH uses the same external node, a warning message is issued to inform you that the NASPATH must also be deleted. If it has not been deleted when the provisioning session is copied or deployed, an error message is generated and the copy or deployment stops.

The value of PORT cannot be set to the same value as the PORT attribute of any IP link, session set, SIP link, or SS7 signaling gateway link.

If a value for IPADDR2 or PEERADDR2 is specified, values for IPADDR1 and PEERADDR1 must also be specified. In other words, you cannot have one local address and two remote addresses, or two local addresses and one remote address.

An IP link, session set, SS7 signaling gateway link, or another association with a different external or signaling gateway node cannot use the resolved value set in PEERADDR1 or PEERADDR2.

Only one association can be defined to an SS7 signaling gateway process (SGP).

A value for EXTNODE can be defined only when the association type is IUA.

A value for SGP can be defined only when the association type is M3UA or SUA.

The maximum number of associations with a type of M3UA is defined in the XECfgParm.dat parameter, M3UA.maxSgp.

The maximum number of associations with a type of SUA is defined in the XECfgParm.dat parameter, SUA.maxSgp.

The commands to retrieve the service state of an IP route can be found in Retrieving the Service State of an IP Route. The commands to set the service state of an IP route can be found in Changing the Service State of an IP Route.

Modified Components

The following components are modified for this feature.

External Node

The external node component type represents another node with which the MGC communicates. Its MML name is EXTNODE.

The parameters for EXTNODE are defined in Table 10.

Table 10 External Node Component Structure 

Parameter MML Name
Parameter Description
Parameter Values (Default)
NAME

MML name

The name can be as many as 20 alphanumeric characters. No special characters other than "-" are allowed. The name should begin with a letter.

DESC

Component description

The description can be up to 128 characters.

TYPE

The type of the external node

Valid values can be found in External Node Types.

ISDNSIGTYPE

ISDN Signaling Type

Valid values are IUA and N/A (default is N/A). This parameter was added in software Release 9.4(1)T.

GROUP

M3UA/SUA Group Number

Value is 1-100 for M3UA or SUA nodes. Value is 0 for nodes that do not support M3UA or SUA. This parameter was added in software Release 9.4(1)T.



Note DESC is the only parameter for this command that can be modified:


The following rules apply when creating/editing external nodes:

TYPE must be one of the valid external node types.

The maximum number of external nodes with an ISDNSIGTYPE of IUA is 256.

External Node Types

Table 11 lists the valid external node types for Release 9.6(1) of the Cisco MGC software.

.

Table 11 External Node Types for Cisco MGC Software Release 9.6(1) 

ExtNode MML Type
SGCP
MGCP
IPFAS
IUA
BRI
NAS
MGCP
ANNO
MGCP
IVR
SUA
Other

AS5200

 

 

IPFAS

 

 

NAS

 

 

 

 

AS5300

SGCP

MGCP

IPFAS

IUA

 

NAS

MGCP
ANNO

MGCP
IVR

 

 

AS5350

SGCP

MGCP

IPFAS

IUA

 

NAS

MGCP
ANNO

MGCP
IVR

 

BSMV0

AS5400

SGCP

MGCP

IPFAS

IUA

 

NAS

MGCP
ANNO

MGCP
IVR

 

BSMV0

AS5800

 

 

IPFAS

 

 

NAS

MGCP
ANNO

 

 

 

AS5850

 

MGCP

IPFAS

IUA

 

NAS

MGCP
ANNO

MGCP
IVR

 

 

AS7200

SGCP

MGCP

IPFAS

 

 

NAS

 

 

 

 

C1751

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C1760

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2600

SGCP

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2610XM

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2611XM

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2620XM

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2621XM

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2650XM

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2651XM

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C2691

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C3600

SGCP

MGCP

IPFAS

 

 

 

 

 

 

 

C3640

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C3640A

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C3660

SGCP

MGCP

IPFAS

IUA

BRI

NAS

 

 

 

 

C3725

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

C3745

 

MGCP

IPFAS

IUA

BRI

 

 

 

 

 

CAT8510

SGCP

MGCP

 

 

 

 

 

 

 

 

CAT8540

SGCP

MGCP

 

 

 

 

 

 

 

 

CCMCLUSTER

                   

H323

 

 

 

 

 

 

 

 

 

EISUP

ITP

 

 

 

 

 

 

 

 

SUA

M3UA

LIMD

 

 

 

 

 

 

 

 

 

LI

LS1010

SGCP

MGCP

 

 

 

 

 

 

 

 

MC3810

 

MGCP

IPFAS

 

 

 

 

 

 

 

MGC

 

 

 

 

 

 

 

 

 

EISUP

MGX8260

 

MGCP

IPFAS

 

 

NAS

 

 

 

 

MGX8850

SGCP

MGCP

 

 

 

 

 

 

 

 

SCP

 

 

 

 

 

 

 

 

 

TCAPIP

SLT

 

 

 

 

 

 

 

 

 

BSMV0

TALISS7

 

 

 

 

 

 

 

 

 

SS7SG

UNKNOWN

 

 

 

 

 

 

 

 

 

UNKNOWN

VISM

SGCP

MGCP

IPFAS

 

 

 

 

 

 

 

VXSM

SGCP

MGCP

IPFAS

 

 

 

 

 

 

 


Properties

New properties have been added to MML commands:

CallBackDBCleanUpTimer

MaxCBRequest

TimeOutCBNU

TimeOutCBWF

CallBackDBCleanUpTimer

Purpose:

This property defines the timeout value for Call Back DB cleanup in milliseconds.

Valid Values:

600000-10800000 (10 minutes to 3 hours)

Default Value:

3600000 (1 hour)

Domain:

_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)

Example:

mml>prov-ed:sigsvcprop:name="stisigpath", MaxCBRequest ="9"

MaxCBRequest

Purpose:

This property defines the maximum number of Call Back requests allowed in the queue per CTI sigpath.

Valid Values:

1-50

Default Value:

10

Domain:

_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)

Example:

mml>prov-ed:sigsvcprop:name="stisigpath", MaxCBRequest ="9"

TimeOutCBNU

Purpose:

This property defines the timeout value for Call Back When Not Used against QBE sigpath measured in minutes.

Valid Values:

60-480

Default Value:

480

Domain:

_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)

Example:

mml>prov-ed:sigsvcprop:name="ctisigpath", TimeOutCBNU ="200"

TimeOutCBWF

Purpose:

This property defines the timeout value for Call Back When Free against QBE sigpath measured in minutes.

Valid Values:

60-180

Default Value:

180

Domain:

_XE Parameter _X_SigPath _LinkSet X_Trunk Group _MGC (Choose one)

Example:

mml>prov-ed:sigsvcprop:name="ctisigpath", TimeOutCBWF = "100"

Provisioning Worksheets

This section contains worksheets for the provisioning components required for this feature. For worksheets covering the rest of the provisioning components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/prvgde/index.htm

Table 12 External Node Worksheet Example  

Name
Type
ISDN Signaling Type
Group
Description

va-3600-37

AS3600

iua

 

DPNSS conn to va-3600-37

         
         
         
         
         
         
         
         
         

Table 13 DPNSS Signaling Service Worksheet Example  

Name
External Node
Customer Group ID
DPNSS Side
Signaling Port
Signaling Slot
Description

dpnsvc2

va-3660-20

 

A

0

0

IUA DPNSSpath to GW

             
             
             
             
             
             
             
             
             

Table 14 IP Route Worksheet Example (optional) 

Name
Destination
Subnet Mask
Next Hop
IP Address
Priority
Description

iproute1

va-3600-37

255.255.255.0

va-3600-36

175.25.211.17

1

IP route to va-3600-37

             
             
             
             
             
             
             
             
             

Table 15 SCTP Association Worksheet Example 

Parameter
Parameter Value

Name

nasassoc1

         

Description

DPNSS IUA association 1

         

Signaling type

IUA

         

SGP name

           

First local address

IP_Addr1

         

Second local address (optional)

IP_Addr2

         

Local SCTP port number (optional)

           

Highest priority destination address

10.82.80.30

         

Lowest priority destination address (optional)

10.82.81.30

         

Destination SCTP port number (optional)

           

External node name

va-3600-37

         

First IP route name (optional)

iprte1

         

Second IP route name (optional)

iprte2

         

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

           

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

           

Maximum initial timer retransmission value (optional)

           

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

           

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

           

Maximum time SCTP will wait for other outgoing datagrams for bundling (optional)

           

Minimum value allowed for the retransmission timer (optional)

           

Maximum value allowed for the retransmission timer (optional)

           

Time between heartbeats (optional)

           

IP precedence (optional)

           

Differential Service Code Point (optional)

           

Maximum number of retransmissions to peer address 1 or 2 before it is declared failed (optional)

           

Obtaining Documentation

Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation on the World Wide Web at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:

http://www.cisco.com

International Cisco websites can be accessed from this URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated regularly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual or quarterly subscription.

Registered Cisco.com users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool:

http://www.cisco.com/en/US/partner/ordering/ordering_place_order_ordering_tool_launch.html

All users can order annual or quarterly subscriptions through the online Subscription Store:

http://www.cisco.com/go/subscription

Click Subscriptions & Promotional Materials in the left navigation bar.

Ordering Documentation

You can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/en/US/partner/ordering/index.shtml

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

You can submit e-mail comments about technical documentation to bug-doc@cisco.com.

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour-a-day, award-winning technical support services, online and over the phone. Cisco.com features the Cisco TAC website as an online starting point for technical assistance. If you do not hold a valid Cisco service contract, please contact your reseller.

Cisco TAC Website

The Cisco TAC website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year. The Cisco TAC website is located at this URL:

http://www.cisco.com/tac

Accessing all the tools on the Cisco TAC website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:

http://tools.cisco.com/RPF/register/register.do

For P1 or P2 cases (your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.

To open a case by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

For a complete listing of Cisco TAC contacts, go to this URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

Opening a TAC Case

Using the online TAC Case Open Tool is the fastest way to open P3 and P4 cases. (P3 and P4 cases are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using the recommended resources, your case will be assigned to a Cisco TAC engineer. The online TAC Case Open Tool is located at this URL:

http://www.cisco.com/tac/caseopen

For P1 or P2 cases (P1 and P2 cases are those in which your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.

To open a case by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

For a complete listing of Cisco TAC contacts, go to this URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

TAC Case Priority Definitions

To ensure that all cases are reported in a standard format, Cisco has established case priority definitions.

Priority 1 (P1)—Your network is "down" or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Priority 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Priority 3 (P3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Priority 4 (P4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:

http://www.cisco.com/en/US/products/products_catalog_links_launch.html

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press online at this URL:

http://www.ciscopress.com

Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/packet

iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:

http://www.cisco.com/go/iqmagazine

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html

Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:

http://www.cisco.com/en/US/learning/index.html

Glossary

Table 16 contains definitions of acronyms and technical terms used in this feature module.

Table 16 Glossary 

Term
Definition

ANSI

American National Standards Institute

CIC

Carrier Identification Code

DPNSS

Digital Private Network Signaling System. A PBX standard developed in the United Kingdom.

EISUP

Extended ISDN User Part. A proprietary protocol used to communicate between Cisco MGC nodes and between a Cisco MGC node and a Cisco H.323 System Interface.

I/O

Input/Output

IOCC

Input/Output channel controller

IOCM

Input/Output Channel Controller Manager

ISDN

Integrated Services Digital Network

ISUP

ISDN User Part

ITU

International Telecommunication Union

IUA

ISDN Q.921 User Adaptation Layer

LNP

Local Number Portability

M3UA

Message Transfer Point Level 3 User Adaptation

MGC

Media Gateway Controller

MGCP

Media Gateway Control Protocol

MIB

Management Information Base

MML

Man-Machine Language

MTP3

Message Transfer Part Level 3

NAS

Network access server

NFAS

Non-Facility Associated Signaling

PSTN

Public switched telephone network

Q.931

ITU document that defines the ISDN connection control protocol.

Q.921

ITU document that defines the data link protocol used on an ISDN D-channel. Also known as Link Access Protocol - D Channel (LAPD).

RFC

Request For Comments. A proposed standards document. There are RFCs for both IUA and SCTP.

RLM

Redundant Link Manager. A proprietary protocol used for the transport of Q.931 data between a Cisco MGC host and an associated media gateway.

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