Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Understanding the process of MWI

I'm a bit confused. The way that I understand how MWI gets lit after a message is as followed:

1. AVMSGMONITOR sees a message in an inbox via login the Unity_(servername).

2. The the AVnotifier finds what the change is to the mailbox to decide what needs to happern MWI, call phone ect.

3. Sends to the AVSmgr for processing.

I have also heard that it is Exchanges job to notify the AVMSGMONITOR that it has a new voicemail.

This is contridicting, if anyone can explain to me how this works I would really appreciate it. Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Understanding the process of MWI

Your understanding is correct - we don't (and can't realisticly) "poll" mailboxes to get status updates.

It sounds like the MAPI connection the notifier is using for the user's mailboxes is "stale" (many MS bugs related to this) - so we stop getting updates from the mailstore on changes. If you force a resync for a user it'll poll it on it's own but that's much too heavy to do for everyone all the time.

I'm guessing if you bounce the Notifier service entirely it'll re-log into everyone's mailbox and the MWI notifications will work properly again.

Recent versions of Unity have put in logic to more accurately tell when a MAPI session has gone "dead" out from under us and to discard and reconstruct it in the background - if you're not at 4.2 you may consider it.

5 REPLIES
Cisco Employee

Re: Understanding the process of MWI

The architecture overview document goes into some detail on this topic:

http://www.ciscounitytools.com/Documents/UnityArchitectureOverview40(3).doc

(this is a rough draft of a chapter found in the Unity Deployment and Solutions Guide book, by the way).

Short story is Exchange sends a notification that _some_ change happened to a mailbox but is not real specific about what - it's the notifier service's job to filter the mailbox to determine if there's something Unity needs to do or not.

Re: Understanding the process of MWI

Hello Jeff,

Thanks very much for answering. I have read your book several times and actually this is what my question stems from.

If I understand then the service AVmessagestoremonitorsvr listens for exchange to tell it that something has changed instead of the other way around???

The problem that this stems from is that when our exchange cluster goes down then MWI is out of synch. I can manually refresh the MWI status but this does not fix the subscribers MWI permenatelly.

Also I have to say thanks for writing the book as it has saved me many times when I worked on TAC and at my current job. Thanks

Cisco Employee

Re: Understanding the process of MWI

Your understanding is correct - we don't (and can't realisticly) "poll" mailboxes to get status updates.

It sounds like the MAPI connection the notifier is using for the user's mailboxes is "stale" (many MS bugs related to this) - so we stop getting updates from the mailstore on changes. If you force a resync for a user it'll poll it on it's own but that's much too heavy to do for everyone all the time.

I'm guessing if you bounce the Notifier service entirely it'll re-log into everyone's mailbox and the MWI notifications will work properly again.

Recent versions of Unity have put in logic to more accurately tell when a MAPI session has gone "dead" out from under us and to discard and reconstruct it in the background - if you're not at 4.2 you may consider it.

Re: Understanding the process of MWI

I have bounced the notifier along with deleting the MAPI profile. We eventually sync up but takes about a day. 9000 users in Exchange. So this is probably working as designed for such a large Exchange enviroment. I can't gather traces from Unity because of how it was installed (gives me errors). I'm looking for a way to probe that it is Exchange and not Unity. I have looked at mailboxes with the mbx siut is this the best way to prove this? Thanks Jeff hate to be a pain on the forum

New Member

Re: Understanding the process of MWI

Cisco Unity Outside Caller Call Flow

Step 1

The outside caller dials a phone number from his mobile phone. The phone number dialed is a Direct Inward Dialing (DID) number that belongs to a Cisco Unity subscriber.

Step 2

The Public System Telephone Network (PSTN) routes the caller to the office communications equipment.

Step 3

The DID number is programmed to ring a phone extension. Based on DID information provided by the PSTN, the business telephone system sends the incoming call to the telephone that it is programmed to connect to that DID number.

Step 4

The telephone rings four times, but the subscriber does not answer the phone because he is busy working on a presentation. The telephone system has been programmed to forward any unanswered calls to voice mail after four rings. The telephone system forwards the outside caller to the voice-mail system.

Step 5

Cisco Unity receives the call and the extension of the subscriber to take a message for. Cisco Unity has a list of subscriber extensions and the e-mail aliases to send messages to. Cisco Unity records a message from the caller, addresses it to the subscriber's alias, and then sends it to the message store server.

Step 6

The message store server receives the message and stores the message for the subscriber.

Step 7

While Cisco Unity is monitoring events in the message store, it notices a new voice-mail message for the subscriber and sends the message waiting indicator (MWI) ON code to the telephone system for the subscriber's extension.

Step 8

The telephone system lights the lamp at the subscriber's telephone set. The telephone now displays an MWI to alert the subscriber of a new message.

220
Views
0
Helpful
5
Replies
CreatePlease login to create content