Configuring Digital T1 Packet Voice Trunk Network Modules on Cisco 2600 and 3600 Series Routers

This document describes how to configure digital T1 packet voice trunk network modules on Cisco 2600 and 3600 routers and includes the following sections:

• Feature Overview, page 1
• Supported Platforms, page 10
• Supported Standards, MIBs, and RFCs, page 10
• Prerequisites, page 11
• Configuration Tasks, page 12
• Monitoring and Maintaining T1 Digital Packet Voice Configuration, page 25
• Configuration Examples, page 33
• Command Reference, page 44
• Glossary, page 66

Feature Overview

Digital T1 packet voice trunk network modules for Cisco 2600 and 3600 series routers allow enterprises or service providers, using the equipped routers as customer premises equipment, to deploy digital voice and fax relay. These modules receive constant bit-rate telephony information over T1 interfaces and can convert that information to a compressed format, so that it can be transmitted as voice over IP.

Cisco IOS software configuration allows you to set up a variety of applications. Here are a few examples:

• Compressed voice over WANs
• Routing of dialed variable-length digits collected from the public switched telephone network or PBX for VoIP calls
• Support for FRF.12 fragmentation and queuing in a VoIP over Frame-Relay network
• Setup of private-line auto-ringdown (PLAR) to allow a station or DS0 to go off hook and have the call completed without dialing (especially applicable to off-premises extensions)
• Transparent trunk connections among routers
• Drop and Insert of T1 channels on a T1 trunk to allow some PBX channels to be directed to the PSTN while others are used for compressed VoIP
  
  For more information about these applications, see “Configuration Examples” on page 33.
  
  T1 digital voice over IP includes the following functionality:
• T1 Channel Associated Signaling (CAS) for the following line-signaling types:
  
  — rEceive and transMit or Ear and Mouth (E&M) immediate start
  
  — E&M wink start
  
  — E&M delay start (also called “dial repeating”)
  
  — Foreign Exchange Station (FXS) and Foreign Exchange Office (FXO) loop start
  
  — FXS and FXO ground start
• Dynamic bandwidth allocation using voice activity detection (VAD)
• Drop-and-Insert capability, allowing the interchange of time-division multiplexing (TDM) slots between the ports on a two-port T1 multiflex trunk voice/WAN interface card installed in a digital T1 packet voice trunk network module
• Support for a wide range of International Telecommunication Union (ITU-T) G-series compression specifications, including:
  
  — G.711 A Law at 64,000 bps
  
  — G.711 u Law at 64,000 bps
  
  — G.723.1 Annex A at 5,300 bps
  
  — G.723.1 Annex A at 6,300 bps
  
  — G.723.1 at 5,300 bps
  
  — G.723.1 at 6,300 bps
  
  — G.726 at 16,000 bps
  
  — G.726 at 24,000 bps
  
  — G.726 at 32,000 bps
  
  — G.728 at 16,000 bps
  
  — G.729 at 8,000 bps
  
  — G.729 Annex A at 8,000 bps
  
  — G.729 Annex B at 8,000 bps
  
  — G.729 Annex B with Annex A at 8,000 bps
• Depending on codec complexity, either 30 or 60 channels of compressed voice
• High-quality voice endpoint-standard features, such as high-quality echo cancellation, silence suppression, comfort noise generation, and DTMF relay
• Group 3 fax relay
• Support for the following framing formats and line coding:
  
  — Super Frame (SF)
  
  — Extended Super Frame (ESF)
  
  — Alternate mark inversion (AMI) line coding
  
  — Binary 8-zero substitution (B8ZS) line coding

Benefits

Digital T1 packet voice trunk network modules allow Cisco 2600 and 3600 series routers to provide T1 connectivity to PBXs or to a central office (CO). With digital T1 connectivity, Cisco 2600 and 3600 series routers can provide greater voice density for enterprise and service provider VoIP networks than they could before. A digital T1 packet voice trunk network module is a complete solution, made up of a network module with installed packet voice data modules (PVDMs), and one T1 multiflex trunk voice/WAN interface card with either one or two T1 ports.

VoIP: T1 Timing, Signaling, Framing, and Line Encoding

With the introduction of the digital T1 packet voice trunk network modules for the Cisco 2600 and 3600 series routers, you must set timing, signaling, framing, and line encoding. The digital T1 packet voice trunk network modules can connect to either a PBX (or similar telephony device) or to a Central Office (CO) in order provide PSTN connectivity.

The differences that set T1 digital configuration apart from analog configuration are as follows:

• Timing. Analog interfaces do not require specific timing configuration. Digital T1 interfaces require not only that you set timing but that you consider the source of the timers.
• Framing. Analog interfaces do not require specific framing configuration. Digital T1 interfaces require that you configure either SuperFrame (SF or D4 framing) or Extended SuperFrame (ESF) framing. Set the framing format to match that of the PBX or CO that connects to the digital T1 packet voice trunk network module.
• Line Encoding. Analog interfaces do not require that specific line encoding be configured. Digital T1 require that you configure either AMI (alternative mark inversion) or B8ZS (bipolar 8- zero substitution). Set the line encoding to match that of the PBX or CO that connects to the digital T1 packet voice trunk network module.

Timing

This section describes the five basic timing scenarios that can occur when a digital T1 packet voice trunk network module is connected to a PBX, CO, or both. In all of the examples below, the PSTN (or Central Office) and the PBX are interchangeable for the purposes of providing or receiving clocking.

The digital T1 module has an on-board PLL (Phase-Lock Loop) chip that can either provide a clock source to both T1s or receive clocking that can drive the second T1. All timing commands are T1 controller configuration commands.

Single T1 Port Provides Clocking
In this scenario, the digital T1 module is the clock source for the connected device. The PLL generates the clock internally and drives the clocking on the T1 line.

Figure 1 Single T1 Port Providing Clock

The following configuration sets up this clocking method:

controller T1 1/0
framing esf
linecoding b8zs
clock source internal
ds0-group 1 timeslots 1-24 type e&m-wink

Note Generally this method is useful only when connecting to a PBX, key system or channel bank. A Cisco VoIP Gateway rarely provides clocking to the CO, because CO clocking provides a higher Stratum level.

Single T1 Port Receiving Clock from the Line
In this scenario, the digital T1 module receives clocking from the connected device (CO or PBX). The PLL clocking is driven by the clock reference on the receive (Rx) side of the T1 connection.

Figure 2 Single T1 Receiving Clock from Line

The following configuration sets up this clocking method:

controller T1 1/0
framing esf
linecoding b8zs
clock source line
ds0-group 1 timeslots 1-24 type e&m-wink

Dual T1s, Both Receive Clocking from the Line
In this scenario, the digital T1 has two reference clocks, one from the PBX and another from the CO. Since the PLL can only derive clocking from one source, this case is more complex than the two preceding examples.

Before looking at the details, consider two important concepts that underlay the clocking method:

• Looped-Time Clocking. The T1 port takes the clock received on its Rx (receive) pair and regenerates it on its Tx (transmit) pair. While the port receives clocking, the port is not driving the PLL on the card but is “spoofing” the T1 so that the connected device has a viable clock and does not see slips. PBXs are not designed to accept slips on a T1 line and such slips cause a PBX to drop the link into failure mode. While in looped-time mode, the router often sees slips, but because these are controlled slips, they usually do not force failures of the router’s T1 port.
• Slips. These messages indicate that the T1 port is receiving clock information that is out of phase, that is, out of synch. Because the router has only a single PLL, it can experience controlled slips while it receives clocking from two different time sources. The router can usually handle controlled slips because its single PLL architecture anticipates them.

Note Physical layer issues, such as bad cabling or faulty clocking references, can also cause slips. Eliminate these slips by addressing the physical layer or clock reference problems.

Figure 3 Dual T1s Receiving Line Clocking

In this scenario, the PLL derives clocking from the CO and puts the T1 port connected to the PBX into looped-time mode. This is usually the best method because the CO provides an excellent clock source (and usually requires that it provide that source) and a PBX usually must receive clocking from the other T1.

The following configuration sets up this clocking method:

controller T1 1/0 < < description - connected to the CO
framing esf
linecoding b8zs
clock source line primary
ds0-group 1 timeslots 1-24 type e&m-wink
!
controller T1 1/1 < < description - connected to the PBX
framing esf
linecoding b8zs
clock source line
ds0-group 1 timeslots 1-24 type e&m-wink
The clock source line primary command tells the router to use this T1 port to drive the PLL. All other T1 ports configured as clock source line are then put into an implicit loop-timed mode. If the primary T1 port fails or goes down, the other T1 instead receives the clock that drives the PLL. In this configuration, T1 1/1 may see controlled slips, but these should not force it down. This method prevents the PBX from seeing slips.

Dual T1s, One Receives Clocking and One Provides Clocking
In this scenario, the digital T1 module receives clocking for the PLL from T1 0 and uses this clock as a reference to clock T1 1. If T1 0 fails, the PLL internally generates the clock reference to drive T1 1.

Figure 4 Dual T1s, One Receiving and One Providing Clocking

The following configuration sets up this clocking method:

controller T1 1/0
framing esf
linecoding b8zs
clock source line
ds0-group 1 timeslots 1-24 type e&m-wink
!
controller T1 1/1
framing esf
linecoding b8zs
clock source internal
ds0-group 1 timeslots 1-24 type e&m-wink

Dual T1s, Both Clocks from Router
In this scenario, the router is “Master of the Timing Universe,” generating the clock for the PLL and therefore for both T1s.

Figure 5 Dual T1s, Both Clocks from Router

The following configuration sets up this clocking method:

controller T1 1/0
framing esf
linecoding b8sz
clock source internal
ds0-group 1 timeslots 1-24 type e&m-wink
!
controller T1 1/1
framing esf
linecoding b8zs
clock source internal
ds0-group 1 timeslots 1-24 type e&m-wink

Signaling

There are three types of signaling that you should consider for digital T1:

• Channel-Associated Signaling (CAS). CAS signaling means that instead of having a specific time slot (such as an ISDN D channel in PRI) designated to provide signaling only, signaling bits (on-hook and off-hook) are within the sixth, twelfth, eighteenth and twenty-fourth frames of each time slot. CAS signaling is often called robbed-bit signaling (RBS) because it takes bits from bearer channels and uses them for signaling. CAS signaling must be specified on both ends of the T1 link and is enabled by default on digital T1 packet voice trunk network modules.
  

  ---

  Note Digital T1 packet voice trunk network modules support T1 CAS at this time, but later plans are to support E1, Primary Rate Interface (PRI), R2, and Common-Channel (CCS) signaling. The digital T1 module can support E&M wink-start, immediate-start, and delay-start signaling, as well as FXS and FXO ground-start and loop-start signaling.

  ---

• E&M Signaling. E&M connections can use one of three different signaling types to acknowledge on-hook and off-hook states: wink-start, immediate-start and delay-start. E&M wink-start is usually preferred because it provides better Answer Supervision (knowledge that the connected device is ready to answer the call). However, not all COs and PBXs can handle wink-start signaling. The E&M connection between the router and switch (CO or PBX) must use matching E&M signaling types or calls are not be connected properly. E&M signaling is defined with the ds0-group controller configuration command, as in the following example:
  
  controller T1 1/0
  ds0-group 1 timeslots 1-24 type e&m-wink-start
  

  ---

  Note Currently, wink-start signaling provides only the functionality of Feature-Group B and not that of Feature-Group D, which will be supported in later releases.

  ---

• FXO and FXS Signaling. While most digital T1 connections used for switch-to-switch (or switch-to-router) trunks are E&M connections, a digital T1 module can also support FXS and FXO connections, which people normally use to provide emulated-OPX (Off-Premise eXtensions) from a PBX to remote stations. As a general rule, FXO ports connect to FXS ports. Either ground-start or loop-start signaling is appropriate for these connections. Ground-start provides better Disconnect Supervision to detect when a remote user has hung up the phone, but ground-start is not available on all PBXs. The FXO or FXS connection between the router and switch (CO or PBX) must use matching signaling or calls are not be connected properly. FXS and FXO signaling are defined with the ds0-group controller configuration command, as in the following example:
  
  controller T1 1/0
  ds0-group 1 timeslots 1-24 type fxo-ground-start
  or
  controller T1 1/0
  ds0-group 1 timeslots 1-24 type fxs-loop-start
  

  ---

  Note While some switches (CO or PBX) can specify both an inbound and outbound signaling method, Cisco VoIP gateway routers can only specify one signaling type for both inbound and outbound calls. The switch inbound and outbound signaling types must match, or calls may only work in one direction.

  ---

Framing

Digital T1 packet voice trunk network modules support two types of framing for T1 CAS: ESF (Extended SuperFrame) and SF (SuperFrame), also called D4 framing. The framing type of the router and switch (CO or PBX) must match. The framing controller configuration command defines T1 framing, as in the following example:

controller T1 1/0
framing esf

or
controller T1 1/0
framing sf

Line Encoding

Digital T1 packet voice trunk network modules support two types of framing for T1 CAS: B8ZS (bipolar-8 zero substitution) and AMI (alternate mark inversion). The line encoding of the router and switch (CO or PBX) must match. The linecoding controller configuration command defines T1 framing, as in the following example:

controller T1 1/0
linecoding b8zs

or
controller T1 1/0
linecoding ami

Verifying Configuration

Use the show controller privileged EXEC command to verify the proper digital T1 configuration:

router# show controller T1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is short 133
Description: Digital T1 WIC
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary.
Data in current interval (2 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Restrictions

The following restrictions apply to digital T1 packet voice trunk network module configuration:

• Group 4 fax is not supported.
• The high-density voice network module has one slot for a voice/WAN interface card (VWIC); VWICs supply one or two ports. Only the dual-mode (voice/WAN) multiflex trunk cards are supported in the digital T1 packet voice trunk network module, not older VICs. For more information, see the “Prerequisites” section on page 11.
• Drop-and-Insert capability is supported only between two ports on the same multiflex card.
• Voice over Frame Relay is not supported.
• Wink-start signaling Feature-Group D is not supported.
• Common-channel signaling (CCS) and Primary Rate Interface (PRI) are not supported.
• R2 signaling is not supported.
• Voice over ATM—including AAL5 encapsulation, circuit emulation service (CES), and AAL2—is not supported for VoATM.
• Digital T1 voice is not manageable through Simple Network Management Protocol (SNMP) using existing versions of Cisco Voice Manager. Release 2.0 of Cisco Voice Manager is planned to support the feature.

Related Features and Technologies

VoIP Quality of Service

This section explains the quality issues that you should consider when building Voice over IP (VoIP) networks and offers a few tips about configuring VoIP with the appropriate Quality of Service (QoS):

• Delay. Delay is the time it takes for VoIP packets to travel between two endpoints and you should design networks to minimize this delay. However, because of the speed of network links and the processing power of intermediate devices, some delay is expected. The human ear normally accepts up to about 150 milliseconds (ms) of delay without noticing problems (the ITU's G.114 standard recommends no more than 150 ms of one-way delay). Once delay exceeds 150 ms, a conversation becomes more and more like a walkie-talkie interchange, where one person must wait for the other to stop speaking before beginning to talk. This type of delay is often evident on international long-distance calls. You can measure delay fairly easily by using ping tests at various times of the day with different network traffic loads. If network delay is excessive, reduce it before deploying VoIP networks.
• Jitter. While delay can cause unnatural starting and stopping of conversations, variable-length delays (also known as jitter) can cause a conversation to break and become unintelligible. Jitter is not usually a problem with public switched telephone network (PSTN) calls, because the bandwidth of calls is fixed. However, in VoIP networks where existing data traffic might be bursty, jitter can become an issue. Cisco voice gateways have built-in de-jitter buffering to compensate for a certain amount of jitter, but if jitter is constant on a network, identify the source and control it before deploying a VoIP network.
• Serialization. Serialization is a term that describes what happens when a router attempts to send both voice and data packets out of an interface. In general, voice packets are very small (80 to 256 bytes), while data packets can be very large (1,500 to 18,000 bytes). On relatively slow links, such as WAN connections, large data packets can take a long time to transmit onto the wire. When these large packets are mixed with smaller voice packets, the excessive transmission time can lead to both delay and jitter. You can use fragmentation to reduce the size of the data packets so that the delay and jitter also decrease.
• Bandwidth Consumption. Traditional voice conversations consume 64 Kb of network bandwidth. When this voice traffic is run though a VoIP network, it can be compressed and digitized by digital signal processors (DSPs) built into the routers. This compression can reduce the calls to sizes as small as 5.3 Kb for voice samples. Once the packets go onto the IP network, the appropriate IP/UDP/RTP headers must be added, and this can add a significant amount of bandwidth to each call (about 40 bytes per packet). Technologies such as RTP header compression, however, can reduce the IP header overhead to about 2 bytes. In addition, VAD (voice activity detection) does not send any packets unless there is active speech.

Supported Platforms

This feature is supported on the following platforms:

• Cisco 2610
• Cisco 2611
• Cisco 2612
• Cisco 2613
• Cisco 2620
• Cisco 2621
• Cisco 3620
• Cisco 3640
• Cisco 3661
• Cisco 3662

Supported Standards, MIBs, and RFCs

RFCs

• RFC 1890
• RFC 1889
  
  MIBs
• CISCO-ENTITY-VENDORTYPE-OID-MIB
• OLD-CISCO-CHASSIS-MIB
• CAS_INTF_MIB
  
  International Telecommunication Union (ITU-T) G-Series Codec Compression Specifications
• G.711 A Law at 64,000 bps
• G.711 u Law at 64,000 bps
• G.723.1 Annex A at 5,300 bps
• G.723.1 Annex A at 6,300 bps
• G.723.1 at 5,300 bps
• G.723.1 at 6,300 bps
• G.726 at 16,000 bps
• G.726 at 24,000 bps
• G.726 at 32,000 bps
• G.728 at 16,000 bps
• G.729 at 8,000 bps
• G.729 Annex A at 8,000 bps
• G.729 Annex B at 8,000 bps
• G.729 Annex B with Annex A at 8,000 bps

Prerequisites

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

• Obtain T1 service from your service provider or PBX.
• Install Cisco IOS Software Release 12.0(5)XK, 12.0(7)T or a later release. The minimum DRAM memory requirements to support digital T1 packet voice trunk network modules are as follows:
  
  — 32 Mb with one or two T1s
  
  — 48 Mb with three or four T1s
  
  — 64 Mb with five to ten T1s — 128 Mb with more than ten T1s
  
  The memory required may be greater than listed above for high-volume applications.
  
  Support for digital T1 packet voice trunk network modules is included in Plus feature sets. The IP Plus feature set requires 8 Mb of flash memory; other Plus feature sets require 16 Mb.
• Install one of the following high-density T1 network modules in the router chassis:
  
  — Single-Port 24 Channel T1 High-Density Voice Network Module (NM-HDV-1T1-24)
  
  — Single-Port Enhanced 24 Channel T1 High-Density Voice Network Module (NM-HDV-1T1-24E)
  
  — Dual-Port 48 Channel High-Density Voice Network Module (NM-HDV-2T1-48)
  

  ---

  Note You can install one module in a Cisco 2600 series router or a Cisco 3620 router. A Cisco 3640 router can support three modules, and you can install as many as six modules in a Cisco 3660 router.

  ---

• Install at least one packet voice data module (PVDM-12) in the high-density digital T1 network module if it is not already equipped. The digital T1 packet voice trunk network module contains five 72-pin SIMM sockets or banks, numbered 0 through 4, for PVDMs. Each socket can be filled with a single 72-pin PVDM. A digital T1 packet voice trunk network module can support the following numbers of channels:
  
  — When the digital T1 packet voice trunk network module is configured for high-complexity codec mode, up to six voice or fax calls can be completed per PVDM-12, using the following codecs: G.711, G.726, G.729, G.729 Annex B, G.723.1, G.723.1 Annex A, G.728, and fax relay.
  
  — When the digital T1 packet voice trunk network module is configured for medium-complexity codec mode, up to twelve voice or fax calls can be completed per PVDM-12, using the following codecs: G.711, G.726, G.729 Annex A, G.729 Annex B with Annex A, and fax relay.
  

  ---

  Note Each PVDM holds three digital signal processors (DSPs). With five PVDM slots populated, a total of 15 DSPs are provided. High-complexity codecs support two simultaneous calls on each DSP, while medium-complexity codecs support four calls on each DSP.

  ---

• Install at least one dual-mode voice/WAN interface card (VWIC) for a voice connection if a VWIC was not included with the network module. You can install one VWIC (providing one or two line interfaces) in the digital T1 packet voice trunk network module. Only the one- and two-port T1 multiflex trunk interface cards (VWIC-1MFT-T1, VWIC-2MFT-T1,
  VWIC-2MFT-T1-DI) are supported with channel-associated signaling (CAS).
  
  For Drop-and-Insert capability, you must install a two-port Drop-and-Insert T1 multiflex trunk voice/WAN interface card (VWIC-2MFT-T1-DI). To install a VWIC in a network module, see Cisco WAN Interface Cards Hardware Installation Guide.
• Install at least one other network module orWAN interface card to provide the connection to the IP LAN or WAN.
• Establish a working IP network. For more information about configuring IP, see “IP Overview,” “Configuring IP Addressing,” and “Configuring IP Services” chapters in the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1.
• Complete your company’s dial plan.
• Establish a working telephony network based on your company's dial plan.
  
  Voice, Video, and Home Applications Configuration Guide and Voice, Video, and Home Applications Command Reference for Cisco IOS Release 12.0 provide information about setting up voice networks.

Configuration Tasks

Perform the following tasks to configure a digital T1 packet voice trunk network module:

• Set up voice cards and T1 controllers.
• Configure serial and LAN interfaces.
• Set up voice ports.
• Configure voice dial peers.

Configuring Voice Card and T1 Controller Settings

The following steps specify codec settings for voice cards and set up T1 controllers for clocking and other T1 parameters, as well as for DS0 groups that define the channels for compressed voice and TDM groups for Drop-and-Insert capability.

Verifying Voice Card and Controller Settings

To verify the configuration of voice card and controller settings, follow these steps:

Configuring Serial Interfaces

The way you set up serial and LAN interfaces depends on your application. To configure VoIP, you must at least set up IP addresses for serial interfaces. When a user dials enough digits to match a configured destination pattern, the telephone number is mapped to an IP host through the dial plan mapper. The IP host has a direct connection to either the destination telephone number or a PBX that completes the call to the configured destination pattern.

This document does not explain all possible serial interface configuration options, nor does it show LAN interface configuration. For complete information, see the Cisco IOS Release 12.0 Cisco IOS Interface Configuration Guide and the Cisco IOS Interface Command Reference.

The “Configuration Examples” section on page 33 shows a sample configuration that sets up VoIP over Frame Relay. For more information about setting up voice networks, see Voice, Video, and Home Applications Configuration Guide for Cisco IOS Release 12.0.

Note For information about monitoring serial interfaces in order to trigger a busyout condition on a voice port when an interface is down, see “Configuring Voice Ports” on page 20.

Verifying Serial Interface Configuration

To verify serial interface configuration, enter the privileged EXEC command showinterfaces serial, which displays the status of all serial interfaces or of a specific serial interface, as shown in the following example. You can use this command to check the encapsulation, IP addressing, and other settings:

Router #show interface serial0/0:0
Serial0/0:0 is up, line protocol is up
Hardware is QUICC Serial
Internet address is 1.156.1.1/24
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive not set
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
637 packets input, 64736 bytes, 0 no buffer
Received 181 broadcasts, 0 runts, 5 giants, 0 throttles
3617 input errors, 1506 CRC, 1646 frame, 0 overrun, 0 ignored, 0 abort
682 packets output, 67213 bytes, 0 underruns
0 output errors, 0 collisions, 1070 interface resets
0 output buffer failures, 0 output buffers swapped out
13 carrier transitions
Timeslot(s) Used:1-24, Transmitter delay is 0 flags

Configuring Voice Ports

Follow these steps to set up voice ports to support the local and remote stations. Not all possible commands are shown here. To learn more, see Voice, Video, and Home Applications Configuration Guide and Voice, Video, and Home Applications Command Reference for Cisco IOS Release 12.0.

Verifying Voice Ports

Follow the procedure below to verify voice-port configuration. To learn more about these commands, see Voice, Video, and Home Applications Command Reference for Cisco IOS Release 12.0.

Important command output is shown in bold.

To verify the voice-port configuration, enter the privileged EXEC show voice port slot/port:ds0-group command. The following sample output from the command shows explanatory information after the “<<“ characters:

cisco-router# show voice port 1/0:1

receEive and transMit Slot is 1, Sub-unit is 0, Port is 1 << voice-port 1/0:1

Type of VoicePort is E&M
Operation State is DORMANT
Administrative State is UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Music On Hold Threshold is Set to -38 dBm
In Gain is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 8 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Region Tone is set for US

Configuring Voice Dial Peers

Follow these steps to set up voice dial peers to support the local and remote stations. Not all possible commands are shown here. To learn more, see Voice, Video, and Home Applications Configuration Guide and Voice, Video, and Home Applications Command Reference for Cisco IOS Release 12.0.

Verifying Voice Dial Peers

Follow the procedure below to verify dial-peer configuration. To learn more about these commands, see Voice, Video, and Home Applications Command Reference for Cisco IOS Release 12.0.

Important command output is shown in bold.

Enter the privileged EXEC show dial-peer voice command. The following text is sample output
from the command for a POTS dial peer:

router# show dial-peer voice 1
VoiceEncapPeer1
tag = 1, dest-pat = \Q+14085551000',
answer-address = \Q',
group = 0, Admin state is up, Operation state is down
Permission is Both,
type = pots, prefix = \Q',
session-target = \Q', voice-port =
Connect Time = 0, Charged Units = 0
Successful Calls = 0, Failed Calls = 0
Accepted Calls = 0, Refused Calls = 0
Last Disconnect Cause is "10"
Last Disconnect Text is ""
Last Setup Time = 0

The following text is sample output from the show dial-peer voice command for a VoIP dial peer: Router# show dial-peer voice 10

VoiceOverIpPeer10
tag = 10, dest-pat = \Q',
incall-number = \Q+14087',
group = 0, Admin state is up, Operation state is down
Permission is Answer,
type = voip, session-target = \Q',
sess-proto = cisco, req-qos = bestEffort,
acc-qos = bestEffort,
fax-rate = voice, codec = g729r8,
Expect factor = 10,Icpif = 30, VAD = disabled, Poor QOV Trap = disabled,
Connect Time = 0, Charged Units = 0
Successful Calls = 0, Failed Calls = 0
Accepted Calls = 0, Refused Calls = 0
Last Disconnect Cause is "10"
Last Disconnect Text is ""
Last Setup Time = 0

Monitoring and Maintaining T1 Digital Packet Voice Configuration

This section presents some useful show and debugging commands for understanding, maintaining, and troubleshooting your configuration.

The balance of this section shows the output of the commands listed in Table 1.

Show Commands

This section illustrates some of the privileged EXEC show commands that are useful for analyzing your system. Note that important information appears in bold, and bold text preceded by the “<<“ characters explains the process.

The show dialplan number command provides information about the dial peer associated with a specified dial-plan number. Notice that the dial peer is operational and that IP Precedence has been configured to the preferred setting of 5.

The show call active voice command displays information about a current call:

cisco-router# show call active voice

GENERIC:
SetupTime=94523746 ms
Index=448
PeerAddress=##73072
PeerSubAddress=
PeerId=70000
PeerIfIndex=37
LogicalIfIndex=0
ConnectTime=94524043
DisconectTime=94546241
CallOrigin=1
ChargedUnits=0
InfoType=2
TransmitPackets=6251
TransmitBytes=125020
ReceivePackets=3300
ReceiveBytes=66000
VOIP:
ConnectionId[0x142E62FB 0x5C6705AF 0x0 0x385722B0]
RemoteIPAddress=171.68.235.18
RemoteUDPPort=16580
RoundTripDelay=29 ms
SelectedQoS=best-effort
tx_DtmfRelay=inband-voice
SessionProtocol=cisco
SessionTarget=ipv4:171.68.235.18
OnTimeRvPlayout=63690
GapFillWithSilence=0 ms
GapFillWithPrediction=180 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms
HiWaterPlayoutDelay=70 ms
LoWaterPlayoutDelay=30 ms
ReceiveDelay=40 ms
LostPackets=0 ms
EarlyPackets=1 ms
LatePackets=18 ms
VAD = disabled
CoderTypeRate=g729r8
CodecBytes=20
cvVoIPCallHistoryIcpif=0
SignalingType=cas

The show call history voice command shows statistics about previous calls:

sb1pbx-voip# show call history voice

GENERIC:
SetupTime=94893250 ms
Index=450
PeerAddress=##52258
PeerSubAddress=
PeerId=50000
PeerIfIndex=35
LogicalIfIndex=0
DisconnectCause=10
DisconnectText=normal call clearing.
ConnectTime=94893780
DisconectTime=95015500
CallOrigin=1
ChargedUnits=0
InfoType=2
TransmitPackets=32258
TransmitBytes=645160
ReceivePackets=20061
ReceiveBytes=401220
VOIP:
ConnectionId[0x142E62FB 0x5C6705B3 0x0 0x388F851C]
RemoteIPAddress=171.68.235.18
RemoteUDPPort=16552
RoundTripDelay=23 ms
SelectedQoS=best-effort
tx_DtmfRelay=inband-voice
SessionProtocol=cisco
SessionTarget=ipv4:171.68.235.18
OnTimeRvPlayout=398000
GapFillWithSilence=0 ms
GapFillWithPrediction=1440 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms
HiWaterPlayoutDelay=97 ms
LoWaterPlayoutDelay=30 ms
ReceiveDelay=49 ms
LostPackets=1 ms
EarlyPackets=1 ms
LatePackets=132 ms
VAD = disabled
CoderTypeRate=g729r8
CodecBytes=20
cvVoIPCallHistoryIcpif=0
SignalingType=cas

Debug Commands

This section illustrates some of the EXEC mode debug commands that are useful when analyzing and troubleshooting your system. Note that important information appears in bold, and bold text preceded by the “<<“ characters explains the process.

The debug vpm all command displays information that allows you to troubleshoot T1 signaling:

cisco-router# debug vpm all
Apr 19 19:18:54 PDT: htsp_process_event: [1/0/16, 1.4 , 34]
em_onhook_offhookem_offhookem_onhookhtsp_setup_ind << port goes offhook
Apr 19 19:18:54 PDT: htsp_process_event: [1/0/16, 1.5 , 8]
Apr 19 19:19:01 PDT: htsp_process_event: [1/0/16, 1.5 , 10] htsp_alert_notify
Apr 19 19:19:01 PDT: htsp_process_event: [1/0/16, 1.5 , 11]
Apr 19 19:19:02 PDT: htsp_process_event: [1/0/16, 1.5 , 11]
Apr 19 19:19:15 PDT: htsp_process_event: [1/0/16, 1.5 , 22]
em_offhook_onhookem_stop_timers em_onhook << port goes onhook
Apr 19 19:19:15 PDT: htsp_process_event: [1/0/16, 1.4 , 7] em_onhook_releaseem_onhook

The debug vtsp all command displays information that allows you to troubleshoot digits received and sent on a call:

cisco-router# debug vtsp all
Apr 19 19:21:55 PDT: dsp_cp_tone_on: [1/0:1 (9502)] packet_len=30 channel_id=1
packet_id=72 tone_id=3 n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=4000
amp_of_second=4000 direction=1 on_time_first=65535 off_time_first=0
on_time_second=65535 off_time_second=0 << providing dialtone

Apr 19 19:21:59 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN:
digit=2,rtp_timestamp=0xF2D37240
act_report_digit_begin
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: digit=2,
duration=102act_report_digit_end
Apr 19 19:22:00 PDT: dsp_cp_tone_off: [1/0:1 (9502)] packet_len=8 channel_id=1
packet_id=71
Apr 19 19:22:00 PDT: vtsp_timer: 34838705
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN:
digit=3,rtp_timestamp=0xF2D37240
act_report_digit_begin
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: digit=3,
duration=92act_report_digit_end
Apr 19 19:22:00 PDT: dsp_cp_tone_off: [1/0:1 (9502)] packet_len=8 channel_id=1
packet_id=71
Apr 19 19:22:00 PDT: vtsp_timer: 34838724
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN:
digit=1,rtp_timestamp=0xF2D37240 act_report_digit_begin
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: digit=1,
duration=92act_report_digit_end
Apr 19 19:22:00 PDT: dsp_cp_tone_off: [1/0:1 (9502)] packet_len=8 channel_id=1
packet_id=71
Apr 19 19:22:00 PDT: vtsp_timer: 34838744
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN:
digit=9,rtp_timestamp=0xF2D37240
act_report_digit_begin
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: digit=9,
duration=102act_report_digit_end
Apr 19 19:22:00 PDT: dsp_cp_tone_off: [1/0:1 (9502)] packet_len=8 channel_id=1
packet_id=71
Apr 19 19:22:00 PDT: vtsp_timer: 34838768
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN:
digit=8,rtp_timestamp=0xF2D37218
act_report_digit_begin
Apr 19 19:22:00 PDT: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: digit=8,
duration=107act_report_digit_end

*** The Caller dialed the digits 23198 ***

The debug voip ccapi inout EXEC command traces the execution path through the call control API, which serves as the interface between the call-session application and the underlying network-specific software.

During the capabilities exchange shown in the command output, both sides agree on what compression to use, and the debug voip ccapi inout output helps you determine what each side is negotiating.

You can use the output from this command to understand how calls are being handled by the router. This command shows how a call flows through the system. By using this debug level, you can see the call setup and teardown operations performed on both the telephony and network call legs:

cisco-router# debug voip ccapi inout
Apr 19 19:23:11 PDT: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(9504), disp(0) << a
new call is originating
Apr 19 19:23:11 PDT: ccCallSetContext (callID=0x2520, context=0x61C0806C)
Apr 19 19:23:11 PDT: ccCallSetupAck (callID=0x2520)
Apr 19 19:23:11 PDT: ccGenerateTone (callID=0x2520 tone=8) << dialtone
Apr 19 19:23:18 PDT: cc_api_call_digit_begin (vdbPtr=0x61A1B1B4, callID=0x2520,
digit=2, flags=0x1, timestamp=0xCE2796D1, expiration=0x0) << digit 2 received
Apr 19 19:23:18 PDT: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: ssaIgnore cid(9504), st(0),oldst(0), ev(10)
Apr 19 19:23:18 PDT: cc_api_call_digit (vdbPtr=0x61A1B1B4, callID=0x2520, digit=2,
duration=102)
Apr 19 19:23:18 PDT: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: cc_api_call_digit_begin (vdbPtr=0x61A1B1B4, callID=0x2520,
digit=3, flags=0x1, timestamp=0xCE2796D1, expiration=0x0)
Apr 19 19:23:18 PDT: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: ssaIgnore cid(9504), st(0),oldst(0), ev(10)
Apr 19 19:23:18 PDT: cc_api_call_digit (vdbPtr=0x61A1B1B4, callID=0x2520, digit=3,
duration=102) << digit 3 received
Apr 19 19:23:18 PDT: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: cc_api_call_digit_begin (vdbPtr=0x61A1B1B4, callID=0x2520,
digit=1, flags=0x1, timestamp=0xCE2796D1, expiration=0x0)
Apr 19 19:23:18 PDT: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: ssaIgnore cid(9504), st(0),oldst(0), ev(10)
Apr 19 19:23:18 PDT: cc_api_call_digit (vdbPtr=0x61A1B1B4, callID=0x2520, digit=1,
duration=92) << digit 1 received
Apr 19 19:23:18 PDT: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: cc_api_call_digit_begin (vdbPtr=0x61A1B1B4, callID=0x2520,
digit=9, flags=0x1, timestamp=0xCE2796B9, expiration=0x0)
Apr 19 19:23:18 PDT: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: ssaIgnore cid(9504), st(0),oldst(0), ev(10)
Apr 19 19:23:18 PDT: cc_api_call_digit (vdbPtr=0x61A1B1B4, callID=0x2520, digit=9,
duration=105) << digit 9 received
Apr 19 19:23:18 PDT: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: cc_api_call_digit_begin (vdbPtr=0x61A1B1B4, callID=0x2520,
digit=8, flags=0x1, timestamp=0xCE279691, expiration=0x0)
Apr 19 19:23:18 PDT: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: ssaIgnore cid(9504), st(0),oldst(0), ev(10)
Apr 19 19:23:18 PDT: cc_api_call_digit (vdbPtr=0x61A1B1B4, callID=0x2520, digit=8,
duration=100) << digit 8 received
Apr 19 19:23:18 PDT: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(9504), disp(0)
Apr 19 19:23:18 PDT: ssa: cid(9504)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
Apr 19 19:23:18 PDT: ssaSetupPeer cid(9504) peer list: tag(20000)
Apr 19 19:23:18 PDT: ssaSetupPeer cid(9504), destPat(23198), matched(1), prefix(),
peer(61C04464) << matched dial-peer 20000 voip
Apr 19 19:23:18 PDT: peer_tag=20000 << matched dial-peer voip 20000
Apr 19 19:23:18 PDT: ccIFCallSetupRequest: (vdbPtr=0x61A25524, dest=, callParams
<< voip call setup
={called=23198, calling=+9.......T, fdest=0, voice_peer_tag=20000}, mode=0x0)
Apr 19 19:23:18 PDT: ccCallSetContext (callID=0x2521, context=0x61C12E18)
Apr 19 19:23:18 PDT: ccCallProceeding (callID=0x2520, prog_ind=0x0)
Apr 19 19:23:19 PDT: cc_api_call_alert(vdbPtr=0x61A25524, callID=0x2521, prog_ind=0x88,
sig_ind=0x1)
Apr 19 19:23:19 PDT: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(9505), disp(0)
Apr 19 19:23:19 PDT: ssa:
cid(9505)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)-cid2(9504)st2(1)oldst2(0)
Apr 19 19:23:19 PDT: ccCallAlert (callID=0x2520, prog_ind=0x88, sig_ind=0x1)
Apr 19 19:23:19 PDT: ccConferenceCreate (confID=0x61A21670, callID1=0x2520,
callID2=0x2521, tag=0x0)
Apr 19 19:23:19 PDT: cc_api_bridge_done (confID=0x33, srcIF=0x61A25524,
srcCallID=0x2521, dstCallID=0x2520, disposition=0, tag=0x0)
Apr 19 19:23:19 PDT: cc_api_bridge_done (confID=0x33, srcIF=0x61A1B1B4,
srcCallID=0x2520, dstCallID=0x2521, disposition=0, tag=0x0)
Apr 19 19:23:19 PDT: cc_api_caps_ind (dstVdbPtr=0x61A25524, dstCallId=0x2521, sr
<< negotiating capabilities with the remote VoIP gateway
Apr 19 19:23:36 PDT: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(9505), disp(0)
Apr 19 19:23:36 PDT: ssa:
cid(9505)st(4)oldst(1)cfid(51)csize(0)in(0)fDest(0)-cid2(9504)st2(4)oldst2(4)
<< the VoIP call is connected
Apr 19 19:23:54 PDT: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(9505),disp(0)
<< the VoIP call is disconnected
Apr 19 19:23:54 PDT: ccCallDisconnect (callID=0x2520, cause=0x10 tag=0x0)
<< the VoIP call is disconnected by cause_code 0x10

Table 2 explains the codec negotiation values that appear—in hexadecimal format— during the capabilities exchange portion of the command output.

Reference Information

The information in this section helps you interpret the output from debug and show commands.

Table 3 shows Q.931 call disconnection causes. In the examples that follow, the disconnects are caused by normal call clearing.

These are codec capabilities bits that can appear in command output:

• CC_CAP_CODEC_G711U 0x1
• CC_CAP_CODEC_G711A 0x2
• CC_CAP_CODEC_G723ar63 0x2000
• CC_CAP_CODEC_G723ar53 0x4000
• CC_CAP_CODEC_G723r63 0x100
• CC_CAP_CODEC_G723r53 0x200
• CC_CAP_CODEC_G726r16 0x10
• CC_CAP_CODEC_G729 0x4
• CC_CAP_CODEC_G729 0x8000
• CC_CAP_CODEC_G729a 0x8
• CC_CAP_CODEC_G729b 0x800
• CC_CAP_CODEC_G729ab 0x1000

These are fax capabilities bits that can appear in command output. The numbers following “FAX_” refer to the fax speed (for example, “144” means 14,400 bps):

• CC_CAP_FAX_NONE 0x1
• CC_CAP_FAX_VOICE 0x2
• CC_CAP_FAX_144 0x4
• CC_CAP_FAX_96 0x8
• CC_CAP_FAX_72 0x10
• CC_CAP_FAX_48 0x20
• CC_CAP_FAX_24 0x40
• CC_CAP_FAX_120 0x80
  
  These are the VAD on and off capability bits:



• CC_CAP_VAD_OFF 0x1
• CC_CAP_VAD_ON 0x2

Configuration Examples

This section includes the following configuration examples:

• Routed Digits. Shows how to set up a router to collect digits from the PBX/PSTN or from a phone and route the VoIP call based on the digits received.
• FRF.12. Shows how to configure a Cisco 2600 or 3600 router to support FRF.12 fragmentation and queuing in a VoIP over Frame-Relay network.
• Gatekeeper. Shows how to configure a Cisco 2600 or 3600 series router to route VoIP calls by using an H.323 Gatekeeper.
• Private-Line Auto-Ringdown (PLAR). Shows how to set up a Cisco 2600 or 2600 series router for PLAR.
• Trunk Connection. Shows how to configure a Cisco 2600 or 3600 router for a transparent trunk connection.
• Variable-Length Digits. Shows how to configure a Cisco 2600 or 3600 router to collect variable-length strings of digits PBX/PSTN or phone and route the VoIP call based on the digits received.
• Drop and Insert. Shows how to configure a Cisco 2600 or 3600 router with a 2-port Drop-and-Insert T1 multiflex trunk voice/WAN interface card (VWIC-2MFT-T1-DI) and a digital T1 packet voice network module so that individual DS0 channels are transparently passed between T1 ports without going through a DSP. For example, this allows the directing of some PBX channels to the PSTN for long-distance service, while other channels are compressed for VoIP calls between interoffice sites.

These examples are not necessarily complete configurations. They are designed to illustrate specific tips and techniques, and only the relevant portions of the configurations are shown. Each configuration includes a brief introduction, side-by-side configurations for routers at either end, and explanations of key points.

Routed Digits - Switched VoIP Calls

Figure 6 Sample Configuration: Routed Digits

This example shows how to set up a Cisco 2600 or 3600 router to collect digits from either a PBX/PSTN or a phone and route a VoIP call based on the digits received. The commands used in the configurations are explained inline. Only relevant sections of the configuration are shown. The example assumes that the IP portion of the network is already in place.

In this configuration, the PBX seizes the T1 to the router, which expects to collect digits from the PBX. Upon collecting those digits, the router tries to match a dial peer to route the call. If the router receives the correct digits, it routes the call according to the configuration of the dial peer.

Here are some key points for consideration:

• The codec complexity high command tells the router what types of codecs that can be used on this voice card—either high or medium. High-complexity permits only two calls for each DSP (6 for each PVDM-12). The codecs supported under high complexity are G.711, G.726, G.729, G.729 Annex B, G.728, G.723.1, G.723.1 Annex A, and fax relay. The default is medium complexity, which allows G.711, G.726, G.729 Annex A, G.729 Annex A with Annex B, and fax relay. Medium-complexity codecs permit four calls for each DSP—a total of twelve for each PVDM-12. All T1 cards in a router must have the same complexity. To change the codec complexity, first remove any configured DS0 group from the T1 controller and then reapply them after the change is complete.
• The ds0-group 1 timeslots 1-24 type e&m-wink command performs the following functions:
  
  — Defines the T1 channels for compressed voice calls.
  
  — Defines the signaling method that the router uses to connect to the PBX or PSTN.
  
  — Automatically creates a voice-port 1/0:1. The numbering for this voice-port is
  
  slot/port:ds0-group no. In this configuration, all calls to “4....” or “5....” are routed to any DS0 timeslot, although only 1/0:1 is shown. To map individual DS0s, define additional DS0 groups under the T1 controller. This creates individual DS0 voice ports.
• The dial-peer voice commands define the dialing plan within the router. They specify both the remote phone numbers (voip or vofr) and the locally connected phone numbers (pots). The digits in the destination pattern can either be complete numbers or partial numbers with wildcard digits, represented by “.”. Each “.” represents an individual digit for collection.

FRF.12 - Switched VoIP Calls

Figure 7 Sample Configuration: FRF.12 Switched VoIP Calls

This example shows how to configure a Cisco 2600 or 3600 router to support FRF.12 fragmentation and queuing in a voice over IP over Frame-Relay network. FRF.12 is a Frame Relay Forum standard mechanism for fragmenting data packets. This fragmentation helps eliminate the delays that occur when transmitting voice and data over the same network—large data packets can delay smaller voice packets from being transmitted into the IP network. FRF.12 is also supported on the MC3810 and 7200 routers, which can be used as tandem-nodes for VoIP networks.

• The frame-relay traffic-shaping command enables Frame-Relay traffic-shaping (FRTS) on the main interface. Enable it if FRTS will be used on subinterfaces.
• The class cisco_frf12 command tells the interface to use the parameters for FRTS defined in the map-class called “cisco_frf12.”
• The map-class cisco_frf12 grouping of commands defines the rules for FRTS. If per-interface/subinterface parameters must differ, define multiple map-classes per router.
• The frame-relay fragment 80 command defines the size of the data or voice packets that FRF.12 fragments. Set the size to about the size of the voice packets or slightly larger. A good rule of thumb is 80 bytes for each DS0 ofWAN bandwidth.With large quantities of bandwidth and small data frames, the fragment size may need to remain small.
• The frame-relay fair-queue command enables Weighted-Fair Queuing (WFQ) on a per-PVC basis to ensure that voice traffic gets priority over data traffic.

Routing Calls through an H.323 Gatekeeper

Figure 8 Sample Configuration: Routing Calls through an H.323 Gatekeeper

Note With the introduction of Cisco IOS Release 12.0(5)T and subsequent releases, Cisco VoIP gateways support H.323v2 (H.323 Version 2), which is backwards-compatible with systems running H.323v1. However, H.323 Version 2 features do not interoperate with H.323 Version 1 features in Cisco IOS releases prior to 11.3(9)NA or 12.0(3)T. Earlier Cisco IOS versions contain H.323 Version 1 software that does not support protocol messages with an H.323 Version 2 protocol identifier. All systems must be running either Cisco IOS version 11.3(9)NA and later or releases Cisco IOS version 12.0(3)T and later releases to interoperate with H.323 Version 2. Gateway Resource Availability Indication (RAI) messages are currently not supported on the Cisco 2600 and 3600 series. (These are messages that are sent to the Gatekeeper to inform it about the status of a Gateway’s DSP or DS0 availability.)

The example in this section shows how to configure a Cisco 2600 or 3600 series router to route VoIP calls through an H.323 Gatekeeper. This setup shows calls being routed from a Gateway in Zone-Alpha, through the Gatekeeper, to a Gateway in Zone-Beta.

For complete documentation of H.323 gatekeeper functionality, refer to the IOS documentation on CCO at these URLs:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios
120/120newft/120t/120t3/mcmtcfg. htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios
120/120newft/120t/120t3/mcmtcmd .htm

Here are some key points for consideration:

• The session target ras command tells the router to route through the Gatekeeper. RAS (Registration, Admission, Status) is the communication that occurs between an H.323 Gateway and the Gatekeeper.
• The gateway command tells the router to use RAS to register with the Gatekeeper.
• The gatekeeper command tells the router to act as a Gatekeeper and respond to calls made through RAS from H.323 Gateways and H.323 clients.

Private-Line Auto-Ringdown Configuration - Switched VoIP Calls

Figure 9 Sample Configuration: PLAR

This example shows how to set up a Cisco 2600 or 3600 series router for a private-line auto-ringdown (PLAR). PLAR is used to allow a station or DS0 to go off hook, and—without the user dialing digits—have a call completed to the far end. PLAR can also provide dial tone from a remote PBX for off-premises applications.

In this configuration, the phones off router Beta go off hook and receive dial tone from the PBX connected to router Alpha. From there, users can dial any digits in to the PBX as if their stations are directly connected to it.

Here are some key points for consideration:

• The configuration includes the dtmf-relay command because the users will send DTMF digits to the PBX over the VoIP network, and the router must not compress these digits. The command ensures that the router sends the digits out-of-band, so that they are not distorted.
• The connection plar command configures the PLAR connection. The router uses the digits that follow the command internally to send the call to a dial peer—the user does not dial these digits.
• voice-port 1/0:2 is created by DS0 group 2, as shown in the last digit of the specification. Each DS0 group creates a separate voice port, which allows the definition of individual DS0s on the digital T1 card.

Connection Trunk Configuration - Permanent VoIP Calls

Figure 10 Sample Configuration: Connection Trunk Permanent VoIP Calls

This example shows how to configure a Cisco 2600 or 3600 router for a trunk connection. A trunk connection is like a “wire” between the two routers. It is a transparent connection, so it allows features such as hookflash (also called switchhook flash) or hoot ‘n’ holler (point-to-point) to pass. This type of trunk configuration can also be used for OPXs (Off-Premise Extensions) that require rollover to a centralized voice mail system when the user does not answer.

A trunk connection can only be used between E&M ports or with FXO-to-FXS connections.

In this configuration, a permanent and transparent path is set up between individual DS0s on each router. It passes dial tone from the remote PBX and passes DTMF digits out of band.

The connection trunk command establishes the permanent trunk connection between the routers. The digits after the command are passed internally within the router to match a dial-peer so that the call can be set up.

Drop-and-Insert Sample Configuration

Figure 11 Sample Configuration: Drop and Insert

Drop-and-Insert technology is one way to integrate old PBX technologies with VoIP. It allows you to take 64Kb DS0 channels from one T1 and digitally cross-connect them to 64Kb DS0 channels on another T1. Drop and Insert is sometimes called TDM Cross-Connect.

Drop and Insert allows individual 64Kb DS0 channels to be transparently passed, uncompressed, between T1 ports without passing through a DSP. Using this method, the channel traffic is sent between a PBX and Central Office switch (PSTN) or other telephony device, allowing the use, for example, of some PBX channels for long-distance service through the PSTN while the router compresses others for interoffice VoIP calls. In addition, Drop and Insert can cross-connect a telephony switch (from the CO or PSTN) to a channel bank to provide external analog connectivity.

Note the following design requirements:

• On the 2600, 3620, and 3640 platforms, Drop and Insert is only permitted between T1 ports on the same multiflex trunk module (MFT). The MFT module can either be in a standalone WIC slot or integrated into a digital T1 packet voice trunk network module VWIC slot.
• When the MFT module is installed in the VWIC slot of a digital T1 packet voice trunk network module, it does not allow the T1 ports to provideWAN connectivity (for example. Frame-Relay, PPP, and so on) in addition to voice and Drop and Insert.
• WAN and Drop-and-Insert capabilities are supported when the MFT is in a standalone WIC slot.

Here are some key points for consideration:

• The tdm-group 2 timeslots 13-24 type e&m command defines Drop and Insert by setting up the timeslots from each T1 that will be used in the digital cross-connect. The type keyword is optional, but its use is specific to the Drop and Insert feature.
  
  — If you include the type keyword with a signaling type, the Drop-and-Insert cross-connect ensures that the specified signaling (on-hook and off-hook) is passed between the DS0s. It also uses the signaling bits to signal busy-out if one of the T1s goes down.
  
  — If you do not use the type keyword, the Drop-and-Insert cross-connect is clear-channel and does not interpret any signaling.
• The connect tdm1 T1 1/0 2 T1 1/1 3 command activates the Drop-and-Insert digital cross-connect between the T1s. The tdm1 portion of the command is just a name for the cross-connect, and the name can be any word, number, or series of letters.
• You can verify Drop-and-Insert connections by using the show connect command.

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.

• busyout monitor interface
• codec (dial-peer)
• codec complexity
• connect
• ds0-group
• echo-cancel coverage
• loopback (T1 controller)
• loopback (T1 controller)
• show voice port
• voice-card

busyout monitor interface

To place a voice port into busyout monitor state, enter the busyout-monitor interface voice-port configuration command. To remove the busyout monitor state on the voice port, use the no form of this command.

busyout-monitor interface interface number
no busyout-monitor interface interface number

Syntax Description

interface    The name of the associated interface or subinterface that will be monitored to trigger a voice-port busyout, for example serial, atm, or ethernet.

number     The slot and port position of the interface or subinterface, for example, 0/1, 1/1.0, and so on.

Default

The voice port is not in busyout monitor state.

Command Mode

Voice-port configuration

Command History

Release         Modification
12.0(3)T     This command was introduced for the Cisco MC3810.
12.0(5)XK and 12.0(7)T  The command was modified for the Cisco 2600 and 3600 series.

Usage Guidelines

When you place a voice port in busyout monitor state, the voice port monitors the specified interface and enters the busyout state when the interface is down. This forces rerouting of calls when an interface is down.

If you specify more than one monitored interface for a voice port, all the monitored interfaces must be down in order to trigger busyout on the voice port.

The command monitors only the up or down status of an interface—not end-to-end TCP/IP connectivity.

When an interface is operational, a busied-out voice port returns to its normal state. This feature can monitor LAN, WAN, and virtual interfaces, as well as subinterfaces.

Example

The following example configures the voice port to monitor two serial interfaces and an Ethernet interface. When all these interfaces are down, the voice port is busied out. When at least one interface is operating, the voice port is put back into a normal state. voice-port 3/0:0

busyout monitor interface Ethernet0/0
busyout monitor interface Serial1/0
busyout monitor interface Serial2/0

codec (dial-peer)

To specify the voice coder rate of speech for a VoIP dial peer, enter the codec dial-peer configuration command. Use the no form of this command to restore the default value.

codec {g711alaw | g711ulaw | g723ar53 | g723ar63 | g723r53 | g723r63 | g726r16 | g726r24 | g726r32 | g728 | g729r8 [pre-ietf] | g729br8 } [bytes]

no codec

Syntax Description

Default

The default is g729r8.

Command Mode

Dial-peer configuration

Command History

Usage Guidelines

This command applies only to VoIP dial peers.

A specific codec type can be configured on the dial-peer as long as it is supported by the setting used with the codec complexity voice-card configuration command.

The dial-peer configuration command is particularly useful when you must change to a small-bandwidth codec. Large-bandwidth codecs, such as G.711, do not fit in a small-bandwidth link. However, g711alaw and g711ulaw provide higher-quality voice transmission than other codecs. g729r8, which provides near-toll quality with considerable bandwidth savings.

If codec values for the VoIP peers of a connection do not match, the call fails.

You can change the payload of each VoIP frame by using the byte setting. However, increasing the payload size can add processing delay for each voice packet.

Example

The following example configures a dial peer to use the g723r53 (G.723.1 at 5,300 bps) codec type:

dial-peer voice 1 voip
codec g723r53

Related Commands

codec complexity

Based on the codec standard you are using, enter the codec complexity voice-card configuration command to specify call density and codec complexity. High-complexity codecs support lower call density than do medium-complexity codecs. The no form of the command resets the voice card to the default.

codec complexity {high | medium}

no codec complexity

Syntax Description

high      High-complexity codecs support the following services: G.711, G.726, G.729, G.729 Annex B, G.723.1, G.723.1 Annex A, G.728, and fax relay.

medium      Medium-complexity codecs support the following services: G.711, G.726, G.729 Annex A, G.729 Annex B with Annex A, and fax rela

Default

The default is medium.

Command Mode

Voice-card configuration

Command History

Usage Guidelines

Codec complexity refers to the amount of processing required in order to perform compression. Codec complexity affects the number of calls that can take place on a voice card’s digital signal processors (DSPs), referred to as call density. The greater the codec complexity, the fewer calls are handled. For example, G.711 requires less DSP processing than G.728, so that as long as the bandwidth is available, more calls can be handled simultaneously by using the G.711 standard than using G.728.

All voice cards in a router must use the same codec complexity. The voice-card codec complexity setting affects the options available for the codec dial-peer configuration command. To change codec complexity, you must first remove any configured CAS or DS0 groups, then reinstate them after the change.

Example

The following example configures a voice card for high-complexity codecs:

voice-card 1
codec complexity high

Related Command

connect

To define connections between T1 or E1 controller ports for Drop and Insert (also called TDM Cross-Connect), enter the connect global configuration command.

connect id {t1 | e1} slot/port-1 tdm-group-no-1 {t1 | e1} slot/port-2 tdm-group-no-2

no connect id {t1 | e1} slot/port-1 tdm-group-no-1 {t1 | e1} slot/port-2 tdm-group-no-2

Syntax Description

Default

There is no Drop-and-Insert connection between the ports.

Command Mode

Global configuration

Command History

Usage Guidelines

The connect command creates a named connect between two TDM groups associated with Drop-and-Insert ports on T1 or E1 interfaces where the user has already defined the groups by using the tdm-group command.

Example

The following example shows how two T1 TDM groups are set up and then connected:

Router(config)# controller T1 1/0
Router(config-controller)tdm-group 2 timeslots 13-24 type e&m
Router(config-controller)# controller T1 1/1
Router(config-controller)tdm-group 3 timeslots 13-24 type e&m
Router(config-controller)exit
Router(config)connect tdm1 T1 1/0 2 T1 1/1 3

Related Command

ds0-group

To define T1 channels for compressed voice calls and the channel-associated signaling (CAS) method by which the router connects to the PBX or PSTN, enter the ds0-group controller configuration command. The no form of the command removes the group and signaling setting.

ds0-group ds0-group-no timeslots timeslot-list type {e&m-immediate | e&m-delay | e&m-wink | fxs-ground-start | fxs-loop-start | fxo-ground-start | fxo-loop-start}

no ds0-group ds0-group-no

Syntax Description

Default

There is no DS0 group.

Command Mode

Controller configuration

Command History

Usage Guidelines

The ds0-group command automatically creates a logical voice port that is numbered as follows on Cisco 2600 and 3600 series routers: slot/port:ds0-group-no. Although only one voice port is created for each group, applicable calls are routed to any channel in the group.

Example

The following example configures ranges of T1 controller timeslots for FXS ground-start and FXO loop-start signaling:

controller T1 1/0
framing esf
linecode b8zs
ds0-group 1 timeslot 1-10 type fxs-ground-start
ds0-group 2 timeslot 11-24 type fxo-loop-start