Chapter 3: Routing Calls over Analog Voice Ports

Cisco Press

1 2 3 4 5 6 7 8 Page 5
Page 5 of 8

Example 3-3  E&M Voice Port Configuration

Router(config)#voice-port 1/1/1Router(config-voiceport)#signal wink-startRouter(config-voiceport)#operation 2-wireRouter(config-voiceport)#type 1 Router(config-voiceport)#no shutdownRouter(config-voiceport)#exitRouter(config)#dial-peer voice 10 potsRouter(config-dialpeer)#destination-pattern 1...Router(config-dialpeer)#direct-inward-dialRouter(config-dialpeer)#forward-digits all Router(config-dialpeer)#port 1/1/1


Trunks are used to interconnect gateways or PBX systems to other gateways, PBX systems, or the PSTN. A trunk is a single physical or logical interface that contains several physical interfaces and connects to a single destination. This could be a single FXO port that provides a single line connection between a Cisco gateway and a FXS port of small PBX system, a POTS device, or several T1 interfaces with 24 lines each in a Cisco gateway providing PSTN lines to several hundred subscribers.

Trunk ports can be analog or digital and use a variety of signaling protocols. Signaling can be done using either the voice channel (in-band) or an extra dedicated channel (out-of-band). The available features depend on the signaling protocol in use between the devices.

Figure 3-18 illustrates a variety of possible trunk connections.

Figure 3-18

E&M Trunks

Consider the following characteristics of the trunks depicted in Figure 3-18:

  • If a subscriber at the London site places a call to the PSTN, the gateway uses one voice channel of the E1 R2 trunk interface.

  • If a subscriber of the legacy PBX system at the Chicago site needs to place a call to a subscriber with an IP phone connected to the Chicago gateway, the call will go via the E&M trunk between the legacy PBX and the gateway.

  • The Denver and the Chicago sites are connected to San Jose via Q Signaling (QSIG) to build up a common private numbering plan between those sites. Because Denver’s Cisco IP telephony rollout has not started yet, the QSIG trunk is established directly between San Jose’s gateway and Denver’s legacy PBX.

Analog Trunks

Because many organizations continue to use analog devices, a requirement to integrate analog circuits with VoIP or IP telephony networks still exists. To implement a Cisco voice gateway into an analog trunk environment, the FXS, FXO, DID, and E&M interfaces are commonly used, as illustrated in Figure 3-19.

Figure 3-19

Analog Trunks

PSTN carriers typically offer analog trunk features that can be supported on home phones. Table 3-5 presents a description of the common analog trunk features.

Table 3-5  Analog Trunk Features



Caller ID

Caller ID allows users to see the calling number before answering the phone.

Message waiting

Two methods activate an analog message indicator:

  • High-DC voltage message-waiting indicator (MWI) light and frequency-shift keying (FSK) messaging.

  • Stuttered dial tone for phones without a visual indicator.

Call waiting

When a user is on a call and a new call comes in, the user hears an audible tone and can “click over” to the new caller.

Caller ID on call waiting

When a user is on a call, the name of the second caller is announced or the caller ID is shown.


This feature includes both blind and supervised transfers using the standard established by Bellcore laboratories. The flash hook method is common with analog trunks.


Conference calls are initiated from an analog phone using flash hook or feature access codes.

Speed dial

A user can set up keys for commonly dialed numbers and dial these numbers directly from an analog phone.

Call forward all

Calls can be forwarded to a number within the dial plan.


A simple last-number redial can be activated from analog phones.


Supported on E&M and FXS DID ports.

Figure 3-20 shows small business voice networks connected through a gateway to the PSTN. The voice network supports both analog phones and IP phones. The connection to the PSTN is through an FXO port, and the analog phone is connected to the small business network through an FXS port. The issue in this scenario is how the caller ID is passed to call destinations.

Figure 3-20

Analog Trunks - Example

This example describes two calls; the first call is to an on-premises destination, and the second call is to an off-premises destination:

  • Call 1: Call 1 is from the analog phone to another phone on the premises. The FXS port is configured with a station ID name and station ID number. The name is John Smith, and the number is 555-0212. When a call is placed from the analog phone to another phone on the premises, an IP phone in this case, the caller name and number are displayed on the screen of the IP phone.

  • Call 2: Call 2 is placed from the same analog phone, but the destination is off the premises on the PSTN. The FXO port forwards the station-ID name and station-ID number to the CO switch. The CO switch discards the station ID name and station ID number and replaces them with information it has configured for this connection.

For inbound calls, the caller ID feature is supported on the FXO port in the gateway. If the gateway is configured for H.323, the caller ID is displayed on the IP phones and on the analog phones (if supported).

Note - Although the gateway supports the caller ID feature, Cisco Unified Communications Manager does not support this feature on FXO ports if the gateway is configured for Media Gateway Control Protocol (MGCP).

Centralized Automated Message Accounting

A Centralized Automated Message Accounting (CAMA) trunk is a special analog trunk type originally developed for long-distance billing but now mainly used for emergency call services (911 and E911 services). You can use CAMA ports to connect to a Public Safety Answering Point (PSAP) for emergency calls. A CAMA trunk can send only outbound automatic number identification (ANI) information, which is required by the local public safety answering point (PSAP).

CAMA interface cards and software configurations are targeted at corporate enterprise networks and at service providers and carriers who are creating new or supplementing existing networks with Enhanced 911 (E911) services. CAMA carries both calling and called numbers by using in-band signaling. This method of carrying identifying information enables the telephone system to send a station identification number to the PSAP via multifrequency (MF) signaling through the telephone company E911 equipment. CAMA trunks are currently used in 80 percent of E911 networks. The calling number is needed at the PSAP for two reasons:

  • The calling number is used to reference the Automatic Location Identification (ALI) database to find the exact location of the caller and any extra information about the caller that might have been stored in the database.

  • The calling number is used as a callback number in case the call is disconnected. A number of U.S. states have initiated legislation that requires enterprises to connect directly to the E911 network. The U.S. Federal Communications Commission (FCC) has announced model legislation that extends this requirement to all U.S. states. Enterprises in areas where the PSTN accepts 911 calls on ISDN trunks can use existing Cisco ISDN voice-gateway products because the calling number is an inherent part of ISDN.

Note - You must check local legal requirements when using CAMA.

Calls to emergency services are routed based on the calling number, not the called number. The calling number is checked against a database of emergency service providers that cross-references the service providers for the caller location. When this information is determined, the call is then routed to the proper PSAP, which dispatches services to the caller location.

During the setup of an E911 call, before the audio channel is connected, the calling number is transmitted to each switching point, known as a selective router, via CAMA.

The VIC2-2FXO and VIC2-4FXO cards support CAMA via software configuration. CAMA support is also available for the Cisco 2800 Series and 3800 Series ISRs. It is common for E911 service providers to require CAMA interfaces to their network.

Figure 3-21 shows a site that has a T1 PRI circuit for normal inbound and outbound PSTN calls. Because the local PSAP requires a dedicated CAMA trunk for emergency (911) calls, all emergency calls are routed using a dial peer pointing to the CAMA trunk.

Figure 3-21

Configuring a CAMA Trunk

The voice port 1/1/1 is the CAMA trunk. The actual configuration depends on the PSAP requirements. In this case, the digit 1 is used to signal the area code 312. The voice port is then configured for CAMA signaling using the signal cama command. Five options exist:

  • KP-0-NXX-XXXX-ST: 7-digit ANI transmission. The Numbering Plan Area (NPA), or area code, is implied by the trunk group and is not transmitted.

  • KP-0-NPA-NXX-XXXX-ST: 10-digit transmission. The E.164 number is fully transmitted.

  • KP-0-NPA-NXX-XXXX-ST-KP-YYY-YYY-YYYY-ST: Supports CAMA signaling with ANI/Pseudo ANI (PANI).

  • KP-2-ST: Default transmission when the CAMA trunk cannot get a corresponding Numbering Plan Digit (NPD) in the look-up table or when the calling number is fewer than 10 digits. (NPA digits are not available.)

  • KP-NPD-NXX-XXXX-ST: 8-digit ANI transmission, where the NPD is a single MF digit that is expanded into the NPA. The NPD table is preprogrammed in the sending and receiving equipment (on each end of the MF trunk). For example: 0=415, 1=510, 2=650, 3=916

  • 05551234 = (415) 555-1234, 15551234 = (510) 555-1234

    The NPD value range is 0–3.

When you use the NPD format, the area code needs to be associated with a single digit. You can preprogram the NPA into a single MF digit using the ani mapping voice port command. The number of NPDs programmed is determined by local policy as well as by the number of NPAs the PSAP serves. Repeat this command until all NPDs are configured or until the NPD maximum range is reached.

In this example, the PSAP expects NPD signaling, with the area code 312 being represented by the digit 1.

You could then complete the following steps to configure the voice port for CAMA operation:

Step 1. Configure a voice port for 911 calls.

Router(config)#voice-port 1/1/1Router(config-voiceport)#ani mapping 1 312Router(config-voiceport)#signal cama kp-npd-nxx-xxxx-st

Step 2. Configure a dedicated dial peer to route emergency calls using the CAMA trunk when a user dials “911.”

Router(config)#dial-peer voice 911 potsRouter(config-dialpeer)#destination-pattern 911Router(config-dialpeer)#prefix 911Router(config-dialpeer)#port 1/1/1

Step 3. Configure a dedicated “9911” dial peer to route all emergency calls using the CAMA trunk when a user dials “9911.”

Router(config)#dial-peer voice 9911 potsRouter(config-dialpeer)#destination-pattern 9911Router(config-dialpeer)#prefix 911Router(config-dialpeer)#port 1/1/1

Step 4. Configure a standard PSTN dial peer for all other inbound and outbound PSTN calls.

Router(config)#dial-peer voice 910 potsRouter(config-dialpeer)#destination-pattern 9[2-8].........Router(config-dialpeer)#port 0/0/0:23

Example 3-4 shows the complete CAMA trunk configuration.

Example 3-4  CAMA Trunk Configuration

Router(config)#voice-port 1/1/1Router(config-voiceport)#ani mapping 1 312Router(config-voiceport)#signal cama KP-NPD-NXX-XXXX-STRouter(config)#dial-peer voice 911 potsRouter(config-dialpeer)#destination-pattern 911Router(config-dialpeer)#prefix 911Router(config-dialpeer)#port 1/1/1Router(config)#dial-peer voice 9911 potsRouter(config-dialpeer)#destination-pattern 9911Router(config-dialpeer)#prefix 911Router(config-dialpeer)#port 1/1/1Router(config)#dial-peer voice 910 potsRouter(config-dialpeer)#destination-pattern 9[2-8].........Router(config-dialpeer)#port 0/0/0:23

Direct Inward Dial

Typically, FXS ports connect to analog phones, but some carriers offer FXS trunks that support DID. The DID service is offered by telephone companies, and it enables callers to dial an extension directly on a PBX or a VoIP system (for example, Cisco Unified Communications Manager and Cisco IOS routers and gateways) without the assistance of an operator or automated call attendant. This service makes use of DID trunks, which forward only the last three to five digits of a phone number to the PBX, router, or gateway. For example, a company has phone extensions 555-1000 to 555-1999. A caller dials 555-1234, and the local CO forwards 234 to the PBX or VoIP system. The PBX or VoIP system then rings extension 234. This entire process is transparent to the caller.

An FXS DID trunk can receive only inbound calls, thus a combination of FXS, DID, and FXO ports is required for inbound and outbound calls. Two signaling types exist, loopstart and groundstart, with groundstart being the preferred method.

Figure 3-22 shows an analog trunk using an FXS DID trunk for inbound calls and a standard FXO trunk for outbound calls.

Figure 3-22

Configuring DID Trunks

You could then complete the following steps to enable DID signaling on the FXS port:

Step 1. Configure the FXS port for DID and wink-start.

Router(config)#voice-port 0/0/0Router(config-voiceport)#signal did wink-start

Step 2. Configure the FXO port for groundstart signaling.

Router(config)#voice-port 0/1/0Router(config-voiceport)#signal groundstart

Step 3. Create an inbound dial peer using the FXS DID port. Note that direct inward dial is enabled.

Router(config)#dial-peer voice 1 potsRouter(config-dialpeer)#incoming called-number .Router(config-dialpeer)#direct-inward-dialRouter(config-dialpeer)#port 0/0/0

Step 4. Create a standard outbound dial peer using the FXO port.

Router(config)#dial-peer voice 910 potsRouter(config-dialpeer)#destination-pattern 9[2-8].........Router(config-dialpeer)#port 0/1/0

Example 3-5 shows the complete DID trunk configuration.

Example 3-5  DID Trunk Configuration

Router(config)#voice-port 0/0/0Router(config-voiceport)#signal did wink-startRouter(config)#voice-port 0/1/0Router(config-voiceport)#signal groundstartRouter(config)#dial-peer voice 1 potsRouter(config-dialpeer)#incoming called-number . Router(config-dialpeer)#direct-inward-dialRouter(config-dialpeer)#port 0/0/0Router(config)#dial-peer voice 910 potsRouter(config-dialpeer)#destination-pattern 9[2-8].........Router(config-dialpeer)#port 0/1/0

Timers and Timing

You can set a number of timers and timing parameters for fine-tuning a voice port. Following are voice-port configuration mode commands you can use to a set variety of timing parameters:

  • timeouts initial seconds: Configures the initial digit timeout value in seconds. This value controls how long the dial tone is presented before the first digit is expected. This timer value typically does not need to be changed.

  • timeouts interdigit seconds: Configures the number of seconds for which the system will wait between caller-entered digits before sending the input to be assessed. If the digits are coming from an automated device, and the dial plan is a variable-length dial plan, you can shorten this timer so the call proceeds without having to wait the full default of 10 seconds for the interdigit timer to expire.

  • timeouts ringing {seconds | infinity}: Configures the length of time a caller can continue to let the telephone ring when there is no answer. You can configure this setting to be less than the default of 180 seconds so that you do not tie up a voice port when it is evident the call is not going to be answered.

  • timing digit milliseconds: Configures the DTMF digit signal duration for a specified voice port. You can use this setting to fine-tune a connection to a device that might have trouble recognizing dialed digits. If a user or device dials too quickly, the digit might not be recognized. By changing the timing on the digit timer, you can provide for a shorter or longer DTMF duration.

  • timing interdigit milliseconds: Configures the DTMF interdigit duration for a specified voice port. You can change this setting to accommodate faster or slower dialing characteristics.

  • timing hookflash-input milliseconds and hookflash-output milliseconds: Configures the maximum duration (in milliseconds) of a hookflash indication. Hookflash is an indication by a caller that wants to do something specific with the call, such as transfer the call or place the call on hold. For the hookflash-input command, if the hookflash lasts longer than the specified limit, the FXS interface processes the indication as on-hook. If you set the value too low, the hookflash might be interpreted as a hang-up. If you set the value too high, the handset has to be left hung up for a longer period to clear the call. For the hookflash-output command, the setting specifies the duration (in milliseconds) of the hookflash indication that the gateway generates outbound. You can configure this to match the requirements of the connected device.

Under normal use, these timers do not need to be adjusted. In two instances, these timers can be configured to allow more or less time for a specific function:

  • When ports are connected to a device that does not properly respond to dialed digits or hookflash

  • When the connected device provides automated dialing

Example 3-6 shows a configuration for a home for someone with a disability that might require more time to dial digits. Notice the requirement to allow the telephone to ring, unanswered, for 4 minutes. The configuration enables several timing parameters on a Cisco voice-enabled router voice port 0/1/0. The initial timeout is lengthened to 15 seconds; the interdigit timeout is lengthened to 15 seconds; the ringing timeout is set to 240 seconds; and the hookflash-in is set to 500 ms.

Example 3-6  Timers and Timing Configuration

Router(config)#voice-port 0/1/0Router(config-voiceport)#timeouts initial 15Router(config-voiceport)#timeouts interdigit 15Router(config-voiceport)#timeouts ringing 240Router(config-voiceport)#timing hookflash-in 500

Verifying Voice Ports

After physically connecting analog or digital devices to a Cisco voice-enabled router, you might need to issue show, test, or debug commands to verify or troubleshoot your configuration. For example, the following list enumerates six steps to monitor and troubleshoot voice ports:

Step 1. Pick up the handset of an attached telephony device and check for a dial tone. If there is no dial tone, check the following:

  • Is the plug firmly seated?

  • Is the voice port enabled?

  • Is the voice port recognized by the Cisco IOS?

  • Is the router running the correct version of Cisco IOS in order to recognize the module?

  • Is a dial peer configured for that port?

Step 2. If you have a dial tone, check for DTMF voice band tones, such as touch-tone detection. If the dial tone stops when you dial a digit, the voice port is probably configured properly.

Step 3. Use the show voice port command to verify that the data configured is correct. If you have 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 steps 4 through 6.

Step 4. Use the show voice port command to make sure the port is enabled. If the port is administratively down, use the no shutdown command. If the port was working previously and is not working now, it is possible the port is in a hung state. Use the shutdown/no shutdown command sequence to reinitialize the port.

Step 5. If you have configured E&M interfaces, make sure the values associated with your specific PBX setup are correct. Specifically, check for two-wire or four-wire wink-start, immediate-start, or delay-start signaling types, and the E&M interface type. These parameters need to match those set on the PBX for the interface to communicate properly.

Step 6. You must confirm that the voice network module (VNM) (that is, the module in the router that contains the voice ports) is correctly installed. With the device powered down, remove the VNM and reinsert it to verify the installation. If the device has other slots available, try inserting the VNM into another slot to isolate the problem. Similarly, you must move the voice interface card (VIC) to another VIC slot to determine whether the problem is with the VIC card or with the module slot.

For your reference, Table 3-6 lists six show commands for verifying the voice-port configuration.

Table 3-6  Commands to Verify Voice Ports



show voice port

Shows all voice-port configurations in detail

show voice port slot/subunit/port

Shows one voice-port configuration in detail

show voice port summary

Shows all voice-port configurations in brief

show voice busyout

Shows all ports configured as busyout

show voice dsp

Shows status of all DSPs

show controller T1 | E1

Shows the operational status of a controller

Example 3-7 provides sample output for the show voice port command.

Example 3-7  show voice port Command

Router#show voice portForeign Exchange Station 0/0/0 Slot is 0, Sub-unit is 0, Port is 0 Type of VoicePort is FXS  VIC2-2FXS 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 Non Linear Mute is disabled Non Linear Threshold is -21 dB Music On Hold Threshold is Set to -38 dBm In Gain is Set to 0 dB Out Attenuation is Set to 3 dB Echo Cancellation is enabled Echo Cancellation NLP mute is disabled Echo Cancellation NLP threshold is -21 dB Echo Cancel Coverage is set to 64 ms Echo Cancel worst case ERL is set to 6 dB Playout-delay Mode is set to adaptive

Playout-delay Nominal is set to 60 ms

Example 3-8 provides sample output for the show voice port summary command.

Example 3-8  show voice port summary Command

router#show voice port summary                                     IN       OUTPORT      CH   SIG-TYPE   ADMIN OPER STATUS   STATUS   EC========= == ============ ===== ==== ======== ======== ==0/0/0     —  fxs-ls       up    dorm on-hook  idle     y0/0/1     —  fxs-ls       up    dorm on-hook  idle     y50/0/11   1      efxs     up    dorm on-hook  idle     y50/0/11   2      efxs     up    dorm on-hook  idle     y50/0/12   1      efxs     up    dorm on-hook  idle     y50/0/12   2      efxs     up    dorm on-hook  idle     y

For your further reference, Table 3-7 provides a series of commands used to test Cisco voice ports. The test commands provide the capability to analyze and troubleshoot voice ports on voice-enabled routers. As Table 3-7 shows, you can use five test commands to force voice ports into specific states to test the voice port configuration. The csim start dial-string command simulates a call to any end station for testing purposes.

Table 3-7  test Commands



test voice port port_or_DS0-group_identifier detector {m-lead | battery-reversal | ring | tip-ground | ring-ground | ring-trip} {on | off | disable}

Forces a detector into specific states for testing.

test voice port port_or_DS0-group_identifier inject-tone {local | network} {1000hz |2000hz | 200hz | 3000hz | 300hz | 3200hz | 3400hz | 500hz | quiet | disable}

Injects a test tone into a voice port. A call must be established on the voice port under test. When you are finished testing, be sure to use the disable option to end the test tone.

test voice port port_or_DS0-group_identifier loopback {local | network | disable}

Performs loopback testing on a voice port. A call must be established on the voice port under test. When you finish the loopback testing, be sure to use the disable option to end the forced loopback.

test voice port port_or_DS0-group_identifier relay {e-lead | loop | ring-ground | battery-reversal | power-denial | ring | tip-ground} {on | off | disable}

Tests relay-related functions on a voice port.

test voice port port_or_DS0-group_identifier switch {fax | disable}

Forces a voice port into fax or voice mode for testing. If the voice port does not detect fax data, the voice port remains in fax mode for 30 seconds and then reverts automatically to voice mode. After you enter the test voice port switch fax command, you can use the show voice call command to check whether the voice port is able to operate in fax mode.

csim start dial-string

Simulates a call to the specified dial string. This command is most useful when testing dial plans.

Introducing Dial Peers

As a call is set up across the network, the existence of various parameters is checked and negotiated. A mismatch in parameters can cause call failure. Therefore, it is important to understand how routers interpret call legs and how call legs relate to inbound and outbound dial peers. Successful implementation of a VoIP network relies heavily on the proper application of dial peers, the digits they match, and the services they specify. A network designer needs in-depth knowledge of dial-peer configuration options and their uses. This section discusses the proper use of digit manipulation and the configuration of dial peers.

Understanding Call Legs

Call legs are logical connections between any two telephony devices, such as gateways, routers, Cisco Unified Communication Managers, or telephony endpoint devices. Additionally, call legs are router-centric. When an inbound call arrives, it is processed separately until the destination is determined. Then a second outbound call leg is established, and the inbound call leg is switched to the outbound voice port. The topology shown in Figure 3-23 illustrates the four call legs involved in an end-to-end call between two voice-enabled routers.

Figure 3-23

Dial Peers and Call Legs

An end-to-end call consists of four call legs: two from the source router’s perspective and two from the destination router’s perspective. To complete an end-to-end call from either side and send voice packets back and forth, you must configure all four dial peers. Dial peers are used only to set up calls. After the call is established, dial peers are no longer employed.

An inbound call leg occurs when an incoming call comes into the router or gateway. An outbound call leg occurs when a call is placed from the router or gateway, as depicted in Figure 3-24.

Figure 3-24

End-to-End Calls

1 2 3 4 5 6 7 8 Page 5
Page 5 of 8