Unable to Connect ISDN BRI to a Remote Site PRI

Unanswered Question
Oct 7th, 2009

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Wed, 10/07/2009 - 08:33

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'.

sohail_sarwar Wed, 10/07/2009 - 08:38

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

Paolo Bevilacqua Wed, 10/07/2009 - 09:51

They are incorrect, challenge them to come over and verify correctness of your setup message with an analyzer.

shillyar Wed, 10/07/2009 - 10:20

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

Paolo Bevilacqua Wed, 10/07/2009 - 10:51

OP is in UK, where numbers like other places in EU, starts with 0.

This is most definitely not a router configuration issue.

sohail_sarwar Wed, 10/07/2009 - 17:00

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

pompeychimes Wed, 10/07/2009 - 18:43

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

sohail_sarwar Wed, 10/07/2009 - 19:30

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

shillyar Wed, 10/07/2009 - 19:41

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

sohail_sarwar Wed, 10/07/2009 - 20:58

Hi Steve

The ISDN Switch used in INDIA and in my case is basic-net3 and we dont configure SPIDS

Thanks

Sohail

shillyar Wed, 10/07/2009 - 21:08

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,

chinkevi_2 Thu, 10/08/2009 - 18:29

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.

Paolo Bevilacqua Fri, 10/09/2009 - 00:15

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.

Actions

This Discussion