[asterisk-dev] Implementing MWI for Definity PBX served by Asterisk VoiceMail

[Richard Mudgett]

----- Original Message -----
> I have a client who engaged me to interconnect several hundred
> Definity PBXs into a private network using Asterisk. That's
> deployed to the first two; piece of cake using ENUM. They will
> be buying lots of Digium PRI cards because I insisted on Digium
> hardware. But that's not what this is about.
> 
> He also wants Asterisk to be the Voicemail server. Another
> piece of cake. Until he told me that he wanted me to control
> the MWI lights on the phones in the PBX, and is considering
> cancelling the whole project if I can't deliver that. Ooops.
> 
> He claims (without providing any documentation) that I should

ETSI Specification: EN 300 745-1 V1.2.4 (1998-06)

> be able to send MWI commands over the D-channel. It appears
> that this is partially implemented in Asterisk, but of course
> with the expectation that this is for ISDN BRI phones which
> would be declared in chan_dahdi.conf. We don't have that.
> 
> It seems like a lot of what I need is present. I think I

Base your modifications on libpri 1.4.12-beta3 and an Asterisk 1.8
version.  The ISDN MWI support is in that code.  It will also reduce
merging issues later.

I think you are really dealing with the MWIActivate/MWIDeactivate messages
for PRI.  The MWIActivate/MWIDeactivate messages are carried either by a
REGISTER or FACILITY message.  The MWIIndicate message seems to be
intended for delivery to phones/users.

> need only the following two routines that rmudgett is
> working on that are not yet released:
> 
> enc_etsi_mwi_indicate_message
> rose_mwi_indicate_encode
> 
> I should then be able to do the things done in
> pri_mwi_indicate from a dialplan function or application
> which I call when I know that a message has been left or
> deleted.

The events needed for using pri_mwi_indicate() are generated by the
Asterisk voicemail system.  These events are subscribed to by the channel
driver.  The events are not associated with any active call so a dialplan
function or application is not likely to be useful.

> For example: exten => s,n,SetMWIonPRI(DAHDI/1, stationID, numMsgs)
> 
> To help me, I would like to better understand the parameters
> listed for rose_mwi_indicate_encode:
> 
> * \param ctrl D channel controller.
> * \param call Call leg to queue message.
> * \param mailbox Controlling party number (NULL if not present).
> * \param basic_service Basic service enum (-1 if not present).
> * \param num_messages NumberOfMessages (-1 if not present).
> * \param caller_id Controlling party privided number (NULL if not
> present).
> * \param timestamp Generalized Time format (NULL if not present).
> * \param message_reference Message reference number (-1 if not
> present).
> * \param message_status Message status: added(0), removed(1).

These parameters were derived from what is supposed to go into the
MWIIndicate message.  (See the ETSI specification)

> I assume there's an easy way to get the D-channel given a DAHDI
> channel.
> 
> I think I can create the dummy call leg like this:
> call = PRI_MASTER(ctrl)->dummy_call;

PRI_MASTER() is no longer needed/present in libpri 1.4.12-beta3.

> I assume "mailbox" is actually the station number, which might not be
> the asterisk mailbox. For example, the station might be 11118 but the
> asterisk mailbox might be 2811118 so that they are global throughout
> the hundred interconnected pbxes.
> 
> Looks like it's actually pretty simple, just a struct pri_party_id
> initialized with
> 
> Basic service seems to be "1" for speech.
> 
> Is "num_messages" what controls turning the light on/off? I.E. 1 or
> greater, on, 0, off? (Maybe some phones actually can display the
> number, and not just a light).
> 
> caller_id is this the caller_id of the last caller who left a message?
> I'll probably not provide this, since it seems to be optional,
> although
> I could make in an optional parameter to the application.
> 
> What's the use of the timestamp? Looks like the code in
> channels/sig_pri.c
> wasn't going to provide this, so I won't either. Same with the message
> reference.
> 
> message_status - this appears to be passed as zero from the code in
> sig_pri.c, but what does it mean.

Richard