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

Jay Ray jonty_11 at yahoo.com
Mon Apr 25 11:35:03 MST 2005


Hi,
 
  My idea was to implement VoiceMail w/MWI for Third Pty SIP Softswitches (to be able to support MWI for endpoints registered on another SIP Softswitch). Hence I have changed the chan_sip.c (SIP code) to support that. The diff is present in the first email in this thread. I have not explored at the IAX protocol to support the same functionality.
 
 I guess if we implement using SIP, it would be generic and would work for other Asterisks as well. and we dont have to necessarily use IAX to support this...
 
 What does everyone think.....
 
Thx,
Jay

Gil Kloepfer <astr-dev at kloepfer.org> wrote:
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)
_______________________________________________
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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050425/e575854f/attachment.htm


More information about the asterisk-dev mailing list