[asterisk-dev] wctdm 4/8/24 VMWI generation capabilities

[Alec Davis]

Doug.
	Regarding bug #14143, I forgot to mention that the annoying mwispill is also heard when you clear a message from your extension and press # when finished. Example, with extension 2345 connected to FXS port, dial voicemail, then enter mailbox 2345 and password 2345 then clear 1 message, press # when finished, but stay off-hook, the FSK mwispill is heard.

	I haven't yet had a chance to test the latest patch, but I believe it may not fix this senario, assuming that the initial logic fix patch was applied, the DAHDI_EVENT_RINGOFFHOOK event was handled by 'handle_init_event' if it wasn't handled in 'mwi_send_process_event'.

	Alec Davis

-----Original Message-----
From: Alec Davis [mailto:sivad.a at paradise.net.nz]
Sent: Wednesday, 7 January 2009 08:53 p.m.
To: Doug Bailey
Cc: asterisk-dev-bounces at lists.digium.com
Subject: RE: [asterisk-dev] wctdm 4/8/24 VMWI generation capabilities


The intention to implement all methods was ambitious, and may miss some methods, but it provides the framework to be expanded on later.

FXS Line 'reversepolarity' was already in wctdm, so implementing vmwi line reversal just followed the logic already in the code, and set the line polarity using a logical xor of 'vmwistate' and 'reversepolarity'. Pity there is no such logical xor operator ^^.

The reversepolarity logic in wctdm isn't in wctdm24xxp, but assuming it was implemented and tested, then vmwi implementation just follows that code.

Regarding coexisting with FSK generation the proposed method supports LineReversal in parallel with FSK, I have tested with a callerid unit attached to the same line as a phone that only supports LED line reversal.
FSK MWI generation, currently has a few bugs http://bugs.digium.com/view.php?id=14143 this simple 1 line fix bug hasn't yet been looked at. But there is still an existing bug when you leave a voice mail for a user.

Using the mwisendtype=nofsk was my initial work around that fixed the annoyance of bug 14143.
'nofsk' method, if you really don't want FSK, there is an option, particularly in countries where DTMF is used.

'hvdc' method, was enough to trip another model of phone we have, which doesn't support line reversal, but it's not a Neon, must just be a 75v zener in series with an LED or Lamp. But I had trouble then trying to ring the phone, I need to understand the proslic better, so aborted that attempt.

'hvac' method, completely untested. I'll take your advice, proslic may not be able to generate enough AC.

'dtmf' method, not implemented, but may be necessary.

Regarding FXO NeonMwiMonitoring, I had seen it in the wctdm24xxp, but not the wctdm code.

I have fxstest to also submit, that supports vmwi message setting.

Sounds like we don't need to change much, if anything?

Alec Davis
 



-----Original Message-----
From: Doug Bailey [mailto:dbailey at digium.com]
Sent: Wednesday, 7 January 2009 11:51 a.m.
To: Alec Davis
Cc: asterisk-dev-bounces at lists.digium.com
Subject: Re: [asterisk-dev] wctdm 4/8/24 VMWI generation capabilities


----- "Alec Davis" <sivad.a at paradise.net.nz> wrote:

> Doug,
> 	You were correct, since that message I have implemented the wctdm
> driver,
> but not the wctdm24xxp, It comes down to is there any interest?
> 

I'm game for at least some of the changes you are proposing.  My concern is
that we do not convolute anything more in the driver for something that provides
marginal return.  I guess we can start with the line reversal that you have
proposed and go from there. 

> 	Referring to http://bugs.digium.com/view.php?id=14104 I've extended
> the use
> of the configuration element 'mwisendtype' in chan_dahdi.conf. The
> intention
> is to be able to generate more than just an FSK MWI spill to light up
> a
> phone's MWI lamp, many low cost phones don't support FSK, most support
> a
> LineReversal Lamp, some support HVDC Lamp, and I assume only a few
> support
> HVAC Neon these days. Some I've seen support various methods,
> LineReversal
> being the common method.
>
> I have added options for Line reversal, High Voltage DC and High
> Voltage AC,
> which may or may not be supported by the underlying driver. Currently
> I have
> implemented and tested Line Reversal and submitted the code for the
> TDM400
> FXS module in wctdm.c.
> 
> As you added the mwisendtype option in
> http://bugs.digium.com/bug_view_advanced_page.php?bug_id=8587 the
> question
> is are you happy for 'mwisendtype' configuration element to be
> extended in
> this way, or would you rather seen more configuration elements added
> for
> each mwisend method.
>

I have no problem with making the mwisendtype more consistent and capable of
handling all the supported methods of mwi generation.  What you propose
looks fine by me.

Currently the chan_dahdi supports the generation of a simple FSK and a FSK
message preceded by a ring pulse alert signal as specified by ETSI EN 300 659. 
(I have not done anything with the other ETSI variants as there has been no one
clamoring for them.)  I would suggest that we make these methods coexist with
your line reversal MWI capability.

Currently, the wctdm and wctdm24xxp drivers have the ability to detect NEON MWI
but cannot generate the NEON DC pulses.  Having spoke with someone intimately
familiar with the proslic IC, there is some concern that the neon MWI method as
specified AN-33 will not achieve a high enough DC voltage to guarantee the
triggering of a neon detector. If this is the case, I would probably pass on
implementing NEON MWI generation for the wctdm and wctdm24xxp drivers.

- Doug Bailey