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

Jean-Hugues ROBERT jean_hugues_robert at yahoo.com
Fri May 13 01:44:34 MST 2005


Hi Gil,

Poll versus Push is an issue. Push is more elegant.

But Push can be complex and inefficient too.

A well optimized Poll can sometimes be a better solution
(and a simpler one). The most basic/efficient optimization
is probably to aggregate multiple changes to transmit them in
bulk mode rather than one at a time.

Think about it:
   On busy system, Poll will often collect a change, i.e. your
   Poll request was not wasted bandwidth/cpu.
   On a not busy system... well... bandwidth/cpu is cheap.

So, I certainly would not rule out a Poll solution before
doing some math about the exact overhead (at different load
levels).

You may even monitor in realtime the overhead, to reduce
the polling frequency to reduce overhead (if bandwidth/cpu
isn't that cheap after all). Perceived quality would decrease
when load is light however. It all depends on how much you
can afford to get quality.

The next optimization is probably to introduce a little of
Push. Something like the Publisher telling the Consumer:
"please poll more frequently if you can, changes are likely".

The next optimization is naturally a full Push, where
Publisher says: "Please see changes attached".

As always, avoiding premature optimization is a good thing.

There are cases when Polling Scales! Maybe it is the case
with MWI?

Yours,

   JeanHuguesRobert

EOM

At 23:19 10/05/2005 -0500, you wrote:
>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
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17




More information about the asterisk-dev mailing list