Troubleshooting Dial Technology Connectivity - Non-DDR Callout
Available Languages
Contents
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:
-
Non-DDR callout
Prerequisites
Requirements
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 Primary Rate Interface (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 Basic Rate Interface (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.
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
Non-DDR Callout
There are a few common reasons to do a non-DDR outbound call from a Cisco access server:
-
To use the access server with Cisco Dialout Utility.
-
To use the access server as a terminal server to access a character cell dialup session on another server, perhaps to manually log in and start PPP later.
-
To test or configure a modem (refer to Configuring Reverse Telnet).
Similar to troubleshooting DDR Callouts, the general flow of reasoning for troubleshooting Non-DDR Callouts resembles the following:
-
Is the TCP connection to the listening port successful? (A yes advances to the next question)
-
Is the modem able to offer the AT prompt?
-
Does the call make it out to the PSTN?
-
Does the remote end answer the call?
-
Does the call complete?
-
Is data passing over the link?
-
Is the session established? (PPP or Terminal)
A Few Notes About the Cisco Dialout Utility
The Cisco Dialout Utility allows a community of Windows PCs to effectively share the modem resources of an access server. The general steps in setting up the Cisco Dialout Utility for a community of users are:
-
Set up the Network Access Server (NAS) with the following commands under the line configurations:
line 1 16 modem InOut rotary 1 transport input all flowcontrol hardware
-
Install Cisco Dialout on the PCs that will be using the NAS's modems. Verify the configurations:
-
Double-click on the dialout utility icon at the bottom right of the screen.
-
Click More.
-
Click Configure Ports.
-
-
Enabling modem logging on the PC is also suggested. This is done by clicking Start > Control Panel > Modems. Select your Cisco dialout modem and click the Properties button. Select the Connection tab, then click the Advanced button. Select the Record a log file check box.
-
Configure Dial Up Networking on the PCs to use the Cisco Dialout COM port.
There are a few things to know about the port number selection for Cisco Dialout Utility. By default, it tries to use TCP port 6001. This implies that it is the only user on an outbound NAS. Since this is not normally the case, it is better to use 7001 to take advantage of the rotary function. TCP listener processes are created by putting the transport input command on a line configuration. Here's a table of what the various IP port number ranges do:
Table 3: TCP Listener Ports Set Up by The "Transport Input" Command| 2000 | Telnet protocol |
| 3000 | Telnet protocol with rotary |
| 4000 | Raw TCP protocol |
| 5000 | Raw TCP protocol with rotary |
| 6000 | Telnet protocol, binary mode |
| 7000 | Telnet protocol, binary mode with rotary |
| 9000 | XRemote protocol |
| 10000 | XRemote protocol with rotary |
A rotary allows someone to make an inbound TCP connection to a specified port and end up connecting to any modem currently available that has the rotary group number. In the above example, the rotary group sets up listeners on 3001, 5001, 7001, and 10001. Cisco Dialout Utility uses binary mode, so 7001 is the correct number to configure the client programs to use on the PCs.
Troubleshooting Non-DDR Dialout
Try these steps to troubleshoot your non-DDR dialout.
-
To watch the initial success of a non-DDR callout (for example, a Configuring Reverse Telnet callout), use the debug telnet command to see the incoming telnet connection to the router.
-
If the TCP connection is being refused, there is either no listener at the specified address and port or someone is already connected to that port. Verify the address to which you are connecting, and verify the port number.
Also, ensure the modem inout (or modem dtr-active) and the transport input all commands appear under the line configuration for the line being reached. If using the rotary function, ensure the rotary 1 (or whatever number you chose) command also appears in the line configuration. To see whether someone is connected, telnet to the router and use the show line command. Look for an asterisk to indicate that the line is in use. Also, use the show line n command to ensure Clear to Send (CTS) is high and data set ready (DSR) is not. Use the clear line n command to disconnect the current session on that port number.
At this point, the telnet should be working. Next, identify the type of media that is being used for the outbound connection:
External Async Modem Non-DDR Callout
To identify an external async modem non-DDR callout (for example,Configuring Reverse Telnet callout), perform the following:
-
Enter the AT command, and ensure that an OK response appears. If the OK response does not appear, enter the AT&FE1Q0 command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to be initialized. If you still do not get an OK response, verify the cabling, line speed, and parity settings on the local async modem to the router connection. For further reference, see the Modem-Router Connection Guide.
-
Turn up the volume on the modem's speaker with the ATM1 command and enter ATDT <number>.
-
If the remote end does not seem to be answering, verify that the call is being placed by the originating modem by calling a local number manually with the command ATDT <number>and listening for the ring.
-
If there is no ring, the call is not getting out.
Swap the originating modem's cables and try again. If it still is not working, try a handset on the line. Be sure to use the same cable that the modem was using. If the handset is not able to make an outbound call even with the new cable, contact the telco to check the originating phone line.
-
If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.
Use a handset to call the receiving number. Be sure to use the same cable that the modem was using. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.
-
If a manual call is not able to reach the answering async modem, change the phone cables on the receiving modem and try a regular phone on the receiving modem's line. If the call can be received by the regular phone, there is likely a problem with the receiving modem. Verify the modem, and replace as needed.
-
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, have the telco check the phone line going to the receiving modem.
-
If the manual call is not able to reach the receiving facility and 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 10-10 codes for different long distance companies.
-
Ensure that the async modems train up.
If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, llet's try a connection to one of Cisco's test systems. First, we'll want to enable the speaker and DCE rate information reporting:
atm1 OK
Next, we dial into a static lab:
at OK atdt914085703932 NO CARRIER
The normal connection seems to be failing. In this case we know it is a noisy line, so put the modem to factory defaults (&f), turn on the speaker (m1), and cap the modem at 28.8 (&n14 for USR modems) with the following command:
at&fm1&n14 OK
Now we try the dial again:
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
-
Ensure that data is flowing. Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug and replace as needed.
If entering data gets a reasonable response from the other side, the modem connection is working.
CAS T1/E1 Non-DDR Callout
Follow these steps to perform a CAS T1/E1 non-DDR callout.
-
Diagnose a CAS T1/E1 async modem Non-DDR Callout, use the following commands, then try to make a call:
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 RBS on the Cisco AS5800 requires connecting to the trunk card. (Use modem-mgmt csm no-debug-rbs to turn off the debug.)
-
Enter the AT command and ensure that an OK response appears.
If the OK response does not appear, enter the AT&F command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to be initialized. If you still do not get an OK response, there may be a problem with the modem module. Before a call can be placed, a modem must be allocated for the call. To view this process and the subsequent call, use the debug output to determine whether this is happening. For example:
Turning on the debugs:
router#conf t Enter configuration commands, one per line. End with CNTL/Z. router(config)#service internal router(config)#^Z router#modem-mgmt csm ? debug-rbs enable rbs debugging no-debug-rbs disable rbs debugging router#modem-mgmt csm debug-rbs router# neat msg at slot 0: debug-rbs is on neat msg at slot 0: special debug-rbs is on
Turning off the debugs:
router# router#modem-mgmt csm no-debug-rbs neat msg at slot 0: debug-rbs is off
Debugging this information on an AS5800 requires connecting to the trunk card. The following is an example of a normal outbound call over a CAS T1 that is provisioned and configured for FXS-Ground-Start:
Mica Modem(1/0): Rcvd Dial String(5551111) [Modem receives digits from chat script] CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 CSM_RX_CAS_EVENT_FROM_NEAT:(A003): EVENT_CHANNEL_LOCK at slot 1 and port 0 CSM_PROC_OC4_DIALING: CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 Mica Modem(1/0): Configure(0x1) Mica Modem(1/0): Configure(0x2) Mica Modem(1/0): Configure(0x5) Mica Modem(1/0): Call Setup neat msg at slot 0: (0/2): Tx RING_GROUND Mica Modem(1/0): State Transition to Call Setup neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING [Telco switch goes OFFHOOK] CSM_RX_CAS_EVENT_FROM_NEAT:(A003): EVENT_START_TX_TONE at slot 1 and port 0 CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 neat msg at slot 0: (0/2): Tx LOOP_CLOSURE [Now the router goes OFFHOOK] Mica Modem(1/0): Rcvd Tone detected(2) Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 Mica Modem(1/0): Rcvd Digits Generated CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 CSM_RX_CAS_EVENT_FROM_NEAT:(A003): EVENT_CHANNEL_CONNECTED at slot 1 and port 0 CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 Mica Modem(1/0): Link Initiate Mica Modem(1/0): State Transition to Connect Mica Modem(1/0): State Transition to Link Mica Modem(1/0): State Transition to Trainup Mica Modem(1/0): State Transition to EC Negotiating Mica Modem(1/0): State Transition to Steady State Mica Modem(1/0): State Transition to Steady State Speedshifting Mica Modem(1/0): State Transition to Steady State
Debugs for T1s and E1s with other signaling types are similar.
Getting to this point in the debugging indicates that the calling and answering modems have trained and connected. If a modem is properly allocated for the outbound call but the connection fails to get this far, the T1 must be examined. Use the show controller t1/e1 command to verify that T1/E1 is working. See Troubleshooting Serial Lines for an explantion of show controller output. If the T1/E1 is not working properly, then T1/E1 troubleshooting is necessary.
-
If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.
Use a handset to call the receiving number. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.
-
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, have the telco check the phone line going to the receiving modem.
-
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 (CAS) line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.
-
Ensure that the async modems train up.
If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, let's try a connection to one of Cisco's test systems.
at OK
Next we dial into a static lab:
at OK atdt914085703932 NO CARRIER
The normal connection seems to be failing. In this case we know it's a noisy line, so let's put the modem to factory defaults (&f), turn on the speaker (m1), and cap the modem at 28.8 (S56=28800) with the following command:
at&fs56=28800 OK
Now we try the dial again:
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
-
Ensure that data is flowing.
Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug, and replace as needed.
Warning: Running debugs on a busy system could crash the router by overloading the CPU or over-running the console buffer.If entering data gets a reasonable response from the other side, the modem connection is working.
PRI Non-DDR Callout
Follow these steps to perform a PRI non-DDR callout.
-
Diagnose a PRI async modem Non-DDR Callout, use the following commands, then try to make a call:
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 isdn q931 router# debug isdn
-
Enter the AT command and ensure that an OK response appears.
If the OK response does not appear, enter the AT&F command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to use a modemcap to be initialized. This involves using the command modem autoconfigure type xxx , where xxx is the modem type. If you still do not get an OK response, there may be a problem with the modem module. Verify that the modem can place a call by manually initiating a dial. If the remote end does not seem to be answering, verify that the call is being placed by the modem by calling a local number manually with the command ATDT <number> and listening for the ring. If no call gets out, there may be an ISDN problem. Upon the first suspicion of an ISDN failure on a BRI, always check the output from show isdn status. The key things to note are that Layer 1 should be Active and Layer 2 should be in a state of MULTIPLE_FRAME_ESTABLISHED. Refer to Interpreting Show ISDN Status for information on reading this output, as well as for corrective measures.
For outbound ISDN calls, debug isdn q931 and debug isdn events are the best tools to use. Fortunately, debugging outbound calls is very similar to debugging incoming calls. A normal successful call might look like this:
*Mar 20 21:07:45.025: ISDN SE0:23: Event: Call to 5553759 at 64 Kb/s *Mar 20 21:07:45.033: ISDN SE0:23: TX -> SETUP pd = 8 callref = 0x2C *Mar 20 21:07:45.037: Bearer Capability i = 0x8890 *Mar 20 21:07:45.041: Channel ID i = 0x83 *Mar 20 21:07:45.041: Keypad Facility i = 0x35353533373539 *Mar 20 21:07:45.141: ISDN SE0:23: RX <- CALL_PROC pd = 8 callref = 0xAC *Mar 20 21:07:45.145: Channel ID i = 0x89 *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING Channel ID i = 0x0101 *Mar 20 21:07:45.161: ------------------- Channel ID i = 0x89 *Mar 20 21:07:45.313: ISDN SE0:23: RX <- CONNECT pd = 8 callref = 0xAC *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECTNote that the CONNECT message is the key indicator of success. If a CONNECT is not received, you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by a cause code:
*Mar 20 22:11:03.212: ISDN SE0:23: RX <- RELEASE_COMP pd = 8 callref = 0x8F *Mar 20 22:11:03.216: Cause i = 0x8295 - Call rejected
The cause value indicates two things.
-
The second byte of the 4- or 6-byte value indicates the point in the end-to-end call path from which the DISCONNECT or RELEASE_COMP was received. This can help you to localize the problem.
-
The third and fourth bytes indicate the actual reason for the failure. See Table 9 for the meanings of the different values.
-
-
If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.
Use a handset to call the receiving number. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.
-
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, have the telco check the phone line going to the receiving modem.
-
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 (BRI) line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.
-
Ensure that the async modems train up.
If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, let's try a connection to one of Cisco's test systems.
at OK
Next we dial into a static lab:
at OK atdt914085703932 NO CARRIER
The normal connection seems to be failing. In this case we know it's a noisy line, so let's put the modem to factory defaults (&f), turn on the speaker (m1), and cap the modem at 28.8 (S56=28800) with the following command:
at&fs56=28800 OK
Now we try the dial again:
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
-
Ensure that data is flowing.
Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug, and replace as needed.
If entering data gets a reasonable response from the other side, the modem connection is working.
BRI Non-DDR Callout
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 WAN Interface Card (WIC).
-
Diagnose a PRI async modem Non-DDR Callout, use the following commands, then try to make a call:
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 isdn q931 router# debug isdn
-
Enter the AT command and ensure that an OK response appears.
Enter the AT command and ensure that an OK response appears. If the OK response does not appear, enter the AT&F command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to use a modemcap to be initialized. This involves using the command modem autoconfigure type xxx , where xxx is the modem type. If you still do not get an OK response, there may be a problem with the modem module. Verify that the modem can place a call by manually initiating a dial. If the remote end does not seem to be answering, verify that the call is being placed by the modem by calling a local number manually with the command ATDT<number>and listening for the ring. If no call gets out, there may be an ISDN problem. Upon the first suspicion of an ISDN failure on a BRI, always check the output from show isdn status. The key things to note are that Layer 1 should be Active and Layer 2 should be in a state of MULTIPLE_FRAME_ESTABLISHED. Refer to Interpreting Show ISDN Status for information on reading this output, as well as for corrective measures.
For outbound ISDN calls, debug isdn q931 and debug isdn events are the best tools to use. Fortunately, debugging outbound calls is very similar to debugging incoming calls. A normal successful call might look like this:
*Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s *Mar 20 21:07:45.033: ISDN BR0: TX -> SETUP pd = 8 callref = 0x2C *Mar 20 21:07:45.037: Bearer Capability i = 0x8890 *Mar 20 21:07:45.041: Channel ID i = 0x83 *Mar 20 21:07:45.041: Keypad Facility i = 0x35353533373539 *Mar 20 21:07:45.141: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xAC *Mar 20 21:07:45.145: Channel ID i = 0x89 *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING Channel ID i = 0x0101 *Mar 20 21:07:45.161: ------------------- Channel ID i = 0x89 *Mar 20 21:07:45.313: ISDN BR0: RX <- CONNECT pd = 8 callref = 0xAC *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECTNote that the CONNECT message is the key indicator of success. If a CONNECT is not received, you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by a cause code:
*Mar 20 22:11:03.212: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x8F *Mar 20 22:11:03.216: Cause i = 0x8295 - Call rejected
The cause value indicates two things.
-
The second byte of the 4- or 6-byte value indicates the point in the end-to-end call path from which the DISCONNECT or RELEASE_COMP was received. This can help you to localize the problem.
-
The third and fourth bytes indicate the actual reason for the failure. See Table 9 for the meanings of the different values.
-
-
If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.
Use a handset to call the receiving number. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.
-
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, have the telco check the phone line going to the receiving modem.
-
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 (BRI) line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.
-
Ensure that the async modems train up.
If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, let's try a connection to one of Cisco's test systems.
at OK
Next we dial into a static lab:
at OK atdt914085703932 NO CARRIER
The normal connection seems to be failing. In this case we know it's a noisy line, so let's put the modem to factory defaults (&F), turn on the speaker (m1), and cap the modem at 28.8 (S56=28800) with the following command:
at&fs56=28800 OK
Now we try the dial again:
atdt914085703932 CONNECT 28800/ARQ Welcome! Please login with username cisco, password cisco, and type the appropriate commands for your test: ppp - to start ppp slip - to start slip arap - to start arap access-3 line 29 MICA V.90 modems User Access Verification Username: cisco Password: access-3>
-
Ensure that data is flowing.
Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug, and replace as needed.
If entering data gets a reasonable response from the other side, the modem connection is working.
Common Problems
Debugging Session Establishment
At this point in the sequence, the modems are connected and trained up. Now it?s time to find out whether any traffic is coming across properly.
If the line receiving the call is configured with autoselect ppp and the async interface is configured with async mode interactive, use the command debug modem to verify the autoselect process. As traffic comes in over the async link, the access server will examine the traffic to determine whether the traffic is character-based or packet-based. Depending on the determination, the access server will then either start a PPP session or go no farther than having an exec session on the line.
A normal autoselect sequence with inbound PPP LCP packets:
*Mar 1 21:34:56.958: TTY1: DSR came up *Mar 1 21:34:56.962: tty1: Modem: IDLE->READY *Mar 1 21:34:56.970: TTY1: EXEC creation *Mar 1 21:34:56.978: TTY1: set timer type 10, 30 seconds *Mar 1 21:34:59.722: TTY1: Autoselect(2) sample 7E (See Note 1) *Mar 1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23 *Mar 1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate (See Note 2) *Mar 1 21:34:59.746: TTY1: EXEC creation *Mar 1 21:34:59.746: TTY1: create timer type 1, 600 seconds *Mar 1 21:34:59.794: TTY1: destroy timer type 1 (OK) *Mar 1 21:34:59.794: TTY1: destroy timer type 0 *Mar 1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up (See Note 3)
Note 1: The inbound traffic is displayed in hexadecimal format. This is based on the bits coming in over the line, regardless of whether the bits are ASCII characters or elements of a packet. The bits represented in this example are correct for an LCP packet. Anything different would be either a malformed packet or character traffic.
Note 2: Having determined that the inbound traffic is actually an LCP packet, the access server triggers the PPP negotiation process.
Note 3: The async interface changes state to up, and the PPP negotiation (not shown) commences.
If the call is a PPP session and if async mode dedicated is configured on the async interface, use the command debug ppp negotiation to see whether any configuration request packets are coming from the remote end. The debugs show these as CONFREQ. If you observe both inbound and outbound PPP packets, refer to Troubleshooting PPP. Otherwise, connect from the call-originating end with a character-mode (or "exec") session (that is, a non-PPP session).
Note: If the receiving end displays async modem dedicated under the async interface, an exec dial-in only shows what appears to be random ASCII garbage. To allow a terminal session and still have PPP capability, use the async interface configuration command async mode interactive. Under the associated line?s configuration, use the command autoselect ppp.
If the modems connect with a terminal session and no data comes across, check the following:
Table 4: Modem Cannot Send or Receive Data| Possible Causes | Suggested Actions |
|---|---|
| Modem speed setting is not locked |
|
| Hardware flow control not configured on local or remote modem or router |
|
| Misconfigured dialer map commands |
|
| Problem with dialing modem | Make sure that the dialing modem is operational and is securely connected to the correct port. Determine whether another modem works when connected to the same port. |
Debugging an incoming exec session generally falls into a few main categories:
-
Dialup client receives no exec prompt. Refer to Table 17-2.
-
Dialup session sees "garbage." Refer to Table 17-3.
-
Dialup opens in existing session. Refer to Table 17-4.
-
Dialup receiving modem does not disconnect properly. Refer to Table 17-5.
| Possible Causes | Suggested Actions |
|---|---|
| Autoselect is enabled on the line | Attempt to access exec mode by pressing Enter. |
| Line is configured with the no exec command |
|
| Flow control is not enabled. or Flow control is enabled only on one device (either DTE or DCE). or Flow control is misconfigured. |
|
| Modem speed setting is not locked |
Note: The lock DTE speed command, which might also be referred to as port rate adjust or buffered mode, is often related to the way in which the modem handles error correction. This command varies widely from one modem to another. Locking the modem speed ensures that the modem always communicates with the Cisco access server or router at the speed configured on the Cisco auxiliary port. If this command is not used, the modem reverts to the speed of the data link (the telephone line) instead of communicating at the speed configured on the access server. |
| Possible Causes | Suggested Actions |
|---|---|
| Modem speed setting is not locked |
Note: The lock DTE speed command, which might also be referred to as is port rate adjust or buffered mode , often related to the way in which the modem handles error correction. This command varies widely from one modem to another. Locking the modem speed ensures that the modem always communicates with the Cisco access server or router at the speed configured on the Cisco auxiliary port. If this command is not used, the modem reverts to the speed of the data link (the telephone line) instead of communicating at the speed configured on the access server. |
Symptom: Remote dialin session opens up in an already-existing session initiated by another user. That is, instead of getting a login prompt, a dialin user sees a session established by another user (which might be a UNIX command prompt, a text editor session, or any other ongoing exchange).
Table 7: Dialup Session Opens in Existing Session| Possible Causes | Suggested Actions |
|---|---|
| Modem configured for DCD always high |
|
| Modem control is not enabled on the access server or router |
Note: Be certain to use the modem inout command instead of the modem ri-is-cd command while the connectivity of the modem is in question. The latter command allows the line to accept incoming calls only. Outgoing calls will be refused, making it impossible to establish a telnet session with the modem to configure it. If you want to enable the modem ri-is-cd command, do so only after you are certain the modem is functioning correctly. |
| Incorrect cabling |
|
| Possible Causes | Suggested Actions |
|---|---|
| Modem is not sensing DTR | Enter the Hangup DTR modem command string. This command tells the modem to drop carrier when the DTR signal is no longer being received. On a Hayes-compatible modem the &D3 string is commonly used to configure Hangup DTR on the modem. For the exact syntax of this command, see the documentation for your modem. |
| Modem control is not enabled on the router or access server |
Note: Be certain to use the modem inout command instead of the modem dialin command while the connectivity of the modem is in question. The latter command allows the line to accept incoming calls only. Outgoing calls will be refused, making it impossible to establish a telnet session with the modem to configure it. If you want to enable the modem dialin command, do so only after you are certain the modem is functioning correctly. |
Cause Code Fields
Table 9 lists the ISDN cause code fields that display in the following format within the debug commands:
Table 9: ISDN Cause Code Fieldsi=0x y1 y2 z1 z2 [a1 a2]
| Field | Value Description |
|---|---|
| 0x | The values that follow are in hexadecimal. |
| y1 | 8--ITU-T standard coding. |
| y2 | 0--User 1--Private network serving local user 2--Public network serving local user 3--Transit network 4--Public network serving remote user 5--Private network serving remote user 7--International network A--Network beyond internetworking point |
| z1 | Class (the more significant hexadecimal number) of cause value. Refer to the next table for detailed information about possible values. |
| z2 | Value (the less significant hexadecimal number) of cause value. Refer to the next table for detailed information about possible values. |
| a1 | (Optional) Diagnostic field that is always 8. |
| a2 | (Optional) Diagnostic field that is one of the following values: 0--Unknown 1--Permanent 2--Transient |
ISDN Cause Values
Table 10 lists descriptions of some of the most commonly-seen cause values of the cause information element - the third and fourth bytes of the cause code.
Table 10: ISDN Cause Values| Value | Cause | Description |
|---|---|---|
| 81 | Unallocated (unassigned) number | The ISDN number was sent to the switch in the correct format; however, the number is not assigned to any destination equipment. |
| 90 | Normal call clearing | Normal call clearing has occurred. |
| 91 | User busy | The called system acknowledges the connection request but is unable to accept the call because all B channels are in use. |
| 92 | No user responding | The connection cannot be completed because the destination does not respond to the call. |
| 93 | No answer from user (user alerted) | The destination responds to the connection request but fails to complete the connection within the prescribed time. The problem is at the remote end of the connection. |
| 95 | Call rejected | The destination is capable of accepting the call but rejected it for an unknown reason. |
| 9C | Invalid number format | The connection could be not established because the destination address was presented in an unrecognizable format or because the destination address was incomplete. |
| 9F | Normal, unspecified | Reports the occurrence of a normal event when no standard cause applies. No action required. |
| A2 | No circuit/channel available | The connection cannot be established because no appropriate channel is available to take the call. |
| A6 | Network out of order | The destination cannot be reached because the network is not functioning correctly, and the condition might last for an extended period of time. An immediate reconnect attempt will probably be unsuccessful. |
| AC | Requested circuit/channel not available | The remote equipment cannot provide the requested channel for an unknown reason. This might be a temporary problem. |
| B2 | Requested facility not subscribed | The remote equipment supports the requested supplementary service by subscription only. This is frequently a reference to long-distance service. |
| B9 | Bearer capability not authorized | The user requested a bearer capability that the network provides, but the user is not authorized to use it. This might be a subscription problem. |
| D8 | Incompatible destination | Indicates that an attempt was made to connect to non-ISDN equipment, such as an analog line. |
| E0 | Mandatory information element is missing | The receiving equipment received a message that did not include one of the mandatory information elements. This is usually due to a D-channel error. If this error occurs systematically, report it to your ISDN service provider. |
| E4 | Invalid information element contents | The remote equipment received a message that includes invalid information in the information element. This is usually due to a D-channel error. |
For more complete information about ISDN codes and values, refer to the ISDN Switch Codes and Values chapter in the Cisco IOS Debug Command Reference for your version of IOS.
Related Information
- Cisco IOS Dial Services Quick Configuration Guide
- Cisco IOS Dial Services Configuration Guide: Network Services
- Cisco IOS Dial Services Configuration Guide: Terminal Services
- Cisco IOS Dial Services Command Reference
- Dial Case Study Overview
- Access Technology Pages
- Technical Support & Documentation - Cisco Systems
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
09-Jul-2007 |
Initial Release |
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)