Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Message Waiting Lights

Is there any way to not have a message waiting light go on for public distribution list messages? We have a site that has over 1500 users and they do not want message lights to go on if there are group messages being sent because of the time it takes to light all the lights and the strain on the Calista integration. Other message waiting lights (on and off) appear to be delayed when they send a distribution list message.<br><br>

3 REPLIES
Anonymous
N/A

Re: Message Waiting Lights

No, the notifier component (the guy that's monitoring everyone's inbox) doesn't make any distinction about the source of the message or how it got to your inbox. Whenever a change is made in a subscriber's inbox, the notifer filters for new messages that are tagged as voice (i.e. they have a message class of IPM.Note.Voice.Unity) and if there's at least one that's marked unread, it'll trigger the lamp to go on if it's not already on and vice versa.

It'd be very difficult in Exchange to have to open each message and determine if it was sent to a DL (since Exchange "flattens" the delivery list, this is tricky). Even if possible this would add a lot of overhead to the mailbox monitoring process since we'd actually have to open each voice mail message instead of just filtering on it's message class.

In general, I'm reluctant to be selective about which messages trigger lamps/notifications... These are the types of things that cause calls to support with complaints of "delayed messages" and "I had a voice mail, why wasn't my lamp on or why didn't I get paged" etc... Also, things get sticky since you can address voice mail messages to many recipients (i.e. multiple DLs and individual subscribers). How would we determine which destinations had their lamps lit and which didn't?

One possible compromise would be something like not turning lamps on for messages sent with low priority. We can filter for the priority flag without having to open the message itself, which will keep the overhead down. Of course you'd still have some potential confusion when folks picked up their phone to check messages and discovered they had one or more even though their lamp wasn't on. This would also require that folks sending messages to DLs remember to mark their messages as low priority. But, that said, I still think it would be a better option than going the route where all messages sent to DLs don't trigger lamps.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: Message Waiting Lights

Jeff,
Thanks for the quick reply. I see now that this has been on the forum once or twice already. The one part of your reply that seems like an option is the last paragraph where you refer to sending the message as a low priority and not lighting the light for low priorities. How would we do that? Would tech support have to log in to flag it as such? If we had a distribution list that the customer was aware was going to be a low priority dl, could we just flag that one particular dl automatically to be low priority and not light MWL's? This end-site is a college campus environment where they would know when that particular dl would be used. Any more help on this would be appreciated.


Anonymous
N/A

Re: Message Waiting Lights

Sorry if I was unclear... these are not capabilities of the current product. These would be engineering changes if we were going to support not lighting lamps for low priority messages. It can't be done today.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

146
Views
0
Helpful
3
Replies
CreatePlease to create content