[Home]

Summary:DAHLIN-00068: [patch] Generate VMWI line reversal from FXS module to light LED on newer 'non intellegent phone'
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2008-12-18 02:36:07.000-0600Date Closed:2010-07-20 05:31:03
Priority:MajorRegression?No
Status:Closed/CompleteComponents:wctdm
Versions:2.1.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asttrunk-14104.diff2.txt
( 1) chan_dahdi_mwisend_part2.diif.txt
( 2) dahdidriver-14104.diff2.txt
( 3) dahditools-14104.diff.txt
( 4) mwiioctl_structure_asterisk.diff2.txt
( 5) mwiioctl_structure_asterisk.diff4.txt
( 6) mwiioctl_structure_asterisk.diff5.txt
( 7) mwiioctl_structure_dahdi.diff2.txt
( 8) mwiioctl_structure_dahdi.diff4.txt
( 9) mwiioctl_structure_dahdi.diff5.txt
(10) mwiioctl_structure_fxstest.diff.txt
(11) mwiioctl_structure_fxstest.diff5.txt
(12) wctdm_whitepsace.diff.txt
(13) wctdm.mwisendtype.diff5.txt
(14) wctdm.mwisendtype.diff6.txt
Description:Added initial fundamental support to manipulate FXS line to generate Message Waiting Indication. Still supports sending FSK as has been supported for years.

Discovered undocumented parameter 'mwisendtype' in chan_dahdi.conf which can only be 'rpas' Ring Pulse Alert Signal at the moment.

Intention is to use this field with parameters as follows;
  '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 Silicb AN33

Alec

Comments:By: Alec Davis (alecdavis) 2008-12-18 02:44:23.000-0600

I'll use this first note to update implementation details, which may vary from the description above.

Tests done on TDM400P at channel 32, extension number 2345.

snippet from chan_dahdi.conf below, the key fields are 'mailbox=2345' and to alert the user there is a message waiting 'mwisendtype=rpas'

 context=default
 signalling = fxo_ls
 echocancel=yes
 echocancelwhenbridged=yes
 answeronpolarityswitch=no
 hanguponpolarityswitch=no
 group = 4
 rxgain=0.0
 txgain=0.0
 mailbox = 2345
 mwisendtype=rpas
 channel => 32

mwisendtype default (or commented out) is to only send FSK MWI
 'nofsk'  FSK MWI is not sent.
 'rpas'   a single Ring Pulse Alert Signal before FSK.
 'lrev'   line polarity reversed while new Voice Messages are pending.
 'hvdc'   line voltage set to steady ~90Vdc while new Voice Messages are pending.
 'neon'   line voltage pulsed to ~90Vdc at 4Hz to flash Neon Lamp.

  It is possible to have multiple methods enabled, separated by a comma.
  mwisendtype=rpas,nofsk,lrev

Notes:
  'lrev', 'hvdc' or 'neon' require appropriate hardware driver support.
  'neon' and 'lrev' are not possible together.


By: Alec Davis (alecdavis) 2008-12-18 03:22:09.000-0600

Googling 'MWI line reversal' brings up many hits, but what is become apparent with most of the low cost phones is that most that I looked at support 'MWI line reversal' as well as 90Vdc line voltage.

In summary, this patch may be all that is needed by the majority, only a minority I believe are going to need the 90Vdc (which should be easy to do), and a few may require the 90Vac MWI indication.

If you find this patch usefull or otherwise, please report in.

Alec
By: Alec Davis (alecdavis) 2008-12-18 12:56:00.000-0600

Forgot to mention the ioctl DAHDI_VMWI requires a 1 line fix in chan_dahdi.c

fix http://bugs.digium.com/view.php?id=14090
By: Tzafrir Cohen (tzafrir) 2008-12-21 05:37:14.000-0600

Nice work!

I'll just note that fsk and neon indication could be used together.
By: Alec Davis (alecdavis) 2008-12-21 13:15:31.000-0600

tzafrir: Thanks to you implementing ZT_VMWI early on, this was just an extension to the work you had done.

As mentioned on mailing list, I'm now not sure where to implement initializing the kernel driver. I currently have a new ioctl DAHDI_VMWI_SENDTYPE which needs to setup a channel variable in chan_dahdi and in wctdm, so that at chan_dahdi level 'mwisendtype=rpas' can still work, but also in wctdm so that if 'mwisendtype=hvac' is used both chan_dahdi and wctdm can act appropriately.
By: Alec Davis (alecdavis) 2008-12-22 03:17:57.000-0600

Please remove file dahdi_wctdm.c.VMWI.diff.txt

Uploaded wctdm.mwisendtype.diff.txt which includes previous changes
Also DAHDI_VMWI ioctl value now is a combined TYPE|NUMBER parameter. Number of messages can only be upto 255. TYPE is upper byte.

Will upload user.h for the DAHDI_VMWI_TYPES which are
#define DAHDI_VMWI_FSK  (1 << 8)        /* default FSK, no Ring Pulse Alert Signal*/
#define DAHDI_VMWI_RPAS (1 << 9)        /* Ring Pulse Alert Signal then FSK */
#define DAHDI_VMWI_LREV (1 << 10)       /* Line Reversal */
#define DAHDI_VMWI_HVDC (1 << 11)       /* HV 90VDC */
#define DAHDI_VMWI_HVAC (1 << 12)       /* HV 90VAC Neon lamp */
By: Alec Davis (alecdavis) 2008-12-22 03:30:52.000-0600

uploaded chan_dahdi.mwisendtype.diff.txt

adds code in process_dahdi to read chan_dahdi.conf to support various VMWI types
small change in do_monitor for DAHDI_VMWI ioctl to support combined TYPE|NUMBER

snippet from chan_dahdi.conf, to alert user 2345 with ring pulse and to reverse the line.
    mailbox = 2345
    mwisendtype=rpas,lrev

Low level code for HVDC and HVAC not yet done.
By: Tzafrir Cohen (tzafrir) 2008-12-23 03:33:48.000-0600

Looks good.

A number of comments, though:

1. mwisendtype seems to be related to the FXO VMWI detection in chan_dahdi. Is it really unused?

2. Are 8 bits enough for the messages count? Maybe go for 16 bits?
By: Tzafrir Cohen (tzafrir) 2008-12-23 03:54:57.000-0600

I'll also note that the change is not backward compatible. The "on" message is the same as an e.g. original "on + 2049 messages" in the original interface, whereas the "off" message is e.g. "on + 2048 messages".

However it is supported in one channel driver (the FXS driver of the Astribank), and in it, can be disabled explicitly at run time to fall back to FSK detection.
By: Alec Davis (alecdavis) 2008-12-23 04:32:44.000-0600

mwisendtype is a new int to indicated which VMWI method we want to use to manipluate the FXS line, Line Reversed, HVDC and HVAC, and includes existing RPAS (which gives a 1 ring pulse before the FSK).

Oron Peled on asterisk-dev was happy for TYPE+NUMBER in the ioctl, as the purpose of this ioctl is to turn on a MWI light, I think even 8 bits is too many. In other words, 'You have messages' or not.

FSK MWI signalling already does the number of messages, for the more expensive phones, and remains untouched in these patches.

As Oron mentioned Xorcom (you) are the only ones using VMWI, so to change now in the early lifecyle of DAHDI wouldn't be too painful.

Alec
By: Alec Davis (alecdavis) 2008-12-24 02:14:44.000-0600

please remove chan_dahdi.mwisendtype.diff.txt

upload chan_dahdi.mwisendtype_v2.diff.txt
This new version includes #ifdef's around new code for backwards compatiblity of unpatched dahdi-linux. Also small fix if number of messages > 255 or particularly if divisible by 256.

regarding backwards compatibility, wctdm.c patched, but chan_dahdi.c not.
This will require a new DAHDI_VMWI_V2 ioctl, unpatched chan_dahdi.c code will use DAHDI_VMWI ioctl, patched code will use DAHDI_VMWI_V2 ioctl.

Note. Only since 16 Dec 2008 would the DAHDI_VMWI ioctl in chan_dahdi.c code work as it required a fix refer http://bugs.digium.com/view.php?id=14090, So is backwards compatibilty really an issue for most out there?

Alec
By: Tzafrir Cohen (tzafrir) 2008-12-24 02:34:14.000-0600

I'm not removing chan_dahdi.mwisendtype.diff.txt just yet, as chan_dahdi.mwisendtype_v2.diff.txt seems needlessly complecated. The keyword you use is related to some FXO functionality. It is not mutually exclusive with the FXS functionality you add.

Why not simply add a new configuration keyword?
By: Alec Davis (alecdavis) 2008-12-24 03:29:01.000-0600

In chan_dahdi.c just before mwi_send_init, you'll find the description below. It's all about sending MWI out of an FXS port, not receiving FSK CID on an FXO port. I changed the global variable 'mwisend_rpas' to a chan variable 'mwisendtype' I could change it to vmwi_method if that seems more appropriate.

Snippet before mwi_send_init in chan_dahdi.c below
/*
* The following three functions (mwi_send_init, mwi_send_process_buffer,
* mwi_send_process_event) work with the do_monitor thread to generate mwi spills
* that are sent out via FXS port on voicemail state change.  The execution of
* the mwi send is state driven and can either generate a ring pulse prior to
* sending the fsk spill or simply send an fsk spill.
*/

The original 'process_dahdi' function reads the keyword from chan_dahdi.conf as mwisendtype=rpas, I extended this to support any of the options to:
mwisendtype=rpas,lrev,hvdc,hvac

Snippet of original process_dahdi below:

static int process_dahdi(struct dahdi_chan_conf *confp, const char *cat, struct ast_variable *v, int reload, int options)
{
.
.
               } else if (!strcasecmp(v->name, "mwisendtype")) {
                       if (!strcasecmp(v->value, "rpas")) {            /* Ring Pulse Alert Signal */
                               mwisend_rpas = 1;
                       } else {
                               mwisend_rpas = 0;
                       }

Hope this explanation helps clear up any confusion.
By: Alec Davis (alecdavis) 2008-12-25 02:25:29.000-0600

please remove chan_dahdi.mwisendtype.diff.txt

Discussed this with tzafrir on IRC last night, tzafrir now believes the mwisendtype keyword was not somehow related to FXO monitoring. It was only related to FSK sending and the initial rpas 'Ring Pulse Alert Signal', I have extended the use of the chan_dahdi.conf keyword 'mwisendtype' to support other options related to VMWI indication.

The differences between chan_dahdi.mwisendtype.diff.txt and chan_dahdi.mwisendtype_v2.diff.txt are mainly the inclusion of #ifdef's to make chan_dahdi.c compatible with an unpatched dahdi-linux.

I'm also thinking of adding an option 'nofsk', so you don't hear the annoying FSK every 2nd time you pick up the handset, the mwispill should be aborted as soon as OffHook is detected, I think this quirk should be opened as a new bug.

Alec Davis


By: Alec Davis (alecdavis) 2008-12-25 03:36:14.000-0600

uploaded chan_dahdi.conf.sample.diff.txt

This is the Asterisk chan_dahdi configs sample file describing the previously undocumented 'mwisendtype' keyword, the previous option 'rpas', and the new available options 'lrev','hvdc','hvac'.

Alec
By: Alec Davis (alecdavis) 2008-12-27 03:39:50.000-0600

please remove chan_dahdi.mwisendtype_v2.diff.txt

uploaded chan_dahdi.mwisendtype.diff3.txt

Further testing on tzafrir's advise, revealed a reload chan_dahdi bug. Now mwisendtype is forced to a known value.

Additional option added for chan_dahdi.conf keyword 'mwisendtype' of 'nofsk',  never send FSK, you'll get dialtone every time you pickup the handset. This works around the bug that MWISPILL is not aborted immediately offhook is detected.

Tested with TDM400P with 2 FXS modules, both with 'rpas' enabled so you know when to pick up the phone to hear the FSK.

snippet from chan_dahdi.conf

mailbox = 2345
mwisendtype=nofsk,rpas,lrev
channel => 32

mailbox = 2346
mwisendtype=rpas
channel => 33

Results:
Channel 33: You hear FSK if you pick up the handset immediately the phone rings, and you don't get a dial tone.
Channel 32: FSK is never sent. Single ring pulse. LED is on indicating Message, Stutter Dial Tone

Alec Davis
By: Alec Davis (alecdavis) 2008-12-28 03:40:58.000-0600

related:
regarding the use of mwisendtype=rpas in chan_dahdi.conf http://bugs.digium.com/bug_view_advanced_page.php?bug_id=8587
Doug Bailey wrote on 2008-05-22: I added a configuration element (mwisendtype) that can be set to "rpas" to initiate a ring pulse alert signal.
By: Doug Bailey (dbailey) 2009-01-07 15:24:14.000-0600

What is the purpose of mwisendtype and vmwimessages in the wctdm driver patch?
I assume they are for future use as I don't see them doing anything in the
patch.

At present all MWI FSK generation is done within chan_dahdi.  I don't envision
pushing any of that down into the driver level.  I foresee only pushing only the
MWI functionality to the driver that cannot be effectively generated within
chan_dahdi.  (NEON MWI generation would be one of those as is already done in
the card_fxs.c.)  It is possible that line reversal could be handled in
chan_dahdi but would require driver level support of setting individual channel
polarity which would need to be implemented in wctd, and wctdm24xxp..
By: Alec Davis (alecdavis) 2009-01-07 16:14:14.000-0600

In wctdm 'mwisendtype' is the low driver level support for the various methods that can be implemented in the driver IE. 'lrev' or 'hvdc'. But in chan_dahdi 'mwisendtype' is used for higher level methods, IE 'fsk' and 'rpas'

'vmwimessages' is the number of messages, trafrir (Xorcom) suggested we keep the number of messages. If vmwimessages=0 then line reversal is then set back to normal. But for the line reversal method this is only needed as a boolean bit.

I never intended MWI FSK generation to be pushed down into wctdm and the like, it needs to stay in chan_dahdi.

chan_dahdi could implement channel line reversal, I have asked before on asterisk-dev, why is there a module parameter in wctdm.c to reverse all FXS lines, why global not channel? It's not in wctdm24xxp though.
I can foresee additional requirements to reverse the line while it's already
reversed, so we have to be careful there.
By: Doug Bailey (dbailey) 2009-01-08 11:05:59.000-0600

I had not really thought through the situation where there could be multiple
line reversal situations.  It certainly could be a problem though I have a hard
time thinking that a phone would be configured for line reversal MWI and use
line reversal alert signaling for Caller ID.

If the for some reason someone wanted this situation, what would occur when a
message is already pending and a line reversal alert is requested?  I would assume
that the event of the line reversal transition is what is actually desired for the alert signal.
Therefore I would implement it so that the polarity would transition back to nominal polarity in
this situation.  (An exclusive Or'ing of all the conditions.)

Or do we just say you can't do that and say the two modes are incompatible.
By: Alec Davis (alecdavis) 2009-01-08 14:17:13.000-0600

I say we can do multiple line reversals, a MWI pending line reversal and a DAHDI line reversal if required for caller id.

For this to work the 'reversepolarity' global module parameter in wctdm needs to be changed to a channel variable, or leave the module parameter and change DAHDI_SETPOLARITY ioctl to control a new 'reversepolarty' channel variable.

In other words (all 3 of the following are xor together to detemined the actual line state);
 wctdm module parameter 'reversepolarity' reverses all FXS channels.
 wctdm fxs.channel variable 'reversepolarity' reverses  a FXS channel.
 wctdm fxs.channel variable 'vmwi_lrev' reverses a FXS channel.

I already do a 'logical exclusive or' of 'reversepolarity' and 'vmwi_lrev' to determine wheter to set line reversed or line normal. So changing this to XOR 3 variables is easy.


By: Doug Bailey (dbailey) 2009-01-08 14:41:19.000-0600

The DAHDI_SETPOLARITY ioctl call is problematic.  The wctdm
implementation that I have looked at is transitory.  The value that is set is
thrown away on the next linefeed transition.  It does not appear to be very deterministic.  

I can't see where it is used in the code base and if there truly a need for this type of behavior.  (It doesn't seem to be particularly useful.)  

If we do add a channel parameter for polarity, do we change the nature of the DAHDI_SETPOLARITY ioctl call as well or do we come up with a new call that
handle the new behavior?
By: Tzafrir Cohen (tzafrir) 2009-01-08 14:52:14.000-0600

Is it used anywhere outside fxstest?

The module parameter reversepolarity is a hack, I guess. It may be useful for initialization. But module parameters cannot be used for per-channel information in a sane way.

Furthermore, the user can change its value at any time without letting us know. So let's make it read-only for now (at least conceptioally) and wait for sysfs to add proper per-channel controls (already implemented at the span level. Can be implemented at the channel level)
By: Alec Davis (alecdavis) 2009-01-08 16:01:27.000-0600

If DAHDI_SETPOLARITY ioctl was changed to a channel variable, fxstest would still work.

DAHDI_SETPOLARITY ioctl does seem deterministic, as the VMWI code I implemented followed the reversepolarity logic and I haven't faulted VMWI yet.

The question is, when do you see it as not being deterministic?
I think the answer is, The line will only reflect the appropriate polarity after going off-hook then on-hook.


By: Alec Davis (alecdavis) 2009-01-09 05:07:07.000-0600

uploaded wctdm.mwisendtype.diff3.txt
uploaded fxstest.diff.txt

wctdm:
Added a fxs channel variable 'reversepolarity'.
module parameter 'reversepolarity' still supported.
DAHDI_SETPOLARITY ioctl, now controls the fxs channel variable 'reversepolarity'.
VMWI ioctl changed to set line state, mainly for fxstest.

All 3 variables related to reversepolarity are logically xor'd together, to set line polarity. This allows for chan_dahdi to reverse the line for callerid if required, even if the line is already reversed due to the module parameter being set, or vmwi_lrev is set.

fxstest:
added support for VMWI message testing, and minor change to allow setting polarity immediately after wctdm is loaded, otherwise a ring test was required first.


By: Doug Bailey (dbailey) 2009-01-09 16:10:17.000-0600

I've taken attached a patch that takes the wctdm modifications and mirrors them in the wctdm24xxp driver.  

I am still looking at chan_dahdi but want to find the cause of the http://bugs.digium.com/view.php?id=14143 issue before I get too far with testing out the line reversal MWI addition.
By: Alec Davis (alecdavis) 2009-01-09 17:33:35.000-0600

For what it's worth regarding the wctdm patches.

I didn't like my logical XOR testing, it's not very readable, it's dependant on an odd number of terms, and when compiled with 'cc -S xor_test.c' takes one more instruction.

The 2nd and 3rd method below compile to exacly the same instructions, any number of terms can be evaluated, and I believe the 3rd method is most readable.

 result = ( !(!var1 != !var2) != !var3); /*12 instructions */
 printf("XOR var1=%d var2=%d var3=%d result=%d\n", var1, var2, var3, result);

 result = (!!var1 ^ !!var2 ^ !!var3); /*11 instructions */
 printf("XOR var1=%d var2=%d var3=%d result=%d\n", var1, var2, var3, result);

 result = ( (0!=var1) ^ (0!=var2) ^ (0!=var3) ); /*11 instructions */
 printf("XOR var1=%d var2=%d var3=%d result=%d\n", var1, var2, var3, result);


By: Alec Davis (alecdavis) 2009-01-12 03:45:01.000-0600

uploaded dahdi_lrevmwi.wctdm.part2.diff.txt

This needs to be applied after dahdi_lrevmwi.patch.txt
This only modifies wctdm.c to use a similar shortcut POLARITY_XOR as in wctdm24xxp.c

Also changed the shortcut to the more readable format, as I mentioned in the previous note.

#define POLARITY_XOR(card) ((reversepolarity!=0) ^ (wc->mod[(card)].fxs.reversepolarity!=0) ^ (wc->mod[(card)].fxs.vmwi_lrev!=0))

tested OK TDM400P channel 32. Also used modified fxtest.c to check polarity reversal and vmwi.

Doug: user.h has small typo WMWI instead of VMWI


By: Alec Davis (alecdavis) 2009-01-13 04:49:46.000-0600

please remove wctdm.mwisendtype.diff4.txt

uploaded wctdm.mwisendtype.diff5.txt which only modifies wctdm.c from svn 9th Jan 2009.

This adds wctdm.c driver support for MWI HVAC neon generator, as recommended from xpp/card_fxs.c, as well as previous changes.
By: Doug Bailey (dbailey) 2009-01-13 17:29:40.000-0600

Since you are now setting the the lasttxhook to 4 to generate the HVAC neon generator, will this not get mixed up as a ringing indicator.  

This obviously cannot coexist with FSK MWI as OHT mode is not available while generating the HVAC pulses using the ring mode.  Do we see any way of interlocking this or what the side effects are when doing this?  

How does the HVAC get restarted after standard ringing? I don't believe that chan_dahdi will initiate anything after the ringing event.
By: Alec Davis (alecdavis) 2009-01-13 19:32:02.000-0600

re. neon generator lasthook=4

I was testing with all three parameters set, mwisendtype=rpas,lrev,hvac, I got the ring pulse, then I presume I got the FSK (I'll test with a caller id unit)then I got the NEON generator, but with NEON ringing the line can only be REVERSE.

I think we should be controlling the line polarity with the VSGN bit of SIL3215 register 72, not by setting the FORWARD/REVERSE transfer mode as we are currently doing.

I'm sure HVAC got restarted after standard ringing, development box isn't here, so unable to verify at moment.
By: Alec Davis (alecdavis) 2009-01-14 05:23:40.000-0600

uploaded wctdm.mwisendtype.diff6.txt
please remove wctdm.mwisendtype.diff5.txt

neon ringing seems to require SLIC to be in Forward Active before setting parameters, otherwise phone ringer triggers every pulse (4Hz). This will make 'lrev' and 'hvac' mutually exclusive, unless I've missed something.

Neon HVAC, working correctly with various phones, one with a real Neon, not just a LED+Zener.

Further work required, MWI FSK as this doesn't yet work with 'hvac'. The intention there would be while the FSK is being sent change to OHT mode.

MWI FSK works with 'lrev', the senario being 2 phones on the same circuit, or a caller id unit next to phone.

HVAC does get restarted after a standard ring. Tested with 'mwisendtype=hvac' purposely to avoid the 'rpas' or 'lrev' fixing things up.

some whitespace cleanup has crept in.

OT. Whats the syntax you used to create the indexed unified diff?
By: Alec Davis (alecdavis) 2009-01-14 13:36:42.000-0600

Doug:
I think this feature has got a bit ambitious, it's met it's first mile stone. Between your efforts with the 24 port card and some minor cleanup the 'polarity reversal' and VMWI line reversal is ready to go.

The neon generation is a lowlevel driver mod effort that can carry on in perhaps a new bug/feature.
By: Doug Bailey (dbailey) 2009-01-14 13:45:06.000-0600

I agree.  I will go ahead and merge the 14143 fix for chan_dahdi and then will work to pull in the line reversal VMWI in this issue.
By: Doug Bailey (dbailey) 2009-01-15 13:48:30.000-0600

Since NEON VMWI is not going to be implemented, I assume that I am to use  wctdm.mwisendtype.diff5.txt with the wctdm_set_vmwi_neon_mode function and associated calls removed as the basis for your changes to wctdm.c.  

Should the VMWI ioctl fail if the fxs port is ringing or should the state get set and the polarity will be set properly when the ringing stops.  (i.e. set the idletxhookstate but do not set the lasttxhook variable.)


By: Doug Bailey (dbailey) 2009-01-15 15:37:13.000-0600

dahdidriver-14104.diff.txt (dahdi driver changes), dahditools-14104.diff.txt (fxstest changes), and asttrunk-14104.diff.txt (chan_dahdi changes) have been uploaded for perusal before I commit them.
By: Alec Davis (alecdavis) 2009-01-15 16:38:35.000-0600

Your correct, wctdm.mwisendtype.diff5.txt is best to use, and undo the neon generation code.

VMWI ioctl, agreed, if ringing then idletxhookstate should be set not   lasttxhook.

Regarding Neon VMWI. I'll open a new bug/feature when this committted. I'm nearly there.
By: Alec Davis (alecdavis) 2009-01-15 16:49:04.000-0600

refer http://bugs.digium.com/view.php?id=14104#97399

In wctdm.c I changed the POLARITY_XOR macro
Do you want to change it for wctdm24xxp.c

from
#define POLARITY_XOR(card) (!reversepolarity != !(!wc->mods[(card)].fxs.reversepolarity != !wc->mods[(card)].fxs.vmwilinereverse))

to
#define POLARITY_XOR(card) ( (reversepolarity != 0) ^ (wc->mods[(card)].fxs.reversepolarity != 0) ^ (wc->mods[(card)].fxs.vmwilinereverse != 0) )
By: Alec Davis (alecdavis) 2009-01-15 17:04:33.000-0600

chan_dahdi.c

The changes in mwi_send_process_buffer don't seem to be here, to allow 'nofsk' but still have an 'rpas'

'rpas' may be needed before the MWI FSK, so both flags DAHDI_VMWI_RPAS and DAHDI_VMWI_FSK should be set.

+ if (strcasestr(v->value, "rpas")) { /* Ring Pulse Alert Signal with FSK*/
+ confp->chan.mwisendtype |= DAHDI_VMWI_RPAS;
+ confp->chan.mwisendtype &= ~DAHDI_VMWI_FSK;
+ }

so remove
- confp->chan.mwisendtype &= ~DAHDI_VMWI_FSK;
By: Doug Bailey (dbailey) 2009-01-15 17:11:26.000-0600

I guess I was always treating DAHDI_VMWI_RPAS to be a MWI FSK message preceded by a ring pulse alert signal.  I always thought of it as an either or option.

Does this need to be better described? (Perhaps DAHDI_VMWI_RPAS_FSK)  

Presently the RPAS is highly integrated into the FSK spill generation.
By: Alec Davis (alecdavis) 2009-01-15 17:52:01.000-0600

uploaded chan_dahdi_mwisend_part2.diif.txt (can't spell)

This change modifies the FSK spill generation, to allow an RPAS without the MWI FSK

The ground work here is to allow us later to add a 'Line Reversal Alert Signal' as may be required in some countries, as some callerid units/phones need to wake them up. Also could included DTMF spill instead of FSK.

Alec
By: Alec Davis (alecdavis) 2009-01-16 03:11:16.000-0600

applied asttrunk-14104.diff.txt
applied dahdidriver-14104.diff2.txt

tested and works, after fixing the senario where mwisendtype is commented out, which will be most default installs. The default is to act as previously, to send the FSK MWI spill.

uploaded chan_dahdi_nodefaultfsk.diff.txt to fix this.

tests  (with callerid unit and phone with LineReversal LED)
in chan_dahdi.conf
mwisendtype commented out or nonexistant (same as previous behaviour)
 left a message, FSK MWI spill was sent, callerid unit updated.
 cleared all messages. FSK MWI spill was sent, callerid unit updated.

mwisendtype=rpas (same as previous behaviour)
 left a message, ring pulse, FSK MWI spill was sent, callerid unit updated.
 cleared all messages. ring pulse, FSK MWI spill was sent, callerid unit updated.

mwisendtype=lrev
 left a message, FSK MWI spill was sent, callerid unit updated. MWI LED on.
 cleared all messages. FSK MWI spill was sent, callerid unit updated. MWI LED off.

mwisendtype=lrev,rpas
 left a message, Ring pulse, FSK MWI spill was sent, callerid unit updated. MWI LED on.
 cleared all messages. Ring pulse, FSK MWI spill was sent, callerid unit updated. MWI LED off.

mwisendtype=lrev,nofsk
 left a message, FSK MWI spill was NOT sent, callerid unit NOT updated. MWI LED on.
 cleared all messages. FSK MWI spill was NOT sent, callerid unit NOT updated. MWI LED off.

alec


By: Doug Bailey (dbailey) 2009-01-16 13:40:09.000-0600

asttrunk-14104.diff2.txt uploaded incorporating your suggestions.  

I tested it with both the modified dahdi drivers and the current trunk dahdi drivers with positive results.  

Anything else missing?
By: Alec Davis (alecdavis) 2009-01-16 14:43:14.000-0600

My last thoughts were, the #IFDEF's I had through chan_dahdi.c that would allow anyone to upgrade asterisk to SVN, and Asterisk would still compile if DAHDI hadn't been upgraded. But just checked and they are now in there.

So my testing last night on a TDM400P with FXS's with Si3210 and Si3215 both worked as expected, and your testing I presume using the wctdm24xxp drivers.

Looks good.

Opened http://bugs.digium.com/view.php?id=14261 to continue with Neon Generation.


By: Doug Bailey (dbailey) 2009-01-16 17:05:07.000-0600

In the monitoring of mwi, chan_dahdi recognizes "mwimonitor=neon"  
I suggest that this modification allow the keyword "neon" as well and set hvac as enabled.  Any problems with that?

mwisendtype=neon
By: Alec Davis (alecdavis) 2009-01-16 18:47:42.000-0600

I'd been thinking about instead of 'hvac' use 'neon', but both works for me.

Technically the neon pulses are pulsed DC not AC, and for a user I think 'neon' makes more sense, and it's consistant with the FXO 'mwimonitor=neon'.
By: Alec Davis (alecdavis) 2009-01-19 01:04:21.000-0600

uploaded chan_dahdi.rpas_and_fsk.diff.txt, applied after asttrunk-14104.diff2.txt

adds better described, consistant keyword option as "mwisendtype=neon" instead of 'hvac'.

Previously it's been that mwisendtype=rpas would automatically send the MWI FSK spill after the Ring Pulse Alert Signal.

Now that wctdm.c state machine allows an RPAS without the FSK spill, as well original implementation of MWI FSK only, and RPAS plus MWI FSK.
  example: mwisendtype=rpas,nofsk,lrev
  With a message waiting, the above example alerts the user with a single ring pulse, and reverses the line turning on the phone's MWI LED.


By: Alec Davis (alecdavis) 2009-01-19 05:18:08.000-0600

cleanup:
please remove the following
  chan_dahdi_nodefaultfsk.diff.txt now in asttrunk-14104.diff2.txt
  chan_dahdi.conf.sample.diff.txt now in asttrunk-14104.diff2.txt
 
  user.h.vmwisend.diff.txt now in dahdidriver-14104.diff2.txt
  dahdi_lrevmwi.wctdm.part2.diff.txt now in dahdidriver-14104.diff2.txt

  fxstest.diff.txt now in dahditools-14104.diff.txt


By: Digium Subversion (svnbot) 2009-01-19 09:19:24.000-0600

Repository: dahdi
Revision: 5728

U   tools/trunk/fxstest.c

------------------------------------------------------------------------
r5728 | dbailey | 2009-01-19 09:19:23 -0600 (Mon, 19 Jan 2009) | 9 lines

Add test to excercise VMWI
Enhance polarity test by making sure the line is in an active state before testing
(issue DAHLIN-68)
Reported by: alecdavis
Patches:
     dahditools-14104.diff.txt uploaded by dbailey (license )
Tested by: alecdavis


------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5728
By: Doug Bailey (dbailey) 2009-01-19 10:30:47.000-0600

Per discussion with tzafrir, the number of messages in the DAHDI_VMWI have been increased to 16 bits.  (Up from 8 bits)
By: Digium Subversion (svnbot) 2009-01-19 10:33:30.000-0600

Repository: asterisk
Revision: 169277

U   trunk/channels/chan_dahdi.c
U   trunk/configs/chan_dahdi.conf.sample

------------------------------------------------------------------------
r169277 | dbailey | 2009-01-19 10:33:29 -0600 (Mon, 19 Jan 2009) | 9 lines

Add enhanced MWI generation to take advantage of new dahdi line reversal MWI ability.

(closes issue DAHLIN-68)
Reported by: alecdavis
Patches:
     asttrunk-14104.diff2.txt uploaded by dbailey (license )
     chan_dahdi.rpas_and_fsk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, dbailey

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=169277
By: Alec Davis (alecdavis) 2009-01-20 01:37:13.000-0600

Reopened:
uploaded wctdm_fixneon.diff.txt

After downloading new SVN rev 5746 there is still some critical neon generation code that was left over.
It takes effect when mwisendtype=neon

The result is after the first time the phone is rung, the phone has non-cadenced ring forever.


By: Alec Davis (alecdavis) 2009-01-20 03:40:28.000-0600

uploaded wctdm_whitepsace.diff.txt

white space cleanup throughout wctdm.c


By: Doug Bailey (dbailey) 2009-01-20 09:32:49.000-0600

I've attached  mwiioctl_structure_dahdi.diff.txt and mwiioctl_structure.diff.txt that implements the DAHDI_VMWI ioctl call using a structure to pass MWI information as opposed to packing bits into an integer.  

Since there are no longer any #defines added to user.h to indicate that this support is available, I need to add to the asterisk configure script to detect the new structure.
By: Alec Davis (alecdavis) 2009-01-20 17:19:56.000-0600

They've vanished....
By: Doug Bailey (dbailey) 2009-01-20 17:36:33.000-0600

My bad.  I got distracted while updating.  
I've attached  mwiioctl_structure_dahdi.diff2.txt and  mwiioctl_structure_asterisk.diff2.txt that have been tested on the wctdm24xxp.  It has not been tested on the wctdm driver.  

In addition, I will probably commit the white space cleanup on its own as a separate commit.
By: Alec Davis (alecdavis) 2009-01-21 02:27:16.000-0600

applied mwiioctl_structure_dahdi.diff2.txt and mwiioctl_structure_asterisk.diff2.txt

Tested and confirmed OK on TDM400P with modules with Si3210 and Si3215 proslics.

mwisendtype=lrev worked as expected, FSK and Line reversal
mwisendtype=rpas,lrev worked as expected, RPAS, FSK and Line reversal
mwisendtype=lrev,nofsk  worked as expected, Line reversal and NO FSK
mwisendtype=neon worked as expected, FSK only, as driver not yet submitted.
By: Alec Davis (alecdavis) 2009-01-21 05:54:06.000-0600

uploaded fxstest_neon_hvdc.diff.txt

fxstest:
support 'struct' method, not bit setting.
added following FXS exerciser
'hvdc' - High Voltage DC
'neon' - Pulsed DC.

Tested on TDM400P.
By: Doug Bailey (dbailey) 2009-01-21 09:37:03.000-0600

mwiioctl_structure_asterisk.diff3.txt has a tweak to fix backward compatibility
By: Digium Subversion (svnbot) 2009-01-21 09:39:31.000-0600

Repository: dahdi
Revision: 5785

U   linux/trunk/drivers/dahdi/wctdm.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/base.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/wctdm24xxp.h
U   linux/trunk/include/dahdi/user.h

------------------------------------------------------------------------
r5785 | dbailey | 2009-01-21 09:39:30 -0600 (Wed, 21 Jan 2009) | 9 lines

Change the DAHDI_VMWI ioctl call to pass data via structure.  
Changed wctdm and wctdm24xxp to handle these calls.
(issue DAHLIN-68)
Reported by: alecdavis
Patches:
     mwiioctl_structure_dahdi.diff2.txt uploaded by dbailey (license )
Tested by: alecdavis, dbailey


------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5785
By: Doug Bailey (dbailey) 2009-01-21 13:47:38.000-0600

I committed a patch this morning for the changes in the ioctl call.  It was quickly brought to my attention that any future VMWI types will break the ioctl call due to needing a new byte for each type of VMWI required.  

Therefore, I have brought back the bit field much as was done previously but I have split it away from the number of messages.  (I have kept the structure and split the bit type bit field away from the number of messages.)  

I have also dumped the RPAS and FSK settings as they are handled in chan_dahdi and not in the driver.  These are now specified locally to chan_dahdi

What the patches are:
mwiioctl_structure_dahdi.diff4.txt - dahdi patches to what I committed today.  
mwiioctl_structure_asterisk.diff4.txt - The asterisk patch to bring trunk from today to handle the latest ioctl call
mwiioctl_structure_fxstest.diff.txt - Alec's changes in fxstest brought up to the latest ioctl call.
By: Alec Davis (alecdavis) 2009-01-21 15:19:23.000-0600

Doug, want to assign yourself to http://bugs.digium.com/view.php?id=14261
Or should we close that one and continue Neon support here.
By: Alec Davis (alecdavis) 2009-01-21 18:01:05.000-0600

please remove
chan_dahdi_mwisend.diff3.txt now in mwiioctl_structure_asterisk.diff4.txt
chan_dahdi.rpas_and_fsk.diff.txt now in mwiioctl_structure_asterisk.diff4.txt

wctdm_fixneon.diff.txt now in mwiioctl_structure_dahdi.diff4.txt
fxstest_neon_hvdc.diff.txt now in mwiioctl_structure_fxstest.diff.txt
By: Alec Davis (alecdavis) 2009-01-22 03:38:22.000-0600

applied the following.
mwiioctl_structure_dahdi.diff4.txt
mwiioctl_structure_asterisk.diff4.txt
mwiioctl_structure_fxstest.diff.txt

Tested Asterisk functionality on TDM400P all OK.
Tested fxstest, all OK.
By: Digium Subversion (svnbot) 2009-01-22 09:42:20.000-0600

Repository: dahdi
Revision: 5799

U   linux/trunk/drivers/dahdi/wctdm.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/base.c
U   linux/trunk/include/dahdi/user.h

------------------------------------------------------------------------
r5799 | dbailey | 2009-01-22 09:42:19 -0600 (Thu, 22 Jan 2009) | 9 lines

Change structure passed in DAHDI_VMWI ioctl call to make it so new VMWI types do not break the ioctl call
Remove FSK and RPAS from the VMWI types as no driver implemented them and the functionality is in chan_dahdi.

(issue DAHLIN-68)
Reported by: alecdavis
Patches:
     mwiioctl_structure_dahdi.diff4.txt uploaded by dbailey (license )
Tested by: alecdavis, dbailey

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5799
By: Digium Subversion (svnbot) 2009-01-22 09:45:08.000-0600

Repository: dahdi
Revision: 5800

U   tools/trunk/fxstest.c

------------------------------------------------------------------------
r5800 | dbailey | 2009-01-22 09:45:08 -0600 (Thu, 22 Jan 2009) | 8 lines

Alec Davis change to modify vmwi test to use new ioctl call structure and enhance functionality
(issue DAHLIN-68)
Reported by: alecdavis
Patches:
     mwiioctl_structure_fxstest.diff.txt uploaded by dbailey (license )
Tested by: alecdavis, dbailey


------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5800
By: Digium Subversion (svnbot) 2009-01-22 09:49:42.000-0600

Repository: asterisk
Revision: 170112

U   trunk/channels/chan_dahdi.c
U   trunk/configure
U   trunk/configure.ac
U   trunk/include/asterisk/autoconfig.h.in

------------------------------------------------------------------------
r170112 | dbailey | 2009-01-22 09:49:42 -0600 (Thu, 22 Jan 2009) | 8 lines

change VMWI to use new DAHDI_VMWI ioctl call.  
Change configure script to detect the new ioctl call data structure.    
(issue DAHLIN-68)
Reported by: alecdavis
Patches:
     mwiioctl_structure_asterisk.diff4.txt uploaded by dbailey (license )
Tested by: alecdavis, dbailey

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=170112
By: Doug Bailey (dbailey) 2009-01-26 17:36:12.000-0600

Earlier commits broke the DAHDI_VMWI ioctl call for older asterisk binaries.  
mwiioctl_structure_asterisk.diff5.txt, mwiioctl_structure_dahdi.diff5.txt and mwiioctl_structure_fxstest.diff5.txt restructure the ioctl call to fix this.
By: Digium Subversion (svnbot) 2009-01-27 09:13:15.000-0600

Repository: dahdi
Revision: 5826

U   linux/trunk/drivers/dahdi/wctdm.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/base.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/wctdm24xxp.h
U   linux/trunk/include/dahdi/user.h

------------------------------------------------------------------------
r5826 | dbailey | 2009-01-27 09:13:15 -0600 (Tue, 27 Jan 2009) | 6 lines

Break VMWI ioctl calls into two separate calls to maintain old revision compatibility

(issue DAHLIN-68)
Reported by: alecdavis
Tested by: dbailey

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5826
By: Digium Subversion (svnbot) 2009-01-27 09:13:56.000-0600

Repository: dahdi
Revision: 5827

U   tools/trunk/fxstest.c

------------------------------------------------------------------------
r5827 | dbailey | 2009-01-27 09:13:55 -0600 (Tue, 27 Jan 2009) | 7 lines

Break VMWI ioctl calls into two separate calls to maintain old revision compatibility

(issue DAHLIN-68)
Reported by: alecdavis
Tested by: dbailey


------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5827
By: Digium Subversion (svnbot) 2009-01-27 09:23:12.000-0600

Repository: asterisk
Revision: 171558

U   trunk/channels/chan_dahdi.c

------------------------------------------------------------------------
r171558 | dbailey | 2009-01-27 09:23:12 -0600 (Tue, 27 Jan 2009) | 7 lines

Handle new VMWI ioctl structure (Now there are two VMWI ioctl calls.)  

(issue DAHLIN-68)
Reported by: alecdavis
Tested by: dbailey


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=171558