ISDN Layer

ISDN Layer 3 is about signaling between the TE and the ISDN switch (ET). The ISDN Layer 3 signaling specifications are provided by ITU-T I.450 (also known as ITU-T Q.930) and ITU-T I.451 (also known as ITU-T Q.931). Although the purpose of Layer 3 signaling is to establish an end-to-end circuit, the signaling itself is not a user-to-user process; it operates over the D channel between the terminal and the switch (TE and ET). Signaling essentially facilitates call establishment and call termination, and exchange of information and messages. ISDN Q.931 messages include CALL SETUP, CALL PROCEEDING, CONNECT, CONNECT ACK, DISCONNECT, RELEASE, RELEASE COMPLETE, INFORMATION, CANCEL, STATUS, and so on (see Figure 11-5).

It is best if you save your ISDN Layer 3 troubleshooting effort for after you have fixed all the Layer 2 issues and Layer 2 has become active. Call setup can fail for any of the following reasons:

• The ISDN switch type is not configured, or it is configured incorrectly, on either the caller's or the called party's side (or both!).

• The called party has no B channel free to accept an incoming call (i.e., the called party is busy).

• Due to some form of call screening (based on called number or the calling party's number), the called party rejects the call.

Figure 11-5 ISDN Call Setup and Teardown

Calling TE

Figure 11-5 ISDN Call Setup and Teardown

(5) Connect

(6) Connect Ack

(5) Connect

(6) Connect Ack

(8) Disconnect

(12) Release Complete

Called TE

(4) Connect (7) Connect Ack

(9) Disconnect

(4) Connect (7) Connect Ack

(9) Disconnect

(10) Release

(13) Release Complete

Many ISDN switch manufacturers developed products before the Q.931 specifications were completed. These products differ in the way they interpret the Layer 3 (signaling) frames. It is crucial that you specify/configure the switch type precisely and double-check with your service provider to make sure that it is indeed the type of switch to which your router is connected. Prior to version 12 of Cisco IOS, the ISDN switch type was only a global configuration command; as of version 12.0, the switch type can be configured separately for each interface. Some of the ISDN (BRI) switch types that are supported by Cisco IOS are listed in Table 11-3.

Table 11-3 ISDN (BRI) Switch Types (Cisco-Supported)

Type

Description

basic-1tr6

1TR6 switch type for Germany

basic-5ess

AT&T 5ESS switch type for the U.S.

basic-dms100

Northern DMS-100 switch type

basic-net3

NET3 switch type for U.K. and Europe

basic-nil

National ISDN-1 switch type

basic-nwnet3

NET3 switch type for Norway

basic-nznet3

NET3 switch type for New Zealand

Table 11-3 ISDN (BRI) Switch Types (Cisco-Supported) (Continued)

Type

Description

basic-ts013

TS013 switch type for Australia

ntt

NTT switch type for Japan

vn2

VN2 switch type for France

vn3

VN3 and VN4 switch types for France

The ISDN switch type is configured using the following command in global configuration mode:

isdn switch-type switch-type

As of Release 12.0 of Cisco IOS, however, each individual BRI interface may be individually configured with an ISDN switch type using the same command syntax in interface configuration mode.

To find out the switch type configured on your router, you may look at your router's running configuration (using the show running-config command). The simpler option you have is to issue the show isdn status command, which also displays the ISDN switch type your router is configured for. Remember that if you change the ISDN switch type on your router, the change will not take effect until you reload your router.

One effective method for troubleshooting ISDN Layer 3 is through usage of the debug isdn q931 command. A sample output of this debug during call setup is shown in Example 11-11. The top portion of Example 11-11 shows the output for the calling router and the bottom portion shows the output for the called router.

Example 11-11 Sample Outputs of the debug isdn q931 Command

B_BackR#debug isdn q931

ISDN

Q931 packets debugging is on

ISDN

BR0: TX -> SETUP pd = 8 callref = 0x14

Bearer Capability i = 0x8890

Channel ID i = 0x83

Keypad Facility i = '5552001'

ISDN

BR0: RX <- CALL_PROC pd = 8 callref = 0x94

Channel ID i = 0x89

ISDN

BR0: RX <- CONNECT pd = 8 callref = 0x94

ISDN

BR0: TX -> CONNECT_ACK pd = 8 callref = 0x14

%LINK-3-UPDOWN: Interface BRI0:1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1

, changed

state to up

%ISDN-6-CONNECT: Interface BRI0:1 is now connected to

5552001 A_

BackR

ISDN

BR0: RX <- SETUP pd = 8 callref = 0x28

Bearer Capability i = 0x8890

Channel ID i = 0x89

Example 11-11 Sample Outputs of the debug isdn q931 Command (Continued)

Called Party Number i = 0xC1, '5552001' ISDN BR0: TX -> CONNECT pd = 8 callref = 0xA8 ISDN BR0: RX <- CONNECT_ACK pd = 8 callref = 0x28

%LINK-3-UPDOWN: Interface BRI0:1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5552002B Back

When reading the output of the debug isdn q931 command, you must pay attention to the callref (call reference) number that is used on the messages that are sent back and forth between the router and the ISDN switch. This will allow you to analyze the distinct conversations that are occurring between the router and the switch regarding different calls. The callref is an 8-bit field (2 hex digits—0x14) and its left most bit is a flag bit that indicates the flow direction of the message. The flag bit on the call ref of messages that go from the router to the switch are 0, and the flag is set to 1 when the switch sends a message to the router. For instance, in Example 11-11 (the top portion), when the router transmits (TX) a setup for the number 5552001 to the switch, it gives it a call ref number of 0x14. When the switch responds to the router regarding callref 0x14, the switch flips the leftmost bit of the callref from 0 to 1, resulting in callref 0x94.

The output of the debug isdn q931 command can help you find out the reason for a call setup failure. The top portion of Example 11-12 shows a case in which the call made by the local router was rejected. Notice that below the Release message the cause information (cause i) is shown to be =0x8295, which is also stated in words as Call rejected. The reason for a call rejection could be any of the following:

• Remote router's call screening

• Remote router is out of channels (has no B channel available)

• Bad SPID number configuration

Example 11-12 Determining Call Rejected and Call Release Causes

B_BackR#debug isdn q931

ISDN Q931 packets debugging is on

ISDN BR0: TX -> SETUP pd = 8 callref = 0x18 Bearer Capability i = 0x8890 Channel ID i = 0x83 Keypad Facility i = '5552001' ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x98

Channel ID i = 0x89 ISDN BR0: RX <- RELEASE pd = 8 callref = 0x98

Cause i = 0x8295 - Call rejected ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0x18

B_BackR#

ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x9D

Example 11-12 Determining Call Rejected and Call Release Causes (Continued)

Cause i = 0x8290 - Normal call clearing %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 5552001 A_BackR, call lasted 17 seconds

%LINK-3-UPDOWN: Interface BRI0:1, changed state to down ISDN BR0: TX -> RELEASE pd = 8 callref = 0x1D Cause i = 0x8090 - Normal call clearing ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x9D B_BackR#

%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down B_BackR#

On the bottom portion of Example 11-12, another capture of the debug isdn q931 command's output is shown. In that case, a DISCONNECT message is received by the router and the cause information is stated to be =0x8290, which is also stated in words as Normal call clearing. The router replies with a RELEASE message (causei=0x8090) and it restates the cause as Normal call clearing.

Was this article helpful?

0 0

Responses

  • tiziano
    How to resolve isdn layer 3 issues in cisco?
    8 months ago

Post a comment