10-07-2009 08:30 AM - edited 03-04-2019 06:17 AM
Hi
I have been trying to connect ISDN BRI to one of my Aggregation Router having PRI installed but am facing problem
ISDN Q921 is OK but when checking for ISDN Q931 debug it gives o/p as follows
JAM-BBI-R01#p 172.X.X.X
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.235.170, timeout is 2 seconds:
*Mar 17 00:37:43.484: ISDN BR0/0 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Called num 019XXXXXXX
*Mar 17 00:37:43.484: ISDN BR0/0 Q931: TX -> SETUP pd = 8 callref = 0x15
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x81
Called Party Number i = 0x80, '0191XXXXXXX'
Plan:Unknown, Type:Unknown
*Mar 17 00:37:43.953: ISDN BR0/0 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x95
Cause i = 0x0280BF - Service/option not available, unspecified
Display i = 'ISOLATE CONF SUCCESS'.
*Mar 17 00:37:43.961: ISDN BR0/0 **ERROR**: host_disconnect_ack: Unfound B-channel on Disconnect_Ack call id 0x8095....
Success rate is 0 percent (0/5)
Debug dialer gives O/P
AM-BBI-R01#p 172.17.235.170
*Mar 17 00:49:42.900: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0/0, TEI 68 changed to down
JAM-BBI-R01#p 172.17.235.170
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.235.170, timeout is 2 seconds:
*Mar 17 00:49:43.473: BRI0/0: wait for isdn carrier timeout, call id=0x80A2
*Mar 17 00:49:43.473: DDR: Dialing failed, 5 packets unqueued and discarded
*Mar 17 00:49:44.635: BR0/0 DDR: place call
*Mar 17 00:49:44.635: BR0/0 DDR: Dialing cause ip (s=172.X.X.X, d=172.XXXX)
*Mar 17 00:49:44.635: BR0/0 DDR: Attempting to dial 019XXXXXX.
*Mar 17 00:49:47.283: BRI0/0: wait for isdn carrier timeout, call id=0x80A3.
*Mar 17 00:49:48.477: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/0, TEI 69 changed to up.
*Mar 17 00:49:50.284: BR0/0 DDR: Attempting to dial 019XXXXXXXX..
Success rate is 0 percent (0/5)
BRI Configuartion on access location is as follows
interface b0/0
IP address X.X.X.X 255.255.255.252
dialer map IP XXXXX name DDD broadcast 019XXXXX
dialer-group 5
dialer idle-timeout 150
ppp authentication chap
ppp chap hostname JAM-BBI-R01
ppp chap password XXXXX
dialer-list protocol ip permit any
10-07-2009 08:33 AM
Complain to telco:
*Mar 17 00:37:43.953: ISDN BR0/0 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x95
Cause i = 0x0280BF - Service/option not available, unspecified
Display i = 'ISOLATE CONF SUCCESS'.
10-07-2009 08:38 AM
hi bevilacqua
telco is saying that everything is OK from Switch Side
i tried to google cause i=0x0280BF but am unable to find documentation related to it
U have some reference material pertaining to this cause
10-07-2009 09:51 AM
They are incorrect, challenge them to come over and verify correctness of your setup message with an analyzer.
10-07-2009 10:20 AM
One other thing to chk is In your dialer map, is dialing a 01 correct as usually it's just a 1 or an access code ive never seen anyone dial with a 0 first unless its an international number.
If that is correct then get telco to trace you call.
Also im not sure if we have your complete conf but, its dialing.
Your dialer-group 5 needs to point to
dialer-list 5 protocol ip per. Also this ACL may need to be adjusted if you have issues with the line not disconnection after 2 minutes of being idle.
Thx Steve
10-07-2009 10:51 AM
OP is in UK, where numbers like other places in EU, starts with 0.
This is most definitely not a router configuration issue.
10-07-2009 05:00 PM
hi all
In dialer map command we use 0191XXXX because in india using ISP like BSNL for dialing interstate we have to prefix STD code before the PRI No given ny telco. Also am having around 75 ISDN Links working fine for same PRI and are using 0191 code .
About dialer list command , we do use an access list where in it specifies the interesting traffic used to trigger ISDN Call and also use dialer idle timeout command . But what i am looking for is the ISDN Debug Code starting with 0x02 , some documentation / references to it because ISDN Debug Codes available on google / cisco doenot contain the cause i have included in my first mail --- i just want to leave no room for telco so that he doesnot come up with any other excuse
10-07-2009 06:43 PM
Eliminate your config (Dialer maps, interesting traffic etc...) from the equation by using "isdn test call" command.
I'm not at all familiar with telco's in your location but i would have them monitor the line while you make the call. If it's anything like the US the telco will have that "A-HA" moment and realize what they screwed up.
I can't tell by the number if this is a local or LD call. If LD try making a local call to any number outside your local exchange. Even to your cell phone is fine. If you are using spids you could also call the second spid from your first spid via the "isdn test call" command. These tests will give you something to compare against and might provide better cause codes to troubleshoot with.
I don't know if you use pic codes in your location but if you susptect a LD issue try using a pic code.
One final option is to make the call from the other direction. See if you can call from the PRI to the BRI. Again using the "isdn test call" command.
James
10-07-2009 07:30 PM
hi james
I tried test call option earlier using
Isdn test call interface bri0/0 220078
where 220078 is the access location BRI No , but the call is not getting through , as per cisco document one is reasonable sure that there is no issue in ISDN CLOUD IF This call gets through
What i am again stressing is that how can i convince Telco that it is an issue from their end and for that i need some good document
10-07-2009 07:40 PM
10-07-2009 07:41 PM
hello,
Everyone that has replied is exactly right.
I just found this on google
http://en.wikipedia.org/wiki/Q.931
0x2
2
No route to specified transit network (Transit Network Identity)
what this mean in plan English is the Telco doesn't know how/where to route this call to. Translations are incorrect somewhere in the path.
Call your Telco and get ahold of someone that can trace your call. This is a L3 issue. If the first person doesn't know what your talking about escalate it with them/Telco and get someone to trace your call when you place it. Once your that find you call they will be able to tell you exactly whats wrong.
It may sound like a pain but, I've had many fights with Telco's trying to get ahold of the right people to trace isdn calls. Most of em look at q921 and call it a day and blame the router.
Out of curiosity what is your switch type on the bri END ? Do you have spids/ldn configured ? or is this all originating internationally ?
Have you tried to dial a totally different number and check the q931 debugs ? The call may not go through but the q931 debugs may also be different shedding more light.
If this originates in the states try dialing your cell number and see what the debugs say.
Thx Steve
10-07-2009 08:58 PM
Hi Steve
The ISDN Switch used in INDIA and in my case is basic-net3 and we dont configure SPIDS
Thanks
Sohail
10-07-2009 09:08 PM
Ok, I know the telco are hard to deal with out there. So I can feel your pain and frustration.
Just remember ISDN is like a phone call and the Telco has to get the call routed to the far end.
Someone in Telco land out there has to be able to trace this call out.
If you can dial out of the PRI from the other end try dialing toward the BRI and see what errors you get.
Bottom line is Telco need to help ya here
Good luck,
10-08-2009 06:29 PM
beside that everyone agrees this is telco issue, it would be worth to ask them the switch type.
some EU switch has switch type that is not supported by Cisco, and appear to have layer 1 up.
10-09-2009 12:15 AM
I'm not aware of any cause in the EU with a non-standard switch type, but again, even the wrong swtich-type does not cause the call to fail.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: