Worldwide [change] |Account |Register |About Cisco
Guest

Hierarchical Navigation

Dial-on-Demand Routing (DDR)

Troubleshooting Dial Technology Connectivity - Callin

Downloads

Document ID: 14951


Contents

Introduction
Before You Begin
      Conventions
      Prerequisites
      Components Used
History
Callin - Troubleshooting Incoming Calls
External Async Modem Callin
CAS T1/E1 Async Modem Callin
PRI Async Modem Callin
PRI ISDN Callin
BRI Async Modem Callin
BRI ISDN Callin
Related Information

Introduction

This document provides methods of troubleshooting different types of dial connections and is not intended to be read from start to finish. The structure is designed to allow the reader to skip forward to the sections of interest, each of which are variations on the overall troubleshooting theme for a specific case. This document covers three main scenarios; before you begin to troubleshoot, determine what type of call is being attempted and go to that section:

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

History

Dialup is simply the application of the public switched telephone network (PSTN) that carries data on behalf of the end user. It involves a customer premises equipment (CPE) device sending the telephone switch a phone number to which to direct a connection. The AS3600, AS5200, AS5300, and AS5800 are all examples of routers that have the ability to run a PRI along with banks of digital modems. The AS2511, on the other hand, is an example of a router that communicates with external modems.

The carrier market has grown significantly, and the market now demands higher modem densities. The answer to this need is a higher degree of interoperation with the telephone company equipment and the development of the digital modem. This is a modem that is capable of direct digital access to the PSTN. As a result, faster CPE modems have now been developed that take advantage of the clarity of signal that the digital modems enjoy. The fact that the digital modems connecting into the PSTN through a PRI or BRI can transmit data at over 53k using the V.90 communication standard, attests to the success of the idea.

The first access servers were the AS2509 and AS2511. The AS2509 could support 8 incoming connections using external modems, and the AS2511 could support 16. The AS5200 was introduced with 2 PRIs and could support 48 users using digital modems, and it represented a major leap forward in technology. Modem densities have increased steadily with the AS5300 supporting 4 and then 8 PRIs. Finally, the AS5800 was introduced to fill the needs of carrier class installations needing to handle dozens of incoming T1s and hundreds of user connections.

A couple of outdated technologies bear mentioning in a historical discussion of dialer technology. 56Kflex is an older (pre-V.90) 56k modem standard that was proposed by Rockwell. Cisco supports version 1.1 of the 56Kflex standard on its internal modems, but recommends migrating the CPE modems to V.90 as soon as possible. Another outdated technology is the AS5100. The AS5100 was a joint venture between Cisco and a modem manufacturer. The AS5100 was created as a way to increase modem density through the use of quad modem cards. It involved a group of AS2511s built as cards that inserted into a backplane shared by quad modem cards, and a dual T1 card.

Callin - Troubleshooting Incoming Calls

This document is broken up into 6 sub-sections, based on media being used:

There is some overlap between sections. Some sections are repeated as needed.

Troubleshooting an incoming call starts at the bottom and works its way up. The general flow of reasoning resembles the following:

  1. Do we see the call arrive? (A yes answer advances to the next question)

  2. Does the receiving end answer the call?

  3. Does the call complete?

  4. Is data passing across the link?

  5. Is the session established? (PPP or terminal)

For modem connections, a data call looks the same as a terminal session coming in until the end where the data call goes to negotiate PPP.

External Async Modem Callin

Follow the steps below for external async modem callin:

  1. To identify an external async modem callin, use the debug modem command.

  2. To facilitate debugging on an external modem connected to a TTY line, increase the speaker volume with the ATM1 command. This helps to make some problems more apparent.

  3. Ensure that the call reaches the async modem. If the call does not reach the async modem, try the following:

    Manual Callin

    1. Ensure that the called phone number is correct. Put a handset on the originating phone line and try calling the number.

    2. Ensure that a manual call is able to reach the answering async modem. If a manual call is able to reach the answering async modem, check the call originating device.

    3. If a manual call is not able to reach the answering async modem, change the phone cables and try a regular phone on the modem line. If the call can be received by the regular phone, there is likely a problem with the receiving modem.

    4. If the manual call is still not able to reach the regular phone on the line in question, try another (known good) line in the receiving facility. If that connects OK, have the telco check the phone line going to the receiving modem.

    5. If this is a long distance call, have the originating side try another (known good) long distance number. If that works the reciving facility or line may not be provisioned to receive long distance calls. If the originating line cannot reach any other long distance numbers, it may not have long distance enabled. Try 1010 codes for different long distance companies.

    6. Finally, try another (known good) local number from the originating line. If the connection still fails, have theh telco check the originating line.

  4. If an external modem is not answering, check the cabling between the modem and the access server or router. Confirm that the modem is connected to the TTY or auxiliary port on the router with a rolled RJ-45 cable and an MMOD DB-25 adapter. Cisco recommends and supports this cable configuration for RJ-45 ports. Note that these connectors are typically labeled: Modem.

    RJ-45 cabling comes in a few types: straight, rolled, and crossover. You can determine the cabling type by holding the two ends of an RJ-45 cable side-by-side. You'll see eight colored strips, or pins, at each end.

    • If the order of the colored pins is the same at each end, the cable is straight.

    • If the order of the colors is reversed at each end, the cable is rolled.

    • The cable is a crossover cable if colors indicate the following:

    RJ45 to RJ45 crossover cable:

    RJ45                  RJ45 



         5 ------------------ 2



         2 ------------------ 5



         4 ------------------ 1 



         1 ------------------ 4

    To make sure the signaling is OK, use the show line command outlined in Chapter 16 of the Internetwork Troubleshooting Guide.

    Ensure that the local async modem picks up the call. If the local async modem does not pick up the call, the modem may not be configured to autoanswer or the modem may not see DTR from the router. Use reverse telnet to ensure the modem is initialized and cabled correctly.

  5. Ensure that the async modems train up. If the receiving modem raises DSR, the trainup was successful. From debug modem, one can see if DSR went high. If DSR does not go high, there may be a cable problem between the modem and the router. Trainup failures can also indicate a circuit problem or modem incompatibility.

    To get to the bottom of an individual modem problem, go to the AT prompt at the originating modem while it's attached to the POTS line of interest. If possible, use to get to the AT prompt of the receiving modem as well. Use ATM1 to have the modems send sound to their speakers so that people at each end can hear what is happening on the line.

    Does the music have noise in it? If so, clean up the circuit. If the async modems do not train up, call the number and listen for static. There may be other factors interfering with train up. Reverse telnet to the async modem and debug.

  6. With the modems training up, it's time to check the session to make sure it's starting properly.

CAS T1/E1 Async Modem Callin

Follow these steps to identify a CAS T1/E1 async modem callin:

  1. To identify a CAS T1/E1 async modem callin, use the following commands, then try to make a call:

    warning Warning: Running debugs on a busy system could crash the router by overloading the CPU or over-running the console buffer!

    router# debug modem
router# debug modem csm
router# debug cas

    Note: The debug cas command is available on Cisco AS5200 and AS5300 platforms running Cisco IOS® Software Release 12.0(7)T and later. In prior versions of IOS the command service internal would have to be entered into the main level of the router's configuration and modem-mgmt csm debug-rbs would need to be entered at the exec prompt. Debugging on the Cisco AS5800 requires connecting to the trunk card. (Use modem-mgmt csm no-debug-rbs to turn off the debug.)

  2. Check debug outputs to see if the switch went off hook. If the switch did not go off hook, try the following:

      Manual Callin

    1. Ensure that the called phone number is correct. Put a handset on the originating phone line and try calling the number. If a manual call is able to reach the answering async modem, check the call originating device.

    2. If the manual call is not able to reach the receiving modem, try another (known good) line in the receiving facility. If that works, move forward to T1/E1 check.

    3. If this is a long distance call, have the originating side try another (known good) long distance number. If that works, the receiving facility or line may not be provisioned to receive long distance calls. If the originating line cannot reach any other long distance numbers, it may not have long distance enabled. Try 1010 codes for different long distance companies.

    4. Finally, try another (known good) local number from the originating line. If the connection still fails, have telco check the originating line.

      T1/E1 Check

    1. Use the show controller t1/e1 command to verify that T1/E1 is working. See Troubleshooting T1 or Troubleshooting E1 in Chapter 15 of the Internetworking Troubleshooting Guide for an explanation of show controller output.

    2. If the T1/E1 is not working properly, T1/E1 troubleshooting is necessary.

    CAS Signal Check

    Use the debug serial interface command, then the show interface serial x command. If this is a CAS T1 (which uses RBS), then RBS CAS troubleshooting is necessary. If this is a CAS E1 (which uses R2), then R2 troubleshooting is necessary. In either case, debugging should be done with a live specialist. Please contact the Cisco TAC.

  3. Ensure that the originator of the call hears an answerback tone from the receiving modem. If the originator of the call does not hear an answerback tone, try the following:

    1. Ensure the line configuration contains the modem inout command

    2. Using the modem-mgmt csm debug-rbs command, make sure a modem is being allocated. If a modem gets allocated and there is no answerback tone, gather debugs and contact the Cisco TAC. (Use modem-mgmt csm no-debug-rbs to turn off the debug.)

    3. If no modem gets allocated to the call, check the availability of modems. Adjust the configuration of the modem pools or use resource pool management to accommodate the number of users.

  4. If the receiving modem raises DSR, the trainup was successful. Trainup failures can indicate a circuit problem or modem incompatibility.

    To get to the bottom of an individual modem problem, go to the AT prompt at the originating modem while it's attached to the POTS line of interest. If calling into a digital modem in a Cisco access server, be prepared to record a .wav file of the trainup music, or digital impairment learning sequence (DIL). The DIL is the musical score (PCM sequence) that the originating V.90 analog modem tells the receiving digital modem to play back. The sequence allows the analog modem to discern any digital impairment in the circuit, such as multiple D/A conversions, a law/u-law, robbed bits, or digital pads. If you don't hear the DIL, the modems did not negotiate V.90 in V.8/V.8bis (that is, there is a modem compatibility issue). If you do hear the DIL and a retrain in V.34, the analog modem decided (on the basis of the DIL playback) that V.90 was infeasible. To turn on the client modem's speaker, use the command ATM1.

    Does the music have noise in it? If so, clean up the circuit. See T1/E1 troubleshooting for further assistance.

    Does the client give up quickly, without running V.34 training? It may not know what to do when it hears V.8bis. In this case you should try disabling V.8bis (hence K56Flex) on the server (if acceptable). You should get new client firmware or swap out the client modem. Alternately, the dialing end could insert five commas at the end of the dial string. This delays the calling modems listen and will cause the V.8bis tone from the receiving server to timeout without affecting the client modem. Five commas in the dial string is a general guideline and might need adjusting to allow for local conditions.

  5. With the modems training up, it's time to check the session to make sure it's starting properly.

PRI Async Modem Callin

Follow these steps to make a PRI async modem callin:

  1. Use the debug isdn q931 command, then try to make a call.

    warning Warning: Running debugs on a busy system could crash the router by overloading the CPU or over-running the console buffer!

    Here is example output from a successful connection:

    Router# debug isdn q931

RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

    The setup message indicates that a connection is being initiated by the remote end. The call reference numbers are maintained as a pair. In this case, the call reference number for the incoming side of the connection is 0x06, and the call reference number of the outbound side of the connection is 0x86. The Bearer Capability (often referred to as the bearercap) tells the router what kind of call is coming in. In this case the connection is type 0x8890. That value indicates "ISDN Speed 64 Kb/s." If the bearercap had been 0x8090A2, it would have indicated "Speech/voice call u-law."

  2. If no setup message came in, verify the correct number by calling it manually. Also check the status of the ISDN interface (you might refer to the Internetwork Troubleshooting Guide Chapter 16, "Interpreting Show ISDN Status" for details). Try this:

      T1/E1 Check

    1. Use the show controller t1/e1 command to verify that T1/E1 is working. See Troubleshooting T1 or Troubleshooting E1 in Chapter 15 of the Internetworking Troubleshooting Guide for an explanation of show controller output.

    2. If the T1/E1 is not working properly, then T1/E1 troubleshooting is necessary.

      PRI ISDN Check

    1. Use the show isdn stat command to see whether Layer 1 is active. If Layer 1 is not active, the ISDN interface is down - the PRI does not see T1/E1 framing. See Troubleshooting a PRI in Chapter 15 of the Internetwork TroubleShooting Guide for a more detailed explanation.

    2. Ensure that Layer 2 shows multiple frame established. If Layer 2 does not show multiple frame established, ensure that the settings match the switch type with the debug isdn q921 command.

    3. Use the show isdn service command to ensure that channels are available. If channels are not available, check the T1/E1 controller config by using the show running-config command. Look for the pri-group timeslot command under the T1 controller config and verify that the setting is correct.

    4. If the PRI checks out and the call is still not showing up, contact the telco to verify the line. It may not be provisioned to allow voice calls (which is how a modem call appears to the ISDN network).

        If all that checks out, make sure that the call originator is making the correct call. Try this:

      1. Ensure that the called phone number is correct. Put a handset on the originating phone line and try calling the number. If a manual call is able to reach the answering modem, check the call originating device.

      2. If this is a long distance call, have the originating side try another (known good) long distance number. If that works, the receiving facility or line may not be provisioned to receive voice calls (check with the telco). If the originating line cannot reach any other long distance numbers, it may not have long distance enabled. Try 1010 codes for different long distance companies.

      3. Finally, try another (known good) local number from the originating line. If the connection still fails, have the telco check the originating line.

  3. If the call arrived but did not complete, look for a cause code (see Table 9). A successful completion is indicated by connect-ack.

  4. Enter the following commands, then try to make a call:

    router# debug modem
router# debug modem csm

  5. Ensure that the originator of the call hears an answerback tone. If the originator of the call does not hear an answerback tone, verify the Cisco IOS Software configuration and the availability of the modem. Ensure the isdn incoming-voice modem command appears in the configuration. If a modem is allocated, but no tone is heard, gather the debugs and contact the Cisco TAC.

  6. If the receiving modem raises DSR, the trainup was successful. Trainup failures can indicate a circuit problem or modem incompatibility.

    To get to the bottom of an individual modem problem, go to the AT prompt at the originating modem while it's attached to the POTS line of interest. If calling into a digital modem in a Cisco access server, be prepared to record a .wav file of the trainup music, or digital impairment learning sequence (DIL). The DIL is the musical score (PCM sequence) that the originating V.90 analog modem tells the receiving digital modem to play back. The sequence allows the analog modem to discern any digital impairment in the circuit, such as multiple D/A conversions, a law/u-law, robbed bits, or digital pads. If you don't hear the DIL, the modems did not negotiate V.90 in V.8/V.8bis (that is, there is a modem compatibility issue). If you do hear the DIL and a retrain in V.34, the analog modem decided (on the basis of the DIL playback) that V.90 was infeasible. To turn on the client modem's speaker, use the command ATM1.

    Does the music have noise in it? If so, then clean up the circuit. See T1/E1 troubleshooting for further assistance.

    Does the client give up quickly, without running V.34 training? It may not know what to do when it hears V.8bis. In this case you should try disabling V.8bis (hence K56Flex) on the server (if acceptable). You should get new client firmware or swap out the client modem. Alternately, the dialing end could insert five commas at the end of the dial string. This delays the calling modems listen and will cause the V.8bis tone from the receiving server to timeout without affecting the client modem. Five commas in the dial string is a general guideline and might need adjusting to allow for local conditions. With the modems training up, it's time to check the session to make sure it's starting properly.

PRI ISDN Callin

To identify a PRI ISDN callin:

Use the following commands, then try to make a call:

warning Warning: Running debugs on a busy system could crash the router by overloading the CPU or over running the console buffer!

router# debug isdn q931

Here's an example output from a successful connection:

Router# debug isdn q931

RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

The setup message indicates that a connection is being initiated by the remote end. The call reference numbers are maintained as a pair. In this case, the call reference number for the incoming side of the connection is 0x06, and the call reference number of the outbound side of the connection is 0x86. The Bearer Capability (often referred to as the bearercap) tells the router what kind of call is coming in. In this case, the connection is type 0x8890. That value indicates "ISDN Speed 64 Kb/s." If the bearercap had been 0x8090A2, it would have indicated "Speech/voice call u-law."

If no setup message came in, you should verify the correct number by calling it manually (if it is voice provisioned).

You should also check the status of the ISDN interface (you might refer to the Internetwork Troubleshooting Guide Chapter 16, "Interpreting Show ISDN Status" for details). Try this:

    T1/E1 Check

  1. Use the show controller t1/e1 command to verify that T1/E1 is working. See Troubleshooting T1 or Troubleshooting E1 in Chapter 15 of the Internetworking Troubleshooting Guide for an explanation of show controller output.

  2. If the T1/E1 is not working properly, T1/E1 troubleshooting is necessary.

    PRI ISDN Check

  1. Use the show isdn stat command to see whether Layer 1 is active. If Layer 1 is not active, the ISDN interface is down - the PRI does not see T1/E1 framing. See Troubleshooting a PRI in Chapter 15 of the Internetwork Troubleshooting Guide for a more detailed explanation.

  2. Ensure that Layer 2 shows multiple frame established. If Layer 2 does not show multiple frame established, ensure that the settings match the switch type with the debug isdn q921 command.

  3. Use the show isdn service command to ensure that channels are available. If channels are not available, check the T1/E1 controller config by using the show running-config command. Look for the pri-group timeslot command under the T1 controller config and verify the setting is correct.

  4. If the PRI checks out and the call is still not showing up, contact the telco to verify the line. It may not be provisioned to allow voice calls (which is how a modem call appears to the ISDN network).

      If all that checks out, make sure that the call originator is making the correct call. Try this:

    1. Ensure that the called phone number is correct. Put a handset on the originating phone line and try calling the number. If a manual call is able to reach the answering modem, check the call originating device.

    2. If this is a long distance call, have the originating side try another (known good) long distance number. If that works, the receiving facility or line may not be provisioned to receive voice calls (check with the telco). If the originating line cannot reach any other long distance numbers, it may not have long distance enabled. Try 1010 codes for different long distance companies.

    3. Finally, try another (known good) local number from the originating line. If the connection still fails, have the telco check the originating line.

      If the call arrived but did not complete, look for a cause code (see Table 9). A successful completion is indicated by connect-ack.

      At this point the ISDN call is connected, but no data has been seen coming across the link. Use the command debug ppp negotiate to see if any PPP traffic is coming across the line. If you do not see traffic, there may be a speed mismatch. To determine whether this is the case, use the show running-config privileged exec command to view the router configuration. Check the dialer map interface configuration command entries in the local and remote router. These entries should look similar to the following:

      dialer map ip 131.108.2.5 speed 56 name C4000

      For dialer profiles, a map-class needs to be defined in order to set the speed. Note that, by default, ISDN interfaces attempt to use 64K communications speeds on each channel.

      For detailed information on configuring dialer maps and profiles, refer to the Cisco IOS Dial Solutions Configuration Guide, Dial Solutions Command Reference, and the Dial Solutions Quick Configuration Guide.

      If you receive valid PPP packets, the link is up and working. You should proceed to the "Troubleshooting PPP" section in Chapter 17 of the Internetwork Troubleshooting Guide

BRI Async Modem Callin

This feature only works on the Cisco 3640 platform using Cisco IOS Software Release 12.0(3)T or later. It requires a later hardware revision of the BRI network module. This will not work with a WIC.

  1. Use the debug isdn q931 command, then try to make a call.

    Here's an example output from a successful connection:

    Router# debug isdn q931

RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

    The setup message indicates that a connection is being initiated by the remote end. The call reference numbers are maintained as a pair. In this case, the call reference number for the incoming side of the connection is 0x06, and the call reference number of the outbound side of the connection is 0x86. The Bearer Capability (often referred to as the bearercap) tells the router what kind of call is coming in. In this case, the connection is type 0x8890. That value indicates "ISDN Speed 64 Kb/s." If the bearercap had been 0x8090A2, it would have indicated "Speech/voice call u-law."

  2. If no setup message came in, verify the correct number by calling it manually. Also check the status of the ISDN interface (you might refer to the Internetwork Troubleshooting Guide Chapter 16, "Interpreting Show ISDN Status" for details). Try this:

      BRI ISDN Check

    1. Use the show isdn stat command to see whether Layer 1 is active. If Layer 1 is not active, the ISDN interface is down. BRI does not see the voltage.

    2. Ensure that Layer 2 shows multiple frame established. If Layer 2 does not show multiple frame established, ensure that the settings match the switch type with the debug isdn q921 command.

    3. If the BRI checks out and the call is still not showing up, make sure that the call originator is making the correct call. Try this:

      1. Ensure that the called phone number is correct. Put a handset on the originating phone line and try calling the number. If a manual call is able to reach the answering modem, check the call originating device.

      2. If this is a long distance call, have the originating side try another (known good) long distance number. If that works, the receiving facility or line may not be provisioned to receive voice calls (check with the telco - modem calls look like voice calls to the ISDN network). If the originating line cannot reach any other long distance numbers, it may not have long distance enabled. Try 1010 codes for different long distance companies.

      3. Finally, try another (known good) local number from the originating line. If the connection still fails, have the telco check the originating line.

  3. If the call arrived but did not complete, look for a cause code (see Table 9). A successful completion is indicated by connect-ack.

  4. Enter the following commands, then try to make a call:

    router# debug modem
router# debug modem csm

  5. Ensure that the originator of the call hears an answerback tone. If the originator of the call does not hear an answerback tone, verify the Cisco IOS Software configuration and the availability of the modem. Ensure the isdn incoming-voice modem command appears in the configuration. If a modem is allocated, but no tone is heard, gather the debugs and contact the Cisco TAC.

  6. If the receiving modem raises DSR, the trainup was successful. Trainup failures can indicate a circuit problem or modem incompatibility.

    To get to the bottom of an individual modem problem, go to the AT prompt at the originating modem while it's attached to the POTS line of interest. If calling into a digital modem in a Cisco access server, be prepared to record a .wav file of the trainup music, or digital impairment learning sequence (DIL). The DIL is the musical score (PCM sequence) that the originating V.90 analog modem tells the receiving digital modem to play back. The sequence allows the analog modem to discern any digital impairment in the circuit, such as multiple D/A conversions, a law/u-law, robbed bits, or digital pads. If you don't hear the DIL, the modems did not negotiate V.90 in V.8/V.8bis (that is, there is a modem compatibility issue). If you do hear the DIL and a retrain in V.34, the analog modem decided (on the basis of the DIL playback) that V.90 was infeasible. To turn on the client modem's speaker, use the command ATM1.

    Does the music have noise in it? If so, then clean up the circuit. (Contact the telco for further assistance.)

    Does the client give up quickly, without running V.34 training? It may not know what to do when it hears V.8bis. In this case, you should try disabling V.8bis (hence K56Flex) on the server (if acceptable). You should get new client firmware or swap out the client modem. Alternately, the dialing end could insert five commas at the end of the dial string. This delays the calling modem's listen and will cause the V.8bis tone from the receiving server to timeout without affecting the client modem. Five commas in the dial string is a general guideline and might need adjusting to allow for local conditions.

    With the modems training up, it's time to check the session to make sure it's starting properly.

BRI ISDN Callin

This section shows steps for a BRI ISDN callin:

  1. Use the debug isdn q931 command, then try to make a call.

    Here's an example output from a successful connection:

    Router# debug isdn q931

RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

    The setup message indicates that a connection is being initiated by the remote end. The call reference numbers are maintained as a pair. In this case, the call reference number for the incoming side of the connection is 0x06, and the call reference number of the outbound side of the connection is 0x86. The Bearer Capability (often referred to as the bearercap) tells the router what kind of call is coming in. In this case, the connection is type 0x8890. That value indicates "ISDN Speed 64 Kb/s." If the bearercap had been 0x8090A2, it would have indicated "Speech/voice call u-law."

  2. If no setup message came in, you should verify the correct number by calling it manually (if it's provisioned for voice calls). You should also check the status of the ISDN interface (You might refer to the Internetwork Troubleshooting Guide Chapter 16, "Interpreting Show ISDN Status" for details). Try this:

      BRI ISDN Check

    1. Use the show isdn stat command to see whether Layer 1 is active. If Layer 1 is not active, the ISDN interface is down. BRI does not see the voltage.

    2. Ensure that Layer 2 shows multiple frame established. If Layer 2 does not show multiple frame established, ensure that the settings match the switch type with the debug isdn q921 command.

    3. If the BRI checks out, make sure that the call originator is making the correct call. This can be done by contacting the telephone company. The call originator can trace the call to see where it's being sent. If the connection is long distance, try a different long distance carrier using a 1010 long distance code

  3. If the call arrived but did not complete, look for a cause code (see Table 9). A successful completion is indicated by connect-ack.

  4. At this point the ISDN call is connected, but no data has been seen coming across the link. Use the command debug ppp negotiate to see whether any PPP traffic is coming across the line. If you do not see traffic, there may be a speed mismatch. To determine whether this is the case, use the show running-config privileged exec command to view the router configuration. Check the dialer map interface configuration command entries in the local and remote router. These entries should look similar to the following:

    dialer map ip 131.108.2.5 speed 56 name C4000

    For dialer profiles, a map-class needs to be defined in order to set the speed. Note that, by default, ISDN interfaces attempt to use 64K communications speeds on each channel.

    For detailed information on configuring dialer maps and profiles, refer to the Cisco IOS Dial Solutions Configuration Guide, Dial Solutions Command Reference, and the Dial Solutions Quick Configuration Guide.

    If you receive valid PPP packets, the link is up and working. You should proceed to the "Troubleshooting PPP" section in Chapter 17 of the Internetwork Troubleshooting Guide.

Related Information

Updated: Jul 06, 2007 Document ID: 14951