Phantom MWI lamps each morning

[odiefoxydog]

Hi all,

I've several customers on 3300's on vers 9 and also now MCD 4 using embedded vm that are complaining that each morning their message waiting lamp is flashing but when they check their voicemail no messages are there. However once they've checked the mailbox the MWI is turned off.

The locate feature extn shows it is a call back, not a dialled mw lamp (all vm ports are in the vm group), they do not have a key appearance of 0 on their phones, nor are they members of any groups.

Any ideas?

 

[mitelmmaniac]

It could be a call back message then. when someone calls the phone it gives them an option to press call back. when they see the light flashing get them to press it and see what it says.

Desk Jockey Lunacy

 

[IrwinMFletcher]

You can look at the diag.dat file for voicemail (\vmail\c\voxdrv), if it's the vm ports you will see it calling the extensions. Take a look just after the 3am restart.

e.g.
09/15 12:29:34 INFO 8483-30 mwi: vb_dial[*3219220]

where *32 is the FAC to turn on the MWI, and it will do so on extension 19220.

 

[kwbMitel]

I remember other threads on the same subject but can't find them. My memory says that the VM was doing a refresh or someother at midnight or 3:00am or somesuch.

Look in the DIAG file as Irwin suggests and focus on those timeframes.

P.S. Your information provided was a refreshing breath of fresh air. You've covered virtually every question except possibly how widespread the issue is. Well Done!

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[YnotPhone]

Are the phones that are having this issue, the same phones everyday?

Are the phones that are having the MWI lamp on every morning on a Resilient System?

Users retrieve messages in the usual way, unless using speed-dial keys for this purpose. Upon failing back to the primary ICP, a device is notified of any messages waiting on the secondary voice mailbox. Since users may have messages waiting on both mailboxes (primary and secondary), their phone is notified of messages waiting on both.

If a user is using speed dial keys to access voice mail, two speed dial keys must be programmed: one for the primary ICP and one for the secondary ICP. The Message Waiting Indicator stops flashing when all messages have been retrieved from both ICPs.

 

[MitelInMyBlood]

I believe we've danced this dance a time or two before.

A "Callback" is from voice voice mail. That's what a "locate features extension" will show when there's MWI set against an extension by voice mail.

Are any of your VM "ports" being used as hosts for key appearances for any trick numbers in the system? If so, you must not use ports designated as MWI ports.

Check to be sure none of your VM ports themselves accidentally have callbacks set against them. That will cause you to chase your tail looking for weird MWI problems.



Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

Also something else I just remembered.

Multiline groups & hunt groups containing non-prime members (where all members are softkey apps) do really strange things if/when MWI or a callback gets set against them. For example, if the complaining user happens to have a softkey app of some DN that just so happens to be the first member of a multiline key group or hunt group and a callback happens to get set against that key, you will turn your world upside down looking for it.

Clearing the lamp only to have it mysteriously reappear the following day strikes an awfully familiar bell.

Original MUG/NAMU Charter Member

 

[odiefoxydog]

Hi All,

Thanks for your responses. Irwin, I'll check the log file to see when the MW lamp is getting turned on.

YnotPhone, on the one site in particular it is always the same phone which happens to be device 1 on the system, not sure if this is relevant. It's not a resilient switch, only a stand alone CXi and the extension was the first member of a ring group that overflows to auto atendant so not sure again if this may have been causing it. I have since deleted the extn from the ring group and added a multicall to the ring group instead. The multicall I created first on a different extension before adding it to the one with a problem.

MitelInMyBlood, if it was a callback set against the multicall why would the MWI go out after accessing voicemail for the prime extension? For info all 4 Vm ports are in the Vm hunt group and not used for anything else.

The problem was occuring on this site on Rel 9 and has continued after upgrading to MCD4.0. As I'm typing this I'm wondering if this may be similar to an issue I've had before when deleting a cluster element ID off a 3300 which still kept being seen by SDS, even after a data restore. Maybe the 3300 still thinks it's the first extn in the ring group even though it has been deleted? On this thread it did also used to have a key appearance of 0 that I had deleted to try to resolve the issue.

I'll maybe try a clean install of MCD4.0 instead of an upgrade!

The other site is being dealt with by another engineer so i don't know the full details.