From: CHRIS HUGO (chrishugo@xxxxxxxxx)
Date: Fri Feb 15 2002 - 14:55:20 GMT-3
I had this problem before. Reset your isdn simulator this should fix it. But fi
rst do a "debug isdn q931" on both routers. On one router you will probaly see
a cause code for the dissconnect.
heres a snippet on how to proceed on the debug process.
For outbound ISDN calls, debug isdn q931 and debug isdn events are the best too
ls to use. Fortunately, debugging outbound calls is very similar to debugging i
ncoming 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 = 0x
83*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.14
5: Channel ID i = 0x89*Mar 20 21:07:45.157: ISDN BR0: received HOST_PRO
CEEDING 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_CONNECT
Note 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") m
essage 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 from where in the end-to-end call path the DISCONNECT or RELEASE_COM
P was received. This can help you to localize the problem. The third and fourth
bytes indicate the actual reason for the failure. See the tables that follow f
or the meanings of the different values.
The rest of this great article can be foun on Cisco's website:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1917.htm#xtocid204721
5
let me know if this helps,
chris hugo
"Steven M. Sowell" <ssowell@gate.net> a icrit : A good place to start with an
y ISDN BRI troubleshooting scenario is "show
isdn stat". It shows fundamental ISDN information in a clear format.
In the output below, "Layer 1 status" is Active. Often the source of your
problem is that Layer 1 is inactive, which is basically the physical cabling
(and proper configuration of the Telco switch/ISDN simulator) It is
typically a bad cable, bad/misconfigured switch, or you forgot to do a "no
shut" on your interface.
Once Layer 1 is ACTIVE, verify that, under Layer 2, you have "spid1 valid
spid2 valid". If it says "spid1 is invalid" you have fat-fingered your
SPIDS. Often, when you correct the invalid spids on your router they still
show up as invalid. You should do a "clear int bri0/0" or "shut/no shut" on
the BRI interface to activate the new spids. Some IOS/platforms prefer the
former, some the latter, and sometimes you have to do it a couple of times.
Familiarity with the output of "debug isdn q921" and "debug isdn q931", and
"debug ppp ????" are also vital to effective ISDN troubleshooting.
R2#sh isdn stat
Global ISDN Switchtype = basic-ni
ISDN BRI0/0 interface
dsl 0, interface ISDN Switchtype = basic-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 65, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI 64, ces = 1, state = 5(init)
spid1 configured, no LDN, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 70, tid = 1
TEI 65, ces = 2, state = 5(init)
spid2 configured, no LDN, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 70, tid = 2
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Number of L2 Discards = 0, L2 Session ID = 0
Total Allocated ISDN CCBs = 0
Steven Sowell
CCIE#7317
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of Lupi,
Guy
Sent: Friday, February 15, 2002 10:26 AM
To: 'Kang BS'; ccielab@groupstudy.com
Subject: RE: Trouble on ISDN
I would check the physical connection to the simulator or ISDN line, this
happened to me last night and that is what it was. I believe that this
means that the router does not see the ISDN carrier signal from the line or
simulator.
~-----Original Message-----
~From: Kang BS [mailto:avantus1@hotmail.com]
~Sent: Friday, February 15, 2002 9:55 AM
~To: ccielab@groupstudy.com
~Subject: Trouble on ISDN
~
~
~Hi, all
~
~
~When I call to the other side of router thru BRI interface,
~"wait for isdn carrier timeout" message come out.
~
~Could you anyone explain on what the message mean and What should I do?
~
~Thanks in advance.
~
~BS Kang
~
~
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:24 GMT-3