Turning off MWI

[grazedbymitel]

thread1329-1542954

I'm trying to follow the instructions to turn off the MWI light and failing when I try and add my set to the voicemail hunt group and get a message which says "Members must be stations or broadcast groups"

Help....

 

[dryaquaman]

Change your COS to match that of the VM ports.

Dry Aquaman

http://www.university-music-on-hold.com

 

[grazedbymitel]

Unfortunately this didn't work... same error

 

[Supernova99]

Are you trying to add a key or a physical extn?
only physical extns with the same cos as the rest of the voicemail ports will work
Once this extn is added make sure you make it DND and put it in the voicemail hunt group

Share what you know - Learn what you don't

 

[grazedbymitel]

I think my fundsamental lack of knowledge may be the issue... I have a Superset 4025 plugged into a floor socket which routes into my system. I can identify the extension in the LOC FE EX 4348 command:


Card Type : DNI Line
Circuit Location : 4 1 10 16 1
Extension : 4348
Active Features :
Message Waiting Lamp On
Dialed Message Waiting.
Callback Messages : 1
Call Forward No Answer External : 4332
Call Forward No Answer Internal : 4332
Call Forward Busy External : 4332
Call Forward Busy Internal : 4332

And I have set its class of service to include Voicemail and also tried just copying the COS of the voicemail ports.

I think maybe I'm missing something fundamental

 

[nytalkin]

Why would you be trying to add this extension to the voicemail hunt group?

NO GOOD DEED GOES UNPUNISHED!

 

[grazedbymitel]

What I really want to do is find a way to turn of MWI lights on phones whioch have been moved about and the light is out of sync with reality. This thread "thread1329-1542954: SX-2000 Can't delete msg wtg ind button from multiline" gives a method which I'm trying to follow.

but it isn't working.

maybe you know another way?

 

[kwbMitel]

If you are moving DNIC sets on 3300's or SX2000's your first step should be to check the status of the lamp on all sets before moving.

If you do not, the message lamp may get permanently stuck. The reason is that it can only be turned off when the original extension is returned to the port it was activated against.

You've been warned!


**********************************************
What's most important is that you realise ... There is no spoon.

 

[nytalkin]

If you think the voicemail turned the light on, make sure you have a mailbox with the extension number assigned with the proper message wating type assigned. Leave this mailbox a message. Login, listen to the message and delete it. See if the lamp is extingushed. If so, you may then delete the mailbox and the extension.

NO GOOD DEED GOES UNPUNISHED!

 

[kwbMitel]

@NyTalkin - MWI against DNIC sets is assigned against the port (and the specific extension). In the case being discussed here, the MWI was set against Extension XXXX on Port X, then Extension XXXX was moved to a different port. This being the case, the only way that message will ever be turned off is to return extension XXXX to port X and then involk measures to turn it off. It will never be turned off until the original extension is returned to the port.

I will not claim 100% certainty in the above but my confidence is quite high.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[LoopyLou]

does messsage waiting status get backed up. Datasave, restore?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[kwbMitel]

Yes it does. Restore will not help. I've been down this road. The definitive word on this would come from MitelInMyBlood as his experience with this issue exceeds mine by several factors of 10. I'll see if I can get him to chime in.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[nytalkin]

I agree KWB. He's got to get the original extension back on the port and have the voicemail send the off code. I have had some success by removing the entire port from the system; i.e removing the dnic reference and reassigning a set and extension.

NO GOOD DEED GOES UNPUNISHED!

 

[MitelInMyBlood]

Note that LOC FE shows that the DN has dialed mwi enabled, not to be confused with a callback, ie, that set by your VM system.

Dialed MWI can be cleared either by the extension that set it in the first place or cleared by any extension that is up or downstream via the network, ie, on a different PBX. With the SX2K you can simulate this with back-to-back trunking then performing a direct trunk select to sieze an outbound trunk then send the MWI cancel command across the trunk. Not sure but you may be able to accomplish this via DISA.

Mitel some years ago sent out a TSB (tech bulletin) on this suggesting that the sysadmin disable dialed MWI in all COS forms associated with users to prevent what has happened to you.

As a matter of routine we always did a LOC FE E on every extension when we did our mov/swaps, even when we started doing them via OPSMAN otherwise you could end up with an errant MWI light from VM. This is what spawned the idea to put your bench phone in the Voice Mail hunt group with DND Permanent set against the prime # (so you can use that phone to toggle MWI lights).


Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

For grazedbymitel

Perhaps it wasn't clear that in order to control your MWI lamps with your bench phone that your phone has to first be added to the voice mail hunt group.

For example if your users dial 9999 to reach voice mail, then add the prime line of your phone to that group. You should have two different classes of service for the ports in your voice mail hunt group. One of those classes of service is for the regular (answering) ports, the other is for those ports that are used to set and clear the message waiting lamps. These two hunt groups will be similar if not identical except that one will have "Do not disturb permanent" set to "yes" - this latter class of service is the one you want to assign to the phone that you plan to use for toggling MWI lamps on & off with.

once this is done then look at your FEature access code assignment form to find out what the feature code is for turning off the message lamp, say for example it's "#42" (that's what ours is, yours is likely to be different)

Now, with your phone assigned to the voicemail hunt group and with the class of service set correctly, simply use your phone to dial the voice mail feature code followed by the target extension, i.e., #42-1234 (where 1234 is the target extension)



Original MUG/NAMU Charter Member

 

[kwbMitel]

MIMB - Looking for clarification regarding your first response.

My Understanding:

A MWI is set against a port P1 by VM that has extension E1 configured.
While the MWI is active, E1 is moved to port P2 and E2 is moved to port P1
E2 will have an active lamp that cannot be turned off by any standard means.

Option1 - Restore E1 to Port P1 and deactivate the MWI
Option2 - Send MWI deactivation code via remote system over MSDN trunk
Option3 - Send MWI deactivation code via Loopback trunk or possibly DISA

Is this correct?

**********************************************
What's most important is that you realise ... There is no spoon.

 

[MitelInMyBlood]

Yes. Absent an available MSDN trunk, I'd be tempted to set up DISA even temporarily if they don't already have it (then kill it afterwards as it is a gaping hole for toll fraud).

The diagnosis is correct in that a move swap will not bring the MWI lamp with it and if there's a MWI set against the PLID it will forever be there (until cleared), or worse if set against a MWI line appearance you'll never be able to deassign the PLID.

What is the result of issuing the command STAT MLS PLID?
It's been too long so I don't regall if you can take the previous command one level deeper (to the line key level) or if stat mls plid will give you all the keys. Obviously we need to know the DN that MWI is set against. Also is it true MWI (a callback) or is it Dialed Message Waiting? The latter is what I was referring to with attacking from DISA or from an MSDN trunk. I've never tried those methods against a true callback.

Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

One final comment.... I tried this last week just to verify.

VoiceMail Message Waiting, i.e., a "CALLBACK" (not dialed message waiting) can only be cleared by the DN that turned it on (or by a Voice Mail Hunt Group). In the latter case it does not need to be the same voice mail hunt group as the original one - you could create another hunt group, but the hunt type would have to be "Voice Mail".

Turning the lamp off via an MSDN (or DISA) trunk only works for Dialed Message Waiting, not a callback.



Original MUG/NAMU Charter Member