6.3 Message Waiting Indication (MWI) & Troubleshooting

6.3 Message Waiting Indication (MWI) & Troubleshooting

Message Waiting Indication (MWI) is the critical signaling feedback loop that alerts telephone subscribers to the presence of unheard voice messages. When a caller deposits a message, Cisco Unity Connection (CUC) notifies Cisco Unified Communications Manager (CUCM), which instructs the target Cisco IP Phone to illuminate its handset LED lamp and display an envelope icon on the liquid crystal display (LCD).

Diagnosing MWI failures is a frequent requirement in enterprise collaboration environments. Understanding the exact signaling mechanisms and protocol flows is essential for effective troubleshooting.

---

1. MWI Signaling Mechanisms: SIP NOTIFY vs. Legacy Outdial

Enterprise collaboration deployments implement MWI using one of two primary architectures: SIP NOTIFY MWI (RFC 3842) or Legacy Outdial MWI.

+-----------------------------------------------------------------------------------+
|                         MWI SIGNALING METHOD COMPARISON                           |
|                                                                                   |
|  METHOD 1: RFC 3842 SIP NOTIFY MWI (MODERN BEST PRACTICE)                         |
|  +------------------------+      SIP NOTIFY (Unsolicited)    +-----------------+  |
|  | Unity Connection (CUC) | -------------------------------> |   CUCM Cluster  |  |
|  |                        | <------------------------------- |                 |  |
|  +------------------------+            SIP 200 OK            +--------+--------+  |
|  * No call placed; port busy for an instant                           |           |
|  * Fast, lightweight, scalable IP signaling                           v           |
|                                                                [ IP Phone Lamp ]  |
|                                                                                   |
|  METHOD 2: LEGACY OUTDIAL MWI (DEPRECATED / TRADITIONAL)                          |
|  +------------------------+        Dials MWI On (e.g. 2500)  +-----------------+  |
|  | Unity Connection (CUC) | ===============================> |   CUCM Cluster  |  |
|  |                        |        (Seizes Outdial Port)     |                 |  |
|  +------------------------+                                  +--------+--------+  |
|  * Consumes physical/virtual Voice Messaging Ports                    |           |
|  * Prone to port starvation during peak traffic                       v           |
|                                                                [ IP Phone Lamp ]  |
+-----------------------------------------------------------------------------------+

Method 1: RFC 3842 Unsolicited SIP NOTIFY MWI

In a standard SIP integration, CUC utilizes the RFC 3842 standard (Session Initiation Protocol (SIP) Event Package for Message Waiting Indication and Summary).

When a message state changes (e.g., a new message arrives, or an unread message is marked read or deleted), CUC sends an unsolicited SIP NOTIFY request directly to CUCM across the existing SIP Trunk.

Anatomy of an RFC 3842 SIP NOTIFY Message:

NOTIFY sip:2002@10.1.1.10:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.10.51:5060;branch=z9hG4bK5f6a7b8c9d
From: <sip:5000@10.1.10.51>;tag=cucmwi102938
To: <sip:2002@10.1.1.10>
Call-ID: 1122334455@10.1.10.51
CSeq: 1001 NOTIFY
Max-Forwards: 70
Event: message-summary
Subscription-State: terminated
Content-Type: application/simple-message-summary
Content-Length: 94

Messages-Waiting: yes
Message-Account: sip:2002@10.1.10.51
Voice-Message: 2/4 (1/2)
Fax-Message: 0/0 (0/0)

Key header fields and syntax breakdown:

• Event: message-summary: Identifies this transaction as an MWI state notification.
• Messages-Waiting: yes: Directs the switch to illuminate the visual lamp (no turns the lamp off).
• Voice-Message: 2/4 (1/2): Reports detailed message counts formatted as: $\text{Voice-Message:} \; \frac{\text{New Normal + New Urgent}}{\text{Old Normal + Old Urgent}} \; \left( \frac{\text{New Urgent}}{\text{Old Urgent}} \right)$ In this example, the user has 2 new messages and 4 old messages (with 1 new urgent message and 2 old urgent messages).

Method 2: Legacy Outdial MWI

In legacy SCCP or older telephony configurations, CUC does not transmit SIP NOTIFY packets. Instead, CUC treats MWI lamp toggling as an outbound telephone call:

1. In CUCM, administrators define two dialed numbers: Message Waiting On (e.g., 2500) and Message Waiting Off (e.g., 2501).
2. When extension 2002 receives a voicemail, CUC seizes a configured Dial-Out Voice Messaging Port.
3. The port places a brief call to the MWI On number, identifying extension 2002 as the target; CUCM turns the lamp on and the call ends.
4. When the user has no more new messages, a port places a similar call to the MWI Off number.

Architectural Comparison

---

2. Common MWI Failure Modes and Troubleshooting Workflows

When a user reports that their voicemail lamp remains dark despite having unheard messages (or stays illuminated after all messages are deleted), administrators must isolate the failure point using a structured troubleshooting methodology.

+-----------------------------------------------------------------------------------+
|                         MWI ROOT CAUSE ISOLATION MATRIX                           |
|                                                                                   |
|  SYMPTOM: SIP NOTIFY MWI FAILS (LAMP NEVER ILLUMINATES)                           |
|  +-----------------------------------------------------------------------------+  |
|  |                                                                             |  |
|  |  1. CUCM returns 'SIP/2.0 404 Not Found' to CUC NOTIFY                      |  |
|  |     Cause: SIP Trunk Calling Search Space (CSS) lacks the partition of DN.  |  |
|  |     Fix: Add Phone Directory Number Partition to the SIP Trunk's CSS.       |  |
|  |                                                                             |  |
|  |  2. CUCM returns 'SIP/2.0 403 Forbidden' or drops NOTIFY                    |  |
|  |     Cause: 'Accept Unsolicited Notification' is UNCHECKED on SIP Profile.   |  |
|  |     Fix: Check 'Accept Unsolicited Notification' in Security Profile.       |  |
|  |                                                                             |  |
|  |  3. CUC sends NOTIFY to wrong IP address                                    |  |
|  |     Cause: Port Group points to non-call processing CUCM Publisher/TFTP.    |  |
|  |     Fix: Update CUC Port Group to point to active CUCM Subscribers.         |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Issue 1: Calling Search Space (CSS) Partition Misconfiguration

When CUC sends NOTIFY sip:2002@10.1.1.10:5060, CUCM acts as a SIP receiver and must route the notification to internal Directory Number 2002.

• CUCM uses the Calling Search Space configured on the incoming SIP Trunk to search for DN 2002.
• If DN 2002 resides in the Internal_Phones_PT partition, but the SIP Trunk's CSS contains only the Gateway_PT partition, CUCM cannot find the destination directory number.
• Diagnostic Indicator: CUCM responds to CUC's SIP NOTIFY with a SIP/2.0 404 Not Found message. The lamp never turns on.
• Resolution: Ensure the Calling Search Space assigned to the CUC SIP Trunk in CUCM includes the partitions containing all subscriber directory numbers.

Issue 2: SIP Trunk Security Profile Misconfiguration

By default, standard SIP security profiles reject unsolicited notifications to prevent denial-of-service (DoS) lamp flooding.

• Under System > Security > SIP Trunk Security Profile, inspect the profile assigned to the CUC SIP trunk.
• If the Accept Unsolicited Notification checkbox is unchecked, CUCM rejects incoming RFC 3842 NOTIFY packets with SIP/2.0 403 Forbidden or ignores them.
• Resolution: Check the box for Accept Unsolicited Notification and reset the SIP trunk.

Issue 3: Outdial Port Starvation (Legacy Outdial MWI)

In systems utilizing Legacy Outdial MWI, CUC must seize a Voice Messaging Port configured with the Send MWI Requests attribute.

• During the morning busy hour (8:00 AM – 9:30 AM), hundreds of users arrive, listen to messages, and delete them.
• If the CUC Port Group only has 2 or 3 ports dedicated to outdialing, all outdial ports become saturated.
• MWI turn-off requests enter a software buffer queue. Users see their lamp remain illuminated for 30 to 60 minutes after emptying their inbox.
• Resolution: Transition to RFC 3842 SIP NOTIFY MWI, or reallocate additional Voice Messaging Ports from "Answering" to "Send MWI Requests".

---

3. MWI Synchronization Utility & Diagnostics

When network disruptions, cluster failovers, or database maintenance cause phone lamp states to fall out of sync with actual mailbox contents (e.g., lamps remain lit with zero unheard messages), administrators can synchronize the system without restarting services.

Synchronizing MWIs

In Cisco Unity Connection Administration > Telephony Integrations > Phone System, open the phone system and run Synchronize All MWIs on This Phone System:

• CUC checks the unheard-message state of every mailbox on that phone system.
• It resends the correct on or off request for each user (a SIP NOTIFY, or an MWI call in an SCCP integration), overriding whatever state the phone currently shows.
• For a single user, resend or check MWI from that user's Message Waiting Indicators page.

Traces and Status Checks

• In Cisco Unity Connection Serviceability > Trace > Macro Traces, enable Traces for MWI problems, reproduce the issue, and collect the logs with RTMT.
• RTMT's Port Monitor for Unity Connection shows which ports are busy and what they are doing, which helps confirm port starvation.
• show cuc cluster status on the CLI confirms that both servers are running and shows which one has Primary status.

In CUCM, administrators inspect MWI signaling using the Cisco Unified Real-Time Monitoring Tool (RTMT):

• Collect Cisco CallManager traces.
• Filter by Event: message-summary or search for the subscriber directory number (e.g., 2002).
• Verify that CUCM returns SIP/2.0 200 OK to CUC's NOTIFY request, followed by CUCM sending a Skinny or SIP NOTIFY downstream to the IP phone.