Showing results for 
Search instead for 
Did you mean: 
Aseem Anand
Cisco Employee
Cisco Employee


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.

Components Involved:

Process Flow:

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


SIP integration:

>>>> Conversation manager on CUC initiates the SIP stack to send out a SIP notify to CUCM:

NOTIFY sip:216181@ SIP/2.0
From: sip:;tag=185be2450fa4498f9ad928a998f4cc11
To: sip:216181@
Via: SIP/2.0/TCP;branch=z9hG4bK83d91e663e4d47768465116b5a37666c
Max-Forwards: 70
Contact: sip:
Call-ID: faa6de08ae424acc8dda1cc260e732ed@
CSeq: 300 NOTIFY
Event: message-summary
Content-Length: 73
Content-Type: application/simple-message-summary

Messages-Waiting: yes
Voice-Message: 4/0 (0/0)
Fax-Message: 0/0 (0/0)

>>>> Message waiting manager creates a message waiting process for that extension:

91495542.000 |10:12:37.303 |SdlSig   |SsInfoReq                              |wait                           |MessageWaiting(2,100,134,2267308) |MessageWaitingManager(2,100,133,1) |2,100,14,8121954.2863^^*    |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Type=0 Key=0 Node=2 Party=44401597 DevId=(2,81,1) CSS=947a4fc1-c861-eb04-090f-c80b57cff533 dn=ti=1nd=216181pi=0si1 FeatId=122 FeatVal=2 WhichLamps=0 LampPersis=0 Signal=0 Cause=0 clientCodeReq=F authCodeReq=F numVoiceMsgNew=4 numVoiceMsgOld=0 numVoicePriNew=0 numVoicePriOld=0 numFaxMsgNew=0 numFaxMsgOld=0 numFaxPriNew=0 numFaxPriOld=0 FDataType=0opId=0ssType=0 SsKey=0invokeId=0resultExp=Fbpda=F

>>>> Message waiting process sends out the da request:

91495542.001 |10:12:37.304 |AppInfo  |MessageWaiting::sendDaReq dialingPattern=216181 dialingPartition=33b00713-6550-607d-3c37-61a716556c28 voiceMailbox= orig digitString=216181, cmDeviceType 0

>>>> Message waiting process asks the DB layer to update the MWI status:

91495545.000 |10:12:37.304 |SdlSig   |DbVoiceMailUpdtReq                     |initialized                    |Db(2,100,208,1)                  |MessageWaiting(2,100,134,2267308) |2,100,14,8121954.2863^^*    |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0] 02000000 01010101 04000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00617043 b0ce9c90 f02cc086 00000000

91495545.001 |10:12:37.304 |AppInfo  |DB: CFastAccess(EXEC dblSetMwi_)
91495545.002 |10:12:37.304 |AppInfo  |DB: SQL1[execute procedure dblSetMWIEx('216181', '33b00713-6550-607d-3c37-61a716556c28', 2, 1, 4, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0)]

Skinny integration:


>>> VM port sends out a stationinit message with the MWI notification:


This notification message from CUC contains the target extension, MWI extension and message count.


12:52:07.094 |StationInit: (0002591) StationMwiNotificationMessage mwiTarget=28439 mwiCtrl=481099 msgsWaiting=1 totalVm(-1/-1) priVm(-1/-1) totalFax(-1/-1) priFax(-1/-1)|4,100,50,1.1761524357^^CiscoUM1-VI39


 >>> CUCM respond back with MWI response:


12:52:07.096 |StationD:    (0002591) TX StationMwiResponse: mwiTarget=28439 result=0.|4,100,50,1.1761524357^^CiscoUM1-VI39

Troubleshooting MWI:

(a). Checklist under telephony integration:

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:

>>>> CUC sends out a Notify to CUCM:


NOTIFY sip:1000@ SIP/2.0

From: sip:;tag=03d2231777d0465aa329d31db6e02e16

To: sip: 1000@

Via: SIP/2.0/TCP;branch=z9hG4bKa8092e71a93d41f68862e887250d29a2

Max-Forwards: 70

Contact: sip:

Call-ID: 3af731fa29d5466c89b2c6c6803e3ff1@

CSeq: 300 NOTIFY

Event: message-summary

Content-Length: 73

Content-Type: application/simple-message-summary


Messages-Waiting: yes

Voice-Message: 1/1 (0/0)

Fax-Message: 0/0 (0/0)


>>>>>> CUCM will response with a 503 service unavailable error:


SIP/2.0 503 Service Unavailable

Via: SIP/2.0/TCP;branch=z9hG4bK76d6868527bc46c9814f2b52390d0325

From: sip:;tag=8979f8a2d55640cf8e710118dbe4dda3

To: sip:1000@;tag= 1877519591

Date: Mon, 03 Feb 2016 15:42:31 GMT

Call-ID: d4f7d9bd989b4dde8926559173d11968@

CSeq: 300 NOTIFY

Warning: 399 LODKSCUCMUCSPUB01 "Unable to find a device handler for the request received on port 35410 from"

Content-Length: 0


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:

Skinny Integration:

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.

SIP integration:

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".

Thank you

Bikramjit Singh
Community Member

This is a good doc. It is very lucid and informational.


Excellent Doc..!!


very good  document Aseem...

Abhishek Singh
Cisco Employee
Cisco Employee

This document kills it :) - absolutely covers all the aspects in terms of isolating it.


Abhishek Singh

This is a fabulous document. Thank you


Very good post

Thomas Buchholz

Thanks for this, after checking all seems to be fine, but after Callmanager Certificate renewal MWI doesnt not work.

We can dial manually fro ma phone to switch MWI on and off.

But it seems that CUC cannot notify CUCM for new messages. We dont use SIP, just Skinny.


Any hint where we can search for?

Cisco Employee
Cisco Employee



Can you share the following for a failed scenario:


Notifier logs


Cucsmgr logs


CUCM logs






Outstanding presentation!


Thank you for your sharing, it's really helpful~

i had a problem with MWI indicator, which lid lamp not goin on when receive voice-mail,

and when i check phone-system on voice-mail-template in cuc, found out the wrong phone system is selected,

so i correct that, then MWI for voicemail get fixed and working..


thanks for this great document..

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links