Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IPO - Phantom Ringing on Analog Lines

Status
Not open for further replies.

IPScec

Programmer
Aug 14, 2007
55
US
Hello,

I just installed an IPO R9.0 with 4 analog trunks on a combo card. When a caller calls in and is answered, after hanging up, the phones start to ring again showing the callers same caller ID but they are not on the line and the person that answers just gets silence. I tested from my cell and office while watching system status. I can see my caller ID ringing in and see when it is answered. If they don't answer it, it rings about 8 seconds then disconnects. Whether answered or not, it will continue to do this anywhere from 1 to 10 more times. I tested on all their analog lines with the same result.

Per thread we upgraded them to R9.1 sp8 and the issue remained. I also called the carrier and found that they did have MWL on even though the lines do not have voicemail through them. They did turn that off, still phantom ringing.

I ended up changing the analog line "Trunk Type" from Loop Start ICLID to Loop Start and the phantom ringing stopped. It has been about a week now with no phantom ringing. However, my client is not happy they have lost their caller id. This customer came off a Partner ACS. I don't really like doing analog lines in an IP Office but this is the first time I have had this issue which leads me to think it is something with the carrier/type of lines they brought in (they are on a channel bank, not true individual copper lines). However, when they had the Partner (before it died) they never had these issues and caller ID worked fine. Not sure where else to go with this now and need to get them their caller id back. Thought about changing out the Combo Card, but not sure that is where the issue is. Any thoughts would be appreciated.
 
Hi

I am not so sure about this, my experience with alog trunks was many years ago and not on Avaya systems.
But I have a feeling that by adjusting the Ring Persistency could make a difference.
So have you tried to increase the setting from default ?
Do note that if you increase it to much, it will never ring.

Ring Persistency: Default = Set according to system locale. Range = 0 to 2550ms. The minimum duration of signal required to be recognized.

/ Lodde
 
Thanks for the response Lodde, I will try that tonight and see if it makes a difference. I'm not sure if it requires a reboot, but even if it's a mergeable change I like to be able to reboot just in case. The thread I linked above has a link to this thread ( that left things with either being a release issue with IPO (that was supposed to be fixed in 9.1) or the MWI setting with the carrier. These posts were from 2013 and since neither of those items resolved our issue, I'm thinking they had something else going on. As stated, changing the lines from ICLID to Loop Start with no caller id has stopped the phantom calls.
 
Often in the modern world people say they did to make you go away when in fact they didn't change anything. Watch monitor to view this phantom ringing. It puts the ipo in a pre alert state. It doesn't ring on its own.

No phone, no pool, no pets.
 
The Avaya IP Office has a long and troublesome history with analog lines.
You would expect them to have the knowledge to deliver a rock solid integration but it is not.

Only advise I can give, try and error and maybe you'll fix it.
At this very moment we have only one customer with analog trunks coming from a Internet Modem and luckily enough it seems to work.
 
it also depends if they are real analog lines or if they come out of a providers voip box.
i don't trust these VoIP integrations much.
if you can also reproduce the problem then double up on the trunk and have your butt set on it to monitor if there is actually a call indicated. that way you can see if the ipo is the problem or the lines.


Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter
 
previous experience suggests to me that this may simply be a problem with Disconnect clear timers.

1 make sure the circuit you are connecting to has a reliable disconnect clear.
2 make sure the timers on the IPO are set to suitable values for those specified by the line provider



Do things on the cheap & it will cost you dear
 
Was doing more testing today after changing my lines back to ICLID from Loop Start and Ring Persistancy from 400 to 1200ms. Here are a couple logs that show the difference between a real call and a phantom call setup as they first come in. The main thing that sticks out is all phantom calls have StateChange Idle->CLIDataSettle right away when they present to the system unlike the real calls. I have full logs if anyone wants to see them. Thanks again.

**Note that while on Loop Start Line Type there have been NO Phantom Calls over the last two weeks.

Test Call:

16:38:43 3010022mS ATMChannel: [1] External Rx: 'IncomingRing' (ls)
16:38:43 3010022mS ATMChannel: [1] StateChange Idle->CLIPossibleIncoming
16:38:43 3010072mS ATMChannel: [1] Sloppy timeout(50ms)
16:38:43 3010102mS ATMChannel: [1] StateChange CLIPossibleIncoming->CLIAwaitData
16:38:43 3010102mS ATMIO: [1] CLI DETECTION ON, EQUALISER OFF
16:38:43 3010102mS ATMChannel: [1] CMLinkLayer Tx: 'Alert_PreIndication'
16:38:43 3010102mS CMCallPkt: v=0
CMInformation

Phantom Call:

15:26:15 1027083mS ATMIO: [1] CLI DETECTION OFF, EQUALISER OFF
15:26:15 1027083mS ATMChannel: [1] StateChange Idle->CLIDataSettle
15:26:15 1027283mS ATMChannel: [1] Sloppy timeout(200ms)
15:26:15 1027283mS ATMChannel: [1] StateChange CLIDataSettle->Incoming
15:26:15 1027283mS ATMChannel: [1] CMLinkLayer Tx: 'Ringing'
15:26:15 1027283mS CMCallPkt: v=0
CMInformation
 
1: Delete the incoming call route for any 'data'.
2: Turn off modem enabled against the PSTN trunks.


Now dieting.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top