Line offhook when it shouldn't be 1

[noisecode]

I have a customer who has about 8 lines on 2 408 gs/ls/mlx modules. Line 5 is always offhook, even though no one is using it. When I first got there I listened on the line and just heard clicking. I restarted the system and then I heard dialtone on the line followed by the sound you hear when the handset is off the hook for too long. Something is taking this line offhook. Is there a way to find out what port/extension is taking the line off hook? I tried disconnecting each extension and watching a button associated with Line 805 and never saw it go on hook. I was also noticing the clicking on the line, so I disconnected each line until I didn't hear clicking anymore. I found the line that was making the clicking sound but it did not get rid of my line going off hook problem. Any help would be greatly appreciated. Thanks!

 

[merlinman]

The problem is, if you have a Bad Phone that's seizing the line, when you unplug the Phone, you just put the line on hold, so the light on the line stays on.

I would, one at a time, disconnect the phones, then after each phone is disconnected, I'd disconnect the line also and see if it goes out.

 

[Pepperz]

Try: Sys Prog>Start or Exit>Lines Trunks> TT/LS Disconnect>LS Disconnect> Yes.
... then test again.

Pepperz at newper dot net

 

[noisecode]

Pepperz, just wondering what this option does. Will this make it so I can disconnect each phone one at a time and not have to disconnect the line as well to test?

 

[Pepperz]

Yep. I thnk it's something that the manufacturer did to trip up guys in the field. It's got me a couple of times. It will lock up voicemail systems sometimes, and generally cause a line not to release from the system unless set to "yes".

Pepperz at newper dot net

 

[merlinman]

Yes, that could be it too.

 

[noisecode]

I went ahead and did what Pepperz had said. I changed the LS Disconnect to YES and the problem went away immediately. Just wondering what this option actually does. If everything was working before the problem first occured a few days ago, why would I have had to enable this once the problem emerged? Just don't understand why one line would be offhook when this was disabled but the rest were ok, even after multiple system restarts and power cycles.

 

[Pepperz]

Stuff happens.

Pepperz at newper dot net

 

[merlinman]

This option tells the Legend/Magix to recognize the momentary drop in Loop Current that happens when a Central Office detects the end of a call.

 

[TravelingTom]

There are a couple of reasons why this needs to be on. In the earlier release legends the loop start disconnect had to be on for loop start lines to help eliminate hacking. Hackers would call in to the auto attendant on the older mail systems and be able to get back out on another line before it would disconnect. It could also save the customer money on long distance calls by disconnecting sooner, particularly if the customer did a lot of long distant calling. I once had a customer that could not make outgoing calls and found conversations on their lines. Investigation from the provider showed the calls came in on a published 800 number and were going to South America. I found that the customer had loop start lines and the LS disconnect was not on. Now most of this has been eliminated with dissallowed lists and frl restrictions but hackers are very smart about systems.

 

[noisecode]

If it wasn't looking for the momentary drop in loop current, how would it detect when the line was once again available?

 

[TravelingTom]

It would rely on the CO disconnect.

 

[noisecode]

Which would be?