[asterisk-dev] VMWI - Voice Mail Waiting Indication

Oron Peled oron at actcom.co.il
Thu Jun 7 14:02:46 MST 2007


Currently chan_zap assume that VMWI is to be signalled by sending FSK
tones (similar to caller-id, but done while the FXS line is onhook).

However, there are many analog phones with small neon-bulb to indicate
voice mail waiting. These phones need a completely different signalling
to light this bulb (basically it involves sending a "ring-like" voltage
while the FXS line is onhook).

Several months ago we added in our zaptel/xpp drivers support for this
mechanism. During development we used a private ioctl() to send
notification from chan_zap to our driver. However, since we did not
want to change Asterisk, we had to replace this with an ugly hack
(hold your breath...)

We basically look for these FSK patterns in the outgoing PCM
stream (only during onhook) and detect the VMWI-ON and VMWI-OFF messages.

While this implementation work quite nicely, it's obviously a very
silly method of communication from chan_zap to zaptel/xpp via FSK.
(Hmmm... in zaptel-1.6 we can replace them by smoke-signals ;-)

Instead, we would like to propose a new ioctl() that would be sent
from chan_zap upon VMWI state change (in addition to the traditional
FSK). BTW, this would help anybody that maintain drivers for SLIC
based chips as they have native support to generate the required
"ring-like" signal for these phones.

Tzafrir has already opened an issue at:
With the relevant patches (which are minimal).

These patches send the event directly to the interested low
level driver via a private ioctl(), since this is the common
pattern in other private messages.

However, in the long run I think it is better to handle this ioctl()
directly in zaptel and delegate it to low-level driver via an optional
method call.

The advantage in the later approach is that zaptel may maintain
the state information which can enable performance optimizations
(which is another subject we work on). If a span registers the
optional VMWI notification method, than zaptel does not need
to process PCM at all for its channels while they are onhook.

Ok, this was a long one. Thank you, whoever got this far,
and your comments are more than welcome.


Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
ICQ UIN: 16527398

If it's there and you can see it, it's REAL
If it's there and you can't see it, it's TRANSPARENT
If it's not there and you can see it, it's VIRTUAL
If it's not there and you can't see it, it's GONE!

More information about the asterisk-dev mailing list