[Home]

Summary:ASTERISK-13082: [patch] fxo modules incorrectly believes channel is answered, if telco reverses line polarity at off hook.
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2008-11-18 01:22:12.000-0600Date Closed:2009-06-26 14:42:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_dahdi.bug13917.feb09.diff2.txt
Description:With answeronpolarityswitch=yes in chan_dahdi.conf
In our setup channels 63-65 in attached chan_dahdi.conf

When fxo modules are connected to analog lines that reverse polarity when the line is picked up, the fxo driver (wcdtm) sends a polarity reversal event, causing the channel to be answered, which is incorrect, as the call is yet to be dialled.

The caller hears a very short ring, then silence for a while as the call is set up, then finally remote ringing. This is very off putting for the unaware user.

The attached patch chan_dahdi.diff.txt patch, sets the polaritydelaytv at call setup, then uses the same sytle of checking mechnism as is used for hanguponpolarityswitch=yes.

The DAHDI_EVENT_POLARITY in dahdi_handle_event has been reworked, from using IF/ELSE statements with multiple OR's to easier to read SWITCH statements.

Has been on a production box for nearly a month with around 100 calls out of the fxo channels a day, with clean sounding ringing, with audio passed as soon as the called party answers.




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

Setup:
2 channel E1 card, channels 1-62.
1 TDM400P with 4x FXO modules, channels 63-66.

With answeronpolarityswitch=yes in chan_dahdi.conf
File: chan_dahdi.conf attached

dialplan code snippet:

exten => s,1,ChanIsAvail(${ARG1})
exten => s,2,Goto(5) ; give some room for error handling after 102
; cut away session id: "-<ID>". separator defaults to '-':
exten => s,5,Set(AVAILCHAN_NOSESSION=${CUT(AVAILCHAN,-,1)})
exten => s,n,Dial(${AVAILCHAN_NOSESSION}/${ARG2}#,,r)

related http://bugs.digium.com/view.php?id=13716 but was a work in progress, with a bad choice of wording for the Summary/Subject. Severity became major when hanguponpolarityswitch was enabled, as calls were terminated as soon as they were answered.

Alec



Comments:By: Alec Davis (alecdavis) 2008-11-26 13:44:38.000-0600

I see I've got a karma point for this bug :))

Did a bug marshal award this, with the intention of committing the bug, and got distracted?

Or was it because someone has used this patch and found it to work but not yet reported back as 'tested and works'.

Alec
By: Alec Davis (alecdavis) 2008-12-10 04:15:59.000-0600

Please delete chan_dahdi.diff.txt

uploaded chan_dahdi.bug13917.diff.txt
By: Leif Madsen (lmadsen) 2008-12-10 11:56:27.000-0600

I awarded karma because you uploaded a patch which appears to have worked for you, but no, there has been no further movement on this bug :)  I've decided that when going through bugs sometimes I'll give karma, regardless whether the patch has been evaluated or not (because obviously you put some time into it :))
By: Alec Davis (alecdavis) 2008-12-13 17:47:28.000-0600

related??: http://bugs.digium.com/bug_view_page.php?bug_id=2847

4 Years ago, others were having the same problem, When going off hook, the line reverses. During that bug report answeronpolarityswitch and hanguponpolarityswitch were born, but it appears as though it's become broken over time.

Quoting marty 'The line also does a Polarity Reversal as the line goes off hook, so this code stores the time of the off hook event and when the polarity reversal event triggers, the timestamps are compared. If the duration is greater than the (configurable) allowed period, the signal is assumed to be a remote end disconnect and the channel is then hungup'

Seems as though his intial intensions, are similar to mine.
That is
1). take a snapshot of the time at call start
2). if a reversal happens before timeout, then ignore, else it's remote answer
3). take another snapshot of the time for remote disconnect timing
4). if a reversal happens before timeout, then ignore, else it's remote disconnect

Step 1 and 2 are relevant if answeronpolarityswitch=yes
Step 1 to 4 are relevant if (answeronpolarityswitch=yes and hanguponpolarityswitch=yes)
By: Alec Davis (alecdavis) 2009-02-09 17:20:26.000-0600

please remove chan_dahdi.bug13917.diff.txt
please remove chan_dahdi.bug13917.feb09.diff.txt

uploaded chan_dahdi.bug13917.feb09.diff2.txt remove extra console output noise.

Updated to trunk r174327M today, as the old patch chan_dahdi.bug13917.diff.txt
doesn't apply cleanly.


By: Leif Madsen (lmadsen) 2009-02-10 07:39:43.000-0600

Files removed per reporters request.
By: Digium Subversion (svnbot) 2009-06-26 14:03:26

Repository: asterisk
Revision: 203672

U   trunk/channels/sig_analog.c

------------------------------------------------------------------------
r203672 | jpeeler | 2009-06-26 14:03:25 -0500 (Fri, 26 Jun 2009) | 16 lines

Check if polarityonanswerdelay has elapsed before setting a channel as answered
after a polarity reversal.

Previously on a polarity switch event chan_dahdi would set the channel
immediately as answered. This would cause problems if a polarity reversal
occurred when the line was picked up as the dial would not have yet occurred.
Now if the polarity reversal occurs before delay has elapsed after coming off
hook or an answer, it is ignored. Also, some refactoring was done in
_handle_event.

(closes issue ASTERISK-13082)
Reported by: alecdavis
Patches:
     chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

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

http://svn.digium.com/view/asterisk?view=rev&revision=203672
By: Digium Subversion (svnbot) 2009-06-26 14:25:52

Repository: asterisk
Revision: 203698

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r203698 | jpeeler | 2009-06-26 14:25:52 -0500 (Fri, 26 Jun 2009) | 23 lines

Merged revisions 203672 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r203672 | jpeeler | 2009-06-26 14:03:25 -0500 (Fri, 26 Jun 2009) | 16 lines
 
 Check if polarityonanswerdelay has elapsed before setting a channel as answered
 after a polarity reversal.
 
 Previously on a polarity switch event chan_dahdi would set the channel
 immediately as answered. This would cause problems if a polarity reversal
 occurred when the line was picked up as the dial would not have yet occurred.
 Now if the polarity reversal occurs before delay has elapsed after coming off
 hook or an answer, it is ignored. Also, some refactoring was done in
 _handle_event.
 
 (closes issue ASTERISK-13082)
 Reported by: alecdavis
 Patches:
       chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
 Tested by: alecdavis
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=203698
By: Digium Subversion (svnbot) 2009-06-26 14:28:25

Repository: asterisk
Revision: 203700

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_dahdi.c

------------------------------------------------------------------------
r203700 | jpeeler | 2009-06-26 14:28:24 -0500 (Fri, 26 Jun 2009) | 23 lines

Merged revisions 203672 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r203672 | jpeeler | 2009-06-26 14:03:25 -0500 (Fri, 26 Jun 2009) | 16 lines
 
 Check if polarityonanswerdelay has elapsed before setting a channel as answered
 after a polarity reversal.
 
 Previously on a polarity switch event chan_dahdi would set the channel
 immediately as answered. This would cause problems if a polarity reversal
 occurred when the line was picked up as the dial would not have yet occurred.
 Now if the polarity reversal occurs before delay has elapsed after coming off
 hook or an answer, it is ignored. Also, some refactoring was done in
 _handle_event.
 
 (closes issue ASTERISK-13082)
 Reported by: alecdavis
 Patches:
       chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
 Tested by: alecdavis
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=203700
By: Digium Subversion (svnbot) 2009-06-26 14:42:52

Repository: asterisk
Revision: 203709

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r203709 | jpeeler | 2009-06-26 14:42:52 -0500 (Fri, 26 Jun 2009) | 23 lines

Merged revisions 203672 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r203672 | jpeeler | 2009-06-26 14:03:25 -0500 (Fri, 26 Jun 2009) | 16 lines
 
 Check if polarityonanswerdelay has elapsed before setting a channel as answered
 after a polarity reversal.
 
 Previously on a polarity switch event chan_dahdi would set the channel
 immediately as answered. This would cause problems if a polarity reversal
 occurred when the line was picked up as the dial would not have yet occurred.
 Now if the polarity reversal occurs before delay has elapsed after coming off
 hook or an answer, it is ignored. Also, some refactoring was done in
 _handle_event.
 
 (closes issue ASTERISK-13082)
 Reported by: alecdavis
 Patches:
       chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
 Tested by: alecdavis
........

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

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