Channels LCKO on PRI trunk

[pcod1970]

Hi all,

We have 2 PRI trunks connected to PSTN. We have then connected a voice multicoupler (Nice product) between the PSTN and the PBX on these PRAs. The purpose of Nice application is to record the calls on the voice channels. From time to time, we are facing to LCKO channels on these trunks at the PBX level. We are investigating the root cause but we are not able to point to a PBX/ PSTN or Nice issue. According Nice, the multicoupler should not be pointed since it is a passive component listening the voice timeslots on the PRI2 trunks. We don't have the possibility to bypass this multicoupler. Could some of you help me? Moreover, what are the conditions to have LCKO channels? Can this be a hardware or software issue? Usually after a reset of the trunks, channels become IDLE. Thanks

 

[Johnthephoneguy]

If you have this happening to both PRI trunks, I would first remove one of them from the multicoupler and see what happens. If the removed PRI has no more issues you know its the multicoupler, if it still does then you would have to get further into it, but that would be my first step.

JohnThePhoneGuy

"If I can't fix it, it's not broke!

 

[pcod1970]

This is what we already proposed but due to the random frequency of the occurence (it can work for 2 weeks without any issue), customer did not accept to remove the recording solution. It should be indeed easier... now we trying to understand what could be the reasons.

 

[johnpoole]

might try posting your rdb.. couple of things in it that could help limit lock outs.. i've never seen a nice hold a trunk.. it just does not have the software to do that.. i've never seen a hardware issue that is that random and just shows up on timeslots... do you get any hits in the lcnt table.. and what does your clocks look like..

john poole
bellsouth business
columbia,sc

 

[MagnaRGP]

LD 60

lcnt

if you are receiving lots of errors the channels could LCKO. the only way to determine the source, however is to bypass one PRI and see if it LCKOs. There will not likely be any other way to determine the root cause.

 

[pcod1970]

Could a bad earth conection or PRI quality cable or connector lead to such status? There are no alarms reported on the clocks (in sync and no slips). When issue is occuring, channels are becoming one by one LCKO until the links are not usable. For sure I will check the error counters at the next occurence (lcnt). I totally agree with you : the only way to determine the root cause is to remove this box and see what happens but you are not the customer who has a business view... :-(

 

[MagnaRGP]

Right! But since this is already a service affecting issue, briefly invoking a troubleshooting method that is service affecting should be a no-brainer. Especially if the methodology will likely determine the source of the problem.

Patient: My feet hurt ever since I put these shoes on.
Doctor: Let's take one off and see if the pain goes away in that foot. If so, we should look at the shoes.
Patient: I can't do that because I need shoes to walk in.
Doctor: <speechless>

 

[Triton101]

you could also be getting channel lockouts to to glare and time to disconnect. If the far end does not drop the connection within a time limit, then the channel locks out so it is not used, you also might want to confirm the DCH programming with the CO to make sure nothing changed.....

if you do not pickup errors, I have seen modems stay online for more than several days that cause channels to lock out as well.....

__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius

 

[pcod1970]

New interecting fact what I'm sure is linked:Today, we added some extra monitoring on the Q.931 protocol level on PBX side. Doing so, we learned that when a failing inbound call is made, the Telco does send a call SETUP message and it is well received on the PBX's E1 interface (monitoring Dchannel level 2) but not on level 3. And as the PBX doesn't respond, the Telco sends a clearing message with cause 102 (recovery on time expiry).