Re: Problem with Cisco 3660 and 3 PRI lines

hbaumbach · ‎06-06-2005

Hello, I have a serious problem with a Cisco 3660 connected to 3 PRI lines. The Router receives PPP calls from Windows clients. Some of these get a callback from the Router, some users don't. Whenever the Router already has a load of around 60 or more calls we have problems with the callback of users. They call in, authenticate themselves and then the Router receives that the user should be called back from a RADIUS Server. The call gets disconnected and then the callback is set up. All three PRI interfaces on the router don't use all 30 channels, so there should be free B-channels. But the Router always tells me that there is no free B-channel to use for callback. The debug output look like this:

5w5d: ISDN Se1/0:15: Outgoing call id = 0x8850, dsl 0

5w5d: ISDN Se1/0:15: Event: Call to 02176763 at 64 Kb/s

5w5d: ISDN Se1/0:15: process_pri_call(): call id 0x8850, number 02176763, speed 64, call type DATA, redialed? f, csm call? f, pdata? f

5w5d: callED type/plan overridden by call_decode

5w5d: did't copy oct3a reason: not CALLER_NUMBER_IE

5w5d: building outgoing channel id for call nfas_int is 0 len is 0

5w5d: ISDN Se1/0:15: TX -> SETUP pd = 8 callref = 0x084D

5w5d: Bearer Capability i = 0x8890

5w5d: Channel ID i = 0xA18393

5w5d: Called Party Number i = 0x81, '02176763', Plan:ISDN, Type:Unknown

5w5d: ISDN Se1/0:15: RX <- SETUP_ACK pd = 8 callref = 0x884D

5w5d: Channel ID i = 0xA98393

5w5d: ISDN Se1/0:15: LIF_EVENT: ces/callid 1/0x8850 CALL_SETUP_ACK

5w5d: ISDN Se1/0:15: PRI Event: 16, bchan = 18, call type = DATA

5w5d: ISDN Se1/0:15: RX <- DISCONNECT pd = 8 callref = 0x884D

5w5d: Cause i = 0x80A2 - No circuit/channel available

5w5d: ISDN Se1/0:15: LIF_EVENT: ces/callid 1/0x8850 CALL_DISC

5w5d: ISDN Se1/0:15: process_disc_ack(): call id 0x8850, ces 1, call type DATA cause 0x22

5w5d: ISDN Se1/0:15: TX -> RELEASE pd = 8 callref = 0x084D

5w5d: ISDN Se1/0:15: RX <- RELEASE_COMP pd = 8 callref = 0x884D

RoutEWAHL1#

5w5d: ISDN Se1/0:15: CCPRI_ReleaseCall(): bchan 19, call id 0x8850, call type DATA

5w5d: CCPRI_ReleaseChan released b_dsl 0 B_Chan 19

5w5d: ISDN Se1/0:15: LIF_EVENT: ces/callid 1/0x8850 CALL_CLEARED

5w5d: ISDN Se1/0:15: received CALL_CLEARED call_id 0x8850

5w5d: no resend setup, no redial

Now my question is why aren't there any available B-channels ??? To me this looks like a problem with our PBX, but unfortunately our PBX guys can't find anything. But the log clearly states that the Router receives the message that there are no free B-channels available from the PBX, or isn't it like that... If the same user tries to connect for several times he will finally get a free B-channel for his callback after trying several times.

Thanks for your help!

Richard Burts · ‎06-06-2005

I am not clear from your posting whether you always have problems with callback or if you have problems with callback when there are 60 or more calls. Can you clarify this?

If callback does work under light load and has problems when load exceeds 60 calls it would suggest that there is an issue with the third PRI. The issue might involve the way the PRI is provisioned (from your PBX) and perhaps is provisioned to receive but not to place calls. Or this issue might involve the way that the PRI is configured. perhaps you could post the relevant parts of the config.

HTH

Rick

HTH

Rick

hbaumbach · ‎06-06-2005

Hi Rick, this is the weirdest problem I ever had... It only comes up when the Router has 60 or more connections, and between 10.00 to 13.00 in the morning. Sometimes on some days, there aren't even errors !!! The 3 PRI Lines are configured the same way on the Router, and the 3 lines are reachable under one phone number (ringdown) which connects to one of the 3 adapters. So, I never had the case that 1 Line uses all 30 channels. So, the callback error appears on all 3 adapters ! My guess after seeing all this is the PBX, our main PBX is around 3 km away in the city centre, and connections from the public network are routed there and then internally to my office PBX where the router is.Over here at the office we also have a smaller PBX which uses some trunks to be connected to the main PBX. Around 10 days ago the PBX guys already set up more trunks between main PBX and our Office because they also thought it might be that, or let's say after connecting a PRI-tester to one of the lines in parallel and recording what is going on. Now the error is still there, and my guess is that our PBX guys don't know what they are doing. I'll add the config of the Router, but I already tried everything logically with the configuration after this problem appeared first. I guess the best would be to place the router on the main pbx with the same number there which would be possible, the only problem is that our guys told me they need to order a new shelf for PBX cards, and this is not so easy in our situation, as we are public services...

Anyways, thanks for your help!

Richard Burts · ‎06-07-2005

Hans

This is indeed a strange issue. I have looked through the config that you posted and I do not see anything in the config that looks like it might cause the symptoms that you are experiencing. It feels to me more likely to be an issue with provisioning of the PRIs or within the PBX but I am not sure of what it is. Perhaps the output of debug isdn q931 might be helpful in seeing more detail of the isdn signaling that is going on.

HTH

Rick

HTH

Rick

hbaumbach · ‎06-07-2005

The output in the first post is already a part of the isdn q931 debug. This behaviour is already there for more than half a year, and we still have demand to put more PRI's online, but with this strange problem I guess it wouldn't work out well ... Our PBX guys already told me that they put some more trunks between our office and the central PBX which also receives all calls from the PSTN and then routes them through the trunks if they are for our office. This was also my idea, and after doing some investigation they said I might be right. Now I am running out of idea's ...