[asterisk-bugs] [DAHDI-linux 0015018]: Hangups are ignored if the channel has not been answered

Asterisk Bug Tracker noreply at bugs.digium.com
Mon May 25 12:10:25 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15018 
====================================================================== 
Reported By:                cabal95
Assigned To:                
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   15018
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2009-05-02 13:32 CDT
Last Modified:              2009-05-25 12:10 CDT
====================================================================== 
Summary:                    Hangups are ignored if the channel has not been
answered
Description: 
When a call comes in, if it has not been Answer()'d yet by Asterisk and the
call is hung up (i.e., I changed my mind, or I called wrong number, etc.),
Dahdi does not pass the hookswitch state to Asterisk to signal a hangup. 
In my dialplan I have a Wait(2) before I Answer() the call.  If the calling
party hangs up during this Wait(2) call before Answer() then the hangup is
never detected and eventually goes to voicemail as a re-order tone.

At or near line 6321 is this bit of code:
           case DAHDI_SIG_FXSKS:  /* FXS Kewlstart */
                  /* ignore a bit error if loop not closed and stable */
                if (chan->txstate != DAHDI_TXSTATE_OFFHOOK) break;

Is there any reason for this?  I commented this out and everything seems
to be fine and it actually detects those early hangups now.  It would seem
like this was put in to fix one bug and caused another.
====================================================================== 

---------------------------------------------------------------------- 
 (0105371) cabal95 (reporter) - 2009-05-25 12:10
 https://issues.asterisk.org/view.php?id=15018#c105371 
---------------------------------------------------------------------- 
Sorry, re-reading my original description I can see it is a little vague.

Asterisk: 1.4.20.1
Zaptel: 1.4.10-1
Device: TE212P (I believe, can't remember the exact model off the top of
my head, run by the wct4xxp module)
Country: US
Provider: Verizon T1 circuit (24 voice channels)
Detection: The RxA bit toggles, signaling a hang up (same as if the call
was fully "connected")

Sequence one (fully connected call, this works):
1 - Dial my Asterisk box.
2 - Asterisk detects rings, RxB bit toggles from 1 to 0 and back (one
toggle for each ring).
3 - Asterisk Answers via a call to Answer(), TxA bit switches to 1 to
signal off-hook.
4 - I hang up, RxA bit toggles from 0 to 1 and back, TxA bit switches from
1 to 0.

Sequence two (hang up before answer, this does not work):
1 - Dial my Asterisk box.
2 - Asterisk detects rings, RxB bit toggles from 1 to 0 and back (one
toggle for each ring).
3 - I hang up, RxA bit toggles from 0 to 1 and back. Zaptel/DAHDI sees
this as invalid and ignores the bit due to the code I mentioned above.
4 - Asterisk answers via a call to Answer(). TxA bit switches to 1 to
signal off-hook.
5 - The call eventually falls through the menu into our receptionist line,
who answers the phone and hears the re-order tone and hangs up; which
switches the TxA bit from 1 to 0 and releases the line.

I have Asterisk and Dahdi setup on a test machine, but unfortunately
cannot test against our provider as we have only the one T1 line.  We plan
an upgrade in the near future, but I cannot say how near that is. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-25 12:10 cabal95        Note Added: 0105371                          
======================================================================




More information about the asterisk-bugs mailing list