Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco Catalyst 6500 Series Switches

Catalyst 6500 Series and Cisco 7600 Series Communication Media Module QSIG Backhaul Configuration Note

Downloads

Table of Contents

QSIG Backhaul (RUDP based) for Cisco IOS Gateways Configuration Note
 Feature Overview
 Supported Platforms
 Supported Standards, MIBs, and RFCs
 Prerequisites
 Configuration Tasks
 Monitoring and Maintaining Signaling Backhaul and MGCP
 Configuration Examples
 Command Reference
 backhaul-session-manager
 clear backhaul-session-manager group
 clear rudpv1 statistics
 debug backhaul-session-manager session
 debug backhaul-session-manager set
 debug rudpv1
 group auto-reset
 group cumulative-ack
 group out-of-sequence
 group receive
 group retransmit
 group set
 group timer cumulative-ack
 group timer keepalive
 group timer retransmit
 group timer transfer
 isdn bind-L3
 isdn protocol-emulate
 session group
 set
 show backhaul-session-manager group
 show backhaul-session-manager session
 show backhaul-session-manager set
 show rudpv1
 Glossary

QSIG Backhaul (RUDP based) for Cisco IOS Gateways Configuration Note

Feature History
Release Modification

12.2(11)T

This feature was introduced on the Cisco IAD2420 series, Cisco 2600 series, Cisco 3600 series, and Cisco VG200.

12.2(11)ZC

This feature was introduced on the Catalyst 6500 series and Cisco 7600 series Communication Media Module (CMM).

The QSIG Backhaul (RUDP based) for Cisco IOS Gateways feature describes the implementation of the PRI/Q.931 Signaling Backhaul for the Call Agent Applications. It includes information on the benefits of the new feature, supported platforms, related documents, and configuring the feature.

This document includes the following sections:

Feature Overview

PRI/Q.931 signaling backhaul is the transport of PRI signaling (Q.931 and above layers) between a media gateway (such as a Cisco access server, router, or concentrator) and a media gateway controller (specifically, the Cisco VSC3000). The Media Gateway Controller can also be referred to as a Virtual Switch Controller (VSC). Communication between the media gateway and the media gateway controller is managed by the Media Gateway Control Protocol (MGCP). Figure 1 shows signaling backhaul paths in a typical packet voice network.


Figure 1   PRI Signaling Backhaul


The signaling backhaul takes place between a media gateway and a Cisco VSC3000. A media gateway is an access server, router, or access concentrator that provides an interface between the Public Switched Telephone Network (PSTN) and the packet network world (IP or ATM). The VSC provides call processing and gateway control.

The general principle behind signaling backhaul is to pass as many layers of a protocol stack as possible through a gateway directly to the VSC.

Signaling backhaul usually occurs at a common boundary for all protocols. For ISDN, the signaling backhaul takes place at the boundary between Layer 2 (Q.921) and Layer 3 (Q.931). The lower layers of the protocol are terminated and processed on the gateway. The upper layers of the protocol are backhauled, or transported, to the VSC using Cisco Reliable User Datagram Protocol (RUDP) over IP. RUDP provides autonomous notification of connected and failed sessions and guarantees delivery of signaling protocols across an IP network.

Signaling backhaul provides the additional advantage of distributed protocol processing. This permits greater expandability and scalability, while offloading lower-layer protocol processing from the VSC.

Signaling Backhaul and Backhaul Session Manager

The backhaul session manager is a software function that resides on the Cisco media gateway and manages RUDP sessions on the VSC and gateway.

The backhaul session manager enables signaling applications to backhaul signaling information to a remote or local VSC and provides redundancy and transparent management of transport paths. The backhaul session manager also combines sessions between endpoints into session groups and combines session groups into session sets. In this process the session manager establishes a selection priority for the sessions.

To configure the backhaul session manager, you must create a new session-set, add session-groups to that session-set, and then add sessions to the session-group.

A session is an RUDP connection between two endpoints. An endpoint is defined by the IP address and the User Datagram Protocol (UDP) port.

A session-group is a logically ordered list of sessions based on priority of the sessions. All of the sessions in the session-group must be configured to connect the same physical machines and, for reliability, these sessions can be defined to take different paths through the network. The backhaul session manager always uses the highest priority session available in the session-group to transport all PRI signaling traffic, regardless of the number of sessions configured in the session-group (note that RUDP keepalive traffic would exist on all sessions).

If a session fails while in use, or a higher priority session within the same session group gets established, the backhaul session manager and RUDP support a function in which messages waiting to be transmitted on the current session are transferred to another session automatically, while maintaining guaranteed, in-sequence delivery. This function is sometimes referred to as session failover. Thus, a session-group enables network path redundancy between the gateway and the VSC. A session-group cannot be deleted unless the sessions associated with it are deleted first.

A session-set is a collection of session-groups. A session-set enables VSC redundancy and is used to implement VSC switchover. A session-set cannot be deleted unless the groups associated with it are deleted first.

In a fault-tolerant configuration, a session-set on the media gateway can have more than one session-group, with each session-group connecting the gateway to a different VSC. In a non-fault-tolerant configuration, a session-set on the gateway contains only one session-group, because there is only one VSC available.

Each session-set on the VSC always has one session-group, regardless of the configuration being used.

Benefits

Call Control

Signaling backhaul integrates gateways into a virtual switch with the call control centralized in the Cisco VSC.

Signaling Protocols

The QSI Backhaul (RUDP based) for Cisoc IOS Gateways feature provides the infrastructure to support the backhaul of the ISDN signaling protocol in a non-fault-tolerant manner.

Restrictions

On the Cisco 2600 and Cisco 3600 series, this feature supports FAS D-Channel signaling only.

Related Features and Technologies

The PRI/Q.932 Signaling Backhaul for Call Agent Applications feature is supported by the Media Gateway Control Protocol technology, which is documented in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2

Related Documents

  • Cisco Media Gateway Controller Hardware Installation Guide
  • Regulatory Compliance and Safety Information for Cisco Media Gateway Controller
  • Cisco MGC Software Release 7 Reference Guide, version 2
  • Cisco MGC Release 7 Provisioning Guide (-02)
  • Cisco MGC Software Release 7 Operations, Maintenance, and Troubleshooting Guide
  • Cisco MGC Software Release 7 Installation and Configuration Guide
  • Cisco Media Gateway Controller Software Release Notes (version 7)
  • Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
  • Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2
  • Catalyst 6500 Series and Cisco 7600 Series Communication Media Module Installation and Configuration Note
  • Release Notes for Catalyst 6500 Series and Cisco 7600 Series Communication Media Module Software Release 12.2(11)ZC

Supported Platforms

Supported Platforms

  • Cisco IAD2420 series
  • Cisco 2600 series
  • Cisco 3600 series
  • VG200
  • Catalyst 6500 series and Cisco 7600 series CMM
Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

http://www.cisco.com/register

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

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

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://tools.cisco.com/ITDIT/MIBS/servlet/inde x

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

http://www.cisco.com/register

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites

  • If there are multiple Cisco VSC3000s in the network, E-ISUP signaling connectivity must be in place between them.
  • Data connectivity must be in place between the media gateways in the network.
  • Cisco 2600 and 3600 series media gateways must have a high-density voice network module installed for interface to the PSTN.
  • Cisco CallManager Version 3.3 or a later release.
  • Cisco IOS Release 12.2(11)T or a later release must be running.
  • For the Catalyst 6500 series and Cisco 7600 series CMM, Cisco IOS Release 12.2(11)ZC or a later release must be running.

Configuration Tasks

See the following sections for configuration tasks for the PRI/Q.931 Signaling Backhaul for Call Agent Applications feature. Each task in the list is identified as either required or optional:

Configuring Backhaul Session Manager

The backhaul session manager operates on the media gateway and enables signaling applications to backhaul signaling information to a remote or local virtual switch controller (VSC), and also provides redundancy and transparent management of transport paths.

To configure the backhaul session manager, log onto the media gateway and complete the following tasks as required for your application:

Creating Session-Sets, Session-Groups, and Sessions

To create session-sets, session-groups, and sessions on the Cisco media gateway, complete the following steps beginning in global configuration mode:

  Command  Purpose 
Step 1 
Router(config)# backhaul-session-manager

Enters backhaul session manager configuration mode.
Step 2 
Router(config-bsm)# set set-name client {ft | nft}

Creates a session-set and specifies its parameters:

  • set-name—A word you select to identify the session-set
  • client—Required for PRI backhaul; specifies that the session-set function as a client
  • Fault-tolerance option:
    • ft = Fault-tolerant
    • nft = Non-fault-tolerant

Note For fault-tolerant operation, you must configure more than one group in this session-set. If only one group is configured in this session-set, you must specify nft.

Note If you configure the session-set for non-fault-tolerant operation, you should also configure the VSC for non-fault-tolerant operation. See the "Configuring the Cisco VSC3000" section.
Step 3 
Router(config-bsm)# group group-name set set-name

Adds a new session-group to a specified session-set.

  • group-name—A word you select to identify the new session-group
  • set-name—The session-set to which you are adding the new session-group

Repeat this step to add additional session-groups to a session-set.
Step 4 
Router(config-bsm)# session group group-name remote_ip remote_port local_ip local_port priority

Adds a session to a session-group and specifies the interfaces and selection priority for the session.

  • group-name—The session-group to which you are adding this session
  • remote_ip—IP address of the VSC server at the remote end of this backhaul link
  • remote_port—The UDP port number on the VSC server at the remote end of this backhaul link; The range is from 1024 to 9999; Make sure that this number is not already being used by another service on the VSC, such as Media Gateway Control Protocol (MGCP).
  • local_ip—The IP address of the media gateway port used for signaling backhaul.
  • local_port—The UDP port number of the media gateway port used for signaling backhaul; The range is from 1024 to 9999.
  • priority—The priority within the session-group; The range is from 0 to 9999; 0 is the highest priority.

Note Although the Cisco IOS software allows you to configure multiple sessions with the same priority in a session-group, Cisco Systems recommends that the priority of each session be unique within a session-group.
Step 5 
Repeat Step _(_THISREFOBJ:ol_3972.fm:090019e980a8b7e2:17051:4_ )_ to create additional sessions in a session-group.
 Note To support session failover (fault tolerance), you must configure at least two sessions in a session-group.

Changing the Values of Session-Group Parameters

If you need to change the default values of session-group parameter, use the following commands as required, in backhaul session manager configuration mode:

Caution   Do not change the session-group parameters unless instructed to do so by Cisco technical support. There are relationships between the parameters that can cause sessions to fail if not set correctly.

Command  Purpose 
Router(config-bsm)# group group-name auto-reset number-of-auto-resets

Specifies the maximum number of auto resets before the connection is considered failed.

The range is from 0 to 255. The default is 5.
Router(config-bsm)# group group-name cumulative-ack number-of-segments

Specifies the maximum number of RUDP segments that will be received before sending an acknowledgment.

The range is from 0 to 255. The default is 3.
Router(config-bsm)# group group-name out-of-sequence number-of-segments

Specifies the maximum number of out-of-sequence segments that will be received before an error acknowledgment (EACK) is sent.

The range is from 0 to 255. The default is 3.
Router(config-bsm)# group group-name receive window-size

Specifies the maximum window size for the receiver.

The range is from 1 to 65. The default is 32.
Router(config-bsm)# group group-name retransmit resend-attempts

Specifies the maximum number of times RUDP will attempt to resend a segment before declaring the connection broken.

The range is from 0 to 255. The default is 2.
Router(config-bsm)# group group-name timer cumulative-ack milliseconds

Specifies the maximum number of milliseconds RUDP will delay before sending an acknowledgment for a received segment.

The range is from 100 to 65535. The default is 300.
Router(config-bsm)# group group-name timer keepalive milliseconds

Specifies the number of milliseconds RUDP will wait before sending a keepalive segment.

The range is from 0 to 65535. The default is 200.
Router(config-bsm)# group group-name timer retransmit milliseconds

Specifies the number of milliseconds RUDP will wait to receive an acknowledgment for a segment.

The range is from 100 to 65535. The default is 600.
Router(config-bsm)# group group-name timer transfer-state milliseconds
Router(config-bsm)# exit

Specifies the number of milliseconds RUDP will wait to receive the selection of a new session from the application during a transfer state.

The range is from 0 to 65535. The default is 600.

Configuring ISDN Signaling Backhaul

To configure ISDN to backhaul Q.931 signaling, use the following commands beginning in global configuration mode:

  Command  Purpose 
Step 1 
Router(config)# controller {t1 | e1} slot/port

Enters controller configuration mode.
Step 2 
Router(config-controller)# clock source [internal | line]

Configures the clock source used by the T1 or E1 controller.

The keywords are as follows:

  • internal (Optional)—Specifies that the clocking source is obtained from the port adapter line.
  • line (Optional)—Specifies that the clocking source is obtained from the network.
Step 3 
Router(config-controller)# cablelength long {0db | -7.5db | -15db | -22.5db}

Specifies the cable length longer than 600 feet for a T1 link. The cable length must conform to the actual cable length that you are using. For example, if you attempt to enter the cablelength short command on a long-haul T1 link, the command is rejected.

The keywords are as follows:

  • 0db—Specifies the decibel pulse level at 0 dB. This is the default pulse rate.
  • -7.5db—Specifies the decibel pulse level at -7.5 dB.
  • -15db—Specifies the decibel pulse level at -15 dB.
  • -22.5db—Specifies the decibel pulse level at -22.5 dB.

 

or

 

 

Router(config-controller)# cablelength short {110ft | 220ft | 330ft | 440ft | 550ft | 600ft}

Specifies a cable length 600 feet or less for a T1 link.

The keywords are as follows.

  • 110ft—Specifies a cable length from 0 to 110 feet.
  • 220ft—Specifies a cable length from 111 to 220 feet.
  • 330ft—Specifies a cable length from 221 to 330 feet.
  • 440ft—Specifies a cable length from 331 to 440 feet.
  • 550ft—Specifies a cable length from 441 to 550 feet.
  • 600ft—Specifies a cable length from 551 to 600 feet.

If you do not set the cable length, the system defaults to a setting of cablelength long 0 dB.
Step 4 
Router(config-controller)# pri-group timeslots list-of-timeslots service mgcp

Specifies MGCP as the control protocol used for backhaul. The controller time slots cannot be shared between backhaul and other Layer 3 protocols.
Step 5 
Router(config-controller)# framing {esf | sf | crc4 | no-crc4 | mp-crc4} [australia]

Specifies the framing type on a DS1 link for T1 and E1 PRI. The keywords are as follows:

  • esf—Specifies extended Super Frame as the T1 frame type.
  • sf—Specifies Super Frame as the T1 frame type. This is the default.
  • crc4—Specifies CRC4 frame as the E1 frame type. This is the default for Australia.
  • no-crc4—Specifies no CRC4 frame as the E1 frame type.
  • australia—(Optional) Specifies the E1 frame type used in Australia.
Step 6 
Router(config-controller)# linecode {ami | b8zs | hdb3}

Specifies the line encoding method for a DS1 link. The keywords are as follows:

  • ami—Specifies alternate mark inversion (AMI) as the line-code type. Valid for T1 or E1 controllers. This is the default for T1 lines.
  • b8zs—Specifies B8ZS as the line-code type. Valid for T1 controller only.
  • hdb3—Specifies high-density bipolar 3 (hdb3) as the line-code type. Valid for E1 controller only. This is the default for E1 lines.
Step 7 
Router(config-controller)# exit

Returns to global configuration mode.
Step 8 
Router(config)# interface serial slot/port:timeslot number

Enters serial interface configuration mode.

The arguments and keywords are as follows:

  • slot/port:—Specifies the slot number and port number where the channelized E1 or T1 controller is located.
  • timeslot—Specifies, for ISDN, the D channel time slot, which is the 23 channel for T1 and the 15 channel for E1. PRI time slots are range from 0 to 23 for channelized T1 and range from 0 to 30 for channelized E1. On a dual port card, it is possible to run channelized on one port and primary rate on the other port.

Note The colon (:) is required.

  • number—Specifies the channelized E1 or T1 controller number.
Step 9 
Router(config-if)# isdn switch-type [primary-4ess | primary-5ess | primary-dms100 | primary-ni | primary-net5 | primary-ntt | primary-qsig | primary-ts014]

Configures the ISDN switch type. This configuration can be done in global configuration mode or interface configuration mode.

The keywords are as follows:

  • primary-4ess (Optional)—Specifies electronic switching system (ESS) 4.
  • primary-5ess (Optional)—Specifies ESS 5 that works with T1.
  • primary-dms-100 (Optional)—Specifies the DMS 100 switch that works with T1 and E1 PRI.
  • primary-ni (Optional)—Specifies an NI switch that works with T1.
  • primary-net5 (Optional)—Specifies a Net5 switch that works with E1.
  • primary-ntt (Optional)—Specifies the Japanese T1 and E1 PRI switch.
  • primary-qsig (Optional)—Supports QSIG signaling per Q.931. Network side functionality is assigned with the isdn protocol-emulate command.
Step 10 
Router(config-if)# isdn protocol-emulate {user | network}

Specifies the ISDN protocol emulation. The default is the user-side ISDN protocol. The keywords are as follows:

  • user—Specifies Layer 2 and Layer 3 port protocol operation as TE (port functions as QSIG slave).
  • network—Specifies Layer 2 and Layer 3 port protocol operation as NT (port functions as QSIG master).

Repeat this procedure for each T1 interface on the media gateway that will utilize backhaul.

Configuring Fast Ethernet for Signaling Backhaul Compatibility

If your media gateway has 10/100 Base T Fast Ethernet capability, configure the Fast Ethernet interface not to use auto-negotiation.

Caution   When the Fast Ethernet interface is configured for autonegotiation, it can take as much as two seconds for this interface to be enabled when the interface has to initialize. Two examples of when the interface initializes are the running of the no shut command and disconnection or reconnection of the Ethernet cable. Autonegotiation affects the traffic flow on the Ethernet interface, and can therefore interrupt the traffic flow on existing RUDP connections, causing them to fail. To avoid these problems, the Fast Ethernet interface should not be configured for autonegotiation. Instead, the duplex and speed parameters should be set according to the requirements of the network.

To reconfigure the Fast Ethernet interface for specified duplex and speed operation, complete the following steps beginning in global configuration mode:

  Command  Purpose 
Step 1 
Router(config)# interface Ethernet-port-number

Enters Ethernet interface configuration mode for the specified Ethernet port.
Step 2 
Router(config-if)# duplex {full | half}

Configures the Ethernet port for full-duplex or half-duplex operation.
Step 3 
Router(config-if)# speed {10 | 100}

Configures the Ethernet port to operate at 10 Mbps or 100 Mbps.
Step 4 
Router(config-if)# exit

Exits from interface configuration mode.

Configuring the Cisco VSC3000

The Cisco VSC3000 is the signaling controller software that provides call control and runs on a UNIX server such as a Sun Netra 1800. Man Machine Language (MML) is the user interface into the signaling controller software. You use this interface to configure parameters of your signaling controller software and to display information about the current settings.

To configure the Cisco VSC3000 to perform signaling backhaul, log onto the UNIX server and complete the MGCP service provisioning procedure as follows:

  Command  Purpose 
Step 1 
mml> prov-add:extnode:name=media-gateway-name,

Assigns a name to the media gateway (the external node) at the far end of a backhaul link.

 
desc=media-gateway-name

Provides a description of the media gateway.
Step 2 
mml> prov-add:ipfaspath:name=ipfaspath-name,

Adds an IP path for D-channel transport (ipfaspath) from the Cisco VSC3000 to a media gateway and assigns it a path name.

 
extnode=media-gateway-name,

Specifies the media gateway (external node) at the opposite end of the IP path; the name must match the media gateway name assigned in Step 1.

 
mdo=ISDN-varient,

Specifies the ISDN variant. Options include:

  • ETSI_300_102
  • ETSIS_300_102_C1
  • ATT_41459
  • ATT_41459_C2
  • BELL_1268
  • ETSI_300_172
  • BELL_1268_C3
  • NTT_INS_1500
  • ETS_300_121.

 
custgrpid=customer-group-ID,

Assigns a customer group ID (the dial plan to use for this connection).

 
side=equipment-location,

Defines the Cisco VSC3000 as network side or user side. The Cisco VSC3000 is normally network side, opposite to the PBX, which is normally the user side. Enter network, or user,.

desc=description

Describes the function of this IP path (backhaul service to a specified media gateway.
Step 3 
mml> prov-add:iplnk:name=iplink-name,

Adds an IP link for the PRI D-channel and assigns it a name.

 
if=enifinterface-number,

The Ethernet interface name for the Cisco VSC3000 Ethernet card (typically enif1).

 
ipaddr=IP_Addrnumber,

The IP address of the Cisco VSC3000 Ethernet port as defined in ../etc/XECfgParm.dat (for example, IP_Addr1).

 
port=port-number,

The port number on the Cisco VSC3000.

 
pri=priority-number,

The selection priority of this IP link. (1, 2, etc.; this should match the selection priority specified on the media gateway for this IP link.)

 
peeraddr=IP-address,

The IP address of the media gateway.

 
peerport=port-number,

The port number on the media gateway; does not have to match the VSC port.

 
sigslot=slot-number,

The physical card slot in the media gateway.

 
sigport=port-number,

The PRI port number in the media gateway (same as the T1/E1 controller number).

 
svc=ipfaspath-name,

The IP path that this IP link is assigned to, which matches the ipfaspath-name assigned in Step 2.

 
desc=description

Optional description of this IP link.
Step 4 
mml>prov-add:mgcppath:name=MGCP-path-name,

Defines an MGCP control path.

 
extnode=ipfaspath-name,

Associates the MGCP control path with an IP path for D-channel transport. The ipfaspath-name must match the ipfaspath-name specified in Step 2.

 
desc=description

Optional description of this MGCP control path.
Step 5 
mml>prov-add:iplnk:name=clink6,

Adds an IP link for the MGCP control path.

 
if=enif1,

The Ethernet interface name for the Cisco VSC3000 Ethernet card (typically enif1).

 
ipaddr=IP_Addrnumber,

The IP address of the Cisco VSC3000 Ethernet port as defined in ../etc/XECfgParm.dat (for example, IP_Addr1).

 
port=2427,

The port used by the IP link for the MGCP control path on the Cisco VSC3000 (2427 is predefined for MGCP use).

 
peeraddr=IP-address,

The IP address of the media gateway connected to this IP link.

 
peerport=2427,

The IP port at the media gateway for this IP link (2427 is predefined for MGCP use).

 
svc=mgcp-service-name,

A name of the MGCP signaling service supported by this IP link.

 
pri=1,

Selection priority for this IP link(1, 2, etc.)

 
desc=description

Optional description of the IP link for the MGCP control path.

Note   If the Cisco VSC3000 is set up for fault-tolerant operation, configure the backhaul session manager also for fault-tolerant operation. For more information, refer to the Cisco MGC Software Release 7 Provisioning Guide.

Configuring MGCP

To configure Media Gateway Control Protocol (MGCP) on the Cisco media gateway, perform the following steps beginning in global configuration mode:

  Command  Purpose 
Step 1 
Router(config)# mgcp

Starts the MGCP daemon.
Step 2 
Router(config)# mgcp request timeout timeout

Specifies how long the gateway should wait for a response to a request.
Step 3 
Router(config)# mgcp request retries count

Specifies the number of times to retry sending the mgcp command.
Step 4 
Router(config)# mgcp call-agent {ipaddr | hostname} [port]

Configures the address of the call agent.
Step 5 
Router(config)# mgcp max-waiting-delay value

Configures the maximum waiting delay to be used in an RSIP message as restart instructions for the call agent.
Step 6 
Router(config)# mgcp restart-delay value

(Optional) Configures the restart delay value to be used in an RSIP message as graceful tear down instructions for the gateway connection.
Step 7 
Router(config)# mgcp vad

(Optional) Configures voice activity detection.
Step 8 
Router(config)# mgcp package-capability
{as-package | atm-package | ddtmf-package | gm-package | rtp-package | trunk-package}

Specifies an MGCP package capability.
Step 9 
Router(config)# mgcp default-package
{as-package | atm-package | dtmf-package | gm-package | rtp-package | trunk-package}

Configures the default package capability type.
Step 10 
Router(config)# mgcp quality-threshold {hwm-jitter-buffer value | hwm-latency value | hwm-packet-loss value | lwm-jitter-buffer value | lwm-latency value | lwm-packet-loss value}

(Optional) Configures the jitter buffer size, packet-loss threshold, and latency threshold.
Step 11 
Router(config)# mgcp playout {adaptive init-value min-value max-value} | {fixed init-value}

(Optional) Tunes the jitter buffer packet size used for MGCP connections.
Step 12 
Router(config)# mgcp codec type [packetization-period value]

(Optional) Configures the default codec type.
Step 13 
Router(config)# mgcp ip-tos {high-reliability | high-throughput | low-cost | low-delay | precedence value}

(Optional) Enables the IP Type of Service for MGCP connections.
Step 14 

Router(config)# controller T1 0

Selects the T1 controller 0.
Step 15 

Router(config-controller)# mode atm

Specifies that the controller will support ATM encapsulation and create ATM interface 0.

When the controller is set to ATM mode, the following takes place:

  • Controller framing is automatically set to Extended SuperFrame (ESF).
  • The linecode is automatically set to B8ZS.
Step 16 

Router(config-controller)# no shutdown

Activates the controller.
Step 17 

Router(config-controller)# exit

Exit controller configuration mode.
Step 18 

Router(config)# controller T1 1

(For CAS PBX Scenarios only) Selects the T1 controller 1.
Step 19 

Router(config-controller)# mode cas

(For CAS PBX Scenarios only) Specifies that the controller will support CAS.
Step 20 

Router(config-controller)# ds0-group channel-number timeslots range type signaling-type tone type addr info service service-type

(For CAS PBX Scenarios only) Configures the T1 timeslots for CAS calls. The scenarios use the following three DS0 definitions:

ds0-group 1 timeslots 1-8 type e&m-immediate-start

ds0-group 2 timeslots 9-16 type e&m-wink-start

ds0-group 3 timeslots 17-24 type fxs-ground-start
Step 21 

Router(config-controller)# exit

(For CAS PBX Scenarios only) Exits controller configuration mode.
Step 22 

Router(config)# interface atm0 [subinterface-number [multipoint | point-to-point]]

Enters interface configuration mode to configure ATM interface 0 or an ATM subinterface.

The default for subinterfaces is multipoint.

(For all Scenarios) Set up three subinterfaces for point-to-point.
Step 23 

Router(config-if)# pvc [name] vpi/vci

Creates an ATM PVC for voice traffic and enter ATM virtual circuit configuration mode.

Note The ilmi and qsaal options are not supported for AAL2.
Step 24 

Router(config-if-atm-vc)# encapsulation aal-encap

Sets the encapsulation of the PVC for voice traffic. aal2 automatically creates channel identifiers (CIDs) 1 through 255.

Some of the scenarios use aal5snap for ATM0.1 and ATM0.3. Use aal2 for ATM0.2.
Step 25 

Router(config-if-atm-vc)# vbr-rt peak-rate average-rate [burst]

Configures the PVC for the variable-bit-rate real-time (voice) traffic. Guidelines for setting the peak rate, average rate, and burst size are as follows:

  • Peak rate — If it does not exceed your carrier's allowable rate, set to the line rate (for example, 1536 kbps for T1-ATM).
  • Average rate — Calculate according to the maximum number of calls the PVC will carry times the bandwidth per call. The following formulas give you the average rate in kbps:
For VoIP

G.711 with 40 or 80 byte sample size — max calls x 128K

G.726 with 40 byte sample size: — max calls x 85K

G.729a with 10 byte sample size — max calls x 85K

For VoAAL2

G.711 with 40 byte sample size — max calls x 85K

G.726 with 40 byte sample size — max calls x 43K

G.729a with 10 byte sample size — max calls x 43K

If voice activity detection (VAD) is enabled, the bandwidth usage is reduced by as much as 12 percent with the maximum number of calls in progress. With fewer calls in progress, bandwidth savings are less.

  • Burst size — Set the burst size as large as possible, and never less than the minimum burst size. Guidelines are as follows:

The minimum burst size is 4 x the number of voice calls.

The maximum burst size is the maximum allowed by the carrier.
Step 26 

Router(config-if-atm-vc)# vcci pvc-identifier

Assigns a unique identifier to the PVC.
Step 27 

Router(config-if-atm-vc)# exit

Exits ATM virtual circuit configuration mode.
Step 28 

Router(config-if)# exit

Exits interface configuration mode.
Step 29 

Router(config)# dial-peer voice number pots

Enters dial peer configuration mode for the POTS dial peer.
Step 30 

Router(config-dial-peer)# application MGCPAPP

Initiates the MGCP protocol for the voice ports.

Verifying the Configuration

Step 1   Enter the show isdn status command to verify successful ISDN configuration for backhaul. The following output shows that Layers 1, 2, and 3 are enabled and active. Layer 3 shows the number of active ISDN calls.

In the following example, notice that the Layer 2 protocol is Q.921, and the Layer 3 protocol is BACKHAUL. This verifies that the Cisco VSC3000 is configured to backhaul ISDN. Also, if you are connected to a live line, you should see that Layer 1 status is ACTIVE, and Layer 2 state is MULTIPLE_FRAME_ESTABLISHED. This means that the ISDN line is up and active.

Router# show isdn status
*00:03:34.423 UTC Sat Jan 1 2000
Global ISDN Switchtype = primary-net5
ISDN Serial1:23 interface
        dsl 0, interface ISDN Switchtype = primary-net5
        L2 Protocol = Q.921  L3 Protocol(s) = BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        NLCB:callid=0x0, callref=0x0, state=31, ces=0 event=0x0
        NLCB:callid=0x0, callref=0x0, state=0, ces=1 event=0x0