[asterisk-app-dev] MWI implementation

[Joshua Colp]

Mark Michelson wrote:
> The basic scenario where persistence is desirable is when Asterisk has
> accumulated a bunch of MWI state, then restarts, then a device requests
> current MWI state for a mailbox. If mailbox state is not persisted, then
> Asterisk has to respond with incorrect state. If the MWI state is
> persisted, then Asterisk can respond with the latest known state.

Correct, until it's updated.

> Regarding work required by the application, having state not be
> persisted is, in my opinion, more of a hassle. If Asterisk restarts,
> then the application needs to know that it happened and then retransmit
> all MWI state to Asterisk in order to repopulate Asterisk's cache. If
> state is persisted, then the only state that needs to be retransmitted
> by the application is whatever couldn't previously have been delivered
> during the downtime.

The application would have a WebSocket connection up so it would know.

> Regarding the mailbox destruction scenario, the application is going to
> have to create a backlog of updates to send at any point when Asterisk
> is down, whether those updates are changes to MWI state or creation or
> destruction of said state. I don't think that removing persistence will
> have any effect on this.

If there is no persistence it actually simplifies things quite a bit 
because you *don't* have to keep a backlog of updates.

It boils down to:
When your connection to Asterisk is established feed it state for all 
known about mailboxes

If you have persistence you now have to:
Keep a log with any in-flight updates that received no response
Keep a log of any mailboxes that have been changed (added, updated, deleted)
When your connection to Asterisk is established replay your log
* This should ensure state is the same between both

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org