Introduction:
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
Traces:
SIP integration:
>>>> Conversation manager on CUC initiates the SIP stack to send out a SIP notify to CUCM:
NOTIFY sip:216181@10.106.117.132 SIP/2.0
From: sip:10.106.117.132;tag=185be2450fa4498f9ad928a998f4cc11
To: sip:216181@10.106.117.132
Via: SIP/2.0/TCP 10.106.117.133:5060;branch=z9hG4bK83d91e663e4d47768465116b5a37666c
Max-Forwards: 70
Contact: sip:10.106.117.133:5060
Call-ID: faa6de08ae424acc8dda1cc260e732ed@10.106.117.132
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^10.106.117.133^* |[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^10.106.117.133^* |[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^10.226.240.14^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^10.226.240.14^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@10.106.117.132 SIP/2.0
From: sip:10.106.117.133:5060;tag=03d2231777d0465aa329d31db6e02e16
To: sip: 1000@10.106.117.132
Via: SIP/2.0/TCP 10.106.117.133:5060;branch=z9hG4bKa8092e71a93d41f68862e887250d29a2
Max-Forwards: 70
Contact: sip: 10.106.117.133:5060
Call-ID: 3af731fa29d5466c89b2c6c6803e3ff1@10.106.117.132
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 10.106.117.132:5060;branch=z9hG4bK76d6868527bc46c9814f2b52390d0325
From: sip:10.106.117.133:5060;tag=8979f8a2d55640cf8e710118dbe4dda3
To: sip:1000@10.106.117.132;tag= 1877519591
Date: Mon, 03 Feb 2016 15:42:31 GMT
Call-ID: d4f7d9bd989b4dde8926559173d11968@10.106.117.132
CSeq: 300 NOTIFY
Warning: 399 LODKSCUCMUCSPUB01 "Unable to find a device handler for the request received on port 35410 from 10.106.117.133"
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
