Nupoint Delayed VM ??

[shawnb345]

Has anybody had e this issue with Delayed VM?
I had an executive work all weekend and he was checking vm.
He comes in on Monday and has 2 from sat, 5 from sunday..

We have a Nupoint VM server, along with 5 3300's

Our phone Vend wanted to do an offline verify as a "might help" it but said they wanted to speak with Mitel first.

We ALWAYS do everything after hours so our customer does not get effected.

 

[Lundah]

yes an offline verify would be the first thing to try. This sort of thing happens all the time, and not just with NuPoint. If it continues, start up event logger and track all activity on that mailbox.

 

[MitelInMyBlood]

Delayed message waiting is something that used to plague us until we set our MWI refresh task to happen twice a day (at 4 AM and again at noon)

A number of things can occur that can affect the MWI indicator. Initially the flag was being missed by occasional extensions because the nightly dbms check was still running. Other times people were performing Move/Swaps from the command line (bad, bad idea) without first checking the status of the MWI lamp. If it's on before you do a move/swap, ot doggone better still be on afterwards else you're going to have an unhappy client.

MWI indicator status also does not survive a software upgrade or data save/restore task, so whenever you perform a data save/data restore, be sure to refresh your MWI else you'll have unhappy clients.

Be VERY AWARE of MWI port status in your VM system whether NuPoint or competitor's product. If the VM system sends a MWI flag set bit it thereafter assumes the lamp is lit, whether it's lit or not. Some VM systems (ie, Octel) will not resend the MWI flag set bit for any subsequently received messages because it things the flag is still set. There's an option on an Octel system to use AT&T Message Waiting, which means to reset the flag with every new message, but it does not work.

When working on an OCTEL system be doggone sure to quiesce the MWI ports before swapping a TIC card else you will get bitten HARD with MWI lamps out-of-synch. Voice of experience.

 

[TheMitelGuy]

Does this executive use Unified Messaging?
When you say there was a delay, are you talking about the message waiting indicator OR the messages being deposited into the mailbox itself?

 

[shawnb345]

He does not use UM, The delay is messages being deposited into the mailbox.

 

[kwbMitel]

There is an FCOS bit that can be set up to Trace all MB Activity. (In the 250's)

It will show exactly when messages are received and how the user is handling them.

My experience is that the user is reponsible for this issue over 50% of the time.

Of the remaining 50%, most are due to the indicator not being lit (If your issue is pimarily after weekends check to make sure the 24hr cancel message is not turned on)

Sometimes a port will get stuck off hook and the message only gets delivered after hangup. Make sure the ports are limited to the amount of silence they will record or turn off silence compression.

99% of issues resolved by above.



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

 

[shawnb345]

ty, I'll check it out.

 

[Lundah]

The FCOS bit is 254. Copy the user's existing FCOS to an unused number (I normally just add a "1" in front of the existing FCOS), enable bit 254, and change the user to this. Then you can use the trace utility to see everything that happens to that mailbox.