[Home]

Summary:ASTERISK-13673: [patch] FXO channels "hookstate" incorrect on startup
Reporter:Jaco Kroon (jkroon)Labels:
Date Opened:2009-03-01 16:16:40.000-0600Date Closed:2010-07-21 13:22:28
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_chan_dahdi_hookstate_fix_trunk_new.diff
( 1) asterisk_chan_dahdi_hookstate_fix.diff
Description:Referencing bug 13786 (http://bugs.digium.com/view.php?id=13786) which attempts to work around an underlying problem in userspace (chan_dahdi).  The issue seems to be (as described by tzafrir):

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.

This is manifested in that I cannot make outbound calls on an FXO card (Using FXSKS signalling) until I've received an incoming call resetting the hookstate to offhook (A single ring is good enough), or alternatively, disconnecting and reconnecting the telephone line.

****** ADDITIONAL INFORMATION ******

I say attempt because the patch really is wrong imho, looking at chan_dahdi.c for asterisk 1.6.0.3 the patch resulted in this code (trimmed on tabs on the left, line 8729 onwards):

if (res) {
   ast_log(LOG_WARNING, "Unable to check hook state on channel %d: %s\n", p->channel, strerror(errno));
} else if ((p->sig == SIG_FXSKS) || (p->sig == SIG_FXSGS)) {
   /* When "onhook" that means no battery on the line, and thus
     it is out of service..., if it's on a TDM card... If it's a channel
     bank, there is no telling... */
   if (par.rxbits > -1)
       return 1;
   if (par.rxisoffhook)
       return 1;
   else
       return 0;
} else if (par.rxisoffhook) {
   ast_debug(1, "Channel %d off hook, can't use\n", p->channel);
   /* Not available when the other end is off hook */
#ifdef DAHDI_CHECK_HOOKSTATE
   return 0;
#else
   return 1;
#endif
}

For an FXO channel using FXSKS or FXSGS signalling the code will not reach the #ifdef part of the code, instead they'll be grabbed by the snippet just above it, and indeed, changing the return 0 on line 8740 resolves the problem for me.

Currently I can work around this bug by changing the return statement, or by using fxsls signalling.

IMHO this (as tzafrir implied) is in fact a ZAPTEL/DAHDI bug that should be fixed.  In the meantime I'm working around the issue by using loopstart signalling instead.
Comments:By: Jaco Kroon (jkroon) 2009-03-01 17:06:49.000-0600

Some further investigation shows that tzafrir is indeed 100 % correct.  The wctdm24xxp module (and supposedly the others too) directly after initializing detects battery on the connected lines, and subsequently signals offhook to dahdi.

Some time after this dahdi_cfg gets run and at line 3992 of drivers/dahdi/dahdi-base.c this line exists:

chans[ch.chan]->rxhooksig = DAHDI_RXSIG_INITIAL;

For a test (since I only have FXO modules in this particular machine) I changed this line to DAHDI_RXSIG_OFFHOOK, which afaik should end up not changing the state at all.  My concern here is that this state may be incorrect anyway as there may not be battery on the line and how it's being forced that way.  So perhaps it's better to just leave this line out entirely (but that may again have other consequences).

If this line is indeed required then something like the following may be more appropriate?

     switch (chans[ch.chan]->sig) {
     case DAHDI_SIG_FXSKS:
     case DAHDI_SIG_FXSGS:
       chans[ch.chan]->rxhooksig = DAHDI_RXSIG_OFFHOOK;
       break;                  
     default:          
       chans[ch.chan]->rxhooksig = DAHDI_RXSIG_INITIAL;
     }                

Alternatively, just don't touch rxhooksig for FXSKS and FXSGS signalling?

Please advise on the correct course of action.

By: Tzafrir Cohen (tzafrir) 2009-03-01 17:21:04.000-0600

When a line has no battery it is in alarm. Hence this test is not really needed anymore.

By: Jaco Kroon (jkroon) 2009-03-01 22:59:57.000-0600

That's a valid point.  Specifically if I'm not mistaken it's a RED alarm in this particular case.

Ok, so you're suggesting to rip out the if/else ladder in channel/chan_dahdi.c (leading up to line 7840) and replacing with a single return, eg:

   if (par.rxbits > -1)
       return 1;
   if (par.rxisoffhook)
       return 1;
   else
       return 0;

becomes

   return 1;

?

I can easily cook up a patch but since I haven't signed any code disclaimers nothing with Digium me doing so might well delay the process.  I can (and don't mind to) go through the process but that would waste time imho and the patch is trivial.

By: Leif Madsen (lmadsen) 2009-03-04 13:36:39.000-0600

jkroon: if you sign the license, it is entirely online, and is usually accepting within 24-48 business hours, so I'd say go ahead and sign the disclaimer, and submit a patch. It'll help move the issue forward.

Thanks!

By: Jaco Kroon (jkroon) 2009-03-04 15:11:14.000-0600

Cool.

I've electronically signed the license thing (must've missed that I can sign it electronically previously as I thought I had to fax/mail it through).

This issue is rather crucial, not sure whether it warrants a version bump or not though.

patch was compile tested as is, logic was tested in production environment.

By: Leif Madsen (lmadsen) 2009-03-04 16:37:50.000-0600

jkroon: thanks for the file. Last time you looked it probably needed to be mailed/faxed, but the process has changed to make it nice and easy :)

By: Jaco Kroon (jkroon) 2009-03-05 14:41:16.000-0600

Ok, I received an email indicating that the license has been formally accepted, can we maybe move this forward?  I've now got this in use at three different sites ... working like a charm so far.

By: Tzafrir Cohen (tzafrir) 2009-03-05 14:56:16.000-0600

(Ack for the issue itself. I believe the patch is good as well)

By: Octavio Ruiz (tacvbo) 2009-03-21 16:25:23

FYI, I've just applied attached patch; looks to solve the issue using Asterisk 1.6.0.6 + DAHDI-trunk using a Xorcom's Astribank with eight FXO ports and kewl start signalling.

By: Tzafrir Cohen (tzafrir) 2009-03-21 16:50:57

The issue is still present in trunk.

Compare code in trunk to code in 1.4. The code in 1.4 seems pretty much like the code in 1.4.21 and like the code of 1.6.0-beta9. On 1.4 it may only return 0 ("not available") from the code ifdef-ed by DAHDI_CHECK_HOOKSTATE. In 1.6 this is not the case.

This leads me to suspect that this whole code should be put inside #ifdef DAHDI_CHECK_HOOKSTATE, as I see no use for that ioctl.

(hint: in firefox mark the part of the text and use "view selection source" to see it properly indented)

Code in trunk (and 1.6.x branches):
-----------------------------------

                       if (!p->sig || (p->sig == SIG_FXSLS))
                               return 1;
                       /* Check hook state */
                       if (p->subs[SUB_REAL].dfd > -1)
                               res = ioctl(p->subs[SUB_REAL].dfd, DAHDI_GET_PARAMS, &par);
                       else {
                               /* Assume not off hook on CVRS */
                               res = 0;
                               par.rxisoffhook = 0;
                       }
                       if (res) {
                               ast_log(LOG_WARNING, "Unable to check hook state on channel %d: %s\n", p->channel, strerror(errno));
                       } else if ((p->sig == SIG_FXSKS) || (p->sig == SIG_FXSGS)) {
                               /* When "onhook" that means no battery on the line, and thus
                                 it is out of service..., if it's on a TDM card... If it's a channel
                                 bank, there is no telling... */
                               if (par.rxbits > -1)
                                       return 1;
                               if (par.rxisoffhook)
                                       return 1;
                               else
                                       return 0;
                       } else if (par.rxisoffhook) {
                               ast_debug(1, "Channel %d off hook, can't use\n", p->channel);
                               /* Not available when the other end is off hook */
#ifdef DAHDI_CHECK_HOOKSTATE
                               return 0;
#else
                               return 1;
#endif
                       }



code in 1.4:
------------

                       if (!p->sig || (p->sig == SIG_FXSLS))
                               return 1;
                       /* Check hook state */
                       if (p->subs[SUB_REAL].dfd > -1)
                               res = ioctl(p->subs[SUB_REAL].dfd, DAHDI_GET_PARAMS, &par);
                       else {
                               /* Assume not off hook on CVRS */
                               res = 0;
                               par.rxisoffhook = 0;
                       }
                       if (res) {
                               ast_log(LOG_WARNING, "Unable to check hook state on channel %d: %s\n", p->channel, strerror(errno));
                       } else if ((p->sig == SIG_FXSKS) || (p->sig == SIG_FXSGS)) {
                               /* When "onhook" that means no battery on the line, and thus
                                 it is out of service..., if it's on a TDM card... If it's a channel
                                 bank, there is no telling... */
                               if (par.rxbits > -1)
                                       return 1;
                               if (par.rxisoffhook)
                                       return 1;
                               else
#ifdef DAHDI_CHECK_HOOKSTATE
                                       return 0;
#else
                                       return 1;
#endif
                       } else if (par.rxisoffhook) {
                               ast_log(LOG_DEBUG, "Channel %d off hook, can't use\n", p->channel);
                               /* Not available when the other end is off hook */
                               return 0;
                       }

By: Jaco Kroon (jkroon) 2009-04-07 15:43:23

do we really need the ifdef?  Want me to update the patch?

By: Alan McNeil (a9k) 2009-05-15 02:12:07

FYI, I applied this patch and got Sangoma A200 working for inbound calls. Outbound is another problem.
I'd be willing to test an updated patch against the A200.

By: Shaun Ruffell (sruffell) 2009-05-20 15:34:54

As tzafrir indicated in issue ASTERISK-12968, the root cause does appear to be that the DAHDI_CHANCONFIG ioctl sets the rxhooksig back to DAHDI_RXSIG_INITIAL, and I too am unsure what the original purpose for that is and what other side effects may be if removed.

0001-dahdi-base-Do-not-overwrite-the-hookstate-at-channe.patch just removes that line which appears to work fine in the limited testing I've done in the lab with a TDM800P card.

I've also attached 0001-wctdm24xxp-Detect-if-our-hookstate-has-been-set-bac.patch, which is only against the wctdm24xxp driver.  This has the wctdm24xxp driver forget what it thinks the current battery state if it detects that the rxhooksig has been set to DAHDI_RXSIG_INITIAL.  This allows it to re-report to dahdi what the true rxhooksig state is.

While I would like to see the fix go into dahdi-base.c, the change to the wctdm24xxp driver is less risky since it isn't clear to me who depends on the rxhooksig to be in the initial state.

By: Tzafrir Cohen (tzafrir) 2009-07-03 14:15:38

Uploaded the current workaround I use on Asterisk 1.6.2 on Debian

By: Sebastian Gutierrez (sum) 2009-07-20 21:37:22

I have the same issue with 1.6.2 todays SVN version, do you need any info to move this issue forward?

Update: patched apply and works fine.



By: Jaco Kroon (jkroon) 2009-08-08 13:19:15

This has again come up in the IRC channel.  tzafrir also explained to me in irc at the time when I first found the issue that for FXO channels the hookstate really makes no sense, we only really care whether the channel is in alarm or not - which will depend on the battery state.

I also recall trying something down the lines of not setting the state back to initial, which caused major breakage for me (I couln't make calls at all, inbound, outbound, and re-plugging things didn't help either).  Not sure about the battery state variant, haven't tested that.

Is there a specific reason why we can't use the patch to asterisk itself (not to dahdi drivers?)

By: Josef Seger (doda) 2009-08-09 14:38:50

I changed the code in chan_dahdi.c to (Same as in older source 1.2, 1.4 etc...):
---cut      
                        /* When "onhook" that means no battery on the line, and thus
                                 it is out of service..., if it's on a TDM card... If it's a channel
                                 bank, there is no telling... */
                               if (par.rxbits > -1)
                                       return 1;
                               if (par.rxisoffhook)
                                       return 1;
                               else
#ifdef DAHDI_CHECK_HOOKSTATE
                                       return 0;
#else
                                       return 1;
#endif
                       } else if (par.rxisoffhook) {
                               ast_log(LOG_DEBUG, "Channel %d off hook, can't use\n", p->channel);
                               /* Not available when the other end is off hook */
                               return 0;
 
---cut
Running on Asterisk 1.6.1.1 and DAHDI-linux 2.2.0.1

The above solves my issue with not being able to dial out before an incoming call at startup.

By: Digium Subversion (svnbot) 2009-08-13 19:46:52

Repository: dahdi
Revision: 7003

U   linux/trunk/drivers/dahdi/wctdm.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/base.c

------------------------------------------------------------------------
r7003 | sruffell | 2009-08-13 19:46:51 -0500 (Thu, 13 Aug 2009) | 9 lines

wctdm24xxp, wctdm: Detect if our hookstate has been set back to the initial state.

Check if our hookstate has been set back to the initial state, typically the
result of a chanconfig, and if so, if we're an FXO port, forget our current
battery state.  This allows the driver to determine and report again what the
hook state of the port is.

(related to issue ASTERISK-13673)
(closes issue DAHLIN-121)
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=7003

By: Shaun Ruffell (sruffell) 2009-08-13 20:09:39

While the easiest place to fix this is with the Asterisk patches, there is still a bug in the drivers.  I looked into it some today, and the rxhooksig is changed back to initial so that digital boards that call dahdi_rbsbits will have new events queued to the channel after the channel is configured (which could change the type of CAS signalling used on the span).  

Therefore, it appears that the 'proper' fix was to make the analog drivers recognize the DAHDI_RXSIG_INITIAL rxhooksig state as an indication to re-report the current hookstate of it's lines.

By: Tzafrir Cohen (tzafrir) 2009-08-14 06:03:24

For me it's a clear regression from Asterisk 1.6.0 to 1.6.1 and thus should be fixed. Fixing the drivers can be done regardless, but will take longer.

By: Jaco Kroon (jkroon) 2009-08-14 12:11:33

Regression is from 1.4.  I first encountered this problem with asterisk 1.6.0.3, which was the first version of 1.6 I used after upgrading from 1.4.22.

By: Shaun Ruffell (sruffell) 2009-08-14 12:16:48

I vote this issue is kept open until all the analog drivers are updated and a new issue is opened up against chan_dahdi in Asterisk which references this issue.

By: Tzafrir Cohen (tzafrir) 2009-08-19 17:15:10

I still don't understand what is the point of this code in Asterisk.

Why is this test not needed in the case of LS signalling?

Can anybody please explain why this was made a default build option all of a sudden?

By: Tzafrir Cohen (tzafrir) 2009-08-19 17:16:49

Another note: the proposed fix adds an extra test in the interrupt handler. Isn't there a way to avoid that?

By: james.zhu james.zhu (zhulizhong) 2010-02-04 23:40:25.000-0600

hi:
i tested the patch with asterisk-1.6.2.2 and dahdi/wctdm/opvxa1200. it works!

By: frawd (frawd) 2010-02-14 06:39:58.000-0600

Hi,
For some reason when using Sangoma A100 with their latest stable driver (wanpipe 3.4.8 at this time), no alarm is set when no battery is on the line. I don't know if this is a dahdi or wanpipe bug that should be reported to Sangoma.

In order to detect battery status I then still rely on the Offhook-Onhook status, and while tzafrir's patch makes outgoing calls work, the initial state shown by "dahdi show channel X" is still set to Onhook even when there is battery. An incoming call or re-plugging the line makes the hook status correct again.

Patch 0001-dahdi-base-Do-not-overwrite-the-hookstate-at-channe.patch makes it work for me.

By: Tzafrir Cohen (tzafrir) 2010-03-08 12:03:49.000-0600

frawd, that patch alone helps? Does the wanpipe driver set the rxsig after chanconfig?

By: frawd (frawd) 2010-03-08 13:00:00.000-0600

That patch alone helps to have a correct Offhook-Onhook status on FXO ports, but there are still no red alarms when no battery is on the line.

I have no idea what you are talking about in your last question. Tell me how to check if that driver "sets the rxsig after chanconfig" and I'll do it. :-)

The drivers are freely available at the following URL in case it can help (I use the stable 3.4.9 version):
http://wiki.sangoma.com/wanpipe-linux-drivers

By: Leif Madsen (lmadsen) 2010-03-08 13:58:57.000-0600

This is starting to sound like a vendor support issue, and not something in Asterisk.

By: frawd (frawd) 2010-03-08 16:29:54.000-0600

Sorry, it was just meant to report that with those types of cards the patch 0001... resolves this issue. This same patch alone also makes the initial hookstate work for Digium and OpenVox hardware.

And I have no idea why.

By: Tzafrir Cohen (tzafrir) 2010-03-09 04:26:19.000-0600

Looking at the Asterisk side again.

In the case of FXOKS / FXOGS channels, Asterisk currently checks the 'rxbits' field returned from the channel ioctl DAHDI_GET_PARAMS. That field is set to -1 if CAS is not used, and to the rx bits if CAS is used.

But Asterisk goes along and decides that the channel is available if the value of that field > -1 . That is: if this is a CAS channel, the value of rxisoffhook is ignored.

For analog channels we already know that it's pointless as the channel alarm replaces it.

Patch asterisk-162-14577-onlycas.diff includes the suggested fix. For Asterisk 1.6.2  SVN r249844 . (trunk is not usable right now to debug those issues, due to the near-by issue 16983).

By: odicha (odicha) 2010-03-10 02:58:42.000-0600

Tested patch asterisk-162-14577-onlycas.diff over 1.6.2 svn
It works as expected.

By: frawd (frawd) 2010-03-10 09:13:32.000-0600

Looking back on posts, I mistakenly mentioned problems with a Sangoma A100 (PRI) when I meant to speak about their analog card (A200 w FXO ports). The PRI cards of course sets the alarms correctly.

In that case it is not pointless to keep old Offhook/Onhook behaviour for analog channels as those drivers do not set alarms when no battery is on the line.

By: Tzafrir Cohen (tzafrir) 2010-03-10 09:53:19.000-0600

frawd, the bug is that dahdi does not properly set this value. At least not in the non-CAS case. I consider the patch to wctdm and wctdm24xxp an ugly workaround in the channel driver for an ugly behaviour of DAHDI.

By: frawd (frawd) 2010-03-16 08:30:24

I agree that the wctdm and wctdm24xxp patches might have been ugly solutions.

What I was saying is that removing this behavior with the patch 0001-dahdi-base-Do-not-overwrite-the-hookstate-at-channe.patch uploaded by sruffell and explained in Note 0105153 also resolves this particular bug for me without side effects, meaning the initial hookstate is again correct for a card that is not wctdm nor wctdm24xxp (Sangoma). No need for channel driver specific patches.

From what I understand your patch does not correct the hookstate value, but just allows outgoing calls to go through if this state is wrong (which is a valid issue, but a different one).

Now about this other issue, the hookstate value should be checked by the available() function only if DAHDI_CHECK_HOOKSTATE is defined. If not (by default), the hookstate shouldn't even be considered. The ifdef are placed correctly in FXSLS signalling, why not in KS and GS case?
Your patch seem to resolve something I don't understand (what does CAS mean?), but it should still be placed inside an "ifdef DAHDI_CHECK_HOOKSTATE".

Am I crazy? :-)

By: frawd (frawd) 2010-03-19 20:48:37

I think the patch I just uploaded puts the #ifdef back where it should be, and it would resolve the "available()" issue on default compile (when DAHDI_CHECK_HOOKSTATE isn't defined). Even if the initial hookstate is wrong, the outgoing calls can still go through. It should then resolve the effects of this bug but not the bug itself.

Now sruffell's dahdi_base patch makes the initial hookstate correct and allows me to define DAHDI_CHECK_HOOKSTATE. I need it to prevent calls going through analog FXO ports with a driver that doesn't set alarms when no battery is on the line (Sangoma wanpipe). Other than that it's not really needed and this check should be deprecated in favour of alarms.

Would this be the right approach?

By: Tzafrir Cohen (tzafrir) 2010-03-29 03:45:36

frawed: yes. That's actually closer to the original code (before the zap->dahdi conversion). Frankly I have no issue with that one either.

Given that (according to my fix) the patch did not actually help the target population (CAS folks), I vote for keeping this code IFDEF-ed out until it is actually proven useful.

By: frawd (frawd) 2010-03-30 03:47:18

I had forgotten that there are other things that FXO (FXS signalled) ports... The uploaded fix puts back the #ifdef in the right place and clears up the comments. I think it completely resolves the issue.

tzafrir: I make the assumption that for CAS channels (FXO channel banks), the "onhook"/"offhook" does not necessarily mean something about the battery state, so even if DAHDI_CHECK_HOOKSTATE is defined, it returns 1. This hook state would only be taken into account for non-CAS channels. It is the opposite of your patch so your comments on this would be great.

Note: If one wants to define DAHDI_CHECK_HOOKSTATE, he still needs to apply sruffell's dahdi_base patch into dahdi to have a resolve the initial hookstate bug on non-CAS channels (wctdm cards and similar).

By: frawd (frawd) 2010-04-08 15:07:51

tzafrir: I suppose you approve that latest patch including it in the debian asterisk package (which, by the way is an awesome work that we use a lot).

Now to fix the initial hookstate for those that need it, I think the dahdi_base patch is a better alternative than patching all individual drivers.

I can confirm it has been working for me for the past 6 months in multiple implementations with different analog and digital (BRI/PRI) cards (Digium, Openvox, Sangoma, Rhino) without breaking dahdi.

sruffell: Is there any more test or review needed in order to commit this patch in dahdi?

By: Tzafrir Cohen (tzafrir) 2010-05-13 14:08:50

asterisk_chan_dahdi_hookstate_fix_trunk.diff - a patch for trunk (channels/sig_analog.c )

By: frawd (frawd) 2010-05-18 04:49:02

Attached basically the same patch except for:
- Includes ANALOG_SIG_FXSLS to the check (I don't see why it should be left out)
- No need for any type of check if DAHDI_CHECK_HOOKSTATE is defined
- Simplified comments.

By: Tilghman Lesher (tilghman) 2010-06-15 11:47:06

Since there are 9 patches here, could someone please summarize which patches are to be tested and committed and which patches need to be deleted?

By: Tzafrir Cohen (tzafrir) 2010-06-15 12:03:21

asterisk_chan_dahdi_hookstate_fix_trunk_new.diff is the one included in the review (for trunk).

asterisk_chan_dahdi_hookstate_fix.diff is intended for 1.6.2 .

By: Digium Subversion (svnbot) 2010-07-21 12:44:19

Repository: asterisk
Revision: 278501

U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_analog.c

------------------------------------------------------------------------
r278501 | tzafrir | 2010-07-21 12:44:19 -0500 (Wed, 21 Jul 2010) | 19 lines

Fix invalid test for rxisoffhook in FXO channels

This fixes some cases of no outgoing calls on FXO before an incoming call.

Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.

If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .

(closes issue ASTERISK-13673)
Reported by: jkroon
Patches:
     asterisk_chan_dahdi_hookstate_fix_trunk_new.diff uploaded by frawd (license 610)
Tested by: frawd

Review: https://reviewboard.asterisk.org/r/699/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=278501

By: Digium Subversion (svnbot) 2010-07-21 13:22:24

Repository: asterisk
Revision: 278524

U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r278524 | tzafrir | 2010-07-21 13:22:24 -0500 (Wed, 21 Jul 2010) | 21 lines

Fix invalid test for rxisoffhook in FXO channels

This fixes some cases of no outgoing calls on FXO before an incoming call.

Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.

If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .

(closes issue ASTERISK-13673)
Reported by: jkroon
Patches:
      asterisk_chan_dahdi_hookstate_fix.diff uploaded by frawd (license 610)
Tested by: frawd

Review: https://reviewboard.asterisk.org/r/699/



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=278524