sncsnc

is it a T1 card or a PRI 23 card that you are interfacing with
a t1 and pri are 2 different animals as far as the panasonic is concerned
so your post is confusing without knowing how you are running
were on the east coast are you?who is your provider?

thig95

Thanks so much for your reply! Sorry i should have mentioned it's a PRI 23 card, not a T1 card. Here's a breakdown of what hardware is in our switch if it helps...

slot 0: MPR(M) v1.0068
slot 1: LCOT8
slot 2: DHLC8 v1.009
slot 3: DLC16 v2.008
slot 4: DLC16 v1.009
slot 5: PRI23 (which is OUS since we pulled that T1) v1.006
slot 6: PRI23 (our remaining T1) v1.006
slot 7: SLC8 v1.002
slot 8: DLC16 v2.008
slot 9: idle
slot 10: OPB3 v3.001
slot 11: CTI-LINK v1.001

I seriously appreciate any advice you might be able to provide. Our service provider is Cooperative Communications based in NJ (as are we).

sncsnc

OK then you don't have a T1 you have a ISDN PRI.
So how many channels are actually used for voice out of the 23?

budweiser

is there a csu/dsu beetween the t1 smartjack and the tda system?
if so, try bypassing it or replacing it. panasonic requests that you have a csu/dsu, but the t1/pri should work without it. that goes for a straight pri circuit, not sure about the fractional t1/pri. could be that the adtran is faulty.
back in 2005, i handled the phone system for nyc mayoral candidate "Freddy ferrer" campaign headquarters. they started having t1 lockups and cutoffs durring high traffic like your customer, we tried everything, with no luck. as a last resort i just bypassed the adtran csu/dsu and the problems disapearred. the t1 worked flawlessly without the adtran unit for the next 2 months when he lost and closed the office.
since you have a fractional pri, you might not be able to bypass the adtran but if resetting your adtran temporarily solves your problem then i would suspect that the adtran might be faulty. your dealer might be able to get an advanced replacement unit from adtran to swapp it out with.
if the problems happens only during high traffic, i doubt that it is faulty programming in the panasonic.

sncsnc

they must have a iad if they are getting internet through the same
pri.

thig95

hey guys thanks for the replies. im sorry for the delayed response. sorry for my confusion about the ISDN PRI vs T1...im still working on the terminology. we have 12 channels for data and 11 for voice. yes, there is an ADTRAN unit where the line terminates. im not sure of the specifics of the unit as im not on site right now but I can post that when I get back later. that unit is how we split the cicuit between voice and data as our router and pbx are connected to it.I have our vendor coming on site today as well as a tech from our provider to replace that unit. I've spent the last several days reviewing voice activity to look for a pattern, but the only thing that seems common is heavy inbound volume. reseting the adtran is the only thing that seems to release the frozen channels. the most difficult thing here is not being able to reproduce the problem in a controlled situation. we have spent many hours after hours blowing up the lines but have yet to trigger the problem. what is also odd to me is this does not limit our ability to make outbound calls. only inbound calls are affected.hopefully I will have some better info later today and will post as soon as I can. thanx again for all ur help and advice!

sncsnc

its got to be how the iad is provisoned !

thig95

Hey i'm sorry again for the delayed response. Last week was quite a hectic one. On Tuesday of last week, our vendor was on site as well as a tech from our service provider. We tried for several hours to duplicate the problem without any success. Our SP had one of their lead guys monitoring the traffic from their end and didn't notice any problems. After some convincing, I was able to talk them into replacing the Adtran unit with a reprogram of the device, not just a swap of the cards.

Well, nothing really came from that. I was hopefull after not seeing any sign of the problem until late Friday, around 4:30 just as we were getting ready to head out. Sure enough I got a call saying one of our clients wasn't able to get through. Channel 13 (our bottom voice channel) was the only one able to take inbound calls. Every call that would come in when channel 13 was in use would attempt to connect via channel 14 and it would get dropped. So i dumped the ISDN protocol trace for the whole day and printed out 50 some pages for that last hour of the day. Here is what i found.

The last successful call we had come in to the PBX on a channel higher than 13 was at 3:56 PM to one of our DIDs. Sometime between the end of that call and 4:09 PM, a call came in again to a different DID on channel 14. The protocol trace shows the setup of that call, but the weird thing is there is no record of that call ever connecting. It also shows no disconnect or release. From that point on, any call coming in shows a connect attempt via channel 14, and then shows #44 Requested Channel not available. What i can conclude from that is channel 14 was never released properly. Because it wasn't actually in use, the PBX tries to setup an inbound call on that channel instead of bumping it up to a higher channel, but can't. I don't know if that makes sense or not, i'm not a phone guy but looking at the protocol trace leads me to thinks so.

He's an exerpt of the trace log so you can see what i'm talking about:

####ISDN TRACE####
CO->PBX No.4287 Port:1 (elapsed time from LPR reset) 01/01/03 13:03:02
L2: I SAPI:0 TEI:0
L3:
CONNECT ACK crn:4276 (O)
02 01 E2 96 08 02 42 76 0F
CO->PBX No.4288 Port:1 (elapsed time from LPR reset) 01/01/03 13:03:34
L2: I SAPI:0 TEI:0
L3:
SETUP crn:4277 (O)
Bearer Capability: 90 90 A2 (3.1kHz Audio Mu-Law)
Channel Identity: A1 83 8E (channel=B14 pref.)
Facility: 9F 8B 01 00 A1 17 02 01 01 02 01 00 80 0F 46 41 49 52 48 55 52 53 54 20 4D 49 43 48 45
([Inv] id= 01 op= 0(CallingName(PRI23))
Progress Indicator: 82 83
Description= "Origination address is non-ISDN"
Location= "public network serving the local user"
Calling Party Number: 21 83 37 33 32 34 37 31 38 38 31 39
Type of Number= National Number, Numbering Plan= ISDN/Telephony
Number= ########## //i blanked out the # for privacy purposes
Called Party Number: 80 33 32 30 33
Type of Number= Unknown, Numbering Plan= Unknown
Number= 3203
02 01 E4 96 08 02 42 77 05 04 03 90 90 A2 18 03
A1 83 8E 1C 1D 9F 8B 01 00 A1 17 02 01 01 02 01
00 80 0F 46 41 49 52 48 55 52 53 54 20 4D 49 43
48 45 1E 02 82 83 6C 0C 21 83 37 33 32 34 37 31
38 38 31 39 70 05 80 33 32 30 33
CO->PBX No.4289 Port:1 (elapsed time from LPR reset) 01/01/03 13:03:39
L2: I SAPI:0 TEI:0
L3:
SETUP crn:4277 (O)
Bearer Capability: 90 90 A2 (3.1kHz Audio Mu-Law)
Channel Identity: A1 83 8E (channel=B14 pref.)
Facility: 9F 8B 01 00 A1 17 02 01 01 02 01 00 80 0F 46 41 49 52 48 55 52 53 54 20 4D 49 43 48 45
([Inv] id= 01 op= 0(CallingName(PRI23))
Progress Indicator: 82 83
Description= "Origination address is non-ISDN"
Location= "public network serving the local user"
Calling Party Number: 21 83 37 33 32 34 37 31 38 38 31 39
Type of Number= National Number, Numbering Plan= ISDN/Telephony
Number= ########## //i blanked out the # for privacy purposes
Called Party Number: 80 33 32 30 33
Type of Number= Unknown, Numbering Plan= Unknown
Number= 3203
02 01 E6 96 08 02 42 77 05 04 03 90 90 A2 18 03
A1 83 8E 1C 1D 9F 8B 01 00 A1 17 02 01 01 02 01
00 80 0F 46 41 49 52 48 55 52 53 54 20 4D 49 43
48 45 1E 02 82 83 6C 0C 21 83 37 33 32 34 37 31
38 38 31 39 70 05 80 33 32 30 33
########

Now that shows the inbound call on channel B14. There's no records anywhere after showing this call being connected or released. I asked the user at this extension if she had taken a call from that number at that time and she said she did not. Now here is an example showing the #44 error:

####ISDN TRACE####

CO->PBX No.4296 Port:1 (elapsed time from LPR reset) 01/01/03 13:04:07
L2: I SAPI:0 TEI:0
L3:
SETUP crn:4278 (O)
Bearer Capability: 90 90 A2 (3.1kHz Audio Mu-Law)
Channel Identity: A1 83 8E (channel=B14 pref.)
Facility: 9F 8B 01 00 A1 17 02 01 01 02 01 00 80 0F 46 41 49 52 48 55 52 53 54 20 4D 49 43 48 45
([Inv] id= 01 op= 0(CallingName(PRI23))
Progress Indicator: 82 83
Description= "Origination address is non-ISDN"
Location= "public network serving the local user"
Calling Party Number: 21 83 37 33 32 34 37 31 38 38 31 39
Type of Number= National Number, Numbering Plan= ISDN/Telephony
Number= ########## //i blanked out the # for privacy purposes
Called Party Number: 80 33 32 30 33
Type of Number= Unknown, Numbering Plan= Unknown
Number= 3203
02 01 F0 9A 08 02 42 78 05 04 03 90 90 A2 18 03
A1 83 8E 1C 1D 9F 8B 01 00 A1 17 02 01 01 02 01
00 80 0F 46 41 49 52 48 55 52 53 54 20 4D 49 43
48 45 1E 02 82 83 6C 0C 21 83 37 33 32 34 37 31
38 38 31 39 70 05 80 33 32 30 33
PBX->CO No.4297 Port:1 (elapsed time from LPR reset) 01/01/03 13:04:07
L2: I SAPI:0 TEI:0
L3:
RELEASE COMPLETE crn:4278 (D)
Cause: 80 AC
Cause Value= "#44 Requested channel not available"
Location= "user"
00 01 9A F2 08 02 C2 78 5A 08 02 80 AC
########

The odd thing is, it is from that same number to the same extension. I'm really at a loss, and so is my vendor. He's going to reach out to Panasonic, but if any of you guru's could help me out it would be most appreciated!

thig95

some more information on whats happening. Today i've experienced 2 additional failures, and call volume has been low. I did notice similar elements from the incident on friday.

in all 3 cases (friday, and 2 times today) a call came in via DID to a user who was already on the phone. each time this happens, the protocol trace shows a call coming it to whatever DID the inbound caller dialed, it shows essentially 2 entries with the same crn# (see previous post for example) and then there's no indication of the call being released.

We have our extensions setup to FWD B/NA to voicemail from both CO and from EXT. When this happens, I will notice the corresponding Single-CO button for that line on the call director's phone will be lit up as if the line was in use. When i hit the button, it says "line busy" and gives the option to do a call back. Could this have something to do with call waiting??? I just can't understand why when i go to duplicate the problem and call my DID from my cell while my DID is busy, it transfers to VM as it should, and never results in the error. There must be some other element that remains to be seen.

Maybe this is a bug in the system's firmware? we are currently using Version 004-001 with console Version 1.06h