Without any more info, it might be that the number of simultaneous alarms that can be in progress is limited so if you have too many set some will be delays (its somewhere in the help).
Vm ports are all in use. Check congestion alarms in system status>resources.
Blast from the past:
On NEC KTSs you used to be able to set a VM port to MW only. Its function was to use the vm port to turn on & off the mwi on the handset.
After some more troubleshooting, it appears to only be an issue when the secondary voicemail server is up. I suspect that somehow the replication of data between systems is taking priority or otherwise causing delays. I would expect that alarms and replication use the same scheduling mechanism, so maybe the replication schedule is interfering with alarms?
There is only 7 alarms and they are at least 15 minutes apart.
I have 48 voicemail ports and I've only ever seen about 10 in use at once.
When it fails to make the call at all, I can't find any reference to it in the logs at all. When it calls late, it shows the details of when it was scheduled and when it actually occurred, but otherwise the logs don't seem to indicate that there is even a problem.
Thanks lxtn. Hopefully 9.1.7 will take care of it.
Try to add an alarm which fires a call flow with a mail action.
That way you can compare the time the mail is sent with the time the alarm was scheduled.
So I've done quite a bit of testing and it looks like the issue ltxn posted is pretty much exactly what I am having issues with. As soon as the alarm gets triggered the first time, my vmpro replication status goes from up to date to in progress, and stays there indefinitely. The next alarm is delayed several minutes, and it eventually just quits working. My VMPro replication between servers also definitely quits working at this point, but it's really inconsistent. Weird things start happening, like wav files I recorded start disappearing, changes to auto attendants revert back, I lose variables I created, any changes made to the alarms revert back after a few minutes, etc. Seems like the old data on the secondary server intermittently gets sent back to the primary, instead of replicating the new data to the secondary. Good to know, this has been driving me crazy. Thanks.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.