×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Strange Problem after upgrade to 8.1(63)

Strange Problem after upgrade to 8.1(63)

Strange Problem after upgrade to 8.1(63)

(OP)
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)

RE: Strange Problem after upgrade to 8.1(63)

The line is out of use now because of the programming, can you parallel or even disconnect it from your system and monitor it from your butt handset?
I've seen a POT phantom ring fault that was caused by a dodgy patch panel socket on the tie cable from the MDF. I used a different pair on the tie and pp and hey presto.
Electrician had to replace their new patch panel.
8.1.63 upgrade could just be a coincidence- had a working NIC blow up yesterday around the same time i plugged a PoE handset in.

GL

RE: Strange Problem after upgrade to 8.1(63)

(OP)
Well, I have plugged this directly into the DMARC (Verizon Fios) with nothing else in it, and still every 30 minutes or so, that comes into the office. There is nothing on the butt set ringing at all.. even checked with the phone company and no phanthom calls. Tried Analog port 3 as well, same result.

What I notice in this log event is that the following lines ALWAYS come in first:

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

What it looks to me is that it's looking for DTMF CallerID? Even though I am not set for that and set for FSK.
Normal calls kick off like this:

2013-01-12T16:49:57 8334201mS ATMChannel: [1] External Rx: 'IncomingRing' (ls)
2013-01-12T16:49:57 8334201mS ATMChannel: [1] StateChange Idle->CLIPossibleIncoming
2013-01-12T16:49:57 8334251mS ATMChannel: [1] Sloppy timeout(50ms)
2013-01-12T16:49:57 8334281mS ATMChannel: [1] StateChange CLIPossibleIncoming->CLIAwaitData
2013-01-12T16:49:57 8334281mS ATMChannel: [1] CMLinkLayer Tx: 'Alert_PreIndication'
2013-01-12T16:49:57 8334281mS ATMCMLine: [1] CMLinkLayer Rx: 'Alert_PreIndication' callid=(lid=0, id=0, in=1)
2013-01-12T16:49:57 8334282mS ATMCMLine: [1] StateChange Idle->IncomingGuard
2013-01-12T16:50:00 8337281mS ATMChannel: [1] Sloppy timeout(3000ms)
2013-01-12T16:50:00 8337281mS ATMChannel: [1] StateChange CLIAwaitData->CLIAwaitSecondRing
2013-01-12T16:50:04 8341281mS ATMChannel: [1] Sloppy timeout(4000ms)

But these Phanthom calls come in as stated above. I have it set properly with ICLID and FSK.. so it's almost as if it's "listening" for some kind of DTMF tone?

RE: Strange Problem after upgrade to 8.1(63)

So we can say this:

If your butt isn't ringing it isn't a real call.

Also to confirm your findings, below is also a normal trace which matches yours:

24508275mS ATMChannel: [1] External Rx: 'IncomingRing' (ls)
24508275mS ATMChannel: [1] StateChange Idle->CLIPossibleIncoming
24508325mS ATMChannel: [1] Sloppy timeout(50ms)
24508355mS ATMChannel: [1] StateChange CLIPossibleIncoming->CLIAwaitData
24508355mS ATMChannel: [1] CMLinkLayer Tx: 'Alert_PreIndication'
24508355mS ATMCMLine: [1] CMLinkLayer Rx: 'Alert_PreIndication' callid=(lid=1, id=2, in=1)
24508356mS ATMCMLine: [1] StateChange Idle->IncomingGuard
24511355mS ATMChannel: [1] Sloppy timeout(3000ms)
24511355mS ATMChannel: [1] StateChange CLIAwaitData->CLIAwaitSecondRing


At the start of your buggy monitor:
2013-01-10T13:58:48 4647038mS ATMChannel: [1] DTMF Message Rx: 0x0000 (Tone=0x0000)

You are right, you are getting some voltage the IP Office is detecting somehow.


1) Are there any other devices or line cords on this line hanging up this line and/ or generating a 'tinkle' on the circuit? Sometimes tracing back to the frame is the only way to be sure!!
2) Have you got clear dial tone at your main frame and at your endpoints?
3) Can you use a different port on the IP Office?

I have seen a faulty node in the exchange that would drop a DSL/POT service every 10 -15 minutes, then come back online with a burst that made the phones ring. Carrier tech had to swap a card. Carrier checked and had normal dial tone every time.

Tlpeter or one of the other deep .bin file programmers would be able to tell you if there is any benefit in downgrading to 8.1.56. I shouldn't think so, but stand to be corrected.

RE: Strange Problem after upgrade to 8.1(63)

I think you just have static on the line from a external source like a cooler starting every 30 minutes, you could try to find a line filter to suppress static.

A simple mind delivers great solutions

RE: Strange Problem after upgrade to 8.1(63)

(OP)
For testing there are NO other devices on this line, I did think it could be the Alarm which is tied in, but we removed that and plugged directly into the POTS jack on the Verizon FIOS ONT at the DMARC with a brand new line cord. We also tried other ports on the combo card by placing this one out of service, and the same result - it follows the line.

Dial tone is completely clear, No static at all (at least that is audible).

Interesting point - as there IS a water cooler! - Unplugged that as well.. problem still exists.

My only thought would be why would the system even "listen" for a DTMF CallerID when it's not set that way - I would think it should be supressed. In fact, when I turn the line to a Loop Start instead of ICLID, I still get the same going on. It's almost like a line test.

We did also call Verizon whom tested the line and reported no trouble.

RE: Strange Problem after upgrade to 8.1(63)

You don't have a oscilliscope around there I suppose? That would make static or other signals visible.

A simple mind delivers great solutions

RE: Strange Problem after upgrade to 8.1(63)

change the line port and see if the problem follows (requires a reboot I know if you want to reprogram the line ID but you can also just make a new incoming call route with the line ID and outgoing you skip the line for an hour until you know)
Had it also happening that a DsL line filter took care of phantom ringing so if you have one then put it in and hope for the best.

Joe W.

FHandw, ACSS (SME), ACIS (SME)

http://convergednetworks.ca


Give a tech a solution and he will be back tomorrow to ask you the next question, teach a tech how to read the manual and he will be able to solve the problems for a life time.

RE: Strange Problem after upgrade to 8.1(63)

I am experiencing the same "phantom ring" on my system. It is an IPO 500v2 just upgraded to 8.1(63). This is a test system I have in my shop and it is a fresh config. It was running fine without this issue for about a month but started with these false call detections almost immediately after upgrading.

I also have a single POTS line on FIOS digital voice service connected to a combo card. I have tried moving the line to all 4 ports, logging into my verizon portal to make sure that Light message light and/or change dial tone to stutter (where available) is turned off, to eliminate that as the problem. I increased the Ring Detection, Ring Persistency to 1200 (from default of 400) to try to eliminate the phantom calls, but they are still there. The line from the FIOS ONT is plugged directly into the IPO, bypassing all internal wiring.

I will dig up a DSL filter to see if it helps, but has anyone gotten any answers on this? As I stated, this is a test system, so if anyone has any suggestions, I'd be happy to test them out.

RE: Strange Problem after upgrade to 8.1(63)

We also have 2 customers running 8.1(63) and analog trunks experiencing the same issue....

RE: Strange Problem after upgrade to 8.1(63)

I did an install last week for a business partner. The IP Office was loaded with 8.1.63, and we were told that 8.1.63 was acting 'buggy'. They didn't go into specifics, they just said they had just found out that 8.1.63 was 'buggy' by someone at tier 3/4 Avaya, for what it's worth.

RE: Strange Problem after upgrade to 8.1(63)

Oh, and we ended up downgrading the switch from 8.1.63 to 8.1.43 and had no problems.

RE: Strange Problem after upgrade to 8.1(63)

(OP)
Well it looks like a new update to .65 came out - wonder if that included any other fixes. I am glad I am not the only one having this issue - I am also dealing with Fios, so we called and had VM removed completely. But as mentioned, this only started when moving to .63 build.

RE: Strange Problem after upgrade to 8.1(63)

On Phone 16 & 30 modules the number presenation doesn't work on all stations. I use the 8.0 bins and then it works.

A simple mind delivers great solutions

RE: Strange Problem after upgrade to 8.1(63)

(OP)
No this is an inbound issue.
I just upgraded to .65 and these phanthom ringing calls are still coming in every 30 minutes or so.
Just wondering what I will lose if I downgrade back to Q4 .57?

RE: Strange Problem after upgrade to 8.1(63)

What happens if you just unplug the line from port 9. Do you still get a ring? It could be a short on the card.

RE: Strange Problem after upgrade to 8.1(63)

You've already diagnosed what is happening yourself (the CLI MESSAGE events from Verizon) and also been given the answer in a previous reply, ask Verizon to turn off the message waiting indication that they are sending on that line. FSK can be used to send more things than just CLI, in this case its sending message indication and the IP Office is being triggered to expect a call that never actually occurs. The actual line is fine.

Stuck in a never ending cycle of file copying.

RE: Strange Problem after upgrade to 8.1(63)

(OP)
What I am saying is:

1. I already did call Verizon - and had any message waiting cleared, as well as had voicemail completely removed.
2. If I unplug the line, the problem goes away

3. I have already plugged it directly into the ONT eliminating anything to do with any other phones, alarms, or anything else plugged in.

4. I have changed/tested all settings, including even turning off callerID on the line.

As mentioned above, others have the same issue. I never said it was a CLI message from Verizon - I just figured I would rule that out as well because others have mentioned it as an issue.

RE: Strange Problem after upgrade to 8.1(63)

They all seem to have FIOS in common, what is this service? Some kind of emulated POTS line or is it a true trunk delivered on a copper cable?


Avaya Implementation Qualified Professional Specialist Technical Engineer (AIQPSTE)

RE: Strange Problem after upgrade to 8.1(63)

(OP)
To answer your question - FIOS has been coming through Fiber for a few years now. About 6 months ago, they moved over to Digital Voice, which I assume it's coming VOIP into the ONT Fiber Unit - then to a regular jack. It DOES provide the same power specifications of a pots line, as well as disco supervision, etc.

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.

I can't tell you if it did that before, because since it wasn't ringing, we didnt look at that.

It's definately something with that line, because we have another POTS (Emumlated Line) on Line 2 which is actually a Skype Gateway that acts as a POTS, and this one works fine in and out.. none of that. If we flip flop the lines, it does follow the line, so it can't be a bad port.

(Not sure if I mentioned that for the fun of it, there is a DSL filter in place too as suggested).

Really bizarre if you ask me.

RE: Strange Problem after upgrade to 8.1(63)

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


Avaya Implementation Qualified Professional Specialist Technical Engineer (AIQPSTE)

RE: Strange Problem after upgrade to 8.1(63)

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.

RE: Strange Problem after upgrade to 8.1(63)

"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...

RE: Strange Problem after upgrade to 8.1(63)

(OP)
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.

RE: Strange Problem after upgrade to 8.1(63)

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

BAZINGA!

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

RE: Strange Problem after upgrade to 8.1(63)

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


RE: Strange Problem after upgrade to 8.1(63)

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!

RE: Strange Problem after upgrade to 8.1(63)

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

RE: Strange Problem after upgrade to 8.1(63)

(OP)
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...

RE: Strange Problem after upgrade to 8.1(63)

(OP)
@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.

RE: Strange Problem after upgrade to 8.1(63)

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

RE: Strange Problem after upgrade to 8.1(63)

(OP)
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)

RE: Strange Problem after upgrade to 8.1(63)

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

RE: Strange Problem after upgrade to 8.1(63)

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 smile



"No problem monkey socks"

RE: Strange Problem after upgrade to 8.1(63)

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

RE: Strange Problem after upgrade to 8.1(63)

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 smile



"No problem monkey socks"

RE: Strange Problem after upgrade to 8.1(63)

Make sure your system is grounded.

RE: Strange Problem after upgrade to 8.1(63)

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.

RE: Strange Problem after upgrade to 8.1(63)

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/

RE: Strange Problem after upgrade to 8.1(63)

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.

RE: Strange Problem after upgrade to 8.1(63)

We're trying to find regular copper to run the same tests, but those are getting rare...

http://interconnexionsld.ca/

RE: Strange Problem after upgrade to 8.1(63)

Ok , I have this issue resolved but still requires more data to present to Avaya. Thanks to yankblan for pointing me in the right direction. This is a MWI burst of information. The fibre fed ONT device has a back end(at least with Bell) of Broadsoft as opposed to dms-100. I spoke to our techs in that department and they had run into a similar situation in Quebec. He was able to turn off the MWI indicator. Note that the customer did NOT have voicemail active on the line. The MWI is separate and left on whether or not they have have voicemail. After having it disabled I remained on site and no phantom rings for over an hour. He confirmed that this is standard operation of the Fibre to the business line. The burst occurs every half hour.
Going forward the people in that department will be testing with Our Avaya support group to see what can be done in future releases to stop the Avaya from ringing. Obviously there is an issue here with the Avaya as it only rings on certain releases. If I hear any more info I'll post here.
I would not be surprised if Verizon also uses the broadsoft platform as it also the back-end used in Hosted IP Voice applications.

RE: Strange Problem after upgrade to 8.1(63)

Thanks for the update, being UK based we don't and will not see this issue, but I have archived this post so I can direct other folks to it, this is bound to rear it's ugly head again. I suspect they change the sensitivity of the line card from release to release as some folks complain of it not detecting ringing on long run/weak lines etc, so it's a balancing act for Avaya smile



"No problem monkey socks"

RE: Strange Problem after upgrade to 8.1(63)

(OP)
So did you have the provider turn this off? Looks like this is the exact same issue with Verizon.

RE: Strange Problem after upgrade to 8.1(63)

Yes, I had the provider turn off MWI. In my case this is fairly easy as the company I work for is a major carrier. So it's just matter of calling an internal department. I can tell you this , it was a real hunt to find the correct department. Because the fibre to the business is so new to the company , few people have seen any issue's. I think if you contacted Verizon and ask them to turn it off you may have some luck.
I can imagine it would be extremely difficult to make a product that has to connect to such a wide range of carriers all over the world.
I think that was why Nortel was so rock solid on some things, they mostly designed the equipment for the canadian market and DMS100.

RE: Strange Problem after upgrade to 8.1(63)

They should add in the trunk settings a detection level setting,or like Panasonic, let a delayed ring (3 to 5 seconds) on caller ID settings. All we have is either clid on or off, which is not good. And yes I am in Québec, and Bell and Vidéotron have been inundated with this issue with Avaya customer since release 8.0 . Fortunately we are major partners with Vidéotron and have provided us stuff to lab with.

To quote South Park, blame Canada!

http://interconnexionsld.ca/

RE: Strange Problem after upgrade to 8.1(63)

I suspect this "new" 7.0 feature is the cause that this now happens:

CODE

3.11 Optimization for CallerID Detection on Analogue trunks
In IP Office Release 7.0 the timings for Analogue Trunks in relation to CallerID detection have been optimized. There should be no noticeable changes except for faster responses to incoming calls, particularly where the trunk is configured for incoming callerID but none is presented. 

BAZINGA!

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

RE: Strange Problem after upgrade to 8.1(63)

(OP)
I saw someplace a trick to actually add an announcement to the incoming group with no recording, and then set it to ringing - which will actually pick the line up (it's already doing that anyhow)before it routyes to the hunt group members. I wonder if this trick will work...

RE: Strange Problem after upgrade to 8.1(63)

(OP)
I see a new Service Pack 5 is out - before I go perform this upgrade, I was just wondering if anyone has already done that - and has any insight on if this problem seems to be fixed.

I don't see anything related in the release notes, but that doesn't always mean it's not a symptom of something else.

RE: Strange Problem after upgrade to 8.1(63)

We were told by Avaya that this problem will not be addressed in release 8.1, but will be corrected for 9.1 (apparently they will skip 9.0; apparently again). So stick to 8.56 if you don't have SCN and VM Pro.

Anyway, if you have SCN and VMPro, you should be using PRI or SIP...

http://interconnexionsld.ca/

RE: Strange Problem after upgrade to 8.1(63)

(OP)
That does not make a whole lot of sense. Besides downgrading or leaving at an older revision - since it's been quite some time, how has others got around this? Verizon seems clueless on the issue when opening service requests with them. Has anyone tried any thing else at all to stop the initial ring from happening? Usually I can come up with more than one way to skin a cat in this kind of issue, but I am at a loss on this one.

RE: Strange Problem after upgrade to 8.1(63)

We basically went with older releases; thing I didn't try are the new combo and ATM4U v2 cards; don't know if they handle that problem better.

http://interconnexionsld.ca/

RE: Strange Problem after upgrade to 8.1(63)

(OP)
Well there are others that had this issue, and probably got around it somehow. I am going to call Verizon one more time to see if they can do anything.. Surely someone has fixed this on their own. I am curious as to where they are stating 9.1 on this issue - seems silly.

RE: Strange Problem after upgrade to 8.1(63)

My 2 cents

just took ours to 8.1(69) from (43) and now I can set my watch to a phantom ring every 30 minutes. We have a mix of lines, Verizon copper, SIP, Comcast analog handoff, all are quiet, the only line that rings is the FiOS every 30 minutes. We use Combo and DS 8 mods with ATM V1 daughter cards. I am going back to (43) although I think (57) as stated is ok for this too. There is the Park button issue on (67) so that needs to be avoided in many cases too.

What's the lowest build that we can use ATMV2 mods on? Is this going to be an issue with FiOS if we can't downgrade low enough with those mods in the game?

RE: Strange Problem after upgrade to 8.1(63)

(OP)
@mikedphones - that is exactly the problem. The IP Office is picking up a refresh signal every 30 minutes. I am not about to spend any more money on this to buy ATM V2 if there is no proof this fixes the issue.
I did spend close to an hour on the phone with Verizon, and they told me I was crazy since we had VM turned off, and all they kept wanting to do was reboot the ONT, which doesn't do any good at all. It was like pulling teeth.

Another interesting thing to note, is even though we downgraded, in System Status application, it still flags those calls as incoming abandoned.. just does not ring through like it does in later releases. AS WELL, we went on a service call for an older 4.2 system, and for the heck of it, looked at system monitor (they have FIOS as well) - and it ALSO flags those abandons! (Yes, I know, we have been trying to get them to upgrade for quite a while now).

For the time being, we went into Verizons online settings and setup call forwarding on the POTS to a spare DID coming through SIP - and that solved it so that we can bring them to the latest release at this point.

Again, since FIOS is fairly common, I am amazed that either side of the house can't seem to understand this.

RE: Strange Problem after upgrade to 8.1(63)

Thanks Phone Guy. I went back to 8.1(43) all is well for now, however, I will have to do a dry run on a high enough build supporting an ATMV2 for a site with Verizon Fios to see if I can even install at all. Otherwise, I will have to be sure to have an ATMv1 on hand.

RE: Strange Problem after upgrade to 8.1(63)

Verizon needs to turn off MWI or VMWI, ask them to turn off both just to see if it fixes the issue(it will). Official stance for most carriers will be to downgrade the IPO to a software that does not cause this until Avaya officially fixes the problem.
It is not an actual problem with the FIOS service. This is normal operation. It just updates MWI more often than standard switching equipment. That update to MWI is a 20 volt AC burst.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close