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:45	Date Closed:	2009-07-27 14:26:29
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence
Related Issues:
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. */ /* #define DAHDI_CHECK_HOOKSTATE */ Sadly, DAHDI_CHECK_HOOKSTATE is defined unconditionally in include/asterisk/dahdi_compat.h in case you built it with zaptel support: #define DAHDI_CHECK_HOOKSTATE ZT_CHECK_HOOKSTATE 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_EVENT_EC_DISABLED #ifdef DAHDI_EVENT_RINGBEGIN #ifdef DAHDI_GETCONFMUTE #ifdef DAHDI_PRI #ifdef DAHDI_TONEDETECT
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 1.4.12.1 .. 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 1.4.12.1. 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 1.4.12.1. 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. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=158629 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 1.4.22.1 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: http://lists.digium.com/pipermail/asterisk-users/2008-November/thread.html#221553 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=160319 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: http://lists.digium.com/pipermail/asterisk-dev/2009-January/036054.html 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.