Strange Analog Noise on Call Pickup with Verizion FIOS Analog 3

[waldrondigital]

Dealing with a strange issue. Client has Verizon FIOS service with analog handoff to a analog trunk card in an IP500. When picking up the call on the second ring, there is a 1-2 second buzzing/flutter sound which can only be heard on the IP office side (from internal extensions), outside callers hear nothing. I've tried impedance matching, but have no idea why this is happening or what to do about it. We had Verizon come out, but they had no idea on how to fix it... I have them coming back next week with me here to investigate further.

I originally thought this might be an issue with the trunk card, which I replaced to no avail.

I've attached a recording picking up the call from speakerphone, recorded from my iPhone (m4a format).

Any ideas to help would be REALLY appreciated. The client has lived with this for quite a while and I'd like to get it licked.

 

[waldrondigital]

@bluemr2 - No caller ID works just fine and we are using embedded VM at this client.

@klubar - No caller ID is a deal breaker for this client. Turning off caller ID or changing the lines to Loop start did fix the issue.

 

[bluemr2]

Thanks for the help. If you're ever in baltimore, the beer's on me!

 

[waldrondigital]

@bluemr2 - You can also use this workaround for extensions, but just hunt groups... Check out the blog article I wrote which spells it out in one place.

 

[waldrondigital]

Sorry that should have read "NOT just hunt groups". Ugh... long day

 

[TouchToneTommy]

Listened to the mp3 of the problem - CID is a red herring, that "purring" you're hearing upon answering is ringing that has not been tripped.

Perhaps the IPO deliberately adjusts its impedance on the first 2 rings in hopes of capturing CID, but that is untripped ringing voltage you're hearing.

 

[waldrondigital]

@TTtommy - the CID is presented by this point. Is there a non-workaround fix you have in mind? Obviously better than my hack.

 

[wspence]

Thanks waldrondigital, you resolved my problem on my second case of this intermittent flutter. The first was my office system, we switched to a PRI. The second was today and it is gone thanks to your workaround!

 

[Sptech2]

Thank you waldrondigital....I was having this issue in NY with Cablevision analog lines. Your workaround solved it.

 

[brainey1]

I had the same issue on a 500V2. After swapping out all equipment, I finally took the trunk cards out and installed an old IP 400 analog trunk 16. Problem solved, never happened again after that point.

 

[hbiss]

Has anybody had this issue resolved? IP500V2 with Cablevision Motorola EMTAs. Has the problem gone away with newer product releases? I have a customer with this problem for the last 10 months. I'm willing to replace the system but wonder if the current hardware is going to do the same thing.

-Hal

 

[amriddle01]

You will notice the issue always involves some device that is trying to emulate analogue lines, this isn't the IP office, the IP Office may show it where previous systems didn't but it still isn't the IPO causing it, put in ISDN or at least proper analogue lines

http://www.ipoffice.tel

 

[waldrondigital]

Hey Hal -

Long time no talk (remember me from my 1A2 to partner install?)

There are two solutions to this (none are desirable):

1. Do my workaround as documented here:

http://www.waldrondigital.com/2011/...h-ip-office-analog-trunks-verizon-fios-fixed/

2. Use an analog trunk IP400 16, which brainey1 suggested above.

Other than that there is no fix. It has to do with how Cablevision/Verizon hand off the analog....

Best of luck!

 

[hbiss]

Good to talk with you again. My problem is that this is a Partner version so I don't have the options to do your workaround in the embedded VM. I'm mot convinced this is a problem attributed to the cable company ot FiOS.

What I have found is that you will hear the buzz every time if you happen to pick up the call during the CO line ring cycle so it's not random. It just depends on the odds of picking up the line during the ring or the silent period. The IPO seems to have a one second delay when picking up a line. It connects to the line then one second later the impedance drops to where the ring will trip. So for that one second it's like a butt set on monitor. That would support why the old trunk 16 card works and there is a problem with the trunk 4.

Why copper doesn't have the problem but a cable EMTA or a FiOS ONT does might have to do with CO ringing voltage being a sine wave and the ring from an EMTA or ONT ring generator being non-sinusoidal- which is full of higher frequency nasty sounding harmonics. A clean sine wave sounds much better and at 30Hz much might not even be passed to the receiver. So with copper it's still there only you don't notice it. Unfortunately I have no copper lines left where I can test this theory.

-Hal

 

[brainey1]

Since my last post, i have had the trouble again. This time a 500v2 70.12 using norstar sets. I immediately replaced every piece of equipment. The new equipment had the same issue. The dial tone provider was an ILEC (AT&T). The first time was with a small mom and pop privider so I figured it was them. I put another IP400 trunk 16 in and it solved it again. Brought the original equipment back to my office; we have one AT&T trunk, so I could test it. I never had it happen again. Tested it off and on for days.

 

[hbiss]

So you tested it with a trunk and didn't have the problem? The way to confirm it is to put a butt set or single line phone directly on the trunk before the IPO. Call the trunk from like your cell then listen to the butt set or phone for the ringing. During a ring cycle pick up a system phone and note whether or not you hear the buzz on it.

I really need to get this resolved because 99% of my customers are on either cable or FiOS. Verizon won't even give you copper any more, so how am I supposed to sell these things? Avaya is no help at all. All they say is that the IPO does not support analog lines from cable companies yet they have settings for every damn country from Afganistan to Zimbabwe.

-Hal

 

[waldrondigital]

Not that this is a good suggestion, but you can disable caller ID which will solve the issue. This problem is a) prevalent, b) annoying and c) yet to be fixed.

 

[brainey1]

I did the butt set test on the first customer with the problem. I had it in monitor mode and never heard the sound while at the same time hearing it on a 9620. I also used the butt set on an analog port answering an incoming cal with it but never heard it. I did hear the caller id burst on the butt set but that wasn't what is being heard on the set when answered. It didn't matter if I answered the call on the first or sixth ring; i heard it.

 

[hbiss]

Not that this is a good suggestion, but you can disable caller ID which will solve the issue.

Yeah, I've yet to try that because it's not really an option. If it does eliminate the buzz it adds credibility to what I was saying about the 1 sec delay above. If you change the trunk setting to loop start without CID there is no longer a delay between when the trunk rings and when the extensions ring. The delay is there to prevent users from picking up a call before the second ring and interrupting the CID. It looks like that delay is somehow causing the delay I mentioned above.

I did the butt set test on the first customer with the problem. I had it in monitor mode and never heard the sound while at the same time hearing it on a 9620.

That would be correct.

I also used the butt set on an analog port answering an incoming call with it but never heard it.

You should if you went off hook with it during the incoming trunk ring.

I did hear the caller id burst on the butt set but that wasn't what is being heard on the set when answered. It didn't matter if I answered the call on the first or sixth ring; i heard it.

Nothing to do with CID itself and like I say, doesn't matter how many rings, if you pick it up during the incoming trunk ring you will hear it.

-Hal

 

[waldrondigital]

I'm all ears if you find some sort of fix for this issue. Prior to working around it, I tried just about everything I could with the analog trunks and the IPO configuration for my case.

AKAIK it's not fixable via the IP Office.