[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:              10-22-2007 04:34 CDT
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 meneault - 10-22-07 04:34  
---------------------------------------------------------------------- 
I think that this is partly because the patch description is a little
confused.

So I will try to explain it further:

First trying to determine busy state from an analog FXO line is just not
possible with Loop Start and Kewl Start signalling (the ones that wctdm
implement).
That's why when you look at 'zap show channel' output you get 'Hookstate
(FXS only):'. It is specified that the value is only valid for fxs channels
(i.e FXO signalling).

However you can still know if you get battery from telco provider or not.
This may tell you if a line is physically connected to your card but no
more, 
knowing if the line is busy is not theorically possible
(hacks are still possible but may not be integrated in the main branch
IHMO).

That's probably why the ZAP_CHECK_HOOKSTATE (in chan_zap) is a
compile-time define because it is a hack that may be usefull for some
users... (for instance it has not be designed for Loop Start Signalling, I
can't figure out why).

RX state ON-HOOK does not mean -for an FXO channel- that line is busy.
likewise RX state OFF-HOOK does not mean line is free.

These states may indicate some state information that may not be related
to the real state of the line.... even if it tries to do so...
They are more related to battery states and ring states than hook states.

RX ON-HOOK state should be seen as no battery on the line.
 	
So while your card is on-hook the only "reliable" thing you could get is:
whether a line is connected or not.

Usually in drivers, it is implemented by a Red Alarm (state borrowed from
T1 lines) when no line is connected, but actually wctdm does not trigger
this alarm
(whereas wcfxo does).
Why? maybe because the state is only relevant to T1 channels, using a T1
state
for an analog line can be seen as a hack too.

Moreover in case of red alarms, in chan_zap you are only warned of it
during
chan_zap.c 'zap show status'. But the state is not checked before
any call attempts (AFAIK).

IHMO a clean patch would be to:
- add battery-alarm in zaptel (or use red-alarm for battery-alarm).
- add battery-alarm detection on wctdm.
- add battery-alarm (and other alarm checking) before attempting a call in
chan_zap.c.

However this is out of scope for now (at least for me), so I took a look
at your patch and I tried to get this fixed in a cleaner manner.
Please note that I use zaptel 1.4 so my patches will only apply cleanly
for zaptel 1.4!

In patch description you say that fxo.battery is not initialized,
that's false 'memset(wc, 0, sizeof(struct wctdm));', however
you are right saying that there is a problem in initialization because
there is a bug -- a tricky race condition.

The problem lies while checking if card is an FXO or an FXS,
in wctdm_init_proslic routine (unions are used in an unsafe manner!).
My first patch wctdm-race-1.4-rev3211 correct this tricky bug.

But there is still the problem that if no line is connected then it won't
be noticed (cause fxo.battery is initialized to 0).
So we'll have to initialize to -1 (unknown) and then check for it in check
hook
state routing.

Now the second part of your problem is still there, because when running
ztcfg
at boot will erase the right hook state by RXSIG_INITIAL.

To correct this we only force to update the rx hook state every
battdebounce ms
so that it is properly noticed to zaptel-base and then to chan_zap or
whoever is using zaptel modules. This is safe because it won't do anything
if the new state   is the same as the old state.

So there is no need to patch zaptel-base.c anymore!

So you could try my patches (apply them in order):
wctdm-race-1.4-rev3211
wctdm-hooksig-1.4-rev3211

Note to maintainer:
Please note that there is outdated code in wctdm.c JAPAN and
ZERO_BATT_RING, I am not sure anyone has ever used it and may ever use it
because it has been copied (AFAIK) from wcfxo code in april 2004 and has
never been fixed to compile properly on wctdm (try to find wc->onhook and
wc->offhook variables in wctdm struct!!!!). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-22-07 04:34  meneault       Note Added: 0072329                          
======================================================================