[Asterisk-Dev] Proposed MWI support for Endpoints on Different Softswitch

Gil Kloepfer astr-dev at kloepfer.org
Sat Apr 23 09:04:05 MST 2005


Well, I got into this discussion a little late (unfortunately, I
don't have a lot of time to read the mailing lists these days)...
but I, too, have an immediate need for being able to get phones
registered on one Asterisk PBX to get MWI from the voicemail system
on another Asterisk PBX.

What I thought would be a good idea would be to somehow extend IAX2
to have a function to check the voicemail status for an extension on
another PBX.  Then I saw IAX_COMMAND_MWI in iax2.h and was confused,
because there isn't anything about what it is actually for.

A high-level explanation of an idea I had was as follows:

   1. Extend the 'mailbox=' option in all the .conf files to allow
      a syntax of IAX2/Path/Extension at Context - with the
      IAX2/Path portion optional (just as the @Context is now).
      This is easy because I don't think anything really checks it
      at the .conf file parser level.

   2. The mailbox= args are already passed verbatum to
      ast_app_messagecount and ast_app_has_voicemail in asterisk/app.c.
      These functions are already called periodically on a schedule by the
      various channel interfaces to light the MWI on the phones.

      Modify these two functions to call a function within chan_iax2
      when requested through the extended mailbox= syntax to request
      a remote mailbox status.

   3. The IAX2 remote MWI status request would actually call the
      ast_app_messagecount and ast_app_has_voicemail on the system
      receiving the request.

Architecturally this would work fine, at least for IAX2.  I'm not
sure whether this same idea could work via SIP or any other channel type.
Since SIP is a notify rather than a polled request, this is probably
not really applicable here (although it may be desirable to make it
work).

The only implementation issue I saw was that when coding this extension,
app.c and chan_iax2.c are not present at the same time in some points
while Asterisk is running (app.c is part of core Asterisk, and
chan_iax2 is a module).  My thought would be that app.c would define
some function that would allow "registration" via a persistent (global?)
variable containing the function to call for the IAX2 remote MWI request
that app.c would use.  When chan_iax2 loads and registers, one of the
things it would do is register its remote MWI handler function with
app.c (kind of like it does for other parts of Asterisk now).

The reason why I need this feature is because where I work we are
intending to roll-out a large (approx. 1000 phones) implementation of
Asterisk to replace our very old Nortel PBX and Octel Voice Mail system.
We have one remote site and several buildings that we would like to
equip with their own PBX (in the case of our on-campus buildings,
we plan to have about a third of the phones be analog phones/modems/etc.
on channel banks and we'd rather put the channel banks onto a PBX in
the network closet rather than pull T1 connections all the way back
to a bunch of wct4xxp cards on a single central PBX or use MGCP).  I'm
also being asked for a certain level of redunancy (or at least a distributed
system), and the voicemail's MWI is a deal-breaker issue right now.

I am seriously looking into making the changes to get the MWI through
IAX2 to work, but would like to know if (1) someone else is doing this
already, (2) what IAX_COMMAND_MWI is really for, and (3) if this is
really the right way to do it.

The only other way I could see to do this would be to modify the
two routines in app.c to be able to optionally call an external program
and use the manager interface.  I feel that's far too heavy-weight and
not particularly scalable.  It really looks like it should be part of
an inter-PBX communication protocol, not hacked via an external
program and second protocol.

---
Gil Kloepfer
home: astr-dev at kloepfer.org / FWD: 413932
work: gil at arlut.utexas.edu / FWD: 395683 (UT Applied Research Laboratories)



More information about the asterisk-dev mailing list