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, page 2
•
Supported Platforms, page 4
•
Supported Standards, MIBs, and RFCs, page 5
•
Prerequisites for Using This Feature, page 5
•
Configuration Tasks, page 5
•
Provisioning Tasks, page 5
•
Monitoring and Maintaining the Feature, page 34
•
Configuration Examples, page 40
•
Provisioning Examples, page 40
•
Command Reference, page 40
•
Reference Information, page 41
•
Obtaining Documentation, page 55
•
Documentation Feedback, page 56
•
Obtaining Technical Assistance, page 56
•
Obtaining Additional Publications and Information, page 58
•
Glossary, page 58
Cisco MGC Software Release 9.5(2)
1
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Feature Overview
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
Cisco MGC Software Release 9.5(2)
2
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Feature Overview
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.
Cisco MGC Software Release 9.5(2)
3
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Supported Platforms
– 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.
Cisco MGC Software Release 9.5(2)
4
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Supported Standards, MIBs, and RFCs
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, page 5
•
Provisioning Procedures, page 8
•
Troubleshooting Provisioning Data, page 30
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.
Cisco MGC Software Release 9.5(2)
5
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 51.
Collecting MGCP Path Data
The MGCP component type represents a MGCP signaling service to a particular Cisco voice gateway.
Refer to the “Restrictions” section on page 2 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 on page 51.
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 on page 51.
Cisco MGC Software Release 9.5(2)
6
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 2
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 on page 51.
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
on page 51.
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)
Cisco MGC Software Release 9.5(2)
7
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
•
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 on page 51.
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 on page 51.
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 on page 51.
Provisioning Procedures
This section covers the following provisioning topics:
•
Provisioning Basics, page 9
Cisco MGC Software Release 9.5(2)
8
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
•
Adding QSIG/Q.931 Over BRI Backhaul Connections, page 12
•
Modifying QSIG/Q.931 Over BRI Backhaul Components, page 20
•
Deleting QSIG/Q.931 Over BRI Backhaul Components, page 26
Provisioning Basics
The procedures in this section describe how to start a provisioning session and how to save and activate
the changes you have made.
•
Starting a Provisioning Session, page 9
•
Saving and Activating Your Provisioning Changes, page 10
•
Ending a Provisioning Session Without Activating Your Changes, page 10
•
Retrieving Provisioning Data, page 10
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 on page 11.
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 on page 10 or ending
your provisioning session without saving and activating your changes, as described in the “Ending a
Provisioning Session Without Activating Your Changes” section on page 10.
Cisco MGC Software Release 9.5(2)
9
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 9.
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 on page 9.
Ending a Provisioning Session Without Activating Your Changes
You may find that you want to end a provisioning session without saving and activating the changes you
have entered during your session. If this is the case, you can enter the prov-stp MML command. This
command ends your current provisioning session and your changes are not entered.
Retrieving Provisioning Data
You can use the prov-rtrv MML command to retrieve information about your current provisioning
settings. The ways in which you can use this command to retrieve provisioning data are described in the
following sections:
•
Retrieving Data for an Individual Component, page 11
•
Retrieving Data for All Components, page 11
•
Retrieving Data for All Components of a Particular Type, page 11
•
Retrieving Data on the Current Provisioning Session, page 11
Cisco MGC Software Release 9.5(2)
10
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
•
Retrieving Data on Supported Signaling Protocols, page 12
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:
Cisco MGC Software Release 9.5(2)
11
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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, page 12
•
Adding Cisco BRI Voice Gateway External Nodes, page 12
•
Adding MGCP Signaling Services, page 14
•
Adding QSIG/Q.931 Over BRI Backhaul Signaling Services, page 15
•
Adding IP Routes (Optional), page 16
•
Adding Backhaul TCP Links, page 17
•
Adding MGCP IP Links, page 18
•
Adding QSIG/Q.931 Over BRI Backhaul D-Channels, page 19
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 on page 12.
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.
Cisco MGC Software Release 9.5(2)
12
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 9.
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 on page 10.
Otherwise, proceed to the “Adding MGCP Signaling Services” section on page 14.
Cisco MGC Software Release 9.5(2)
13
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 9.
Step 2
Enter the following command to add a MGCP signaling service:
mml>prov-add:mgcppath:name="name", desc="description", extnode=”mgw”
Cisco MGC Software Release 9.5(2)
14
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
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 on page 22 and return here.
Otherwise, proceed to the “Adding QSIG/Q.931 Over BRI Backhaul Signaling Services” section on
page 15.
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 on page 9.
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).
Cisco MGC Software Release 9.5(2)
15
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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”
Up to 2000 QSIG/Q.931 over BRI Backhaul signaling services can be provisioned on your
Cisco MGC.
Note
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 on page 10.
Otherwise, you have two choices:
•
Proceed to the “Adding IP Routes (Optional)” section on page 16 if your Cisco MGC is on a
different subnet from the associated BRI voice gateway
•
Proceed to the “Adding Backhaul TCP Links” section on page 17 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 on page 9.
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
Cisco MGC Software Release 9.5(2)
16
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
– 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 on page 10.
Otherwise, proceed to the “Adding Backhaul TCP Links” section on page 17.
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 on page 9.
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.
Cisco MGC Software Release 9.5(2)
17
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
•
addr—Local IP address, as defined by the one of the following XECfgParm.dat parameters:
– IP_Addr1
– IP_Addr2
– IP_Addr3
– IP_Addr4
Note
•
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.
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 on page 10.
Otherwise, proceed to the “Adding MGCP IP Links” section on page 18.
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
Cisco MGC Software Release 9.5(2)
18
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
– 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 on page 10.
Otherwise, proceed to the “Adding QSIG/Q.931 Over BRI Backhaul D-Channels” section on page 19.
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 on page 9.
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.
Cisco MGC Software Release 9.5(2)
19
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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"
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 on page 45.
Note
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 on page 10.
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, page 20
•
Modifying QSIG/Q.931 Over BRI Backhaul Signaling Services, page 21
•
Modifying MGCP Signaling Service Properties, page 22
•
Modifying IP Routes, page 23
•
Modifying Backhaul TCP Links, page 24
•
Modifying MGCP IP Links, page 24
•
Modifying QSIG/Q.931 Over BRI Backhaul D-Channels, page 25
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 on page 9.
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.
Cisco MGC Software Release 9.5(2)
20
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
•
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 on page 10.
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 on page 32.
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 on page 9.
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.
Cisco MGC Software Release 9.5(2)
21
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
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 on page 32.
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 on page 32.
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 on page 9.
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 on page 46.
•
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 on page 46.
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 on page 10.
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 on page 32
Cisco MGC Software Release 9.5(2)
22
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 32.
Step 2
Repeat Step 1 for each IP route to be modified.
Step 3
Start a provisioning session as described in the “Starting a Provisioning Session” section on page 9.
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.
Cisco MGC Software Release 9.5(2)
23
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
Step 7
Set the IP route to be modified to the IS state as described in the “Setting the Service State of an IP
Route” section on page 32.
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 on page 9.
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 on page 10.
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 on page 9.
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
Cisco MGC Software Release 9.5(2)
24
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
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 on page 33.
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 on page 9.
Cisco MGC Software Release 9.5(2)
25
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
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 on page 33.
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, page 27
•
Deleting QSIG/Q.931 Over BRI Backhaul D-Channels, page 27
•
Deleting Backhaul TCP Links, page 28
•
Deleting MGCP IP Links, page 28
•
Deleting IP Routes, page 29
•
Deleting an QSIG/QBRI Over BRI Backhaul Signaling Service, page 29
•
Deleting MGCP Signaling Services, page 30
Cisco MGC Software Release 9.5(2)
26
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 9.
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 on page 27.
Step 4
Delete the Backhaul TCP links for this external node, as described in the “Deleting Backhaul TCP
Links” section on page 28.
Step 5
Delete the Backhaul TCP links for this external node, as described in the “Deleting Backhaul TCP
Links” section on page 28.
Step 6
If your system uses IP routes for this external node, delete the IP routes as described in the “Deleting IP
Routes” section on page 29.
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 on page 29.
Step 8
Delete the MGCP signaling service by performing the steps in the “Deleting MGCP Signaling Services”
section on page 30.
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 on page 10.
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 on page 33.
Step 2
If you do not already have an active provisioning session, start one as described in the “Starting a
Provisioning Session” section on page 9.
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.
Cisco MGC Software Release 9.5(2)
27
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
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 on page 9.
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 on page 10.
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 on page 33.
Step 2
If you do not already have an active provisioning session, start one as described in the “Starting a
Provisioning Session” section on page 9.
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 on page 10.
Cisco MGC Software Release 9.5(2)
28
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 32.
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 on page 28.
Step 3
If you do not already have an active provisioning session, start one as described in the “Starting a
Provisioning Session” section on page 9.
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 on page 10.
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
Note
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 on page 32.
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 on page 9.
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"
Cisco MGC Software Release 9.5(2)
29
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 10.
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 on page 32.
Step 2
If you do not already have an active provisioning session, start one as described in the “Starting a
Provisioning Session” section on page 9.
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 on page 10.
Troubleshooting Provisioning Data
The following sections contain troubleshooting procedures related to provisioning:
•
Alarm Troubleshooting Procedures, page 30
•
Signaling Channel Troubleshooting Procedures, page 31
•
Rebooting Software to Modify Configuration Parameters, page 34
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.
Cisco MGC Software Release 9.5(2)
30
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 20. 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 on page 56.
Signaling Channel Troubleshooting Procedures
The following signaling channel troubleshooting procedures are used for this feature:
•
Setting the Service State of a Signaling Service, page 32
•
Setting the Service State of an IP Route, page 32
•
Setting the Service State of a D-Channel, page 33
Cisco MGC Software Release 9.5(2)
31
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
•
Setting the Service State of an IP Link, page 33
Setting the Service State of a Signaling Service
To set the service state of a signaling service, perform the following steps.
Caution
Step 1
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.
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 on page 35.
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.
Cisco MGC Software Release 9.5(2)
32
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Provisioning Tasks
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 on page 35.
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 on page 36.
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.
Cisco MGC Software Release 9.5(2)
33
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Monitoring and Maintaining the Feature
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 on page 37.
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, page 35
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.
Cisco MGC Software Release 9.5(2)
34
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Monitoring and Maintaining the Feature
Managing Signaling Channels
The following procedures are used for this feature:
•
Retrieving Signaling Service States, page 35
•
Retrieving the Service State for IP Routes, page 35
•
Retrieving the Service State of D-Channels, page 36
•
Retrieving the Service State for IP Links, page 37
•
Valid Service States, page 38
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 on
page 38.
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 on page 32.
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:
M
Media Gateway Controller 2000-03-26 20:26:18
RTRV
Cisco MGC Software Release 9.5(2)
35
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Monitoring and Maintaining the Feature
"iprte1:IS"
To retrieve attributes for all of the IP routes, log in to the active Cisco MGC, start an MML session, and
enter the following command:
mml>rtrv-iproute:all
The system returns a message similar to the following:
M
Media Gateway Controller 2000-03-26 19:23:23
RTRV
"iprte1:IS
"iprte2:IS
The valid service states for an IP route are described in the following sections. If the route is in any state
other than IS, attempt to bring it into service, as described in the “Setting the Service State of an IP
Route” section on page 32.
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
Cisco MGC Software Release 9.5(2)
36
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Monitoring and Maintaining the Feature
When the D-channel is associated with an FAS signaling path, the system returns a message similar to
the following:
M
Media Gateway Controller 2000-03-26 20:26:18
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:
M
Media Gateway Controller 2000-03-26 20:26:18
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):
M
Media Gateway Controller 2000-03-26 19:23:23
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 on page 38. 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
on page 33.
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
Cisco MGC Software Release 9.5(2)
37
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Monitoring and Maintaining the Feature
The system returns a message similar to the following:
M
Media Gateway Controller 2000-03-26 20:26:18
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).
M
Media Gateway Controller 2000-03-26 19:23:23
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 on page 38. 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 on page 33.
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.
Cisco MGC Software Release 9.5(2)
38
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Monitoring and Maintaining the Feature
Table 3
Signaling Channel Primary Service State Values (continued)
Link State ID
Link State
Description
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
Cisco MGC Software Release 9.5(2)
39
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Configuration Examples
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.
Cisco MGC Software Release 9.5(2)
40
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
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, page 41
•
Alarms, page 42
•
Components, page 42
•
External Node Types, page 49
•
Provisioning Worksheets, page 51
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.
Cisco MGC Software Release 9.5(2)
41
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
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
Severity
Cause
Type
Action
All IP connections supporting an QSIG/Q.931 Over BRI Backhaul signaling service have failed.
Major
This alarm is reported when all IP connections supporting an QSIG/Q.931 Over BRI Backhaul signaling
service have failed.
2 (Major error).
Refer to the “All ISDN BRI IP Conn Fail” section on page 31.
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.
Cisco MGC Software Release 9.5(2)
42
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
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
MML name of a previously provisioned Cisco BRI
associated external node 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.
Cisco MGC Software Release 9.5(2)
43
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
•
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 on page 37.
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
The following attributes cannot be modified:
Cisco MGC Software Release 9.5(2)
44
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.
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
•
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 on page 35 and the “Setting
the Service State of a Signaling Service” section on page 32.
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 MML name of a previously provisioned TCP link.
(restricted)
This parameter is used only for D-channels
associated with QSIG/Q.931 Over BRI Backhaul
signaling services.
Cisco MGC Software Release 9.5(2)
45
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
Table 6
DCHAN Component Structure (continued)
SIGSLOT
SIGPORT
Physical slot on the
media gateway on
which the associated
T1/E1 is terminated
Integer 0 through 63; (0).
Physical port of the
associated slot on the
media gateway
Integer 0 through 167; (0).
Note
Note
SUBUNIT
Required for
QSIG/Q.931 Over BRI
Backhaul D-channels
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.
This parameter can be set to either 0 or 1
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 on page 36 and the “Setting the Service State of a D-Channel”
section on page 33.
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
Cisco MGC Software Release 9.5(2)
46
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
Table 7
MGCP Properties (continued)
Property
Definition
*.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
Cisco MGC Software Release 9.5(2)
47
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
Table 7
MGCP Properties (continued)
Property
Definition
*.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
*.mgcpDomainNameRemote
Additional differences can be handled by adding enumerated values.
Default MGCP remote domain name. It is used to append to the audit command
to send to the remote gateway.
Default: [email protected]
*.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
Cisco MGC Software Release 9.5(2)
48
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.
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
Table 7
MGCP Properties (continued)
Property
Definition
*.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
*.mgcpMaxRspAckToBuffer
Set this value to the same duration as the gateway’s command/response
timeout value.
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
*.T309Time
To prevent possible hung calls on a MGW, the recommended value is
4000.
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.
Cisco MGC Software Release 9.5(2)
49
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
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
Cisco MGC Software Release 9.5(2)
50
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
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
Cisco MGC Software Release 9.5(2)
51
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
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
brisvc1
va-3640-01
Q.931
Call Model
Side
MDO File
ETS_300_102
Cisco MGC Software Release 9.5(2)
52
Customer
Group ID
Call
Reference
Length
Description
1
BRI path to va-3640-01
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
Table 12
QSIG/Q.931 Over BRI Backhaul Signaling Service Worksheet Example (continued)
Name
External
Node
Q.931
Call Model
Side
MDO File
Table 13
Customer
Group ID
Call
Reference
Length
Description
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
Cisco MGC Software Release 9.5(2)
53
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Reference Information
Table 13
Name
Table 14
IP Route Worksheet Example (Optional) (continued)
Destination
Subnet Mask
Next Hop
IP Address
Priority
Backhaul TCP Link Worksheet Example
Name
Signaling
Type
Local
IP Address
Local
Port Number
Destination
IP Address
Destination
Port Number
External
Node
britcp1
bri
175.25.211.17
1024
175.25.211.17
1024
va-3640- n–a
01
Table 15
Description
IP Route
Description
IP route to
va-3640-01
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
Cisco MGC Software Release 9.5(2)
54
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Obtaining Documentation
Table 16
Name
D-Channel Worksheet Example
Signaling Type
brichan1 bri
Priority
Link
Slot
Port
Subunit
Description
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
Cisco MGC Software Release 9.5(2)
55
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Documentation Feedback
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 [email protected].
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
Cisco MGC Software Release 9.5(2)
56
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Obtaining Technical Assistance
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.
Cisco MGC Software Release 9.5(2)
57
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Obtaining Additional Publications and Information
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.
Cisco MGC Software Release 9.5(2)
58
Support for QSIG Over BRI and Q.931 Over BRI Backhaul
Glossary
Table 17
Acronyms (continued)
Acronym
Definition
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.
Cisco MGC Software Release 9.5(2)
59