This document is to help you understand the concept of MWI when CUC is integrated with CUCM with the help of process diagram and sample traces.
What is MWI?
MWI stands for message waiting indicator. When a caller leaves a message for a subscriber, Cisco Unity connection notifies the phone system to activate the MWI on the subscriber's phone which is done by turning on the red light of the phone along with a blinking message icon on the Phone.
1. Call comes to IP phone and since user does not answer/busy, it goes to Voice mail.
2. When the call reaches CUC and user has to leave a voice mail, conversation manager answers the call. Caller leaves a message for the user.
3. NotifyQ is informed about the new message.
4. Connection Notifier's main function is to keep a check on the NotifyQ . When an event is placed in it, connection Notifier will check the user's mailbox to determine whether their MWI should be on or off. It then compares that with what state we currently think the light is in and, if it needs to change, queues the task.
5. In case of new message, the NotifyQ gets filled. Since the NotifyQ is actively being monitored by connection notifier service it instructs the Conversation manager to notify the phone system about the new message by sending a SIP NOTIFY message with Request URI header of user’s CUC extension & a skinny notification in case of Skinny integration.
6. When the subscriber listens to the message, Cisco Unity connection notifies the phone system to deactivate the MWI on the phone
>>>> Conversation manager on CUC initiates the SIP stack to send out a SIP notify to CUCM:
1. Check Telephony: Cisco Unity Connection Administration, in the Related Links list in the upper right corner of any Telephony Integrations page, click Check Telephony Configuration and click Go.
2.On CUC port group, make sure that the port group has check “register with SIP server” and “Enable message waiting indicator”.
3. Choose Telephony Integrations > Ports in Cisco Unity Connection Administration page and Confirm that there are voice−messaging ports for the phone system integration that are assigned to send MWI requests.
4. If you are having a CUC PUB/SUB setup, then make sure you have ports created for SUB as well on CUC.
5. Make sure that the order of CUCM servers is correct in port group on CUC. Browse to:
Telephony integration >>>> Port group >>>> Edit >>> Servers
It should be in accordance with the CM group assigned to the device pool associated with the SIP trunk/Voice Mail ports.
If the server list on CUC is not in accordance with the CCM group defined on the trunk then CUCM will send out a 503 service unavailable in response to the Notify from CUC. Here is a snippet from the traces:
Warning: 399 LODKSCUCMUCSPUB01 "Unable to find a device handler for the request received on port 35410 from 10.106.117.133"
7. If the issue is specific to certain users then make sure that the user is associated with the correct phone system on CUC.
8.You can try doing a resync of MWI if MWI is not working for any of the users:
9. Make sure that the MWI numbers defined on CUC are same as to what you have defined on CUCM.
Telephony integration >>>> Port Group >>>> MWI on & off extension
Note: In case of SIP integration MWI numbers are not created as CUC uses Notify message.
(b). Things to check on CUCM:
1. If SCCP integration is there, then make sure the voice mail ports should have the CSS which has the partition of the phones. 2. Dial the MWI on extension then dial MWI off extension, if the phone led become red after dialling MWI on, then the disappear after dial MWI off that means MWI on & off configured properly on you cucm. 3. Make sure that the MWI on and off numbers are unique and should verify it by checking in from route plan report on CUCM.
1. Check the following on the SIP trunk security profile:
- Accept Out-of-Dialog REFER
- Accept Unsolicited Notification
- Accept Replaces Header
In case of SIP integration, CUC sends SIP notify messages to the phone system to turn the MWI on or OFF so “Accept unsolicited notification” should be checked under SIP profile assigned to the trunk.
2. The calling search on the trunk should have the partition assigned to the directory number of user.
(c). Things to check on CUC for Platform issues:
1. Make sure the connection notifier service is activated on the primary server. 2. Cluster health check: Make sure the cluster is in healthy status with the output of the command "show cuc cluster status"
In unity connection cluster, while both servers can answer the calls and take messages but the connection notifier service responsible for MWI is activated only on the primary server and not on the secondary.
A good status would look something like:
show cuc cluster status
Server Name Member ID Server State Internal State Reason ------------- --------- ------------ -------------- ------ pubcuc 0 Primary Pri Active Normal subcuc 1 Secondary Sec Active Normal
A bad cluster can look something like this:
Server Name Member ID Server State Internal State Reason ------------- --------- ------------ -------------- --------------------- ccanslev01cuc 0 Secondary Pri Failover Critical Service Down ccavcltv01cuc 1 Secondary Sec Active Normal
3. Verify the enterprise dbreplication, a healthy cluster should have the replication status as 2.
You can check the replication using the command “utils dbrelication runtimestate” and is similar to what you have on CUCM or CUPS.
4. Check the the MWI Port Activity:
Step 1 In Cisco Unity Connection Serviceability, on the Tools menu, click Reports. Step 2 On the Serviceability Reports page, click Port Activity Report. Step 3 On the Port Activity Report page, select the applicable options for the report. Step 4 Click Generate Report.
5. In case of any delay in MWI, make sure that the CUC server is synched with an NTP stratum at a value less than 3 using the output of the command "Utils ntp status".