[asterisk-dev] VMWI generation implemenation on FXS ports

Alec Davis sivad.a at paradise.net.nz
Sun Dec 21 04:10:33 CST 2008


I've got the beginning's of what I believe to be a useful feature 'Visual
Message Waiting Indicator' for low cost phones attached to an FXS port on
the TDM400P, I don't have access to the 8 and 24 port cards, so this is
going to need someone else to pick this up. The basic tested non breaking
code is released at http://bugs.digium.com/view.php?id=14104 this still
supports FSK sending and RPAS.

In code which is still in progress uses 'mwisendtype' in chan_dadhi.conf to
set the type of vmwi to use
   'fsk' or undefined for exisiting FSK only support.
   'none' no FSK spill heard every second time you go off hook.
   'rpas' for existing support ring pulse before FSK
   'lrev' line reversed while messages exist
   'hvdc' high voltage, 90Vdc idle voltage
   'hvac' high voltage neon generation, Following Silicon Labs AN33

But have a dilemma, my current method for wctdm is a new ioctl
DADHI_VMWI_SENDTYPE, with initial support for setting only 1 type of VMWI
type per channel. But I can foresee installations where multiple phone types
may be attached to the same FXS port, where one type may support FSK only
and another a low cost phone only supporting Line Reversal. Perhaps some
that require the line to be reversed to wake them up, example stand alone
CallerID boxes.

The dilemma is
	1). A new ioctl like DADHI_VMWI_SENDTYPE
	2). Use existing DAHDI_VMWI and limit it to 255 messages, where the upper
byte is the VMWI type, bit settable, to support multiple VMWI types per
channel.
I'd appreciate some help with direction here.

I've also considered the question.
	Q. What part does the kernel driver need to do, if any at all?
	A. Following the FXO neonmwimonitoring code, I believe it will be needed
when I get to neonvmwi generation. But this could be a different ioctl to
set ONHOOK idle line voltage perhaps called DAHDI_SETVOLTAGE, so using
existing ioctl DAHDI_SETPOLARITY and new ioctl DAHDI_SETVOLTAGE the logic
can be implemented in user space chan_dahdi.c.

Current wctdm ioctl DAHDI_SETPOLARITY currently sets a global line polarity
for every channel, it may need to change to be per channel.

A question, that I'll probably work out with a fresh mind, not at 11PM on a
Sunday night.
With the new ioctl DADHI_VMWI_SENDTYPE, the problem I'm having is where to
actually initialize FXS channel, process_dahdi seems like we only want to be
dealing with chan_dahdi parameters, but not nessarily initializing the low
level driver - not this early, dahdi_chan_init seems like a good place, but
I think thats a typo in the code, isn't it dahdi_chan_conf?

Alec Davis




More information about the asterisk-dev mailing list