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

[John R. Covert]

Thanks for your reply, Richard.

>The events needed for using pri_mwi_indicate() are generated by the
>Asterisk voicemail system.  These events are subscribed to by the channel
>driver.

How would you propose having the channel driver subscribe to all
of the possible extensions in the remote PBX (possibly several
thousand)?  The current architecture seems to be targetted at a
small number of phones on a BRI channel, which is why the
1.4.12-beta3 version of pri_mwi_indicate has "if (!BRI_NT_PTMP(ctrl))
{return -1;}"

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

Ah, thanks.  I see call = ctrl->link.dummy_call; which I assume
means that there is always a dummy call available for these
kind of messages.

An off-list reply that I got reminded me about the externnotify
keyword in voicemail.conf. This was helpful to get me to see the
point at which the voicemail system sends updates due to changes.

I was thinking of extending externnotify in a general manner --
if you specify externnotify=MACRO:macro-name instead of calling
ast_safe_system it would invoke a macro which would determine
if the mailbox represents a phone in the PBX by doing a
${DIALPLAN_EXISTS(stations-in-pbx,${ARG1})} and then invoking
the Dialplan Application to send the message.

It may also be necessary to occasionally send an update for every
mailbox in the system, since phones may lose power and have their
light turned off (unless the Definity PBX maintains state when
it receives messages).

>> 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

Yes, but the documentation I would like to see is documentation
that the Definity actually implements this for notification from
remote voicemail systems.

>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.

Given these parameters to mwi_message_send

Encode and queue the Q.SIG MWIActivate/MWIDeactivate invoke message.
D channel controller for diagnostic messages or global options.
call Call leg to queue message.
req Served user setup request information.
activate Nonzero to do the activate message.

D channel and activate are obvious.  Is the call leg a dummy call, as
with the others?  The req is a pri_sr, which doesn't seem to be quite
as simple as a pri_party_id.  Any pointers, please, to how to construct
this?

I've seen other replies that talk about sending DTMF over an analog
line.  The customer has specifically rejected this as not acceptable.

Thanks/john


On Thu, 3 Feb 2011 11:29:16 -0600 (CST) Richard Mudgett <rmudgett at digium.com>
wrote:
----- 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