Strange Problem after upgrade to 8.1(63) 1

[PhoneGuyNJ]

I have IP Office 500V2, with a Digital and a Combo Card. We have 1 POTS line on port 9 of the combo, and all was working fine until the upgrade. Now, almost every 30 minutes, the system thinks that line is ringing, when in fact it's not. It rings about 1 ring and stops, with no callerID. I have now set an incoming call route with a "?" to go to a phanthom extension that just is a busy, because it's annoying. Tried everything, reboots, some settings, etc. Strange because it's only since the upgrade. It seems as though it is detecting "something" but I dont know what that something is. I can say there is no voicemail on the POTS.

Here is a piece of the log when it happens if anyone has any ideas..

2013-01-10T13:58:48 4647038mS ATMChannel: [1] DTMF Message Rx: 0x0000 (Tone=0x0000)
2013-01-10T13:58:48 4647038mS ATMChannel: [1] CLI Message Rx:
2013-01-10T13:58:48 4647038mS ATMChannel: end of CLI Message
2013-01-10T13:58:48 4647038mS ATMChannel: [1] StateChange Idle->CLIAwaitData
2013-01-10T13:58:48 4647038mS ATMChannel: [1] CMLinkLayer Tx: 'Alert_PreIndication'
2013-01-10T13:58:48 4647038mS ATMIO: [1] CLI DETECTION OFF, EQUALISER OFF
2013-01-10T13:58:48 4647038mS ATMChannel: [1] StateChange CLIAwaitData->CLIDataSettle
2013-01-10T13:58:48 4647039mS ATMCMLine: [1] CMLinkLayer Rx: 'Alert_PreIndication' callid=(lid=1, id=2, in=1)
2013-01-10T13:58:48 4647039mS ATMCMLine: [1] StateChange Idle->IncomingGuard
2013-01-10T13:58:48 4647238mS ATMChannel: [1] Sloppy timeout(200ms)
2013-01-10T13:58:48 4647238mS ATMChannel: [1] StateChange CLIDataSettle->Incoming
2013-01-10T13:58:48 4647238mS ATMChannel: [1] CMLinkLayer Tx: 'Ringing'
2013-01-10T13:58:48 4647238mS ATMCMLine: [1] CMLinkLayer Rx: 'Ringing' callid=(lid=1, id=2, in=1)
2013-01-10T13:58:48 4647239mS ATMCMLine: [1] StateChange IncomingGuard->Present
2013-01-10T13:58:48 4647239mS ATMCMLine: [1] IncomingCall
2013-01-10T13:58:48 4647240mS CMCallEvt: 0.1113.0 -1 BaseEP: NEW CMEndpoint f5170318 TOTAL NOW=1 CALL_LIST=0
2013-01-10T13:58:48 4647240mS CMCallEvt: CREATE CALL:6 (f51889b4)
2013-01-10T13:58:48 4647240mS CMCallEvt: 0.1114.0 -1 BaseEP: NEW CMEndpoint f51874e8 TOTAL NOW=2 CALL_LIST=0
2013-01-10T13:58:48 4647242mS CMLineRx: v=1
CMSetup
Line: type=AnalogueLine 1 Call: lid=1 id=2 in=1
Called[] Type=Unknown (0) Reason=CMDRdirect SndComp Calling[] Type=Unknown Plan=Unknown Pres=NAInterworking (2)
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ULaw
BChan: slot=1 chan=1
IE CMIEDeviceDetail (231) LOCALE=enu HW=15 VER=8 class=CMDeviceAlogTrunk type=0 number=1 channel=0 rx_gain=32 tx_gain=32 ep_callid=2 ipaddr=192.168.42.1 apps=0
2013-01-10T13:58:48 4647242mS CD: CALL: 1.2.1 BState=Idle Cut=1 Music=0.0 Aend="Line 1" (1.1) Bend="" [] (0.0) CalledNum= () CallingNum= () Internal=0 Time=2 AState=Idle
2013-01-10T13:58:48 4647243mS CMCallEvt: 1.2.1 6 Alog Trunk:1: StateChange: END=A CMCSIdle->CMCSDialInitiated
2013-01-10T13:58:48 4647243mS CMTARGET: 1.2.1 6 Alog Trunk:1: LOOKUP CALL ROUTE: type=0 called_party= sub= calling= dir=in complete=1 ses=0
2013-01-10T13:58:48 4647243mS CMTARGET: 1.2.1 6 Alog Trunk:1: SET BESTMATCH: length 0 vs -1 match= dest=Home Line
2013-01-10T13:58:48 4647243mS CMTARGET: 1.2.1 6 Alog Trunk:1: AMBIGUITY: match= dest=498
2013-01-10T13:58:48 4647243mS CMTARGET: 1.2.1 6 Alog Trunk:1: SET BESTMATCH: length 0 vs 0 match= dest=498
2013-01-10T13:58:48 4647243mS CMCallEvt: Priority hike: call 6 priority 0->1
2013-01-10T13:58:48 4647243mS CMTARGET: 1.2.1 6 Alog Trunk:1: LOOKUP ICR: DDI=856-854-2679 CGPN= (Destination 498 ) => CDPN=498
2013-01-10T13:58:48 4647244mS CMTARGET: 1.2.1 6 Alog Trunk:1: ADD TARGET (N): number=498 type=0 depth=1 nobar=1 setorig=1 ses=0
2013-01-10T13:58:48 4647244mS CMTARGET: 1.2.1 6 Alog Trunk:1: SET USER: BUSY orig=1
2013-01-10T13:58:48 4647244mS CMTARGET: 1.2.1 6 Alog Trunk:1: ADD USER: BUSY depth=1 disallow_cw=0 dnd=0 real_call=1 group_call=0 type(CMNTypeUnknown) incl(0x0) excpt(0x0), allow_redir(1) remote=00000000 simult 0 (0)
2013-01-10T13:58:48 4647244mS CMTARGET: TryLoggedOutTargeting for user BUSY Failed
2013-01-10T13:58:48 4647244mS CMTARGET: 1.2.1 6 Alog Trunk:1: NO INITIAL TARGETS: BUSY
2013-01-10T13:58:48 4647244mS CMTARGET: 1.2.1 6 Alog Trunk:1: ADD USER: BUSY depth=1 disallow_cw=0 dnd=0 real_call=1 group_call=0 type(CMNTypeUnknown) incl(0x40) excpt(0x40), allow_redir(1) remote=00000000 simult 0 (0)
2013-01-10T13:58:48 4647245mS CMTARGET: TryLoggedOutTargeting for user BUSY Failed
2013-01-10T13:58:48 4647245mS CMTARGET: 1.2.1 6 Alog Trunk:1: SELECT: TRY VOICEMAIL orig_hg() orig_user(498)
2013-01-10T13:58:48 4647245mS CMTARGET: 1.2.1 6 Alog Trunk:1: Fallback() targeting failed
2013-01-10T13:58:48 4647246mS CMLOGGING: CALL:2013/01/1013:58,00:00:00,000,,I,498,,,,,0,,""n/a,0
2013-01-10T13:58:48 4647246mS CD: CALL: 1.2.1 BState=Idle Cut=0 Music=0.0 Aend="Line 1" (1.1) Bend="BUSY(498)" [] (0.0) CalledNum=498 (BUSY) CallingNum= () Internal=0 Time=6 AState=Dialling
2013-01-10T13:58:48 4647246mS CD: CALL: 1.2.1 Deleted
2013-01-10T13:58:48 4647246mS CMTARGET: 1.2.1 -1 Alog Trunk:1: ~CMTargetHandler f518a7e0 ep f5170318
2013-01-10T13:58:48 4647246mS CMCallEvt: 1.2.1 -1 Alog Trunk:1: StateChange: END=X CMCSDialInitiated->CMCSCompleted
2013-01-10T13:58:48 4647247mS CMCallEvt: 0.1114.0 -1 BaseEP: DELETE CMEndpoint f51874e8 TOTAL NOW=1 CALL_LIST=0
2013-01-10T13:58:48 4647247mS CMCallEvt: END CALL:6 (f51889b4)
2013-01-10T13:58:48 4647247mS ATMCMLine: [1] ControlEchoCancellation ON
2013-01-10T13:58:48 4647247mS ATMCMLine: [1] CMLinkLayer Tx: 'EchoControl'
2013-01-10T13:58:48 4647249mS ATMChannel: [1] CMLinkLayer Rx: 'EchoControl' (ls)
2013-01-10T13:58:48 4647249mS ATMIO: [1] ECHO CANCELLATION ON
2013-01-10T13:58:48 4647249mS PRN: Config Write Wake Up
2013-01-10T13:58:48 4647513mS RES: Thu 10/1/2013 13:58:49 FreeMem=60075060(1) CMMsg=5 (6) Buff=5200 956 999 12463 5 Links=7775 BTree=0 CPU=10/13/16495/34376/36055/2
2013-01-10T13:58:48 4647513mS RES2: IP 500 V2 8.1(63) Tasks=48 RTEngine=0 CMRTEngine=0 ExRTEngine=0 Timer=58 Poll=0 Ready=0 CMReady=0 CMQueue=0 VPNNQueue=0 Monitor=2 SSA=1 TCP=21 TAPI=1 ASC=1 SYS=MNTD OPT=UMNT SDSPD=2034
2013-01-10T13:58:48 4647513mS RES4: XML MemObjs=45 PoolMem=2097152(1) FreeMem=2082064(1)
2013-01-10T13:58:48 4647554mS PRN: Updates IO list size 1 updated list size 1
2013-01-10T13:58:48 4647554mS PRN: Sending Updates out to f5b05870 started
2013-01-10T13:58:48 4647554mS PRN: Sending Updates out to f5b05870 finished
2013-01-10T13:58:48 4647555mS PRN: Config Write Completed
2013-01-10T13:58:53 4652238mS ATMChannel: [1] Sloppy timeout(5000ms)
2013-01-10T13:58:53 4652238mS ATMIO: [1] TRUNK RELEASE
2013-01-10T13:58:53 4652238mS ATMChannel: [1] StateChange Incoming->Idle
2013-01-10T13:58:53 4652238mS ATMIO: [1] ECHO CANCELLATION OFF
2013-01-10T13:58:53 4652238mS ATMIO: [1] BLOCK FORWARDING OFF
2013-01-10T13:58:53 4652238mS ATMIO: [1] CLI DETECTION ON, EQUALISER OFF
2013-01-10T13:58:53 4652238mS ATMChannel: [1] CMLinkLayer Tx: 'Disconnect'
2013-01-10T13:58:53 4652239mS ATMCMLine: [1] CMLinkLayer Rx: 'Disconnect' callid=(lid=1, id=0, in=1)
2013-01-10T13:58:53 4652239mS ATMCMLine: [1] StateChange Present->DiscInd
2013-01-10T13:58:53 4652239mS ATMCMLine: [1] CM Tx: 'CMReleaseComp' callid=(lid=1, id=2, in=1)
2013-01-10T13:58:53 4652239mS CMLineRx: v=1
CMReleaseComp
Line: type=AnalogueLine 1 Call: lid=1 id=2 in=1
BChan: slot=1 chan=1
IE CMIERespondingPartyNumber (230)(P:2 S:100 T:0 N:0 R:4) number=
IE CMIEDeviceDetail (231) LOCALE=enu HW=15 VER=8 class=CMDeviceAlogTrunk type=0 number=1 channel=0 rx_gain=32 tx_gain=32 ep_callid=2 ipaddr=192.168.42.1 apps=0
2013-01-10T13:58:53 4652239mS ATMCMLine: [1] StateChange DiscInd->Idle
2013-01-10T13:58:53 4652240mS ATMCMLine: [1] CMLinkLayer Tx: 'DisconnectAck'
2013-01-10T13:58:53 4652240mS CMCallEvt: 1.2.1 -1 Alog Trunk:1: StateChange: END=X CMCSCompleted->CMCSDelete
2013-01-10T13:58:53 4652240mS CMCallEvt: 1.2.1 -1 BaseEP: DELETE CMEndpoint f5170318 TOTAL NOW=0 CALL_LIST=0
2013-01-10T13:58:53 4652241mS ATMChannel: [1] CMLinkLayer Rx: 'DisconnectAck' (ls)
2013-01-10T13:58:53 4652513mS RES: Thu 10/1/2013 13:58:54 FreeMem=60081100(1) CMMsg=5 (6) Buff=5200 956 999 12463 5 Links=7778 BTree=0 CPU=3/4/16495/34711/36055/2
2013-01-10T13:58:53 4652513mS RES2: IP 500 V2 8.1(63) Tasks=48 RTEngine=0 CMRTEngine=0 ExRTEngine=0 Timer=57 Poll=0 Ready=0 CMReady=0 CMQueue=0 VPNNQueue=0 Monitor=2 SSA=1 TCP=21 TAPI=1 ASC=1 SYS=MNTD OPT=UMNT SDSPD=2034
2013-01-10T13:58:53 4652513mS RES4: XML MemObjs=45 PoolMem=2097152(1) FreeMem=2082064(1)

 

[amriddle01]

Will just be some sort of incompatability which both manufacturers will say is the others issue....so good luck with that


Avaya Implementation Qualified Professional Specialist Technical Engineer (AIQPSTE)

 

[PatLeb]

Take the analog port from your combo ex;port 7 and plug it to the port trunk 9.
simulate an incoming line and monitor it.
And just in case do cancellation code on the line from carrier.

 

[smoknonions]

I DOWNGRADED to .57 at this point - and the phantom ringing has now stopped.

What I observed through system monitoring is that we are still getting Incoming Abandoned calls every 30 minutes on Line 1 - which is the POTS... BUT, the IP Office is not seizing the line now. Before it was seizing the line, and then ringing the hunt group with about 1 ring, then releasing the line. It has stopped doing that and leaves the line idle, even though it's registering the incoming abandoned."

We also downgraded the 2 systems having the issue to 8.1(57) and have the same symptoms but at least the phones are no longer ringing around the clock...

 

[PhoneGuyNJ]

Exactly! Although this is frustrating because I would like to have FP1 installed - since we paid for Power User licenses for offsite users, and would like to test out all of the One-X functionality. I would say we should port that POTS over to SIP with the rest of the lines, but we really wanted to keep that line for various reasons.

I am wondering how best to go about letting Avaya know - this is really not something I want to spend a month explaining and testing when it's clear I am not the only one with the same issue.

I did call Verizon on this - they did reset our lines, etc etc.. with no resolution - still get those inbound abandons. We actually then went and put a plain old 2500 set (An OLD Bell System one) to see if it would even do that "ding" phones used to do once in a while when you had the pos/neg reversed and someone dialed with pulse (LOL).. but that didn't even peep.

 

[tlpeter]

Do you have IPOSS?
If yes then spam them with traces and SSA logs and keep calling them
Let them know that there new support model sucks big time.


BAZINGA!

I'm not insane, my mother had me tested!

 

[PhoneGuyNJ]

Thats what I don't have time to do at the moment.

 

[tlpeter]

Then it won't be fixed and this problem will be in the coming releases too!


BAZINGA!

I'm not insane, my mother had me tested!

 

[ringvoltage]

Seeing the same issue with a POTS line on .63. FWIW.

 

[PhoneGuyNJ]

I agree. I just have a week long project at the moment, that there was not enough time even budgeted for it, so I can't add that to the mix until I return from that. - Not saying I "wouldn't" do it - just can't...

 

[PhoneGuyNJ]

@ringvoltage - yes and it's the same on the new .65 that was released - issue will still be there in .57 - but at least that version stops seizing the line and making phones ring.

 

[allwright71]

You might try bumping the gains on the line down to -1.5 DB's in both fields. Bounce it, and reassess. If no change go down to -3.0

 

[PhoneGuyNJ]

I have done all of that. Now that I am on version .57 - here is the latest trace of these mysterious abandons from the POTS - it's a lot less than the one above..

21738514mS ATMChannel: [1] DTMF Message Rx: 0x0000 (Tone=0x0000)
21738514mS ATMChannel: [1] CLI Message Rx:
21738514mS ATMChannel: end of CLI Message
21738514mS ATMChannel: [1] StateChange Idle->CLIAwaitData
21738514mS ATMChannel: [1] CMLinkLayer Tx: 'Alert_PreIndication'
21738514mS ATMIO: [1] CLI DETECTION OFF, EQUALISER OFF
21738514mS ATMChannel: [1] StateChange CLIAwaitData->CLIDataSettle
21738515mS ATMCMLine: [1] CMLinkLayer Rx: 'Alert_PreIndication' callid=(lid=1, id=2, in=1)
21738515mS ATMCMLine: [1] StateChange Idle->IncomingGuard
21738714mS ATMChannel: [1] Sloppy timeout(200ms)
21738714mS ATMChannel: [1] StateChange CLIDataSettle->CLIAwaitSecondRing
21743715mS ATMChannel: [1] Sloppy timeout(5000ms)
21743715mS ATMIO: [1] TRUNK RELEASE
21743715mS ATMChannel: [1] StateChange CLIAwaitSecondRing->Idle
21743715mS ATMIO: [1] ECHO CANCELLATION OFF
21743715mS ATMIO: [1] BLOCK FORWARDING OFF
21743715mS ATMIO: [1] CLI DETECTION ON, EQUALISER OFF
21743715mS ATMChannel: [1] CMLinkLayer Tx: 'Idle'
21743716mS ATMCMLine: [1] CMLinkLayer Rx: 'Idle' callid=(lid=1, id=0, in=1)
21743716mS ATMCMLine: [1] StateChange IncomingGuard->Idle
21743717mS ATMCMLine: [1] CMLinkLayer Tx: 'DisconnectAck'
21743717mS ATMChannel: [1] CMLinkLayer Rx: 'DisconnectAck' (ls)

 

[SIRMcD]

Hahahah , I know what this problem is and I thought I was going crazy. Are the ONT's from Verizon made by Alcatel. Probably an I-820G
Bell has recently started rolling out Fibre to the business and I have just installed an IPO that is supplied by lines from an ONT. Phantom ring every half hour on the dot. After much testing and having all the ONT equipment replaced the trouble continues. The ONT is bursting 20 VAC every half hour. Not enough to ring an analog phone (or buttset) but apparently enough to ring the IPO.
My A-d is 0, D-A is -3 I tried changing ring persistency to 2500ms to no avail. Impedance is set to 600.
IPO is 8.0(53)
Unfortunately there are no copper lines in the building. New policy for all new construction is fibre only. Does anyone have a version of *.0 that will stop the ringing, Driving my customer nuts. Why does the IPO ring with only 20 VAC?

Phoneguy , please connect a meter on the line and see if you get the 20 VAC when the line rings, the buttset won't tell you.

Thanks, Craig

 

[amriddle01]

A more relevant question should be aimed at the provider, "Why is the ONT is bursting 20 VAC every half hour?" That's what is causing the issue, it shouldn't be happening and they need to sort it out



"No problem monkey socks

 

[SIRMcD]

Yes , I agree, but I don't think anyone is aware of it. I and another tech have spent quite a few hours testing this. I am just starting to find out about this issue. My next step is to set up an ONT on a bench. See if the unit does it without fibre connected to it first. Anyone who is having an issue like this could you send me the model number off the ONT your carrier is using.
ONT's are very new to us so there are no subject matter experts at our company yet(at least that I know of). I'm going to try to reach out to Alcatel to see if this is some normal operation. Both units We used were brand new in the box.
Also if anyone knows of an 8.0 software level that will stop it from ringing, or any other ideas to stop the system from ringing on 20 VAC

 

[amriddle01]

I know Avaya Definity systems had a setting on analogue cards that would send out periodic pulses to check for equipment on the end, this could cause some handsets to do a short ring, on the Definity it could be turned off though



"No problem monkey socks

 

[Squatch]

Make sure your system is grounded.

 

[SIRMcD]

The system is , of course , grounded. The real issue here is why the 20 vac voltage spike coming from the ONT. Hopefully I can use an alternative software in the IPO so that it will stop ringing.

 

[yankblan]

The voltage is similar to the data containing caller ID info on analog. IPO started picking it up at 7.0 Def an Avaya issue, only system that does this; both with Bell Fibe (fiber) and Videotron (cable). The data sur sent is to update MWI on the line.

http://interconnexionsld.ca/

 

[SIRMcD]

Still the question remains is why so much voltage for a data burst. The MWI data does make sense, but true analog copper fed lines would do the same thing. But they do not cause the IPO to ring.