With the release of Exchange 2010 the uptake of using Exchange as a Voicemail platform appears to be increasing. I am unsure if this is due to the Message Waiting Indicator (MWI) functionality now been included, or if the time is now right for customers to start adopting it.
While researching into the UM features of Exchange 2010, information around the features available and how to configure them is plentiful but there appears to be very little information about how MWI operates behind the scenes.
Therefore this post is based on the limited information that appears to be available and from looking into the MWI functionality.
The initial information at a high level comes from a slide deck produced by Ankur Kothari a Sr. Technical Product Manager at Microsoft. This has been published in PDF format and can be found here. Due to it being a PDF there are a number of slides which are hard to read and understand these are due to them been animation based slides and the PDF shows all the animations on a single page.
A high level view of the UM processes for leaving a message and for MWI can be seen in the diagram below (borrowed from Ankur’s slide deck)
As can be seen from the diagram above the process of leaving a message has not changed; one thing to note, step 3 shows the Voice message being delivered to the Mailbox server since this is an SMTP message from the UM Server to the recipient it goes via the Hub Server.
The new to Exchange 2010 part of the diagram above is the MWI part. This works in two parts the first is the notification from the Mailbox Role to the UM Role that MWI needs to either be turned on or off. The second is the SIP NOTIFY message between the UM Role and the IP-PBX or Gateway.
Before looking into this in more detail it is worth covering off some of the higher level details. MWI is enabled at both a UM Mailbox Policy and Gateway Level, for MWI to be set correctly it needs to be enabled on the UM Mailbox Policy and at least one Gateway associated with the Policy and Dial Plan. These are enabled by default but in some scenarios it may be necessary to disable MWI for some gateways.
Also MWI does not function if the Dial Plan has a URI type of SIP URI, even though the MWI settings are available. I am unsure why this is the case but I assume it is by design and probably due to the fact that a SIP URI dial plan is most commonly used for OCS.
Moving on to look at how MWI works, the process starts with the Mailbox Role which hosts the UM Mailbox Assistant this Assistant actively monitors the user’s mailbox for the number of read and unread messages. When this count changes it sends an RPC message to a Unified Messaging Server which hosts the UM Dialplan the user is associated with. There can be a small delay in this task being performed, this is usually due to the time it takes for Outlook to update Exchange when a message’s read\unread flag gets changed.
The following message can be seen in the Event Log of the Mailbox Role Server when diagnostic logging is turned on:
The UM Mailbox Assistant is housed within the Microsoft Exchange Mailbox Assistants Service; this Service needs to be running in order for MWI to function (along with a number of other Exchange functions) .
Once the message has been received by the UM Server, a SIP message is sent to the IP-PBX or Gateway, if the first gateway is unavailable or responds with a SIP error message it will attempt each remaining IP-PBX or Gateway associated with the Dial Plan and enabled for MWI.
The SIP message sent to the IP-PBX or Gateway is a NOTIFY message and contains the following information:
- MWI On or Off
- Account to modify MWI on
- Number of Read and Unread messages
The Message Body of the SIP Message looks like:
The reasons why the number of read and unread messages are sent is some PBXs and Phones display the number of read and unread messages. This is as specified in the RFC3842, unfortunately Exchange does not implement an optional part of the RFC which is to provide the message count for urgent messages; this would have rounded the implementation off nicely since Exchange provides the ability to mark Voicemails as High Importance.
The RFC also provides scope for the number of read and unread fax messages to be passed to the IP-PBX or Gateway, this is not implemented within Exchange MWI and is not include as part of the Voicemail message count.
The following message can be seen in the Event Log of the UM Role Server when diagnostic logging is turned on if the SIP Notify has been successful:
If an MWI notification fails messages similar to the following can be see, these are written to the Event Log on the UM Role Server irrelevant of the Diagnostic Logging Setting:
During the MWI process both on the Mailbox Role and the UM Role a number of LDAP queries are run against Active Directory these are to look up information such as if the UM Mailbox Policies are enabled for MWI and the associated Gateways, this information is not cached and is queried for each time.
Once the IP-PBX or Gateway has been acknowledged the MWI Notify message it is left to the IP-PBX or Gateway to locate the phone or phones associated with the specified extension and either turn on or off the Message Waiting Indicator.
Any IP-PBX or Gateway that supports RFC3842 should work with Exchange 2010 MWI although specific settings my be required on the PBX.
In summary MWI is something which was missing from Exchange 2007 and although there were third party applications to fill the gap, it was still seen as a major deployment blocker. Hopefully with Exchange 2010 supporting MWI it will increase the number of Exchange UM deployments.