Embedded vm delayed messages

[Hawaii5O]

Customer claims that they recieved thier message a day after it was left. Is there a log to check when messages are delivered?

 

[kwbMitel]

Yes, but you must be familiar with FTP directory access and navigation.

A program like Filezilla can help

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

 

[Hawaii5O]

OK once I can find out when the messages are being delivered. The next question, why were they late?

 

[kwbMitel]

[tt]>0 times out of 10 the message was late
<1 times out of 10 the message was on time but the user is lying for reasons unknown
2 times out of 10 the message was on time but myterious circumstances prevented reception
3 times out of 10 the message was on time but the user missed it thru user error
4 times out of 10 the message was on time but the MWI lamp failed in some way
[/tt]

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

 

[nytalkin]

No such thing as late messages. Late for work, yeah. Didn't check voicemail for a week; seen that. MW light didn't light; been there too. Some times a user with multiple messages listens to the first one, deletes it then hangs up. MW light gets turned off until next message is delivered. User logs in and finds old messages. Technician receives call for "LATE MESSAGES".

NO GOOD DEED GOES UNPUNISHED!

 

[kwbMitel]

Nytalkin - Late messages do exist. I've seen it with my own eyes, but they are as rare as sightings of the Loch Ness Monster.

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

 

[Hawaii5O]

Opened ticket with Mitel Tech support. Error logs showed that I had Zone 001 and 002 were not able to communicate. He said these errors were slowing down the processor. I removed the Zone programing since there wasn't any real need for it. going to monitor again and see if OLD Nessy appears again

 

[kwbMitel]

As I mentioned in a different thread, Hard Drive read/write is a relatively low priority for the system. I realise now that I should have asked how long the messages were delayed. I will add that to my question list for this issue.

For the record, how long were the delays?

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

 

[nytalkin]

KW - I got a Late message once. Turns out she wasn't pregnant.

NO GOOD DEED GOES UNPUNISHED!

 

[Hawaii5O]

Messages were one day Late. Approx 16hrs.

 

[dryaquaman]

I've seen what appears to be delayed messages but turned out to be that the user had keys on the phone that were in a hunt group. A VM message would be delivered, the VM would light the light but it would be the phone that had the 1st appearance of the 1st member of the hunt group.
Another user would delete the message and it would turn off the other users MWI. The next message the user would get to his own phone would relight the light his MWI and (bingo!) a "delayed message".
Took a bit to find the issue but now that's one of the first things I look for.

Ralph

 

[kwbMitel]

Hawaii50 16 hours is too long for processor errors to apply.

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

 

[IrwinMFletcher]

The diag.dat file will show when the MWI message was sent to the phone, you should also be able to figure out when the person listened to the message. Get specifics from a user and look at the file. It's pretty easy to read through.

 

[kwbMitel]

Irwin - Would you be interested in writing a FAQ for how to obtain the file? I think this question comes up often enough and you are my acknowledged expert on the subject.

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

 

[IrwinMFletcher]

Possibly. I would be more inclined to write something up that solves a particular problem though, like this one, rather than a general how-to without specifics.

Hawaii, if you would like, post the diag.dat file (located at /vmail/c/voxdrv on the system) and the timing details of the vm mailbox in question and I can run through it and provide a FAQ for the process.

 

[kwbMitel]

Irwin - If the Diag file gets delivered. Could you document the scenario then for the FAQ page. This example would cover most scenarios.

Step 1 - Acquire diag.dat file (complete with method for doing so)

Step 2 - Open file using ----

Step 3 - Observe user accessing MB @ HH:MM

Step 4 - Observe message delivery @ HH:MM

Step 5 - Observe user action @ hh:mm

Conclusions

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

 

[IrwinMFletcher]

kwb, As I look at the files I have access to right now, this may not actually provide the level of reporting that he is looking for. I know at one point more of the activity was reported in the logging, but perhaps this has been filtered out semi-recently.

I just started to write up an FAQ, but if the info in the file no longer amounts to much, there isn't a need for it. Do you have a sample file I can use?

 

[kwbMitel]

I don't have one handy.

The key points to the FAQ are:
- File name
- Where/how to get it
- What MWI activation looks like (general sense)
- What Login/Logout looks like
- What Play/Keep/Discard/Skip Message looks like

Analysis of the data is specific to the problem. In my opinion, the log is fairly self explainitory once you can get your hands on it.



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