Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Cause codes for PRI Layer 3

Status
Not open for further replies.

jinxs

Vendor
Mar 28, 2003
725
US
I have a Cust. with a PRI coming in from the LEC. Normal PRI, DID, call by call service, ESF, B8ZS on a dms-100. I verified the protocol with the Switchman today. The problem is every couple of phone calls while making a phone call, we would get a fast busy. I could be on trunk 805 make a phone call get a fast busy, roll through the pool and hit 805 again dial the same exact number and complete the call. I went into "the unsaid" and did the normal trace. I'm getting the normal set-up message but then it goes right to release complete, with a cause code of 80 A2. So, from what I am reading, this would be ITU-T standard on the user side with no circuit or channel avaible. Then it goes into co initiated disconnect. Now, according to the book I am reading, I quote," If a setup message is recieved from the user side of the interface for a busy b-channel, the responce is release complete. This means 'channel not avaible' but an alternate channel may be selected by the user end of the interface. "
So, the question here is, since this is on the user side, would this be a magix problem or network problem. It is on a INA board but we are not using the CSU, we have a paradyne 3160. 3 misframes an hour, 1 slip, no errors. Help.
 
I run an INA board on one side of a tandem networking setup and would see sporadic issues with it as well. We wouldn't have dialout busies as much as sporadically dropped calls across the point to point. The ptp ciruit has tested out fine and checking the trace result codes apparently the INA board was the one terminating these calls. The calls were flagged as being completed with normal disconnects. But they were anything but.

What I did was upgrade the INA firmware to the latest version. There was no QPPCN bulletin regarding the specific issues being encountered but I figured it would be worth a shot anyway. AFAIK the issues still persist. According to Avaya Tier 3 support a rate of around 2% dropped calls is acceptable within vendor specs. Given our call volume this would mean 8 calls per day. Maybe I'm picky but that doesn't sound too good to me. Good thing we're a retail company and not an outbound agent call center!

I know I should've probably tried replacing the INA board. But since no one is complaining too loudly about the dropped calls we're staying put for now.

Out of curiosity why are you employing an external CSU? You can break voice and data internally right out of the INA. Avaya only recommends an external CSU for those folks using their 100D card models I thought. Some things I would suggest to check would be circuit clock source and dialing time thresholds. That and perhaps upgrade the INA firmware to see if this helps.
 
I had a similar issue with a PRI on a 100DCD. After much trial and error I chend the default setting on the T303 timer which controls the delay in network response when the system sends a setup message to initiate an outgoing call to 10 seconds and I did not see this issue any longer

Coladmin
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top