Troubleshooting ISDN BRI Layer 3 Using the debug isdn q931 Command

Introduction

When troubleshooting ISDN call failure issues, it is important to keep in mind that the call could be failing due to any of the following:

• Dial-on-demand routing (DDR)

• ISDN Layers 1, 2 and 3

• Point-to-Point Protocol (PPP): including link control protocol (LCP), Authentication or IP Control Protocol (IPCP) related issues.

This document specifically focuses on ISDN related issues that cause call failures. This document also assumes that you have verified that ISDN Layers 1 and 2 on both ends of the circuit are functioning. Refer to Using the show isdn status Command for BRI Troubleshooting for more information on verifying ISDN Layer 1 and 2 status.

Prerequisites

Requirements

There are no specific requirements 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.

Conventions

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

Troubleshooting Prerequisites: Activating ISDN Layer 3 debugs

Use the command debug isdn q931 on both ends to activate ISDN Layer 3 debugs. You should also have millisecond timestamps for debugs enabled on both routers. The timestamps are necessary to provide relative input to the troubleshooting process.

Note: Activate millisecond timestamps for debugs using the following commands:

maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec

For more information on debug commands refer to Important Information on Debug Commands.

Initiate the ISDN Call

Generate an ICMP ping to the remote router IP address. This should initiate an ISDN call to that router. Both routers will generate debug isdn q931 messages.

There can be many variations in the Q.931 exchanges due to specific requirements for ISDN switch types or in cases where additional parameters are required. The following diagram illustrates common Q.931 transactions during a successful ISDN call setup.

Note: Some of the following debug output lines are broken into multiple lines for printing purposes.

maui-soho-01#
18:39:29.425: ISDN BR0: TX -> SETUP
    pd = 8  callref = 0x10

!-- The Calling Router Transmits !-- (indicated by TX) the SETUP message

18:39:29.433:
         Bearer Capability i = 0x8890
18:39:29.441: Channel ID i = 0x83
18:39:29.449:
         Keypad Facility i = '5558888'
18:39:29.822: ISDN BR0: RX <- CALL_PROC
    pd = 8  callref = 0x90

!-- The telco switch responds with a !-- Call Proceeding. This indicates the !-- network is processing the call.

18:39:29.830:
         Channel ID i = 0x89
.
.
.

!-- Nothing has been omitted here. The !-- dots were put in place to align !-- the Called and Calling Routers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18:39:30.000: ISDN BR0: RX <- CONNECT
    pd = 8  callref = 0x90

!-- Received a CONNECT from the remote !-- router. The ISDN connection has been !-- established. Any failures of the call !-- past this point are due to higher !-- level issues such as DDR, PPP, !-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK
    pd = 8  callref = 0x10

!--- The Router responds with a Connect !--- Acknowledgment (CONNECT_ACK) !--- to the telco.

maui-nas-08#
18:39:29.647: ISDN BR2/0: RX <- SETUP
    pd = 8  callref = 0x08

!-- The Called Router receives !-- (indicated by RX) a SETUP message !-- from the switch

18:39:29.647:
    Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital. 

18:39:29.647: Channel ID i = 0x89
18:39:29.647:
    Signal i = 0x40 - Alerting on -
    pattern 0 
18:39:29.647:
    Called Party Number i = 0xC1,'5558888',
    Plan:ISDN, Type:Subscriber(local)
18:39:29.647:
    Locking Shift to Codeset 5
18:39:29.647:
    Codeset 5 IE 0x2A  
    i = 0x808001038001118001, '<'
18:39:29.651:
    ISDN BR2/0: Event: Received a DATA 
    call from  on B1 at 64 Kb/s
18:39:29.651: ISDN BR2/0: TX -> CALL_PROC
    pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding
 
18:39:29.655:
         Channel ID i = 0x89
18:39:29.655: %LINK-3-UPDOWN:
 Interface BRI2/0:1, changed state to up
18:39:29.955: ISDN BR2/0: TX -> CONNECT
    pd = 8  callref = 0x88

!--- Call is accepted and the routers sends !--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89
18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK
    pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK !--- from the switch

18:39:29.995:
         Channel ID i = 0x89
18:39:29.995:
         Signal i = 0x4F - Alerting off 
18:39:35.655: %ISDN-6-CONNECT:
 Interface BRI2/0:1 is now
 connected to unknown 

When evaluating the debug isdn q931 output on the calling and called ends, keep the following points in mind:

• Pay attention to the direction of the messages. The debugs indicate whether the messages were generated by the router (indicated by TX ->) or if they were received by the router (indicated by RX <--). In the example below, the first message (CONNECT) is received by the router from the ISDN Switch, while the second (CONNECT_ACK) is sent by the router:

  18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90
  18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10
  
  

  You can identify the source of the problem by following the direction of a particular message and the response. For example, if the router unexpectedly receives a RELEASE message from the telco ISDN switch, then it will reset its end of the connection as well. This indicates that the issue lies with the telco ISDN switch or the remote router

• Verify that the message received or sent is the expected one. For example, if the called party receives a SETUP message but sends a DISCONNECT instead of a CONNECT, then troubleshoot the Called Router and not the ISDN network. The following table has a list of possible Q.931 messages seen during call establishment and teardown:

Troubleshooting Overview: Symptom and Resolution Procedure

Analyze the debug isdn q931 output as described in the previous sections, and proceed to the appropriate symptom discussed below.

Note: In this document, the router that initiates the call is referred to as the Calling Router, while the router that accepts the call is referred to as the Called Router.

Troubleshooting: Symptom and Detailed Resolution Procedure

The Calling Router does not send a SETUP message

If the Calling Router does not send a SETUP message to the ISDN network, the problem is likely related to ISDN layers 1, 2 or Dial-on-Demand Routing (DDR) issues, and is not layer 3 related

Perform the following tasks on the Calling Router:

• Verify that the ISDN switchtype is correctly configured:

  The ISDN switchtype can be verified using the command show isdn status . The telco should explicitly indicate the switchtype that needs to be configured. Occasionally (especially in North America) the telco may indicate the switchtype is "custom" or "national". In such cases, use the following guidelines to determine the switchtype configuration:

  • Custom: If the telco indicates that their switch-type is Custom, then configure the switchtype on the router as basic-5ess (for BRI with 5ess switch), primary-5ess (for PRI with 5ess), basic-dms (for BRI with DMS switch), or primary-dms (for PRI with DMS).

  • National: Switchtype conforming to the NI-1 standard for BRI and NI-2 standard for PRI (there is no NI-1 standard for PRIs) . If the telco informs you that the switchtype is National, then the Cisco router configuration should be basic-ni (for BRI) or primary-ni (for PRI).

  To configure the switchtype use the command isdn switch-type switch-type in the BRI interface configuration mode. For an example refer to Troubleshooting ISDN BRI Layer 1

• Verify that the ISDN Layers 1 and 2 on the Calling Router are functioning:

  You can verify that ISDN Layers 1 and 2 are up using the command show isdn status. Use the procedure outlined in to troubleshoot ISDN Layer 1 and 2 related issues.

• Use the show ip route command to verify that the the router has a route to the destination.

  The show ip route command will indicate whether there is a route to the remote router network. If the route does not exist, use the ip route command to add a static route for the remote network. Make sure the route points to the correct interface on the Calling Router.

  In a legacy DDR environment (for example, dialer maps) the next hop should be either the physical interface network (interface BRI x ) or the remote router IP address (which should also have been configured in the dialer map statement).

  With Dialer Profiles, the next hop is usually the interface Dialer x used for the dialout. For example,

  maui-soho-01#show ip route
  ...
  ...
  !-- Output omitted
  
  ...
  
       10.0.0.0/24 is subnetted, 1 subnets
  C       10.0.0.0 is directly connected, Ethernet0
  S*   0.0.0.0/0 is directly connected, Dialer1
  

  In the example above, note that the default route next hop is interface Dialer 1 (the logical dialer interface for this connection).

• Verify that the interesting traffic is correctly identified.

  The router checks to verify that an incoming packet is interesting traffic before initiating the dial. Hence, the router may not dial if the interesting traffic is incorrectly defined, or if the dialer-list number (the interesting traffic definition) is not applied to the physical or dialer interface (using the dialer-group number command). For example, if you are using an ICMP ping to initiate the DDR connection, verify that the ICMP is permitted in the interesting traffic definition.

  Refer to Configuring BRI-to-BRI Dialup with DDR Dialer Maps for more information.

• Check whether the appropriate dialer string (or dialer map) includes the remote device's ISDN number.

  The dialer string (or dialer map) must include the remote router's ISDN number. For example,

  dialer string 5551111
  or
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  

• Check the DDR configuration and use debug dialer to verify that the router is initiating the call:

  Verify that the DDR configuration is correct. Use the document Dialup Technology: Overviews and Explanations for further assistance on the correct DDR configuration.

  You should also use the command debug dialer to verify that the router receives interesting traffic and has the appropriate dialer map or dialer string to initiate the dial. Refer to the document above as well as Dialup Technology: Troubleshooting Techniques for more information.

  Refer to the following sample configuration for examples of proper DDR configuration:

  Dialer Profiles: Configuring ISDN DDR with Dialer Profiles Legacy DDR(Dialer Maps): Configuring BRI-to-BRI Dialup with DDR Dialer Maps

  Tip: For testing purposes, you can eliminate DDR by using the isdn call command (explained in the next section) to generate an ISDN call to the remote device. If that call succeeds then you can be reasonably sure that the ISDN circuit is functioning. Continue troubleshooting DDR.

• Perform a loopback test call

  In a loopback call, the router dials the ISDN number of its own BRI. The call proceeds to the telco cloud, where the telco switches the call to the second BRI channel. This call is now seen by the router as an incoming call on the second channel. Therefore, the router both sends and receives the ISDN call.

  A loopback call tests the ability of the router to initiate and terminate an ISDN call. A successful loopback call gives you a strong indication that the ISDN circuit to the telco cloud is functioning correctly.

  The following is an annotated example of a successful loopback call. The command isdn call (introduced in Cisco IOS® software 12.0(3)T) enables outgoing isdn calls without requiring the DDR requirements such as interesting traffic and routes. This command can only be used for testing of the ISDN circuit and cannot be used to pass traffic or as a substitution for a proper DDR configuration. This command allows us to verify that the ISDN circuit, especially Layer 3, is functioning.

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: 
Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: 
Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful

Notes:

• During the loopback call, the router performs as both the Called Router as well as the Calling Router (albeit on different B-channels). It is important that you keep track of these "dual roles" when interpreting the debug isdn q931 output. For example, the router transmits a setup message (TX -> SETUP) and receives one as well (RX <- SETUP). The transmitted SETUP should be associated with the outgoing call while the received SETUP message is associated with the incoming call.

• In the above example, we dialed the number for the first B-channel. However, the telco recognizing that the first B-channel was busy (since it was making the call), switched the call to the second B-channel and the connection was completed successfully. However, a misconfiguration in the telco switch can result in a failure of the loopback call, due to the switch trying to assign the call to the first channel (which is busy making the call). The telco should correct this problem. However, as a workaround solution specify the second B-channel number in the command isdn call.

• If the loopback call succeeds and the call to the remote end continues to fail, contact the telco for further troubleshooting assistance with your BRI circuit.

The Called Router does not receive a SETUP message

If you determine that the Calling Router sends an ISDN Layer 3 SETUP message, but that the Called Router does not receive it, then the issue could be with ISDN layers 1 and 2 on the Called Router or it could be a problem with the telco ISDN cloud.

Perform the following tasks on the Called Router:

• Verify that the ISDN switchtype is correctly configured:

  The ISDN switchtype can be verified using the command show isdn status . The telco should explicitly indicate the switchtype that needs to be configured. Occasionally (especially in North America) the telco may indicate the switchtype is "custom" or "national". In such cases, use the following guidelines to determine the switchtype configuration:

  • Custom: If the telco indicates that their switch-type is Custom, then configure the switchtype on the router as basic-5ess (for BRI with 5ess switch), primary-5ess (for PRI with 5ess), basic-dms(for BRI with DMS switch), or primary-dms (for PRI with DMS).

  • National: Switchtype conforming to the NI-1 standard for BRI and NI-2 standard for PRI (there is no NI-1 standard for PRIs) . If the telco informs you that the switchtype is National, then the Cisco router configuration should be basic-ni (for BRI) or primary-ni (for PRI).

  To configure the switchtype use the command isdn switch-type switch type in BRI interface configuration mode. For an example refer to Troubleshooting ISDN BRI Layer 1

• Verify that the ISDN Layers 1 and 2 on the Calling Router are functioning:

  You can verify that ISDN Layers 1 and 2 are up using the command show isdn status. Use the procedure outlined in Using the show isdn status Command for BRI Troubleshooting to troubleshoot ISDN Layer 1 and 2 related issues.

• Verify that the SPID Local Directory Number (LDN) is correctly configured

  Certain switchtypes require that the spid and ldn are correctly configured in order to accept incoming calls. Refer to Troubleshooting ISDN BRI SPIDs for more information.

Perform the following tasks on the Calling Router:

• Use a regular analog phone to make a test call to the remote router.

  Using a regular analog phone, dial the ISDN number of the Called Router exactly as it is configured on the Calling Router. The Called Router should receive a SETUP message (though the call will later fail since it is not an ISDN call). If the Called Router receives the SETUP message then we can assume that the Called side ISDN network is functioning. The issue could be with the local side ISDN network, the destination ISDN number, the Long distance service, so forth and so on. Proceed using the steps below.

• Ensure that the destination ISDN number is configured correctly:

  Check the Calling Router configuration and verify that the ISDN number configured for the remote router is correct. Very often ISDN circuits behind a PBX require a 9 preceding the ISDN number. Also, if the call is long distance (in the US), then you should include the digit 1 before the remote site ISDN number (similar to normal phone long distance dialing) . For example, consider a situation where the local site is behind a PBX and the call to the remote site needs to be a long distance call. The remote end ISDN number is 5551111 within area code 512. In this case, including the appropriate digits for the PBX and long distance, the number dialed is 915125551111.

  The debug isdn q931 disconnect reason can also be used to determine whether the call failure is due to, an incorrect remote ISDN number or due to an improperly formatted number. Refer to the document Understanding debug isdn q931 Disconnect Cause Codes for more information on interpreting ISDN q931 disconnect cause codes.

  A disconnect due to an incorrect ISDN number may be indicated with:

  Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85
  Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination
  

  Referring to the Disconnect Cause codes document referenced previously, we can determine that the disconnect code was caused by an attempt to connect to a non-ISDN equipment. (For example, an analog line.).

  A disconnect due to an improperly formatted number may be indicated with:

  Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
  Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format 
  (incomplete number)
  

  Referring to the document Understanding debug isdn q931 Disconnect Cause Codes , we can determine that the disconnect code was caused by an invalid format for the remote ISDN number. The connection fails because the destination address is presented (to the switch) in an unrecognizable format, or the destination address is incomplete.

• If applicable, determine whether the Long Distance service is active:

  You should contact your local telco and long distance provider to verify that the service is activated. Often, the local telco has the ISDN circuit misconfigured such that outbound ISDN long distance calls are not switched over to the appropriate long distance provider network. You should also verify that the long distance providers network is functioning.

  In the US and in situations where the telco/long distance provider is unable to rectify the problem, you may wish to use a Presubscribed Interexchange Carrier (PIC). PIC codes are 7-digit prefixes which identify US long distance carriers to the local exchange carriers (LEC). This allows customers to use different long-distance carriers for separate calls. The PIC code is configured as a prefix to the dialed number. Most PICs are of the format 1010xxx. For a numerical listing of PICs refer to US PIC codes, Numerically

• Configure two dialer map or two dialer string statements; one for each remote B-channel's ISDN number:

  Configuring a dialer map (or a dialer string, if using dialer profiles) for each remote B-channel allows the connection to proceed even if the telco is not capable of switching the second call to the second ISDN B-channel.

  Note: This workaround is required if only 1 B-channel is accepting calls on a given BRI. This issue is often seen with multilink connections.

  A sample configuration (using dialer maps) is provided:

  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112
  
  !--- dialer map statements for the remote router !--- The two different phone numbers correspond !--- to the b-channels of the remote side. The multiple statements allow !--- the router to dial the second number if the first number is busy. 
  
  

The Called Router does not send a CONNECT message

If the Called Router receives a SETUP message but does not respond with a CONNECT message, then this could indicate that the router (for some undetermined reason) choose not to accept the call.

Perform the following tasks on the Called Router:

• Check if the call is rejected due to Caller ID/DNIS based screening:

  Caller ID or DNIS based screening permits the router to selectively accept or deny a particular calls without incurring toll charges. With Caller ID based screening, the Called Router receives (in the SETUP message) the number of the Calling Party. This allows the router to permit calls from certain numbers thus providing some security. With DNIS based screening the Called Router discriminates incoming calls based on the number dialed.

  There are a couple of main points to remember regarding CLID/DNIS based screening:

  1) The telco must provide the appropriate CLID/DNIS information in the SETUP message. If you enable Caller ID screening on the router, but do not have Caller ID digits being passed to the router, then all calls to the router will be "screened" and no calls will be accepted.

  2) Check the format of the CLID/DNIS digits delivered by the telco (in the debug isdn q931 output). For example, some telcos include the area code in the delivered CLID/DNIS digits, while others do not. Correct any CLID/DNIS configuration as appropriate.

  The following is an example of a failed call. The router has CLID based screening enabled, however, since the telco does not deliver the CLID digits the router rejects the call.

  maui-nas-08#
  05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E
  
  ! --- The router receives (RX) a SETUP message
  
  05:46:33:         Bearer Capability i = 0x8890
  05:46:33:         Channel ID i = 0x89
  05:46:33:         Signal i = 0x40 - Alerting on - pattern 0 
  05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,
    Type:Subscriber(local)
  
  ! --- The Called Number (DNIS) is delivered to the router ! --- Note that CLID information is not delivered
  
  05:46:33:         Locking Shift to Codeset 5
  05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
  05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE
  05:46:33:         Cause i = 0x8095 - Call rejected
  
  ! --- Calls is Rejected due to screening
  
  

  For more information on Caller ID refer to the document ISDN Authentication and Callback with Caller ID

• Verify that the SPIDs are correct:

  Use the show isdn status command to verify that the SPIDs on the Called Router is correct. Refer to Using the show isdn status Command for BRI Troubleshooting for further information on troubleshooting Spid related Issues.

• Ensure that there are available B-channels on the circuit that was dialed:

  Use the show isdn status command to check if there are any available channels on the circuit that was dialed. If there are no available channels use the clear command to free up some channels.

• If multiple BRIs are available, have the telco configure them in a hunt group:

  Having multiple BRIs in a hunt group allows for the telco to switch the call to any free BRI circuit on that router. Contact the telco for this feature.

• Check whether you are encountering bearer capability related issues:

  The Bearer Capability (or bearer cap) is the layer 3 service indication which defines the characteristics of a given call. The Bearer Cap of a call is indicated by the telco in the Q.931 SETUP messages. The Bearer cap is often used to distinguish among 64k voice (analog), 56k data calls and 64k data calls. The most commonly seen bearer cap messages and their descriptions are provided below:

  Bearer Cap	Description
  0x8890	ISDN 64K call
  0x8890218F	ISDN 56K call
  0x8090A2	Voice/Speech call (u-law)
  0x9090A2	Voice/Speech call (u-law) - 3.1 kHz Audio
  0x8090A3	Voice/Speech call (A-law)
  0x9090A3	Voice/Speech call (A-law) - 3.1 kHz Audio

  The following is an example of a ISDN 64k call:

  Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F
  
  !-- Incoming SETUP messages
  
  Aug  8 18:49:48.246:         Bearer Capability i = 0x8890
  
  !-- The bearer cap indicates the incoming call is ISDN 64k
  
  Aug  8 18:49:48.246:         Channel ID i = 0x89......
  

  Follow the steps below depending on the bearer cap of the call:

  Bearer Capability is 0x8890218F: The call is ISDN 56K digital :

  • Verify that the ISDN switchtype is correctly configured:

    The ISDN switchtype can be verified using the command show isdn status . The telco should explicitly indicate the switchtype that needs to be configured. Occasionally (especially in North America) the telco may indicate the switchtype is "custom" or "national". In such cases, use the following guidelines to determine the switchtype configuration:

    • Custom: If the telco indicates that their switch-type is Custom, then configure the switchtype on the router as basic-5ess (for BRI with 5ess switch), primary-5ess (for PRI with 5ess), basic-dms(for BRI with DMS switch), or primary-dms (for PRI with DMS).

    • National: Switchtype conforming to the NI-1 standard for BRI and NI-2 standard for PRI (there is no NI-1 standard for PRIs) . If the telco informs you that the switchtype is National, then the Cisco router configuration should be basic-ni (for BRI) or primary-ni (for PRI).

    To configure the switchtype use the command isdn switch-type switch type in BRI interface configuration mode. For an example refer to Troubleshooting ISDN BRI Layer 1

  • On the dialing side, verify that the speed/rate of the call is 56k. This is necessary because some legacy ISDN switches may not be passing clear channel and may force you to make your call at 56K to get through.

    Use the speed parameter on the dialer map configuration command to make outgoing calls at 56 Kbps as shown in the following example:

    maui-soho-01(config)#interface bri 0
    maui-soho-01(config-if)#dialer map ip 10.1.1.1 name 
    Maui-NAS-08 speed 56 5551111
    
    !-- The keyword speed 56 sets the outgoing call rate at 56k
    
    

    The following example illustrates how to configure a Cisco IOS dialer profile to make outgoing calls at 56 Kbps:

    maui-soho-01(config)#interface dialer 1
    maui-soho-01(config-if)#dialer string 5558888 class 56k     
    
    !-- Use the map-class named "56k" when dialing number 5558888 
               
    maui-soho-01(config-if)#exit
    maui-soho-01(config)#map-class dialer 56k
    
    !-- map-class named "56k" that was used with the dialer string above
    
    maui-soho-01(config-map-clas)#dialer isdn speed 56
    
    !-- Set the speed of the call to be 56k (default is 64k)
    
    

  • On the receiving side, configure the command isdn not-end-to-end 56 under the BRI interface.

    Maui-NAS-08(config)#interface bri 2/0
    Maui-NAS-08(config-if)#isdn not-end-to-end 56
    

    The ISDN Q.931 bearer capability and other Information Element (IE)s are used to determine the speed of the incoming call and in most circumstances will operate properly. However, in some country-to-country applications (or due to some legacy switches), the incoming call setup message will be delivered with a bearer capability that does not match the originating call. If a message indicating isdn 'not end-to-end' is received, the router can override the received bearer capability using the Cisco IOS configuration command isdn not end-to-end.

    Bearer Capability is 0x8090A2 or 0x9090A2: Voice/Speech call (u-law)

    Bearer Capability is 0x8090A3 or 0x9090A3: Voice/Speech call (A-law)

    The incoming call is a 64k Analog Call. For modem applications the call will be sent to the internal modems, while for voice applications the call may be sent to the appropriate voice module. Perform the following steps:

    1. On the receiving side, verify that the ISDN physical interface (for example, interface bri 0) has isdn incoming-voice modem configured.

    2. Verify that the modem lines have the command modem inout.

    For an example configuration refer to the document Configuring Modem Connectivity with a Cisco 3640 BRI

  • Interpret the disconnect cause code sent (from the Called Router to the Calling Router) in the DISCONNECT or RELEASE message

    If the Called Router does not send a CONNECT message to the Calling Router, it should send back either a DISCONNECT or RELEASE message. This DISCONNECT or RELEASE message should also include a Disconnect cause code. In the example below, the Disconnect cause code is 0x8090. Refer to the document Understanding debug isdn q931 Disconnect Cause Codes to interpret the disconnect code.

    Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8  
    callref = 0x06
    Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing
    

The Calling Router does not receive a CONNECT message

If the Called Router sends a CONNECT message, but that message is not received by the Calling Router, then the issue most likely lies with the telco.

• Determine whether the router receives a CONNECT_ACK from the local ISDN switch:

  This indicates the the telco switch near the Called Router accepted the CONNECT message and is passing the CONNECT message to the Calling Router. A failure of the call is likely a telco issue.

• Contact the telco for further troubleshooting.

The Calling Router receives a CONNECT but the call still fails

If the Calling Router receives a CONNECT message, that indicates that the ISDN connection is active and functioning correctly. Contact the telco to determine if there is a problem with the B-Channel not being properly mapped across for data. Any failure of the call, past this stage, is due to a higher layer issue such as with PPP, Authentication or IPCP/IP Address negotiation. Use debug ppp negotiation for further ppp troubleshooting.

You should also consult the document Dialup Technology: Troubleshooting Techniques for further PPP troubleshooting techniques.

Related Information

• Access Technology Support Page
• Technical Support - Cisco Systems