aln

I have a customer with an IP412 which is losing connection with expansion modules for apparently no reason. It works perfectly for one or two days, and then strange things start happening: phones get locked or don't ring, calls get transferred to wrong destinations, incoming calls get queued but are not passed on to the groups, and many other funny things. After the happy customer calls us, I found that the LEDs indication connection with modules were unlit, and this is part of the log file related to one of the crashes:


22568063mS ERR: CM::Message Line not found
22568202mS RES: Wed 10/3/2004 22:47:32 FreeMem=20321156(34) NoCache=10203368 CMMsg=6 (6) Buff=200 896 999 1719 Links=7724
22575866mS PRN: GODTDMLink::LinkDown line id 5 transitioned to down
22575869mS ERR: Device Down 5
22576785mS PRN: GODTDMLink::LinkDown line id 4 transitioned to down
22576789mS ERR: DTExtn Line Down 4
22576789mS CMMap: a=0.17 b=0.0 *0
22576789mS PRN: ConfUnMap 1 0.17 (1)
22576792mS PRN: ConfUnMap 1 18.8 (1)
22576795mS PRN: ConfUnMap 1 1.16 (1)
22576800mS PRN: RealPhysicalMap 1.16 18.8 error IESTA2 80
(...)
22577214mS RES: Wed 10/3/2004 22:47:41 FreeMem=20333180(40) NoCache=10203368 CMMsg=6 (6) Buff=200 895 999 1719 Links=7745
22577644mS PRN: GODTDMLink::LinkDown line id 3 transitioned to down
22577647mS ERR: DTExtn Line Down 3
22578813mS CMExtnEvt: v=1004 State, new=Idle old=PortRecoverDelay,0,0,
22578832mS CMExtnEvt: v=1003 State, new=Idle old=PortRecoverDelay,0,0,
22578852mS CMExtnEvt: v=1005 State, new=Idle old=PortRecoverDelay,0,0,
22586827mS CMExtnEvt: v=1 State, new=Idle old=PortRecoverDelay,0,0,
22587841mS ISDNL3Evt: v=5 stacknum=5 State, new=Present, old=NullState id=29

I've found the following in the list of solved issues for 2.0(18), and it looks close to what was happening to us (autorecording is heavily used, though always in the user's mailbox). But this should be theoretically solved, as we already are at 2.0(18)

Auto recording to a different mailbox on a 412 no longer causes modules to lose
connectivity to the switch.

Ultimately, we decided to replace it with a 406 which runs perfectly - but the customer has bought the 412, and he doesn't want to have it back until the issue is conclusively solved. Any ideas? Is this a known issue that will be solved in some upcoming release? (Of course, our reseller tries to blame it on the server, the network, or whatever, but I'm quite sure is a bug in the firmware).

Cephas

You indicated that the 412 is 2.0.18 - what about the firmware on the expansion modules? Has it also been upgraded to the latest?

PBXtech.info

 

aln

Yes, it's 4.0(18) in all of them.