[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:              12-03-2007 03:01 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 - 12-03-07 03:01  
---------------------------------------------------------------------- 
menault, thank you for the feedback.

First : replies to you questions :
- What is supposed to be the right voltage for a on-hook line in your
country?
  => about 48V
- Do you have any phones connected in parallel to your FXO port?
  => No
- Is the line really on-hook?
  => Yes

Next : your idea of tracking battery voltage was good, I added a trace in
order to check 'b', and also fxo.battdebounce counter. So, I saw that
battery is stable : -34 or -35 V, and I *also* saw that battdebounce always
is 3. I will upload flf_wctdm.c-1.4.7-debugonly-checkbatt with additional
traces included (I also tried a few variations on sampling rate in order to
be sure that battdebounce always 3 was not a sampling artefact).

That's why we never enter code section that may call
zt_hooksig(&wc->chans[card], ZT_RXSIG_OFFHOOK) and update line state. If I
try to analyse the code (not so easy, due to numerous conditional
compilation ...) :
- Let's consider that ...
  . AUDIO_RINGCHECK, JAPAN, ZERO_BATT_RING are NOT defined
  . your patch is applied
  . mine is not
  . we sometime get a stable battery voltage such as abs(b) > battthresh
and a fxo.battdebounce equal to 3 (that's what I see in traces)
- How does wctdm_voicedaa_check_hook() run ?
  . handle poopy stuff
  . handle ring
  . read voltage "b = wc->reg1shadow[card];"
  . "if (abs(b) < battthresh)" : skip
  . "else if (abs(b) > battthresh)" : execute ...
      . "if (!wc->mod[card].fxo.battdebounce)" : skip !
      . "else if (wc->mod[card].fxo.battery)" : execute (whether it is 1
or -1)
          "wc->mod[card].fxo.battdebounce = battdebounce;"
          => back to battdebounce = 4 (default value)
  ... some more code
  . "if (wc->mod[card].fxo.battdebounce)
wc->mod[card].fxo.battdebounce--;"
    => result is fxo.battdebounce = 3
So, if no event occurs, zt_hooksig() will never be called.

In fact, I suspect it works for you and not for me, due to a competition
between ztcfg called when zaptel service starts, and initial battery
debounce : if zaptel starts faster than initial battery debounce, then end
of debounce will update correct line state, otherwise ztcfg will force
ZT_RXSIG_INITIAL that "prevents" ZT_GET_PARAMS "correct" handling in
zaptel-base.c:zt_common_ioctl() (see logs I uploaded on 11/28). Otherwise,
I don't understand how zt_hooksig() can be called periodically for you and
not for me :-( 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-03-07 03:01  flefoll        Note Added: 0074663                          
======================================================================