[Asterisk-Dev] [RFC] Remote MWI using IAX2

[Gil Kloepfer]

On Sat, May 07, 2005 at 04:49:29PM +0100, Chris Lee wrote:
> It would make much more sense if the voice mail was linked to the user 
> not the phone.

In a majority of cases, the phone is the user - that's why message
waiting indication is linked to the phone right now (that's probably
a very good idea, although having a user association would be a nice
option).

> A user logs in (registers a physical phone as their location).
> The Asterisk server that is logged into gets the location of the users 
> VoiceMail server from the user config file.
> Makes a request for VoiceMail updates to be sent and keeps a local 
> record for the device to access for its WMI indicator.
> Then the phone can ask the local asterisk server for WMI info when it 
> wants to and we dont have massive clouds of WMI info all over the network.

I think I understand what you're suggesting and what I added in a
later follow-up is in line with this thinking.  However, given
what I said above, there needs to be a way for one PBX to "subscribe"
to updates for multiple mailboxes in the case where it is servicing
a channel bank, for instance.  This is a real case I will very
soon have to deal with (organization's voicemail on one server
handling mailboxes for phones being handled by another server).

The problem I see is that there is no mechanism to subscribe to MWI
updates from a remote server to forward onto a local phone.  Everything
for Zap and MGCP channels (among other technologies) is handled via
a "poll" mechanism within Asterisk.  So the only way to implement
remote MWI between Asterisk servers without revamping how MWI and IAX is
implemented is to poll over IAX as I have hacked together.

What I've been trying to do is start by maybe doing remote MWI
the "wrong" way (but show the value it provides) modeling it after
Asterisk's current methodolgy in the hopes it will motivate a larger
move toward getting the "right" solution in general for MWI.  This would
be a "push"-type solution rather than the "poll"-type solution
currently implemented.

---
Gil Kloepfer
astrepl at kloepfer.org