Presss the message Key. It should tell you what device left the message on the set. It will either say a voicemail port/ext or another users ext. I usually find this problem when an internal user calls another internal user and when there is no answer, they press the message key on their set thinking that they will get forwarded to vm. The only way the light will cancel by itself is when the device that sent the message is called back and it answers. A code is sent back to the set that had the message waiting light on to turn off the light as the message has been retrieved.
After you press the message key, you can cancel the light by pressing the soft key "erase" instead of the soft key Call. * = erase & # = call are the softkeys.
I have only seen that problem once and I was able to turn off the light using the feature access code for Message activation/deactivation (not sure of the nomaclature). Maybe try using another set to send a message to the problem set, then retrieve it to turn the light off. Might work.
Does the set have a mailbox? We have had issues where the lamp gets turned on by the voicemail and then the mailbox gets removed with the light still on. When that happens the only way to get the light off was to add a mailbox and leave a message on it, retrieve it and when the light goes out delete the mailbox.
Another option you could do is set your message lamp timer to a low value in system options, which will turn out all the lamps on the pbx. Onces the lights are off you can bump up the timer and do a lamp refresh.
Throughout this whole thread I didn't see any mention of what platform (200/2000/3300 ?) this is occurring on or what software. If on a 3300 or 2K and recent s/w go into ALL the class of service forms that you have defined (except your cos for your voice mail ports, and make sure you have:
1) Disable Send Message = YES 2) Message Waiting = NO 3) Multiline Set Voice Mail Callback Message Erasure Allowed = YES
These settings will prevent an individual user from arbitrarily setting a "callback" message plus it will permit someone who has an errantly-set VM MWI light already on to turn it off themselves.
I saw a SX2000 MicroLight once where the user had defined only one common class of service and had everything including his voicemail ports, trunks, etc all assigned to that same cos. That was a pretty stupid thing to do and was causing several problems.
Years ago, a vendor suggested this solution to the Message waiting lamp issue on an SX-2000 + DigitalSpeech voicemail system connected via COV ports.
Use Superset5(COV)phones to send feature access codes to turn off the message lamps. It seemed like a pretty jugheaded idea, but since we had extra ports, I went with it and put a set in the Phone Room and one on my desk.
With informed hindsight, I'm sure it was just that the SS5's had the same COS as the VM ports, but it worked.
A side benefit was that with the ass-ugly phone on my desk instead of the nifty white 430 I had previously, I didn't have to put up with status-hungry users whining for an upgrade from their black 410's. (My prime line was a 1937 North Electric Model 20 rotary phone with a sticker labelled: Y2K PHONE).
There is a bug with 5215 and 5207s where the MSG LAMP stays on, but there are no MSGS. I have not deemed what causes the issue, but when you press MSG it responds with "No Messages" (which is acquit) however the orange lamp continues to flash.
I have seen the problem corrected by pressing the MSG key twice. It is rare to get this error, but it does occur.
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.