Summary:ASTERISK-12968: [patch] DAHDI_CHECK_HOOKSTATE automatically defined when chan_dahdi is built with zaptel support
Reporter:Tzafrir Cohen (tzafrir)Labels:
Date Opened:2008-10-26 06:15:45Date Closed:2009-07-27 14:26:29
Versions:Frequency of
Environment:Attachments:( 0) dahdi_fix_defs.diff
( 1) trunk_check_hookstate_define.diff
Description:chan_dahdi.c has the following compile time option:

/*! \note
* Define if you want to check the hook state for an FXO (FXS signalled) interface
* before dialing on it.  Certain FXO interfaces always think they're out of
* service with this method however.

Sadly, DAHDI_CHECK_HOOKSTATE is defined unconditionally in include/asterisk/dahdi_compat.h in case you built it with zaptel support:


Thus it should be made conditioned on the definition of ZT_CHECK_HOOKSTATE, just in case someone had it in a build script.

At first glance it seems that the same applies to:

#ifdef DAHDI_PRI
Comments:By: Tzafrir Cohen (tzafrir) 2008-10-26 09:51:53

ZT_EVENT_RINGBEGIN - defined before zaptel 1.2 . Do we really care to keep compatibility to those old Zaptel versions?
ZT_EVENT_EC_DISABLED - from ~ Zaptel 1.2.6
ZT_CONFMUTE - way way older than ZT_EVENT_BEGIN

DAHDI_PRI - Should probably be replaced with HAVE_PRI

ZT_TONEDETECT is from 1.4.8/1.2.23

By: Tzafrir Cohen (tzafrir) 2008-10-28 14:39:07

Fixed patch: fixed handling of DAHDI_CHECK_HOOKSTATE itself.

By: Tzafrir Cohen (tzafrir) 2008-11-13 08:30:50.000-0600

It seems that in 1.6 the whole DAHDI_CHECK_HOOKSTATE ifdef was removed, but it always assumes that this needs checking (available() returns there 0, that is: channel is not available). This seems to break some FXO adapters, e.g. the TDM400 in http://lists.digium.com/pipermail/asterisk-users/2008-November/thread.html#221553 .

This hack is no longer necessary if the FXO adapter provides this information by sending an alarm.

It seems to expose a bug(?) in zaptel/dahdi where chan->rxhooksig is set to RX_HOOKSIG_INITIAL at the end of chanconfig() which leaves the channel's state there "uninitialized" and even if the channel driver knows better it cannot override this decision. But I'm not sure what's the intended behaviour, so I avoid a seperate bug report on that for now.

By: xrobau (xrobau) 2008-11-17 17:30:26.000-0600

Re your last comment, tzafrir, that may be what's causing the problems I'm experiencing with a new install of 1.4.22 with Zaptel .. They are unable to make calls OUT of the FXO ports until the line has rung once, resetting the channels state. The lines aren't in alarm, and they're just coming up CHANUNAVAL without any further reasoning.  I was going to post a new bug, but I believe that this may be it.

By: xrobau (xrobau) 2008-11-17 18:43:54.000-0600

This definately seems to be a bug, Tzafrir.  When Asterisk is started, 'zap show channel 1' has Hookstate: OnHook.  When it it's in that state, you CAN NOT make a call out through it.  Having someone call that line sets the Hookstate to Offhook, at which point it starts working, and will send and receive calls. This is, obviously, broken. Hookstate: Offhook means that the channel SHOULD be unavailable.

By: bobf (netintegrity) 2008-11-17 18:53:46.000-0600

Likewise, was going to log a bug, but more and more it looks like this is the issue. I am running a genuine TDM400 from Digium, tested with 1.4.22 and zaptel Have also tested with 1.4.23rc1. running on Centos 5.2 with all latest YUM updates

Exactly the same fault as xrobau. Unable to make calls out of the FXO ports until the line has rung once. The fault is 100% reproducible by rebooting the box, and the same cycle starts over again.

Have found a workaround which is switching from FXSKS to FXSLS for moment which is showing 100% success.

Card & hardware was working until Centos 5.2, Asterisk 1.4.22rc5 and Zaptel Has also been confirmed the same issue exists by another user running the same system

By: xrobau (xrobau) 2008-11-17 19:27:42.000-0600

Yup, changing to Loop Start fixes that problem, and ALSO fixes the 'Hook State' being incorrect.. when you're using KS, HookState 'onhook' means 'I am broken' and HookState 'Offhook' means 'I am working'. When using LS, it's stuck on 'Onhook' even if it's offhook:

localhost*CLI> show channels
Channel              Location             State   Application(Data)
SIP/111-0915e150     (None)               Up      AppDial((Outgoing Line))
SIP/118-0915c9e8     s@macro-dial:7       Up      Dial(SIP/111||tr)
Zap/1-1              (None)               Up      AppDial((Outgoing Line))

zap show channel 1:
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook

By: xrobau (xrobau) 2008-11-18 15:20:37.000-0600

Created a new bug - http://bugs.digium.com/view.php?id=13927 - referencing this issue.

By: Digium Subversion (svnbot) 2008-11-21 18:04:45.000-0600

Repository: asterisk
Revision: 158629

U   branches/1.4/channels/chan_dahdi.c
U   branches/1.4/include/asterisk/dahdi_compat.h

r158629 | jpeeler | 2008-11-21 18:04:44 -0600 (Fri, 21 Nov 2008) | 5 lines

(closes issue ASTERISK-12968)
Reported by: tzafrir

When compiling against Zaptel dahdi_compat will now only define all the DAHDI defines if the Zaptel define is present. Also, there is no such thing as DAHDI_PRI.



By: Jeff Peeler (jpeeler) 2008-12-01 16:51:44.000-0600

Reopening per request of xrobau.

By: xrobau (xrobau) 2008-12-01 17:09:09.000-0600

Well. There we go. Thanks, jpeeler.  As I mentioned, this is a SERIOUS bug, and it deserves a new release of Asterisk.. Being unable to dial out of a Zaptel port is a SIGNIFICANT issue. The current SVN of branch-1.4 of Asterisk fixes this issue, I believe (yet to fully test), but it's pretty major.

By: Jeff Peeler (jpeeler) 2008-12-01 17:45:22.000-0600

Based on your comment I'm not sure why you had me reopen this bug. The next release will have these changes and 1.4.23-rc2 is on the way out the door. I'll be closing this soon unless you find a problem.

By: xrobau (xrobau) 2008-12-01 18:06:30.000-0600

... Because it's a MAJOR bug. At the moment, anyone who downloads the 'latest' asterisk is unable to make outgoing calls.  This patch should be applied to 1.4.22 and a version released. The current version of asterisk IS SEVERELY BROKEN.

I thought we were a long way past knowingly having significantly broken versions as the current release.

By: Tzafrir Cohen (tzafrir) 2008-12-02 02:07:15.000-0600

xrobau: for some of the people the workaround to use ls instead of ks will apply (unless you rely on ks for disconnect supervision or just don't want to touch a working configuration).

That said, I have applied this fix to my packages.

However, there's a different aspect for this issue: the same code is missing from 1.6.x, and is thus a major regression of the same scale there.

Attaching a patch vs. trunk to re-add the conditional building. 1.6.0 looks the same.

By: Digium Subversion (svnbot) 2008-12-02 12:00:27.000-0600

Repository: asterisk
Revision: 160319

U   trunk/channels/chan_dahdi.c

r160319 | jpeeler | 2008-12-02 12:00:27 -0600 (Tue, 02 Dec 2008) | 7 lines

(closes issue ASTERISK-12968)
Reported by: tzafrir

Readding DAHDI_CHECK_HOOKSTATE define that was removed in r134260 which fixes not being able to make outgoing calls on some FXO adapters:



By: Tzafrir Cohen (tzafrir) 2009-01-11 04:40:34.000-0600

It seems we need to apply the same fix from r160319 to branch 1.6.0.

See also the following mail from Karl Fife:

By: Jeff Peeler (jpeeler) 2009-01-12 10:48:42.000-0600

It looks like the fix is already there. Am I missing something?

By: Tzafrir Cohen (tzafrir) 2009-01-12 14:33:16.000-0600

Already fixed before 1.6.0-rc3, indeed.

My mistake. I'm not sure at which copy of chan_dahdi.c I looked yesterday that seemed unfixed. Sorry for the noise.