[asterisk-bugs] [Zaptel 0008290]: [patch] zap hookstate is never set offhook if wctdm module is loaded with an active fxo line

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8290 
====================================================================== 
Reported By:                tmarkov
Assigned To:                mattf
====================================================================== 
Project:                    Zaptel
Issue ID:                   8290
Category:                   wctdm
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Zaptel Version:              1.2.10 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             11-03-2006 17:28 CST
Last Modified:              11-28-2007 07:38 CST
====================================================================== 
Summary:                    [patch] zap hookstate is never set offhook if wctdm
module is loaded with an active fxo line
Description: 
If #define ZAP_CHECK_HOOKSTATE is uncommented in chan_zap.c, then the
hookstate stays onhook if the wctdm module is loaded with an active line. 
Removing line and reinserting will cause the hookstate to initialize
properly.  The problem appears to be that wc->mod[card].fxo.battery never
gets initialized to 0, so in wctdm_voicedaa_check_hook() the test "if
(!wc->mod[card].fxo.battery && !wc->mod[card].fxo.battdebounce)" is never
entered, and the hookstate remains onhook upon module startup.  Only a
cycling of line voltage will correct the problem.  I have attached a patch
which initializes the battery variable and fixes the problem for me.
====================================================================== 

---------------------------------------------------------------------- 
 flefoll - 11-28-07 07:38  
---------------------------------------------------------------------- 
I tried patch proposed by meneault with Zaptel 1.4.6 and, although it
applies correctly, it does not seem to fix the problem with the initial fxo
line state, at least for me, with Asterisk 1.4.13, Zaptel 1.4.6 and a
TDM400P in a CentOS 5.0 machine.

In fact, it seemed to work a few times, but more tests showed that the
defect was always there. I think that it init problem is time-sensitive and
results may differ, depending on platforms.

In order to investigate, I have equipped zaptel-base.c and wctdm.c with a
number of traces ('dmesg -c' to get the traces).

wctdm.c also includes code from menault (if MPATCH if #define'd). In my
tests, I see that code that should "force update of rx hook state every
battdebounce ms" does not run periodically (changes in battdebounce
handling ?) although wctdm_voicedaa_check_hook() DOES run every 1 out of 4
interrupts.

So, I added another patch (if FPATCH if #define'd) that also forces update
if rxhooksig was set to ZT_RXSIG_INITIAL. With this patch, fxo state is
correctly set avec initialization sequence, and outgoing calls succeed
without needing a disconnect/reconnect or an incoming call.
... At least for all tests I ran.

The same problem occurs with the TDM2400P, the same fix probably is
applicable  to wctdm24xxp/base.c (not tried yet).

I will upload :
flf_zaptel-base.c-1.4.6-debugonly (only logs)
flf_wctdm.c-1.4.6-debugonly (logs, MPATCH, FPATCH)
flf_MPATCH_alone.log
flf_MPATCH_and_FPATCH.log
flf_FPATCH_alone.log
These files are just for investigation at the moment.

Any feedback STRONGLY welcome ! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-28-07 07:38  flefoll        Note Added: 0074467                          
======================================================================