Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

3300Mxe: Delayed Voicemails?

Status
Not open for further replies.

pichels

Technical User
Aug 1, 2005
313
US
Hi,

Has anyone ever heard of users checking their VM remotely and the system reporting no VM's for the entire day?

Then, the next day-morning - checking Voicemail remotely and finding a number of VM's were indeed left with date/time stamps for the entire previous day they were checking!

Make sense?
I've had this happen a few times and thought of re-moving the VM box and re-creationg but it seemed to be a glitch.
The time is set properly on the machine - althogh I do find it drifts and we need to reset.

We don't have any mgmnt software or even use NTP.

Any more details required? Mitel Software version?
Oour VM is the internal mail system that is built intio the 3300Mxe.

Thanks.

-SP
 
check system option superset callback message cancel time ensure its blank, secondly the embedded mail uses port 24 to turn lamps on and off so ensure someone has bnnot used as a rad
 
What the users say and what actually happens is 2 different things.

There is a VM log that can help. It can be extracted from the SYSdiag or obtained directly thru FTP.

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

1. SS Callback Mesg Cancel Timer = 24.
2. I have to figure this one out in Embedded Mail/VM? "ensure someone has bnnot used as a rad"?

Nothing in the Maint logs.
Vm logs -> System Diag Reporting?
Ok - I'll try to ftp the info.

Thanks,

-SP
 
As already mentioned by M1Tel, blank out the timer. If you leave it as is, all message waiting lights will go out after 24 hours even if the message is still unread in VM.

VM Ports can be taken out of the regular Voicemail hunt group and then used as a Recorded Announce Device(RAD). If the last port is used for a RAD, then Message Waiting Indication will become unreliable. The last VM port is used for setting message waiting. Check that the last port is in the regular VM hunt group.

_______________________________________________________________

If you did not take enough time to get it right the first time...

What makes you think that you have time to fix it?
 
Hmmm...
You are saying that if I log in to my vmail box there are no messages? Then, I log in to my vmail box the next day and there are messages from BEFORE I logged in yesterday?
If so, we have all seen this before on various products.
Sounds like a hard drive issue, perhaps with indexing. Call Mitel. They will quite likely tell you to reboot and/or upgrade.
Is the MXe redundant/RAID?

You can't believe anything you read... unless of course it's this sentence.
 
We've had this issue for years, and had a complaint today, i checked SS Callback Mesg Cancel Timer and it was set to 24 and i set it to blank, i hope that is our magic setting change :)

Im glad i came across this post!

 
I don't think that option will affect your issue.

The callback timer controls how long a lamp will stay lit until it is automatically turned off. I believe it is only applicable to voicemails that set MWI via Mitai Messaging (not embedded then).

The symptom usually is that on Mondays the user has Messages but no lamp. Your description of the issue does not mention a lamping component.

Suffice it to say, don't get your hopes up.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top