Is there a document out there somewhere listing the top ten causes for MWI synchronization problems out there somewhere? I had one user where MWI would not go on or off. Everyone else's MWI worked. I don't know what was different about this user BUT found that the only thing that fixed the problem was to reset the MWI by performing a reset under the user's mailbox in the CUC admin interface. I've read that if the phone system is offline when a mailbox status changes, MWIs get out of synch. Is there any other reason MWIs would get out of synch? And BTW does "phone system offline" only mean this: call setup to CUC has occured, connection with CM goes, caller completes leaving a message and then hangs up.
Finally, how does CUC determine that MWI doesn't need to be lit? Below is the cuNotifyer meesage I found regarding the mailbox that needed to be manually synced:
03/22/2010 20:17:17.887 |11764,,,Notifier,12,Billy Bob, mwi extension=8734: doesn't need MWI update with (Voice+Fax+Text)mail count= 11 and MWI state=ON|
I'm not sure I understand why CUC couldn't simply blindly send the mwi on or off every time the mailbox is fully read or every time the mailbox is unread in any way immediately after an event like leaving or check a message has occurred.
Finally, is there a CUC document available to the public or partners that highlights the architecture of CUC like there is with Unity?
Hailey has addressed the architectural and fundamental processes, but I did want to come in with a basic answer to one of your earlier questions. You asked (paraphrasing here) if there was a way to tell Unity to send another MWI "on" message to CUCM even if Unity thinks that the light is already "lit". If you have Unity 7.1, go to the phone system configuration (Telephony Integrations>Phone Systems) and then edit the phone system object pointing to your CUCM cluster. There is a parameter called "Send Message Counts". Enable this option.
Now, this feature is supposed to send updates to the phone so that it shows the number of voicemails that are in the CUC inbox. With SCCP integrations, the full intent of this feature is not available. However, I recall reading the feature guide and as I was reading this thread it made me wonder "what if...". So, I tested this out. If you check that box, CUC will indeed send a message notification to the CUCM each time the mailbox receives a new message. This works regardless of whether CUC already has a MWI-On state set or not. Now, that doesn't fully satisfy your needs but it does address at least one of the issues you saw and noted in your original post.
Another thing I guess you could look at and see if it works for you is tweaking the setting and timers related to resending a successful message waiting indication. Go to Telephony Integrations>Port Group. You will see your defined port groups. Edit one of the port groups. In the "Port Group Basics" configuration page you will see a section with multiple options for Message Waiting Indication. Take a look at "Retries After Successful Attempt" and "Retry Interval After Successful Attempt". Basically, these two parameters work together and it is a rudementary way to have the CUC system resend the MWI multiple times. The default behavior is to only send the initial notification. You can configure the system to send up to 10 notifications and you can specify upto 100ms in between each successful notification. I set this up in my lab and testing with MWI-On and MWI-Off scenarios. It works as advertised for both.
If you really have that many problems with MWI. You could also look at using the MWI resync schedule to be more aggressive than what most folks use. My experience is that most people set their scheduled MWI resync once a day (usually in the wee hours of the morning). With CUC, you can tweak the schedule to run more aggressively if you really needed this. Though, you have to take all things into consideration with respect to port allocation during your busiest hours. In general, I wouldn't recommend doing more than one MWI sync a day. If you have that many MWI issues, you have something else going on in your environment that needs attention. As Hailey said, MWI is simplistic but it works most of the time.
Outside of the above small contributions, I think that Hailey laid out all of the MWI ins and outs. Maybe one of the workarounds above will satisfy your needs. Though, none of them are exactly analogous with IMAP.
Please remember to rate helpful posts.
OK. So, the 3 scenarios that you noted are actually 3 cases where Cisco recommends that you go ahead and perform a resync of MWI after such an event has occurred. They are not the only cases where MWI could get out of sync; however, it is probably safe to say that it's highly likely that MWI would always be out of sync in these cases so that's why it's recommended procedure. There are a lot of questions to be addressed so I'll cover as best as I can.
First, let's look at how MWI works at a high-level. First, a .wav file (message) is queued so CUC checks that the mailstore is online. If so, the message is left in the user's mailbox and then CUC initiates an MWI event using the MWI on/off numbers. CUC is essentially going off-hook as the Subscriber and dialing the MWI on/off number. Now, the synchronization of MWI moves outside of just CUC as CUCM gets involved. CUCM updates the DB and real-time info which is replicated to the cluster Subscriber servers. The CUCM subscriber the user's phone is registered to then sends a SCCP message to the phone letting it know to turn MWI on/off (in this scenario, the light would go on because we're assuming a new message is being left for a CUC subscriber).
So, with Unity and/or CUC there are potential areas of failure which are well-documented in the link I sent you and there is also a Unity MWI troubleshooting guide that has a wealth of information in it as well. Sometimes, it's as simple as the subscriber account is not configured to update MWI. However, you could also run into scenarios where the system doesn't have enough ports to accomodate all of the calls it is taking and MWI requests. In these cases, you have to dedicate more ports for MWI or potentially add more ports (assuming you're not maxed out already). Since CUC has to talk to CUCM to actually get the phone to light up, another issue could be a network latency issue between those 2 systems.
On the CUCM side, DB replication within the cluster could cause issues with MWI. If replication is bad, then Subscriber servers may miss a DB update(s) that contains one or more MWI events. You can use the CU Reporting tool (or web to a phone) to compare what CUCM thinks MWI should be vs. what Unity/CUC says it should be. Another item of importance here is dial plan. The MWI numbers need to be unique throughout the cluster and your voicemail ports need to be configured with the proper CSS(s) so that when CUC goes off-hook, it can dial out properly.
For architecture questions, the best thing to do is look at the SRND and read up on the various deployment models. The link for the Cisco Voice Messaging section of the 7x SRND is http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/vmessage.html. I'm not passing the link blindly. I have to go back to it regularly to keep myself fresh on the best practices for Cisco. You'll also find info on CME and SRST there as well. In the context of your question, SRST and CME are very similar at the core but CME has more features. So, you can configure a failover architecture where phones failover to SRST or failover to CME based on requirements and etc.
I hope this helps as there really is no one single (or even simple) answer that can explain exactly why MWI can get out of sync. There are a lot of moving parts in the equation. Definitely look thru the SRND and the Unity MWI troubleshooting guide. While it focuses on Unity and not CUC, it still contains a lot of information and scenarios where you'd have to troubleshoot MWI synchronization.
Please rate helpful posts!