MWI Class of Service Options

[hsearson]

The question is based on the things I did below, do you think this resolved the issue of the MWI flashing without a call back msg or voicemail in the embedded mailbox?

I have a MCD 4.1 system in which the MWI flashes with no known call back message or voicemail.  The voicemail is embeded. 8 port capacity. The voicemail hunt group had ports 2-8 which the 'recorder' hunt group had port 1 (Record a call). 

I changed this by putting ports 1-7 in the voicemail hunt group and port 8 in the record a call hunt group.  I have heard the there are specific ports that send the MWI activate/deactivate msg to sets.

Then to prevent sets from accidently being the cause, I disabled "Send Message" and the "Message Waiting" options in their COS which prevents these sets from even using the FAC to do so.

At this point the situation is being monitored and the customer will report any more flashing MWI sets.

So what do you guys think?

[wiseguy]

I don't think that this is a way forward. The EMEM normally uses the last channel to activate MWI waiting. That is now not part of the VM huntgroup. If you say that the Light was flahing without a message what did the LOC FEA EXT xxxx tells you?

[ralph]

I'm fighting through a similar issue right now.
Ver 4.1 with embedded.

Multiple users share a single phone.   A user has a DID number assigned to a key on a phone along with a message key.
The message key is lit.   Pressing it brings you into the "please enter your password" of the users vm.
There are no messages.  Leaving a message for the user and deleting it does not resolve.  Dialing <feat On>+<ext> and then <feat off>+<extn> doesn't resolve.
Can't remove the key from the phone because "Line is in use".

I set a different users phone up as a Voice mail port, put the phone in each hunt group and then attempted to deactivate the light.   No good.
I can delete the MSG key by adding a Superkey to the phone and deleting it at the set itself, but if I add it back so the user has a msg key then it re-activates.

I'd like to turn the DID key into a real set and then try it, but....   don't have any licenses to work with.  No IP set or analog lines.

This has been a real pain.

I'd like to see Mitel and a command line to deactivate msg keys.
And...  While I'm on that subject, I'd really like to see Mitel add the ability to, from the command line, activate/deactivate any feature on any phone that the user could do at the set.
I work from our remote center.  This would save a lot of grief since I get a lot of tickets because a user was screwing with their phone.

Ralph

[ralph]

Finally got mine resolved.
Here's what I did: 
Added the key to a second phone along with the message waiting key.
The msg wtg key on the second phone was not lit but the original one was.
Dialed the lamp on code followed by the lamp off code.   
This cleared the lamp on both phones.

What a pain.

Ralph

[hsearson]

I agree, I had to deal with the same issue as well. As well as flashing DSS/BLF buttons on a pkm and the sets are not even in DND.  I had to remove and add the DSS/BLF buttons back on to fix. What's up with that?


@Wiseguy, I believe you in that last port sending the activation/deactivation msg. I was thinking it was the first one. I will have to make sure there are no flashing MWI lights and switch the hg members around again. 

[hsearson]

It's still going on here. On a 5340, I'd see the envelope key flashing, press it and it says No Message. 

I'm wearing out that Feature Access Code turning it off.

[ralph]

Are any of your VM ports in hunt groups other than the main VM hunt group?
We run into issues when we devide up the ports for different greetings.
If  you have to do this you need to (1) be sure ALL ports are in the main hunt group and (2) be sure the main hunt group is a lower exten number than any other of the groups.
i.e.  Main hunt group = 555, other groups would be 556, 557, 888 etc.

Ralph

[hsearson]

Our main hunt group 4400 has 8 ports 4401-4408. I removed 4408 from it and added it to a recrder hunt group for record a call.

[ralph]

4408 can still be in the VM hunt group.    If it's not it will cause a problem with the message waiting lamps.
The symptom will be that a light will not go out because it was lit from your call record hunt group and it was deactivated by a port in the VM hunt group.

I'd expand your call record group by a couple of ports and then add all ports into the main VM hunt group.   Be sure both are set up in terminal hunt mode.

Ralph

[Mattmayn]

I would also suggest that you don't use the last port for anything like RAC. It is the one that handles MWI so it is best to leave it in the VM group only.