cc/td/doc/product/voice/ics/ics24
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring the Cisco ICS 7750
Best Practices for Using the IOS CLI
Setting the System Date and Time
Configuring the SSP
Configuring MRPs and ASIs
Network Security Considerations
Configuring Cisco CallManager
Running Network Time Protocol
Installing and Configuring Cisco Unity Voice Messaging
Configuring the System for Voice Mail

Configuring the Cisco ICS 7750


Many tasks are required for fully configuring the Cisco Integrated Communications System 7750 (Cisco ICS 7750) for data and voice routing. This chapter lists common tasks required to configure the Cisco ICS 7750, gives pointers to Cisco IOS and Cisco CallManager documentation that tells how to perform these tasks, and describes any differences between configuring Cisco IOS or Cisco CallManager software on the Cisco ICS 7750 and configuring Cisco IOS or Cisco CallManager on other platforms.

This chapter contains these sections:

Best Practices for Using the IOS CLI

ICS System Manager is designed to communicate with and to monitor the status of all the components in the chassis. To enable ICS System Manager to perform these functions, a configuration program (ICSConfig) guides you through the configuration process. ICSConfig enables you to change key system parameters, such as the IP addresses of system cards, passwords, destination for syslog messages, and Simple Network Management Protocol (SNMP) community strings.

To enable ICS System Manager to properly function as a system management tool, it is important that you use ICSConfig or ICS System Manager, as appropriate, rather than the IOS command-line interface (CLI), when you enter key system parameters.

Except for the procedures listed in "ICSConfig Tasks," you can enter all IOS CLI commands that are available for use in any IOS software release that is intended for use on the Cisco ICS 7750.

ICSConfig Tasks

You should always use ICSConfig for the following tasks:


Note    SNMP community strings and system passwords are case sensitive.

The following list includes tasks that should never be configured on the Cisco ICS 7750 by using the IOS CLI under any circumstances:

Saving Configuration Changes

To prevent loss of the ASI or MRP configuration, save the running-config file to the startup-config file by following these steps:

Command Purpose
Step 1 

MRP> enable

Password: password

MRP# 

Enters enable mode. You have entered enable mode when the prompt changes to MRP#.

Step 2 

MRP# copy running-config startup-config

Saves the configuration changes to the startup-config file so that they are not lost during resets, power cycles, or power outages.

Setting the System Date and Time

This section explains how to set the date and time on Cisco ICS 7750 cards. It contains the following tasks:

Setting the Date and Time on SPE310 Cards

Complete the following steps to set the date and time on Cisco System Processing Engine 310 (SPE310) cards:


Step 1   On your PC, choose Start > Programs > Terminal Services Client > Client Connection Manager.

Step 2   Use the Client Connection Manager to open a Terminal Services Client connection with the SPE310:

Step 3   Log in as an administrator (user ID administrator), and enter your password (the default is changeme).

Step 4   On the SPE310, choose Start > Settings > Control Panel > Date/Time.

The Date/Time Properties dialog opens.

Step 5   Fill in the necessary fields. Click OK to close the Date/Time Properties dialog box.

Step 6   Repeat Step 2 through Step 6 for any additional SPE310s, if present.



Setting the Date and Time on SSP, MRP, and ASI Cards

The system switch processor (SSP) card, multiservice route processor (MRP) cards, and analog station interface (ASI) cards each have a system clock that begins to run from the point at which the card starts up. The system clock keeps track of the date and time. The SSP stores its configuration data in Flash-simulated NVRAM. The MRP300, MRP3-8FXS, and MRP3-16FXS cards store their configuration data in NVRAM. The MRP200, ASI81, and ASI160 cards obtain their configuration data from the SPE310 running System Manager when they boot.

When you set the date and time, the setting remains accurate until the next card restart.


Note   When changing the date and time settings on SSP, MRP, and ASI cards, open a Telnet session from the PC, not from the SPE310. If you open a Telnet session from the SPE, the changes you make to the card configuration are not saved.

Complete the following steps to set the date and time on the SSP card and MRP cards:


Step 1   From the PC, choose Start > Run.

Step 2   Enter the following command to open a Telnet session:

telnet IP address

where IP address is the IP address of the card with which you wish to communicate.

Step 3   Enter your login password.

Step 4   Enter privileged EXEC mode by entering the following command:

ICS7750> enable

Step 5   Enter your enable password.

Step 6   To enter global configuration mode, enter the following command:

ICS7750# configure terminal

Step 7   To set the time zone, enter the following command in global configuration mode:

ICS7750(config)# clock timezone zone hours [minutes]

where:

For example, to set the time to PST, eight hours offset from UTC, enter the following command:

ICS7750(config)# clock timezone PST -8

Table 6-1 lists the time zones in North America and their offsets from UTC.

Table 6-1   North American Time Zones

Time Zone Abbreviation UTC Offset

Atlantic Standard Time

AST

-4 hours

Atlantic Daylight Saving Time

ADT

-3 hours

Eastern Standard Time

EST

-5 hours

Eastern Daylight Saving Time

EDT

-4 hours

Central Standard Time

CST

-6 hours

Central Daylight Saving Time

CDT

-5 hours

Mountain Standard Time

MST

-7 hours

Mountain Daylight Saving Time

MDT

-6 hours

Pacific Standard Time

PST

-8 hours

Pacific Daylight Saving Time

PDT

-7 hours

Hawaiian Standard Time

HST

-10 hours

Alaska Standard Time

AKST

-9 hours

Alaska Standard Daylight Saving Time

AKDT

-8 hours

Step 8   To set the clock for a card, enter one of the following IOS commands in privileged EXEC mode:

ICS7750(config)# clock set hh:mm:ss day month year

or

ICS7750(config)# clock set hh:mm:ss month day year

where:


Note    This step must be performed after every reboot of the Cisco ICS 7750.

Step 9   To exit global configuration mode, enter the following command:

ICS7750(config)# exit

Step 10   To save your configuration, enter the following command:

copy running-config startup-config

Step 11   To verify your settings, enter the following command:

show clock

Step 12   Repeat Step 3 through Step 12 for additional cards, as necessary.

Step 13   Close the Telnet session by typing exit at the prompt.



Configuring the SSP

The SSP is an eight-port switching module in the Cisco ICS 7750. It has two external ports for connecting to external network devices and has six internal ports for connecting to the other cards in the Cisco ICS 7750.

The SSP serves the following purposes:

Features

The SSP provides the following features:


Note    Hot-swapping the SSP will result in system downtime since all the cards in the ICS 7750 chassis will lose connectivity during the swap.

SSP Configuration Tasks

The SSP is, in the default configuration, network-ready. In most network configurations, the SSP will not require any additional configuration. However, many settings on the SSP are configurable. Table 6-2 lists tasks that you may need or want to perform in order to configure the SSP. In addition, Table 6-2 gives pointers to the locations in the Catalyst 2900 XL and Catalyst 3500 Software Configuration Guide that provide instructions for performing those tasks. The Catalyst 2900 XL and Catalyst 3500 Software Configuration Guide is available at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/29_35wc/sc/index.htm

Table 6-2   SSP Configuration Tasks

Tasks Documentation Locations

Configuring System Settings

Managing the ARP Table

Configuring Device Settings

Controlling IP Multicast Packets Through CGMP

 

Configuring STP

 

Configuring UniDirectional Link Detection

 

Configuring Protected Ports

Configuring Port Settings

Creating EtherChannel Port Groups

 

Enabling SPAN

 

Configuring Flooding Controls

 

Configuring Voice Ports

Configuring VLAN Settings

Assigning VLAN Port Membership Modes

 

Overlapping VLANs and Multi-VLAN Ports

 

Using VTP

 

VTP Version 2

 

VTP Pruning

 

VLANs in the VTP Database

 

How VLAN Trunks Work

 

Configuring 802.1p Class of Service

 

Load Sharing Using STP

 

How the VMPS Works

Configuring Security Settings

Managing the MAC Address Tables

 

Enabling Port Security

 

Configuring TACACS+

Configuring MRPs and ASIs

This section explains how to configure MRP and ASI cards and contains the following sections:

System Card Overview

This section lists the key features of the MRP200, MRP300, ASI81, ASI160, MRP3-8FXS, and MRP3-16FXS system cards.

Key Features of MRP200 and MRP300 Cards

MRP200 and MRP300 cards have the following features:

Key Features of ASI81, ASI160, MRP3-8FXS, and MRP3-16FXS Cards

The key features of the ASI81, ASI160, MRP3-8FXS, and MRP3-16FXS cards are delineated below:

Supported WICs, VICs, and VWICs

For a list of the WICs, VICs, and VWICs that are supported in MRP200, MRP300, MRP3-8FXS, and ASI81 cards, refer to the Cisco ICS 7750 System Description . For information about valid combinations of WICs, VICs, and VWICs on MRP and ASI cards, see "PVDM Requirements."

Codec/DSP Overview

VICs and VWICs installed in MRP cards or ASI cards might require additional digital signal processors (DSPs) for processing heavier voice traffic. Each DSP can perform a maximum of 100 million instructions per second (MIPS).

You can install up to two packet voice/data modules (PVDMs) on each MRP or ASI card. PVDMs contain DSP chips that give MRP and ASI cards more processing power.

Voice Compression Algorithms (Codecs)

The Cisco ICS 7750 supports several options for voice-compression algorithms. These algorithms are commonly called codecs. The word codec is a combination of the words coder and decoder. Coding is the process of encoding a digitized signal into a more efficient form for transmission or storage. Decoding is the process of restoring the coded signal to the original form.

Codecs differ in terms of voice quality, compression rate and bandwidth, ability to carry dual-tone multifrequency (DTMF) and modem traffic, and number of channels (calls) that a single DSP can support. The more DSP channels, the greater the number of calls that an MRP or ASI card can support. The number of channels supported also depends on whether the DSP is running a digital image or it is running an analog image. (Digital T1 and E1 VWICs process digital signals, and analog VICs process analog signals.)

As Table 6-3 shows, some codec compression techniques require more processing power than others. Multiple DSP firmware images are available for use on MRP and ASI cards. High-complexity images support fewer calls than medium-complexity images.

Table 6-3   MRP and ASI Card Codec Options

Channels per DSP—
Digital Image1
Channels per DSP—
Analog Image
Codec Bandwidth Medium Complexity High Complexity Medium Complexity2 High Complexity3

G.711

64 kbps

8

6

4

2

G.723.1

5.3 or 6.3 kbps

none

2

none

2

G.726

32, 24, or 16 kbps4

none

3

4

2

G.729a

8 kbps

4

3

4

2

Fax Relay

Variable

none

3

4

2

1VWICs (VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, and VWIC-2MFT-E1) require digital DSP software.

2Medium-complexity analog DSP software supports 8- and 16-port FXS modules (in the ASI 81 and the ASI 160, respectively).

3High-complexity analog DSP software supports all 2-port analog VICs (VIC-2DID, VIC-2BRI-NT/TE, VIC-2FXS, VIC-2FXO-M1, VIC-2FXO-M2, VIC-2FXO-M3, VIC-2FXO, and VIC-2E/M) and the 8- and 16-port FXS modules (in the ASI 81 and the ASI 160, respectively).

432 kbps = 2:1 compression, 24 kbps = 3:1 compression, and 16 kbps = 4:1 compression.

G.711

G.711 performs pulse code modulation (PCM) and is the standard digital channel used in the public telephone network. PCM provides no compression and therefore no opportunity for bandwidth savings. Any services that operate over the public network should operate with similar performance over a Cisco ICS 7750 PCM channel (although the Cisco ICS 7750 connection might have more delay).

G.723.1

G.723.1 is a compression technique that uses multi-pulse, multi-level quantization (MP-MLQ) or code excited linear prediction (CELP) coding to compress speech or audio signal components at 5.3 or 6.3 kilobits per second (kbps), respectively. G.723.1, which is part of the H.324 family of standards, can be used for compressing speech or audio signal components at very low bit rates. G.723.1 Annex-A provides built-in voice activity detection (VAD) and Comfort Noise Generation (CNG).

G.726

G.726 performs adaptive differential pulse code modulation (ADPCM) coding. G.726 reduces network bandwidth requirements for transmitting voice by encoding 64 kbps voice channels as 32, 24, or 16 kbps ADPCM (that is, 32 kbps provides 2:1 compression, 24 kbps provides 3:1 compression, and 16 kbps provides 4:1 compression). Generally, there is a trade-off between the amount of compression and voice quality. ADPCM-encoded voice can be interchanged between packet voice, PSTN, and private branch exchange (PBX) networks if the PBX networks are configured to support ADPCM.

G.729

G.729 performs CELP coding, where voice is coded into 8-kbps streams. There are two variations of this standard (G.729 and G.729 Annex A [G.729a]) that differ mainly in terms of their computational complexity; both provide speech quality similar to 32-kbps ADPCM. G.729 is a high complexity algorithm, and G.729a is a medium complexity variant of G.729 with slightly lower voice quality. G.729a performs conjugate structure algebraic code excited linear predictive (CS-ACELP) coding, providing speech quality similar to 32-kbps ADPCM. G.729a offers the best compression rate (8:1), but it does not typically carry modem traffic, and it degrades DTMF and music signals somewhat. Depending on the type of traffic, using G.729a can produce cost savings of 40 percent, relative to using G.711. Other algorithms in the G.729 family include G.729 Annex-B, a high complexity algorithm, and G.729a Annex-B, a medium-complexity variant of G.729 Annex-B with slightly lower voice quality. The difference between the G.729 and G.729 Annex-B codecs is that G.729 Annex-B provides built-in VAD and CNG.

Codec Interoperability

Codec interoperability is the ability of one codec to decode another codec. If a DSP is configured with a certain codec, the DSP should be able to decode the voice codec using any codec with which the DSP is interoperable.

The following G.729 codec combinations interoperate:

The following G.723.1 codec combinations interoperate:

Delay

Delay is the time it takes for packets to travel between two endpoints. In traditional data networking, delay can be tolerated with little or no impact on network users; however, in networks carrying voice traffic, delay is potentially quite significant because it can affect the ability of users to carry on a telephone conversation. For example, delay can introduce pauses or gaps in the conversation, increasing the likelihood that one person will start talking before the other person has finished.

Because of the speed of network links and the limited processing power of many devices, some delay is expected. Telephone users normally accept up to about 150 milliseconds (ms) of delay without noticing problems. You can measure delay by using ping tests at various times of the day with different network traffic loads. If network delay is excessive, reduce it before deploying a network that carries Voice over IP (VoIP) traffic.

The two types of delay most commonly found in today's telephony networks are propagation delay and handling delay. Propagation delay is caused by the characteristics of the speed of light traveling via a fiber-optic-based or copper-based medium. Handling delay (sometimes called serialization delay) is caused by the devices that handle voice information. Handling delays have a significant impact on voice quality in a packetized network. Codec-induced delays are considered a handling delay.

Table 6-4 shows the delay that is introduced by different codecs.

Table 6-4   Delay Introduced by Codecs

Compression Method Bit Rate (kbps) Compression Delay (ms)

G.711 PCM

64.0

0.75

G.726 ADPCM

32.0

1

G.729 CS-ACELP

8.0

10

G.729a CS-ACELP

8.0

10

G.723.1 MP-MLQ

6.3

30

G.723.1 ACELP

5.3

30

DSP Groups

ASIs and MRPs handle calls based on the grouping of the DSPs. The DSPs are located on PVDMs. There can be up to five DSPs on a single PVDM. Each PVDM corresponds to one DSP group. MRP200 and MRP300 cards each have two PVDM slots and, therefore, can have a maximum of two DSP groups. Each DSP group serves either an analog port or a T1 port on the VIC. Therefore, one analog VIC and one T1 VWIC make up two groups, and two T1s with two different clock sources (regardless of whether they are on the same VWIC) also make up two groups.

DSP Group Serving a T1 Port

Each DSP group that serves a T1 port can support as many DSPs as there are in the PVDM.

A DSP has a maximum capacity of 100 MIPS to handle a particular number of simultaneous calls. One G.729a call requires 25 MIPS, and one G.711 call requires 12.5 MIPS. The number of calls on a DSP is determined by the total MIPS used reaching 100 on that DSP. The DSP resource manager rejects a call if it cannot find a DSP with required unused MIPS for the selected codec.

Table 6-5 provides some examples of the number of calls that can be supported on a single DSP, depending on the codec used. Table 6-6 lists some of the combinations of calls that can be handled on a single DSP.


Note   The examples provided in Table 6-5 and Table 6-6 are based on the assumption that you are using a medium-complexity digital image.

Table 6-5   Codec/DSP Call-Processing Examples

Scenarios Calls per DSP Codecs MIPS per Session MIPS Required Call Status

1

4

G.729a

25

25 x 4 = 100

4 calls accepted

2

8

G.711

12.5

12.5 x 8 = 100

8 calls accepted

3

4

1

G.729a

G.711

25

12.5

25 x 4 = 100

12.5 x 1 = 12.5

 

1 call rejected

Table 6-6   Sample Combinations of Calls on a Single DSP

G.711 Calls G.729a Calls

2

3

4

2

6

1

DSP Group Serving Analog Ports

Each DSP group that serves analog ports requires the following:

Choosing Codecs

This section provides information that can help you choose the DSP image that is best suited for a particular type of traffic. The following are some common scenarios:

Choosing DSP Firmware

When you choose DSP firmware, it is important to consider the following factors:

DSP firmware is included with each IOS release for the Cisco ICS 7750. Five DSP firmware images are available for use on ASI and MRP cards. Two of the DSP firmware images are intended for MRP200 and MRP300 cards (which contain analog VICs) and for MRP3-8FXS and ASI81 cards (which contain FXS ports); two images are intended for digital trunks (such as T1 CAS and T1/E1 PRI); and one image is intended for transcoding.

Each DSP firmware image supports a particular set of codecs. High-complexity DSP firmware supports more codecs than medium-complexity firmware supports. However, in order to support more codecs, the number of voice channels supported by the firmware has to be reduced.

Table 6-7 lists the number of channels supported by the DSP firmware images.


Note   The abbreviations FIXHC, FIXMC, FLEX6, FLEX8, and XCODE represent the names of the firmware images. These abbreviations appear in the output from the show voice dsp command.

Table 6-7   Number of Channels Supported by DSP Firmware Images

DSP Firmware Image Codec Number of Channels per DSP Cards Supported

High-Complexity Analog (FIXHC)

G.711, G.726, G.729 Annex-B, G.723.1, fax relay

2

  • All 2-port analog VICs1
  • 8-port and 16-port FXS modules (ASIs)
  • VIC-2BRI-NT/TE

Medium-Complexity Analog (FIXMC)

G.711, G.726, G.729a Annex-B, fax relay

4

8-port and 16-port FXS modules (ASIs)

High-Complexity Digital (FLEX6)

G.711, G.726, G.729a Annex-B, G.723.1, fax relay

  • 6 (G.711)
  • 3 (G.729a Annex-B)
  • 3 (G.726)
  • 3 (fax relay)
  • 2 (G.723.1)

All digital VWICs2

Medium- Complexity Digital (FLEX8)

G.711, G.726, G.729a Annex-B

  • 8 (G.711)
  • 4 (G.729a Annex-B)
  • 4 (G.726)

All digital VWICs

Transcoding (XCODE)

G.711, G.726, G.729 Annex-B, G.723.1

2

Not applicable

1VIC-2DID, VIC-2E/M, VIC-2FXS, VIC-2FXO, VIC-2FXO-M1, VIC-2FXO-M2, VIC-2FXO-M3.

2VWIC-1MFT-T1, VWIC-2MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-E1.

Determining How Many DSPs Are Needed

The number of DSPs needed for each voice interface depends on the following two factors:

Table 6-8 shows how to calculate the number of DSPs needed for each channel. For example, with a medium-complexity analog image and a G.726 codec, 1 DSP is needed for 4 voice interfaces.


Note   For additional information on PVDM selection, refer to the "PVDM Requirements" appendix in the Cisco ICS 7750 Hardware Installation Guide .

Table 6-8   DSP Configuration Rules

Type of Card Suggested Number of DSPs Suggested DSP Firmware Total Voice Channels Codecs Supported

All 2-port analog VICs 1

1 (PVDM-4)

High-complexity analog

2

All2

VIC-2BRI-NT/TE

2 (PVDM-8)

High-complexity digital

4

All

ASI81 (8-port FXS module in slot 0)

2 (PVDM-8)

Medium-complexity analog

8

All except G.723.1

4 (PVDM-16)

High-complexity analog

8

All

ASI160 (16-port FXS module)

4 (PVDM-16)

Medium-complexity analog

16

All except G.723.1

8 (2 PVDM-16)

High-complexity analog

16

All

MFT-T1

4 (PVDM-16)

High-complexity digital

24

G.711

8 (2 PVDM-16)

High-complexity digital

24

G.729a

MFT-E1

 

5 (PVDM-20)

High-complexity digital

30

G.711

10 (2 PVDM-20)

High-complexity digital

30

G.729a

1VIC-2DID, VIC-2E/M, VIC-2FXS, VIC-2FXO, VIC-2FXO-M1, VIC-2FXO-M2, VIC-2FXO-M3.

2The codecs supported on the Cisco ICS 7750 are G.711, G.723.1, G.726, and the G.729 family.


Note   Table 6-8 does not address configuration rules for transcoding. See the "Determining How Many DSPs Are Needed for Transcoding" section.


Note   On MFT-T1 and MFT-E1 cards, medium-complexity firmware is not recommended, because this firmware restricts echo cancellation coverage to 16 ms.


Note   The codec complexity for ASI cards defaults to medium-complexity but can be changed to high-complexity with sufficient DSPs (see Table 6-8).

Transcoding

Because some hardware and software currently support only G.711 (uncompressed) connections, transcoding is available on MRP and ASI cards. MRP and ASI cards are considered packet-to-packet gateways because they have DSPs that transcode between voice streams using different compression algorithms. For example, when a user on a Cisco IP Phone at a remote location calls a user at the central location, Cisco CallManager can be configured so that it causes the remote IP phone to use compressed voice (G.729a) for the WAN call. However, if the called party at the central site is unavailable, the call potentially could be routed to an application that supports only G.711. In this case, the MRP or ASI card transcodes the G.729a voice stream to G.711 so that a voice message is stored by the G.711-compliant voice-messaging server.

Transcoding is required when a compressed voice stream is used to save WAN bandwidth and when the local device does not support the codec. The transcoding service compresses and decompresses voice streams to match the capabilities of the endpoint device.

A transcoder is a device that takes the output stream of one codec and transcodes (converts) it from one compression type to another compression type. For example, a transcoder could take an output stream from a G.711 codec and transcode (convert) it in real time to a G.729 input stream accepted by a G.729 codec.

Transcoding is supported under the following conditions:

Deciding When to Use Transcoding

Transcoding is needed when the calling and called parties cannot use the same codec type. Codec incompatibility may result from of a lack of support for a particular codec. For example, some unified messaging systems support only G.711, while Cisco IP Phones support G.711 and G.729. (Note that Cisco Unity supports both G.729a and G.711.) Codec incompatibility could also be caused by a failure when negotiating a common codec. For example, in a lab, two Cisco voice gateways (such as an MRP or an ASI card) can be forced to use different codecs so that transcoding is required for them to communicate.

Suppose that an application is communicating with a G.711-only voice-mail system over a WAN link. To conserve bandwidth, the caller on one side of WAN link uses G.729, while the called party voice-mail system recognizes only G.711. This is a situation that would require transcoding.

Transcoding is not required if all the called parties (except those on a voice-mail system) are on the same LAN. You can configure the calling and called parties so that they must negotiate a common codec when possible.

Here are some additional transcoding guidelines:

Choosing a DSP Firmware Image for Transcoding

When a DSP is reserved for transcoding, a special DSP firmware image is downloaded to the DSP. At present, the DSP firmware supports transcoding between G.723.1/G.729 and G.711 U/a-law, as well as between G.711 U-law and G.711 a-law. Transcoding between low-bit-rate codecs, such as between G.723.1 and G.729, is not supported.

Determining How Many DSPs Are Needed for Transcoding

Before an MRP or ASI can act as a transcoder, DSP resources must be reserved for transcoding. Unlike other Cisco gateways, the MRP or ASI provides the flexibility to choose the number of channels that should be reserved for transcoding. One DSP is required for every two transcoding channels (full duplex).

Understanding How DSPs Are Allocated for Transcoding

When the MRP or ASI boots, DSP resources are statically allocated first for analog VICs and the VIC-2BRI-NT/TE. These DSP resource allocations cannot be changed. In the show voice dsp command output, these DSPs are represented with a value of FIXMC or FIXHC in the Image field, depending on whether high- or medium-complexity DSP firmware is being used. The remaining DSP resources can be allocated to T1 VWICs, to E1 VWICs, or to transcoding, as needed.

For T1 VWICs or E1 VWICs, DSPs are reserved by defining a ds0-group or pri-group under the individual T1 or E1 controller. A DSP is reserved if it hosts a signaling channel for the T1/E1 VWIC. Such a reserved DSP has a non-zero value in the D-sig Allocate field, which can be seen in the show voice dsp command output.

Configuring Fast Ethernet Ports

ASI and MRP cards have Fast Ethernet interfaces that can be configured.Depending on your own requirements and the protocols you plan to route, you might need to enter additional configuration commands. For more information about basic configuration, including enabling the interface and specifying IP routing on Fast Ethernet interfaces, see the section "Configuring Ethernet, Fast Ethernet, or Gigabit Ethernet Interfaces" in the Cisco IOS Interface Configuration Guide, Release 12.2.


Note   See the "Configuring Dial Plans" section for a sample configuration to configure a FastEthernet interface on an ASI or MRP card.


Note   Use ICSConfig to assign or modify the IP address of an ASI or MRP card, as necessary. Do not use the CLI.

Configuring WAN Interfaces

You can configure an MRP or ASI card with a WIC or VWIC installed for access to the WAN. For example, if you are using a serial interface, you can configure Frame Relay, Point-to-Point Protocol (PPP), and High-Level Data Link Control (HDLC) over that serial interface.

Information about the various types of connections is provided in the sections that follow:

Table 6-9 lists tasks you might need to perform in order to configure WAN interfaces on MRP or ASI cards and gives pointers to the location in Cisco IOS documentation set that provides additional instructions on performing those tasks. The various Cisco IOS configuration guides for version 12.2 are available at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/index.htm

Table 6-9   WAN Interface Configuration Tasks

Tasks Documentation Locations

Configuring Asynchronous/Synchronous Serial WICs

See "Configuring a Synchronous Serial Interface " and Configuring Low-Speed Serial Interfaces " in the Cisco IOS Interface Configuration Guide, Release 12.2.

Configuring ISDN BRI WICs

See "Configuring ISDN BRI " in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2

Configuring T1 and Fractional T1 WICs

See "Configuring Serial Interfaces for CSU/DSU Service Modules" in the Cisco IOS Interface Configuration Guide, Release 12.2.

Configuring Asynchronous/Synchronous Serial WICs

You can configure the serial interfaces on your asynchronous/synchronous serial WIC (WIC-1T, WIC-2T, or WIC-2A/S) by entering IOS commands at the ASI or MRP command prompt, in configuration mode.


Note   See the "Configuring Synchronous Serial WICs" section for a sample configuration.

Table 6-10 lists the half-duplex timer commands.

Table 6-10   Half-Duplex Timer Commands

Timer Syntax Default Setting (ms)

CTS1 delay

half-duplex timer cts-delay

100

CTS drop timeout

half-duplex timer cts-drop-timeout

5000

DCD2 drop delay

half-duplex timer dcd-drop-delay

100

DCD transmission start delay

half-duplex timer dcd-txstart-delay

100

RTS3 drop delay

half-duplex timer rts-drop-delay

100

RTS timeout

half-duplex timer rts-timeout

2000

Transmit delay

half-duplex timer transmit-delay

0

1CTS = Clear To Send

2DCD = data carrier detect

3RTS = Request To Send

Table 6-11 through Table 6-13 list clock rate settings in bits per second (bps) for specific interfaces.

Table 6-11   Clock Rate Settings for 1-Port/2-Port Serial WICs in Synchronous Mode

1200 bps

38400 bps

148000 bps

2400 bps

56000 bps

500000 bps

4800 bps

57600 bps

800000 bps

9600 bps

64000 bps

1000000 bps

14400 bps

72000 bps

1300000 bps

19200 bps

115200 bps

2000000 bps

28800 bps

125000 bps

4000000 bps

32000 bps

128000 bps

148000 bps

Table 6-12   Clock Rate Settings for 1-Port/2-Port Serial WICs in Asynchronous Mode

1200 bps

28800 bps

72000 bps

2400 bps

32000 bps

115200 bps

4800 bps

38400 bps

125000 bps

9600 bps

56000 bps

128000 bps

14400 bps

57600 bps

 

19200 bps

64000 bps

 

Table 6-13   Clock Rate Settings for 2-Port Asynchronous/Synchronous Serial WICs

1200 bps

28800 bps

72000 bps

2400 bps

32000 bps

115200 bps

4800 bps

38400 bps

125000 bps

9600 bps

56000 bps

128000 bps

14400 bps

57600 bps

 

19200 bps

64000 bps

 

Configuring ISDN BRI WICs

You can use an Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI) WIC to connect MRPs or ASIs with other ISDN routers. ISDN BRI is a dial-up connection. Adding an ISDN BRI connection to the MRP creates a logical dialer interface.

ISDN connections use one or both data channels for the connection to the ISDN service provider. Normally, the ISDN provider is your local telephone company.

This section tells how to configure ISDN BRI WICs.


Note   For information on how to configure ISDN voice interfaces, see the "Configuring ISDN Interfaces for Voice" section.

ISDN BRI WIC Prerequisite Tasks

Before using an MRP with an ISDN BRI WIC, you must order a correctly configured ISDN BRI line from your local telecommunications service provider.

The ordering process varies from provider to provider and from country to country; however, here are some general guidelines:

Table 6-14 lists the ISDN switch types for North America.

Table 6-14   ISDN Switch Types for North America

ISDN Switch Type Description

basic-5ess

Lucent basic rate switches

basic-dms100

NT DMS-100 basic rate switches

basic-nil1

National ISDN-1 switches

ISDN BRI Provisioning by Switch Type

ISDN BRI provisioning refers to the types of services provided by the ISDN BRI line. Although provisioning is performed by your ISDN BRI service provider, you must tell the provider what you want. Table 6-15 lists the provisioning that you should order for switches used in North America.

Table 6-15   North American ISDN BRI Switch Type Configuration Information

Switch Type Provisioning

DMS-100 BRI Custom

Two B channels for voice and data.

Two directory numbers assigned by service provider.

Two SPIDs1 required; assigned by service provider.

Functional signaling.

Dynamic TEI2 assignment.

Maximum number of keys = 64.

Release key = no, or key number = no.

Ringing indicator = no.

EKTS = no.

PVC = 2.

Request delivery of calling line ID on Centrex lines.

Set speed for ISDN calls to 56 kbps outside local exchange.

Directory number 1 can hunt to directory number 2.

5ESS Custom BRI

For data only:

Two B channels for data.

Point to point.

Terminal type = E.

One directory number (DN) assigned by service provider.

MTERM = 1.

Request delivery of calling line ID on Centrex lines.

Set speed for ISDN calls to 56 kbps outside local exchange.

5ESS National ISDN (NI-1) BRI

Terminal type = A.

Two B channels.

Two directory numbers assigned by service provider.

Two SPIDs required, assigned by service provider.

Set speed for ISDN calls to 56 kbps outside local exchange.

Directory number 1 can hunt to directory number 2.

DMS-100 BRI

Two B channels.

Two directory numbers assigned by service provider.

Two SPIDs required, assigned by service provider.

Functional signaling.

Dynamic TEI assignment.

Maximum number of keys = 64.

Release key = no, or key number = no.

Ringing indicator = no.

EKTS = no.

PVC = 2.

Request delivery of calling line ID on Centrex lines.

Set speed for ISDN calls to 56 kbps outside local exchange.

Directory number 1 can hunt to directory number 2.

1SPID = service profile identifier

2TEI = terminal endpoint identifier

Defining ISDN SPIDs

Some service providers use service profile identifiers (SPIDs) to define the services subscribed to by the ISDN device that is accessing the ISDN service provider. The service provider assigns the ISDN device one or more SPIDs when you first subscribe to the service. If you are using a service provider that requires SPIDs, your ISDN device cannot place or receive calls until it sends a valid, assigned SPID to the service provider when accessing the switch to initialize the connection.

At present, only the DMS-100 and NI switch types require SPIDs. The AT&T 5ESS switch type may support a SPID, but we recommend that you set up that ISDN service without SPIDs. In addition, SPIDs have significance only at the local access ISDN interface. Remote routers never receive the SPID.

A SPID is usually a seven-digit telephone number with some optional numbers. However, service providers may use different numbering schemes. For the DMS-100 switch type, two SPIDs are assigned, one for each B channel.

To define SPIDs and the local directory number (LDN) for both ISDN BRI B channels, use the following isdn spid commands in interface configuration mode:

MRP (config-if)# isdn spid1 spid-number [ldn]
MRP (config-if)# isdn spid2 spid-number [ldn]

Note   Although the LDN is an optional parameter, you might need to enter it so that the MRP or ASI can answer calls made to the second directory number.

For further information on configuring ISDN, refer to the "Configuring ISDN BRI" chapter in the
Cisco IOS Dial Technologies Configuration Guide .

Configuring T1 and Fractional T1 WICs

The 1-port T1 WIC (WIC-1T) and fractional T1 WIC (WIC-1DSU-T1) include an integrated data service unit /channel service unit (DSU/CSU) and can be configured either for full T1 service (1.544 Mbps) or for fractional T1 service (less than 1.544 Mbps). You can configure the interfaces on your T1 WICs by entering IOS commands at the ASI or MRP command prompt, in configuration mode.

The IOS software provides a default configuration for CSU/DSU- and T1-specific parameters. To view the current configuration, enter the show service-module serial slot/port command.


Note   See the "Configuring T1 and Fractional T1 WICs" section to see the default configuration and a sample configuration to configure a new T1 or fractional T1 interface or to change the configuration of an existing interface.

For further information about these commands, refer to the "Configuring Serial Interfaces for CSU/DSU Service Modules" section in the "Configuring Serial Interfaces" chapter in the Cisco IOS Interface Configuration Guide .

Configuring VWICs for Data-Only Transmission

You can configure the multiflex trunk (MFT) interface card as a WIC (for data-only transmission). In the WIC mode, an MRP treats the T1 or E1 as a single serial interface for data. You can specify the number of channels (up to 24 [T1] or up to 30 [E1]) for this connection. On a data T1 or E1, you can configure only one channelized group. The rest of the channels are not used.

In a data-only configuration, an MRP supports the following T1 or E1 configurations:

This section describes basic configuration, including enabling the interface and specifying IP routing. Depending on your own requirements and on the protocols you plan to route, you might need to enter other configuration commands as well.


Note   See the "Configuring VWIC Interfaces for Data" section for a sample configuration to configure a new T1 or E1 VWIC interface or to change the configuration of an existing interface.

Configuring the TDM Clock

Digital T1 and E1 interfaces require not only that you set timing, but also that you consider the source of the timers. You must configure the time-division multiplexing (TDM) clock to specify the clock source. You can specify up to two external clock sources for each MRP. This means that only two of the T1 or E1 ports can use line as the clock source. The clock source is selected via the tdm clock global configuration command.

Scenarios for TDM Clocking

For TDM clocking scenarios and topologies, see the "TDM Clocking Scenarios" section, which describes the basic timing scenarios that can occur when a digital T1 or E1 interface is connected to a PBX, to a central office (CO), or to both.

Voice over IP

This section contains information on VoIP. VoIP is a Layer 3 network protocol that uses various Layer 2 point-to-point or link-layer protocols such as PPP, Frame Relay, or Asynchronous Transfer Mode (ATM) for its transport. VoIP enables Cisco routers, access servers, and multiservice access concentrators to carry and send voice and fax traffic over an IP network. DSPs segment the voice signal into frames and store them in voice packets. These voice packets are transported via IP in compliance with a voice communications protocol or standard such as H.323, MGCP, or SIP.

This section contains the following subsections:

Table 6-16 lists tasks that you might need to perform in order to configure VoIP on your MRP or ASI cards and gives pointers to the locations in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, that provide instructions on performing those tasks. The Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, is available at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/index.htm

Table 6-16   VoIP Configuration Task Checklist

Tasks Documentation Locations

Understanding Analog Voice Port Configuration

See "Voice Port Configuration Overview " in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Configuring Analog Voice Ports

See "Configuring Basic Parameters on Analog FXO, FXS, or E&M Voice Ports" in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Configuring Digital Voice Ports

See "Configuring Digital Voice Ports " in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Configuring ISDN Interfaces for Voice

See "Configuring ISDN Interfaces for Voice " in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Configuring Dial Plans

See "Dial Plan Overview " in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Configuring VoIP for Frame Relay

See "Configuring Voice over Frame Relay " in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Configuring Quality of Service

See "Configuring Quality of Service for Voice " in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Voice Ports Overview

MRP and ASI cards can provide analog and digital voice ports for implementations of VoIP. Voice ports emulate physical telephony switch connections so that voice calls and their associated signaling can be transferred intact between a packet network and a circuit-switched network or device.

For a voice call to occur, certain information must be passed between the telephony devices at either end of the call, such as the devices' on-hook status, the line's availability, and whether an incoming call is trying to reach a device. This information is referred to as signaling, and to process it properly, the devices at both ends of the call segment (that is, those directly connected to each other) must use the same type of signaling.

The type of signaling associated with the analog voice ports on MRP or ASI cards depends on the VIC installed in the device.

You can install either a VIC or a VWIC in an MRP or an ASI to make voice-related calls through the network. A VIC connects the system directly to a regular analog phone, a fax, or a PBX. A VWIC enables 24 channels on a T1 or 30 channels on an E1 (where each channel represents a simultaneous incoming or outgoing call). A VWIC also provides the flexibility to combine channels to form channel groups.

Each VIC is specific to a particular signaling type; therefore, VICs determine the type of signaling for the voice ports. Voice-port commands define the characteristics associated with a particular voice-port signaling type.

The voice ports support the following voice signaling types:

Connecting FXS, FXO, and E&M VICs to the Telephone Network

VICs provide the connection to the telephone equipment or network, as follows:

FXS Interfaces

Interfaces on FXS VICs are color-coded gray. Use a standard RJ11 modular telephone cable to connect this interface to a telephone or fax machine.


Caution   Do not connect an FXS interface directly to the PSTN.

FXO Interfaces

Interfaces on FXO VICs are color-coded pink. The following types of FXO interfaces are available:

In countries where the PSTN does not use RJ11 wall outlets, use a suitable adapter to convert the plug on an RJ11 modular cable to the connector used by the local wall outlet. These adapters are not sold by Cisco Systems, but they are available from other vendors, such as TeleAdapt. You can obtain additional information from TeleAdapt at http://www.teleadapt.com .


Caution   Connect only an FXO interface approved for use in your country to the PSTN. Otherwise, connect the FXO interface only to a PBX. Connections from the PBX to the PSTN are permitted.

E&M Interfaces

Interfaces on E&M VICs are color-coded brown. The E&M voice interface card uses an RJ48S connector. The pinout depends on the PBX type and connection.


Caution   Do not connect an E&M interface directly to the PSTN.


Note   If your MRP is configured with two VICs, a total of four telephones and fax machines can be connected to it. As the MRP has only two slots, you need to replace one VIC with a WIC to provide an interface for IP connectivity to the WAN and for data traffic. To accommodate more than four voice devices, you need to add an ASI, add MRPs, or use an E&M VIC and a local PBX, rather than connecting every telephone to its own FXS VIC.

Configuring Dial Plans

Use a dial plan to map the destination telephone numbers with the voice ports on the MRP. In North America, the North American Numbering Plan (NANP) is used, which consists of an area code, an office code, and a station code. Area codes are assigned geographically; office codes are assigned to specific switches; and station codes identify a specific port on that switch. The format in North America is 1Nxx-Nxx-xxxx, with N = digits 2 through 9, and x = digits 0 through 9. Internationally, each country is assigned a one- to three-digit country code; the country's dialing plan follows the country code.

In most corporate environments, the telephone network is configured so that users can reach a destination by dialing only a portion (an extension number) of the full E.164 telephone number. VoIP can be configured to recognize extension numbers and expand them into their full E.164 dialed numbers by using two commands in tandem: destination-pattern and num-exp. Before you configure these two commands, it is useful to map individual telephone extensions with their full E.164 dialed numbers. This can be done easily by creating a number expansion table.

For Cisco voice implementations, two types of dial peers are used to match a dialed number to either a local telephony port or a remote IP address:

Use the dial-peer voice command to define dial peers and to change to dial-peer configuration mode. See the "Configuring Analog Voice Ports" section for additional information.

Create a Number Expansion Table

In Figure 6-1, a small company decides to use VoIP to integrate its telephony network with its existing IP network. The destination pattern (or expanded telephone number) associated with MRP 1 (at the left of the IP cloud) is (408) 555-xxxx, where xxxx identifies the individual dial peers by extension. The destination pattern (or expanded telephone number) associated with MRP 2 (at the right of the IP cloud) is (729) 555-xxxx.


Figure 6-1   Sample VoIP Network


Table 6-17 shows the number expansion table for this scenario.

Table 6-17   Sample Number Expansion Table

Extension Destination Pattern Num-Exp Command Entry Description

1...

14085551...

num-exp 1... 14085551...

Expands a 4-digit extension beginning with the numeral 1 by prefixing 1408555 to it

2...

14085552...

num-exp 2... 14085552...

Expands a 4-digit extension beginning with the numeral 2 by prefixing 1408555 to it

3...

17295553...

num-exp 3... 17295553...

Expands a 4-digit extension beginning with the numeral 3 by prefixing 1729555 to it

4...

17295554...

num-exp 4... 17295554...

Expands a 4-digit extension beginning with the numeral 4 by prefixing 1729555 to it


Note   You can use a period (.) to represent variables (such as extension numbers) in a telephone number. A period is similar to a wildcard, which matches any entered digit.

The configuration shown in Table 6-17 needs to be made to both MRP 1 and MRP 2. Based on this configuration, MRP 1 can call any number string that begins with the digits 17295553 or 17295554 to connect to MRP 2. Similarly, MRP 2 can call any number string that begins with the digits 14085551 and 14085552 to connect to MRP 1.


Note   See the "Configuring Number Expansion" section for a sample configuration that expands an extension number into a particular destination pattern.

Configuring Analog Voice Ports

This section contains the following subsections:

Configuring FXS Interfaces

This section explains how to configure ports on FXS VICs that connect directly to a standard telephone, fax machine, or similar device.

Figure 6-2 shows a basic voice network. A small business uses a MRP card (named West) to provide telephone and fax connections among employees in its office. Two of these telephones are connected to an FXS VIC port in the West MRP.


Figure 6-2   Basic Voice Network (West MRP)



Note   You can name your MRP by using the global configuration hostname command.

Table 6-18 lists telephone numbers and voice ports for the West MRP.

Table 6-18   West MRP Telephone Numbers and Voice Ports

Telephone Number Voice Port

408 555-3737

0/0

408 555-4141

0/1


Note   If your MRP is configured with two VICs, a total of four telephones and fax machines can be connected to it. As the MRP has only two slots, you need to replace one VIC with a WIC to provide an interface for IP connectivity to the WAN and for data traffic. To accommodate more than four voice devices, you need to add an ASI, add MRPs, or use an E&M VIC and a local PBX, rather than connecting every telephone to its own FXS VIC.

Local Dial Peers

To route a received voice call to the proper destination, the MRP needs to have access to the telephone number that belongs to each voice port. For instance, if a call comes in for 408 555-3737, the MRP needs to correlate that phone number with a particular voice port (voice port 0/0, as shown in Figure 6-2.) In other words, the MRP needs to have access to the information in Table 6-18.

To hold this information, IOS software uses objects called dial peers. A telephone number, a voice port, and other call parameters are tied together by associating them all with the same dial peer. Configuring dial peers is similar to configuring static IP routes—you are telling the MRP what path to follow to route the call. All voice technologies use dial peers to define the characteristics associated with a call leg. A call leg is a segment of a call path; for example, segments occur between a telephone and an MRP, an MRP and a network, an MRP and a PBX, or an MRP and the PSTN. Each call leg corresponds to a dial peer.

Dial peers are identified by numbers, but they are usually referred to as tags to avoid confusion with telephone numbers. Dial-peer tags are arbitrary integers that can range from 1 to 231-1(2147483647). Within the allowed range, you can choose any dial-peer tag that is convenient or that makes sense to you. Dial peers on the same MRP must have unique tags, but you can reuse the tags on other MRPs.

Table 6-19 assigns a dial-peer tag to each telephone number and its associated voice port on the West MRP. This type of dial peer is called a POTS dial peer or a local dial peer. The term POTS (plain old telephone service) means that the dial peer associates a physical voice port with a local telephone device. (VoIP dial peers are explained in "Calling Between MRPs" section.)

Table 6-19   West MRP Local Dial Peers

Telephone Number Voice Port Dial-Peer Tag

408 555-3737

0/0

401

408 555-4141

0/1

402

You should construct a table similar to Table 6-19 for your own MRPs, assigning your own telephone numbers and dial-peer tags.


Note   The telephone numbers used in this guide are only examples and are invalid for public use in the United States. When you configure your network, be sure to substitute your own telephone numbers.

Figure 6-3 shows a configuration that uses dial-peer commands.


Figure 6-3   West MRP Configured for Local Dial Peers


The dial-peer command always takes the argument voice. The number following it is the dial-peer tag, and pots is the type of dial peer.

IOS software refers to a telephone number as a destination pattern because it is the destination for an incoming or outgoing call. Enter these numbers with the destination-pattern command. A destination pattern can include asterisks (*) and pound signs (#) from the telephone keypad, as well as commas (,) and periods (.), which have special meanings. Parentheses ( () ), hyphens (-), slashes (/), and spaces ( ), which are often used to make telephone numbers easier for humans to read, are not allowed.

Notice that the commands in the examples put the prefix 1 (used in the United States to indicate a long-distance number) and an area code in front of the remaining numbers to complete the destination pattern. You need to include similar codes for your country if the VoIP equipment needs to establish a connection to the PSTN.


Note   The IOS software does not check the validity of the telephone number. It accepts any string of permitted characters as a valid number.

The business that owns the West MRP also has a branch office in the East. Figure 6-4 shows the East office network, and Table 6-20 lists the phone numbers, voice ports, and dial-peer tags for this office.


Figure 6-4   Basic Voice Network (East MRP)


Table 6-20   East MRP Local Dial Peers

Telephone Number Destination Pattern Voice Port Dial-Peer Tag

919 555-8282

19195558282

1/0

901

919 555-9595

19195559595

1/1

902


Note   To configure the local ports on the East MRP, enter identical commands to those used in the previous example, substituting the dial-peer information in Table 6-20. See the "Configuring FXS Interfaces" section for a sample configuration.

Figure 6-5 shows a configuration that uses dial-peer commands.


Figure 6-5   East MRP Configured for Local Dial Peers


Calling Between MRPs

To enable the West and East offices to send voice traffic to each other over the same IP network that they use for data traffic, use a WIC on each MRP to provide a connection to the IP network, as shown in Figure 6-6.


Figure 6-6   IP Connection Between MRPs


Look at the connection between the West MRP and the IP network. This connection does not include a voice port or an attached telephone—it leads from a WAN interface to a remote destination somewhere on the IP network. IP MRPs can locate IP addresses on the network, but they cannot locate telephone numbers. To route an outgoing voice call over this connection, the West MRP has to associate a telephone number in the East office with the IP address of the East MRP.

Table 6-21 assigns a dial-peer tag to each telephone number and its associated IP address on the West MRP. This type of dial peer is called a remote dial peer or VoIP dial peer. (Remember, the dial-peer tags are arbitrary.) The term VoIP means that the dial peer associates a telephone number with an IP address.

Table 6-21   West MRP Remote Dial Peers

Remote Location Telephone Number Destination Pattern IP Address Dial-Peer Tag

East

919 555-8282

19195558282

192.168.11.3

501

East

919 555-9595

19195559595

192.168.11.3

502

Create a VoIP dial peer on the West MRP for every telephone on the East MRP, all associated with the same IP address. But it is much easier to use periods as wildcards, as shown in Table 6-22.

Table 6-22   West MRP Remote Dial Peers with Wildcards

Remote Location Telephone Number Destination Pattern IP Address Dial-Peer Tag

East

919 555-xxxx

1919555....

192.168.11.3

501

Construct a table similar to Table 6-22 for your own MRPs, assigning your own telephone numbers, IP addresses, and dial-peer tags.


Note   The IP addresses shown in this guide are meant only as examples. When you configure your network, be sure to substitute your own IP addresses.

IOS software describes the remote network as the session target. This command is followed by the IP address of the remote MRP. The prefix ipv4 means IP version 4. Alternatively, you can use the prefix dns followed by the Domain Name System (DNS) name as follows:

West(config-dial-peer)# session target dns:voice.eastMRP.com

Note   See the "Configuring FXS Interfaces" section for a sample configuration.


Note   Configure a dial peer on each MRP for each telephone number on every other MRP connected to it.

To reduce the amount of data that you must enter, configure number expansion for East MRP telephone numbers on the West MRP. For details on the num-exp command, see "Configuring VoIP for Frame Relay" section.

West(config)# num-exp 5.... 1919555....

Now users can dial a five-digit extension beginning with 5 from a telephone on the West MRP to reach a telephone on the East MRP.

Figure 6-7 shows a configuration that uses dial-peer commands.


Figure 6-7   West MRP Configured for Remote Dial Peers


The West MRP is now configured to send calls to the East MRP.

Table 6-23 shows how to configure the East MRP to send calls to the West MRP.

Table 6-23   East MRP Remote Dial Peers with Wildcards

Remote Location Telephone Number IP Address Dial-Peer Tag

West

408 555-xxxx

192.168.19.27

801


Note   See the "Configuring FXS Interfaces" section for a sample configuration of number expansion on the East MRP using the dial-peer configuration given in Table 6-23.

Figure 6-8 shows a configuration that uses dial-peer commands.


Figure 6-8   East MRP Configured for Remote Dial Peers


Other MRPs on the Network

If the path between endpoints of a voice call runs through intermediate MRPs, configure those MRPs for VoIP traffic, as described in the "Configuring FXS Interfaces" section.

You need to configure POTS or VoIP dial peers on an intermediate MRP only if that MRP also has voice devices attached to it.

Configuring DID for ISDN

The Direct Inward Dialing (DID) feature in dial peers enables the router to use the dialed number identification service (DNIS) to directly match an outbound dial peer when receiving an inbound call from a POTS interface. When DID is configured on the inbound POTS dial peer, the called number (DNIS) is automatically used to match the destination pattern for the outbound call leg.

Unless otherwise configured, when a voice call comes into the router, the router presents a dial tone to the caller and collects digits until it can identify an outbound dial peer. This process is called two-stage dialing. After the outbound dial peer is identified, the router forwards the call through to the destination as configured in the dial peer.

You may prefer that the router use the called number (DNIS) to find a dial peer for the outbound call leg—for example, if the switch connecting the call to the router has already collected all the dialed digits. DID enables the router to match the called number to a dial peer and then directly place the outbound call. With DID, the router does not present a dial tone to the caller and does not collect digits; it forwards the call directly to the configured destination. This is called one-stage dialing.

Figure 6-9 shows a call topology that uses DID.


Figure 6-9   VoIP Call Using DID


In Figure 6-9, the POTS dial peer that matches the incoming called-number has DID configured:

dial-peer voice 100 pots
incoming called-number 5552020
direct-inward-dial
port 0:D

The direct-inward-dial command in the POTS dial peer tells the gateway to look for a destination pattern in a dial peer that matches the DNIS. For example, if the dialed number is 5552020, the gateway matches the following VoIP dial peer for the outbound call leg:

dial-peer voice 101 voip
destination-pattern 5552020
session target ipv4:10.1.1.2

The call is made across the IP network to 10.1.1.2, and a match is found in that terminating gateway:

dial-peer voice 555 pots
destination-pattern 5552020
port 0:D
prefix 5274200

This dial peer matches on the dialed number and changes that number to 52744200 with the prefix command. The result is that the user dials a number, connects, and never knows that the number reached is different from the number dialed.


Note   DID for POTS dial peers is not the same as analog DID for Cisco routers, which enables DID trunk service from the PSTN.


Note   See the "Configuring ISDN Voice Interfaces" section for a sample configuration of a POTS dial peer for DID.


Note   DID is configured for inbound POTS dial peers only.

Configuring FXO Interfaces

FXO interfaces provide a way for a VoIP call to reach the analog PSTN or a PBX that does not support E&M signaling. In this way, FXO interfaces enable users to reach telephones and fax machines outside the VoIP network. Figure 6-10 shows a typical FXO gateway attached to the West MRP.


Figure 6-10   FXO Gateway to PSTN


To create a POTS dial peer for an FXS interface as explained earlier, you enter the complete telephone number of the attached telephone as the destination pattern for incoming calls. However, to create a POTS dial peer for an FXO interface, the destination pattern refers to outgoing calls, and you can include wildcards in it because the PSTN performs the switching.

The VoIP feature can also remove digits that you do not want to send to the PSTN. For instance, to dial 9 to reach an outside line (that is, the analog PSTN), you would configure a destination-pattern for 9.


Note   See the "Configuring FXO Interfaces" section for a sample configuration.

When you dial 9, the MRP makes a connection to the PSTN through voice port 0/0. The PSTN then provides a dial tone, and any digits you enter on the telephone thereafter are interpreted on the PSTN.


Note   See the "Configuring FXO Interfaces" section for a sample configuration to enable East MRP users to make calls over the West MRP local PSTN.

In this example, when you dial 7 on the East MRP, the call is connected to the PSTN on the West MRP. The PSTN then provides a dial tone, and any digits you enter on the telephone thereafter are interpreted on the PSTN.


Note   In this example, West MRP voice port 0/0 has two separate POTS dial peers associated with it. Dial peer 201 matches calls beginning with the digit 9 and handles PSTN calls originating from the West MRP. Dial peer 601 matches calls beginning with the digit 7 and handles calls to the PSTN originating from the East MRP.

Configuring E&M Interfaces

If you have more than a few voice users at each location, the cost of voice ports and MRPs and the effort needed to configure dial peers for all the combinations of origins and destinations increases rapidly. In this situation, it might be more efficient to use a PBX at each location to switch local traffic and direct incoming calls and to then use E&M VICs to connect the PBXs over an IP network.


Note   E&M interfaces are supported with H.323 only.

Figure 6-11 shows a company with two offices, West and East. Each office has a PBX to operate its internal telephone network, and the IP network carries voice traffic between the offices. Each PBX connects to an E&M VIC port in the MRP.


Figure 6-11   Linking PBXs over the IP Network (Local Dial Peers)


To configure E&M voice ports, you need to use the following privileged EXEC commands:

Both PBXs in Figure 6-11 use E&M interface Type 2, with four-wire operation and immediate-start signaling. The values for your configuration depend on your PBX and are available from your telecommunications department or the PBX manufacturer. For more information about E&M interface configuration commands, refer to the "Configuring Voice over IP" chapter in the Software Configuration Guide for Cisco 3600 Series and Cisco 2600 Series Routers.

In this example, West users can dial 5 and then a 4-digit extension to reach telephones in the East office. East users can dial 5 and then a 4-digit extension to reach telephones in the West office.

The West MRP connects to the PBX through an E&M VIC port 0/0. This port is associated with a POTS dial peer for incoming calls. But you no longer need to associate every telephone number with its own port. Instead, you can configure a local dial peer as if all the West telephones (represented by a wildcard destination pattern) are connected directly to this port.


Note   See the "Configuring E&M Interfaces" section for a sample configuration.


Note   Configuration commands for E&M interfaces are identical to those used for FXS interfaces.


Note   To configure VoIP dial peers for outgoing calls and to associate destination phone numbers on the East MRP with that MRP IP address, as shown in Figure 6-12, see the "Configuring E&M Interfaces" section for a sample configuration.


Figure 6-12   Linking PBXs over the IP Network (Remote Dial Peers)


Now configure number expansion so that numbers beginning with 5 (belonging to the East office) and sent by the West PBX to the West MRP are expanded into the full destination pattern:

West(config)# num-exp 5.... 1919555....

Note   See the "Configuring FXS Interfaces" section for a sample configuration.


Note   You do not need to configure number expansion for calls from one West telephone to another West telephone because the PBX switches those calls.

Configure the E&M port on the West MRP.


Note   See the "Configuring E&M Interfaces" section for a sample configuration to configure the E&M port on the West MRP and on the East MRP.

Configure the East MRP similar to the West MRP. The East MRP connects to the PBX through an E&M VIC port 0/1.

Configure number expansion to make it easy for East users to dial numbers on the West MRP:

West(config)# num-exp 5.... 1408555....

Note   See the "Configuring FXS Interfaces" section for a sample configuration to configure a POTS dial peer for all East telephones, and number expansion and a VoIP dial peer for telephones on the West MRP.

Configuring Digital Voice Ports

VWICs support T1 or E1 applications, including fractional T1 or E1. The T1 version integrates a fully managed DSU/CSU. The E1 version includes a fully managed DSU.

The T1 or E1 lines that connect a telephony network to the digital voice ports on a router or MRP contain channels for voice calls. A T1 line contains 24 full-duplex channels or time slots, and an E1 line contains 30. The signal on each channel is transmitted at 64 kbps, a standard known as digital signal 0 (DS0); the channels are known as DS0 channels. For T1 lines, the ds0-group command creates a logical voice port (a DS0 group) from some or all of the DS0 channels, which enables you to address those channels easily, as a group, in voice-port configuration commands. (The ds0-group command is not supported on E1 lines.)

Digital voice ports are found at the intersection of a packet voice network and a digital, circuit-switched telephone network. The digital voice port interfaces that connect the router or MRP to T1 or E1 lines pass voice data and signaling between the packet network and the circuit-switched network.

Signaling is the exchange of information about calls and connections between two ends of a communication path. For instance, signaling communicates to the call's endpoints whether a line is idle or busy, whether a device is on-hook or off-hook, and whether a connection is being attempted. An endpoint can be a CO switch, a PBX, a telephony device such as a telephone or fax machine, or a voice-equipped router or MRP acting as a gateway. There are two aspects to consider with respect to signaling on digital lines: the information about line and device states that is transmitted, and the method used to transmit the information.

The information about line and device states is communicated over digital lines, using signaling methods that emulate the methods used in analog circuit-switched networks: FXS, FXO, and E&M.

Channel-associated signaling (CAS) is the transmission of signaling information within the voice channel. Various types of CAS signaling are available in the T1 world. The most common forms of CAS signaling are loop-start, ground-start, and E&M. The main disadvantage of CAS signaling is its use of user bandwidth to perform signaling functions. CAS signaling is often referred to as robbed-bit signaling because user bandwidth is being "robbed" by the network for other purposes. In addition to receiving and placing calls, CAS signaling processes the receipt of DNIS and ANI information, which is used to support authentication and other functions.

T1 CAS Signaling Systems

VoIP for the Cisco ICS 7750 supports the following T1 CAS signaling systems:

In the original wink start handshaking protocol, the terminating side responds to an off-hook from the originating side with a short wink (transition from on-hook to off-hook and back again). This wink tells the originating side that the terminating side is ready to receive addressing digits. After receiving addressing digits, the terminating side then goes off-hook for the duration of the call. The originating endpoint remains off-hook for the duration of the call.

In the Immediate Start protocol, the originating side does not wait for a wink before sending addressing information. After receiving addressing digits, the terminating side goes off-hook for the duration of the call. The originating endpoint remains off-hook for the duration of the call.

Ground Start / FXS / FXO—Ground Start signaling helps resolve glare, a condition that occurs when two sides of a connection try to go off-hook at the same time. Two sides of the connection simultaneously going off-hook creates a problem with loop start signaling because the only way an incoming call from the network can be recognized by the customer premises equipment (CPE) using loop start is to ring the phone. The 6-second ring cycle leaves a substantial amount of time for glare to occur. Ground Start signaling eliminates this problem and indicates an immediate seizure from the network to the CPE. This indication tells the CPE that a particular channel has an incoming call on it.

Channelized T1 Robbed-Bit Features

Internet service providers can provide switched 56-kbps access to their customers using the Cisco ICS 7750. The subset of T1 CAS (robbed-bit) supported signaling commands are as follows:

Prerequisites for Configuring Digital Voice Ports

Digital T1 or E1 packet voice capability requires specific service, software, and hardware:

Preparing Information to Configure Digital Voice Ports

Gather the following information about the telephony network connection that the voice port will be making:

Configuring ISDN Interfaces for Voice

This section tells how to configure ISDN BRI and Primary Rate Interface (PRI) ports for voice support and contains the following sections:

For complete descriptions of the commands used to configure ISDN interfaces for voice, refer to the Cisco IOS Dial Technologies Command Reference and the Cisco IOS Voice, Video, and Fax Command Reference .

ISDN Voice Interface Overview

ISDN voice support makes it possible to

Cisco routing devices support both ISDN BRI and ISDN PRI. Both media types use bearer (B) channels and data (D) channels.

ISDN BRI

ISDN BRI provides two B channels, each capable of transferring voice or data at 64 kbps, and one 16-kbps D channel that carries signaling traffic. The D channel is used by the telephone network to carry instructions about how to handle each of the B channels. ISDN BRI (also referred to as 2 B + D) provides a maximum transmission speed of 128 kbps.

The ISDN BRI NT/TE voice interface card (VIC-2BRI-NT/TE) enables Cisco IOS software to replicate the PSTN interface to a PBX that is compatible with European Telecommunications Standards Institute (ETSI) NET3 and QSIG switch types.


Note   For more information about QSIG, refer to the "Configuring ISDN Interfaces for Voice" chapter in the Cisco IOS Voice, Video, and Fax Software Configuration Guide.

Customers with PBXs that implement only the BRI TE interface have had to make substantial hardware and software changes on the PBX in order to implement the NT interface. Implementation of an NT interface on MRP and ASI cards enables the customer to connect ISDN PBXs and key systems to a multiservice network with a minimum of configuration changes on the PBX. Use of an NT interface also allows bypassing of the PSTN by enterprise customers who have a large installed base of legacy telephony equipment.

ISDN PRI

ISDN PRI provides 23 B channels plus a D channel (in North America and Japan) or 30 B channels plus a D channel (in the rest of the world). Similar to the ISDN BRI D channel, the ISDN PRI D channel carries signaling traffic. ISDN PRI is often referred to as 23 B + D (in North America and Japan) or 30 B + D (in the rest of the world).

The D channel notifies the central office switch to send the incoming call to particular time slots on the Cisco access server or router. Each B channel carries data or voice. The D channel carries signaling for the B channels. The D channel identifies whether the call is a circuit-switched digital call or an analog modem call. Analog modem calls are decoded and then sent to the onboard modems. Circuit-switched digital calls are relayed directly to the ISDN processor in the router.

ISDN Voice Interface Prerequisite Tasks

Before configuring an MRP or ASI with an ISDN interface, you must do the following:

Configuring ISDN Voice Interfaces

Note   See the "Configuring ISDN Voice Interfaces" section for sample configurations to configure DID for ISDN, ISDN BRI VICs, and ISDN PRI interfaces.

Table 6-24 shows ISDN switch types. An ISDN switch type must be specified in your configuration.

Table 6-24   ISDN Switch Types

ISDN Switch Type Description

basic-ts013

Australian TS013 switches.

basic-1tr6

German 1TR6 ISDN switches.

basic-nwnet3

Norwegian NET3 ISDN switches (phase 1).

basic-net3

NET3 (TBR3) ISDN, Norway NET3, and New Zealand NET3 switches. (This switch type covers the Euro-ISDN E-DSS1 signaling system and is ETSI-compliant.)

vn2

French VN2 ISDN switches.

vn3

French VN3 ISDN switches.

ntt

Japanese NTT ISDN switches.

basic-nznet3

New Zealand NET3 switches.

basic-5ess

Lucent Technologies basic rate switches.

basic-dms100

NT DMS-100 basic rate switches.

basic-nil1

National ISDN-1 switches.

Configuring ISDN PRI Interfaces

With ISDN PRI, signaling in VoIP is handled by ISDN PRI group configuration. After ISDN PRI has been configured, you must enter the isdn incoming-voice command on the serial interface (acting as the D channel) to ensure a dial tone.


Note   See the "Configuring ISDN Voice Interfaces" section for sample configurations to configure DID for ISDN, ISDN BRI VICs and ISDN PRI Interfaces.

Configuring ISDN PRI Voice Ports

Under most circumstances, the default voice port command values are adequate for configuring voice ports to transport voice data over your existing IP network. However, because of the inherent complexities of PBX networks, you might need to configure specific voice port values, depending on the specifications of the devices in your telephony network.

To configure specific voice port parameters, see the "Configuring Voice Ports" chapter in the Cisco IOS Voice, Video, and Fax Configuration Guide .

For more information on specific voice-port configuration commands and additional voice port commands, refer to the Cisco IOS Voice, Video, and Fax Command Reference.

Verifying ISDN PRI Configuration

You can check the validity of your voice port configuration by performing the following tasks:

ISDN PRI Troubleshooting Tips

If you are having trouble connecting a call and you suspect that the problem is associated with voice port configuration, you can try to resolve the problem by performing the following tasks:

Configuring VoIP for Frame Relay

You need to consider certain factors when you configure VoIP so that it runs smoothly over Frame Relay. A public Frame Relay cloud provides no guarantees for quality of service (QoS). For real-time traffic to be transmitted in a timely manner, the data rate must not exceed the committed information rate (CIR), or packets might be dropped. In addition, Frame Relay traffic shaping and Resource Reservation Protocol (RSVP) are mutually exclusive. This is particularly important to remember if multiple data-link connection identifiers (DLCIs) are carried on a single interface.

For Frame Relay links with slow output rates (less than or equal to 64 kbps), where data and voice are being transmitted over the same permanent virtual circuit (PVC), we recommend the following solutions:


Note    Lowering the MTU size affects data throughput speed.


Note    When traffic bursts over the CIR, the output rate is held at the speed configured for the CIR (for example, traffic will not exceed a rate of 32 kbps if CIR is set to 32 kbps).

In IOS Release 12.0, Frame Relay traffic shaping is not compatible with RSVP. We suggest one of the following workarounds:

Configuration Example of Frame Relay for VoIP

For Frame Relay, it is customary to configure a main interface and several subinterfaces with one subinterface per PVC.


Note   See the "Configuring VoIP for Frame Relay" section for sample configurations.

For more information about configuring Frame Relay for VoIP, refer to the "Configuring Frame Relay" chapter in the Cisco IOS Wide-Area Networking Configuration Guide.

Configuring Quality of Service

You need to have a well-engineered, end-to-end network for running delay-sensitive applications such as VoIP. Voice traffic is much more sensitive to timing variations than data traffic. For good voice performance, you need to configure the data network so that voice packets are not lost or delayed. Fine-tuning the network to adequately support VoIP involves selecting a series of protocols and features to improve QoS. It is beyond the scope of this document to explain the specific details relating to wide-scale QoS deployment. Cisco IOS software provides many tools for enabling QoS on the backbone, such as random early detection (RED), weighted random early detection (WRED), Fancy Queuing (that is, custom, priority, or weighted fair queuing), and IP precedence. To configure your IP network for real-time voice traffic, you must take into consideration the entire scope of your network and then select the appropriate QoS tool or tools.


Note   QoS measures the level of network performance. It does not directly measure the quality of the voice signal.

The important thing to remember is that QoS must be configured throughout your network—not just on the MRP running VoIP—in order to improve voice network performance.

Need for Quality of Service

On a relatively low-bandwidth connection, such as a PPP or HDLC serial link, you should consider using methods to ensure QoS. If you have a high-bandwidth network, such as Ethernet or Fast Ethernet, and voice and data traffic together occupy only a small fraction of the available bandwidth, then you might not need to provide QoS. (See Figure 6-13.)


Figure 6-13   Bandwidth versus Quality of Service


Although not mandatory, some QoS tools can be valuable in fine-tuning a network to support real-time voice traffic. To configure an IP network for QoS, perform one or more of the tasks in the following sections:

Configuring Custom Queuing

Some QoS features, such as IP RTP reserve and custom queuing, are based on the transport protocol and the associated port number. Real-time voice traffic is carried on UDP ports ranging from 16384 to 16624. This number is derived from the following formula:

16384 + (4 x number of voice ports in the MRP)

Custom queuing and other methods for identifying high-priority streams should be configured for these port ranges. For more information about custom queuing, refer to the "Configuring Custom Queuing" chapter in the Cisco IOS Quality of Service Solutions Configuration Guide.

Configuring Weighted Fair Queuing

Weighted fair queuing ensures that queues are not starved for bandwidth and that traffic gets predictable service. Low-volume traffic streams receive preferential service; high-volume traffic streams share the remaining capacity, obtaining equal or proportional bandwidth.

In general, weighted fair queuing is used in conjunction with multilink PPP with interleaving and RSVP or IP precedence to ensure voice packet delivery. Use weighted fair queuing with multilink PPP to define how data is managed; use RSVP or IP precedence to give priority to voice packets. For more information about weighted fair queuing, refer to the "Configuring Weighted Fair Queuing" chapter in the
Cisco IOS Quality of Service Solutions Configuration Guide .

Configuring IP Precedence

Use the ip precedence command to give voice packets a higher priority over other IP data traffic. Every IP packet is given a precedence level. In IP precedence, the numbers 1 through 5 identify classes for IP flows; the numbers 6 and 7 are used for network and backbone routing and updates. You can configure voice packets for higher priority by setting the IP precedence value to 5. Internal MRPs using weighted fair queuing give these packets priority. This command applies only to VoIP dial peers.

The ip precedence command should also be used if RSVP is not enabled and you want to give voice packets a higher priority over other IP data traffic.


Note   See the "Configuring IP Precedence" section for a sample configuration of IP precedence.

The ip precedence command should also be used if RSVP is not enabled and you want to give voice packets a higher priority over other IP data traffic.

Configuring RSVP for Voice

RSVP enables MRPs to reserve enough bandwidth on an interface for reliability and quality performance. RSVP allows end systems to request a particular QoS from the network. Real-time voice traffic requires network consistency. Without consistent QoS, real-time traffic can experience jitter, insufficient bandwidth, delay variations, or information loss. RSVP works in conjunction with current queuing mechanisms. It is up to the interface queuing mechanism (such as weighted fair queuing or WRED) to implement the reservation.

RSVP works well on PPP, HDLC, and similar serial line interfaces. It does not work well on multi access LANs. RSVP can be equated to a dynamic access list for packet flows.

You should configure RSVP to ensure QoS if the following are characteristics of your network:

Enabling RSVP

To minimally configure RSVP for voice traffic, you must enable RSVP on each interface where priority must be set.

By default, RSVP is disabled so that it is backward compatible with systems that do not implement RSVP. To enable RSVP for IP on an interface, use the following interface configuration command:

MRP(config-if)# ip rsvp bandwidth [interface-kbps] [single-flow-kbps]

This command starts RSVP and sets the bandwidth and single-flow limits. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount that can be reserved by a flow can be up to the entire available bandwidth.

On subinterfaces, RSVP applies to the more restrictive of the available bandwidths of the physical interface and the subinterface.

Reservations on individual circuits that do not exceed the single flow limit normally succeed. However, if reservations are made on other circuits adding up to the line speed, and if a reservation is made on a subinterface that has enough remaining bandwidth, then the reservation will still be refused because the physical interface lacks supporting bandwidth.

An MRP running VoIP and configured for RSVP requests allocations on the basis of the following formula:

bps=packet_size+ip/udp/rtp header size * 50 per second

For G.729, the allocation works out to be 24,000 bps. For G.711, the allocation is 80,000 bps.

For more information about configuring RSVP, refer to the "Configuring RSVP" chapter in the
Cisco IOS Quality of Service Solutions Configuration Guide .


Note   See the "Configuring RSVP" section for a sample configuration.

Configuring Multilink PPP with Interleaving

Multiclass multilink PPP with interleaving allows large packets to be multilink-encapsulated and fragmented into smaller packets to satisfy the delay requirements of real-time voice traffic; small real-time packets, which are not multilink-encapsulated, are transmitted between fragments of the large packets. The interleaving feature also provides a special transmit queue for the smaller, delay-sensitive packets, enabling them to be transmitted earlier than other flows. Interleaving provides the delay bounds for delay-sensitive voice packets on a slow link that is used for other best-effort traffic.

In general, multilink PPP with interleaving is used in conjunction with weighted fair queuing and RSVP or IP precedence to ensure voice packet delivery. Use multilink PPP with interleaving and weighted fair queuing to define how data is managed; use RSVP or IP precedence to give priority to voice packets.

You should configure multilink PPP if the following are characteristic of your network:

Multilink PPP support for interleaving can be configured on virtual templates, dialer interfaces, and ISDN BRI or PRI interfaces. To configure interleaving, you need to complete the following tasks:

For more information about multilink PPP, refer to the "Configuring Media-Independent PPP and Multilink PPP" chapter in the Cisco IOS Dial Technologies Configuration Guide.

Configuring RTP Header Compression

Real-Time Transport Protocol (RTP) is used for carrying audio traffic in packets over an IP network. RTP header compression compresses the IP/UDP/RTP header in a 40-byte RTP data packet to approximately 2 to 4 bytes (most of the time), as shown in Figure 6-14.


Figure 6-14   RTP Header Compression


This compression feature is beneficial if you are running VoIP over slow links. Enabling compression on both ends of a low-bandwidth serial link can greatly reduce the network overhead if there is a lot of RTP traffic on that slow link.

Typically, an RTP packet has a payload of approximately 20 to 160 bytes for audio applications that use compressed payloads. RTP header compression is especially beneficial when the RTP payload size is small (for example, compressed audio payloads between 20 and 50 bytes).

You should configure RTP header compression if the following are characteristic of your network:

Perform the following tasks to configure RTP header compression for VoIP. The first task is required; the second task is optional.

Enabling RTP Header Compression on a Serial Interface

You must enable compression on both ends of a serial connection. To enable RTP header compression, use the following interface configuration command:

MRP(config-if)# ip rtp header-compression [passive]

If you include the passive keyword, the software compresses outgoing RTP packets only if incoming RTP packets on the same interface are compressed. If you use the command without the passive keyword, the software compresses all RTP traffic.

Changing the Number of Header Compression Connections

By default, the software supports a total of 16 RTP header compression connections on an interface. To specify a different number of RTP header compression connections, use the following interface configuration command:

MRP(config-if)# ip rtp compression connections number

Note   See the "Configuring RTP Header Compression" section for sample configurations for enabling and configuring RTP header compression for a serial interface.

For more information about RTP header compression, see the "Configuring IP Multicast Routing" chapter of the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1.

TDM Clocking Scenarios

This section describes the timing scenarios that can occur when different combinations of WICs and VICs are used on the two slots of an MRP. All digital T1 interfaces are connected to a PBX, to a CO, or to both. In all the examples, the PSTN (or CO) and the PBX can both provide and receive clocking.

The MRP200 and MRP300 cards have two onboard phase locked loop (PLL) chips that can derive clock source from any T1 interface on the system. The clock source is selected by using the tdm clock global configuration command. Both PLL chips can either provide a clock source to both T1 interfaces or receive clocking that can drive the second T1 interface.

The T1 interface payload type can be defined as voice, as data, or as both. In the following scenarios, voice is the most commonly used payload type.

Configuration of TDM clocks affects the DSP groupings. (For information on DSP groups, see the "DSP Groups" section.) If only one clock source is used, the DSPs on both the PVDMs can be considered a single pool of DSP resources. If two clock sources are used, each PVDM constitutes a separate pool of DSP resources. If a port is used for an analog VIC, a single PVDM constitutes the DSP resource. Therefore, depending on whether one or two clock sources are defined, the bindings between the DSP resources and the set of ports that they can service can vary.

An MRP supports the following T1 configurations:

T1 in Slot 0

Table 6-25 describes the timing topologies that can result when slot 0 is a T1 interface and slot 1 is empty.

Table 6-25   Timing Topologies—T1 in Slot 0

Topology Slot 0 Slot 1 PVDM 0 PVDM 1 Clocking Slot 0/
Port 0
Clocking Slot 0/
Port 1
Clocking Slot 1/
Port 0
Clocking Slot 1/
Port 1

Single T1 port 0/0 provides the clock.

T1

None

PVDM-20

None

Import onboard

None

None

None

Single T1 port 0/0 receives the clock from the line.

T1

None

PVDM-20

None

Export line

None

None

None

Dual T1 ports. Both ports 0/0 and 0/1 receive the clock from the line.

T1

None

PVDM-20

None

Export line

Export line

None

None

Dual T1 ports. Both ports 0/0 and 0/1 receive the clock from the line, and one is in the loop-timed mode.

T1

None

PVDM-20

None

Export line

Import T1 port 0/0 line

None

None

Dual T1 ports. Port 0/0 receives the clock, and port 0/1 provides the clock to the line.

T1

None

PVDM-20

None

Export line

Import T1 port 0/0 internal

None

None

Dual T1 ports. Both ports 0/0 and 0/1 provide the clock to the line.

T1

None

PVDM-20

None

Import onboard internal

Import onboard internal

None

None


Note   See the "T1 in Slot 0" section for sample configurations and explanations of the various topologies described in Table 6-25.

T1 in Both Slot 0 and Slot 1

Table 6-26 describes the timing topologies that can result when both slot 0 and slot 1 are T1 interfaces.

Table 6-26   Timing Topologies—T1 in Both Slot 0 and Slot 1

Topology Slot 0 Slot 1 PVDM 0 PVDM 1 Clocking Slot 0/
Port 0
Clocking Slot 0/
Port 1
Clocking Slot 1/
Port 0
Clocking Slot 1/
Port 1

Dual T1 ports. Both ports 0/0 and 1/0 receive the clock from two different line sources.

T1

T1

PVDM-20

PVDM-20

Export line

None

Export line

None

Dual T1 ports. Both ports 0/0 and 1/0 receive the clock from the line, and one is in the loop-timed mode.

T1

T1

PVDM-20

PVDM-20

Export line

None

Import T1 port 0/0 line

None

Dual T1 ports. Port 0/0 receives the clock, and port 1/0 provides the clock to the line.

T1

T1

PVDM-20

PVDM-20

Export line

None

Import T1 port 0/0 internal

None

Dual T1 ports. Both ports 0/0 and 1/0 provide the clock to the line.

T1

T1

PVDM-20

PVDM-20

Import onboard

None

Import onboard

None


Note   See the "T1 in Both Slot 0 and Slot 1" section for sample configurations and explanations of the various topologies described in Table 6-26.

T1 in Slot 0 and an Analog VIC in Slot 1

Table 6-27 describes the timing topologies that can result when slot 0 is a T1 interface and slot 1 is an analog VIC interface.

Table 6-27   Timing Topologies—T1 in Slot 0 and an Analog VIC in Slot 1

Topology Slot 0 Slot 1 PVDM 0 PVDM 1 Clocking Slot 0/
Port 0
Clocking Slot 0/
Port 1
Clocking Slot 1/
Port 0
Clocking Slot 1/
Port 1

Dual T1 ports. Both ports 0/0 and 0/1 receive the clock from the line, and one is in the loop-timed mode.

T1

VIC

PVDM-20

PVDM-4

Export line

Import T1 port 0/0 line

None

None

Dual T1 ports. Port 0/0 receives the clock, and port 0/1 provides the clock to the line.

T1

VIC

PVDM-20

PVDM-4

Export line

Import T1 port 0/0 internal

None

None

Dual T1 ports. Both ports 0/0 and 0/1 provide the clock to the line.

T1

VIC

PVDM-20

PVDM-4

Import onboard

Import onboard

None

None


Note   The MRP200 and MRP300 cards do not support the topology in which both T1 ports in slot 0 are receiving clocking from the line and in which a VIC is installed in slot 1. The VIC utilizes one clock source; the two T1 ports cannot receive two other clock sources because there is a limit of two clock sources in an MRP.


Note   See the "T1 in Slot 0 and an Analog VIC in Slot 1" section for sample configurations and explanations of the various topologies described in Table 6-27.

T1 in Slot 0 and a WIC in Slot 1

Table 6-28 describes the timing topologies that can result when slot 0 is a T1 interface and slot 1 is a WIC interface.

Table 6-28   Timing Topologies—T1 in Slot 0 with a WIC in Slot 1

Topology Slot 0 Slot 1 PVDM 0 PVDM 1 Clocking Slot 0/
Port 0
Clocking Slot 0/
Port 1
Clocking Slot 1/
Port 0
Clocking Slot 1/
Port 1

Dual T1 ports. Both ports 0/0 and 0/1 receive the clock from two different line sources.

T1

WIC

PVDM-20

None

Export line

Export line

None

None

Dual T1 ports. Both ports 0/0 and 0/1 receive the clock from the line, and one is in the loop-timed mode.

T1

WIC

PVDM-20

None

Export line

Import T1 port 0/0 line

None

None

Dual T1 ports. Port 0/0 receives the clock, and port 0/1 provides the clock to the line.

T1

WIC

PVDM-20

None

Export line

Import T1 port 0/0 internal

None

None

Dual T1 ports. Both ports 0/0 and 0/1 provide the clock to the line.

T1

WIC

PVDM-20

None

Import onboard

Import onboard

None

None


Note   T1 data should not be configured on port 1 of either slot when a WIC is present on the same MRP because the WIC takes the same data path as port 1 of the other slot.


Note   See the "T1 in Slot 0 and a WIC in Slot 1" section for sample configurations and explanations of the various topologies described in Table 6-28.

H.323 Overview

The Cisco ICS 7750 MRP and ASI cards can be configured as H.323 or MGCP gateways.

H.323 is a standard from the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) for sending voice, video, and data across a network. The H.323 specification includes several related standards, such as H.225 (call control), H.235 (security), H.245 (media path and parameter negotiation), and H.450 (supplementary services).

An H.323 gateway is an endpoint on the LAN that provides real-time communications between H.323 devices on the LAN and other ITU devices on a WAN or to other H.323 gateways. Gateways allow H.323 devices to communicate with non-H.323 devices by converting protocols. The gateway is the point at which a circuit-switched call is encoded and repackaged into IP packets. Because gateways function as H.323 endpoints, they provide admission control, address lookup and translation, and accounting services.

Gatekeepers are optional nodes that manage other nodes in an H.323 network. Gateways communicate with gatekeepers using the registration, admission, and status (RAS) protocol. The gatekeeper maintains resource computing information, which it uses to select the appropriate gateway during the admission of a call. In an environment in which both gatekeepers and gateways are used, only gateways are configured to send VoIP data.

Cisco software complies with the mandatory requirements and several of the optional features of the H.323 Version 2 specification. Cisco H.323 Version 2 software enables gatekeepers, gateways, and proxies to send and receive all the required fields in H.323 Version 2 messages. Cisco H.323 Version 2 features include the following:

H.323 is the most widely deployed VoIP call-control protocol because it has been in use the longest; no other protocol choices existed before H.323. H.323 specifies how multimedia traffic is carried over packet networks using existing standards—for example, Q.931—to accomplish its goals. Q.931 is an ITU standard that describes one type of ISDN signaling for Layer 3 (Network layer in the OSI reference model).

H.323, however, is not generally seen as a protocol that is robust enough for PSTN networks. For these networks, other protocols such as MGCP and SIP are preferable.

Additional information on the H.323 protocol is available in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2 available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/.

MGCP Overview

MGCP enables the remote control and management of voice and data communications devices at the edge of multiservice IP packet networks.

As a communication protocol, MGCP overcomes the distributed configuration and administration problems inherent in the use of protocols such as the H.323 standard. Using a centralized architecture, MGCP greatly simplifies the configuration and administration of voice gateways that operate in multiservice IP packet networks.

In addition, MGCP supports the presence of multiple (redundant) call agents in a Voice over IP (VoIP) network, thereby eliminating the potential for a single point of failure in controlling the MGCP gateways in the network.

In effect, MGCP functions as a master/slave protocol to ensure that the MGCP voice gateways in a VoIP network properly receive and execute the configuration, control, and management commands that are issued to the gateways by Cisco CallManager.

MGCP is an extension of the earlier version of the protocol Simple Gateway Control Protocol (SGCP). MGCP supports SGCP functionality and provides several enhancements. Systems using SGCP can easily migrate to MGCP, and MGCP commands are available to enable the SGCP capabilities.

An MGCP gateway handles the translation between audio signals and the packet network. The gateways interact with a call agent (CA), also called a Media Gateway Controller (MGC), that performs signal and call processing on gateway calls. In MGCP configurations on the Cisco ICS 7750, the Cisco ICS 7750 acts as the gateway, and the CA is a Cisco CallManager server (version 3.1.2c or above).

MGCP uses endpoints and connections to construct a call. Endpoints are sources of or destinations for data. Endpoints can be either physical or logical locations in a device. Connections can be point-to-point or multipoint.

Like SGCP, MGCP uses User Datagram Protocol (UDP) for establishing audio connections over IP networks. However, MGCP also uses hairpinning to return a call to the Public Switched Telephone Network (PSTN) when the IP network is not available.

Creating a call connection involves a series of signals and events that describe the connection process. This information might include such indicators as the off-hook status, a ringing signal, or a signal to play an announcement. These events and signals are specific to the type of endpoint involved in the call.

MGCP groups these events and signals into packages. A trunk package, for example, is a group of events and signals relevant to a trunking gateway, whereas an announcement package groups events and signals for an announcement server. MGCP supports seven package types, as follows:

The trunk package and line package are supported by default on certain types of gateways. Although configuring a gateway with additional endpoint package information is optional, you may want to specify the packages for your endpoints to add to or to override the defaults.

MGCP provides the following benefits:


Note    POTS dial peer configuration is still required.

Gateway Types

MGCP on the Cisco ICS 7750 supports the following MGCP gateway types:

ISDN PRI Backhaul

ISDN PRI backhaul provides a method for transporting complete IP telephony signaling information from an ISDN PRI interface of a multiservice route processor (MRP) or analog station interface (ASI) system card to Cisco CallManager through a highly reliable TCP connection.

This feature works by terminating all the ISDN PRI Layer 2 (Q.921) signaling functions in the Cisco IOS code on the MGCP voice gateway while, at the same time, packaging all the ISDN PRI Layer 3 (Q.931) signaling information into packets for transmission to the Cisco CallManager through an IP tunnel over a highly reliable TCP connection. This methodology ensures the integrity of the Q.931 signaling information being passed through the network for managing IP telephony devices.

A rich set of user-side and network-side ISDN PRI calling functions is supported by the ISDN PRI backhaul feature. The gateway uses a single TCP connection for backhauling all the ISDN D channels to Cisco CallManager. The "SAP/Channel ID" parameter in the header of each message identifies individual D channels. In addition to carrying the backhaul traffic, the inherent TCP keepalive mechanism is also used to determine MGCP voice gateway connectivity to an available call agent.

The MGCP voice gateway also establishes a TCP link to the backup (secondary) Cisco CallManager server. In the event of Cisco CallManager switchover, the ISDN PRI backhaul functions are assumed by the secondary Cisco CallManager server. During this switchover, all active ISDN PRI calls are preserved, and the affected MGCP gateway is registered with the new Cisco CallManager server through a Restart-in-Progress (RSIP) message to ensure continued gateway operation.

Multicast Music-on-Hold

The multicast music-on-hold (MOH) feature enables you to subscribe to a music-streaming service when using an MRP or ASI system card as a Cisco IOS MGCP voice gateway. By means of a preconfigured multicast address on a gateway, the gateway can "listen for" Real-Time Transport Protocol (RTP) packets that are broadcast from a default router in the network; the gateway can relay the packets to designated voice interfaces in the network.

RTP is the Internet-standard protocol for transporting real-time data, including audio and video information, across a network. Thus, RTP is well suited for media on demand and for interactive services such as IP telephony.

The default router in the network for handling MOH functions must have the following enabled:

When you configure a multicast address on a voice interface of a gateway, the gateway sends an Internet Gateway Management Protocol (IGMP) "join" message to the default router, indicating to the default router that the gateway is to receive RTP multicast packets.

Thus, the MOH feature provides the functionality to stream music from an MOH server to the voice interfaces of on-net and off-net callers that have been placed on hold.

The integrated multicast capability of Cisco CallManager 3.1 is implemented through the H.323 signaling plane in Cisco CallManager.

In an MOH environment, whenever caller A places caller B on hold, Cisco CallManager requests the MOH server to stream RTP packets to the "on-hold" interface through the preconfigured multicast address. In this way, RTP packets can be relayed to appropriately configured voice interfaces in a VoIP network that have been placed on hold.

Multiple MOH servers can be present in the same network, but each server must have a different Class D IP address, and the address must be preconfigured in Cisco CallManager and the Cisco IOS MGCP voice gateways.

Configuring MGCP

To configure MGCP on a Cisco ICS 7750 MRP or ASI, perform the tasks in the following sections.


Note    You can configure the Cisco ICS 7750 MRP as both a TGW and an RGW.

Configuring a TGW

To configure a TGW, use the following commands, beginning in global configuration mode:

Command Purpose
Step 1 

Router(config)# mg cp

Initiates the MGCP application.

Step 2 

Router(config)# mg cp call-agent [ipaddr|hostname] [port] service-type mgcp

Specifies the call agent's IP address or domain name, the port, and the gateway control service type. The keywords and arguments are as follows:

  • ipaddr—Specifies the call agent's IP address.
  • hostname—Specifies the call agent's host name, using the format host.domain.ext.
  • port—Specifies the port for the call agent to use. Valid values are from 1025 through 65535.
  • service-typeSpecifies the type of gateway control service supported by the call agent. Valid values are mgcp and sgcp. For MGCP configurations, use mgcp.
Step 3 

Router(config)# controller t1 number

Specifies the channel number of the T1 trunk to be used for digital calls.

Step 4 

Router(config-controller)# ds0-group ds0-group-no timeslots timeslot-list type {e&m-delay-start | e&m-wink-start}

Specifies the DS0 time slots that make up a logical voice port on a T1 controller and specifies the signaling type.

The arguments and keywords are as follows:

  • ds0-group-no—Specifies a value from 0 to 23 that identifies the DS0 group.
  • timeslots timeslot-list—Specifies a single time-slot number, a single range of numbers, or multiple ranges of numbers separated by commas. For T1 signaling, allowable values are from 1 to 24. Examples are as follows:
    • 2
    • 1-15,17-24
    • 1-23
    • 2,4,6-12
  • type
    • e&m-delay-start—The originating endpoint sends an off-hook signal and then waits for an off-hook signal followed by an on-hook signal from the destination.
    • e&m-wink-start—E&M Mercury Exchange Limited Channel Associated Signaling (MEL CAS) wink-start signaling support.
Step 5 

Router(config-controller)# exit

Returns to global configuration mode.

Step 6 

Router(config)# dial-peer voice tag {pots}

Enters dial-peer configuration mode and specifies a dial peer.

Step 7 

Router(config-dial-peer)# application mgcpapp

Enables a specific application (in this case, MGCP) on a dial peer.

Step 8 

Router(config-dial-peer)# port sub-unit/port

Selects the voice port used for the dial peer. The keywords are as follows:

  • sub-unit—Specifies the sub-unit number of the voice port. Valid values are as follows:
    • MRP or ASI81: 0 or 1.
    • ASI160: 0.
  • port—Specifies the port number. Valid values are:
    • MRP or ASI81 in slot 1: 0 or 1.
    • ASI81 in slot 0: 0 through 7.
    • ASI160: 0 through 15.
Step 9 

Router(config-controller)# exit

Exits controller configuration mode and returns to global configuration mode.

Step 10 

Router(config)# mg cp restart-delay value

(Optional) Specifies the delay value sent in the RSIP graceful teardown method. The value range is from 0 to 600 seconds; the default is 0.

Step 11 

Router(config)# mg cp package-capability {s-package | dtmf-package | gm-package | rtp-package | trunk-package}

(Optional) Specifies the event packages that are supported on the gateway. The set of supported packages varies with the type of gateway (TGW or RGW). The keywords are as follows:

  • as-package—Specifies the announcement server package.
  • dtmf-package—Specifies the DTMF package.
  • gm-package—Specifies the generic media package.
  • rtp-package—Specifies the RTP package.
  • trunk-package (default)—Specifies the trunk package.
Step 12 

Router(config)# mg cp default-package {as-package | dtmf-package | gm-package | rtp-package | trunk-package}

(Optional) Specifies the event package that should act as the default. Overrides the mgcp package-capability default package.

Step 13 

Router(config)# mg cp dtmf-relay voip codec {all | low-bit-rate} mode {cisco | nse | out-of-band}

Selects the codec type and enables dual-tone multi-frequency (DTMF) relay.

voip—(required) Specifies Voice over IP calls.

codec—Specifies use of either a G.711 codec or a G.726 codec.

all—Specifies use of any codec.

low-bit-rate—Specifies any version of the G.729 low-bit-rate codecs.

cisco—Removes DTMF tone from the voice stream and sends FRF.11 with a special payload 121 for DTMF digits.

nse—Uses the NSE-based forwarding method.

out-of-band—Removes DTMF tone from the voice stream and does not send FRF.11.

Step 14 

Router(config)# mg cp sdp simple

(Optional) Specifies use of a subset of the Session Definition Protocol (SDP). Cisco CallManager version 3.1.2c requires this subset to send data through the network. This command is optional for Cisco CallManager version 3.1.3a or later. The default is no mgcp sdp simple.

Step 15 

Router(config)# mgcp fax t38 inhibit

(Optional) Prevents the MRP or ASI from sending T.38 fax gateway information to the CallManager. This command is required for operation with Cisco CallManager version 3.1.2c, but is optional for version 3.1.3a and later.

Step 16 

Router(config)# no mgcp timer receive-rtcp

(Optional) Prevents a timeout, which results in the disconnecting of a call, from occurring after a 30-second period of silence in one direction of the call. (This can happen during long voice message calls, for example.)

Configuring an RGW

To configure an RGW, use the following commands, beginning in global configuration mode:

Command Purpose
Step 1 

MRP(config)# mgcp

Initiates the MGCP application.

Step 2 

MRP(config)# mgcp call-agent [ipaddr | hostname] [port] [service-type mgcp] [version protocol-version]

Specifies the call agent IP address or domain name, the port, and the gateway control service type. The keywords and arguments are as follows:

  • ipaddr—Specifies the call agent's IP address.
  • hostname—Specifies the call agent's host name, using the format host.domain.ext.
  • port—(Optional) Specifies the port for the call agent to use. Valid values are from 1025 through 65535. If no port number is specified, the default port number of 2427 is used for MGCP version 0.1, and port number 2727 is used for MGCP version 1.0.
  • service-type—(Optional) Specifies the type of gateway control service supported by the call agent. Valid values are mgcp or sgcp. For MGCP configurations, use mgcp. If no service-type is specified, the default service-type of mgcp is used.
  • protocol-version—(Optional) Specifies the version of the MGCP protocol used for MGCP configurations. Valid values are 0.1 and 1.0. If no protocol-version is specified, the default protocol-version of 0.1 is used.
Step 3 

MRP(config)# dial- peer voice number pots

Sets up the dial peer for a voice port.

Step 4 

MRP(config-dial-peer)# application MGCPAPP

Selects the MGCP application to run on the voice port.

Step 5 

MRP(config-dial-peer)# port sub-unit/port

Selects the voice port used for the dial peer. The keywords are as follows:

  • sub-unit—Specifies the sub-unit number of the voice port. Valid values are as follows:
    • MRP or ASI81: 0 or 1.
    • ASI160: 0.
  • port—Specifies the port number. Valid values are:
    • MRP or ASI81 in slot 1: 0 or 1.
    • ASI81 in slot 0: 0 through 7.
    • ASI160: 0 through 15.
Step 6 

MRP(config-dial-peer)# exit

Exits dial peer configuration mode and returns to global configuration mode.

Step 7 

MRP(config)# mgcp package-capability {line-package | dtmf-package | gm-package | rtp-package}

(Optional) Specifies the event packages that are supported on the gateway. The keywords are as follows:

  • line-package (default)—Specifies the line package.
  • dtmf-package—Specifies the DTMF package.
  • gm-package—Specifies the generic media package.
  • rtp-package—Specifies the RTP package.
Step 8 

MRP(config)# mgcp default-package [line-package | dtmf-package | gm-package]

(Optional) Specifies the event package that should act as the default. Overrides the mgcp package-capability command.

Step 9 

Router(config)# mg cp sdp simple

(Optional) Specifies use of a subset of the session description protocol (SDP). Cisco CallManager version 3.1.2c requires this subset to send data through the network. This command is optional for Cisco CallManager version 3.1.3a or later. The default is no mgcp sdp simple.

Step 10 

Router(config)# mgcp fax t38 inhibit

(Optional) Prevents the MRP or ASI from sending T.38 fax gateway information to the CallManager. This command is required for operation with Cisco CallManager version 3.1.2c, but is optional for version 3.1.3a and later.

Step 11 

Router(config)# no mgcp timer receive-rtcp

(Optional) Prevents a timeout, which results in the disconnecting of a call, from occurring after a 30-second period of silence in one direction of the call. (This can happen during long voice message calls, for example.)

Configuring a System Card to Use MGCP with Cisco CallManager

The Cisco ICS 7750 MRP and ASI cards have the capability of using MGCP with Cisco CallManager for administration and redundant call agent features. This capability requires additional configuration steps.

To configure a system card so that it can be controlled by Cisco CallManager using MGCP, use the following commands, beginning in global configuration mode:

Command Purpose
Step 1 

MRP(config)# ccm-m anager MGCP

Enables support for Cisco CallManager within MGCP.

Step 2 

MRP(config)# ccm-m anager redundant host hostname1 hostname2

Identifies one or two backup Cisco CallManager servers. The arguments hostname1 and hostname2 specify the first and second backup servers, respectively, using the dotted decimal format (xxx.xxx.xxx.xxx).

Step 3 

MRP(config)# ccm-m anager switchback {graceful | immediate | schedule-time hh:mm | uptime-delay minutes}

Specifies how the gateway behaves if the primary server becomes unavailable and later becomes available again. The keywords and arguments are as follows:

  • graceful—Completes all outstanding calls before returning the gateway to the control of the primary Cisco CallManager server.
  • immediate—Returns the gateway to the control of the primary Cisco CallManager server without delay, as soon as the network connection to the server is reestablished.
  • schedule-time hh:mm—Returns the gateway to the control of the primary Cisco CallManager server at the specified time, where hh:mm is the time according to a 24-hour clock. If the gateway reestablishes a network connection to the primary server after the configured time, the switchback will occur at the specified time on the following day.
  • uptime-delay minutes—Returns the gateway to the control of the primary Cisco CallManager server when the primary server runs for a specified number of minutes after a network connection is reestablished to the primary server. Valid values are from 1 to 1440 (from 1 minute to 24 hours).

To force the MRP to use the backup Cisco CallManager server, use the following command, beginning in privileged EXEC mode:

Command Purpose
MRP# ccm-manager switchover-to-backup

Redirects the MRP or ASI gateway to the backup Cisco CallManager server.

Configuring Download of MGCP Voice Gateway Configuration Information from Cisco CallManager

When using the Cisco ICS 7750 as a voice gateway in conjunction with MGCP and Cisco CallManager Version 3.1, you can complete the necessary configuration for a gateway on the Cisco CallManager server and download the configuration to that gateway through a TFTP server.

Before performing the steps in this section, you should complete the basic configuration of your MGCP voice gateway by using the initial configuration dialog and the command-line interface (CLI). Your gateway configuration, as well as that of other network devices, must provide connectivity between your target gateway and the TFTP server.


Note   The IP host name should match the gateway name that is specified in the CallManager configuration.

After the required basic configuration of your MGCP voice gateway is completed and the gateway is reset, the configuration file, formatted in XML, is downloaded automatically from the Cisco CallManager server to your local gateway through a TFTP server. On receipt, the local gateway parses this file, converts it to Cisco IOS CLI commands, and uses it to update its active configuration.

After the initial download is completed, the local gateway saves some of the configuration file. If the gateway is restarted or reset and the specified TFTP server is not available, the gateway keeps trying to download the file and does not alter the current configuration.


Note   Downloading MGCP gateway configuration information does not override any existing local configuration information. For this reason, you should remove any existing MGCP settings before proceeding with the following steps.


Note   In this procedure, only "mgcp"- and "ccm-manager"-related configuration can be downloaded from the CallManager.

To enable the MGCP configuration download feature, use the following commands in EXEC configuration mode:

Command Purpose
Step 1 

Router# ccm-manager config server {ip-address | name}

Identifies the IP address of the Cisco CallManager TFTP serve and enables the download of the configuration information from the Cisco CallManager TFTP server to the MGCP voice gateway.

The arguments are as follows:

  • ip-address—Specifies the IP address of the TFTP server.
  • name—Specifies the DNS host name.
Step 2 

Router# ccm-manager config

Enables configuration download from the CallManager.

Step 3 

Router# copy running-config startup-config

Copies and saves the running gateway configuration information to NVRAM to prevent the information from being lost during gateway resets, power cycles, or power outages.

Note After completing the above steps, use the Cisco CallManager Administrator to reset the MGCP voice gateway.

Configuring MGCP T1 CAS

To configure T1 CAS for MGCP support, 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)# framing {esf | sf)

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

  • esf—Specifies Extended Superframe as the T1 frame type.
  • sf—Specifies Super Frame as the T1 frame type. This is the default.
Step 3 

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 4 

Router(config-controller)# ds0-group ds0-group-no timeslots timeslot-list type {e&m-delay-start | e&m-wink-start}

Specifies the DS0 time slots that make up a logical voice port on a T1 controller and to specifies the signaling type.

The arguments and keywords are as follows:

  • ds0-group-no—Specifies a value from 0 to 23 that identifies the DS0 group.
  • timeslots timeslot-list—Specifies a single time-slot number, a single range of numbers, or multiple ranges of numbers separated by commas. For T1 signaling, allowable values are from 1 to 24. Examples are as follows:
    • 2
    • 1-15,17-24
    • 1-23
    • 2,4,6-12
  • type
    • e&m-delay-start—The originating endpoint sends an off-hook signal and then waits for an off-hook signal followed by an on-hook signal from the destination.
    • e&m-wink-start—E&M Mercury Exchange Limited Channel Associated Signaling (MEL CAS) wink-start signaling support.
Step 5 

Router(config-controller)# exit

Returns to global configuration mode.

Step 6 

Router(config)# dial-peer voice tag {pots}

Enters dial-peer configuration mode and specifies a dial peer.

Step 7 

Router(config-dial-peer)# application mgcpapp

Enables a specific application (in this case, MGCP) on a dial peer.

Step 8 

MRP(config-dial-peer)# port sub-unit/port

Selects the voice port used for the dial peer. The keywords are as follows:

  • sub-unit—Specifies the sub-unit number of the voice port. Valid values are as follows:
    • MRP or ASI81: 0 or 1.
    • ASI160: 0.
  • port—Specifies the port number. Valid values are:
    • MRP or ASI81 in slot 1: 0 or 1.
    • ASI81 in slot 0: 0 through 7.
    • ASI160: 0 through 15.

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 

Either

 

 

Router(config-controller)# cablelength long {0db | -7.5db | -15db | -22.5db}

Specifies a 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 of 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 3 

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 4 

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 Superframe 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 5 

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 6 

Router(config-controller)# exit

Returns to global configuration mode.

Step 7 

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 range from 0 to 23 for channelized T1; PRI time slots 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 8 

Router(config-if)# isdn switch-type [primary-4ess | primary-5ess | primary-dms100 | primary-ni | primary-net5 | primary-ntt | 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-ts014 (Optional)—Specifies the Australian T1 and E1 PRI switch.
Step 9 

Router(config-if)# isdn bind-L3 ccm-manager

Configures ISDN to backhaul Q.931. Repeat Step 1 through Step 8 for each T1 or E1 interface that will use backhaul.

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).

Blocking New Calls and Gracefully Terminating Existing Calls

You can block all new MGCP calls to the router and gracefully terminate all existing active calls, which means that an active call is not terminated until the caller hangs up. To block all new calls, use the following commands in global configuration mode:

Command Purpose
Step 1 

Router(config)# mgcp block-newcalls

Prevents the gateway from accepting new calls.

Step 2 

Router(config)# no mgcp block-newcalls

Restarts normal MGCP call operation.

Configuring Fax over MGCP

The Cisco ICS 7750 supports fax over IP using the MGCP protocol. There are two supported modes of fax over IP. The Cisco ICS 7750 can be configured to use either or both modes:

Fax Relay

In fax relay mode, the MRP terminates the T.30 fax signaling. Fax relay mode is the preferred method of transmitting fax traffic. Fax relay mode is enabled by default. The following command can be used to disable fax relay or to determine whether fax relay is enabled:

Command Purpose
MRP# no ccm-manager fax protocol cisco

Cisco fax relay over MGCP is enabled by default. You can disable it by using this command. If fax relay is disabled, the MRP will use fax pass-through by default.

To obtain information about the status of the configuration download feature, use the following privileged EXEC command on the MGCP voice gateway:

Router# show ccm-manager

The system displays the current status of the download feature, as shown in the following example.

MGCP Domain Name: MRP-000196663c29
Priority Status Host
============================================================
Primary Registered 10.0.0.50
First Backup None
Second Backup None
Current active Call Manager: 10.0.0.50
Backhaul/Redundant link port: 2428
Failover Interval: 30 seconds
Keepalive Interval: 15 seconds
Last keepalive sent: 1w4d (elapsed time: 00:00:06)
Last MGCP traffic time: 1w4d (elapsed time: 00:00:06)
Last failover time: None
Switchback mode: Graceful
MGCP Fallback mode: Not Selected
Last MGCP Fallback start time: 00:00:00
Last MGCP Fallback end time: 00:00:00
PRI Backhaul Link info:
Link Protocol: TCP
Remote Port Number: 2428
Remote IP Address: 10.7.4.50
Current Link State: OPEN
Statistics:
Packets recvd: 12192
Recv failures: 0
Packets xmitted: 12192
Xmit failures: 0
PRI Ports being backhauled:
Slot 1, port 1
Slot 1, port 0
Configuration Error History:
FAX mode: cisco
Router#
Fax Pass-Through

In fax pass-through mode, the MRP does not distinguish a fax call from a voice call. The fax communication between the two fax machines is carried in band over a "voice" call in its entirety. To use fax pass-through mode, use the following commands.


Note   To use fax pass-through mode on the Cisco ICS 7750, you must have Cisco CallManager version 3.1.3a or later. Fax pass-through mode cannot be used with Cisco CallManager version 3.1.2c or any earlier version.

Command Purpose
MRP# mgcp modem passthrough voip mode nse

Enables peer-to-peer RTP NSE signaling to coordinate disabling of the echo canceller, voice activity detection (VAD), and codec switchover.

MRP# mgcp modem passthrough voip redundancy

Enables redundant packets to improve reliability by protecting against packet loss.

For more information about configuring fax relay or fax pass-through over MGCP on the Cisco ICS 7750, see the document Implementing Fax Over IP on Cisco Voice Gateways at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_access/fxmdmnt.htm


Note   The above document lists H.323 as the only protocol available for fax over IP on the Cisco ICS 7750. Customers using Cisco IOS Version 12.2(4) XT3 can also configure Cisco fax relay and fax pass-through using the MGCP protocol.

Enabling Multicast Music-on-Hold

Cisco CallManager Version 3.1 supports putting callers on hold, with music supplied from a streaming multicast MOH server. This section describes how to enable the MOH feature on a Cisco ICS 7750 MGCP voice gateway so that it can support multicast streaming of music to callers who are on hold.

To configure multicast MOH on a Cisco ICS 7750 MGCP voice gateway, use the following command in global configuration mode:

Command Purpose
Router(config)# ccm-manager music-on-hold

Enables music-on-hold.

Network Security Considerations

Because connecting to the Internet presents security risks, use a set of overlapping security mechanisms, including authentication (verifying a person's identity), authorization (defining user access privileges), firewalls (hardware, software, or a combination of both that enforces security policies at the network boundary), and packet filters (software controls that prevent unauthorized packets from leaving or, in some cases, entering, the network).

You can use the ICS System Manager to configure authentication and authorization privileges. Therefore, this section describes only the following activities:

Setting Up a Firewall

Typically, a network firewall consists of several different machines. Figure 6-15 shows an example of a possible firewall architecture.


Figure 6-15   Typical Firewall Architecture


In the architecture shown in Figure 6-15, the router that is connected to the Internet forces all incoming traffic to go to the application gateway. The router that is connected to the internal network accepts packets only from the application gateway.

The application gateway institutes per-application and per-user policies. In effect, the gateway controls the delivery of network-based services both to and from the internal network. For example, only certain users might be allowed to communicate with the Internet, or only certain applications might be permitted to establish connections between an interior host and an exterior host.

Set up the route and packet filters to reflect the same policies (see the "Setting Up Packet Filters" section). If mail is the only permitted application, only mail packets should be allowed through the router. This restriction keeps the application gateway from being overwhelmed by packets it would otherwise discard.

Suppose that your network is set up as shown in Figure 6-16. The firewall router allows incoming new connections to one or more communication servers or hosts. Having a designated router act as a firewall clearly identifies the router's purpose as the external gateway and avoids encumbering other routers with this task. If the internal network needs to be isolated, the firewall router provides the point of isolation so that the rest of the internal network structure is not affected.


Figure 6-16   Controlling Traffic with a Firewall Router


Connections to the hosts are restricted to incoming File Transfer Protocol (FTP) requests and e-mail services, and incoming Telnet or modem connections are screened by the communication server.

Setting Up Packet Filters

You can set up packet filters on routers and servers to accept or deny packets from particular addresses or services. Packet filters augment authentication and authorization mechanisms.

Set up your security policy so that packet filters follow one of the following policies:

The first policy requires a thorough understanding of specific security threats and can be hard to implement.

The second policy is easier to implement and more secure because you do not have to predict future attacks for which packets should be denied. The second policy is also easier to test because there is a finite set of accepted uses of the network. Cisco devices that support Cisco IOS software implement this second type of policy in their packet filters, which Cisco calls access control lists (ACLs).

This section consists of the following topics concerning ACLs:

Access Control List Design

An ACL on an MRP, ASI, router, or switch running the Cisco IOS software always has an implicit deny-all statement at the end. Accept statements are processed before the implicit deny-all statement. (The statement is implicit because you do not actually have to enter it, although it is a good idea to enter it to make the behavior of the list more obvious.)

ACLs help you determine whether network traffic is forwarded or blocked at interfaces on an MRP, ASI, router, or switch. ACL definitions provide criteria that are applied to packets that enter or exit an interface. Typical criteria are the packet source address, the packet destination address, and the upper-layer protocol in the packet.

Because the Cisco IOS software tests a packet against each criterion in the list until a match is found, you should carefully design ACLs to provide good performance. By studying traffic flow, you can design the list so that most packets match the earliest conditions. Fewer conditions to check per packet means better throughput. It is best to order the list with the most general statements at the top and the most specific statements at the bottom, with the last statement being the general, implicit deny-all statement.

Access Control List Examples

To provide security on the firewall router, as shown in Figure 6-16, you can use ACLs as described below.

Suppose that you decide to permit incoming e-mail and news access for a few hosts, but you want to limit FTP, Telnet, and rlogin services only to hosts on the firewall subnet. You could use IP extended ACLs (range 100 to 199) and Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port numbers to filter traffic. When a connection is to be established for services such as e-mail, Telnet, FTP, and so forth, the connection attempts to open a service on a specified port number. You can, therefore, filter out selected types of service connections by denying packets that are attempting to use that service.

An ACL is invoked after a routing decision has been made but before the packet is sent out on an interface. The best place to define an ACL is on a preferred host, using a text editor. You can create a file that contains the ACL commands, place the file (marked readable) in the default TFTP directory, and then load the file onto the MRP, ASI, or router.


Note   The network server storing the file must be running a TFTP daemon and have TCP network access to the firewall router.

Examples of ACL entries follow (see Figure 6-16):

no access-list 101
access-list 101 deny ip B.B.0.0 0.0.255.255 0.0.0.0 255.255.255.255
access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 53
access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 123
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2049
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.2 0.0.0.0 eq 23
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 21
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 20
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 gt 1023
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 gt 1023
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.101 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.1.101 0.0.0.0 gt 1023

Note   Standard FTP uses ports above 1023 for its data connections. Therefore, for standard FTP operation, ports above 1023 must all be open. Also, every ACL must have an implicit "deny everything else" statement at the end to ensure that all attributes that are not expressly permitted are denied.

Applying Access Control Lists to Interfaces

After loading the ACL onto the ASI, MRP, or router, you can assign that ACL to a particular interface on that device. For example, if you want to filter traffic coming from outside your network (via the serial 0 interface) before allowing it to reach subnet 13 (via the ethernet 0 interface), you could use the following commands:

interface ethernet 0
ip access-group 101 in

Using Access Control Lists to Filter Incoming Traffic

You can filter packets before they enter the ASI, MRP, or router (using input ACLs), instead of filtering them as they leave the device (using output ACLs). In most cases, input ACLs and output ACLs accomplish the same functionality. However, input ACLs can be used to prevent some types of IP address "spoofing" when output ACLs do not provide sufficient security.

Figure 6-17 shows a host that is spoofing (illegally claiming to be an address that it is not). Someone in the outside world is claiming to originate traffic from internal network 131.108.17.0. Although the address is spoofed, the router interface to the outside world assumes that the packet is coming from 131.108.17.0. If the input ACL on the router allows traffic coming from 131.108.17.0, it will accept the illegal packet. To prevent entry of spoofing traffic, an input ACL should be applied to the router interface to the outside world. This ACL would not allow any packets with addresses that are from the internal networks of which the router is aware (in this case, 17.0 and 18.0).


Figure 6-17   A Host That Is Spoofing


Configuring Cisco CallManager

You can configure Cisco CallManager on the SPE310 by logging in to the CallManager application as the administrator and using the password configured in ICSConfig. See the "Accessing Cisco CallManager" section.

This section discusses the following topics:

Differences in Configurations of Cisco CallManager on the Cisco ICS 7750

Because the Cisco ICS 7750 is an integrated voice and data system, there are a few differences between the way that Cisco CallManager is configured on the Cisco ICS 7750 and the way that Cisco CallManager is configured on a a standalone Cisco CallManager configuration. This section describes those differences, which include the following:

TFTP Server Configuration

The TFTP server configuration in ICSConfig takes precedence over the CallManager TFTP configuration. The IP address specified in the Phone TFTP IP field must be configured in ICSConfig because ICSConfig controls the value returned to the IP phones in the DHCP responses. This value must match the actual IP address of the SPE310 running the CallManager TFTP server. See the "Network ConfigurationIP Device Addresses Page Fields" section.

Cisco CallManager Configuration

The Cisco CallManager name, found in the Cisco CallManager Configuration screen, is automatically assigned. This name matches the host name given to the SPE310 on which Cisco CallManager is installed using the naming convention CM_ICS7700-XXXXXXX. Do not change the Cisco CallManager name. Changing the name will require that the SPE310 host name be changed according to the instructions in the "Updating Microsoft SQL Server with the New Host Name" section.

Cisco CallManager Server Configuration

The Cisco CallManager server is automatically configured when you install Cisco CallManager on the Cisco ICS 7750. The CallManager server defaults to the host name assigned to the SPE310 in the form of ICS7700-XXXXXXX. You can change this name in the Server Configuration screen. If your network uses Domain Name System (DNS) services, you can specify the DNS name of the server. If your network does not use DNS services, you must specify the IP address of the SPE310 on which Cisco CallManager is installed. Refer to the Cisco CallManager Administration Guide .

Cisco CallManager Music On Hold Audio Source Configuration

The Cisco ICS 7750 only supports internal music on hold (MOH) with .WAV files. If you want to use external music sources, such as a CD player, for recorded or live audio, such as Muzak, you will need to obtain an external Cisco CallManager hardware server to house a sound board that can be connected to an external source.

Cisco CallManager Configuration Checklist

Table 6-29 lists common configuration tasks that you might need to perform to configure Cisco CallManager on your Cisco ICS 7750. If you are not using a particular feature or component, you can skip the related step. You have some flexibility in the order for performing these tasks, and in some cases you might have to alternate between steps or return to a particular step several times to complete the configuration. Table 6-29 providers pointers to locations in the Cisco CallManager Administration Guide that provide instructions for performing configuration tasks.

Additional documentation to help you configure Cisco CallManager includes the following:

Table 6-29   Cisco CallManager Configuration Task Checklist

Task Cisco CallManager Administration Guide Done

Configure the Cisco CallManager Server to specify the address of the SPE310 on which Cisco CallManager is installed.

Refer to the "Server Configuration" section.

 

Use Cisco CallManager Configuration to specify the ports and other properties for each Cisco CallManager installed in the same cluster. A cluster comprises a set of Cisco CallManagers that share the same database.

Refer to the "Cisco CallManager Configuration" section.

 

Configure system-level settings:

  • Configure Cisco CallManager Group to specify a prioritized list of Cisco CallManagers for redundancy and call-processing load-balancing features. The first entry in the list serves as the primary Cisco CallManager for that group, and the other members of the group serve as secondary (backup) Cisco CallManagers.
  • Configure Date/Time Group to define time zones for the various devices connected to Cisco CallManager. Each device exists as a member of only one device pool, and each device pool has only one assigned Date/Time Group.
  • Use Device Defaults Configuration to set system-wide default characteristics for each type of device that registers with Cisco CallManager.
  • Configure Regions to specify the voice codec used for calls within a region and between existing regions. The voice codec determines the type of compression and maximum amount of bandwidth used per call. You do not need to configure regions if you are using only the default G.711 voice codec.
  • Configure Device Pools to define a set of common characteristics for devices (such as Cisco CallManager group, Date/Time Group, and Region).

 

Configure media resources:

  • Configure Media Resource Groups to manage media resources, such as transcoding, conferencing, music on hold, and media termination services, and enable resource sharing among Cisco CallManagers within the cluster.
  • Configure Media Resource Group Lists to specify a list of prioritized media resource groups. Media resource group lists are associated with devices to provide media resource group redundancy.
  • Configure Music On Hold to provide the ability to place on-net and off-net users on hold with music streamed from a streaming source.

 

Configure your dialing plan:

  • Configure Partitions in conjunction with Calling Search Spaces to implement calling restrictions and closed dial plan groups on the same Cisco CallManager.
    • A partition is a logical grouping of directory numbers (DNs) and route patterns with similar reachability characteristics.
    • A calling search space comprises an ordered list of partitions to determine which partitions calling devices (including IP phones, soft phones, and gateways) can search when attempting to complete a call.
  • Configure Route Filters to determine which route patterns your users can dial.
    • You can use only route filters with North American Numbering Plan (NANP) route patterns; that is, route patterns that use an at symbol (@) wildcard.
  • Configure Route Groups to prioritize a list of gateways and ports for outgoing trunk selection.
  • Configure Route Lists to associate a set of route groups with a route pattern and to determine the order in which those route groups are accessed.
  • Configure Route Patterns to route or block internal and external calls. A directory number specifies a type of specific route pattern that is applied to a Cisco IP Phone.

 

  • Configure Locations to implement call admission control in a centralized call processing system. Call admission control enables you to regulate voice quality by limiting the amount of bandwidth available for calls over links between locations.

Refer to the "Location Configuration" section.

 

Configure Gateways to enable communications with non-IP telecommunications devices.

Refer to the "Gateway Configuration" section.

 

Configure and install Cisco IP Phones and associate users.

Refer to the "Cisco IP Phone Configuration" and "Managing User Directory Information" sections.

 

Configure system-wide features:

  • Configure Call Park to place a call on hold, so that it can be retrieved from another phone in the system.
  • Configure Call Pickup and Group Call Pickup to answer a call that comes in on a directory number other than your own.
  • Configure Cisco IP Phone Services to define XML applications that enable the display of interactive content with text and graphics on Cisco IP Phones 7960 and 7940.
  • Configure Cisco Customer Response Applications 2.2(2) to enable Cisco IP Interactive Voice Response (IP IVR), Cisco IP Integrated Contact Distribution (IP ICD) and Cisco CallManager Extended Services, including IP Auto Attendant and Extension Mobility.

 

Backing Up Cisco CallManager

Cisco CallManager uses the Cisco IP Telephony Applications Backup Utility to back up Cisco CallManager data. You can back up your Cisco CallManager data to a configured network share device or to a local directory, using Backup Server or Backup Target.

Backup Server performs the backup operation by storing the backup data in the destination you specify. If an SPE310 is configured as a Backup Server, Cisco CallManager will automatically add it to the Backup Target list.

Since the Cisco Call Manager Publisher contains the data to be backed up, you should configure the SPE310 running the Cisco CallManager Publisher as the Backup Server.

To back up the Cisco CallManager data, refer to Backing Up and Restoring Cisco CallManager Release 3.1.

For additional guidelines for using backup and restore, refer to Cisco CallManager Backup and Restore Guidelines.

Running Network Time Protocol

When you install Cisco CallManager on the SPE, NTP is installed as part of that installation.

NTP provides a common time base for networked routers, servers, and other devices. NTP is designed to synchronize the time on a network of machines. A synchronized time allows for correlating of syslog and Cisco IOS debug output to specific events. Call records for specific users can be found within one millisecond.

NTP runs by means of UDP, using port 123 as both the source and destination. UDP runs over IP. NTP Version 3 RFC 1305 is used to synchronize timekeeping among a set of distributed time servers and clients. A set of nodes on a network is identified and configured with NTP. The nodes form a synchronization subnet, sometimes referred to as an overlay network.

An NTP network usually obtains its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of one another.

XNTPD.exe is the executable for the NTP service. XNTP is provided as an alternative time synchronization service to Windows' native W32Time service. The XNTP client allows time synchronization with any reachable NTP time server.

You can run the NTP service on the Cisco ICS 7750 to ensure that the dates and times maintained by all the servers in a CallManager cluster are kept in sync. The XNTP client is a preferred method of timekeeping when CallManager servers are not members of a Windows NT/2000 domain structure. Refer to the Network Time Protocol: Best Practice White Paper for information on how to configure the XNTP client to keep time with multiple NTP servers for accuracy and redundancy.

It is highly recommended that the NTP and Service Time Stamp features of Cisco IOS be implemented on your network in order to facilitate coordination of syslog and SNMP events.

For an explanation of NTP, refer to the Time Synchronization Server website at http://www.eecis.udel.edu/~ntp/.

For Cisco IOS configuration examples that incorporate NTP, refer to Clock, Calendar, and NTP Configuration Examples available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/cbook/csysmgmt.htm#31645.

Installing and Configuring Cisco Unity Voice Messaging

Cisco Unity is a Windows 2000-based communications solution that integrates with Cisco CallManager and works with Microsoft Exchange 2000 to deliver and store messages.

The Cisco ICS 7750 provides all the IP telephony features available with Cisco CallManager. With an additional SPE310 card, the Cisco ICS 7750 can also support Cisco Unity Voice Messaging and automated attendant features.

Refer to the following documentation for Cisco Unity installation and configuration information:

http://www.cisco.com/univercd/cc/td/doc/product/voice/ics7750/icsapps/uvminst/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/voice/ics7750/icsapps/uvmrelnt/uvmrelnt.htm

http://www.cisco.com/univercd/cc/td/doc/product/voice/ics/icsapps/icsunity/uvm312/upgrd312.htm

http://wwwin-itg.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/ics/icsapps/icsunity/uvm313/setupins/uvminst.htm

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity30/integuid/callma31/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity30/sag/sag301/index.htm

Configuring the System for Voice Mail

You can configure the Cisco ICS 7750 to work with voice-mail solutions that support the Simplified Message Desk Interface (SMDI). These voice-mail solutions include Cisco Unity running on an external server and traditional legacy voice-mail solutions, such as the Octel 250.

This section tells how to configure the Cisco ICS 7750 and associated components for voice mail. Complete the procedures in the section appropriate section for your configuration:

Direct Serial Connection to the Cisco ICS 7750

This section tells how to configure the system to support a direct serial connection to an Octel 250 or to a voice-mail server. It includes the following tasks:

Preparing External Components

Follow these steps to connect and configure an external voice-mail server or Octel 250 for use with the Cisco ICS 7750:


Step 1   Connect the voice-mail server or Octel 250 to the appropriate serial communications port on the system alarm processor (SAP). (Refer to the "SAP Card Connections" section in the "Installing the Cisco ICS 7750" chapter in the Cisco ICS 7750 Hardware Installation Guide .)

Step 2   Configure the voice-mail server or Octel 250. (Refer to the documentation that came with your messaging software or Octel 250.)

Step 3   Continue with "Configuring Cisco CallManager" section.



Configuring Cisco CallManager

This section tells how to configure Cisco CallManager on the Cisco ICS 7750 for a direct serial connection through the SAP to an external voice-mail server or an Octel 250. It includes the following tasks:

Configuring Route Groups in Cisco CallManager

Follow these steps to configure a route group that contains the serial port of the external voice-mail server or Octel 250:


Step 1   Access Cisco CallManager (see the "Accessing Cisco CallManager" section).

Step 2   Choose Route Plan > Route Group > Add a New Route Group.

The Route Group Configuration dialog box appears.

Step 3   In the Route Group Name field, enter a name for the route group, such as VoiceMail.

Step 4   Click Continue.

The screen refreshes and the route group name that you entered appears.

Step 5   Click the drop-down arrow to view a list of choices for the Device Name field. Choose the voice-mail port on the external server that is running your messaging software or the appropriate serial port on the CF card of the Octel 250.

Step 6   Click the drop-down arrow to view a list of choices for the Port field, and choose All.

Step 7   Click the drop-down arrow to view a list of choices for the Order field, and choose 1.

Step 8   Click Insert.

The screen refreshes and displays the configuration that you entered.

Step 9   Click Add Device to add the voice-mail port that you configured to your route group.



Continue with the "Creating a Route List in Cisco CallManager" section.

Creating a Route List in Cisco CallManager

Follow these steps to associate the voice-mail route group containing the serial port on the external voice-mail server or Octel 250 with a route list:


Step 1   Choose Route Plan > Route List > Add a New Route List.

The Route List Configuration dialog box appears.

Step 2   In the Route List Name field, enter a name for the route list, such as VoiceMail.

Step 3   Click Insert.

The screen refreshes and displays the name of the route list that you specified.

Step 4   Click Add Route Group.

The screen refreshes and displays the name of your voice-mail route group in the Select Route Groups (ordered by priority) field.

Step 5   Choose your voice-mail route group from the Select Route Groups (ordered by priority) field.

Step 6   Click Add.

The Route Details Configuration dialog box appears.

Step 7   Click Insert.

The screen refreshes and displays the default settings for your voice-mail route list.



Continue with the "Configuring a Route Pattern in Cisco CallManager" section.

Configuring a Route Pattern in Cisco CallManager

Follow these steps to associate the voice-mail route list with a route pattern:


Step 1   Choose Route Plan > Route Pattern.

Step 2   Click Add a New Route Pattern.

The Route Pattern Configuration dialog box appears.

Step 3   Enter the appropriate route pattern in the Route Pattern field.

Step 4   Click the drop-down arrow to view a list of choices for the Gateway/Route List field. Choose the voice-mail route list that you created in the "Creating a Route List in Cisco CallManager" section.

Step 5   Click Insert.

The screen refreshes and displays the selections that you made.



Continue with the "Configuring the Cisco Messaging Interface in Cisco CallManager" section.

Configuring the Cisco Messaging Interface in Cisco CallManager

Follow these steps to configure Cisco CallManager to communicate with the SAP COM port that you are using for voice mail:


Step 1   Choose Service > Cisco Messaging Interface.

Step 2   Click the drop-down arrow to view a list of choices for the Select New Server field, and choose the IP address of the target SPE310.

Step 3   Click Insert.


Note    Cisco Messaging Interface can take several minutes to detect and load new parameters.

The page refreshes. The IP address of the selected SPE310 is displayed in the left pane.

Step 4   Click the Command Line Parameters radio button.

Step 5   To make changes to an existing service parameter, highlight the parameter in the Configured Service Parameters list. Make the changes in the Type and Value fields. Then click Update.


Caution   Do not change service parameters unless you fully understand the feature that you are changing or unless the change is specified in this document.

Step 6   Repeat Step 5 for each service parameter you want to configure. You might need to change the following service parameters:


Note    Many voice-mail systems can be configured to use different baud rates, but 9600 is usually correct.


Note    The Parity settings can be None, Even, Odd, Mark, or Space. Settings are usually Even or None—Mark and Space are rarely used. This field is not case sensitive.


Note    To restore the Cisco CallManager default service parameter settings, click Default. A message is displayed that states that you are about to permanently delete any previous settings and replace them with the default settings. Click OK to continue, or click Cancel to keep the current settings.



Go to the "Using Network Management Solutions with the Cisco ICS 7750" section.

Using Network Management Solutions with the Cisco ICS 7750

This section describes various Network Management Solutions (NMS) available for use with the Cisco ICS 7750.

CiscoWorks2000

The CiscoWorks2000 product line provides network management solutions focused on two key administrative areas: wide-area and local-area switched network management. Each of these areas integrates new and existing Cisco applications into an enhanced web-based management solution.

CiscoWorks2000 solutions assist in managing the enterprise network in the following areas:

Several advanced applications are also available:

For information on how you can use Internet technology to integrate management tools, refer to Building the Management Intranet: Using Internet Technology to Integrate Management Tools and Information.

To view detailed information about any of the CiscoWorks2000 product line, including solutions for VPN/security management, LAN management, resource management and service management, refer to the CiscoWorks2000 website.

LAN Management Solution

LMS features web versions of the Layer 2/Layer 3 topology tool, user tracking, virtual LAN (VLAN) manager, path trace, and other functions from CWSI. Table 6-30 summarizes the applications included in LMS.

Table 6-30   CiscoWorks2000 LAN Management Solution Applications

Application Key Function Key Benefits

Campus Manager

Layer 2/Layer 3 switch topology representation with a device locator

Displays the physical and logical relationship between Cisco devices, including link type, device type, and discrepancies

VLAN and ATM configuration tools

Provides a table-type interface for creating and managing VLANs and ATM networks

Analysis of connectivity between two devices in the network

Traces data paths between specific end station devices or IP phone handsets in the network to determine packet responsiveness and the list of devices making up the connection

Extensive user tracking tool

Finds users based on MAC connectivity; provides detailed information about users, work stations, or handsets such as IP address, subnet, and VLAN

Content Flow Monitor

Performance monitoring for Cisco load-balancing server devices

Monitors the resource utilization of the Cisco LocalDirector and Cisco 7200 series server devices

TrafficDirector

RMON/RMON2 statistics collection from Cisco devices and probes

Monitors and troubleshoots LAN traffic at the physical, protocol, and application layers

Setup of traffic-related thresholds and monitoring of historical traffic patterns

Implements a proactive monitoring system to inform you of unusual traffic characteristics

Resource Manager Essentials

Consolidated troubleshooting tools device center

Switch and router analysis tools accessible from a single location; linkage of third-party applications to device center

Detailed software and hardware inventory reporting

Provides accurate Cisco inventory baseline information, including information on memory, slots, software versions, and boot ROMs, to aid in making decisions about the network

Automated update engine for device software and configuration

Can send router and switch device software updates to selected devices on a schedule; reduces time and errors involved in network updates

Centralized change audit logging and application access security

Comprehensive change monitoring log records users and applications active on the network; desktop controls user access to applications, ensuring that only appropriate class of user can access tools that change network parameters

CiscoView

Web-based graphics device management

Displays a console representation of Cisco router and switch devices, color-coded to indicate operational status, with access to configuration and monitoring tools

Routed WAN Management Solution

Routed WAN Management Solution provides wide-area network monitoring, troubleshooting, traffic management, access control, and applications for administering the routed infrastructure of multiservice and VPN routing platforms built with Cisco products. Table 6-31 summarizes the applications included in the Routed WAN Management Solution.

Table 6-31   CiscoWorks2000 Routed WAN Management Solution Applications

Application Key Function Key Benefits

Access Control List (ACL) Manager

ACL optimization

Improves router performance by organizing ACL filters to sort by most frequent usage patterns

ACL profiles

Allows administrators to quickly and uniformly apply and update policy-based ACLs, reducing WAN costs and enhancing security management

ACL distribution

Allows administrators to automate the updating of ACL information in multiple devices

Internetwork Performance Monitor (IPM)

Monitoring of WAN response time characteristics

Determines the responsiveness of WAN connections to find bottlenecks; provides real-time analysis of end-to-end hop delays

TrafficDirector

RMON/RMON2 statistics collection from Cisco devices and probes

Monitors and troubleshoots LAN traffic at the physical, protocol, and application layers

Set up of traffic-related thresholds and monitoring of historical traffic patterns

Implements a proactive monitoring system to inform you of unusual traffic characteristics

Resource Manager Essentials

Consolidated troubleshooting tools device center

Switch and router analysis tools accessible from a single location; linkage of third-party applications to device center

Detailed software and hardware inventory reporting

Provides accurate Cisco inventory baseline information, including information on memory, slots, software versions, and boot ROMs, to aid in making decisions about the network

Automated update engine for device software and configuration

Can send router and switch device software updates to selected devices on a schedule; reduces time and errors involved in network updates

Centralized change audit logging and application access security

Comprehensive change monitoring log records users and applications active on the network; desktop controls user access to applications, ensuring that only appropriate class of user can access tools that change network parameters

CiscoView

Web-based graphics device management

Displays a console representation of Cisco router and switch devices, color-coded to indicate operational status, with access to configuration and monitoring tools

Service Management Solution

SMS provides capabilities for managing network service levels and monitoring quality of service (QoS) embedded within Cisco infrastructures. Table 6-32 summarizes the applications included in SMS.

Table 6-32   CiscoWorks2000 Service Management Solution Applications

Application Key Function Key Benefits

Service Level Manager

Authoring tool for defining service-level contracts

Allows administrators to quickly and uniformly define service-level contracts (SLCs) and service-level agreements (SLAs)

Service-level monitoring and reporting

Allows both business and operational personnel to quickly view service-level conformance

ME1100 Hardware Collector

Data collection

Provides an interface and data collection between the service-level manager software and the device on which the SA agent is configured

CiscoView

Web-based graphics device management

Displays a console representation of Cisco router and switch devices, color-coded to indicate operational status, with access to configuration and monitoring tools

Cisco Management Connection

End-to-end service-level management

Allows service-level data to be shared with third-party and customer applications, enabling end-to-end management

Third-Party Applications

Network management platforms discover network devices and poll them for information. Some common network management platforms include the following:

Each network device is represented by a graphical element on the management platform's console. Different colors on the graphical elements represent the current operational status of network devices. Network devices can be configured to send notifications called SNMP traps to network management platforms. SNMP, widely used for monitoring and configuring network elements, uses an authentication method based on a community string. This community string is essentially a password used for accessing the network element. Upon receiving the notifications, the graphical element representing the network device changes to a different color, depending on the severity of notification received. The notification, usually called an event, is placed in a log file.

It is important that the most current Cisco Management Information Base (MIB) files be loaded on the SNMP platform to ensure that the various alerts from Cisco devices are interpreted correctly. You can find published MIB files for managing various network devices on the Cisco MIBs website:

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

For information about important MIB objects to monitor to ensure that the CallManager, gateways, trunks, and phones are working, refer to the Cisco SNMP MIBs for Fault Management table at:

http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/solution/6_operat.htm#34645


hometocprevnextglossaryfeedbacksearchhelp
Posted: Sun Jan 19 02:32:02 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.