I am having a problem with MWIs on my 7960 IP Phones. I've read the other posts (as many as I could find), but the don't resolve my problem.<br><br>The MWI gets set correctly, but they don't get turned off (so I thought). When I looked into it further, I'm finding that after I read a message, the light goes out, but comes right back on. When doing this and looking at the status monitor, it seems that Unity is sending the MWI on-code several times. My guess is that is why they appear to be staying on, because the messages are being read while Unity is still intermittently sending the on-code. Anyone have any insight on this issue... workarounds? I could schedule a system-wide reset every morning, but I'd rather fix the problem if there is one.<br><br>
also remember that if you hang up after reading a message Unity will mark this message new unless you tell it otherwise. It's best to test this with an Outlook client open for the inbox in question so you can see if the message(s) are being set to unread or not.
Marking messages unread when you hang up without taking action on them is a configurable behavior, by the way... by default, however, this is the case.
I've been testing this by being in the Outlook inbox and marking the messages read and unread. I mark it "read" then I wait, then I mark it "unread". I see the light go out, then come back on immediately afterward. Again, in looking at the status monitor, It shows Unity sending the MWI "on" code about 6 times with about 5 seconds between each attempt. Is this normal behavior?
I think the TSP thinks that the lamp attempt failed when it really didn't. That would explain why it keeps trying and why the SA lamp status says "off". It will say "off" if it thinks it has not successfully turned it on. The fact that it turned back off might be due to the Noitifier sneaking in an off request when you marked the message as read. But, we'd have to see traces for sure.
Do you have any overlapping DNs, route-patterns or anything else close to what the MWIOn/Off DNs are?
Just for kicks, cram a "#" at the end of the TSP's MWIOn/Off DN config and see what happens (i.e. if the TSP's MWIOn DN is 100, make it 100#).
Problem resolved: thanks to the last post, I looked at my MWI on-code, and found that it's the first two digits of another route pattern. I tried putting a # at the end in the TSP, but that just caused the light not to work at all. I changed the code to something completely different, and it works fine now.
As a re-cap, it did seem that TSP kept trying to send the on-code, and it never got confirmation that it went through, so it kept trying, which caused it to reset the MWI light after the message was actually read. For further reference, I am including all the symptoms I had for this problem below: - Unity SA shows the MWI status as "Off" all the time. - When a message is marked as "read", the Unity Status Monitor shows the MWI code being sent repeatedly (6 times for my situation). - From my phone, dialing the MWI on-code doesn't light the light. - After a message is read, the light may flash off, then back on again.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...