IP Office 6.0 dropping calls on analog lines

[jsjungle]

I have a new IP Office 6.0 system that has been installed for less than a month. The customer has complained of dropping calls in the middle of the call with some frequency. they have been doing this on their analog and digital stations. some inbound, some outbound. they have 8 analog lines. We have installed a ground on the system, we adjusted the impedence on the lines to match what the phone company (qwest) is sending, we have run a trace of the monitor and sent the log to avaya, and no one can seem to determine the problem.

has anyone else has simlilar problems with 6.0 on the IP500v2 hardware? any ideas on solutions? my first thought was to try to get them to transition to sip trunks or a T1 to get the local analog phone provider out of the picture.

we are pretty sure that qwest is sending too much voltage down the analog lines, but they can't seem to tell us if they are or not. is there a device we can install in front of the lines that would handle this and shield the phone system?

any thoughts or help is greatly appreciated.

thanks to any that can help.





Great works are performed, not by strength, but by perseverance.
-Samuel Johnson

 

[SYQUEST]

Have you tried using basic telephony skills? Like testing the local loop with a test set and a VOM? Are all 8 lines doing the same thing or only one or two? You need to measure the loop voltage and current for each line, and check all the terminations to make sure nothing is loose or intermittent.

That is where you should start.

....JIM....

 

[jsjungle]

We repunched all the lines to make sure connections are good. How do we do a loop test and what is a vom?





Great works are performed, not by strength, but by perseverance.
-Samuel Johnson

 

[hairlessupportmonkey]

how about just plugging a test butt into the lines and making a call to replicate the issue. if the test phone drops, then you know where your issue is.....

I think you are looking too hard at the issue and need to go back to basic fault finding!

 

[cmnstr]

Just out of curiosity, does your customer have Voice Mail Pro and are inbound calls processed by VM Pro before being handed to an agent? I am working on an issue with dropped calls on a IP Office running R6 and they are experiencing similar issues but they are using PRI. It is only affecting calls on those extensions where the call comes in to an auto attendant before being transfered to th extension. If they are using VM Pro, do you have the latest version running on the server?

 

[jsjungle]

they are using voicemail pro. both versions were the first release of IP Office R6.

I wish the problem was as simple as hooking a butt set up to the lines, but we tried that and have had difficulty replicating the problem. the dropped calls are intermittent, but frequent enough that we know it isn't on the far end.

any other ideas?





Great works are performed, not by strength, but by perseverance.
-Samuel Johnson

 

[cmnstr]

We are looking very closely at an issue with voice mail pro. In our case, this only happens on inbound calls that were first presented to voice mail pro through an auto attendant. Any calls presented directly to an extension via DID are not affected as far as we have been able to determine so far. Also, as mentioned previously our customer has a PRI and not copper trunks. It may not be VM Pro, and even if it is we have not come up with a solution, but it may be something you want to watch closely. This site had no problems whatsoever prior to upgrading to R6. I have changed my transfer tokens to assisted transfer to see if it makes a difference. Hopefully we will know more tomorrow.

 

[SYQUEST]

jsjungle,

Just to pickup where I left off, intermittents are the worst kind of problem. A VOM is a Volt-Ohm-Meter, you need one that measures current too. With that tool you can check the line voltage, should be -48V, and about 30ma of current drawn through the line ckt of the IPO. In tracking the problem lines you want to be able to know what line is being used when on a call. This is when being able to display a particular line on an IPO phone is IMPORTANT!! Depending on how the IPO is programmed, will determine whether you can do this or not. Then keeping a log of the lines verses calls will help isolate the errant lines. One other tool you can use is SMDR, at least to provide a log of the traffic. This may make it easier, also.

Hope this helps!

....JIM....

 

[jsjungle]

I had Qwest run a VOM test on the lines, here is what they came back with:
DC voltage: 42.3
current milliamps: 24.2
loss: -4.7
noise: 8.06
power inflow: 42.2
balance 78.6

They said the analog lines had been set up as PBX lines where the voltage is 42.3 vs. a standard CO line that is 48 volts DC. I see from SYQUEST's comments above that we should be at 48 volts DC and 30ma, is this perhaps the problem? If we switch them to CO lines from PBX lines (as they call it), will that cure what ails us?

Qwest also said they were running a testing line that they stopped running just to make sure that wasn't dropping calls.

Additionally, we had someone suggest that they uncheck 'disconnect clear' on the analog lines in the IPO...not sure if that would make a difference or not.





Great works are performed, not by strength, but by perseverance.
-Samuel Johnson

 

[SCNIPOffice]

We are having this exact same issue with an IP Office 500 v6.0(8) in one of our locations. We have five total, four of which have an analog line configuration. All four analog locations are experiencing bleed over on calls where ports 9 & 10 bleed and 11 & 12 bleed.

Of these, one system, hosting 7 analog lines, is having the same issue you described. Calls are being disconnected mid conversation, quite frequently throughout the day. Our provider was out today and reduced the transmit power and set impedance to "auto." It's only been running under this configuration for about an hour, but so far no further reports of trouble from this location.

We use VM pro across the SCN via IP trunks and use queue announcements, but no auto-attendant.

 

[SCNIPOffice]

jsjungle: Are you having any reports of bleed on the line as well?

 

[jsjungle]

SCNIPoffice: did you reduced the transmit power and set impedance to "auto." in the IP Office settings? - we matched the impedence on the IP Office to match what the CO was presenting, but not sure on the transmit power setting.

also, not sure what you mean by bleed on the lines...or how you test for that.

anyone know what the DC voltage should be set at? 48 or 42.3? would that matter?





Great works are performed, not by strength, but by perseverance.
-Samuel Johnson

 

[SYQUEST]

I don't know what Qwest is up to, but that is nonsense about the line voltage being -42.3V on PBX trunks!! CO lines whether POTS or PBX are -48V +/- 1 or 2 volts. It has been that way as long as I have been doing telephony (1967).

Have you been able to identify if all the lines have the disconnect problem or just certain ones?

At this point, it looks like you still don't know if the problem is the IPO or Qwest.

Did you ever test any of the lines with a single line set or test set? results?

....JIM....

 

[hairlessupportmonkey]

just upgrade them to ISDN and be done with it! ;-)

 

[SCNIPOffice]

Hi jsjungle:

No, we did an automatic impedance test on the IP Office and it came back with 600 ohms, what the provider was set to. We left the IP office with the same value and the provider changed their setting to auto.

They also changed the transmit setting on their end. We didn't make any adjustments in IP office.

For line bleed, I'm referring to cross talk, where within the office, our representatives are hearing conversations on other lines, off-hook signals, fast busy, and dial tone.

This seems to have gone away with the settings changes.

 

[CarGoSki]

If they are using a Cisco IAD to provide loop start lines then there is a command that will provide more voltage.

It's people like you who generalize.

 

[hibroth]

I had it at least 4 systems with the same issue, but I was able to replicate it.
It seems due to Line Appearance placed on phone keys.
The behaviour seems changing depending on the LA position, but, in my experience, the problem disappair completely by removing all LAs.
The issue has been escalated to Tier 3, waiting for a MR.

 

[tlpeter]

Another reason for not using LA's

Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

A yard full of tards

 

[jsjungle]

line appearance does not equal call appearance, correct? we have at least two call appearances per phone.

update: two of the customer's eight lines were shared by the fire alarm system...we took those two out of the system/line hunt on tuesday. we have had no reports of dropped calls since then (3 days). hoping it fixed the problem, will update more if problem is fixed.





Great works are performed, not by strength, but by perseverance.
-Samuel Johnson