Cisco IOS Voice Troubleshooting and Monitoring Guide, Release 12.4
Troubleshooting Digital Voice Interfaces to the IP Network
Downloads: This chapterpdf (PDF - 768.0KB) The complete bookPDF (PDF - 2.89MB) | Feedback

Troubleshooting Digital Voice Interfaces to the IP Network

Table Of Contents

Troubleshooting Digital Voice Interfaces to the IP Network

Checking the Hardware

Software Compatibility

Cabling

T1/E1 Trunk and Digital Voice Port Pinouts (RJ-48)

T1/E1 Trunk and Digital Voice Port Pinouts (RJ-45)

Shutdown Port

Checking the Digital Signal Processors

Voice DSP Control Message Logger

Message Logger Overview

Configuration Tasks

Configuration Examples

Voice Call Tuning

Voice DSP Crash Dump File Analysis

How to Configure Voice DSP Crash Dump File Analysis

Troubleshooting Voice DSP Crash Dump File Analysis

Verifying DSP Crash Dump File Analysis

Configuration Examples for Voice DSP Crash Dump File Analysis

Troubleshooting Universal Port SPEs

Configure SPE Diagnostic Tests

SPE Disconnect Reason Codes

DSP Troubleshooting Links

Verifying Codec Complexity

Codec Complexity Mismatch

Checking the Interface

Troubleshooting T1 and E1 Layer 1 Problems

Controller Is Administratively Down

Controller Has Loss of Frame

Controller Has Loss of Signal

Checking T1/E1 Controller Configuration

Framing Formats on Digital T1/E1 Voice Ports

Clock Sources on Digital T1/E1 Voice Ports

Line Coding on Digital T1/E1 Voice Ports

T1/E1 Channel-Associated Signaling

Troubleshooting Commands

E1 R2 Interfaces

Troubleshooting E1 R2 Failures

debug and show Commands

ISDN Interfaces

ISDN PRI Troubleshooting Tips

Verifying the ISDN Switch Type and PRI Group Timeslot Configuration

Ringback

QSIG Protocol Support

Troubleshooting Drop-and-Insert

Troubleshooting Transparent Common Channel Signaling

Dial Tone Issues

Router Does Not Recognize Voice Port

Voice Ports Are in the Shutdown State

Voice Ports Configured as Connection Trunk

No Dial Tone on Digital Voice Port

Debug Command Output Shows VTSP Timeout

Verifying Digital Voice-Port Configurations

show voice port Samples

show controller Samples

show voice dsp Samples

show voice call summary Samples

show call active voice Samples

show call history voice Sample

Verifying Digits Received and Sent on the POTS Call Leg

Voice Port Testing Commands

Detector-Related Function Tests

Loopback Function Tests

Tone Injection Tests

Relay-Related Function Tests

Fax/Voice Mode Tests


Troubleshooting Digital Voice Interfaces to the IP Network


Digital voice ports are found at the intersection of a packet voice network and a digital, circuit-switched telephone network. Digital voice telephony interfaces include T1 or E1 channel-associated signaling (CAS), ISDN primary-rate interface (PRI) or basic rate interface (BRI), and E1 R2 signaling.

To troubleshoot digital voice interfaces, see the following sections:

Checking the Hardware

Checking the Digital Signal Processors

Verifying Codec Complexity

Checking the Interface

Verifying Digital Voice-Port Configurations

Voice Port Testing Commands

If you are troubleshooting a connection to a PBX, you might the PBX interoperability notes useful. These notes contain configuration information for Cisco gateways and several types of PBXs. To access these notes, use the following website:

http://www.cisco.com/warp/public/779/largeent/avvid/inter_operability/

Checking the Hardware

Digital voice interface hardware connects a router or access server to a line from a circuit-switched telephony device in a PBX or the public switched telephone network (PSTN).

Troubleshoot digital voice hardware by checking the following:

Software Compatibility

Cabling

Shutdown Port

Software Compatibility

To ensure that your card is compatible with your software, check the following:

For network modules inserted into Cisco modular access routers, refer to the compatibility tables in the "Overview of Cisco Network Modules" chapter in the Cisco Network Modules Hardware Installation Guide.

For interface cards inserted into Cisco modular access routers, refer to the compatibility tables in the "Overview of Cisco Interface Cards" chapter in the Cisco Interface Cards Installation Guide.

Cabling

Cabling for the digital ports varies by platform:

Cisco 1600 series, Cisco 1700 series, Cisco 2600 series, Cisco 3600 series, Cisco 3700 series, and Cisco ICS 7750 platforms that use the Multiflex Trunk Interface card use an RJ-48C cable. Refer to the Cisco Interface Card Hardware Installation Guide for information about digital Cisco interface cards.

Cisco 7200 VXR platforms use RJ-48C cables for the port adapter. See the MIX-Multichannel T1/E1 Port Adapter Installation and Configuration Guide for more information.

Cisco AS5300 universal access servers use RJ-45 cables for the T1 or E1 interface. A VoIP feature is also required for voice traffic. See the Cisco AS5300 Module Installation Guide.

Cisco AS5350 and 5400 universal gateways use RJ-45 cables for the four-port card and a 36-pin cable to RJ-45 interface for the eight-port card. For more information about cabling these platforms, see the "Cabling Specifications" chapter of the Cisco AS5350 and AS5400 Universal Gateway Card Installation Guide.

T1/E1 Trunk and Digital Voice Port Pinouts (RJ-48)

Figure 32 shows the RJ-48 connector wiring for the T1/E1 trunk cable and the digital voice port cable; Table 32 lists the pinouts.

Figure 32 RJ-48-to-RJ-48 T1/E1 Cable Wiring

Table 32 Pinouts for T1/E1 Trunk and Digital Voice Port (RJ-48) 

Pin 1
Signal

1

RX (input)

2

RX (input)

3

-

4

TX (output)

5

TX (output)

6

-

7

-

8

-

1 Any pin not referenced on a connector is not connected.


T1/E1 Trunk and Digital Voice Port Pinouts (RJ-45)

Table 33 T1 or E1 Port Pinouts (RJ-45) 

RJ-45 Pin
Description

1

RX tip

2

RX ring

3

RX shield

4

TX tip

5

TX ring

6

TX shield

7

-

8

-


Shutdown Port

If the port is not operational, check to make sure the port is not shut down. Enter the show voice port command with the voice port number that you are troubleshooting, which tells you:

If the voice port is up. If it is not, use the no shutdown command to make it active.

What parameter values have been set for the voice port, including default values. (these do not appear in the output from the show running-config command.) If these values do not match those of the telephony connection you are making, reconfigure the voice port.

Checking the Digital Signal Processors

Digital signal processors (DSPs) enable Cisco platforms to efficiently process digital voice traffic. The following symptoms can be attributed to DSP hardware or software issues:

No audio heard by either party or one-way audio on the voice path after the call is connected.

Call setup failure, such as the inability to detect or transmit proper Channel Associated Signaling (CAS) state transitions.

Channels are stuck in the PARK state and cannot be used.

Error messages on the console or in the router log complain of DSP timeouts.

To check your DSPs, use the following sections:

Voice DSP Control Message Logger

Voice Call Tuning

Voice DSP Crash Dump File Analysis

Troubleshooting Universal Port SPEs

DSP Troubleshooting Links

Voice DSP Control Message Logger

This section contains the following information:

Message Logger Overview

Configuration Tasks

Configuration Examples


Caution Using the logger feature in a production network environment increases CPU and memory usage on the gateway.


Note We recommend that you work closely with your Cisco representative to use this feature. If you are experiencing problems with certain voice calls, the engineering team at Cisco might ask you to capture the control messages using the voice DSP logger. You can capture these messages by turning on the logger, repeating the problematic calls, and capturing the logs. Only Cisco engineers can determine if you should send the logs in for further review.


Message Logger Overview

The Voice DSP Control Message Logger feature provides improved debugging capabilities through Cisco IOS software and allows loggin of control messages that pass through the voice DSP firmware on the host port interface (HPI). The logged messages can later be examined for diagnosis of voice problems.

There are two main types of HPI messages that flow through the HPI interface: control messages and data messages. Control messages carry control information between Cisco IOS software and the DSP. Data messages carry voice data.

The Voice DSP Contol Message Logger feature captures control messages sent between the platform-independent portions of Cisco IOS software and the DSP. The HPI subsystem that is in Cisco IOS software contains the platform-independent portion of Cisco IOS software. This feature addresses the sequence and contents of the control messages. The logged messages can be checked for parameters that might cause undesirable DSP behavior including the following:

Incorrect parameters

Out-of-sequence function calls

Interactions between parameters of different HPI calls

In many cases, DSP problems have been the result of bad control messages. By logging all of these messages for offline analysis, you can better integrate and debug at-speed issues for analysis.

Message Capture

Message capture occurs when voice control messages are captured and passed between the Cisco IOS software and the DSP to a ring buffer. Some of these messages are sent in fast-path routines that run at a high priority, so the capture of the message must be done as quickly as possible. After the fast-path routine messages have been sent, a normal priority process sends the messages that are waiting in the ring buffer to off-router data storage through the Cisco IOS File System (IFS).

The size of the ring buffer is configurable through the use of the voice hpi capture command. If the ring buffer fills up faster than the normal priority process can move the messages off the router, some of the control messages are dropped.

Counters keep track of the number of messages that are waiting in the ring buffer, the number of messages that are sent, and the number of messages that are dropped. When message capture is enabled and a message arrives for which there is no buffer space, a missed-message count is started. The next time there is room for a message on the ring, the dropped-message count is included with the message data. This alerts the software that processes the messages to the missed messages, and it provides data capture feedback that helps you configure the ring buffer size to your specifications.

If messages are dropped during the capture, the ability to check the messages becomes limited. A complete capture is required for analysis.

Benefits

Improved DSP Reliability

This feature improves the reliability of DSPs by improving debug capabilities. Unexpected sequences of calls or parameters that cause DSP problems are difficult to debug because many calls can be made to the DSP before any ill effects are noticed. Systems that are running under load are more likely to encounter subtle timing-related issues that occur infrequently and are very hard to reproduce and debug. These parameters are marked as bad in HPI calls to the DSP, and they can cause undesirable DSP behavior. There fore, the logger intercepts those parameters that pass between Cisco IOS software and the DSP that can later be checked for errors.

Robust Firmware

This feature makes the T1-based DSP firmware more robust, adding debug capabilities and enabling better field support.

Restrictions

The Voice DSP Contol Message Logger feature is supported only on systems that use the HPI interface.

Configuration Tasks

See the following sections for configuration tasks for the Voice DSP Control Message Logger feature. Each task in the list is identified as either required or optional.

Configuring the Voice DSP Control Message Logger (required)

Verifying the Voice DSP Control Message Logger (optional)

Configuring the Voice DSP Control Message Logger

You can start the message logger by choosing the amount of memory (greater than 324 bytes) that the buffer-queueing system can allocate to the free message pool. HPI messages are captured until buffer space runs out. Once the buffer-queueing system is running, the transport process attempts to connect to a new or existing capture destination URL. A version message is written to the URL, and if the version message is accepted, any messages placed into the message queue are written to the URL. If a new URL is entered using command-line interface (CLI), an open URL is closed, and the system tries to write to the new URL. If the new URL fails, the transport process exits. The transport process is restarted when another URL is entered or the system is restarted.

To configure the message logger, use the following commands beginning in privileged EXEC mode.

SUMMARY STEPS

1. enable

2. show voice hpi capture

3. debug hpi capture

4. configure terminal

5. voice hpi capture buffer size

6. voice hpi capture destination url

7. exit

8. show voice hpi capture

9. configure terminal

10. no voice hpi capture buffer 0

11. exit

12. show voice hpi capture

DETAILED STEPS

 
Command
Purpose

Step 1 

enable

Example:

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

Enter your password if prompted.

Step 2 

show voice hpi capture

Example:

Router# show voice hpi capture

(Optional) Displays the capture status and statistics.

Use this command to confirm logger status and examine the logger status output when the logger is running.

Step 3 

debug hpi capture

Example:

Router# debug hpi capture

(Optional) Turns on the debug output for the logger.

It is recommended that you enable the debug output for the logger when you are interacting with it using CLI.

Step 4 

configure {terminal | memory | network}

Example:

Router# configure terminal

Enters global configuration mode.

Step 5 

voice hpi capture buffer size

Example:

Router(config)# voice hpi capture buffer 122

(Optional if you already have a nonzero buffer) Allocates the buffer for storing captured messages.

Starts the logger by giving it a nonzero buffer size.

The no form of the command turns the logger off by setting the buffer size to zero. Valid range is from 0 to 9000000.

If the buffer overflows so that messages are dropped during the capture, the buffer size needs to be increased and the capture needs to be restarted.

Note To change buffer size, first configure buffer size to zero, and then set the buffer size to your specifications.

Step 6 

voice hpi capture destination url

Example:

Router(config)# voice hpi capture destination 172.14.33.255

(Optional if you already have a destination or do not want to change the currently assigned destination) Sets up an FTP destination file to which the logged data is sent.

The url argument is the destination address.

Step 7 

exit

Example:

Router(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 8 

show voice hpi capture

Example:

Router# show voice hpi capture

(Optional) Displays the capture status and statistics.

Use this command to confirm logger status and examine the logger status output when the logger is running.

Note At this point, you can execute voice calls and capture the control messages. You can capture these messages by turning on the logger, repeating problematic calls, and capturing the logs. Cisco engineers can determine if you should send the logs in for further review.

Step 9 

configure {terminal | memory | network}

Example:

Router# configure terminal

Enters global configuration mode.

Step 10 

no voice hpi capture buffer 0

Example:

Router(config)# no voice hpi capture buffer 0

(Optional if you already have a nonzero buffer) Turns the logger off by setting the buffer size to zero and stops message capture.

Step 11 

exit

Example:

Router(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 12 

show voice hpi capture

Example:

Router# show voice hpi capture

Verifies that no messages were dropped during the capture.

Note At this point, gather the captured messages in the destination files on your PC or UNIX station and send the information to Cisco TAC for analysis.

Verifying the Voice DSP Control Message Logger

To verify and print capture status and statistics, use the show voice hpi capture privileged EXEC command. This command displays the capture status and statistics and checks that the message counter is incrementing. If messages are being dropped consistently, try increasing the buffer size.


Note If you want to stop the logger or change the buffer to another size, first set the buffer size to zero.


Troubleshooting Tips

Use the debug hpi capture command in privileged EXEC mode to turn on the debug output for the logger. Enable the debug output for the logger by using the CLI.

Configuration Examples

This section provides configuration examples for the Voice DSP Control Message Logger feature. This section contains the following examples:

Starting the Logger Feature Example

Setting up an FTP Destination Example

Verifying Configuration Example

Starting the Logger Feature Example

In the following example, the voice hpi capture buffer command is used in global configuration mode to start the logger by giving it a buffer size of 700000:

Router(config)# voice hpi capture buffer 700000

*Mar  1 00:24:47.090:caplog:caplog_cli_interface:hpi capture buffer size set to 700000 
 bytes
*Mar  1 00:24:47.090:caplog:caplog_logger_init:TRUE, Started task HPI Logger (PID 140 
*Mar  1 00:24:47.150:caplog:caplog_cache_init:TRUE, malloc_named(699952), 2134 elements 
(each 328 bytes big)
*Mar  1 00:24:47.154:caplog:caplog_logger_proc:Terminating...

In the following example, the show voice hpi capture command is used in privileged EXEC mode to examine the logger status output now that the logger is enabled:

Router# show voice hpi capture

HPI Capture is on and is logging to URL <www.company.com>0 messages sent to URL, 0 
messages droppedMessage Buffer (total:inuse:free)  2134:0000:2134Buffer Memory:699952 
bytes, Message size:328 bytes

Setting up an FTP Destination Example

In the following example, the voice hpi capture destination command is used in global configuration mode to set up an FTP destination file where the logged data can be sent:

Router(config)# voice hpi capture destination ftp://100.00.100.200/d:\test_data.dat

*Mar  1 00:26:54.617:caplog:caplog_cli_interface:hpi capture 
destination:ftp://100.00.100.200/d:\test_data.dat 
*Mar  1 00:26:54.621:caplog:caplog_logger_init:TRUE, Started task HPI Logger (PID 140) 
*Mar  1 00:26:54.621:caplog:caplog_logger_proc:Attempting to open 
ftp://100.00.100.200/d:\test_data.dat 
*Mar  1 00:26:57.091:caplog:caplog_logger_proc:Logging to 
ftp://100.00.100.200/d:\test_data.dat

In the following example, the show voice hpi capture command is used in privileged EXEC mode to examine the logger status output:

Router# show voice hpi capture

HPI Capture is on and is logging to URL ftp://172.23.184.216/d:\test_data.dat1 messages 
sent to URL, 0 messages droppedMessage Buffer (total:inuse:free)  2134:0000:2134Buffer 
Memory:699952 bytes, Message size:328 bytes

Verifying Configuration Example

In the following example, the show voice hpi capture command is used in privileged EXEC mode to check on the status of the logger before, during, and after configuration:

Router# show voice hpi capture 

HPI Capture is off and is logging to URL <no URL>
0 messages sent to URL, 0 messages dropped
Message Buffer (total:inuse:free)  0000:0000:0000
Buffer Memory:0 bytes, Message size:328 bytes
 
   

Voice Call Tuning

The Voice Call Tuning feature monitors the interface between Cisco IOS software and a system's digital signaling processors (DSPs) in real time and reports status on the following: packet flow, DSP state, echo-cancellation state, and jitter state. The feature also allows you to manipulate echo-cancellation and jitter-buffer parameters in real time. For details on this feature, see the "Voice Call Tuning" section on page 309 in the "Troubleshooting Quality of Service for VoIP" chapter.

Voice DSP Crash Dump File Analysis

The Voice Crash Dump File Analysis feature allows Cisco IOS voice platforms using Texas Instruments DSPs the ability to capture the contents of the DSP memory into a file in the event of a DSP crash. By making this crash dump file available for offline analysis, engineers can better and more quickly determine and fix the cause of the crash.

DSP crash dump analysis allows to you do the following:

Detect when control messages have been lost between Cisco IOS software and the DSP

Detect when the DSP has crashed

Collect an image of the DSP memory after a DSP crash and put it into a file for analysis later by an engineer

When these events have been detected, they are announced by console alarms. You can enable and disable this feature and specify where the crash dump is to be written using Cisco IOS command-line interface (CLI). The active part of the stack is written to the console, while the entire contents of the DSP memory is written to the crash dump file. You can request that a dump file be written into a "smart" slot 0 or slot 1 flash card, or sent to a server using TFTP or FTP, or it may be written directly to Flash.

How to Configure Voice DSP Crash Dump File Analysis

To configure Voice DSP crash dump file analysis, use the following steps:

SUMMARY STEPS

1. enable

2. configure {terminal | memory | network}

3. voice dsp crash-dump destination url

4. voice dsp crash-dump file-limit limit-number

5. exit

6. show voice dsp crash-dump

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure {terminal | memory | network}

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

voice dsp crash-dump destination url

Example:

Router(config)# voice dsp crash-dump destination 175.101.122

(Required) Designates a valid file system where crash dump analysis is stored.

The url argument must be set to a valid file system.

The destination URL can be one of the following

The file on a TFTP server with the following format:
tftp://x.x.x.x/subfolder/filename.

The x.x.x.x value is the IP address of the TFTP server

The file on the flashcard of the router, with the following format: slot0:filename

Note The DSP crash dump feature is disabled when the crash-dump destination is not specified.

Step 4 

voice dsp crash-dump file-limit limit-number

Example:

Router(config)# voice dsp crash-dump file-limit 99

(Required) Sets the number of files you would like to write.

The crash dump file-limit keyword must be set to a non-zero value. The default is that the crash dump capability is turned off, as the url argument is empty, and the file-number argument is zero.

The limit-number argument can range from 0 to 99.

Note The DSP crash dump feature is disabled when the crash-dump file limit is set to 0.

Step 5 

exit

Example:

Router(config)# exit

Exits to privileged EXEC mode.

Step 6 

show voice dsp crash-dump

Example:

Router# show voice dsp crash-dump

(Optional) Displays voice DSP crash dump information

Troubleshooting Voice DSP Crash Dump File Analysis

To troubleshoot the Voice DSP Crash Dump File Analysis feature, use the debug voice dsp crash-dump command in privileged EXEC mode. This command is intended only for troubleshooting purposes because the volume of output generated by the software can result in severe performance degradation on the router.

SUMMARY STEPS

1. enable

2. debug voice dsp crash-dump keepalive

3. undebug all

4. debug voice dsp crash detail

5. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

Enter your password if prompted.

Step 2 

debug voice dsp crash-dump keepalives

Example:

Router(config)# no logging console

Displays debugging information for the crash dump feature keepalives.

Confirms that a crash dump file has been written to the specified destination.

Step 3 

undebug all

Example:

Router# un all

Disables all the debug output on screen to stop the above output.

Alternately, you can use the no debug all command.

Step 4 

debug voice dsp crash detail

Example:

Router# debug voice dsp crash detail

Displays debugging information for the crash dump feature details.

There is no debug output until there is one DSP crash. When the crash dump feature is turned on, the detailed debug messages are displayed.

Step 5 

exit

Example:

Router(config)# exit

Exits to privileged EXEC mode.

Verifying DSP Crash Dump File Analysis

To verify crash dump statistics, use the show voice dsp crash-dump command in privileged EXEC mode.

Configuration Examples for Voice DSP Crash Dump File Analysis

The following example shows that crash dump analysis is enabled:

Router(config)# voice dsp crash-dump destination 172.29.248.12
Router(config)# voice dsp crash-dump file-limit 10

voice dsp crash-dump destination tftp://172.29.248.12/tester/crash-152-t 
voice dsp crash-dump file-limit 10 
end 
1w0d:%SYS-5-CONFIG_I:Configured from console by consoleoice dsp crash 

Verifying Voice DSP Crash Dump File Analysis

The following example shows output information that verifies the status of the crash dump:

Router# show voice dsp crash-dump 

Voice DSP Crash-dump status: 
    Destination file url is 
          tftp://172.29.248.12/tester/crash-152-t 
    File limit is 10 
    Last DSP dump file written was 
          tftp://172.29.248.12/zongshan/crash/26-152-t2 
    Next DSP dump file written will be 
          tftp://172.29.248.12/tester/crash-152-t1 

Troubleshooting Universal Port SPEs

A universal port card is a hardware card that processes digital signals for the Cisco AS5350 and Cisco AS5400 universal gateways. The service-processing element (SPE) works as a DSP for the universal port card.

This section provides troubleshooting information that apply to modems regardless of service type mode. It describes how to perform diagnostic tests on installed ports or SPEs, configure automatic recovery of ports on an SPE, and configure a scheduled recovery of SPEs.

Configure SPE Diagnostic Tests

You can perform three types of diagnostic tests on the SPE modem:

SPE Startup Test

SPE Auto-Test

SPE Back-to-Back Test

SPE Startup Test

To perform diagnostic testing on all the installed SPE ports during the system's initial startup or rebooting process, use theport modem startup-test command in global configuration mode.

The results of the SPE port startup test are displayed in the show port modem test command output. SPE ports that pass the diagnostic test are marked as Pass, Fail, and Unkn. Ports that fail the diagnostic test are marked as Bad. These ports cannot be used for call connections. Depending on how many ports are installed, this diagnostic test may take from 5 to 10 minutes to complete. Perform additional testing on an inoperative SPE port by executing the test port modem back-to-back command. The no port modem startup-test command disables startup testing.

SPE Auto-Test

To perform diagnostic testing on all the installed SPE ports during the system's initial startup or rebooting process, or during service, use the port modem autotest command in global configuration mode.

The results of the SPE port auto-test are displayed in the show port modem test command's output. Ports that pass the diagnostic test are marked as Idle, Busy, Downloading, and Reset, and are put into service. Ports that fail the diagnostic test are marked as Bad, and are not put into service or tested again until they are no longer marked as Bad. If all the ports of an SPE are bad, the corresponding SPE is also marked bad. These ports cannot be used for call connections. Depending on how many ports are present and not marked Bad, this diagnostic test may take from 5 to 10 minutes to complete. You may perform additional testing on an inoperative port by executing the test port modem back-to-back command. The no port modem autotest command disables testing.

You may optionally configure the following commands:

port modem autotest minimum portsDefine the minimum number of free ports available for autotest to begin.

port modem autotest time hh:mm {interval}Enable autotesting time and interval.A sample diagnostic autotest setting the time at 12:45 and at 8 hour intervals looks like the following:

AS5400(config)# port modem autotest time 12:45 8
AS5400(config)# 

port modem autotest error threshold—Define the maximum number of errors detected for autotest to begin.

SPE Back-to-Back Test

When an SPE port tests as Bad, perform additional testing by conducting a series of internal back-to-back connections and data transfers between two SPE ports. All port test connections occur inside the gateway. For example, if mobile users cannot dial into port 2/5 (the sixth port on the universal port card in the second chassis slot), attempt a back-to-back test with port 2/5 and a known-functioning port such as port 2/6.

Enter the following command in privileged EXEC mode (the prompt is displayed as AS5350# or AS5400#) to perform internal back-to-back port tests between two ports:

test port modem back-to-back slot/port slot/port {num-packets}—Perform internal back-to-back port tests between two ports, sending test packets of the specified size.

You might need to enable this command on several different combinations of ports to determine which one is not functioning properly. A pair of operable ports successfully connect and complete transmitting data in both directions. An operable port and an inoperable port do not successfully connect with each other.

A sample back-to-back test might look like the following:

AS5400# test port modem back-to-back 2/10 3/20

Repetitions (of 10-byte packets) [1]:
*Mar  02 12:13:51.743:%PM_MODEM_MAINT-5-B2BCONNECT:Modems (2/10) and (3/20) connected in 
back-to-back test:CONNECT33600/V34/LAP
*Mar  02 12:13:52.783:%PM_MODEM_MAINT-5-B2BMODEMS:Modems (3/20) and (2/10) completed 
back-to-back test:success/packets = 2/2

A port that has been confirmed to have problems can often be fixed using the clear spe command.

The results of the test port modem back-to-back command are displayed in the show port modem test command's output:

AS5400# show port modem test

 Date Time             Modem  Test               Reason            State Result
 3/02 12:00:57 PM       2/01  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:00:57 PM       2/00  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:00:58 PM       2/02  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:00:58 PM       2/03  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:00:58 PM       2/04  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:00:58 PM       2/05  Back-To-Back     :STARTUP TEST      Idle  PASS
...
 3/02 12:01:14 PM       3/95  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:01:14 PM       3/94  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:01:15 PM       3/75  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:01:15 PM       3/74  Back-To-Back     :STARTUP TEST      Idle  PASS
 3/02 12:13:52 PM       3/20  Back-To-Back     :USER INITIATED    Idle  PASS
 3/02 12:13:52 PM       2/10  Back-To-Back     :USER INITIATED    Idle  PASS
...
 3/02 12:44:00 PM      3/102  No Test (Time)   :MIN IDLE MODEMS   Idle  NOTST
 3/02 12:44:00 PM      3/103  No Test (Time)   :MIN IDLE MODEMS   Idle  NOTST
 3/02 12:44:00 PM      3/104  No Test (Time)   :MIN IDLE MODEMS   Idle  NOTST
 3/02 12:44:00 PM      3/105  No Test (Time)   :MIN IDLE MODEMS   Idle  NOTST
 3/02 12:44:00 PM      3/106  No Test (Time)   :MIN IDLE MODEMS   Idle  NOTST
 3/02 12:44:00 PM      3/107  No Test (Time)   :MIN IDLE MODEMS   Idle  NOTST
 3/02 12:44:21 PM       2/73  Back-To-Back     :TIME INTERVAL     Idle  PASS
 3/02 12:44:21 PM       2/72  Back-To-Back     :TIME INTERVAL     Idle  PASS
 3/02 12:44:21 PM       2/33  Back-To-Back     :TIME INTERVAL     Idle  PASS
 3/02 12:44:21 PM       2/32  Back-To-Back     :TIME INTERVAL     Idle  PASS
 3/02 12:44:21 PM       3/37  Back-To-Back     :TIME INTERVAL     Idle  PASS

Note The Reason column indicates why the test was started. The TIME INTERVAL is one of the triggers under autotest; the other is the error threshold.


SPE Disconnect Reason Codes

This section describes how to interpret the call disconnect reason codes reported by Cisco universal port card SPEs. Whenever a call using the universal port SPEs is cleared or disconnected, the SPE records the reason for the disconnect. This disconnect reason code can be used to determine whether the disconnect was normal or an error occurred. This reason code can be used to track down possible sources of failure. Modems can be disconnected due to a variety of factors such as client disconnects, telco errors, and call drops at the network access server (NAS). A "good" disconnect reason is that the DTE (client modem or NAS) at one end or the other wanted to terminate the call. Such "normal" disconnects indicate that the disconnect was not a result of modem or transmission level errors.


Note The disconnect reason is managed in a first-come-first-serve fashion. This means that the first disconnect reason generated is the only disconnect reason recorded. If the modem and the NAS attempt to terminate the session simultaneously and the modem happens to save the disconnect reason before the LINK_TERMINATE message from the NAS is processed, then the NAS disconnect reason is ignored.


Determining the disconnect Reason

When evaluating whether you are experiencing "good" or "bad" disconnects, it is important to obtain the history of disconnects that a particular port has experienced. In most environments, the disconnect reason is obtained using modem call records or call tracker syslog messages. This disconnect code can then be interpreted using the table provided in this document. Use the following commands to determine the disconnect reason:

The show spe modem disconnect-reason command does not display the disconnect reason code as a hexadecimal value. However, it does indicate the disconnect reason as a name. The name and class of the disconnect reason can be found inTable 35 and Table 36 respectively.

The show port modem log command displays the disconnect reason code as a hexadecimal value. Refer to Table 34 for the hexadecimal values.

Table 34 Disconnect Reason Code Hexadecimal Values

0x0..
0x1..
0x2..
0x3..
0x4..
0x5..
 

0x010

0x100

0x1F00

-

-

0x210

0x220

0x3xx

-

-

0x001

0x011

0x101

0x1F01

-

0x201

0x211

0x221

-

-

0x501

0x002

0x012

0x102

0x1F02

-

0x202

0x212

0x222

-

-

0x502

0x003

-

0x103

0x1F03

-

0x203

-

-

-

0x403

0x503

0x004

-

0x104

0x1F04

-

0x204

-

0x224

-

0x404

0x504

0x005

-

0x105

0x1F05

-

0x205

-

0x225

-

-

0x505

0x006

-

0x106

0x1F06

-

0x206

-

-

-

-

0x506

0x007

-

0x107

0x1F07

-

-

-

-

-

-

0x507

0x008

-

0x108

0x1F08

-

-

-

-

-

0x408

-

0x009

-

0x109

-

-

-

-

-

-

-

-

0x00C

-

-

-

-

-

-

-

-

-

-

0x00D

-

-

-

-

-

-

-

-

-

-

0x00E

-

-

-

-

-

-

-

-

-

-

0x00F

-

-

-

0x1FFF

-

-

-

-

-

-


Using the show port modem log command

Use the show port modem log slot/port command to obtain the disconnect cause code (in Hex) for a particular call on a specific port. This disconnect code is identical to the cause code obtained from modem call-record and call-tracker syslog outputs. An example is shown:

*Jan  1 00:53:56.867: Modem State event: State: Terminate
*Jan  1 00:53:56.879: Modem End Connect event: 
  Call Timer                              :   195  secs
  Disconnect Reason Info                  :   0x220
      Type (=0  ):  
     Class (=2  ):  EC condition - locally detected
    Reason (=32 ):  received DISC frame -- normal LAPM termination

From the example above, note that the disconnect code is 0x220.

Using the show spe modem disconnect-reason Command

Use the show spe modem disconnect-reason {summary | slot | slot/spe} command to determine the distribution of disconnect reasons that the particular port has experienced. A sample summary output of all the ports is shown below:

Router# show spe modem disconnect-reason summary
     ===CLASS OTHER====  =====CLASS DSP====  ===CLASS EC LCL===  ==CLASS EC FRMR===
     Software Rst     0  No Carrier     341  No LR            0  Frmr Bad Cmd     0
     EC Termntd       0  No ABT dtctd     0  LR Param1        0  Frmr Data        0
     Bad MNP5 Rx      0  Trainup flr    328  LR Incmpt        0  Frmr Length      0
     Bad V42B       110  Retrain Lt       0  Retrns Lt      226  Frmr Bad NR      0
     Bad COP stat     0  ABT end flr      0  Inactivity       0  
     ATH              0                      Protocol Err     1  ===CLASS EC LD====
     Aborted          0  ====CLASS HOST====  Fallbck Term    74  LD No LR         0
     Connect Tout   198  Hst NonSpec      0  No XID          67  LD LR Param1     0
     Reset DSP        0  HST Busy         0  XID Incmpt       0  LD LR Incmpt     0
                         HST No answr     0  Disc         21448  LD Retrns Lt     0
     ===CLASS EC Cmd===  HST DTR       3615  DM               5  LD Inactivty     0
     Bad Cmd          0  HST ATH          0  Bad NR           0  LD Protocol      0
                         HST NoDialTn     0  SABME Online     0  LD User          0
     =====N O N E======  HST No Carr   5276  XID Online       0  
     None            39  HST Ack          0  LR Online        0  TOTAL        31728                  
HST NoDialTn     0  SABME Online     0  LD User          0=====N O N E======  HST No 
Carr   5276  XID Online       0  None            39  HST Ack          0  LR Online        
0  TOTAL        31728

From the example above, let us say that we are interested in the disconnect category Disc within CLASS EC LCL. To determine what the disconnect reason Disc means, go to the entry corresponding to the class (CLASS EC LCL) and the disconnect reason name (Disc) which shows a hex code of 0x220 and is a normal disconnect. The codes for the classes are shown in the following tables:

CLASS OTHER Code Summary Table

CLASS DSP Reason Codes

CLASS EC LCL: EC Condition, Locally Detected Reason Code Table

CLASS EC Cmd: EC Detected Bad Command Code Reason Code Table

CLASS EC FRMR: EC Detected FRMR From Peer Reason Code Table

CLASS EC LD: Error Correction (EC) Detected Link Disconnect (LD) From Peer Reason Code Table

CLASS HOST: Requested by Host Reason Code Table

Reason Code Summary Tables

The following tables contain the detailed reason codes for universal port disconnects.

Table 35 CLASS OTHER Code Summary Table  

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

2

Software Rst

0x001

Cisco IOS software disconnected the call for some indeterminate reason (SOFTWARE_RESET).

2

EC Termntd

0x002

Error Correction (EC) layer termination

2

Bad MNP5 Rx

0x003

The Microcom Network Protocol 5 (MNP5) decompression task received an illegal token in the data stream. There is probably a logic error in the implementation of compression, decompression or error correction by the modem or partner. Can also be caused by a transient line or RAM memory error.

2

Bad V42B

0x004

The V.42bis or V.44 decompression task received an illegal token in the data stream. There is probably a logic error in either the modem's or partner's implementation of compression, decompression or error correction. Can also be caused by a transient line or RAM memory error.

2

Bad COP stat

0x005

Reserved

6,7

ATH

0x006

ATH command detected by local modem. The ATH (Hangup) AT command is detected by the local modem (universal port card). For example, following a dialout from Cisco IOS, the DTE interface clears the call by transmitting an inband ATH AT command after the call is connected.

3

Aborted

0x007

AT mode any-key abort of dial command The AT dial command was aborted by the any-key abort command. For example, the host modem originates a call. During connection establishment, pressing any-key causes the AT dial command to be aborted.

3

Connect Tout

0x008

The call took too long to complete the connection. Notice that the S7 timer (wait for carrier after dial) expired for this disconnect.

The causes include:

Difficulty negotiating a Layer I standard

Layer I and Layer II establishment taking too long.

For example, error correction negotiation takes an extended amount of time because of bit-errors introduced when the client modem receiver tries to connect at a rate it can't sustain.

This disconnect could also happen if the answer modem heard no tone from the channel because, for example, the originator was not a modem.

2

Reset DSP

0x009

The DSP was reset (command/internal/spontaneous).

The DSP within the host modem was reset by the Control Processor (CP) or Signal Processor (SP). The CP resets the DSP if mail messages from the CP to SP are not being acknowledged. The SP resets itself if it gets an internal inconsistency error.

4,6

0x00C

V.42bis or V.44 codeword size exceeded negotiated maximum.

4,6

0x00D

V.42bis or V.44 received codeword equal to next empty dictionary entry.

4,6

0x00E

V.42bis or V.44 received codeword greater than the next empty dictionary entry.

4,6

0x00F

V.42bis or V.44 received reserved command code.

4,6

0x010

V.42bis or V.44 ordinal size exceeded eight.

4,6

0x011

V.42bis or V.44 negotiation error.

4,6

0x012

V.42bis or V.44 compression error.


Table 36 CLASS DSP Reason Codes  

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

0x1xx

DSP conditions reported by SPE

4,5

No Carrier

0x100

The SPE carrier signal is lost. The universal port card detected a client modem carrier drop.

The universal port SPE stopped hearing carrier for a period greater than the value specified in Register S10 (hang-up delay after carrier loss). This could mean that the talk path went away or that the client stopped transmitting. If a layer II protocol (V.42 and/or V.42bis) is in effect, it is abnormal to see such a disconnect.

Common causes are users hanging up the call before a connection takes place can occur because of incidental dialing, aborted starts, and client applications timing out when calls take too long to connect due to multiple retrains during Layer 1 negotiation.

The condition can also occur during normal data mode when the client abruptly drops the carrier. This can occur if the link is abruptly dropped (network error), or power is shut off to the client modem disconnecting the call. This can also occur with less sophisticated client modems that do not implement the Layer I and/or Layer II clear-down protocols on a DTR drop. For a large number of client modems, this is considered a normal disconnection.

3

No ABT dtctd

0x101

No answer-back tone detected, caller is probably not a modem

3

Trainup flrv

0x102

Call failure while modem training up due to incompatible modulation or bad line.

This may be indicative of attempts to negotiate an unsupported modulation such as a legacy Rockwell proprietary modulation (K56Plus, V.FC, and so on). Other possible causes are DSP failures to train up due to severe line impairments, impulse noises, interrupting training, incompatible modulation parameters, and perhaps the inability to properly select a Layer I standard.

4,5

Retrain Lt

0x103

Too many consecutive retrains or speed-shifts. The retrain limit is specified with Register S40.

During the progress of a call, too many retrains occurred and rendered the call ineffective—the data rate would be so poor as to be useless. Sometimes the client modem does not complete the clear-down protocol, for example, when the Telco tore down the call in the middle of the connection; NextPort (NP) attempts to recover the call by issuing retrains. Once the retrain limit is reached, NP drops the call and report this disconnect reason.

3

ABT end flr

0x104

Problem detecting end of Answer-Back Tone(ABT). Negotiation failure or excessive noise during V.34 training.

Host modems answer and send out V.8bis and modulated 2100Hz answer-back tones (ABTs) with phase reversals but encounter excessive noise during the trainup sequence. Look for errors on the path from the calling modem to the answering modem in either one or both directions. Similar behavior occurs when there is latency in the Public Switched Telephone Network (PSTN)that exceeds one second for dial up and causes modems to be unable to train up the echo cancellers.

Other possible causes are:

TX power levels are incorrect and the tones are then not handled by the remote side.

Excessive noise in Phase III and IV during V.34 training.

Operator error.

Network interference during V.34 training (someone picks up the extension).

3

0x105

SS7/COT (continuity test) operation completed successfully.

3

0x106

SS7/COT (continuity test) operation failed: T8/T24 timeout waiting for tone on.

3

0x107

SS7/COT (continuity test) operation failed: T8/T24 timeout waiting for tone off.

4

0x108

Modem on hold (MOH) cleardown by the universal port card. V.92 specifies that the cleardown reason can be:

Cleardown due to incoming call

Cleardown due to outgoing call

Cleardown due to other reason

4

0x109

MOH timeout value reached.

This value can be adjusted using Register S62 (V.92 maximum MOH time).


Table 37 CLASS EC LCL: EC Condition, Locally Detected Reason Code Table  

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

0x2xx

Local error correction (EC) conditions.

3

No LR

0x201

During negotiation a link request (LR) frame was not received. Peer may not support MNP.

3

LR Param1

0x202

The received MNP LR frame had a bad/unexpected PARAM1.

For more information on PARAM1 refer to the V.42 specification.

3

LR Incmpt

0x203

The received MNP LR frame is incompatible with the host modem's settings for EC.

4,5

Retrns Lt

0x204

Too many consecutive retransmissions in EC.

This disconnect reason can be caused by noise on the line that spurs retransmissions. For instance, the host modem transmits data to the client modem, but noise on the line causes the data to be received incorrectly (or not at all) by the client side.

The client modem could also have disconnected without the host modem realizing this. So the host modem continuously retransmits, without knowing that the client modem is no longer present.

Sometimes, when the call connects in LAPM or MNP, the universal port card is unable to transmit a frame to the client modem. The client modem fails to acknowledge the universal port card's initial transmission, then fails to respond to Register S19 (error correction retransmission limit) polls (the default is 12), so NP disconnects the call. One cause could be that the carrier in the transmit path degraded substantially while the client failed to downshift. Another cause could be a problem with the client's EC engine (as happens on a Winmodem system if Windows stops responding).

6,7

Inactivity

0x205

Inactivity timeout, MNP Link Disconnect (LD) sent.

The host modem sends the client modem a LD frame, indicating that an inactivity timeout has occurred.

4,5

Protocol Err

0x206

EC protocol error.

This is a general catch-all protocol error. It indicates that a LAPM or MNP EC protocol error has occurred.

3

Fallbck Term

0x210

No EC fallback protocol available. Error correction negotiation has not been successful. The call is terminated because there is no error correction fallback protocol available.

S-register S25 (link protocol fallback) determines the available fallback protocol. The options are asynchronous framing, synchronous framing, or disconnect (hang up).

3

No XID

0x211

Never received eXchange IDentification (XID) frame during negotiation. Peer may not support MNP.

3

XID Incmpt

0x212

The received XID frame is incompatible with local settings.

The client modem may not support LAPM within V.42.

3,4,5

Disc

0x220

Received Disconnect (DISC) frame. This is the normal LAP-M disconnect.

The call terminated normally with a proper clear down from the client side. For example, a V.42 disconnect packet was sent from the client modem to the host modem. The client modem dropped DTR and cleanly negotiated a clear-down protocol.

3,4,5

DM

0x221

Received DM frame. Peer might be disconnecting.

The client modem indicates that it is disconnecting. During call setup, this reason indicates that the client modem is giving up on negotiating error correction.

4,5

Bad NR

0x222

Bad receive sequence number or ACK number was received. An MNP LD or LAP-M FRMR is sent.

The host modem received a LAPM or MNP error correction frame with a bad sequence number or acknowledgment number. An LD or Frame Reject (FRMR) frame is sent to the client modem, indicating that the host modem is disconnecting.

4,5

SABME Online

0x224

Received MNP XID frame in steady-state.

This is interpreted as a LAPM error correction protocol error in steady state. It means that the client modem may have reset due to receiving a FRMR.

4,5

XID Online

0x225

Received MNP LR frame while in steady-state.

This is interpreted as an MNP error correction protocol error in steady state. It means that the client modem has reset.


Table 38 CLASS EC Cmd: EC Detected Bad Command Code Reason Code Table

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

4,5

Bad Cmd

0x3xx

EC detected bad command code. The received unknown command is in the last 2 digits. An MNP LD or LAP-M FRMR frame is sent in response.


Table 39 CLASS EC FRMR: EC Detected FRMR From Peer Reason Code Table  

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

4,5

0x4xx

EC conditions indicated by client in LAP-M FRMR frame. The bit-mapped reason is in the last two digits.

4,5

Frmr Bad Cmd

0x401

LAPM: peer reports bad command.

The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad command.

4,5

Frmr Data

0x403

LAPM: peer reports that data field is not permitted or is incorrect length (U frames).

The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a data field that is not permitted or contained a data field with an incorrect length (that is, U frame).

4,5

Frmr Length

0x404

LAPM: peer reports data field length is greater than N401 (the maximum information field length specified in V.42), but has good Frame Check Sequence (FCS).

The modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the modem that contained a data field length that is greater than the maximum number of octets that can be carried in the information field (N401) of an I frame, an SREJ frame, an XID frame, a UI frame, or a TEST frame. The frame check sequence is good.

4,5

Frmr Bad NR

0x408

LAPM: peer reports bad receive sequence number or N(R).

The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad receive sequence number.


Table 40 CLASS EC LD: Error Correction (EC) Detected Link Disconnect (LD) From Peer Reason Code Table  

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

4,5

0x5xx

EC conditions indicated by client in MNP link disconnect ( LD ) frame. Reason field is in the last 2 digits.

3

LD No LR

0x501

MNP: peer never received LR frame.

The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem never received a link request from the host modem.

3

LD LR Param1

0x502

MNP: peer reports link request (LR) frame has bad parameter #1

The host modem received an LD frame from the client modem. The received LD frame indicates that the client modem received a link request frame from the host modem that contained an unexpected PARAM1. For more information on PARAM1 refer to the V.42 specification.

3

LD LR Incmpt

0x503

MNP: peer reports LR frame is incompatible with its configuration

The host modem received an LD frame from the client modem. The received LD frame indicates that the client modem received an LR frame from the host modem that is incompatible with the configuration of the client modem.

4,5

LD Retrns Lt

0x504

MNP: peer reports too many consecutive EC retransmissions

The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received too many consecutive retransmissions.

4,5

LD Inactivty

0x505

MNP: peer reports inactivity timer expired

The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem's host (DTE) has not passed data to the client modem within a period of time.

3

LD Protocol

0x506

MNP: peer reports error

The host modem received an LD frame from the client modem. The received LD frame indicates that the client modem received a MNP protocol error.

3

LD User

0x507

Normal MNP disconnect

The host modem received a LD frame from the client modem. The received LD frame indicates a normal MNP termination.


Table 41 CLASS HOST: Requested by Host Reason Code Table  

Disconnect Reason Type
Disconnect Reason: Name
Disconnect Reason Code (Hex)
Description

6,7

0x1Fxx

Host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the other host terminate reason. The host reason is indicated in the low-order bytes "xx".

3,6,7

HST NonSpec

0x1F00

Non-specific host-initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value.

This is the catch all Cisco IOS-initiated disconnect reason. It is used for all non-standard disconnects. For example, this could be a result of modem management software deciding to terminate the call. One possible explanation is a higher-level authentication failure RADIUS, TACACS, or another application issuing a DTR drop to the host modem. This type of disconnect does not count towards CSR when the host modem is in data mode.

3

HST Busy

0x1F01

Dialed number was busy.

Disconnection has occurred because the host is indicating that the dialed number is busy.

3

HST No answr

0x1F02

Dialed number did not answer.

Disconnection has occurred because the host is indicating that the dialed number didn't answer.

3,6,7

HST DTR

0x1F03

Virtual DTR dropped. This status is reflected by the I/O port redirector that is currently using the modem.

Disconnection has occurred because the host dropped the virtual DTR line. This generic disconnect cause is initiated by the Cisco IOS software. Example causes are idle timeout, PPP LCP TERMREQ received, authentication failure, Telnet hangup, and so on. To determine the reason for the hang up, examine the Radius disconnect reason from the modem call-record terse command or from Authentication, Authorization, and Accounting (AAA).

6,7

HST ATH

0x1F04

ATH (hangup) command was detected by local host.

3

HST NoDialTn

0x1F05

No access to telco network. Disconnection has occurred because the host could not access the network.

3,4,5

HST NoCarr

0x1F06

Network indicated disconnect.

This is a client-side triggered disconnect that is not a graceful call termination. It can occur during call set-up. A common cause is when users of Windows 95 or Windows 98 Dial Up Networking (DUN) cancel the call before the call reaches steady state. Another common reason is any client-instigated DTR drop before steady state. During data mode, this is also a client side triggered disconnection that is not a graceful call termination. One very common cause is authentication failures.

3

0x1F07

NAS terminated SS7/continuity test (COT) operation.

Disconnection has occurred because the NAS has terminated the SS7/COT operation.

3

0x1F08

The SS7/COT operation was terminated by the router because of a T8/T24 timeout.

-

0x1FFF

Unsolicited TERMINATING.

The host sends this disconnect reason when it receives a unsolicited terminating message.


Table 42 Disconnect Reason Types

Disconnect Type
Description

0

(unused)

1 - 0x2...

(unused)

2 - 0x4...

Other situations

3 - 0x6...

Condition occurred during call setup

4 - 0x8...

In data mode. Rx (line to host) data flushing OK

5 - 0xA...

In data mode. Rx (line to host) data flushing not OK

(at present, applications should not be concerned about the "not OK")

6 - 0xC...

In data mode. Tx (host to line) data flushing OK

7 - 0xE...

In data mode. Tx (host to line) data flushing not OK (at present, applications should not be concerned about the "not OK")


For more information about troubleshooting SPEs, refer to Interpreting NextPort Disconnect Reason Codes, document ID 9502.

DSP Troubleshooting Links

DSP troubleshooting procedures vary from platform to platform. To troubleshoot DSPs on your Cisco product, see the following links:

For troubleshooting the DSP on NM-HDV for Cisco 2600 series, Cisco 3600 series, and VG200 series routers, refer to Troubleshooting the DSP on NM-HDV for Cisco 2600/3600/VG200 Series Routers, document ID 19066.

For troubleshooting DSPs on the PA-VXA/PA-VXB/PA-VXC voice port adapters for Cisco 7200 series and Cisco 7500 series routers, refer to Troubleshooting DSPs on the PA-VXA/PA-VXB/PA-VXC Voice Port Adaptors for Cisco 7200/7500 Series Routers, document ID 26367.

For troubleshooting the VTSP-3-DSP_TIMEOUT error on AS5300 platforms, refer to Troubleshooting VTSP-3-DSP_TIMEOUT Error on Cisco AS5300 Access Server Platforms, document ID 18680.

If you have problems with unrecognized voice cards on Cisco 1750, Cisco 1751, and Cisco 1760 routers, it could be a problem with the packet voice data module (PVDM), which houses the DSPs. Refer to Troubleshooting Unrecognized Voice Interface Cards on Cisco 1750, 1751, and 1760 Routers, document ID 5711.

Verifying Codec Complexity

Codec complexity refers to the amount of processing power that a codec compression technique requires: some require more processing power than others. Codec complexity affects call density, which is the number of calls that can take place on the DSP interfaces. The DSP interfaces can be HCMs, port adapter DSP farms, or voice cards, depending on the type of router. The greater the codec complexity, the fewer the calls that can be handled.

Codec complexity is either medium or high. The difference between medium- and high-complexity codecs is the amount of CPU power necessary to process the algorithm and, therefore, the number of voice channels that can be supported by a single DSP. All medium-complexity codecs can also be run in high-complexity mode, but in that mode fewer (usually half as many) channels are available per DSP.

For details on the number of calls that can be handled simultaneously through the use of each of the codec standards, refer to the entries for the codec and codec complexity commands in the Cisco IOS Voice Command Reference.

Codec Complexity Mismatch

You might encounter a situation in which the router cannot set up a call and a message similar to the following appears in the output:

21:12:54: %DSPRM-5-SETCODEC: Configured codec 10 is not supported with this dsp image.

This condition indicates that the codec complexity and the voice card complexity configuration are mismatched. This problem can appear on Cisco modular access routers with HDV modules. This problem can affect Cisco IOS software Releases 12.0(7)T and later.

To see if you have this problem, you need to check the following conditions:

Check if the codec you are using is a high-complexity codec. For more information about codecs, refer to Understanding Codecs: Complexity, Hardware Support, MOS, and Negotiation, document ID 14069.

If you are going to use high-complexity codecs, check the voice card configuration. It should also be configured as high complexity.

The default configuration for voice cards on routers with HDV modules is medium complexity. To allow usage of high-complexity codecs, use the voice-card 1 and codec complexity high configuration commands.


Note To change the voice card codec complexity, remove all voice ports bound to the card and remove the configuration from the E1/T1 controller.


Checking the Interface

To troubleshoot the T1 or E1 interface, perform the following steps:

SUMMARY STEPS

1. show controller {t1 | e1}

2. Check if the line is down.

3. Check for reported alarms.

4. Check for error events.

5. Check if the interface is T1 or E1 CAS, E1 R2, or PRI.

DETAILED STEPS


Step 1 Enter the show controller t1 or show controller e1 command with the controller number for the voice port you are troubleshooting.

Router# show controller {t1 | e1} controller-number

Step 2 Check if the line is down. If so, see the "Troubleshooting T1 and E1 Layer 1 Problems" section.

Step 3 Check if there are any reported alarms. If so, refer to T1 Alarm Troubleshooting, document ID 14172 to troubleshoot alarm indications.

Step 4 Check if there are any error events. If you encounter framing, line coding, or clock timing errors, see the "Checking T1/E1 Controller Configuration" section.

Refer to T1 Error Event Troubleshooting, document ID 14174 for a flowchart to troubleshoot error events.

Step 5 Check if the interface is T1 or E1 CAS, E1 R2, or PRI. See the following sections for more information:

Checking T1/E1 Controller Configuration

T1/E1 Channel-Associated Signaling

E1 R2 Interfaces

ISDN Interfaces

Troubleshooting Drop-and-Insert

Troubleshooting Transparent Common Channel Signaling


Troubleshooting T1 and E1 Layer 1 Problems

Most T1 and E1 errors are caused by incorrectly configured lines. Ensure that line coding, framing, and clock source are configured according to the recommendations of your Service Provider.

Use the show controllers t1 and show controllers e1 commands in privileged EXEC mode to display information about the T1 or E1 links or to display the hardware and software driver information for the controller. These commands show what state the T1 or E1 controller is in. The controller can be in one of three states:

Administratively down—If the controller is administratively down, you can manually bring it up using the procedure in the "Controller Is Administratively Down" section.

Down—If the controller is down, then the cause is one of the following:

Loss of frame—See the "Controller Has Loss of Frame" section to resolve this issue.

Loss of signal—See the "Controller Has Loss of Signal" section to resolve this issue.

Up—The controller is functioning properly on Layer 1.

Solutions for bringing the controller up follow.

Controller Is Administratively Down

The controller is administratively down when it has been manually shut down. Follow these steps to restart the controller to correct this error.

SUMMARY STEPS

1. enable

2. configure {terminal | memory | network}

3. controller t1 number

4. no shutdown

5. end

DETAILED STEPS


Step 1 Enable privileged EXEC mode:

enable
Example: Router> enable

Enter your password if prompted.

Step 2 Enter global configuration mode:

configure terminal
Example: Router(config)# configure terminal

Step 3 Enter controller configuration mode:

controller t1 number

The number syntax is platform-specific. For more information about the syntax of this command, see the Cisco IOS Interface and Hardware Component Command Reference, Release 12.3.

Example: Router(config)# controller t1 0

Step 4 Restart the controller:

no shutdown

Example: Router(config-controller)# no shutdown

Step 5 Exit to privileged EXEC mode:

end

Example:Router(config)# end


What to Do Next

The controller should be running and normal configuration can continue.

Controller Has Loss of Frame

Complete the following steps if the receiver has loss of frame:

Ensure that the framing format configured on the port matches the framing format of the line. Check the framing format of the controller from the running configuration or the show controller t1or show controller e1 command output. To change the framing format, use the framing command in controller configuration mode.

For T1, the options are sf and esf. For example:

Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# controller t1 0
Router(config-controlle)# framing esf

For E1, the options are crc4 and no-crc4. For example:

Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# controller e1 0
Router(config-controlle)# framing crc4

If the first framing format does not work, try the other framing format to see if the alarm clears. For more information on framing formats, see the "Framing Formats on Digital T1/E1 Voice Ports" section.

For T1 lines, change the line build-out setting using the cablelength long or cablelength short command.

Line build-out (LBO) or cable length compensates for the loss in decibels based on the distance from the device to the first repeater in the circuit. A longer distance from the device to the repeater requires that the signal strength on the circuit be boosted to compensate for loss over that distance.

To configure transmit and receive levels for a cable length (line build-out) longer than 655 feet for a T1 trunk with a channel service unit (CSU) interface, use the cablelength long controller configuration command. To configure transmit attenuation for a cable length (line build-out) of 655 feet or shorter for a T1 trunk with a DSX-1 interface, use the cablelength short controller configuration command.

Contact your service provider and refer to the Cisco IOS Interface Configuration Guide for details on build-out settings.

What to Do Next

If the preceding steps do not fix the problem, see the "Controller Has Loss of Signal" section.

Controller Has Loss of Signal

If your controller is experiencing loss of signal, check the following.


Note Use the show controller t1 EXEC command after each step to see if the controller exhibits any errors.


Ensure that the cable between the interface port and the T1 service provider's equipment or T1 terminal equipment is connected correctly. Ensure that the cable is hooked up to the correct ports. Correct the cable connections if necessary.

Check the cable integrity by looking for breaks or other physical abnormalities in the cable. Ensure that the pinouts are set correctly. Replace the cable if necessary.

Check the cable connectors. A reversal of the transmit and receive pairs or an open receive pair can cause errors. Depending on the type of module used, the cable terminates on a male DB-15 or RJ-45/48 connector.

On a DB-15 connector, the receive pair should be on pins 2 and 9, and the transmit pair on pins 8 and 15. A DB-15 connector is shown in Figure 33.

Figure 33 DB-15 Connector

The pins on a RJ-45/48 jack are numbered from 1 through 8. With the metal pins facing toward you, pin 1 is the left-most pin. Figure 34 shows the pin numbering on an RJ-45 jack. The receive pair should be on lines 1 and 2, and the transmit pair should be on lines 4 and 5.

Figure 34 RJ-45 Pin Numbering

If you have completed all of the steps above and you are still experiencing problems, try using a rollover cable. A rollover cable is shown in Figure 35.

Figure 35 Rollover Cable

Checking T1/E1 Controller Configuration

Digital T1/E1 voice ports must have controller configurations that match the configuration of the router to the line characteristics of the telephony network connection being made so that voice and signaling can be transferred between them. This configuration also affects allows the logical voice ports, or DS0 groups, to be established. Make sure to check the following:

Framing Formats on Digital T1/E1 Voice Ports

Clock Sources on Digital T1/E1 Voice Ports

Line Coding on Digital T1/E1 Voice Ports

Contact your service provider for framing and line coding settings. Common settings are as follows:

For T1 lines, it is common to use binary 8-zero substitution (B8ZS) line coding with extended superframe (ESF), and alternate mark inversion (AMI) line coding with superframe (SF).

For E1 lines, both HDB3 and AMI line coding are available, but CRC4 framing is most widely used.

Framing Formats on Digital T1/E1 Voice Ports

The framing format parameter describes the way that bits are robbed from specific frames to be used for signaling purposes. The controller must be configured to use the same framing format as the line from the PBX or CO that connects to the voice port you are configuring.

Digital T1 lines use the SF or ESF framing format. SF provides two-state, continuous supervision signaling, in which a 0 bit value is used to represent on-hook and a 1 bit value is used to represent off-hook. ESF robs four bits instead of two, yet has little impact on voice quality. ESF is required for 64-kbps operation on DS0 and is recommended for Primary Rate Interface (PRI) configurations.

E1 lines can be configured for cyclic redundancy check (CRC4) or no cyclic redundancy check, with an optional argument for E1 lines in Australia.

To change the framing format, use the framing command in controller configuration mode. Refer to the Voice Port Configuration document for configuration information.

Path Code Violations Increasing

Ensure that the framing format configured on the port matches the framing format of the line. Path code violations and line code violations are typically present simultaneously. Always verify that your line coding is correct. Look for the following in the show controller command output:

For E1 lines, look for "Framing is {crc4|no-crc4}"

For T1 lines, check the line coding, as described in the "Line Coding on Digital T1/E1 Voice Ports" section. For T1 lines, path code violation error event is a frame synchronization bit error in the D4 (SF) format, or a CRC error in the ESF format.

If path code violations keep increasing, contact your service provider to check the line, because path code violations can also be caused by physical line problems.

Clock Sources on Digital T1/E1 Voice Ports

Digital T1/E1 interfaces use clock timers to ensure that voice packets are delivered and assembled properly. All interfaces handling the same packets must be configured to use the same source of timing so that packets are not lost or delivered late. The timing source that is configured can be external (from the line) or internal to the router's digital interface.

If the timing source is internal, timing derives from the onboard phase-lock loop (PLL) chip in the digital voice interface. If the timing source is line (external), timing derives from the PBX or PSTN CO to which the voice port is connected. It is generally preferable to derive timing from the PSTN because PSTN clocks are maintained at an extremely accurate level. This is the default setting for the clock source. When two or more controllers are configured, one should be designated as the primary clock source; it drives the other controllers.

To change the clock source, use the clock source command in controller configuration mode. Refer to the Voice Port Configuration document for configuration information.

Slip Seconds Error Counter Increasing

Use the show controller command to see if there are alarms or errors displayed by the controller. To see if the framing, line coding, and slip seconds error counters are increasing, use the show controller e1 command repeatedly. Note the values of the counters for the current interval.

If slips are present on the line, there is a clocking problem. The customer premises equipment (CPE) needs to synchronize to the clocking from the T1/E1 service provider. Complete the following steps to correct this problem:

SUMMARY STEPS

1. enable

2. show controller

3. configure terminal

4. controller {t1 | e1}

5. clock source {line [primary | secondary} | internal}

DETAILED STEPS


Step 1 Enter enable to enter privileged EXEC mode. Enter a password, if necessary.

Step 2 Ensure that the clock source is derived from the network. In the show controller EXEC command output, look for "Clock Source is Line Primary."


Note If there are multiple lines into an access server, only one can be the primary source. The other lines derive the clock from the primary source. If there are multiple lines, ensure that the line designated as the primary clock source is configured correctly. You can also configure a second line to provide clocking in case the primary source goes down. To do this, use the clock source line secondary command from controller configuration mode.


Step 3 Enter configure terminal to enter global configuration mode.

Step 4 Enter controller t1 or controller e1 to enter controller configuration mode.

Step 5 Set both the primary and secondary clock sources from controller configuration mode. For example:

Router(config-controlle)#clock source line primary

and

Router(config-controlle)#clock source line secondary 1

Ensure that the lines that you specify as the primary and secondary are both active and stable.


Note On Cisco universal gateways and access servers, the clock source is specified using the dial-tdm-clock command. Refer to the "Managing Dial Shelves" chapter in the Cisco IOS Interface Configuration Guide.



Framing Loss Seconds Increasing

Follow these instructions when dealing with a framing loss seconds increase:

SUMMARY STEPS

1. enable

2. show controller

3. configure terminal

4. controller {t1 | e1}

5. framing {sf | esf} or framing {crc4|no-crc4}

6. cablelength {long|short}

DETAILED STEPS


Step 1 Enter enable to enter privileged EXEC mode. Enter a password, if necessary.

Step 2 Ensure that the framing format configured on the port matches the framing format of the line. Look for the following in the show controller output

For T1 lines, look for "Framing is {ESF|SF}"

For E1 lines, look for "Framing is {crc4|no-crc4}"

Step 3 Enter configure terminal to enter global configuration mode.

Step 4 Enter controller t1 or controller e1 to enter controller configuration mode.

Step 5 To change the framing format, use the following commands in controller configuration mode:

For T1 lines, use framing {sf | esf}. For example:

Router(config-controlle)#framing esf

For E1 lines, use framing {crc4|no-crc4}. For example:

Router>(config-controller)#framing crc4

Step 6 For T1 lines, change the line build-out using the cablelength long or cablelength short command.

Contact your service provider and consult the Voice Port Configuration document, Release 12.3 for details on settings.


Line Coding on Digital T1/E1 Voice Ports

Digital T1/E1 interfaces require that line encoding be configured to match that of the PBX or CO that is being connected to the voice port. Line encoding defines the type of framing used on the line.

T1 line encoding methods include alternate mark inversion (AMI) and binary 8 zero substitution (B8ZS). AMI is used on older T1 circuits and references signal transitions with a binary 1, or "mark." B8ZS, a more reliable method, is more popular and is recommended for PRI configurations as well. B8ZS encodes a sequence of eight zeros in a unique binary sequence to detect line-coding violations.

Supported E1 line encoding methods are AMI and high-density bipolar 3 (HDB3), which is a form of zero-suppression line coding.

Use the show controller command to see if there are alarms or errors displayed by the controller. To see if the framing, line coding, and slip seconds error counters are increasing, use the show controller command repeatedly. Note the values of the counters for the current interval.

Line Code Violations Increasing

Ensure that the line coding configured on the port matches the line coding of the line. Change the line code in controller configuration mode if necessary.

For E1 lines, look for "Line Code is HDB3" in the show controller e1 output.

For T1 lines, look for "Line Code is {B8ZS|AMI}" in the show controller t1 output.

For T1 lines, change the line build-out using the cablelength long or cablelength short command.

If line code violations keep increasing, contact your service provider to check the line, because line code violations can also be caused by physical line problems.

Path Code Violations Increasing

Ensure the framing format configured on the port matches the framing format of the line. Path code violations and line code violations are typically present simultaneously. Always verify that your line coding is correct. Look for the following in the show controller output:

For T1 lines, look for "Line Code is {B8ZS|AMI}"

For T1 lines, path code violation error event is a frame synchronization bit error in the D4 (SF) format, or a CRC error in the ESF format.

For E1 lines, check the framing as described in the "Framing Formats on Digital T1/E1 Voice Ports" section.

For T1 lines, change the line build-out using the cablelength long or cablelength short command.

If path code violations keep increasing, contact your service provider to check the line. Path code violations can also be caused by physical line problems.

T1/E1 Channel-Associated Signaling

CAS exists in many networks today. CAS systems carry signaling information in the same channels in which voice and data are carried. Current telecommunication networks require more efficient means of signaling. CAS exists in many varieties that operate over analog and digital facilities. The analog facilities are either two- or four-wire, and the digital facilities are either North American T1 or European E1. Each CAS system uses either supervision signaling or address signaling over analog and digital facilities.

Three groups of signals are present in these facilities:

Supervision signals represent events occurring on a trunk and can be specific to CAS. Signal types include seizure, wink, and answer.

Address signals represent the digits dialed or called party number and, in some instances, other information. Address signals are based on multiflex signaling.

Tone and announcement signals include ringing and busy tones and announcements specific to an event. Service circuits are used in most exchanges to send and receive address signals and tones as well as to play announcements.

This section describes CAS signaling, which is sometimes called robbed-bit signaling because user bandwidth is robbed by the network for signaling. A bit is taken from every sixth frame of voice data to communicate on- or off-hook status, wink, ground start, dialed digits, and other information about the call.

In addition to setting up and tearing down calls, CAS provides for the receipt and capture of dialed number identification (DNIS) and automatic number identification (ANI) information, which are used to support authentication and other functions. The main disadvantage of CAS signaling is its use of user bandwidth to perform these signaling functions.

For more information about troubleshooting CAS, refer to Configuring and Troubleshooting T1 CAS Signaling, document ID 24642.

If your CAS-configured router gets stuck in the EM_PARK state, refer to Troubleshooting EM_PARK Issues for E&M Digital CAS Signaling, document ID 18959.

Troubleshooting Commands

Certain show commands are supported by the Output Interpreter tool, which allows you to view an analysis of show command output.

debug voip ccapi inout—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. You can use the output from this command to understand how calls are being handled by the router.

debug vpm all—Enables all of the debug vpm commands: debug vpm spi, debug vpm signal, and debug vpm dsp.


Note Note: This debug command generates lots of output.


show call active voice—Displays the contents of the active call table, which shows all of the calls currently connected through the router.

show call history voice—Displays the call history table. The call history table contains a listing of all calls connected through this router in descending time order since VoIP was enabled. You can display subsets of the call history table by using specific keywords.

show voice port—Displays configuration information about a specific voice port.

debug vtsp all—Enables the following debug vtsp commands: debug vtsp session, debug vtsp error, and debug vtsp dsp.

E1 R2 Interfaces

R2 signaling is a CAS system developed in the 1960s and still in use today in Europe, Latin America, Australia, and Asia. R2 signaling exists in several country versions or variants in an international version called Consultative Committee for International Telegraph and Telephone-R2 (CCITT-R2). The R2 signaling specifications are contained in International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendations Q.400 through Q.490. E1 R2 signaling is an international signaling standard that is common to channelized E1 networks.

E1 R2 signaling support allows the Cisco gateways to communicate with a central office (CO) or PBX trunk and act as a tie-line replacement. Although R2 signaling has been defined in ITU-T Q.400-Q.490 recommendations, R2 is implemented in many different ways. (Various countries implement R2 differently.) Cisco's implementation of R2 signaling on routers can accommodate most of the variations.

Troubleshooting E1 R2 Failures

Follow the instructions below to troubleshoot your configuration.

SUMMARY STEPS

1. show controller e1

2. show vfc slot number interface

3. Configure DID on the POTS peer.

4. cptone

5. Match line and register signaling provisions to the switch configuration.

6. Turn on appropriate debugs.

7. Check for communication between the router and PBX or switch.

DETAILED STEPS


Step 1 Verify that controller E1 0 is up with the show controller e1 0 command.

If it is down, check framing, line coding, clock source, and alarms. Replace the cable and reseat the card. To run these tests, see the following sections:

Checking the Hardware

Checking the Digital Signal Processors

Verifying Codec Complexity

Troubleshooting T1 and E1 Layer 1 Problems

Checking T1/E1 Controller Configuration

Step 2 If you are using an AS5300, check that the DSPs are correctly installed with the show vfc slot number interface command.

Step 3 Configure direct inward dial (DID) on the plain old telephone service (POTS) peer, so that the received digits are used to choose an outgoing peer.

Step 4 Specify cptone (cptone is specific for your country) on the voice-ports.

A cptone country must be configured to match cas-custom country. The cptone parameter sets the call progress tones for a particular country, and more importantly sets the encoding to a-law or u-law, depending on the country. For u-law, use the us keyword. For a-law, use the gb keyword. To configure cptone, see the Voice Port Configuration document, Release 12.3.

Step 5 Match line and register signaling provisions to the switch configuration.

Step 6 Turn on some of the debugs shown in the following section and study the outputs.

Step 7 Check for communication between the router and PBX or switch:

Is the line seized?

Does the router receive/send digits?

Find out which side is clearing the call.

If possible, use the latest Cisco IOS software release.


debug and show Commands

Certain show commands are supported by the Output Interpreter Tool, which allows you to view an analysis of show command output.

For Cisco IOS Software Release 12.0 and newer, use the following debugs:

debug cas—For line signaling

debug csm voice—For interregister signaling

debug vtsp all —Exchanges output of all messages (digits) between the PBX and the router

For Cisco IOS Software Release IOS 11.3, use the following commands:

modem-mgmt csm debug-rbs —For line signaling (specify service internal in global configuration mode.)

debug csm voice — For interregister signaling

debug vtsp all —Exchanges output of all messages (digits) between the PBX and the router

For the AS5400 and AS5350 platforms, use the following debugs:

debug sigsm r2—For interregister signaling

debug vtsp all —Exchanges output of all messages (digits) between the PBX and the router

ISDN Interfaces

An ISDN network can consist of T1, T3, E1, and E3 and has two types of subscriber access: Basic Rate Interface (BRI) and Primary Rate Interface (PRI). Each access comprises B and D channels.

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.

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 one of the B channels carries data or voice. The D channel carries signaling for the B channels. The D channel indicates 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.

The ISDN interfaces for Cisco gateways enable 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.

The application shown in Figure 36 allows enterprise customers with a large installed base of legacy telephony equipment to bypass the PSTN.

Figure 36 Typical Application Using ISDN BRI NT/TE VICs or ISDN BVMs

Topics for ISDN voice troubleshooting are as follows:

ISDN PRI Troubleshooting Tips

Verifying the ISDN Switch Type and PRI Group Timeslot Configuration

QSIG Protocol Support

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 chapter "Configuring IP" in the Cisco IOS IP Configuration Guide.

Determine if the voice feature card (VFC) has been correctly installed. For more information, refer to Installing Voice-over-IP Feature Cards in Cisco AS5300 Universal Access Servers, which came with your voice network module (VNM).

To learn if the VFC is operational, use the show vfc slot_number command.

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 the cable connection is not loose or disconnected.

With T1 lines, determine if your a-law setting is correct. With E1 lines, determine if your u-law setting is correct. To configure both a-law and u-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 occur, use the debug isdn q931 command to check the ISDN configuration.

For more information about troubleshooting T1 PRI, refer to T1 PRI Troubleshooting, document ID 9344.

Verifying the ISDN Switch Type and PRI Group Timeslot Configuration

Use the show running-config command to ensure that isdn switch-type and pri-group timeslots are configured correctly. To specify the central office switch type on the ISDN interface, use the isdn switch-type global configuration command. Options for this command include primary-net5. Contact your service provider for the correct values to use.


Note If you have defined ISDN PRI groups and channel groups on the same controller, ensure that you do not overlap time slots or use the ISDN D-channel timeslot in a channel group. When configuring a Primary Rate Interface (PRI), use the isdn switch-type global configuration command to configure the switch type.


To configure the isdn switch-type and pri-group:

Router# configure terminal
Router(config)# isdn switch-type primary-net5
Router(config)# controller e1 0
Router(config-controlle)# pri-group timeslots 1-31


Note In some countries, service providers offer fractional PRI lines. This means that fewer than 30 B-channels may be used for ISDN connections. For fractional PRI lines, the time slot range must include the operational B channels, plus the D channel (this is fixed on time slot 16). For example:

pri-group timeslots 1-10, 16 for the first ten B-channels.

timeslots 1-21 for the first 20 B-channels.


Verifying the Signaling Channel

If the error counters do not increase, but the problem persists, complete the following steps to verify that the signaling channel is up and configured correctly

SUMMARY STEPS

1. show interfaces serial number :15

2. Ensure that the interface is up.

3. Ensure that encapsulation is PPP.

4. Ensure that the interface is not in loopback mode.

5. Power cycle the router.

6. Turn on appropriate debugs.

7. Contact TAC.

DETAILED STEPS


Step 1 Run the show interfaces serial number:15 command, where the number is the interface number.

Step 2 Ensure that the interface is up. If the interface is not up, use the no shutdown command to bring the interface up. For example:

Router# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface serial 0:15
Router(config-if)# no shutdown

Step 3 Ensure that encapsulation is PPP. If not, use the encapsulation ppp command to set encapsulation. For example:

Router(config-if)# encapsulation ppp

Step 4 Ensure that the interface is not in loopback mode. Loopback should be set only for testing purposes. Use the no loopback command to remove loopbacks. For example:

Router(config-if)# no loopback

Step 5 Power cycle the router.

Step 6 If the problem persists, contact your service provider or the Cisco Technical Assistance Center (TAC). Refer to "Obtaining Technical Assistance" section on page xxvi for information about contacting TAC.


Ringback

In some situations, a gateway might intermittently fail to provide ringback tone (RBT) to an incoming ISDN caller. This problem has been seen on local, long-distance, and international calls.

The gateway generates ringback towards the network side (PSTN or PBX) if the setup contains Progress IE = 3, meaning the originating address (calling party) is NON-ISDN.

The gateway does not generate a ringback towards the network side (PSTN or PBX) if the setup contains no Progress IE (Progress IE =0), meaning the originating address (calling party) is ISDN.

The following figure is an example of when this might occur. International calls are arriving on ISDN.

PSTN (ISDN) --------- Cisco IOS gateway ------------ Cisco CallManager ------------ IP phone

Example of a Call That Gets Ringback Tone

You receive a call from a non-ISDN terminal. The setup contains a Progress IE = 3. The gateway generates ringback when it receives an alert from Cisco CallManager.

The following debugs were captured with the Cisco IOS command debug isdn q931:

01:34:48: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x002B
01:34:48: Sending Complete
01:34:48: Bearer Capability i = 0x9090A3
01:34:48: Channel ID i = 0xA9838D
01:34:48: Progress Ind i = 0x8583 - Origination address is non-ISDN
01:34:48: Calling Party Number i = 0x2183, '27045000', Plan:ISDN, Type:National
01:34:48: Called Party Number i = 0xA1, '27182145', Plan:ISDN, Type:National
01:34:48: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0x802B
01:34:48: Channel ID i = 0xA9838D
01:34:48: act_alert: Tone Ring Back generated in direction Network One
01:34:48: act_gen_tone: Tone Ring Back generated in direction Network
01:34:48: ISDN Se0:15: TX -> ALERTING pd = 8 callref = 0x802B

Example of a Call That Does Not Get Ringback Tone

You receive a call from an ISDN terminal. There is no Progress IE in the setup. (Progress IE = 0). The gateway is not generating ringback when it receives the alert from Cisco CallManager.

01:37:01: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x002E
01:37:01: Sending Complete
01:37:01: Bearer Capability i = 0x8090A3
01:37:01: Channel ID i = 0xA98391
01:37:01: Calling Party Number i = 0x2183, '478681058', Plan:ISDN, Type:International
01:37:01: Called Party Number i = 0xA1, '27182145', Plan:ISDN, Type:International
01:37:01: High Layer Compat i = 0x9181
01:37:01: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0x802E
01:37:01: Channel ID i = 0xA98391
01:37:01: ISDN Se0:15: TX -> ALERTING pd = 8 callref = 0x802E

In the case above, the gateway is expecting the ISDN to generate the ringback (due to no PI of 3). The ISDN, however, is not generating a ringback tone. This results in the caller hearing only silence until the called party answers the call. This might be due to an ISDN interworking issue caused because the call originated internationally (normally ring is generated at the terminating device for international calls).

Forcing Ringback

You can force the gateway to generate a ringback with the progress_ind setup enable 3 command. Configure the forced ringback on the VoIP dial peer that points to Cisco CallManager.

!
dial-peer voice 500 voip
destination-pattern 5...
progress_ind setup enable 3
!--forces ring back tone for this peer
session target ipv4:10.200.73.15
codec g711ulaw
!

For more information, refer to PSTN Callers not Hearing any Ring Back When they Call IP Phones, document ID 8331.

QSIG Protocol Support

QSIG is a peer-to-peer signaling system used in corporate voice networking. Internationally, QSIG is known as Private Signaling System No. 1 (PSS1). This open standard is a variant of ISDN D-channel voice signaling that is based on the ISDN Q.921 and Q.931 standards. Therefore, as well as providing inter-PBX communications, QSIG is compatible with public and private ISDN systems.

QSIG also has one important mechanism known as Generic Functional Procedures (QSIG GF). This mechanism provides a standard method for transporting features transparently across a network.

Integration of QSIG protocol support with Cisco voice switching services allows Cisco devices to connect PBXs, key systems, and central office switches (COs) that communicate by using the QSIG protocol. With QSIG, Cisco networks emulate the functionality of the PSTN, and QSIG signaling messages allow the dynamic establishment of voice connections across a Cisco WAN to a peer router, which can then transport the signaling and voice packets to a second PBX, as shown in Figure 37.

Figure 37 QSIG Signaling

The Cisco voice packet network appears to the traditional QSIG PBXs as a distributed transit PBX that can establish calls to any PBX, non-QSIG PBX, or other telephony endpoint served by a Cisco gateway, including non-QSIG endpoints.

QSIG Support Troubleshooting Tips

Table 43 lists debug and show commands that can help you analyze problems with your QSIG configuration.

Table 43 QSIG Troubleshooting Commands 

Command
Purpose
Router# show isdn status

Displays the status of all ISDN interfaces, including active layers, timer information, and switch type settings.

Router# show controller t1/e1

Displays information about T1 and E1 controllers.

Router# show voice port summary

Displays summary information about voice port configuration.

Router# show dial-peer voice

Displays how voice dial peers are configured.

Router# show cdapi

Displays the Call Distributor Application Programming Interface (CDAPI) information.

Router# show call history voice record

Displays information about calls made to and from the router.

Router# show rawmsg

Displays information about any memory leaks.

Router# debug isdn event

Displays events occurring on the user side (on the router) of the ISDN interface. The ISDN events that can be displayed are Q.931 events (call setup and teardown of ISDN network connections).

Router# debug tsp

Displays information about the telephony service provider (TSP).

Router# debug cdapi {events | detail}

Displays information about CDAPI application events, registration, messages, and so on.


Troubleshooting Drop-and-Insert

When a router is configured for drop-and-insert, also called TDM cross connect, traffic is passed as a transparent bit stream between the configured ports. The router acts as a conduit between the ports, ensuring that the bit stream and clocking are preserved. Because of this, there are no commands to monitor traffic or debug signaling bits. You can confirm the physical status of the T1 interfaces (carrier loss) and line quality (line errors, clock slips, framing errors) using the show controller t1 slot/port command.

You can connect the PBX directly to the voice mail system to isolate signaling problems. If the system is still not working when the router has been bypassed, you might need to use T1 analyzers (for example, the Acterna Tberd T1 analyzer) to verify that the PBX or voice mail system is sending the correct information on the T1 trunk. You can also use the analyzer to verify that the drop-and-insert feature is working correctly from one port to the other.

For more information on troubleshooting drop-and-insert, refer to Integrating PBXs into VoIP Networks Using the TDM Cross Connect Feature, document ID 27789.

Troubleshooting Transparent Common Channel Signaling

Transparent Common Channel Signaling (T-CCS) allows the connection of two PBXs with digital interfaces that use a proprietary or unsupported CCS protocol without the need for interpretation of CCS signaling for call processing.

With T-CCS, the PBX voice channels can be "nailed-up" and compressed between sites, and the accompanying signaling channel(s) can be transparently tunneled across the IP/FR/ATM backbone between PBXs. Thus, calls from the PBXs are not routed by Cisco on a call-by-call basis but follow a preconfigured route to the destination.

For information about troubleshooting T-CCS, refer to Configuring and Troubleshooting Transparent CCS, document ID 19087.

Dial Tone Issues

This section discusses troubleshooting of the voice network when no dial tone is heard from a voice port that is in the off-hook condition. Some issues include:

Router Does Not Recognize Voice Port

Voice Ports Are in the Shutdown State

Voice Ports Configured as Connection Trunk

No Dial Tone on Digital Voice Port

Debug Command Output Shows VTSP Timeout

A common problem in the voice network involves no dial tone being heard from a voice port in the off-hook condition. This might be related to configuration issues, a hardware problem, a DSP problem, or a bug in Cisco IOS software. A voice port configured with connection trunk does not provide dial tone. A faulty network module or Foreign Exchange Station (FXS) card might cause silence or no dial tone in a voice port.

For more information, refer to Troubleshooting No Dial Tone Issues, document ID 22372.

The following sections describe these various problems and related solutions.

Router Does Not Recognize Voice Port

When a router does not recognize a voice port, it might be because the router is not loaded with the Cisco IOS image required for voice support. In the case of a Cisco 1750 router, make sure that it does not have PVDM-256K-4 and PVDM-256K-8 DSPs. These are packet voice/data modules (PVDMs) for Cisco routers 1751 and later. If the Cisco 1750 router does not have the correct PVDM, the voice ports might show up in show version and show diag command output, however, there is no dial tone. Also, no DSPs are seen in the show voice dsp command output. The Cisco 1750 router should carry the proper PVDM-4 and PVDM-8 DSP cards.

For Cisco modular access routers , another problem could be a bad network module. If there is an alarm light on the network module, remove the module, put it back in the slot and power cycle. If the alarm light is still lit, replace the network module. Also, try plugging an analog phone into the FXS port with a good cable. If there is no dial tone, replace the FXS card.


Note FXS-Direct Inward Dialing (DID) does not provide dial tone.


Voice Ports Are in the Shutdown State

When voice ports are in the shutdown state, they do not provide dial tone. To fix this, enable the voice port with the no shut command under the voice port.

Voice Ports Configured as Connection Trunk

If voice ports are configured as connection trunk, the ports are in the S_TRUNKED state. Voice ports do not provide dial tone if configured for connection private line auto ringdown (PLAR). Use the show voice call summary command to verify the VPM state. In the example below, the dial-tone is given by the remote PBX/PSTN.

Router# show voice call summary
PORT CODEC VAD VTSP STATE VPM STATE
==== ===== === ========== ==========
1/0/0 g729ar8 y S_CONNECT S_TRUNKED
1/0/1 g729ar8 y S_CONNECT S_TRUNKED

Remove the connection trunk/PLAR configuration to ensure that you are getting the dial-tone.

No Dial Tone on Digital Voice Port

Use the show dial-peer command to see if the dial-peer ports are configured with the direct-inward-dial command. This command disables dial tone from the voice port. For example:

dial-peer voice 1 pots
destination-pattern .T
direct-inward-dial
port 0:D

Removing the direct-inward-dial command from dial-peer pots causes the digital voice port to provide dial tone.

Debug Command Output Shows VTSP Timeout

The VTSP and DSP timeouts are known issues that appear in many forms. Use the test dsps slot# command to see if processors are alive. Cisco IOS Releases 12.2.6a [12.2.6cM1] and later include fixes for many of these issues, but possibly not all. The problem can be temporarily cleared by a power cycle. If you experience this problem, you should open a case with the Cisco Technical Assistance Center (TAC).

Verifying Digital Voice-Port Configurations

After configuring the voice ports on your router, follow these steps to verify proper operation:

SUMMARY STEPS

1. Check for dial tone.

2. Check for DTMF detection.

3. show voice port summary

4. show voice port

5. show running-config

6. show controller {t1 | e1} controller-number

7. show voice dsp

8. show voice call summary

9. show call active voice

10. show call history voice {last | number | brief}

DETAILED STEPS


Step 1 Pick up the handset of an attached telephony device and check for a dial tone.

Step 2 If you have dial tone, check for DTMF detection. If the dial tone stops when you dial a digit, then the voice port is most likely configured properly for DTMF detection.

Step 3 To identify port numbers of voice interfaces installed in your router, use the show voice port summary command.

Step 4 To verify voice-port parameter settings, enter the show voice port command with the appropriate syntax for your voice interfaces.

Step 5 For digital T1/E1 connections, to verify the codec complexity configuration, enter the show running-config command to display the current voice-card setting. If medium complexity is specified, the codec complexity setting is not displayed. If high complexity is specified, the setting codec complexity high is displayed. The following example shows an excerpt from the command output when high complexity has been specified:

Router# show running-config
.
.
.
hostname router-alpha 
 
voice-card 0
 codec complexity high 
.
.
.

Step 6 For digital T1/E1 connections, to verify that the controller is up and that no alarms have been reported, and to display information about clock sources and other controller settings, use the show controller command. For output examples, see the "show controller Samples" section.

Router# show controller {t1 | e1} controller-number

Step 7 To display voice-channel configuration information for all DSP channels, enter the show voice dsp command. For output examples, see the "show voice dsp Samples" section.

Router# show voice dsp

Step 8 To verify the call status for all voice ports, enter the show voice call summary command. For output examples, see the "show voice call summary Samples" section.

Router# show voice call summary

Step 9 To display the contents of the active call table, which shows all of the calls currently connected through the router or concentrator, enter the show call active voice command. For output examples, see the "show call active voice Samples" section.

Router# show call active voice

Step 10 To display the contents of the call history table, enter the show call history voice command. To limit the display to the last calls connected through this router, enter the keyword last and define the number of calls to be displayed with the argument number. To limit the display to a shortened version of the call history table, use the keyword brief. For output examples, see the "show call history voice Sample" section.

Router# show call history voice {last | number | brief}


show voice port Samples

In the following sections, output examples of the following types are shown:

Cisco 3600 series digital E&M voice port

Cisco AS5300 universal access server T1 CAS voice port

Cisco 7200 series router digital E&M voice port

Cisco 3600 Digital E&M Voice Port

Router# show voice port 1/0:1
 
receEive and transMit Slot is 1, Sub-unit is 0, Port is 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

Cisco AS5300 Universal Access Server T1 CAS Voice Port

Router# show voice port
 
DS0 Group 1:0 - 1:0
 Type of VoicePort is CAS
 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
 Playout-delay Mode is set to default
 Playout-delay Nominal is set to 60 ms
 Playout-delay Maximum is set to 200 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
 Call-Disconnect Time Out is set to 60 s
 Ringing Time Out is set to 180 s
 Companding Type is u-law
 Region Tone is set for US
 Wait Release Time Out is 30 s
 Station name None, Station number None
 
 Voice card specific Info Follows:
 
 DS0 channel specific status info:
                                IN      OUT
    PORT   CH SIG-TYPE   OPER STATUS   STATUS    TIP     RING

Cisco 7200 Series Router Digital E&M Voice Port

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

show controller Samples

In the following sections, output examples of the following types are shown:

Cisco 3600 series router T1 controller

Cisco AS5800 universal access server T1 controller

Cisco 3600 Series Router T1 Controller

Router# show controller T1 1/1/0

T1 1/0/0 is up.
  Applique type is Channelized T1
  Cablelength is long gain36 0db
  No alarms detected.
  alarm-trigger is not set
  Framing is ESF, Line Code is B8ZS, Clock Source is Line.
  Data in current interval (180 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

Cisco AS5800 Universal Access Server T1 Controller

Router# show controller t1 2
 T1 2 is up.
   No alarms detected.
   Version info of slot 0:  HW: 2, Firmware: 16, PLD Rev: 0
 
 Manufacture Cookie Info:
  EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42,
  Board Hardware Version 1.0, Item Number 73-2217-4,
  Board Revision A0, Serial Number 06467665,
  PLD/ISP Version 0.0, Manufacture Date 14-Nov-1997.
 
   Framing is ESF, Line Code is B8ZS, Clock Source is Internal.
   Data in current interval (269 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

show voice dsp Samples

The following output is from a Cisco 3640 router when a digital voice port is configured.

Router# show voice dsp

TYPE DSP CH CODEC    VERS STATE STATE   RST AI PORT    TS ABORT   TX/RX-PAK-CNT
==== === == ======== ==== ===== ======= === == ======= == ===== ===============
C549 010 00 g729r8    3.3 busy  idle      0  0 1/015   1     0     67400/85384
         01 g729r8     .8 busy  idle      0  0 1/015   7     0     67566/83623
         02 g729r8        busy  idle      0  0 1/015  13     0     65675/81851
         03 g729r8        busy  idle      0  0 1/015  20     0     65530/83610
C549 011 00 g729r8    3.3 busy  idle      0  0 1/015   2     0     66820/84799
         01 g729r8     .8 busy  idle      0  0 1/015   8     0     59028/66946
         02 g729r8        busy  idle      0  0 1/015  14     0     65591/81084
         03 g729r8        busy  idle      0  0 1/015  21     0     66336/82739
C549 012 00 g729r8    3.3 busy  idle      0  0 1/015   3     0     59036/65245
         01 g729r8     .8 busy  idle      0  0 1/015   9     0     65826/81950
         02 g729r8        busy  idle      0  0 1/015  15     0     65606/80733
         03 g729r8        busy  idle      0  0 1/015  22     0     65577/83532
C549 013 00 g729r8    3.3 busy  idle      0  0 1/015   4     0     67655/82974
         01 g729r8     .8 busy  idle      0  0 1/015  10     0     65647/82088
         02 g729r8        busy  idle      0  0 1/015  17     0     66366/80894
         03 g729r8        busy  idle      0  0 1/015  23     0     66339/82628
C549 014 00 g729r8    3.3 busy  idle      0  0 1/015   5     0     68439/84677
         01 g729r8     .8 busy  idle      0  0 1/015  11     0     65664/81737
         02 g729r8        busy  idle      0  0 1/015  18     0     65607/81820
         03 g729r8        busy  idle      0  0 1/015  24     0     65589/83889
C549 015 00 g729r8    3.3 busy  idle      0  0 1/015   6     0     66889/83331
         01 g729r8     .8 busy  idle      0  0 1/015  12     0     65690/81700
         02 g729r8        busy  idle      0  0 1/015  19     0     66422/82099
         03 g729r8        busy  idle      0  0 1/015  25     0     65566/83852

Router# show voice dsp

TYPE DSP CH CODEC    VERS STATE STATE   RST AI PORT    TS ABORT   TX/RX-PAK-CNT
==== === == ======== ==== ===== ======= === == ======= == ===== ===============
C549 007 00 {medium}  3.3 IDLE  idle      0  0 1/0:1    4     0             0/0
                      .13
C549 008 00 {medium}  3.3 IDLE  idle      0  0 1/0:1    5     0             0/0
                      .13
C549 009 00 {medium}  3.3 IDLE  idle      0  0 1/0:1    6     0             0/0
                      .13
C549 010 00 {medium}  3.3 IDLE  idle      0  0 1/0:1    7     0             0/0
                      .13
C549 011 00 {medium}  3.3 IDLE  idle      0  0 1/0:1    8     0             0/0
                      .13
C549 012 00 {medium}  3.3 IDLE  idle      0  0 1/0:1    9     0             0/0
                      .13
C542 001 01 g711ulaw  3.3 IDLE  idle      0  0 2/0/0          0         512/519
                      .13
C542 002 01 g711ulaw  3.3 IDLE  idle      0  0 2/0/1          0         505/502
                      .13
C542 003 01 g711alaw  3.3 IDLE  idle      0  0 2/1/0          0     28756/28966
                      .13
C542 004 01 g711ulaw  3.3 IDLE  idle      0  0 2/1/1          0         834/838
                      .13

show voice call summary Samples

The following is an output example of show voice call summary on a Cisco 3600 series router digital voice port:

Cisco 3600 Series Router Digital Voice Port

Router# show voice call summary
PORT      CODEC    VAD VTSP STATE            VPM STATE
========= ======== === ===================== ========================
1/015.1  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.2  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.3  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.4  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.5  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.6  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.7  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.8  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.9  g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.10 g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.11 g729r8    y  S_CONNECT             S_TSP_CONNECT            
1/015.12 g729r8    y  S_CONNECT             S_TSP_CONNECT            

show call active voice Samples

The output from the Cisco 7200 series router is shown below.

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


show call history voice Sample

The following output is for the Cisco 7200 series router.

Router# 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

Verifying Digits Received and Sent on the POTS Call Leg

Once the on-hook and off-hook signaling are verified to be working correctly, verify the correct digits are being received or sent on the digital voice port. A dial peer that does not matched or the switch (CO or PBX) cannot ring the correct station if incomplete or incorrect digits are being sent or received. Some commands that can be used to verify the digits received or sent are:

show dialplan number—This command is used to show which dial peer is reached when a particular telephone number is dialed.

debug vtsp session—This command displays information on how each network indication and application request is processed, signaling indications, and DSP control messages.

debug vtsp dsp—This command displays the digits as they are received by the voice port.

debug vtsp all—This command enables the following debug voice telephony service provider (VTSP) commands: debug vtsp session, debug vtsp error, and debug vtsp dsp.

show dialplan number

The show dialplan number command displays the dial peer that is matched by a string of digits. If multiple dial-peers can be matched, they are all shown in the order in which they are matched. The output of this command looks like this:

Router# show dialplan number 5000
Macro Exp.: 5000

VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation
        state is up,
        incoming called-number = `', 
        connections/maximum = 0/unlimited,
        application associated: 
        type = voip, session-target = 
        `ipv4:192.168.10.2',
        technology prefix: 
        ip precedence = 5, UDP checksum = 
        disabled, session-protocol = cisco, 
        req-qos = best-effort, 
        acc-qos = best-effort, 
dtmf-relay = cisco-rtp, 
        fax-rate = voice,   
        payload size =  20 bytes
        codec = g729r8,   
        payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,
        signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 25630, Charged Units = 0,
        Successful Calls = 25, Failed Calls = 0,
        Accepted Calls = 25, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call 
        clearing.",
        Last Setup Time = 84427934.
        Matched: 5000   Digits: 4
        Target: ipv4:192.168.10.2

debug vtsp dsp

debug vtsp dsp shows the digits as they are received by the voice-port. The following output shows the collection of DTMF digits from the DSP:

Router# debug vtsp dsp 
Voice telephony call control dsp debugging is on


!-- ACTION: Caller picked up handset and dialed 
!-- digits 5000.
!-- The DSP detects DTMF digits. Digit 5 was 
!-- detected with ON time of 130msec.


*Mar 10 17:57:08.505: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_BEGIN: digit=5, 
*Mar 10 17:57:08.585: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_OFF: digit=5, 
duration=130
*Mar 10 17:57:09.385: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_BEGIN: digit=0
*Mar 10 17:57:09.485: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_OFF: digit=0, 
duration=150
*Mar 10 17:57:10.697: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_BEGIN: digit=0
*Mar 10 17:57:10.825: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_OFF: digit=0, 
duration=180
*Mar 10 17:57:12.865: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_BEGIN: digit=0
*Mar 10 17:57:12.917: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_OFF: digit=0, 
duration=100

Router# debug vtsp session 
Voice telephony call control session debugging is on


!--- <some output have been omitted>
!-- ACTION: Caller picked up handset. 
!-- The DSP is allocated, jitter buffers, VAD 
!-- thresholds, and signal levels are set.


*Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)]
packet_len=18 channel_id=1 packet_id=76 mode=1 
initial=60 min=4 max=200 fax_nom=300
*Mar 10 18:14:22.865: dsp_echo_canceller_control: 
[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66
flags=0x0
*Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)] 
packet_len=12 channel_id=1 packet_id=91 
in_gain=0 out_gain=65506
*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)] 
packet_len=10 channel_id=1 packet_id=78 
thresh=-38act_setup_ind_ack 
*Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)] 
packet_len=24 channel_id=1 packet_id=73 coding_type=1
voice_field_size=80 
VAD_flag=0 echo_length=64 comfort_noise=1 
inband_detect=1 digit_relay=2 
AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mod
e()act_setup_ind_ack: passthru_mode = 0, 
no_auto_switchover = 0dsp_dtmf_mode
(VTSP_TONE_DTMF_MODE)


!-- The DSP is put into "voice mode" and dial-tone is 
!-- generated.


*Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)] 
packet_len=30 channel_id=1 packet_id=72 tone_id=4 
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

If the digits are not being sent or received properly, then it might be necessary to use either a digit-grabber (test tool) or T1 tester to verify that the digits are being sent at the correct frequency and timing interval. If they are being sent "incorrectly" for the switch (CO or PBX), some values on the router or switch (CO or PBX) might need to be adjusted so that they match and can interoperate. These are usually digit duration and inter-digit duration values.

Another item to examine if the digits appear to be sent correctly are any number translation tables in the switch (CO or PBX) that may add or remove digits. Refer to your switch documentation to check the translation tables on your switch.

Voice Port Testing Commands

These commands allow you to force voice ports into specific states for testing. The following types of voice-port tests are covered:

Detector-Related Function Tests

Loopback Function Tests

Tone Injection Tests

Relay-Related Function Tests

Fax/Voice Mode Tests

Detector-Related Function Tests

Using the test voice port detector command, you are able to force a particular detector into an on or off state, perform tests on the detector, and then return the detector to its original state.

To configure this feature, enter these commands beginning in privileged EXEC mode:

 
Command
Purpose

Step 1 

Router# test voice port slot/port:ds0-group detector {m-lead | battery-reversal | loop-current | ring | tip-ground | ring-ground | ring-trip} {on | off}

Identifies the voice port you want to test. Enter a keyword for the detector under test and specify whether to force it to the on or off state.

Step 2 

Router# test voice port slot/port:ds0-group detector {m-lead | battery-reversal | loop-current | ring | tip-ground | ring-ground | ring-trip} disable


Identifies the voice port on which you want to end the test. Enter a keyword for the detector under test and the keyword disable to end the forced state.

Loopback Function Tests

To establish loopbacks on a voice port, enter the following commands beginning in privileged EXEC mode:

 
Command
Purpose

Step 1 

Router# test voice port slot/port:ds0-group loopback {local | network}

Identifies the voice port you want to test and enters a keyword for the loopback direction.

Note A call must be established on the voice port under test.

Step 2 

Router# test voice port slot/port:ds0-group loopback disable


Identifies the voice port on which you want to end the test and enters the keyword disable to end the loopback.

Tone Injection Tests

To inject a test tone into a voice port, enter the following commands beginning in privileged EXEC mode:

 
Command
Purpose

Step 1 

Router# test voice port slot/port:ds0-group inject-tone {local | network} {1000hz | 2000hz | 200hz | 3000hz | 300hz | 3200hz | 3400hz | 500hz | quiet}

Identifies the voice port you want to test and enter keywords for the direction to send the test tone and for the frequency of the test tone.

Note A call must be established on the voice port under test.

Step 2 

Router# test voice port slot/port:ds0-group inject-tone disable

Identifies the voice port on which you want to end the test and enter the keyword disable to end the test tone.

Note The disable keyword is available only if a test condition is already activated.

Relay-Related Function Tests

To test relay-related functions on a voice port, enter the following commands beginning in privileged EXEC mode:

 
Command
Purpose

Step 1 

Router# test voice port slot/port:ds0-group relay {e-lead | loop | ring-ground | battery-reversal | power-denial | ring | tip-ground} {on | off}

Identifies the voice port you want to test.

Enter a keyword for the relay under test and specify whether to force it to the on or off state.

Step 2 

Router# test voice port slot/port:ds0-group relay {e-lead | loop | ring-ground | battery-reversal | power-denial | ring | tip-ground} disable

Identifies the voice port on which you want to end the test.

Enter a keyword for the relay under test, and the keyword disable to end the forced state.

Fax/Voice Mode Tests

The test voice port switch fax command forces a voice port into fax mode for testing. After you enter this command, you can use the show voice call or show voice call summary command to check whether the voice port is able to operate in fax mode. If no fax data is detected by the voice port, the voice port remains in fax mode for 30 seconds and then reverts automatically to voice mode.

The disable keyword ends the forced mode switch; however, the fax mode ends automatically after 30 seconds. The disable keyword is available only while the voice port is in fax mode.

To force a voice port into fax mode and return it to voice mode, enter the following commands, beginning in privileged EXEC mode:

 
Command
Purpose

Step 1 

Router# test voice port slot/port:ds0-group switch fax

Identifies the voice port you want to test.

Enter the keyword fax to force the voice port into fax mode.

Step 2 

Router# test voice port slot/port:ds0-group switch disable

Identifies the voice port on which you want to end the test.

Enter the keyword disable to return the voice port to voice mode.