MWI implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mark Michelson wrote:
> A while back, a discussion of a "blinky lights" proposal appeared on
> this list [1]. A wiki page [2] was created as a result of the discussion.
>
> We're now at the point where we plan to implement externally-initiated
> MWI in ARI and AMI. While the actual ARI approach has been agreed upon,
> the under the hood aspects have not been discussed yet, so I want to
> talk about it some.
>
> The current plan is to have Asterisk be a target for MWI updates.
> Asterisk can be told that the number of messages for a given mailbox has
> updated, and Asterisk will in turn notify interested parties (such as
> SIP phones) of the change. Asterisk will also persist the data (using
> sorcery) so that the data will be accessible if Asterisk is restarted.
> The current MWI state can also be retrieved externally.

What worries me about persisting this information is keeping it in sync 
with the outside world. If a mailbox goes away externally and the 
Asterisk instance is not running now the application has to do one of 
the following:

1. Keep a log of this fact and then ensure it is removed from Asterisk 
when it starts up

2. Destroy with hate any mailboxes it doesn't know about when Asterisk 
starts up (what about other applications?)

That seems like a lot of work, and potentially issue prone which brings 
me to...

Why are we persisting at all? Since this is completely externally driven 
there's going to be a chance no matter what that the information is 
stale. I would argue that not persisting and letting the external 
application feed it back in is better. This gives you a guarantee that 
the state is the same.

Thoughts?

-- 
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



[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux