atcomsystems.ca/forum Forums Other TDM Phone Systems Vertical Telephones & Systems Won't release line on 2 incoming dial tones

I have a client with a Vertical Summit VS-5000-00 that was recently installed. The company that installed it was not very accommodating on troubleshooting a problem that has been here since they put the system in and thus I was asked to take a look. I have had the phone company out to no avail and I am not sure where the issue lies.

There are 8 incoming lines in a hunt group. All lines operate as expected but line 3 and 4. When an incoming call comes in on those lines and then hangs up, the line doesn't release. If you attach a butt set to the DMARC you can hear the phone system answer, then you hear the disconnect signal, but the system keeps playing the welcome message (on the working lines the minute the disconnect signal is heard the message stops and the system releases the line).

We've moved the lines around and the problem stays with the phone number NOT with the port on the phone system. So when we moved incoming lines 3-4 and swapped them with lines 1-2 then lines 1-2 had the problem. Disconnect the phone system and call into the line and it drops and goes to dial tone as soon as the call is ended by the caller so it appears to be the phone system.

Anyone have ANY suggestions? I am about to recommend that they have this company come out and remove this system and have another installed but hoping someone has a suggestion of a setting to change to maybe resolve this?

Thanks in advance for any help and/or suggestions.

Greg Hicks

Sounds like you may have split tips on the pairs. Frog the two tips sides and see if the problem clears. If so I'd ask for two new pairs.

It sounds like the phone company is not sending a disconnect signal on those two lines. You should not hear a "disconnect signal", only a slight "thump" as the voltage is dropped.

The phone company usually refers to this setting as "Cutoff On Disconnect".

With the phone system disconnected from these lines as soon as the caller hangs up the line switches back to dial tone. In fact with a butt set plugged in when you hang up the phone system continues to play the message and you will eventually get a dial tone from the carrier side of things.

The thump is what I was referring to, you can hear the click of the line dropping on the carrier side, but when plugged into the system (auto attendant) keeps droning on.

Here is a dump of the real time device monitoring screen. I just called into one of the trouble lines (Line 7 now) and I see that further down the table, Classification VSF, Type VMIU, Logical Num 1-4, IP 10.10.10.2, shows Line 4 as in use????

Since we moved these lines in the system from 3,4 to 7,8 and the problem follows I think it could be with the providers lines. How do I get them to acknowledge that?

Sorry Bill, what does Frog the two tips mean? One of these pairs was switched this morning so I do not think that is the issue. I am beginning to wonder if there is some service attached to these particular phone numbers (call waiting?) and that is causing the problem?

Thanks guys! I really appreciate your input and guidance.

Classification Type Logical Num IP Address Version Connection State
CO LCOB4 1 - 4 10.10.10.2
R1.1.9 Connected [1:Idle][2:Idle][3:Idle][4:Idle]
CO LCOB4 5 - 8 10.10.10.2
R1.1.9 Connected [5:Idle][6:Idle][7:Use][8:Idle]
CO LCOB4 9 - 12 10.10.10.2
R1.1.9 Connected [9:Idle][10:N/A][11:N/A][12:N/A]
CO VOIU 13 - 20 10.10.10.2
R1.1.9 Connected [13:Idle][14:Idle][15:N/A][16:N/A][17:N/A][18:N/A][19:N/A][20:N/A]
STA DSIB12 100[LDP 9030D] 101[LDP 9030D] 102[LDP 9030D] 103[LDP 9030D] 104[LDP 9030D] 105[LDP 9030D] 106[LDP 9030D] 107[LDP 9030D] 108 109 110 111 10.10.10.2
R1.1.9 Connected [100:Idle][101:Idle][102:Idle][103:Idle][104:Idle][105:Idle][106:Idle][107:Idle][108:Idle][109:Idle][110:Idle][111:Idle]
STA HYIB8 112 113 114 115 116 117 118 119 10.10.10.2
R1.1.9 Connected [112:Idle][113:Idle][114:Idle][115:Idle][116:Idle][117:Idle][118:Idle][119:Idle]
STA HYIB8 120 121 122 123 124 125 126 127 10.10.10.2
R1.1.9 Connected [120:Idle][121:Idle][122:Idle][123:Idle][124:Idle][125:Idle][126:Idle][127:Idle]
MISC MISU 1 - 7 10.10.10.2
R1.1.9 Connected
VSF VMIU 1 - 4 10.10.10.2
R1.1.9
(1:GSA0Fa)
(2:ASA0Cc)
(3:CS10Ba)
(4:GMA0Bb)
(5:IT10Fa)
(6:TK10Ba)
Connected [1:Idle][2:Idle][3:Idle][4:Use]
MCIM Virtual MCIB 1 - 32
.. Connected [1:Idle][2:Idle][3:Idle][4:Idle][5:Idle][6:Idle][7:Idle][8:Idle][9:Idle][10:Idle][11:Idle][12:Idle][13:Idle][14:Idle][15:Idle][16:Idle][17:Idle][18:Idle][19:Idle][20:Idle][21:Idle][22:Idle][23:Idle][24:Idle][25:Idle][26:Idle][27:Idle][28:Idle][29:Idle][30:Idle][31:Idle][32:Idle]

As a note, I was changing the value of the Open Loop Detect Timer in the phone system (CPC) a value of 1 (all values are *100ms) the system never answers, 2 and above and the phone line hangs.

Is there a setting for "Cutoff on Disconnect"? Do I need to mayb e adjust that value?

Cutoff On Disconnect is the telco term. Open Loop Detect Timer would be the setting you adjust. 400ms is what our systems are set at.

If the problem follows the line, then it definitely sounds like a CO problem. You could put a volt-meter on the line and verify that voltage is dropping when the far-end hangs up. You may also want to verify loop current.

Thank you again for the feedback. Do you have a recommendation for a decent multimeter (any of the Flukes probably?) that would give a decent enough reading that I could rely on?

What should loop current be measured at? During ring? Drop amount minimum at hang up?

If all that tests good any other suggestions?

Seems you have to have irrefutable evidence before phone company will even consider that it could be their equipment!

He told me that ALL the lines are hooked up the same so there is no way things could be different on just those two. You want to debate that statement, but at the same time you need to keep him on your side so when you finally do pin down the problem they don't make it more difficult to resolve!

Changing out the system is a bit harsh, like cutting off ones nose...you know the old saying. It may not fix the problem. Disconnect supervision is not working properly on those lines. However there are some adjustments you can make to the CCR which is playing the greeting.

Set the DISA retry count to one or better yet zero so that the message does not repeat after the caller hangs up. In the ccr table that is used to answer the call set the error destination to tone. This will send a howler tone to the co and kick off the line.

You may need to get the installation company back out to do this for your customer.

If the problem happened on 3&4 and on 7&8 once you moved them, it is a problem with the line itself (a carrier issue), and not the system. NFC is probably right about disconnect supervision not being turned on or a voltage issue. Have a vendor meet on-site with the carrier and prove it to them.

If I read his second post right disconnect is working with a butt set. I didn't ask but assumed these are pots lines, if they are CPC is not set on a per line basis, it's per switch line group, so I can't see it not working on just two lines, that's why I suggested spit tips as this will cause this and other weird problems. Being an old fart my assumption of POTS might be wrong.

Disconnect one line from the system and see if the remaining line works properly, my bet is it will.

Bill, they are not experiencing any crosstalk so could it still be split tips? I have run into this before with Cox sip to pots lines and my suggestions seemed to do the trick.

Yes, but I'm only talking POTS, if there cable company or SIP than my theory is out the window. You would get Xtalk if both lines were in use at the same time. He stated with butt set he could hear line go back to DT, yet he could also hear auto attendant, again if I'm reading what's being said correctly. Only takes a couple minutes to either prove or disprove this.

I read in the OP's post "Disconnect the phone system and call into the line and it drops and goes to dial tone as soon as the call is ended by the caller"

If an abandoned call returns dial tone, then loop supervision doesn't appear to be present.

Bill, I agree with you about disconnect (loop) supervision being a line group issue in the traditional sense, but telcos (if there is such a thing any more), often use pair gain hardware to extend lines to the premise. If these pair gain devices are not set to mimic the disconnect supervision via open loop, the line won't ever drop. Sure, you'll hear the click of the signal being sent by the CO when monitoring with a butt set, but that doesn't necessarily mean that the loop at the far end is actually being opened. The only way to test for this is to monitor the line's voltage when the click is heard. If it doesn't drop to zero volts for 600 milliseconds, then it isn't being repeated.

The "split tips" theory could be a logical answer as well, especially if pair gain equipment is in use. Crosstalk won't be prevalent if there is a short loop length to the SLIC, etc. that is providing the lines. Hey, there might be a pair gain cabinet at the nearest street corner, just a few hundred feet away.

Still, why did this just start happening? My guess is that the original installer of the system might have split tips when making modular plug connections to the system. The only true test of the split tip theory is to perform all testing right at the telco's demarc with a meter.

I'll bet a dollar that the plug for lines 3/4 has the tip for line one on pin 4 of the plug and tip for line 2 is on pin 1. The Summit uses pins 1/2 for line one and pins 4/5 for line two on an 8P8C plug (strange, but true).

Line 3 tip: Pin 1
Line 3 Ring: Pin 2

Line 4 tip: Pin 5
Line 4 ring: Pin 4

If the tips are transposed on these plugs, neither of the lines will truly go open upon receipt of an open loop disconnect signal.

Wow, this is some awesome information, I'm getting quite an education... now if I could just get my head around some of it.

They are POTS lines so Bill your theory is alive and well. Now to figure out what is going on. Interesting input also by Ed as far as to the proper wiring pin outs of those lines.

So here is what I am getting, and this sounds like what I should check/test

1) Check that the connector carrying those two lines is actually wired as Ed states (good possibility they were crossed and thus causing this issue, the way they were wired has remained constant through all this so a good possibility). I did notice that the connection was wired 1,2,4,5 but haven't traced those down to ensure they stay in the right sequence. I will make a note of your tip/ring values and check it.

2) If it is wired in correct order/sequence, then I will disconnect one line and test the other, then swap and see what the results are.

3) Still having trouble I will disconnect both lines, place my meter on it, and watch the voltage as the line is hung up on from the caller side.

If NONE of that shows as faulty, then my plan is to run screaming from the building and request an exorcism?!?!?!

This place is a bit outside of town, so there is a possibility of something added to boost some lines, although the CenturyLink guy informed me that all the wires are done up exactly like every other. But the input above gives me some good tests to perform and try to pin down the real culprit.

Thanks guys! This forum is great!

UPDATE:

Wiring doesn't seem to make a difference. However, I did put a meter on the lines with the following results:

All lines are @36-38VDC on hook, and 8.8 off.
Caller hangs up on good line voltage drop is to about 1VDC
Caller hangs up on problem line voltage drop is nothing on one of the lines, and to about 8.1 on another (did see it drop to about 4VDC once but usually still up close to 8)

Looks like it is a CO issue. Have a call in to see if this makes some headway

If anyone has some feedback/suggestions I am all ears. This place just wants their phones to work as expected. They are also still waiting to verify it isn't phone system before paying installer his balance. From these results does anyone think it could be possible in ANY way to be the system rather than the lines?

Just want to get some input as to whether I should tell client to pay, our issue is with CO. Just as a side note, problem is new because lines are new, old lines were either bundled on T1 or some other source. I think installer recommended they be taken back to POTS, not sure of rationale but that is what I have determined in my troubleshooting.

Greg

P.S. These problems are ONLY on incoming calls handled by the system. If office personnel call OUT on the line then things work as expected.

It's not the system. If it were, then the problem would follow the port, not the line.

Thanks, that was my thinking, just good to hear other thoughts.

"P.S. These problems are ONLY on incoming calls handled by the system. If office personnel call OUT on the line then things work as expected."

Greg, that's because the physical handling of a call by a human ensures that the loop current flow is broken upon completion of the call by the simple hanging up. It is the automated answering by systems that aren't able to determine when the caller is finished that demands that the disconnect supervision signal be sent. They never noticed this before because they probably didn't have an auto attendant on their original system.

Your tests further prove that the fault lies with the telco. I remember jokes about US West being referred to as "US Worst". I can't imagine that they are any better now after having been absorbed by CenturyLink.

The loop voltage must drop below one volt in order for ANY system to detect an abandoned call. Your measurements of up to 8 volts will never allow the system to operate under specifications as mandated by the FCC.

It's funny how manufacturers of systems are mandated to adhere to these specifications, yet the telcos that these mandates that are supposedly there to protect are the ones ignoring these very standards of service.

Since you're still seeing 8 volts even when the disconnect signal is being sent, then you really aren't receiving it. That's just your nominal off-hook voltage. I am still on-deck with Bill's theory of split pairs somewhere, and since there's no crosstalk between the lines, the split must be nearby.

But... I see improperly-provisioned line cards in pair gain cabinets responsible for not repeating the open loop signal almost daily. It's one of the two. It's just a matter of getting someone from 'US Worst' to verify this.

I will tell you that on-line trouble reporting with telcos seems to work better than actually talking with a live person in New Delhi. At least you can put information in the comments section that will potentially be viewed by someone with a pulse. Maybe you can copy/paste the information here in their comment section if it will fit. I found this out at my home a while back when GTE's CO wasn't sending disconnect signal. The technician in the CO who took the ticket read it, understood what was happening and called me to apologize for their ignorance. He never got it right (outgoing calls never received it), but at least incoming calls did, and that resolved most of my problem. I gave up the fight after that.

The programming changes I suggested will cause the line to disconnect if you are using an auto attendant to answer the calls. It is only a work around so you should pursue the telco to fix this issue at the same time.

I was given the login information by the installer when I was first called into this location. If you can give me an idea of WHERE those settings reside I will make a change. Spent lots of time on phone with telco today trying to get someone to listen. Person who I dealt with on-site is still telling me that he doesn't think the lack of voltage drop is what the problem is, but I think I've exhausted every other possibility. If it were the system then the problem would change with the port change and NOT stay with those particular lines/numbers.

Thanks for all your advice, phones are much more stable since I had the telco move these bothersome lines to the end of the hunt group, at least they get incoming calls MUCH less frequently and thus don't have to deal with this problem too often daily anymore. Still needs to be resolved though.

Greg

PGM 228 &

As a test, you can take something metallic (needle nose pliers, screwdriver, etc) and quickly short the bridge-clips on the problem line. This will cause the voltage to drop to 0V, and your line port should release.

Went to try your quick short test and when I put my butt set onto lines it is just a high pitched tone. Grrrrr!!!! I do NOT like dealing with telco's. They tell me someone will be here... "late afternoon"

OK, that was my equipment, damn button on butt set was stuck (time for a new one I guess). Got it resolved and did a test call, when I hang up outgoing message continued to play until I shorted the line, then it immediately reset and the line was available. It is 110% the telco... now need to just get a tech out here that understands what the hell is going on!

When you log on using a web browser you just have to search for CCR pgm 228, and you enter the table for the ccr you are using...I assume it is number 1.

The DISA retry is option number 5 in system attributes PGM 160-161

SUCCESS!!!! Finally managed to convince telco to switch pairs and voila! The system releases the lines promptly after the caller hangs up.
Thanks for everyone's suggestions. Now off to figure out the voice mail capacities. Just a few voice mails left and then no one else is able to. One thing or another... never a dull moment.

Well, that is great news to hear that you finally got this resolved and we were happy to help while teaching you a bit along the way. The problem that I still can't wrap my head around is the fact that this didn't start happening until the new Summit system was installed.

Going back to one of my prior posts, I'm going to assume that the prior system didn't have auto attendant or voice mail, since this condition is usually detected only once this hardware is brought into the equation. A line that stays on hold for too long is often just picked back up by a human, and when nobody is there, they hang up and the line is clear. Not so much with automated answering equipment.

That being said, the telco having switched pairs likely resolved the 'split tips' situation that JustBill had mentioned earlier. It sounds as if he nailed this one. This problem has likely been there for years, but nobody noticed it. It's hard to do hard-core testing of copper cable faults without a lot of field experience. Lord knows that Bill has plenty of it.

Thanks, Greg for getting back to us with your results. We are here to help always. Your feedback helps our web search feature to link persons with similar situations to a quick response in the future. Far too often, we help to resolve an issue and never hear another word about it. Come back soon if you need us.

I just looked back through the posts and realized I never clarified. While digging through all of this, I was handed an email where they detailed the process (back in mid December) of switching this office OFF a T1, and onto POTS lines. So that is why this problem wasn't noticed before. Not sure what the reasoning was for that, but that was the boat I found myself flung into. I just grabbed the paddle and started rowing to try to make it move again.

If anyone has any theories (besides cost?) for moving OFF a T1 I would love to hear it.

Greg

Downsizing most likely, plus if the t-1 was not a PRI you are better off with POTS believe it or not. Also a PRI card adds a bit of cost to the system. I suspect it was a frac t-1 with part of it used for data and if the data medium was changed to something else like a cable modem then the t-1 just for a few voice lines is not really cost effective.