Guest

Cisco PGW 2200 Softswitch

Support of QSIG/Q.931 Over BRI Backhaul

  • Viewing Options

  • PDF (744.4 KB)
  • Feedback
Support for QSIG Over BRI and Q.931 Over BRI Backhaul

Table Of Contents

Support for QSIG Over BRI and Q.931 Over BRI Backhaul

Feature Overview

Benefits

Restrictions

Related Features

Software Structural Changes

Changes to Cisco MGC Software Architecture

Input/Output Subsystem

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites for Using This Feature

Configuration Tasks

Provisioning Tasks

Provisioning Prerequisites

Collecting External Node Data

Collecting MGCP Path Data

Collecting MGCP Path Property Data

Collecting QSIG/Q.931 Over BRI Backhaul Path Data

Collecting IP Route Data (optional)

Collecting Backhaul TCP Link Data

Collecting MGCP IP Link Data

Collecting D-Channel Data

Provisioning Procedures

Provisioning Basics

Adding QSIG/Q.931 Over BRI Backhaul Connections

Modifying QSIG/Q.931 Over BRI Backhaul Components

Deleting QSIG/Q.931 Over BRI Backhaul Components

Troubleshooting Provisioning Data

Alarm Troubleshooting Procedures

Signaling Channel Troubleshooting Procedures

Rebooting Software to Modify Configuration Parameters

Monitoring and Maintaining the Feature

Managing Signaling Channels

Retrieving Signaling Service States

Retrieving the Service State for IP Routes

Retrieving the Service State of D-Channels

Retrieving the Service State for IP Links

Valid Service States

Configuration Examples

Provisioning Examples

Command Reference

Modified MML Commands

RTRV-DCHAN—Display Primary and Secondary States of a D-Channel

RTRV-DEST—Display Primary and Secondary States of a Destination

RTRV-IPLNK—Display Primary and Secondary States of an IP Link

SET-DCHAN—Change Service State of a D-Channel

SET-DEST—Change Service State of a Destination

Reference Information

XECfgParm.dat Parameters

Alarms

New Alarms

Components

New Components

Modified Components

Properties

External Node Types

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


Support for QSIG Over BRI and Q.931 Over BRI Backhaul


Document Release History

Publication Date
Comments

October 8, 2004

Initial version of the document.

May 17, 2005

Added information for determining the Cisco IOS software image and platform associated with this feature.


Feature History

Release
Modification

Release 9.5(2)

This feature was introduced in this release.


This document describes the Support for Q Signaling (QSIG) Over Basic Rate Interface (BRI) and Q.931 Over BRI Backhaul feature. This feature is described in the following sections:

Feature Overview

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites for Using This Feature

Configuration Tasks

Provisioning Tasks

Monitoring and Maintaining the Feature

Configuration Examples

Provisioning Examples

Command Reference

Reference Information

Obtaining Documentation

Documentation Feedback

Obtaining Technical Assistance

Obtaining Additional Publications and Information

Glossary

Feature Overview

This feature provides support on the Cisco Media Gateway Controller (MGC) for QSIG over BRI and Q.931 over BRI backhauling. This feature supports two BRI protocols, QSIG and Q.931. The Cisco MGC can now backhaul layer 3 QSIG/Q.931 messages over a TCP session. TCP is required for internetworking with BRI voice gateways.

Benefits

This feature provides the benefit described below.

Expansion of User Application

With the addition of support for QSIG over BRI and Q.931 over BRI backhauling, the Cisco MGC can now be used to control calls for BRI voice gateways connected to QSIG private branch exchanges (PBXs). This adds to the existing functionality that enables the Cisco MGC to control calls for Primary Rate Interface (PRI) voice gateways connected to QSIG PBXs.

Restrictions

Enabling this feature provides a data pathway for the backhaul of QSIG/Q.931 messages from a Cisco BRI voice gateway to the MGC. An MGCP data pathway must also be defined between the Cisco BRI voice gateway and the MGC to form a complete duplex data pathway.

This feature can be used only with the following Cisco BRI voice gateways:

Cisco 1751

Cisco 1760

Cisco 2600

Cisco 2610XM

Cisco 2611XM

Cisco 2620XM

Cisco 2621XM

Cisco 2650XM

Cisco 2651XM

Cisco 2691

Cisco 3640

Cisco 3640A

Cisco 3660

Cisco 3725

Cisco 3745


Tip Use the Cisco Feature Navigator to determine which Cisco IOS software image supports the MGCP-Controlled Backhaul of BRI Signaling feature on your platform. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.


Related Features

The following features are related to this feature:

MGCP-Controlled Backhaul of BRI Signaling (for the Cisco voice gateways)

Support for QSIG Transparency feature (for the Cisco MGC)

Software Structural Changes

This section describes the structural changes to the MGC software for this feature. For information on the structure of the rest of the MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.

Changes to Cisco MGC Software Architecture

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

Input/Output Subsystem

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

The IOCM manages all IOCCs and monitors the hardware resource states of the hardware controlled by the IOCCs.

The IOCCs provide

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

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

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

Basic Rate Interface (BRI)—Added in Release 9.5, this IOCC enables the backhaul of layer 3 QSIG and Q.931 messages in a TCP session. This IOCC is used between a Cisco MGC and voice gateways that support BRI signaling backhaul.

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

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

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

Media Gateway Control Protocol (MGCP)—Enables communication with media gateways and trunking gateways, making possible the setting up of bearer channel connections used in Cisco MGC systems configured for call control environments.

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

Q.931+—A stateless IOCC, for a Cisco-proprietary protocol, which is a special version of ISDN that enables forward hauling of Q931+ signaling to a media gateway used with a Cisco MGC configured for signaling environments.

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

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

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

Related Documents

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:

Release notes for Cisco Media Gateway Controller Software Release 9.5(2)

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

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 MML Command Reference

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

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

Supported Platforms

The hardware platforms that support the Cisco MGC software are described in the Cisco Media Gateway Controller Hardware Installation Guide.

Supported Standards, MIBs, and RFCs

Standards

No standards are associated with this feature.

MIBs

No new or modified MIBs are supported by this feature. Existing MIBs are used to support this feature. For more information on the MIBs used in the Cisco MGC software, refer to the Cisco Media Gateway Controller Release 9 Management Information Base Guide.

RFCs

No RFCs are associated with this feature.

Prerequisites for Using This Feature

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

The Support for ISDN BRI over TCP IOS feature module contains information on the prerequisites for the implementation of this feature for Cisco media gateways.

Configuration Tasks

Implementation of this feature does not require modification of the associated XECfgParm.dat parameters. Modification of the default values for these parameters is required only in response to troubleshooting problems.

Provisioning Tasks

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

Provisioning Prerequisites

Provisioning Procedures

Troubleshooting Provisioning Data

Provisioning Prerequisites

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

Collecting External Node Data


Note If your network supports both PRI and BRI backhaul signaling, we recommend that you maintain the PRI and BRI interfaces on different media gateways. PRI singling backhaul configurations typically use redundant links between the Cisco MGC and the media gateway, and BRI signaling backhaul configurations use a single link between the Cisco MGC and the media gateway.

If you decide to configure PRI and BRI signaling backhaul on the same media gateway, we recommend that you use a single link between the media gateway and the Cisco MGC for both. If you do not remove a link from your PRI signaling backhaul provisioning, and one of those links should fail and be restored, you will need to set the service state of the related MGCP signaling service to OOS, and then set it to IS to restore both links to service.


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

MML name

Component description

The type of the external node

ISDN signaling type

You can define the parameters for your external nodes in Table 9 in the "Provisioning Worksheets" section.

Collecting MGCP Path Data

The MGCP component type represents a MGCP signaling service to a particular Cisco voice gateway. Refer to the "Restrictions" section for more information on the Cisco media gateways that can be used to setup this feature. You must be ready to enter the following data:

MML name

Component description

MML name of the associated external node

You can define the parameters for your MGCP signaling services in Table 10 in the "Provisioning Worksheets" section.

Collecting MGCP Path Property Data

This component type represents properties for an existing MGCP signaling service. All of the MGCP signaling service properties have default values. You must be ready to enter data for the properties you are going to modify. For information on all of the MGCP signaling service properties, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

You can define the new values for the trunk group properties in Table 11 in the "Provisioning Worksheets" section.

Collecting QSIG/Q.931 Over BRI Backhaul Path Data

The QSIG/Q9.31 over BRI Backhaul component type represents an QSIG/Q.931 over BRI Backhaul signaling service to a particular Cisco BRI voice gateway. Refer to the "Restrictions" section for more information on the Cisco media gateways that can be used for this feature. You must be ready to enter the following data:

MML name

Component description

MML name of the associated external node

Q.931 call model side (user or network)

MDO file name (ETS_300_102, Q931, or ETS_300_172)

Customer group ID

Customer group table

Call reference length (0 through 2 bytes)


Note If you are using the ETS_300_102 or Q931 protocol files, call reference should be set to 1. If you are using the ETS_300_172 protocol file, call reference should be set to 2.


You can define the parameters for your QSIG/Q.931 over BRI Backhaul signaling services in Table 12 in the "Provisioning Worksheets" section.

Collecting IP Route Data (optional)

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

MML name

Component description

Destination host name or IP address

Subnet mask of destination (optional)

Next hop router IP address

Local IP address

Priority

You can define the parameters for your IP routes in Table 13 in the "Provisioning Worksheets" section.

Collecting Backhaul TCP Link Data

The Backhaul TCP link component type represents the connection between the Cisco MGC and a Cisco BRI voice gateway. You must be ready to enter the following data:

MML name

Description of this component

Signaling type (BRI)

Local IP address

Local port number

Destination IP address

Destination port number

MML name of the external node

MML name of first IPROUTE (optional)

You can define the parameters for your Backhaul TCP links in Table 14 in the "Provisioning Worksheets" section.

Collecting MGCP IP Link Data

This component type represents a link to an MGCP device. You must be ready to enter the following data:

MML name

Component description

Port

Priority

IP address (must match the IP address selected for the Backhaul TCP links)

Associated MGCP signaling service

You can define the parameters for your MGCP IP links in Table 15 in the "Provisioning Worksheets" section.

Collecting D-Channel Data

The BRI Backhaul over TCP component type represents the connection between the Cisco MGC and a Cisco BRI voice gateway. You must be ready to enter the following data:

MML name

Description of this component

Signaling type

Priority

MML name of associated Backhaul TCP link

Physical slot number on voice gateway

Physical port number for slot on voice gateway

Local subunit

You can define the parameters for your QSIG/Q9.31 over BRI Backhaul D-channels in Table 16 in the "Provisioning Worksheets" section.

Provisioning Procedures

This section covers the following provisioning topics:

Provisioning Basics

Adding QSIG/Q.931 Over BRI Backhaul Connections

Modifying QSIG/Q.931 Over BRI Backhaul Components

Deleting QSIG/Q.931 Over BRI Backhaul Components

Provisioning Basics

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

Starting a Provisioning Session

Saving and Activating Your Provisioning Changes

Ending a Provisioning Session Without Activating Your Changes

Retrieving Provisioning Data

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

Starting a Provisioning Session

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

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

Where:

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

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

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


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


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

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

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

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

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

Saving and Activating Your Provisioning Changes

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


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

The prov-cpy MML command is used to save and activate your changes on simplex Cisco MGC (single host) systems.


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



Caution Do not use the prov-cpy command to save and activate your changes on a continuous-service Cisco MGC system (one with active and standby hosts). Saving and activating using prov-cpy on such a system would require using the prov-sync MML command to synchronize the provisioning data on the active and standby hosts. The system does not indicate when the synchronization process fails, which would create problems for any future switchover operations.

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


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


Ending a Provisioning Session Without Activating Your Changes

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

Retrieving Provisioning Data

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

Retrieving Data for an Individual Component

Retrieving Data for All Components

Retrieving Data for All Components of a Particular Type

Retrieving Data on the Current Provisioning Session

Retrieving Data on Supported Signaling Protocols

Retrieving Data for an Individual Component

You can retrieve provisioning data for any individual component of 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.

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

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

prov-rtrv:ss7path:name="ss7svc1"

The response to the command is dependent upon the component type associated with the desired component.

Retrieving Data for All Components

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

prov-rtrv:all

Retrieving Data for All Components of a Particular Type

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

prov-rtrv:component:"all"

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

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

prov-rtrv:ss7path:"all"

Retrieving Data on the Current Provisioning Session

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

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

Adding QSIG/Q.931 Over BRI Backhaul Connections

This section contains the procedures that you must perform to add QSIG/Q.931 over BRI backhaul connections to your Cisco MGC provisioning data. When provisioning the components that enable the Cisco MGC to support QSIG/Q.931 over BRI backhaul, perform the procedures in the following order:

Ensuring Proper Cisco ISDN Voice Gateway Configuration

Adding Cisco BRI Voice Gateway External Nodes

Adding MGCP Signaling Services

Adding QSIG/Q.931 Over BRI Backhaul Signaling Services

Adding IP Routes (Optional)

Adding Backhaul TCP Links

Adding MGCP IP Links

Adding QSIG/Q.931 Over BRI Backhaul D-Channels

Ensuring Proper Cisco ISDN Voice Gateway Configuration

For this feature to work properly, the connected Cisco ISDN BRI voice gateway must be configured such that the switchback function is disabled. This prevents the voice gateway from automatically reconnecting with the active Cisco MGC. The switchback function is disabled using the following command:

Gateway(config)#ccm-manager switchback never

Refer to the documentation for your voice gateway for more information.

Proceed to the "Adding Cisco BRI Voice Gateway External Nodes" section.

Adding Cisco BRI Voice Gateway External Nodes


Note If your network supports both PRI and BRI backhaul signaling, we recommend that you maintain the PRI and BRI interfaces on different media gateways. PRI signaling backhaul configurations typically use redundant links between the Cisco MGC and the media gateway, and BRI signaling backhaul configurations use a single link between the Cisco MGC and the media gateway.

If you decide to configure PRI and BRI signaling backhaul on the same media gateway, we recommend that you use a single link between the media gateway and the Cisco MGC. If you do not remove a link from your PRI signaling backhaul provisioning, and one of those links should fail and be restored, you will need to set the service state of the related MGCP signaling service to OOS, and then set it to IS to restore both links to full functioning.


To add Cisco media gateway external nodes to your provisioning data, perform the following steps:


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

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

mml>prov-add:extnode:name="name", desc="description", type="as", isdnsigtype="na"

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—An assigned name. It can be as many as 128 alphanumeric characters in length.

as—The MML name for the type of Cisco BRI voice gateway. The valid values are as follows:

C1751

C1760

C2600

C2610XM

C2611XM

C2620XM

C2621XM

C2650XM

C2651XM

C2691

C3640

C3640A

C3660

C3725

C3745

For example, to add a Cisco BRI voice gateway external node named va-3640-01, enter the following command:

mml>prov-add:extnode:name="va-3640-01", desc="BRI 3640", type="C3640", isdnsigtype="na"

Step 3 Repeat Step 2 for each Cisco BRI voice 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 the "Saving and Activating Your Provisioning Changes" section.

Otherwise, proceed to the "Adding MGCP Signaling Services" section.


Adding MGCP Signaling Services

To add MGCP signaling services to your provisioning data, perform the following steps:


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

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

mml>prov-add:mgcppath:name="name", desc="description", extnode="mgw"

Where:

name—The name you want to give to the MGCP 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—An assigned name. It can be as many as 128 alphanumeric characters in length.

mgw—MML name of a previously defined voice gateway external node.

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

mml>prov-add:mgcppath:name="mgcpsvc1",extnode="bri-3640-01",desc="MGCP service to C2600"

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

If you need to modify the settings of the properties for your MGCP signaling service, perform the procedure in the "Modifying MGCP Signaling Service Properties" section and return here.

Otherwise, proceed to the "Adding QSIG/Q.931 Over BRI Backhaul Signaling Services" section.


Adding QSIG/Q.931 Over BRI Backhaul Signaling Services

To add QSIG/Q.931 over BRI Backhaul signaling services to your provisioning data, perform the following steps:


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

Step 2 Enter the following command to add an QSIG/Q.931 over BRI Backhaul signaling service:

mml>prov-add:bripath:name="name", desc="description", extnode="mgw", mdo=variant, 
side=qside, custgrpid="idnum", crlen="callref"

Where:

name—The name you want to give to the QSIG/Q.931 over BRI Backhaul 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—An assigned name. It can be as many as 128 alphanumeric characters in length.

mgw—MML name of a previously defined QSIG/Q.931 BRI voice gateway external node.

variant—MDO filename, from the following list:

ETS_300_102

Q931

ETS_300_172

qside—Q.931 call model side, user for user side and network for network side; (network).

idnum—VNET ID, a four-digit ID; (0000).

callref—Call reference length; Valid values: 0 through 2. The value indicates the number of bytes in the call reference length (0).


Note If you are using the ETS_300_102 or Q931 protocol files, call reference should be set to 1. If you are using the ETS_300_172 protocol file, call reference should be set to 2.


For example, to add an QSIG/Q.931 over BRI Backhaul signaling service named brisvc1, you would enter the following command:

mml>prov-add:bripath:name="brisvc1",extnode="bri-3640-01",desc="BRI service to C2600", 
mdo="ETS_300_172",side="network", custgrpid="V123", crlen="2"


Note Up to 2000 QSIG/Q.931 over BRI Backhaul signaling services can be provisioned on your
Cisco MGC.


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

Otherwise, you have two choices:

Proceed to the "Adding IP Routes (Optional)" section if your Cisco MGC is on a different subnet from the associated BRI voice gateway

Proceed to the "Adding Backhaul TCP Links" section if they are on the same subnet.


Adding IP Routes (Optional)

IP routes are required in your provisioning data if your Cisco MGC hosts are not on the same subnet as the Cisco media 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 the "Starting a Provisioning Session" section.

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

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

Where:

name—The name you want to give to the 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—An assigned name. 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 host name, 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 host name must be less than or equal to 32 characters.

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

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

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

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

Otherwise, proceed to the "Adding Backhaul TCP Links" section.


Adding Backhaul TCP Links

To add Backhaul TCP links to your provisioning data, perform the following steps:


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

Step 2 Enter the following command to add a Backhaul TCP link:

mml>prov-add:tcplink:name="name", desc="description", type="BRI", ipaddr="addr", 
port="pnum", peeraddr="paddr1", peerport="ppnum", extnode="gway", iproute1="iprte1"

Where:

name—The name you want to give to the Backhaul TCP link. 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—An assigned name. It can be as many as 128 alphanumeric characters in length.

addr—Local IP address, as defined by the one of the following XECfgParm.dat parameters:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4


Note The local IP address selected here must match the value for the MGCP IP link.


pnum—Port number, an integer from 1024 to 65,535.


Note Only two combinations of local IP address and port number can be used per Cisco MGC. Once you have identified two unique local IP address and port number combinations, all subsequent Backhaul TCP links must use one of those combinations.


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

ppnum—Destination port number, an integer from 1024 to 65,535.

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

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

For example, to add a Backhaul TCP link named britcp1, enter the following command:

mml>prov-add:tcplink:NAME="britcp1",DESC="BRI TCP link 1", TYPE="BRI", IPADDR="IP_Addr1", 
PORT="1024", PEERADDR="10.82.80.187", PEERPORT="1024", extnode="va-3640-01, 
IPROUTE="iprte1"

Step 3 Repeat Step 2 for each Backhaul TCP link you want to add to your provisioning data.

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

Otherwise, proceed to the "Adding MGCP IP Links" section.


Adding MGCP IP Links

To provision MGCP IP links, perform the following steps:


Step 1 Enter the following command to provision a MGCP IP link:

mml>prov-add:iplnk:name="name", desc="description", ipaddr="addr1", peeraddr="addr2", 
svc="sigsrv", port=lpnum, peerport=rpnum, iproute1="iprte1", pri=priority

Where:

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

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

addr1—Local IP address for a LAN/WAN interface. IP address should be one of the following property names defined in the XECfgParm.dat file:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4


Note The local IP address selected here must match the value for the Backhaul TCP link.


addr2—Remote IP address, expressed in dotted decimal format. This value may also be specified as a host name or a DNS name.

sigsrv—The MML name of a previously provisioned MGCP signaling service.

lpnum—Local IP port number. Valid value is any integer above 1024. For MGCP IP links, we recommend that you use 2427.

rpnum—Remote IP port number. Valid value is any integer above 1024. For MGCP IP links, we recommend that you use 2427.

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

priority—Priority setting for this MGCP IP link. Valid value is any integer above 0. Default value is 1.

For example, to provision a MGCP IP link, you would enter the following command:

mml>prov-add:splnk:name="mgcpsigchan1", ipaddr="IP_Addr1", peeraddr="147.28.210.65", 
svc="mgcpsvc1", port=2427, peerport=2427, iproute1=iproute1, pri=1, desc="MGCP sigchan 1"

Step 2 Repeat Step 1 for each MGCP IP link you want to provision.

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

Otherwise, proceed to the "Adding QSIG/Q.931 Over BRI Backhaul D-Channels" section.


Adding QSIG/Q.931 Over BRI Backhaul D-Channels

To add QSIG/Q.931 over BRI Backhaul D-channels to your provisioning data, perform the following steps:


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

Step 2 Enter the following command to add an QSIG/Q.931 over BRI Backhaul D-channel:

mml>prov-add:dchan:name="name", desc="description", svc="BRI", pri="1", tcplink="lnkname", 
sigslot="sslot", sigport="sport", subunit="sunit"

Where:

name—The name you want to give to the QSIG/Q.931 over BRI Backhaul D-channel. 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—An assigned name. It can be as many as 128 alphanumeric characters in length.

lnkname—MML name of a previously provisioned Backhaul TCP link.

sslot—Physical slot on the Cisco BRI voice gateway on which the BRI link is terminated. Valid values are integers from 0 to 63. Default value is 0.


Note This parameter must be set to 0 for QSIG/Q.931 over BRI Backhaul D-channels when the associated external node is a Cisco 17xx.


sport—Physical port of the associated slot on the Cisco BRI voice gateway. Valid values are 0 and 1. Default value is 0.

sunit—Used only for QSIG/Q.931 over BRI Backhaul D-Channels. Valid values are 0 and 1. Default value is 0.

For example, to add an QSIG/Q.931 over BRI Backhaul D-channel named bridchan1, enter the following command:

mml>prov-add:dchan:NAME="bridchan1",DESC="QSIG BRI D channel 1", SVC="BRI", PRI="1", 
TCPLINK="britcp1", sigslot="4", sigport="1", subunit="1"


Note The parameters listed above are those required for the creation of a D channel for an QSIG/Q.931 over BRI Backhaul signaling service. For a complete list of parameters for this component, refer to the "D-Channel" section.


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


Modifying QSIG/Q.931 Over BRI Backhaul Components

The following sections contain the procedures for modifying the QSIG/Q.931 over BRI Backhaul connection in your Cisco MGC provisioning data:

Modifying Cisco BRI Voice Gateway External Nodes

Modifying QSIG/Q.931 Over BRI Backhaul Signaling Services

Modifying MGCP Signaling Service Properties

Modifying IP Routes

Modifying Backhaul TCP Links

Modifying MGCP IP Links

Modifying QSIG/Q.931 Over BRI Backhaul D-Channels

Modifying Cisco BRI Voice Gateway External Nodes

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


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

Step 2 Enter the following command to edit the description of a Cisco BRI voice gateway external node:

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

Where:

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

description—An assigned name. It can be as many as 128 alphanumeric characters in length.

For example, to modify a Cisco BRI voice gateway external node named va-3640-01, you enter the following command:

mml>prov-ed:extnode:name="va-3640-01", desc="First QSIG BRI Voice Gateway"

Step 3 Repeat the above steps for each Cisco BRI voice 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 the "Saving and Activating Your Provisioning Changes" section.


Modifying QSIG/Q.931 Over BRI Backhaul Signaling Services

All of the QSIG/Q.931 Over BRI Backhaul signaling service parameters can be modified, except for NAME and EXTNODE. To modify QSIG/Q.931 Over BRI Backhaul signaling services, perform the following steps:


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

Step 2 Set theQSIG/Q.931 Over BRI Backhaul signaling service to be modified to the out-of-service (OOS) state as described in the "Setting the Service State of a Signaling Service" section.

Step 3 Repeat Step 2 for each BRI signaling service to be modified.

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

Step 5 Enter the following command to modify an QSIG/Q.931 Over BRI Backhaul signaling service:

mml>prov-ed:bripath:name="name", desc="description", mdo=variant, side=qside, 
custgrpid="idnum", crlen="callref"

Where:

name—The name of the QSIG/Q.931 Over BRI Backhaul signaling service to be modified.

description—An assigned name. It can be as many as 128 alphanumeric characters in length.

variant—MDO filename, from the following list:

ETS_300_102

Q931

ETS_300_172

qside—Q.931 call model side, user for user side and network for network side; (network).

idnum—VNET ID, a four-digit ID; (0000).

callref—Call reference length. The valid value is from 0 to 2, with the value representing the number of bytes in the call reference; (0).


Note If you are using the ETS_300_102 or Q931 protocol files, call reference should be set to 1. If you are using the ETS_300_172 protocol file, call reference should be set to 2.


For example, to modify the customer group ID for an QSIG/Q.931 Over BRI Backhaul signaling service named brisvc1, you would enter the following command:

mml>prov-ed:BRIPATH:NAME="brisvc1", custgrpid="2001"

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

Step 7 Set the QSIG/Q.931 Over BRI Backhaul signaling service to be modified to the in-service (IS) state as described in the "Setting the Service State of a Signaling Service" section.

Step 8 Restore the D-channel(s) on the associated media gateway(s). Refer to the documentation for the media gateway for more information on restoring the D-channels.


Modifying MGCP Signaling Service Properties

The only parameter that can be modified for a MGCP signaling service is DESC. You can modify the various properties associated with your MGCP signaling service.

To modify MGCP signaling service properties, perform the following steps:


Step 1 Set the affected MGCP signaling service to the out-of-service (OOS) state as described in the "Setting the Service State of a Signaling Service" section.

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

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

Step 4 Enter the following command to modify MGCP signaling service properties:

mml>prov-ed:sigsrvprop:name="name", param_name="param_value", param_name="param_value",...

Where:

name—The name of the MGCP signaling service to be modified.

param_name—Name of the MGCP parameter you want to modify. For a complete list of the MGCP signaling service properties, refer to the Table 7.

param_value—New value for the MGCP parameter you want to modify. For definitions of the valid values for the MGCP signaling service properties, refer to the Table 7.

For example, to modify the value of the 310 timer for a MGCP signaling service named mgcpsvc1, you would enter the following command:

mml>prov-ed:sigsvcprop:NAME="mgcpsvc1", T310Timer="4000"

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

Step 6 Set the affected MGCP signaling service to the in-service (IS) state as described in the "Setting the Service State of a Signaling Service" section


Modifying IP Routes

All of the IP route parameters can be modified except for name. To modify other IP route parameters, perform the following steps:


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

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

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

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

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

Where:

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

description—An assigned name. 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 host name, 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 host name must be less than or equal to 32 characters.

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

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

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

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

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


Modifying Backhaul TCP Links

All of the Backhaul TCP link parameters can be modified except for NAME, TYPE, IPADDR, and PORT. To modify Backhaul TCP links, perform the following steps:


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

Step 2 Enter the following command to modify a Backhaul TCP link:

mml>prov-ed:tcplink:name="name", desc="description", peeraddr="paddr", peerport="ppnum", 
iproute1="iprte1"

Where:

name—The name of the Backhaul TCP link to be modified.

description—An assigned name. It can be as many as 128 alphanumeric characters in length.

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

ppnum—Destination port number, an integer from 1024 to 65,535.

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

For example, to modify a Backhaul TCP link named britcp1, enter the following command:

mml>prov-ed:tcplink:NAME="britcp1",DESC="BRI TCP link 1", PEERADDR="10.82.80.187", 
PEERPORT="1024", IPROUTE="iprte2"

Step 3 Repeat Step 4 for each Backhaul TCP link 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 the "Saving and Activating Your Provisioning Changes" section.


Modifying MGCP IP Links

All of the MGCP IP link parameters can be modified, except for NAME and SVC. To provision MGCP IP links, perform the following steps:


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

Step 2 Enter the following command to modify a MGCP IP link:

mml>prov-ed:iplnk:name="name", desc="description", ipaddr="addr1", peeraddr="addr2", 
port=lpnum, peerport=rpnum, iproute1="iprte1", pri=priority

Where:

name—The name of the MGCP IP link you want to modify.

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

addr1—Local IP address for a LAN/WAN interface. IP address should be one of the following property names defined in the XECfgParm.dat file:

IP_Addr1

IP_Addr2

IP_Addr3

IP_Addr4


Note The local IP address selected here must match the value for the Backhaul TCP link.


addr2—Remote IP address, expressed in dotted decimal format. This value may also be specified as a host name or a DNS name.

lpnum—Local IP port number. Valid value is any integer above 1024. For MGCP IP links, we recommend that you use 2427.

rpnum—Remote IP port number. Valid value is any integer above 1024. For MGCP IP links, we recommend that you use 2427.

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

priority—Priority setting for this MGCP IP link. Valid value is any integer above 0. Default value is 1.

For example, to modify the peer IP address for a MGCP IP link, you would enter the following command:

mml>prov-ed:splnk:name="mgcpsigchan1", peeraddr="147.28.209.65"

Step 3 Repeat Step 2 for each MGCP IP link you want to modify.

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


Modifying QSIG/Q.931 Over BRI Backhaul D-Channels

The only QSIG/Q.931 Over BRI Backhaul D-Channel parameter that cannot be modified is NAME. However, the values of the SVC and PRI parameters should not be changed. The SVC parameter must remain BRI, to maintain the D-channel's definition as QSIG/Q.931 Over BRI Backhaul. The PRI parameter must be set to 1 for all QSIG/Q.931 Over BRI Backhaul D-channels. To modify QSIG/Q.931 Over BRI Backhaul D-channels in your provisioning data, perform the following steps:


Step 1 Set the QSIG/Q.931 Over BRI Backhaul D-channel to be modified to the OOS state as described in the "Setting the Service State of a D-Channel" section.

Step 2 Repeat Step 1 for each QSIG/Q.931 Over BRI Backhaul D-channel to be modified.

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

Step 4 Enter the following command to modify an QSIG/Q.931 Over BRI Backhaul D-channel:

mml>prov-ed:dchan:name="name", desc="description", tcplink="lnkname", sigslot="sslot", 
sigport="sport" subunit="sunit"

Where:

name—The name of the QSIG/Q.931 Over BRI Backhaul D-channel to be modified.

description—An assigned name. It can be as many as 128 alphanumeric characters in length.

lnkname—MML name of a previously provisioned Backhaul TCP link.

sslot—Physical slot on the Cisco BRI voice gateway on which the T1/E1 is terminated. Valid values are integers from 0 to 63. Default value is 0.


Note This parameter must be set to 0 for QSIG/Q.931 Over BRI Backhaul D-channels when the associated external node is a Cisco 17xx.


sport—Physical port of the associated slot on the Cisco BRI voice gateway. Valid values are 0 and 1. Default value is 0.

sunit—Used only for QSIG/Q.931 Over BRI Backhaul D-channels. Valid values are 0 and 1. Default value is 0.

For example, to modify the physical port of an QSIG/Q.931 Over BRI Backhaul D-channel named bridchan1, enter the following command:

mml>prov-ed:dchan:NAME="bridchan1", SIGPORT="1"

Step 5 Repeat Step 4 for each QSIG/Q.931 Over BRI Backhaul D-channel you want to modify in your provisioning data.

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

Step 7 Set the modified QSIG/Q.931 Over BRI Backhaul D-channel to the IS state as described in the "Setting the Service State of a D-Channel" section.


Deleting QSIG/Q.931 Over BRI Backhaul Components

The following sections contain the procedures for deleting elements of your ISDN BRI backhaul connections in your Cisco MGC provisioning data:

Deleting Cisco ISDN BRI Voice Gateway External Nodes

Deleting QSIG/Q.931 Over BRI Backhaul D-Channels

Deleting Backhaul TCP Links

Deleting MGCP IP Links

Deleting IP Routes

Deleting an QSIG/QBRI Over BRI Backhaul Signaling Service

Deleting MGCP Signaling Services

Deleting Cisco ISDN BRI Voice Gateway External Nodes

To delete Cisco ISDN BRI voice gateway external nodes from your provisioning data, perform the following steps:


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

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

Step 3 Delete the QSIG/Q.931 Over BRI Backhaul D-channels for this external node, as described in the "Deleting QSIG/Q.931 Over BRI Backhaul D-Channels" section.

Step 4 Delete the Backhaul TCP links for this external node, as described in the "Deleting Backhaul TCP Links" section.

Step 5 Delete the Backhaul TCP links for this external node, as described in the "Deleting Backhaul TCP Links" section.

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

Step 7 Delete the QSIG/Q.931 Over BRI Backhaul signaling service by performing the steps in the "Deleting an QSIG/QBRI Over BRI Backhaul Signaling Service" section.

Step 8 Delete the MGCP signaling service by performing the steps in the "Deleting MGCP Signaling Services" section.

Step 9 Enter the following command to delete a Cisco ISDN BRI voice gateway external node:

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

Where name is the MML name of the Cisco ISDN BRI voice gateway external node to be deleted.

For example, to delete a Cisco ISDN BRI voice gateway external node named va-3640-01, you enter the following command:

mml>prov-dlt:extnode:name="va-3640-01"

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


Deleting QSIG/Q.931 Over BRI Backhaul D-Channels

To delete QSIG/Q.931 Over BRI Backhaul D-channels from your provisioning data, perform the following steps:


Step 1 Set the service state of the QSIG/Q.931 Over BRI Backhaul D-channel to OOS, as described in the "Setting the Service State of a D-Channel" section.

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

Step 3 Enter the following command to delete an QSIG/Q.931 Over BRI Backhaul D-channel:

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

Where name is the MML name of the QSIG/Q.931 Over BRI Backhaul D-channel you want to d elete.

For example, to delete an QSIG/Q.931 Over BRI Backhaul D-channel named bridchan1, you enter the following command:

mml>prov-dlt:dchan:NAME="bridchan1"

Step 4 Repeat the above steps for each QSIG/Q.931 Over BRI Backhaul D-channel you want to delete from your provisioning data.

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


Deleting Backhaul TCP Links

To delete Backhaul TCP links from your provisioning data, perform the following steps:

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

Step 7 Enter the following command to delete a Backhaul TCP link:

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

Where name is the MML name of the Backhaul TCP link you want to delete.

For example, to delete a Backhaul TCP link named britcp1, you enter the following command:

mml>prov-dlt:tcplnk:NAME="britcp1"

Step 8 Repeat the above steps for each Backhaul TCP link you want to delete from your provisioning data.

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


Deleting MGCP IP Links

To delete MGCP IP links from your provisioning data, perform the following steps:


Step 1 Set the service state of the MGCP IP links to OOS, as described in the "Setting the Service State of a D-Channel" section.

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

Step 3 Enter the following command to delete an MGCP IP link:

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

Where name is the MML name of the MGCP IP link you want to delete.

For example, to delete a MGCP IP link named mgcpsigchan1, you enter the following command:

mml>prov-dlt:iplnk:NAME="mgcpsigchan1"

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

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


Deleting IP Routes

To delete IP routes from your provisioning data, perform the following steps:


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

Step 2 Delete any components, such as Backhaul TCP links, that used this route as a parameter. To delete Backhaul TCP Links, perform the steps found in the "Deleting Backhaul TCP Links" section.

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

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

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

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

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

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

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

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


Deleting an QSIG/QBRI Over BRI Backhaul Signaling Service

To delete an QSIG/Q.931 Over BRI Backhaul signaling service from your provisioning data, perform the following steps:


Step 1 Set the service state of the QSIG/Q.931 Over BRI Backhaul signaling service to OOS, as described in the "Setting the Service State of a Signaling Service" section.


Note Before you can take a QSIG/Q.931 Over BRI Backhaul signaling service OOS, you must shut down the D-channel on the associated media gateway. Refer to the documentation for the media gateway for more information on shutting down D-channels.


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

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

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

Where sig_svc is the MML name of this signaling service.

Step 4 Enter the following command to delete an QSIG/Q.931 Over BRI Backhaul signaling service:

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

Where name is the MML name of the QSIG/Q.931 Over BRI Backhaul signaling service to be deleted.

For example, to delete a QSIG/Q.931 Over BRI Backhaul signaling service named brisvc1, you enter the following command:

mml>prov-dlt:BRIPATH:NAME="brisvc1"

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


Deleting MGCP Signaling Services

To delete MGCP signaling services from your provisioning data, perform the following steps:


Step 1 Set the service state of the MGCP signaling service to OOS, as described in the "Setting the Service State of a Signaling Service" section.

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

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

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

Where sig_svc is the MML name of this signaling service.

Step 4 Enter the following command to delete a MGCP signaling service:

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

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

For example, to delete a MGCP signaling service named mgcpsvc1, you enter the following command:

mml>prov-dlt:MGCPPATH:NAME="mgcpsvc1"

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


Troubleshooting Provisioning Data

The following sections contain troubleshooting procedures related to provisioning:

Alarm Troubleshooting Procedures

Signaling Channel Troubleshooting Procedures

Rebooting Software to Modify Configuration Parameters

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

Alarm Troubleshooting Procedures

Any alarms that are associated with signaling services can be issued as a result of errors related to this feature. For information on troubleshooting those alarms, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.

The following alarm is added for this feature.

All ISDN BRI IP Conn Fail

This alarm occurs when all IP connections supporting an QSIG/Q.931 Over BRI Backhaul signaling service has failed.

Corrective Action

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


Step 1 Determine the health of the associated media gateway using the procedures in the user documentation for the media gateway.

If the media gateway is working correctly, proceed to Step 2.

If the media gateway is not healthy, restore it using the procedures in the user documentation for the media gateway. If those procedures restore the media gateway and this alarm clears, the procedure is complete. Otherwise, proceed to Step 2.

Step 2 Verify the functioning of the cabling between the Cisco MGC and the 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 Verify the functioning of the associated switch. Refer to the documentation for your switch for the necessary steps.

If the switch is functioning properly, proceed to Step 4.

If the switch is not functioning properly, refer to the appropriate troubleshooting procedures in the documentation for the switch. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.

Step 4 Check the IP connectivity between the Cisco MGC and the associated Cisco BRI voice gateway.

If the IP connectivity is good, proceed to Step 5.

If the IP connectivity is bad, restore the IP connectivity. If the alarm clears after the IP connectivity is restored, the procedure is complete. Otherwise, proceed to Step 5.

Step 5 Verify the provisioning data for your QSIG/Q.931 Over BRI Backhaul backhaul connection.

If the provisioning data is correct, proceed to Step 6.

If the provisioning data is not correct, modify the incorrect data using the procedures defined in the "Modifying QSIG/Q.931 Over BRI Backhaul Components" section. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.

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


Signaling Channel Troubleshooting Procedures

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

Setting the Service State of a Signaling Service

Setting the Service State of an IP Route

Setting the Service State of a D-Channel

Setting the Service State of an IP Link

Setting the Service State of a Signaling Service

To set the service state of a signaling service, perform the following steps.


Caution The set-dest command should be used only while you are dynamically reconfiguring the system. Do not use the set-dest command to take a signaling service OOS during a maintenance session, because all calls associated with the specified signaling service are dropped. You should instead use the blk-cic command to block the CICs associated with the signaling service when you need to perform maintenance.


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

set-dest:sig_srv:serv_state

Where:

sig_srv—The MML name of the desired signaling service.

serv_state—The desired service state. The valid states:

IS—Places a signaling service in service

OOS—Takes a signaling service OOS


Note Before you can take a Network Access Signaling (NAS) signaling service out of service, you must shut down the D-channel on the associated media gateway. Refer to the documentation for the media gateway for more information on shutting down D-channels.


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

set-dest:sigsrv1:IS

Step 2 Verify that the state of the destination has changed by entering the rtrv-dest command, as described in the "Retrieving Signaling Service States" section.


Setting the Service State of an IP Route

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

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

Where:

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

serv_state—Service state to which you want to change. Valid values for IP links are IS, OOS, and Forced OOS (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 enter the following command to set the service state of an IP route called iprte1 to OOS:

mml>set-iproute:iprte1:OOS,confirm


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


Setting the Service State of a D-Channel

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

mml>set-dchan:dchan_name:serv_state

Where:

dchan_name—MML name of the D-channel you want to modify.

serv_state—Service state to which you want to change. Valid values for D-channels are IS and OOS.

For example, to set the service state of a D-channel named dchan-1 to IS, enter the following command:

mml>set-dchan:dchan-1:IS

You can verify that the selected D-channel is in the proper service state by performing the procedure in the "Retrieving the Service State of D-Channels" section.

Setting the Service State of an IP Link

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

set-iplnk:iplink_name:serv_state[::confirm]

Where:

iplink_name—MML name of the IP link you want to modify.

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

confirm—As of Release 9.2(1)T, this parameter is required when you are setting the service state of an MGCP link. Other types of IP links do not require this parameter.

For example, to set the service state of the IP link, iplink1, to IS, enter the following command:

set-iplnk:iplink1:IS

In another example, you would enter the following command to set the service state of an MGCP link called mgcplnk1 to IS:

set-iplnk:mgcplnk1:IS::confirm

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

Rebooting Software to Modify Configuration Parameters

Use the procedure below if you are having communication problems with your QSIG/Q.931 over BRI backhaul data pathway. 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.


Step 1 Log in to the standby Cisco MGC as root and change directories to the /opt/CiscoMGC/etc directory 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 parameters associated with this feature and modify the values to address your problem.

Step 4 Save your changes and close the text editor.

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

/etc/init.d/CiscoMGC stop

Step 6 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 7 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 8 Repeat steps 2 through 7 for the newly standby Cisco MGC host.


Monitoring and Maintaining the Feature

The following sections contain the procedures required for proper monitoring and maintenance of this feature:

Managing Signaling Channels

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.

Managing Signaling Channels

The following procedures are used for this feature:

Retrieving Signaling Service States

Retrieving the Service State for IP Routes

Retrieving the Service State of D-Channels

Retrieving the Service State for IP Links

Valid Service States

Retrieving Signaling Service States

Retrieving state information about your signaling services is a task that is best performed daily. For more information about this and other daily tasks, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.

To retrieve information about a specific signaling service, log in to the active Cisco MGC, start an MML session, and enter the following command:

rtrv-dest: sig_srv

Where sig_srv is the MML name of a signaling service.

The system returns a response similar to the following:

MGC-01 - Media Gateway Controller 2001-06-12 14:53:03
M  RTRV
   "sigsrv1:PKG=SS7-ANSI,ASSOC=SWITCHED,PST=IS,SST=RCNG"

For more information on the response to this command, refer to the "Valid Service States" section.

If the destination is in a primary service state other than IS, attempt to bring it into service, as described in the "Setting the Service State of a Signaling Service" section.


Note If the rtrv-dest MML command is entered after a switchover has occurred, the state of some of the signaling services might be listed as undefined (UND). UND is the default state for a signaling service when the system starts. In this instance, UND indicates that the Cisco MGC has not received a service state message for the associated signaling service since the switchover occurred. No user action is required.


Retrieving the Service State for IP Routes

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

mml>rtrv-iproute:iproute_name

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

mml>rtrv-iproute:iprte1

The system returns a message similar to the following:

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

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

mml>rtrv-iproute:all

The system returns a message similar to the following:

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

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

IP Route Primary Service States

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

Table 1 IP Route Primary Service State Values 

Link State ID
Link State
Description

IS

In-service

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

OOS

Out-of-service

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


IP Route Secondary Service States

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

Table 2 IP Route Secondary Service State Values 

Link State ID
Link State
Description

COOS

Commanded out-of-service

Route has been commanded OOS by the operator.

STBY

Standby

Routes on the standby Cisco MGC.

OFF_DUTY

Off duty

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

CONF

Configuration

Route is OOS due to a configuration failure.


Retrieving the Service State of D-Channels

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

rtrv-dchan:dchan_name

For example, to retrieve the service state for a D-channel called dchan-1, enter the following command:

rtrv-dchan:dchan-1

When the D-channel is associated with an FAS signaling path, the system returns a message similar to the following:

   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "dchan-1:fas1,LID=0:IS"
   ;

In this response, fas1 is the signaling path, or a logical grouping of D-channels (equivalent to a linkset). The LID is the line identifier, or the logical line ID of the D-channel within the signaling path (equivalent to the SLC in SS7). IS is the primary service state of the D-channel.

When the D-channel is associated with an NFAS signaling path, the system returns a message similar to the following:

   Media Gateway Controller 2000-03-26 20:26:18
M  RTRV
   "dchan-1:nfas1,LID=0:PRI,backup=dchan-2:STBY"
   ;

In this response, nfas1 is the signaling path, or a logical grouping of D-channels (equivalent to a linkset). The LID is the line identifier, or the logical line ID of the D-channel within the signaling path (equivalent to the SLC in SS7). The next field indicates whether the specified D-channel is the primary (PRI) channel or the standby (STBY). Finally, the backup field specifies the MML name of the D-channel that is configured as the backup to the specified D-channel.


Note Backup D-channels are not supported for QSIG/Q.931 Over BRI Backhaul D-channels.


To retrieve the service state for all of the D-channels, log in to the active Cisco MGC, start an MML session, and enter the following command:

rtrv-dchan:all

The system returns a message similar to the following, which shows the signaling links to and from the Cisco MGCs and the associated media gateways (different solutions might use different media gateways):

   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "dchan1:nfas1,LID=0:IS"
   "dchan2:nfas1,LID=1:IS"
   "dchan3:fas1,LID=0:IS" 

The valid service states for a D-channel are identical to the primary service states for signaling channels, as found in the "Valid Service States" section. If the link is in any state other than IS, attempt to bring the linkset into service, as described in the "Setting the Service State of a D-Channel" section.

Retrieving the Service State for IP Links

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

rtrv-iplnk:iplink_name

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

rtrv-iplnk:iplink1

The system returns a message similar to the following:

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

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

rtrv-iplnk:all

The system returns a message similar to the following, which shows the IP links to and from the
Cisco MGCs and the associated media gateways (different solutions might use different media gateways).

   Media Gateway Controller 2000-03-26 19:23:23
M  RTRV
   "iplink1:OOS
   "iplink2:OOS
   "iplink3:OOS
   "iplink4:OOS
   "iplink5:OOS
   "iplink6:OOS

The valid service states for an IP link are identical to the primary service state listings for signaling channels, as found in the "Valid Service States" section. If the link is in any state other than IS, attempt to bring the linkset into service, as described in the "Setting the Service State of an IP Link" section.

Valid Service States

The primary and secondary service states for signaling channels are defined in the subsections below.

Primary Service State

Table 3 lists the valid primary service state values.

Table 3 Signaling Channel Primary Service State Values 

Link State ID
Link State
Description

AOOS

Automatically out-of-service

The system has taken the signaling channel OOS.

INB

Install busy

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

IS

In-service

The signaling channel is IS and fully operational. This is its normal operating state.

MOOS

Manually out-of-service

The signaling channel has been manually taken OOS.

OFF_DUTY

Off duty

State of signaling channels when a retrieve command is entered on the standby Cisco MGC. The current service state is maintained only on the active Cisco MGC.

OOS

Out-of-service

The signaling channel is OOS on the remote end. The system is actively trying to restore the signaling channel. The links on the standby Cisco MGC are always OOS (with a secondary service state of STBY) because the current service state is maintained only on the active Cisco MGC.

TRNS

Transient

The state of the signaling channel is currently being changed.

UNK

Unknown

The state of the signaling channel is not known.


Secondary Service State

The valid secondary service states are:

ACKD—SS7 Acknowledgment delay

BSNR—SS7 backward sequence number received (BSNR)

CIS—Commanded in service

CONF—Configuration failure

COOS—Commanded out of service

ENGR—Call engine reset

ISPEND—In service, pending

LCNG—Congestion, local

LINE—Line failure

LINH—SS7 local inhibit

LINK—Link failure

LINS—Linkset failure

NA—Cause not available

OOSPEND—Out of service, pending

PRHB—SS7 prohibited

RBLK—SS7 remote blocked

RCNG—Congestion, remote

RINH—SS7 remote inhibit

RSTR—SS7 restricted

SERR—SS7 signal error

STBY—Host is in the standby state

SUPPENT—Supporting entity

TPATH—Traffic path

UNK—Cause unknown

Configuration Examples

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.

*.ioChanMgr.IPCsendThreshold=0 
*.ioChanMgr.IPCTimer=0 
*.maxNumDChansPerPort.h=100 

Provisioning Examples

This section provides a provisioning example for this feature. Additional provisioning examples for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

prov-add:extnode:name="bri-2600-1",desc="BRI Backhaul C2600",type="C2600"
prov-add:bripath:name="brisvc1",extnode="bri-2600-1",desc="BRI service to 
C2600",mdo="ETS_300_172",side="network",custgrpid="V123",crlen="2"
prov-add:mgcppath:name="mgcpsvc1",extnode="bri-3640-01",desc="MGCP service to C2600"
prov-add:tcplink:name="tcp1",ipaddr="IP_Addr1",port=7000,peeraddr="5.5.5.6",peerport=8001, 
extnode="bri-2600-1",type="BRI"
prov-add:splnk:name="mgcpsigchan1", ipaddr="IP_Addr1", peeraddr="147.28.210.65", 
svc="mgcpsvc1", port=2427, peerport=2427, iproute1=iproute1, pri=1, desc="MGCP sigchan 1"
prov-add:dchan:name="dchan1",desc="BRI D Channel 1", pri=1,svc="brisvc1",tcplink="tcp1", 
sigslot=1, sigport=1,subunit=0
prov-rtrv:bripath:"all"

Command Reference

This section documents the Man-Machine Language (MML) commands modified for this feature. All other MML commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference.

Modified MML Commands

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

RTRV-DCHAN—Display Primary and Secondary States of a D-Channel

This command has been modified for the inclusion of service state data for QSIG/Q.931 Over BRI Backhaul D-channels in the command response.

RTRV-DEST—Display Primary and Secondary States of a Destination

This command has been modified for the inclusion of service state data for QSIG/Q.931 Over BRI Backhaul signaling services in the command response.

RTRV-IPLNK—Display Primary and Secondary States of an IP Link

This command has been modified for the inclusion of service state data for Backhaul TCP links in the command response.

SET-DCHAN—Change Service State of a D-Channel

This command has been modified for the inclusion of QSIG/Q.931 Over BRI Backhaul D-channels in the command.

SET-DEST—Change Service State of a Destination

This command has been modified for the inclusion of QSIG/Q.931 Over BRI Backhaul signaling services in the command.

Reference Information

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

XECfgParm.dat Parameters

Alarms

Components

External Node Types

Provisioning Worksheets

XECfgParm.dat Parameters

The XECfgParm.dat file configuration parameters added for this feature are in the table below. For information on the other XECfgParm.dat parameters, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.

Configuration Parameter
Definition

ioChanMgr.IPCsendThreshold

Specifies the maximum number of RSIPs that can be sent from the queue during a period defined by the IPCTimer XECfgParam.dat parameter. When this parameter is left at its default value (0), the system uses a base value. You can modify the value if a problem occurs.

Valid values: Any integer

Default value: 0

*.ioChanMgr.IPCTimer

Specifies the frequency at which the queue is scanned for RSIP messages. When this parameter is left at its default value (0), the system uses a base parameter value. You can modify this parameter if a problem occurs.

Valid values: Any integer

Default value: 0

*.maxNumDChansPerPort

Specifies the maximum number of D-channels that can be provisioned per IP address or port.

Valid values: Any integer (1 to 2000)

Default value: 2000


Alarms

This section lists the alarm that is added to support this feature. For information on the other alarms for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.

New Alarms

The alarm that is added for this feature is listed below.

All ISDN BRI Conn Fail

Description All IP connections supporting an QSIG/Q.931 Over BRI Backhaul signaling service have failed.

Severity Major

Cause This alarm is reported when all IP connections supporting an QSIG/Q.931 Over BRI Backhaul signaling service have failed.

Type 2 (Major error).

Action Refer to the "All ISDN BRI IP Conn Fail" section.

Components

The sections below discuss 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.

New Components

The following provisioning components are added for this feature.

Backhaul TCP Link

The Backhaul TCP link component represents a static IP route. Its MML name is as follows:

MML Name—TCPLINK

The Backhaul TCP link component structure is shown in Table 4.

Table 4 TCPLINK Component Structure 

Parameter MML Name
Parameter Description
Parameter Value (Default)

NAME

Unique component name used in MML commands

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

DESC

Component description

The description can be up to 128 characters.

TYPE

Signaling service type

Identifies the type of signaling service associated with this link. Must be set to BRI.

IPADDR

Local IP address

IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4.

PORT

Port number

1024 through 65535; (2428).

PEERADDR

Highest priority destination address

IP address in dotted decimal notation.

PEERPORT

Destination port number

1024 through 65535; (2428).

EXTNODE

MML name for associated external node

MML name of a previously provisioned Cisco BRI voice gateway.

IPROUTE

MML name for first IP route (optional)

MML name of a previously provisioned IP route.


The following attributes cannot be modified:

NAME

EXTNODE

The following rules apply when you are creating or editing QSIG/Q.931 Over BRI Backhaul signaling services:

You must define the TYPE parameter as PRI. If the TYPE parameter is not defined as PRI when the TCPLINK is added/edited, a warning is issued. If the TYPE parameter is not defined as PRI when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.

You must define the TCPLINK parameter with the same EXTNODE attribute that its associated BRIPATH has. If the TCPLNK is not defined when the BRIPATH is added/edited, a warning is issued. If the TCPLINK is not defined when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.

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

Only two combinations of local IP address and port number can be used per Cisco MGC. Once you have identified two unique local IP address and port number combinations, all subsequent Backhaul TCP links must use one of those combinations.

The commands to retrieve the service state of a Backhaul TCP link can be found in the "Retrieving the Service State for IP Links" section.

QSIG/Q.931 Over BRI Backhaul Signaling Service

The QSIG/Q.931 Over BRI Backhaul signaling service component represents a static IP route. Its MML name is as follows:

MML Name—BRIPATH

The QSIG/Q.931 Over BRI Backhaul signaling service component structure is shown in Table 5.

Table 5 BRIPATH Component Structure 

Parameter MML Name
Parameter Description
Parameter Value (Default)

NAME

Unique component name used in MML commands

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

DESC

Component description

The description can be up to 128 characters.

EXTNODE

MML name of external node

MML name of a previously provisioned QSIG/Q.931 BRI voice gateway external node.

MDO

MDO file name

A valid protocol name. You can use the following files:

ETS_300_102

Q931

ETS_300_172

SIDE

Q.931 call model side

User for user side and network for network side; (network).

CUSTGRPID

VNET ID

Four digit ID; (0000).

CRLEN

Call reference length

1 for 1-byte or 2 for 2-byte call reference length; (0).


Note If you are using the ETS_300_102 or Q931 protocol files, this should be set to 1. If you are using the ETS_300_172 protocol file, this should be set to 2.



The following attributes cannot be modified:

NAME

EXTNODE

The following rules apply when you are creating or editing QSIG/Q.931 Over BRI Backhaul signaling services:

You must define the TCPLINK parameter with the same EXTNODE attribute that its associated BRIPATH has. If the TCPLNK is not defined when the BRIPATH is added/edited, a warning is issued. If the TCPLINK is not defined when the provisioning session is copied or deployed, an error message is generated and the copy or deployment is stopped.

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

A maximum of 2000 BRIPATHs can be provisioned on your Cisco MGC.

The commands to retrieve and set the service state of an QSIG/Q.931 Over BRI Backhaul signaling service can be found in the "Retrieving Signaling Service States" section and the "Setting the Service State of a Signaling Service" section.

Modified Components

The following provisioning components are modified for this feature.

D-Channel

The D-channel component type represents a D-channel used on the Cisco MGC. There can be a maximum of two channels per IPFAS (one primary and one backup). Its MML name is as follows:

MML Name—DCHAN

The D-channel component structure is shown in Table 6.

Table 6 DCHAN Component Structure 

Parameter MML Name
Parameter Description
Parameter Value (Default)

NAME

Unique component name used in MML commands

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

DESC

Component description

The description can be up to 128 characters.

PRI

Priority

1 through 65535; (1).

SVC

MML name of the supported signaling service

MML name of a previously configured signaling service (IPFAS or QSIG/Q.931 Over BRI Backhaul only).

SESSIONSET

MML name of session set (restricted)

MML name of a previously provisioned session set. This parameter is used only for D-channels associated with IPFAS signaling services.

TCPLINK

MML name of TCP link (restricted)

MML name of a previously provisioned TCP link. This parameter is used only for D-channels associated with QSIG/Q.931 Over BRI Backhaul signaling services.

SIGSLOT

Physical slot on the media gateway on which the associated T1/E1 is terminated

Integer 0 through 63; (0).


Note This parameter must be set to 0 for IQSIG/Q.931 Over BRI Backhaul D-channels when the associated external node is a Cisco 17xx.


SIGPORT

Physical port of the associated slot on the media gateway

Integer 0 through 167; (0).


Note This parameter can be set to either 0 or 1 for QSIG/Q.931 Over BRI Backhaul D-channels.


SUBUNIT

Required for QSIG/Q.931 Over BRI Backhaul D-channels

Integer 0 and 1; (0).


The following rules apply when you are creating or editing D-channels:

Backup D-channels for QSIG/Q.931 Over BRI Backhaul signaling services are not supported.

The priority for QSIG/Q.931 Over BRI Backhaul D-channels should be set to 1.

Session sets are used only in support of IPFAS D-channels.

TCP links are used only in support of QSIG/Q.931 Over BRI Backhaul D-channels.

Up to 1000 D-channels can be provisioned against a single IP address and port combination used by your Backhaul TCP links. Since the Cisco MGC supports a maximum of two IP address and port combinations, you can provision a maximum of 1000 D-channels for a QSIG/Q.931 Over BRI Backhaul signaling service.

The commands to retrieve and set the service state of a D-channel can be found in the "Retrieving the Service State of D-Channels" section and the "Setting the Service State of a D-Channel" section.

Properties

Table 7 defines the properties associated with MGCP signaling services.

Table 7 MGCP Properties 

Property
Definition

*ADigitCCPrefix

Controls functionality that applies a country code prefix to the calling party number before sending the call forward.
Values are 0 (disabled) or 1 (enabled).

Default: 0

*.AInternationalPrefix

Determines the prefix of the outgoing calling number when NOA = International. Value range: NULL or a numeric string.

Default: NULL

*.ANationalPrefix

Determines the prefix of the outgoing calling number when NOA = National. Value range: NULL or a numeric string.

Default = NULL

*.AuditWhenSscIs

Specifies if the MGC (the engine) will perform an audit on the endpoints of the gateway associated with this cxnSigPath when the MGC receives an In Service (IS) Service State Change (SSC) message. For smaller gateways (AS5300) set value = True, the audit is performed when the connection becomes available; for larger gateways (MGX8260, VISM) set value = False. This property value is dynamically editable using MML commands. Values are: TRUE (1) or FALSE (0).

Default: False

*BDigitCCPrefix

Controls functionality that applies a country code prefix to the called party number before sending the call forward.
Values are: 0 (disabled) or 1 (enabled).

Default: 0

*BDigitCCrm

Provides a country code digit string to which the called party Number leading digits can be compared, and if matched have those digits removed from the front of the number. This modification is made before sending the call forward. Values are: NULL (default) or null, or a maximum 5-digit string.

*.BInternationalPrefix

Determines the prefix of the outgoing called number when NOA = International. Value range: NULL or a numeric string.

Default = NULL

*.BNationalPrefix

Determines the prefix of the outgoing called number when NOA = National. Value range: NULL or a numeric string.

Default = NULL

*.CCOrigin

Provides against the origin trunk group of a call the country code digits, which if needed can be prefixed on a number before sending the call forward. Only required when the property domain is SigPath or LinkSet. Values: NULL or a maximum 5-digit string.

Default: NULL

*.CompressionType

Compression type. Indicates the G.711 compression type used on the trunk. Values are: 0 (none), 1 (mu-law), 2 (A-law), or 3 (clear channel).

Default: 1

*.GatewayName

Used to identify the Gateway in the CDR record, that is whatever this value is set to will be placed in the CDR.

Default: N/A

*.GWDefaultCodecString

Enables the IOCC-MGCP to send the ordered series of codec choices separated by semicolons. Refer to your gateway documentation for a list of supported codec names. The following values represent some of the more common codec names.

Values: NULL, G.711a, G.711u, G.729, G.729a, and G.729b

Default: NULL

*.GWNetworkContinuity

This property enables or disables the network continuity test on the VISM. Values: 0 or 1.

Default: 0

*.GWProtocolVersion

The MGCP protocol version to use when communicating with the gateway.

Default: MGCP 0.1

*.InitEndpointsAsEnabled

Specifies if the MGC (the engine) initializes its endpoint objects (corresponding to those on the gateway) as enabled or disabled. For gateways that send RSIP messages at initialization to inform MGC of their endpoint state, set to False; all others set to True. This property value is dynamically editable using MML commands.

Values: TRUE (1) or FALSE (0)

Default: True

*.MgcpBehavior

Regulates the MGC engine behavior to allow different MGCP gateway types to return different codes for the same error. Value range: 0 through 3.

0—No action

1—Resolves a connection conflict between the MGC and a media gateway to allow a circuit to be used after a CRCX failure (return code 501) by clearing the call; VISM and MX8260

2 or 3—Resolves a connection conflict between the MGC and a media gateway to allow a circuit to be used after a CRCX failure (return code 502) by forcing a delete and reconnection; 5300

Default: 0

Note Additional differences can be handled by adding enumerated values.

 

*.mgcpDomainNameRemote

Default MGCP remote domain name. It is used to append to the audit command to send to the remote gateway.

Default: remote@name.net

*.mgcpGWStdbyHeartbeatInterval

This interval time, in seconds, enables the MGC to send the standby heartbeat to complete a health check on the remote gateway. Value range: 0 to 30 seconds.

Default value: 30 seconds

*.mgcpHeartbeatInterval

Indicates how often the MGCP protocol should heartbeat the gateway. Value range: 0 through 1000.

Default: 10

Note To prevent MGCP IP links from flapping, set this to a minimum value of 4 when the Cisco MGC call agent is working with a Cisco MGX-8260.

 

*.mgcpGWRspAckTimeout

Enables the MGC to discard respAcks in the buffer for which the gateway no longer expects acknowledgements. Value range: any positive value (in seconds).

Default: 30

Note Set this value to the same duration as the gateway's command/response timeout value.

 

*.mgcpMaxRspAckToBuffer

Enables the MGC to buffer the number of response acknowledgements specified by this property before tagging them in the K-parameter in the next mgcp command. Value range: 0 (disable) to any positive value.

Default: 0

*.mgcpRetxCount

A limit on the number of retransmissions before declaring failure. (MGCP protocol.) Value range: 0 through 10.

Default: 3

*.mgcpLocalIpInterfacePollCount

This poll count defines the number of attempts to be performed to reach the remote GW using each configured local IP interface. Value range: any positive value.

Default value: 6

*.mgcpRemoteIpPollCount

This poll count defines the number of retry audit messages to be sent to the remote gateway. Value range: any positive value.

Default Value = 3

*.mgcpRetxTimer

A limit on the time to wait for a response from a gateway before retransmitting the message. (MGCP protocol.) Value range: 0 through 60000.

Default: 1000

Note To prevent possible hung calls on a MGW, the recommended value is 4000.

 

*.T309Time

For timer NT309. In pri_10.mdl. Value range: 6000 through 900000, in milliseconds.

Default: 90000 milliseconds

*.T310Time

For timer 310, which is started when the Call Proceeding message is received by the MGC and is stopped when the Alerting, Progress, Connect, or Disconnect messages are received. Value range: 3000 through 120000, in milliseconds.

Default: 10000


External Node Types

Table 8 lists the external node types, the software release in which they were introduced, and the signaling service types they support.

Table 8 External Node Types 

External Node MML Name
Valid Release
Supported Signaling Service Type

AS3600

Release 9.1(5) and up

MGCP IPFAS NAS IUA

AS3660

Release 9.1(5) and up

MGCP IPFAS NAS IUA

AS5200

Release 9.1(5) and up

IPFAS NAS

AS5300

Release 9.1(5) and up

MGCP IPFAS NAS IUA

AS5350

Release 9.2(2) and up

MGCP IPFAS NAS BSMV0 IUA

AS5400

Release 9.2(2) and up

MGCP IPFAS NAS BSMV0 IUA

AS5800

Release 9.1(5) and up

IPFAS NAS

AS5850

Release 9.1(5) and up

IPFAS NAS

AS7200

Release 9.1(5) and up

MGCP IPFAS NAS

CAT8510

Release 9.1(5) and up

MGCP

CAT8540

Release 9.1(5) and up

MGCP

C1751

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C1760

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2600

Release 9.4(1) and up

MGCP IPFAS IUA BRI

C2610XM

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2611XM

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2620XM

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2621XM

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2650XM

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2651XM

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C2691

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C3640

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C3640A

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C3660

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C3725

Release 9.5(2) and up

MGCP IPFAS IUA BRI

C3745

Release 9.5(2) and up

MGCP IPFAS IUA BRI

H323

Release 9.1(5) and up

EISUP

ITP

Release 9.4(1) and up

M3UA SUA

LS1010

Release 9.1(5) and up

MGCP

MC3810

Release 9.1(5) and up

MGCP IPFAS

MGC

Release 9.1(5) and up

EISUP

MGX8260

Release 9.1(5) and up

MGCP IPFAS NAS

MGX8850

Release 9.1(5) and up

MGCP SGCP IPFAS

SLT

Release 9.2(2) and up

BSMV0

TALISS7

Release 9.1(5) and up

SS7SG

UNKNOWN

Release 9.1(5) and up

UNKNOWN


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.

Table 9 External Node Worksheet Example 

Name
Type
ISDN Signaling Type
Group
Description

va-3640-01

C3640

 

TCP conn to va-3640-01

         
         
         
         
         
         
         
         
         

Table 10 MGCP Signaling Service Worksheet Example 

Name
Ext Node
Description

MGCpth1

Gw1

MGCP path to Gw1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Table 11 MGCP Signaling Service Properties Worksheet Example 

Property Name
Value

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Table 12 QSIG/Q.931 Over BRI Backhaul Signaling Service Worksheet Example 

Name
External
Node
Q.931
Call Model Side
MDO File
Customer Group ID
Call Reference Length
Description

brisvc1

va-3640-01

 

ETS_300_102

 

1

BRI path to va-3640-01

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Table 13 IP Route Worksheet Example (Optional) 

Name
Destination
Subnet Mask
Next Hop
IP Address
Priority
Description

iproute1

va-3640-01

255.255.255.0

va-3640-02

175.25.211.17

1

IP route to va-3640-01

             
             
             
             
             
             
             
             
             

Table 14 Backhaul TCP Link Worksheet Example 

Name
Signaling
Type
Local
IP Address
Local
Port Number
Destination
IP Address
Destination
Port Number
External Node
IP Route
Description

britcp1

bri

175.25.211.17

1024

175.25.211.17

1024

va-3640-01

n-a

IP route to va-3640-01

                 
                 
                 
                 
                 
                 
                 
                 
                 

Table 15 MGCP IP Link Worksheet 

Name
Port
Priority
IP Address
MGCP Path
Peer Port
IP Route
Peer IP Address
Description

mgcplnk1 

2427

1

IP_Addr1 

mgcpsvc1 

2427

iproute1

146.29.64.101

MGCP IP link 1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table 16 D-Channel Worksheet Example 

Name
Signaling Type
Priority
Link
Slot
Port
Subunit
Description

brichan1

bri

1

britcp1

0

4

1

bri d-channel 1

               
               
               
               
               
               
               
               
               

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 17 contains definitions of acronyms and technical terms used in this feature module.

Table 17 Acronyms  

Acronym
Definition

BRI

Basic Rate Interface. ISDN interface composed of two B-channels and one
D-channel for circuit-switched communication of voice, video, and data.

IOCC

I/O Channel Controller.

IOCM

I/O Channel Manager.

IP

Internet Protocol.

ISDN

Integrated Services Digital Network. Communication protocol offered by telephone companies that permits telephone networks to carry data, voice, and other source traffic.

MGC

(Cisco) Media Gateway Controller.

MGCP

Media Gateway Control Protocol.

PRI

Primary Rate Interface. ISDN interface to primary rate access. Primary rate access consists of a single 64-kbps D-channel plus 23 (T1) or 30 (E1)
B-channels for voice or data.

Q.931

ISDN Level 3 ITU standard.

RSIP

Restart in progress. MGCP command used to indicate that a span (or collection of spans) has come into service, has gone out of service, or is about to go out of service.

TCP

Transmission Control Protocol. Connection-oriented transport layer protocol that provides reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.