Voicemail Pro Delayed MWL

[europait]

We have a client with nine sites in an SCN 500v2 R9.1.4 with centralized voicemail pro. There seems to be 2 possible issues going on.

1st issue is that we are getting intermittent delays on message waiting notification. End users report that they may check their messages and have some that are from earlier in the day or the day before and the light just came on. Or that they will get an email from the VM with the message and the light is not on but when they check the message is there.

2nd issues is less frequent but still occurring. End user will check messages at the end of the day and have nothing new. Come in the next day and have new messages from the day before previous to checking them at the end of the day.

I am sure that I have left out information that would be helpful, let me know if you need anymore details.

Thank you all in advance for any info/help or past experiences.

PS. We are a business partner and have been working with our distributor as teir 2. They don't have any real answers and dont want to escalate this to Avaya as they don't believe that it is going to be a covered event.

 

[amriddle01]

In order to escalate an issue the system needs to be under an IPOSS contract, if it is escalate anyway, that's what it's for. I suspect it isn't so they couldn't escalate even if they wanted to

 

[Jonjr88]

They will have you upgrade to 9.1.5 first either way. i would go ahead and try that!

 

[europait]

The client does not currently have IPOSS, they just cut support with there previous partner who always told them that nothing was covered and never pursued fixing anything. I have just gotten approval this week to move them to IPOSS and upgraded all nine sites from 500V1 5.0 to 500v2 9.1.4 in October. Is this something that would be covered under IPOSS. From the distributor It sounded like it would have to be an application or hardware issues for them to cover it and would be a chargeable escalation if not. I may have misunderstood.

Does anyone have any packet header or port info on the message waiting light that may help us wireshark this. We can setup wireshark on each end of 2 sites and monitor for the issue. It is very intermittent and not always the same site. Knowing the packet info would dramatically cut down on searching for the needle in the hay stack.

 

[joe2938]

This is a known issue and I have reported this issue to Avaya many times and was given the run a round so good luck, they wanted all kinds of traces configs etc... basically they want you to do their job. Hopefully some day this issue will be resolved in a future software release!

 

[IPGuru]

Are you sure the SCN is correctly set up for centralised VM?

Do they have additional VM Pro server @ any sites, if so are these correcty configured for operation as distributed servers (all SMTP settings on VMPRo correct)?

How stable is the network between sites? if the VM Pro sends a light lamp msg & it does not get recieverd it will not necessarily send another untill it thiks it needs to.

Misconfigured SCN setup is often a cause of issues & even if it is not whn you escalate to Avaya they will simply point at it & say "Sorry Unsupported" untill it is corrected.

They will also tel you to put everything on lates mant release before looking at anything so that should be your first action anyway



Do things on the cheap & it will cost you dear

 

[europait]

This SCN is setup correctly for centralized VM, and they only have 1 VM pro server.

The network is suspect and I am pointing to that as the cause. I think that the VM Pro is sending the packets and they may be getting lost on the other end. If I could find the packet header or port info that may help us to prove that it is the network with wire shark.
I have setup monitor traces with the proper triggers for monitoring mwl transmissions and we can see the proper info leaving when we leave a message. It appears that we could also see it on the remote system. The big issue is that we cannot recreate the problem during testing so we have to rely on good info from the end user when it does occur. Having port or packet header info will help us to weed through the data that we will

Yesterday I was able to see a case in action. The end user reported that they had no light but did have new messages. We could see in system status that they had 2 new messages and when logging into the voicemail box it said 2 new messages. We left another message and the light did come on that time.

I am planning on upgrading them all to 9.1.5 soon but I don't think that it will make a difference so I am trying to move ahead with the troubleshooting.