Cisco ICS 7750 Installation and Configuration Guide, 2.5.0
Configuring the Cisco ICS 7750
Downloads: This chapterpdf (PDF - 1.15MB) The complete bookPDF (PDF - 5.02MB) | Feedback

Configuring the Cisco ICS 7750

Table Of Contents

Configuring the Cisco ICS 7750

Setting the System Date and Time

Setting the Date and Time on SPE310 Cards

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

Configuring MRPs and ASIs

System Card Overview

Key Features of MRP200 and MRP300 Cards

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

Supported WICs, VICs, and VWICs

Codec/DSP Overview

Voice Compression Algorithms (Codecs)

Codec Interoperability

Delay

DSP Groups

Choosing Codecs

Choosing DSP Firmware

Determining How Many DSPs Are Needed

Transcoding

Configuring Fast Ethernet Ports

Configuring WAN Interfaces

Configuring Asynchronous/Synchronous Serial WICs

Configuring ISDN BRI WICs

Configuring T1 and Fractional T1 WICs

Configuring VWICs for Data-Only Transmission

Configuring the TDM Clock

Scenarios for TDM Clocking

Voice over IP

Voice Ports Overview

Configuring Dial Plans

Configuring Analog Voice Ports

Configuring Digital Voice Ports

Configuring ISDN Interfaces for Voice

Configuring VoIP for Frame Relay

TDM Clocking Scenarios

Configuring VLANs

Sample VLAN Configuration

Configuring Quality of Service

Need for Quality of Service

Configuring Low-Latency Queuing

Configuring Weighted Fair Queuing

Configuring IP Precedence or IP DSCP Packet Marking

Configuring RSVP for Voice

Enabling RSVP

Configuring Multilink PPP with Interleaving

Configuring RTP Header Compression

Enabling RTP Header Compression on a Serial Interface

Changing the Number of Header Compression Connections

H.323 Overview

MGCP Overview

Gateway Types

ISDN PRI Backhaul

Multicast Music-on-Hold

Configuring MGCP

Configuring the SSP

Features

SSP Configuration Tasks

SSP VLAN Configuration

Network Security Considerations

Setting Up a Firewall

Setting Up Packet Filters

Access Control List Design

Access Control List Examples

Applying Access Control Lists to Interfaces

Using Access Control Lists to Filter Incoming Traffic

Configuring Cisco CallManager

Differences in Configurations of Cisco CallManager on the Cisco ICS 7750

TFTP Server Configuration

Cisco CallManager Configuration

Cisco CallManager Server Configuration

Cisco CallManager Music-on-Hold Audio Source Configuration

Cisco CallManager Configuration Checklist

Backing Up Cisco CallManager

Running Network Time Protocol

Installing and Configuring Cisco Unity Voice Messaging

Configuring the System for Voice Mail

Direct Serial Connection to the Cisco ICS 7750

Preparing External Components

Configuring Cisco CallManager

Using Network Management Solutions with the Cisco ICS 7750

CiscoWorks2000

LAN Management Solution

Routed WAN Management Solution

Service Management Solution

Third-Party Applications


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.


Note Before using the IOS command-line interface (CLI) to configure any system cards, be sure to read the "Best Practices for Using the IOS CLI" section. Using the CLI to configure certain parameters, such as system card IP addresses, can prevent the Cisco ICS 7750 from functioning properly.


This chapter contains these sections:

Setting the System Date and Time

Configuring MRPs and ASIs

Configuring the SSP

Network Security Considerations

Configuring Cisco CallManager

Running Network Time Protocol

Installing and Configuring Cisco Unity Voice Messaging

Configuring the System for Voice Mail

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

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


Note For information about using NTP on the Cisco ICS 7750, see the "Running Network Time Protocol" section.


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:

If you already have a Terminal Services Client connection defined for the SPE310, select it, and choose File > Connect.

If you do not have a Terminal Services Client connection defined for the SPE310, choose File > New Connection. Follow the instructions in the wizard, and then choose File > Connect.

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:

zone is the name of the time zone to be displayed when standard time is in effect (such as Pacific Standard Time, or PST)

hours is the number of hours offset from Coordinated Universal Time (UTC)

(optional) minutes is the number of minutes offset from UTC

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:

hh:mm:ss is the current time in hours, minutes, and seconds. Note that this is a 24-hour clock, so 10:03:00 p.m. would be entered as 22:03:00.

day is the current day in the month, entered as a two-digit date.

month is the current month, entered as a three-letter abbreviation. November, for example, would be entered as nov.

year is the current year entered as a four-digit year, such as 2001.


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 MRPs and ASIs

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

System Card Overview

Codec/DSP Overview

Configuring Fast Ethernet Ports

Configuring WAN Interfaces

Voice over IP

Configuring VLANs

Configuring Quality of Service

H.323 Overview

MGCP Overview

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:

Voice- and data-capable routers that support both digital and analog voice trunks and WAN routing interfaces and that can link remote Ethernet LANs to the PSTN and existing private branch exchanges (PBXs), as well as most common analog devices such as fax machines and teleconferencing stations.

Slots for two WAN interface cards (WICs), voice interface cards (VICs), or voice WAN interface cards (VWICs).

Support for the following T1/E1 configurations:

Two T1/E1 ports with voice payload (no more than 24 simultaneous calls per MRP [T1] or no more than 30 simultaneous calls per MRP [E1]).

No more than one T1/E1 data port.

No more than one channelized T1/E1 group for data.

Up to two external clock sources.

H.323 and Quality of Service (QoS) for voice support.

G.711, G.723.1, G.726, and G.729 codec support.

Hot-swap support (MRP cards are hot-swappable, but any WICs, VICs, and VWICs installed within the MRPs are not hot-swappable).

Configuration files for the MRP200 are stored on the SPE310 running System Manager.

Configuration files for the MRP300 are stored in NVRAM.

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:

ASI81 and MRP3-8FXS—Voice-and-data-capable routers that can carry voice traffic over an IP network, that can link small-to-medium-size remote Ethernet LANs to central offices over WAN links (depending on the type of card installed in its WIC/VIC/VWIC slot), and that can support eight connections to analog telephones, fax machines, and polycoms

ASI160 and MRP3-16FXS—Analog gateways that support 16 connections to telephones, fax machines, and teleconferencing stations.

H.323 and QoS for voice support.

G.711, G.723.1, G.726, and G.729 codec support.

Hot-swap support (system cards are hot-swappable, but any WIC, VIC, or VWIC installed within an ASI81 or MRP3-8FXS card is not hot-swappable).

ASI81 and ASI160—Configuration files are stored on the SPE310 running System Manager.

MRP3-8FXS and MRP3-16FXS—Configuration files are stored in NVRAM.


Note The MRP300, MRP3-8FXS and MRP3-16FXS cards have additional functionality provided by 16 MB of onboard Flash memory, with 64 MB of add-on Flash memory available as an option.


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-2 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-2 MRP and ASI Card Codec Options 

   
Channels per DSP—
Digital Image 1
Channels per DSP—
Analog Image
Codec
Bandwidth
Medium Complexity
High Complexity
Medium Complexity 2
High Complexity 3

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

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

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

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

4 32 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:

G.729 and G.729a

G.729 and G.729

G.729a and G.729a

G.729 Annex-B and G.729a Annex-B

G.729 Annex-B and G.729 Annex-B

G.729a Annex-B and G.729a Annex-B

The following G.723.1 codec combinations interoperate:

G.723.1 (5.3 kbps) and G.723.1 (6.3 kbps)

G.723.1 (5.3 kbps) and G.723.1 (5.3 kbps)

G.723.1 (6.3 kbps) and G.723.1 (6.3 kbps)

G.723.1 Annex-A (5.3 kbps) and G.723.1 Annex-A (6.3 kbps)

G.723.1 Annex-A (5.3 kbps) and G.723.1 Annex-A (5.3 kbps)

G.723.1 Annex-A (6.3 kbps) and G.723.1 Annex-A (6.3 kbps)

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-3 shows the delay that is introduced by different codecs.

Table 6-3 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-4 provides some examples of the number of calls that can be supported on a single DSP, depending on the codec used. Table 6-5 lists some of the combinations of calls that can be handled on a single DSP.


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


Table 6-4 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-5 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:

MRP200s and MRP300s—One DSP for every two ports (using the high-complexity image). For example, an MRP300 with two 2-port analog VICs requires two DSPs.

ASI81s and MRP3-8FXSs—One DSP for every two ports (using the high-complexity image) or one DSP for every four ports (using the medium-complexity image). For example, an MRP3-8FXSs with a 2-port VIC installed (for a total of 10 analog ports) requires five DSPs (assuming that the high-complexity image is used).

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:

Intra-LAN or PSTN-to-LAN calls—G.711 is recommended in situations such as the following:

Traffic between analog telephones and Cisco IP Phones (normally on the same LAN).

Traffic between an analog or digital trunk and a Cisco IP Phone.

Traffic between an analog telephone, an analog trunk, or a digital trunk and a software application (such as Cisco Unity).

Calls across a WAN link with limited bandwidth—If one Cisco IP Phone calls another Cisco IP Phone over a WAN link, a codec with voice compression/decompression may be desirable to save bandwidth. Cisco recommends G.711 encoding for LAN environments and G.729A across the WAN. The use of the G.729 family, with a compressed bit rate of 8 kbps, can result in bandwidth savings. Note that the actual bandwidth saving is also affected by the packetizing overhead inherent in Real-Time Transport Protocol (RTP), User Datagram Protocol (UDP), and IP headers.

Calls between an analog telephone and a Cisco IP Phone across a WAN link—G.729a is recommended for traffic between an analog telephone and a remote Cisco IP Phone (using VoIP over the WAN). G.723.1 cannot be used because Cisco IP Phones do not support G.723.1.

Choosing DSP Firmware

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

The codecs that must be supported

The number of voice channels required per DSP

Technical issues such as echo cancellation coverage

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-6 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-6 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

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

2 VWIC-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:

Codec complexity

Type of codec selected

Table 6-7 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-7 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

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

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



Note Table 6-7 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-7).


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:

Low-bit-rate to high-bit-rate (G.729a or G.723.1 to G.711 a-law or to G.711 U-law), or vice versa, configurations.

High-bit-rate to high-bit-rate (G.711 a-law to G.711 U-law), or vice versa, configurations.

Each instance of Cisco CallManager must have access to its own transcoding resources.

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:

Calls between Cisco IP Phones on the same LAN do not need transcoding, even if the Cisco IP Phones are assigned to different Cisco CallManager regions. For example, if a Cisco IP Phone in a G.729 region calls a Cisco IP Phone in a G.711 region (the default), the two Cisco IP Phones automatically negotiate a common codec.

Calls between Cisco IP Phones and an MRP or ASI in the same LAN do not need transcoding, even if the Cisco IP Phone and the MRP or ASI are in different regions. For example, if a G.729 gateway calls a Cisco IP Phone in a G.711 region, the Cisco IP Phone can communicate with the gateway.

If a gateway is configured to use G.723.1, transcoding is needed because Cisco IP Phones do not support G.723.1 and, therefore, cannot communicate with a G.723.1 gateway.

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:

Configuring Asynchronous/Synchronous Serial WICs

Configuring ISDN BRI WICs

Configuring T1 and Fractional T1 WICs

Configuring VWICs for Data-Only Transmission

Configuring the TDM Clock

Table 6-8 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-8 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-9 lists the half-duplex timer commands.

Table 6-9 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

1 CTS = Clear To Send

2 DCD = data carrier detect

3 RTS = Request To Send


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

Table 6-10 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-11 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-12 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:

Ask for two channels to be called by one number.

Ask for delivery of calling-line identification, also known as caller ID or automatic number identification (ANI).

If the MRP or ASI will be the only device attached to the ISDN BRI line, ask for point-to-point service and a data-only line.

If you plan to connect another ISDN device (such as an ISDN telephone) to the ISDN BRI line through the MRP, ask for point-to-multipoint service (subaddressing is required) and a voice-and-data line.


Note See the "Configuring ISDN BRI WICs" section for a sample configuration.


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

Table 6-13 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-14 lists the provisioning that you should order for switches used in North America.

Table 6-14 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.

1 SPID = service profile identifier

2 TEI = 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:

Maximum of one T1 or E1 data port

Only one channelized T1 or E1 group for data

Maximum of two external clock sources

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 or Frame Relay 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:

Voice Ports Overview

Configuring Dial Plans

Configuring Analog Voice Ports

Configuring Digital Voice Ports

Configuring ISDN Interfaces for Voice

Configuring VoIP for Frame Relay

TDM Clocking Scenarios


Note See the "Sample H.323 Call Routing Configurations" section for sample configurations,


Table 6-15 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-15 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:

FXS—The foreign exchange station (FXS) interface connects directly to a standard telephone, fax machine, PBX, or similar device and supplies ring, voltage, and dial tone.

FXO—The foreign exchange office (FXO) interface connects local calls to a PSTN CO or to a PBX that does not support E&M signaling. This interface is used for off-premises extension applications.

E&M—The E&M interface connects remote calls from an IP network to PBX trunk lines (tie lines) for local distribution. It is a signaling technique used for two-wire and four-wire telephone and trunk interfaces.

ISDN BRI—The ISDN BRI interface connects directly to PSTNs, PBXs, and private access branch exchanges (PABXs). ISDN BRI supports on-premises and off-premises connections.

MFT-T1 CAS—The MFT-T1 CAS interface connects remote calls from an IP network to the PBX and the CO.

T1/E1 PRI—The T1 PRI interface provides transmission of digital data over 23 B-channels and one D-channel (or 23B+D), for a total bandwidth of 1.544 Mbps. The E1 PRI provides transmission of digital data over 30 B-channels (64 Kbps) and one D-channel (64 Kbps), plus one framing channel (64 Kbps), for a total bandwidth of 2.048 Mbps.

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

FXO Interfaces

E&M Interfaces

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:

VIC-2FXO—Intended for use in North America. In the United States, Canada, and Mexico, use a standard RJ11 modular telephone cable to connect the VIC-2FXO to the PSTN or PBX through a telephone wall outlet.

VIC-2FXO-M1—Provides battery reversal detection and caller ID support (for use in North America).

VIC-2FXO-M2—Provides battery reversal detection and caller ID support (for use in Europe).

VIC-2FXO-M3—Provides battery reversal detection and caller ID support (for use in Australia).

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:

A POTS dial peer associates a physical voice port with a local telephone device. The key commands you need to configure are the port and destination-pattern.

The port command associates the POTS dial peer with a specific logical dial interface, which is typically the voice port connecting the MRP to the local POTS network.

The destination-pattern command defines the telephone number associated with the POTS dial peer.

A VoIP dial peer associates a telephone number with an IP address. The key commands you need to configure are the destination-pattern and session target.

The destination-pattern command defines the telephone number associated with the VoIP dial peer.

The session target command specifies a destination IP address for the VoIP dial peer.


Note See the "Configuring Dial Plans" section for sample configurations.


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-16 shows the number expansion table for this scenario.

Table 6-16 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-16 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

Local Dial Peers

Calling Between MRPs

Other MRPs on the Network

Configuring DID for ISDN

Configuring FXO Interfaces

Configuring E&M Interfaces

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

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-18 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-18 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-18 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-19 lists the phone numbers, voice ports, and dial-peer tags for this office.

Figure 6-4 Basic Voice Network (East MRP)

Table 6-19 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-19. 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-20 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-20 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-21.

Table 6-21 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-21 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-22 shows how to configure the East MRP to send calls to the West MRP.

Table 6-22 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-22.


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 1/0:23

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 1/0:23
 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 for ISDN voice ports 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:

dial-type {dtmf | pulse}—Selects the appropriate dial type for out-dialing.

signal {wink-start | immediate | delay-dial}—Selects the appropriate signal type for this interface.

cptone {australia | brazil | china | finland | france | germany | japan | northamerica | unitedkingdom}—Selects the appropriate voice call progress tone for this interface.

operation {2-wire | 4-wire}—Selects the appropriate cabling scheme for this voice port.

type {1 | 2 | 3 | 5}—Selects the appropriate E&M interface type.

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:

E&M—E&M signaling is typically used for trunks. It is normally the only way that a CO switch can provide two-way dialing with DID. In all the E&M protocols, off-hook status is indicated by A = B = 1, and on-hook status is indicated by A = B = 0. If dial pulse dialing is used, the A and B bits are pulsed to indicate the addressing digits. There are several further important subclasses of E&M robbed-bit signaling:

E&M Wink Start—Feature Group B

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.

E&M Immediate Start

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.

Ground Start is different from E&M in that the A and B bits do not track each other (that is, A is not necessarily equal to B). When the CO delivers a call, it seizes a channel (goes off-hook) by setting the A bit to 0. The CO equipment also simulates ringing by toggling the B bit. The terminating equipment goes off-hook when it is ready to answer the call. Digits are usually not delivered for incoming calls.

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:

Supervisory: line side

fxs-loop-start

fxs-ground-start

fxo-loop-start

fxo-ground-start

Supervisory: trunk side

e&m-wink

e&m-immediate-start

e&m-delay-dial

Prerequisites for Configuring Digital Voice Ports

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

Obtain T1 or E1 service from the service provider or from your PBX.

Create your company's dial plan.

Complete your company's dial plan. See the "Configuring Dial Plans" section.

Establish a working telephony network based on your company's dial plan, and configure the network for real-time voice traffic. See the "Voice over IP" section.

Establish a connection to the network LAN or WAN.

Install MRPs or ASIs containing T1 or E1 VWICs as required on your network.

Preparing Information to Configure Digital Voice Ports

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

Line interface: T1 or E1

Signaling interface: FXO, FXS, or E&M. If the interfaces are PRI or BRI, see the "Configuring ISDN Interfaces for Voice" section.

Line coding: Alternate mark inversion (AMI) or binary 8-zero substitution (B8ZS) for T1, and AMI or high density binary 3 (HDB3) for E1

Framing format: Super Frame (SF) (D4) or Extended Superframe (ESF) for T1, and CRC4, no-CRC4, or australia for E1

Number of channels

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:

ISDN Voice Interface Overview

ISDN Voice Interface Prerequisite Tasks

Configuring ISDN Voice Interfaces

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

Bypass PSTN tariffed services, such as trunking and administration.

Directly connect PBXs to a Cisco router so that PBX station calls can be routed automatically to the WAN.

Configure a voice interface on an MRP or ASI to emulate either a terminal equipment (TE) or network termination (NT) interface. Customers with all types of PBXs can send calls through a Cisco router and deliver those calls across the customer network.

Configure Layer 2 operation as point-to-point (static terminal endpoint identifier [TEI]) or point-to-multipoint (automatic TEI).

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:

Obtain PRI or BRI service and T1 or E1 service from your service provider, as required. Any BRI lines must be provisioned at the switch to support voice calls.

Establish a working IP network. You can configure MRPs for connectivity to the LAN or WAN.

Complete your company's dial plan. See the "Configuring Dial Plans" section.

Establish a working telephony network based on your company's dial plan, and configure the network for real-time voice traffic. See the "Voice over IP" section.

Install MRPs or ASIs containing digital T1 or E1 VWICs, BRI VICs, and other VICs as required on your network.

Configure voice ports. See the "Voice Ports Overview" section.

Configure voice dial peers. See the "Configuring Analog Voice Ports" section.

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-23 shows ISDN switch types. An ISDN switch type must be specified in your configuration.

Table 6-23 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:

To verify that the data configured is correct, use the show voice port command.

If you have not configured your device to support DID, dial in to the router, and verify that you have a dial tone.

Enter a dual tone multifrequency (DTMF) digit. If the dial tone stops, you have verified two-way voice connectivity with the router.

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:

Ping the associated IP address to confirm connectivity. If you cannot successfully ping your destination, refer to the "Configuring IP Addressing" chapter in the Cisco IOS IP Configuration Guide.

To view layer status information, use the show isdn status command. If you receive a status message stating that Layer 1 is deactivated, make sure that the cable connection is not loose or disconnected. (This status message indicates a problem at the physical layer.)

With T1 lines, determine whether your U-law setting is correct. With E1 lines, determine whether your A-law setting is correct. To configure both U-law and A-law values, use the cptone command. For more information about the cptone command, refer to the Cisco IOS Voice, Video, and Fax Command Reference.

If dialing cannot take place, use the debug isdn q931 command to check the ISDN configuration.

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:

Separate DLCIs for voice and data—By providing a separate subinterface for voice and data, you can use the appropriate QoS tool per line. For example, each DLCI would use 32 kbps of a 64-kbps line.

Apply adaptive traffic shaping to both DLCIs.

Use RSVP or IP Precedence to prioritize voice traffic.

Use compressed Routing Table Protocol (RTP) to minimize voice packet size.

Use weighted fair queuing to manage voice traffic.

Lower maximum transmission unit (MTU) size—Voice packets are generally small. With a smaller MTU size (for example, to 300 bytes), large data packets can be broken up into smaller data packets that can more easily be interwoven with voice packets.


Note Lowering the MTU size affects data throughput speed.


CIR equal to line rate—Make sure that the data rate does not exceed the CIR. This is accomplished through generic traffic shaping.

Use RSVP or IP Precedence to prioritize voice traffic.

Use compressed RTP to minimize voice packet header size.


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


Traffic shaping—Use adaptive traffic shaping to slow the output rate, based on the backward explicit congestion notification (BECN). If the feedback from the switch is ignored, packets (both data and voice) might be discarded. Because the Frame Relay switch does not distinguish between voice and data packets, voice packets could be discarded, which would result in a deterioration of voice quality.

Use RSVP, compressed RTP, reduced MTU size, and adaptive traffic shaping, based on BECN, to hold the data rate to CIR.

Use generic traffic shaping to obtain a low interpacket wait time. For example, set committed burst (Bc) to 4000 to obtain an interpacket wait of 125 milliseconds.

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

Provision the Frame Relay PVC to have the CIR equal to the port speed.

Use generic traffic shaping with RSVP.

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.

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:

Maximum of two T1 ports with voice payload. Even though an MRP can configure two T1 voice ports, it can only make 24 simultaneous calls.

Maximum of one T1 data port.

Only one channelized T1 group for data.


Note These scenarios apply to both data and voice MFT-T1 VWICs.


T1 in Slot 0

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

Table 6-24 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-24.


T1 in Both Slot 0 and Slot 1

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

Table 6-25 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-25.


T1 in Slot 0 and an Analog VIC in Slot 1

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

Table 6-26 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-26.


T1 in Slot 0 and a WIC in Slot 1

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

Table 6-27 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-27.


Configuring VLANs

Starting with system software release 2.5.0, all flash-based MRPs (MRP300, MRP3-8FXS, and MRP3-16FXS) support configuration of multiple virtual LANs (VLANs). Creation of multiple VLANs is desirable to increase voice Quality of Service (QoS). Data packets are loss-intolerant and not latency-sensitive, whereas voice packets have some tolerance to loss but are latency-sensitive. When voice and data packets travel on the same VLAN, the contention for resources between voice and data packets can affect the voice quality. When data, voice and video are placed in the same queue, packet loss and various delays are much more likely to occur. With use of multiple VLANs and separation of voice packets into a different queue from data, network behavior becomes much more predictable.

In terms of network design, grouping IP devices into different VLANs based on their physical or logical network topology might also be required. For example, the network designer might choose to group all IPT devices from the same floor or department into one single subnet.

Figure 6-13 shows a sample VLAN configuration in which voice and data devices reside on different VLANs.

Figure 6-13 Sample VLAN Topology

When configuring multiple VLANs, follow these guidelines:

All system cards in the chassis must be members of the management VLAN (VLAN 1).

At least one Flash-based MRP must be configured to be on all VLANs in order to route data between VLANs; otherwise, an external router must be used to route data between VLANs.

Outside the chassis, the SSP can support a maximum of 250 VLANs and 64 STP instances. The MRP can support a maximum of 300 VLANs.

The management VLAN (VLAN 1) IP address of the MRP300 must be configured via ICSConfig; therefore, it must reside on the primary fast Ethernet interface (0/0) of the MRP300.

Do not add a native VLAN sub-interface on the MRP300.

Do not configure the primary Fast Ethernet interface on the MRP300 to have "no ip address."


Note For more information about VLAN configuration, see the "Virtual LANs" chapter of the Cisco IOS Switching Services Configuration Guide, Release 12.2.


Sample VLAN Configuration

The following example configures two VLANs—VLAN 3 and VLAN 4. In this example, the management VLAN has an IP address of 10.10.10.6 and a subnet mask of 255.255.255.0. Note that the trunking encapsulation used is dot1q.

MRP#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
MRP(config)#int fastEthernet 0/0.3
MRP(config-if)#encapsulation dot1q 3
MRP(config-if)#ip address 10.10.11.6 255.255.255.0
MRP(config-if)#exit
MRP(config)#int fastEthernet 0/0.4
MRP(config-if)#encapsulation dot1q 4
MRP(config-if)#ip address 10.10.12.6 255.255.255.0
MRP(config-if)#exit
MRP(config)#^Z
MRP#write memory

Configuring Quality of Service

Separating voice and data packets onto different VLANs is not enough to ensure voice quality. 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.


Note This section is a quick overview of QoS topics. For more detailed information about QoS, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.


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

Figure 6-14 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 Low-Latency Queuing

Configuring Weighted Fair Queuing

Configuring IP Precedence or IP DSCP Packet Marking

Configuring RSVP for Voice

Configuring Multilink PPP with Interleaving

Configuring RTP Header Compression

Configuring Low-Latency Queuing

A priority queue is required for VoIP. You can use any queuing mechanism that effectively gives VoIP high priority; however, low latency queuing (LLQ) is recommended because it is flexible and easy to configure.

The most flexible queuing method that satisfies VoIP requirements is LLQ. LLQ uses the MQC configuration method to provide priority to certain classes and to provide guaranteed minimum bandwidth for other classes. During periods of congestion, the priority queue is policed at the configured rate so that the priority traffic does not monopolize all the available bandwidth. (If the priority traffic monopolizes the bandwidth, it prevents bandwidth guarantees for other classes from being met.) If you provision LLQ correctly, the traffic going into the priority queue should never exceed the configured rate.

LLQ also allows queue depths to be specified to determine when the router should drop packets if too many packets are waiting in any particular class queue. A class default is used to determine treatment of all traffic not classified by a configured class. The class default can be configured with the fair-queue interface configuration command, which means that each unclassified flow will be given an approximately equal share of the remaining bandwidth. Figure 6-15 shows how LLQ works.

Figure 6-15 LLQ Operation

In Figure 6-15, all traffic going out of an interface or subinterface (for Frame Relay) is first classified using MQC. There are four classes: one high priority class, two guaranteed bandwidth classes, and a default class. The priority class traffic is placed into a priority queue, and the guaranteed bandwidth class traffic is placed into reserved queues. The default class traffic can be given a reserved queue or can be placed in an unreserved default queue, where each flow will get an approximately equal share of the unreserved and available bandwidth. The scheduler services the queues so that the priority queue traffic is output first unless it exceeds a configured priority bandwidth and this bandwidth is needed by a reserved queue (that is, there is congestion). The reserved queues are serviced according to their reserved bandwidth, which the scheduler uses to calculate a weight. The weight is used to determine how often a reserved queue is serviced and how many bytes are serviced at a time. The scheduler services are based on the weighted fair queuing (WFQ) algorithm, a discussion of which is beyond the scope of this document.

If the priority queue fills up because the transmission rate of priority traffic is higher than the configured priority bandwidth, the packets at the end of the priority queue will be dropped only if no more unreserved bandwidth is available. None of the reserved queues are restricted to the configured bandwidth if bandwidth is available. Packets violating the guaranteed bandwidth and priority are dropped only during periods of congestion. You must therefore provision the priority queue with enough bandwidth to handle all the VoIP traffic requiring priority servicing.

The following configuration example shows how to configure LLQ:

access-list 100 permit udp any any range 16384 32000
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
access-list 102 permit tcp any any eq 23
!
class-map voip 
 match access-group 100
class-map data1
 match protocol
class-map data2 
 match access-group 102
!
policy-map llq 
 class voip 
  priority 32 
 class data1 
  bandwidth 64 
 class data2 
  bandwidth 32 
 class class-default 
  fair-queue
!
interface Serial1/0 
 bandwidth 256 
service-policy output llq
 

In this example, any traffic that matches access list 100 will be classified as class VoIP (voice traffic) and given high priority up to 32 kbps. Access list 100 matches the common UDP ports used by VoIP and H.323 signaling traffic to TCP port 1720. The class data1 command matches web traffic (TCP port 80 as seen in access list 101) and guarantees 64 kbps; the class data2 command matches Telnet traffic (TCP port 23 as seen in access list 102) and guarantees 32 kbps. The default class is configured to give an equal share of the remaining bandwidth to unclassified flows. The policy is called llq, and it is applied on outgoing traffic on serial interface 1/0, which has a total bandwidth of 256 kbps.


Note By default, the total guaranteed bandwidth and priority bandwidth for all classes should be less than 75 percent of the interface bandwidth. You can modify this percentage by using the max-reserved bandwidth interface configuration command.


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 or IP DSCP Packet Marking

Associating a packet with an IP Precedence or IP DSCP marking allows users to classify traffic based on IP Precedence and IP DSCP value, depending on which value is marked. These markings can be used to identify traffic within the network, and other interfaces can match traffic based on the IP Precedence or DSCP markings.

IP Precedence and DSCP markings are used to decide how packets should be treated in Weighted Random Early Detection (WRED).

The IP DSCP value is the first 6 bits in the ToS byte, while the IP Precedence value is the first 3 bits in the type of service (ToS) value. The IP Precedence value is actually part of the IP DSCP value. Therefore, both values cannot be set simultaneously. If both values are set simultaneously, the packet is marked with the IP DSCP value.

If you need to mark packets in your network and all of your devices support IP DSCP marking, use the IP DSCP marking to mark your packets, because the IP DSCP markings provide more packet marking options. If marking by IP DSCP is undesirable, however, or if you are unsure whether the devices in your network support IP DSCP values, use the IP Precedence value to mark your packets. The IP Precedence value is likely supported by all devices in the network.

A user can set up to 8 different IP Precedence markings and 64 different IP DSCP markings.

For more information about IP Precedence and IP DSCP marking, refer to the "Configuring Class-Based Packet Marking" chapter in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

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:

Small-scale voice network implementation

Links slower than 2 Mbps

Links with high utilization

Need for the best possible voice quality

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:

Point-to-point connection using PPP encapsulation

Links slower than 2 Mbps


Note Do not use multilink PPP on links faster than 2 Mbps.


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:

Configure the dialer interface or virtual template, as defined in the relevant chapters of the Cisco IOS Dial Technologies Configuration Guide.

Configure multilink PPP and interleaving on the interface or template.


Note See the "Configuring Multilink PPP with Interleaving" section for sample configurations of multilink PPP and interleaving on a configured and operational interface or virtual interface template.


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

Figure 6-16 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:

Links slower than 2 Mbps

Need to save bandwidth


Note Do not use RTP header compression on links greater than 2 Mbps.


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

Enable RTP header compression on a serial interface.

Change the number of header compression connections.

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.

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:

Lightweight registration

Improved gateway selection process

Gateway resource availability reporting

Support for single proxy configurations

Tunneling of redirecting number information element

H.245 tunneling

Hookflash relay

H.235 security

Codec negotiation

H.245 empty capabilities set

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:

Trunk

Line

Dual tone multifrequency (DTMF)

Generic media

Real-Time Transport Protocol (RTP)

Announcement server

Script

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:

Alternative dial plan for VoIP environments—MGCP enables centralized call control in VoIP networks.

Configuration requirements removed for static VoIP network dial peers—When MGCP is used as the call agent in a VoIP environment, configuring of static VoIP network dial peers is not required, so the configuration is simplified. The MGCP call agent provides functions similar to those of VoIP network dial peers.


Note POTS dial peer configuration is still required.


Migration paths—Systems using earlier versions of the protocol can migrate easily to MGCP.

Gateway Types

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

Residential Gateway—A residential gateway (RGW) provides an interface between analog (RJ-11) calls from a telephone and the VoIP network. RGW functionality supports analog plain old telephone service (POTS) calls for both SGCP and MGCP.

Trunking Gateway—A trunking gateway (TGW) provides an interface between trunks on the public switched telephone network (PSTN) and a VoIP network. A trunk can be a DS0, T1, or E1 line.

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:

Multicast routing

A multicast routing protocol; for example, Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP)

An IP routing protocol; for example, Routing Information Protocol (RIP) or Open Shortest Path First (OSPF)

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.

Depending on the type of gateway (TGW or RGW) that you want to configure, perform one of the following tasks:

Configuring a TGW

Configuring an RGW


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


You must also complete the following task:

Configuring a System Card to Use MGCP with Cisco CallManager

In addition, you may want to perform any of the following optional tasks:

Configuring Download of MGCP Voice Gateway Configuration Information from Cisco CallManager

Configuring MGCP T1 CAS

Configuring ISDN Signaling Backhaul

Blocking New Calls and Gracefully Terminating Existing Calls

Configuring Fax over MGCP

Fax Relay

Fax Pass-Through

Enabling Multicast Music-on-Hold


Note Before configuring MGCP, you need to have previously run the ICSConfig initial configuration program on the Cisco ICS 7750, you need to have configured IP routing, and you need to have configured the voice ports on the MRP or ASI card. For information about ICSConfig, refer to the Cisco ICS 7750 Getting Started Guide. For information about configuring IP routing and voice ports on the MRP and ASI cards, refer to the Cisco ICS 7750 Software Configuration Guide.


Configuring a TGW

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

 
Command
Purpose

Step 1 

Router(config)# mgcp

Initiates the MGCP application.

Step 2 

Router(config)# mgcp 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)# mgcp 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)# mgcp 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)# mgcp 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)# mgcp 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)# mgcp 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)# mgcp 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-manager MGCP

Enables support for Cisco CallManager within MGCP.

Step 2 

MRP(config)# ccm-manager 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-manager 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

Fax Pass-Through


Note In order to successfully transmit faxes between a Cisco ICS 7750 and another voice gateway, both the Cisco ICS 7750 and the other voice gateway must be configured to use the same mode. Configuring multiple modes on a single MRP or different modes on different MRPs or other routers in the network can cause fax calls to fail.If, for example, the Cisco ICS 7750 is configured to use both fax relay and fax pass-through modes, and the other voice gateway is configured to use fax relay only, the two gateways will be unable to transmit faxes to each other.


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 Implementing Fax Over IP on Cisco Voice Gateways 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.

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:

With the chassis backplane, the SSP acts as a communications path for intrachassis communications among the installed cards in the Cisco ICS 7750.

When connected to an external Ethernet switch, the SSP forwards voice and data traffic between the IP network and the external network (such as the WAN and the Public Switched Telephone Network [PSTN]) through the Cisco ICS 7750.


Note The Cisco ICS 7750 supports only one SSP, which is always installed in slot 7 of the chassis. For a complete description of the SSP, refer to the Cisco ICS 7750 System Description.


Features

The SSP provides the following features:

10/100 autonegotiation on each port

Duplex autonegotiation on each port

Broadcast storm control for preventing faulty end stations from degrading overall system performance

Port monitoring (Switch Port Analyzer) for complete traffic monitoring

Cisco Discovery Protocol (CDP) for network topology discovery and mapping between the SSP and other Cisco devices in the network

Cisco Group Management Protocol (CGMP) for limiting multicast flooding within the SSP

Spanning Tree Protocol (STP) IEEE 802.1d with STP Port Fast Mode for network loop detection and disabling and for fault-tolerant connectivity

Support for the following enhanced STP features:

STP support on a per VLAN basis

STP UpLinkFast feature to accelerate the reconfiguration of STP

STP Root Guard feature to prevent switches outside the core of the network from becoming the STP root

Protected port option for restricting the forwarding of traffic to designated ports on the same switch

Two queues on each port to prioritize voice and data traffic, based on IEEE 802.1p class of service (CoS)

Telephony features, such as Voice VLAN (VVID), on a per-port basis

Terminal Access Controller Access Control System Plus (TACACS+) feature to manage network security through a server

Network Time Protocol (NTP) to provide an external source for time-of-day information

Hot-swap support for removing and installing the SSP without having to power down the system


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


SSP Configuration Tasks

In the default configuration, the SSP is network-ready. In most network configurations, the SSP will not require any additional configuration. However, many settings on the SSP are configurable. Table 6-28 lists tasks that you may need or want to perform in order to configure the SSP. In addition, Table 6-28 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-28 SSP Configuration Tasks 

Task
Documentation Location

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+


SSP VLAN Configuration

If you have configured VLAN functionality on the Cisco ICS 7750, you must configure the internal ports on the SSP (Fast Ethernet 0/3 through Fast Ethernet 0/8), depending on the type of system card installed in the chassis slot. When configuring the SSP for VLAN support, follow these guidelines:

The internal port of the SSP that connects to the Flash-based MRP that is a member of all VLANs must be configured as "trunking native vlan 1."

For example, if an MRP300 is installed in slot 1, the configuration on the SSP would look as follows:

Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#int fastEthernet 0/3
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport trunk native vlan 1

All other system cards that are members of the management VLAN only, must be installed in slots that are configured as "static access vlan 1."

For example, if an SPE300 is installed in slot 2, the configuration on the SSP would look as follows:

Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#int fastEthernet 0/4
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 1

At least one of the external ports of the SSP that connect to the external switches must have the switchport configured as a dot1q trunk to enable exchange of the 802.1p/q header between the switches.

For example, if the first external port of the SSP were to be configured as a dot1q trunk, the configuration on the SSP would look as follows:

Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#int fastEthernet 0/1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport trunk native vlan 1

The management VLAN on SSP must be VLAN 1 (the default) in order for the SPE to be able to access it. This configuration on the SSP is as follows:

Switch(config)#interface VLAN 1
Switch(config-subif)#management

The components outside the ICS 7750 chassis (such as the Catalyst 3524XL switches, IP phones, and PCs) should be configured as described in the component documentation. For more information, see the following documents:

Cisco IOS Desktop Switching Software Configuration Guide

Catalyst 2900 XL and Catalyst 3500 XL Software Configuration Guide

Cisco IP Phone Administration Guide for Cisco CallManager, Release 3.2 or Later


Note Other VLAN configurations, such as "static access vlan x" where x is a value other than 1, "trunk native vlan x" where x is a value other than 1, "multi-vlan," "dynamic vlan," and "ISL trunk" are not supported on the SSP.


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

Setting Up Packet Filters


Note For additional information about how to use IOS commands related to security, refer to the Cisco ICS 7750 Software Configuration Guide.


Setting Up a Firewall

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

Figure 6-17 Typical Firewall Architecture

In the architecture shown in Figure 6-17, 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-18. 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-18 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:

Deny specific types of packets and accept all others.

Accept specific types of packets and deny all others.

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

Access Control List Examples

Applying Access Control Lists to Interfaces

Using Access Control Lists to Filter Incoming Traffic

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-18, 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-18):

Loading a new ACL—Before loading a new ACL, remove any previous definition of this ACL by using the following command:

no access-list 101 

Denying unauthorized external traffic—You can deny traffic from a user attempting to "spoof" any of your internal addresses from the outside world (see the "Using Access Control Lists to Filter Incoming Traffic" section.):

access-list 101 deny ip B.B.0.0 0.0.255.255 0.0.0.0 
255.255.255.255 

Allowing DNS and NTP traffic—You can permit Domain Name System (DNS) and Network Time Protocol (NTP) requests and replies:

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 

Denying NFS access—You can deny access to the Network File Server (NFS) via the User Datagram Protocol (UDP) port:

access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 
255.255.255.255 eq 2049 

Telnet access—The following command permits Telnet access to the communication server (B.B.13.2):

access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.2 
0.0.0.0 eq 23 

FTP access—The following commands permit FTP access to the host on subnet  13:

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 

Limiting TCP and UDP connections—If network B.B.1.0 is on the internal network, you can permit TCP and UDP connections for port numbers greater than 1023 to a very limited set of hosts:

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-19 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-19 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

TFTP Server Configuration

Cisco CallManager Configuration

Cisco CallManager Server Configuration

Cisco CallManager Music-on-Hold Audio Source Configuration

Cisco CallManager Configuration Checklist

Backing Up Cisco CallManager

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

Cisco CallManager Configuration

Cisco CallManager Server Configuration

Cisco CallManager Music-on-Hold Audio Source Configuration

TFTP Server Configuration

The TFTP server IP address must be configured by using ICSConfig. The TFTP server IP address configured with 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 Configuration—IP 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:

The Cisco CallManager System Guide, which describes the Cisco CallManager system and its components, configuration checklists and links to associated administration procedures

The Cisco CallManager Serviceability Administration Guide, which tells how to configure alarms, traces, and other reporting for Cisco CallManager serviceability and remote serviceability

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

Refer to the "Cisco CallManager Group Configuration" section.

Refer to the "Date/Time Group Configuration" section.

Refer to the "Device Defaults Configuration" section.

Refer to the "Region Configuration" section.

Refer to the "Device Pool Configuration" section.

 

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.

Refer to the "Media Resource Group Configuration" section.

Refer to the "Media Resource Group List Configuration" section.

Refer to the "Music On Hold Configuration" section.

 

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.

Refer to the "Partitions and Calling Search Spaces" section.

Refer to the "Route Filter Configuration" section.

Refer to the "Route Group Configuration" section.

Refer to the "Route List Configuration" section.

Refer to the "Route Pattern Configuration" section.

 

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.

Refer to the "Call Park Configuration" section.

Refer to the "Call Pickup and Group Call Pickup Configuration" section

Refer to the "Cisco IP Phone Services Configuration" section.

Refer to Installing Cisco Customer Response Applications on the Cisco ICS 7750 and Release Notes for Cisco Customer Response Applications 2.2(2) on the Cisco ICS 7750.

 

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:

Installing Cisco Unity Voice Mail on the Cisco ICS 7750

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

Release Notes for Cisco Unity Voice Mail Release 3.0(1) for the Cisco ICS 7750

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

Upgrading from Cisco Unity Voice Mail Release 3.0(1) to Release 3.1(2x) on the Cisco ICS 7750

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

Installing and Configuring Cisco Unity Voice Messaging

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

Cisco CallManager 3.1 Integration Guide

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

Cisco Unity System Administration Guide, Release 3.0(1)

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 using a direct serial connection.

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

Configuring Cisco CallManager

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

Creating a Route List in Cisco CallManager

Configuring a Route Pattern in Cisco CallManager

Configuring the Cisco Messaging Interface in Cisco CallManager

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:

BaudRate—CMI connects to the voice-mail system through an EIA/TIA-232 (serial) connection. This parameter defines that connection (default: 9600).


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


CallManagerName—This parameter specifies the name of the Cisco CallManager server that will be used as the CMI primary. Enter the IP address of the target SPE310. If you are configuring the CMI secondary, enter the IP address of an additional SPE310 that is running Cisco CallManager.

DataBits—This parameter defines one of the values used to configure the serial connection. The recommended setting is 7.

Parity—This parameter defines one of the values used to configure the serial connection. The default is Even.


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.


SerialPort—This parameter defines one of the values used to configure the serial connection. The default is COM1. Enter the SAP port that you are using for voice-mail (COM1 or COM2). If your Cisco ICS 7750 is equipped with a UPS, which should be connected to COM1, voice-mail usually will be connected to COM2.

StopBits—This parameter defines one of the values used to configure the serial connection. The default is 1.

VoiceMailDN—The voice-mail directory number (DN). Enter the number that you assigned to the analog access ports that are connected to the voice-mail system.


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.



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:

LAN Management Solution (LMS)

Routed WAN Management Solution

Service Management Solution (SMS)

Several advanced applications are also available:

CiscoWorks2000 Device Fault Manager (DFM)—provides real-time, detailed fault analysis for Cisco devices.

User Registration Tool (URT)—actively identifies users with the network and creates user policy bindings for policy registration, mobility, and tracking.

CiscoWorks2000 Voice Manager (CVM)—is a web-based voice management and reporting tool provides enhanced capabilities to configure and provision voice ports, and create and modify dial plans on voice-enabled Cisco routers for Voice over IP (VoIP), Voice over Frame Relay (VoFR), and Voice over ATM (VoATM) networks.

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:

HP OpenView Network Node Manager

Computer Associates Unicenter

Tivoli NetView

Aprisma Spectrum

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