[Home]

Summary:ASTERISK-12913: [patch] Prevent false answer of channel when going off-hook
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2008-10-16 04:58:26Date Closed:2011-06-07 14:08:09
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_dahdi.bug13716.diff3.txt
( 1) wctdm.bug13716.diff.txt
Description:With answeronpolarityswitch=no asterisk answers channel soon after dialout has started, or perhaps just finished. Causing Ringing for the caller to stop, then silence for a while as the call is setup, then telco ringing is heard and call proceedes as normal.

With answeronpolarityswitch=yes asterisk answers channel as soon as the line goes off-hook. The user hears a very short Ring from Asterisk, long silence as digits are dialled out and call is setup, then finally telco ring is heard.
This is caused in our case because the line does a polarity reversal when going off hook.

I have modifed wctdm.c that adds polarityignore in 3 sections of the code, strcut fxo, wctdm_voicedaa_check_hook and wctdm_hooksig.

I'll upload for your comment, but welcome any advice if there is a better way.

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

TDM400P fxo ports connected to Ericsson F250m, with FCT set to reverse polarity when called party answers.
The F250m will also reverses polarity when you go Off-Hook and then when you go On-Hook, and I cannot turn that off.

chan_dahdi.conf has answeronpolarityswitch=yes for the F250m connected channels.

debug enabled in wctdm: events from /var/log/debug
Oct 16 22:17:31 astrid kernel: [3841192.791833] Setting FXO hook state 2 to (09), PolIgnore to (1)
Oct 16 22:17:31 astrid kernel: [3841192.960332] 738779686 Polarity Reversed (-1 -> 1)
Oct 16 22:17:31 astrid kernel: [3841192.960332] But ignored
Oct 16 22:17:31 astrid kernel: [3841193.233037] Setting FXO hook state 1 to (09), PolIgnore to (0)
Oct 16 22:17:42 astrid kernel: [3841208.904764] 738782530 Polarity Reversed (1 -> -1)
Oct 16 22:17:52 astrid kernel: [3841222.734810] Setting FXO hook state 0 to (08), PolIgnore to (0)
Oct 16 22:17:52 astrid kernel: [3841222.734810] check hook; HOOK On, chan 2
Oct 16 22:17:53 astrid kernel: [3841224.287608] 738785210 Polarity Reversed (-1 -> 1)
Oct 16 22:17:54 astrid kernel: [3841225.713786] 738785470 Polarity Reversed (1 -> -1)
Oct 16 22:17:56 astrid kernel: [3841228.723299] 738786010 Polarity Reversed (-1 -> 1)
Oct 16 22:17:57 astrid kernel: [3841230.185637] 738786274 Polarity Reversed (1 -> -1)
Comments:By: Alec Davis (alecdavis) 2008-10-16 05:13:09

Commented version of debug log. should have done this orignally.
If the polarity reversal (2nd event) wasn't ingored (3rd event), asterisk would have ansered the call.

debug enabled in wctdm: events from /var/log/debug
<================ Start Call =======================================>
Oct 16 22:17:31 astrid kernel: [3841192.791833] Setting FXO hook state 2 to (09), PolIgnore to (1)
<================ Problem OFF HOOK line Reversal ===================>
Oct 16 22:17:31 astrid kernel: [3841192.960332] 738779686 Polarity Reversed (-1 -> 1)
Oct 16 22:17:31 astrid kernel: [3841192.960332] But ignored
Oct 16 22:17:31 astrid kernel: [3841193.233037] Setting FXO hook state 1 to (09), PolIgnore to (0)
<================ Called Party Answers ==============================>
Oct 16 22:17:42 astrid kernel: [3841208.904764] 738782530 Polarity Reversed (1 -> -1)
<================ Called Party Ends Call ============================>
Oct 16 22:17:52 astrid kernel: [3841222.734810] Setting FXO hook state 0 to (08), PolIgnore to (0)
Oct 16 22:17:52 astrid kernel: [3841222.734810] check hook; HOOK On, chan 2
<=============== 4 Line revesals to ensure hangup =================>
Oct 16 22:17:53 astrid kernel: [3841224.287608] 738785210 Polarity Reversed (-1 -> 1)
Oct 16 22:17:54 astrid kernel: [3841225.713786] 738785470 Polarity Reversed (1 -> -1)
Oct 16 22:17:56 astrid kernel: [3841228.723299] 738786010 Polarity Reversed (-1 -> 1)
Oct 16 22:17:57 astrid kernel: [3841230.185637] 738786274 Polarity Reversed (1 -> -1)


By: Alec Davis (alecdavis) 2008-10-16 05:23:04

Related F250m configuration options.
(on=1 beep, off= 3beeps)
Set Polarity Reversal (should return 1 beep)
** 0016 *0#      (On Hook)              off
** 0016 *1#      (during ringing)       off
** 0016 *2#      (during dialing)       off
** 0016 *3#      (conversation A party)  on
** 0016 *4#      (conversation B party) off
** 0016 *5#      (release A party)      off
** 0016 *6#      (release B party)      off

Reset polarity reversal (should return 3 beeps)
# 0016 *n#       where n is 0-6 from above

Check polarity reversal (return 1 for ON or 3 beeps for OFF)
*# 0016 *n#      where n is 0-6 from above


By: Alec Davis (alecdavis) 2008-10-17 05:34:31

A feature similar to polarityonanswerdelay, maybe a new parameter polarityoffhookdelay could perhaps be implemented at the chan_dahdi level, instead of the wctdm driver. Then I believe all FXO cards would inherit the feature.

The attached concept test code work flawlessly today for around 60 calls to our 'on account' mobile phones.

Another bonus today's CDR billing shows each call's 'duration' and 'billsec' as exactly the same. Previously each call's 'duration' was around 5-6 more than 'billsec'


By: Alec Davis (alecdavis) 2008-10-22 04:01:55

Please remove code for comment wctdm.c, as this was done at a too lower level, but worked well.

uploaded patch chan_dahdi.bug13716.diff.txt

This implements polarityonanswerdelay if answeronpolarityswitch=yes to prevent false answering due to line reversal on seizure, and is already used for hanguponpolarityswitch=yes to prevent prevent false hangups just after answering.

Looking at the variable's name 'polarityonanswerdelay', seems as though it was originally it's intended purpose, and the code that was already there should have been something else, perhaps polarityhangupdelay or polarity_answer_to_hangup_delay.

By using the same delay this avoided another confusing parameter being used in chan_dahdi.conf.

Alec


By: Tzafrir Cohen (tzafrir) 2008-10-22 21:25:58

What exactly are your modifications to wctdm.c ? Could you please attach them as a patch? What was the base version?
By: Alec Davis (alecdavis) 2008-10-23 02:26:45

Modifying wctdm.c was going to only fix our problem on a TDM400P card, a better fix was at a higher level, hence the chan_dahdi patch, that way all FXO cards would inherit the fix.

I will upload the wctdm patch, but would rather see the chan_dahdi patch applied.

chan_dahdi patch worked perfectly today.


By: Alec Davis (alecdavis) 2008-10-23 02:56:12

To answer the question regarding wctdm base version dahdi 2.0.0-rc4

Uploaded patch wctdm.bug13716.diff.txt which only fixes TDM400P.
By: Tzafrir Cohen (tzafrir) 2008-10-23 03:40:10

I took a look at your chan_dahdi patch again. At first I thought you completely changed the polarity handling logic. Then I realized that the indentation was misleading and caused the patch to look larger than it is. Attached chan_dahdi_polarity.diff which is your patch slightly reformatted.

A patch should describe your change so have a look at it before you submit it. Remove unnecessary changes, as they make your patch look larger (read: scarier) than it is. As a last resort, use the option -w of diff to hide stupid white-space changes. -p is also handy to tell in which function exactly your changes are.
By: Alec Davis (alecdavis) 2008-10-23 04:31:27

Thanks tzafrir, sorry about the indent change.

Removed unwanted console debug messages.
uploaded chan_dahdi.bug13716.diff2.txt
By: Alec Davis (alecdavis) 2008-10-23 04:33:57

please remove the following

wctdm.c
chan_dahdi.bug13716.diff.txt
chan_dahdi_polarity.diff
By: Alec Davis (alecdavis) 2008-10-30 05:32:37

Uploaded chan_dahdi.bug13716.diff3.txt
Please remove chan_dahdi.bug13716.diff2.txt

FXO module handling of DAHDI_EVENT_POLARITY using answeronpolarityswitch and hanguponpolarityswitch have changed order of evaluation. Simplified using SWITCH statements instead of IF/ELSE ...

order of evaluation is now reversed
 1st evaluates time (polarityonanswerdelay) from Offhook or Answer event
 2nd based on current state (DIALING | RINGING) or ( UP | RING) will check the respective answeronpolarityswitch or hanguponpolarityswitch to Answer or Hangup the channel

Tested with line that was configurable to enable;
Polarity Switch only on remote connect.
Polarity Switch only on remote disconnect.
Polarity Switch both remote connect and disconnect.
No Polarity Switch for remote connect or disconnect.

Tested with chan_dahdi.conf
 answeronpolarityswitch = yes and no.
 hanguponpolarityswitch = yes and no.

Alec
By: Alec Davis (alecdavis) 2008-10-31 15:51:41

This patch 'chan_dahdi.bug13716.diff3.txt' is now ready for testing.

Others that are using FXO cards on lines that have line reversal and are using answeronpolarityswitch=yes or hanguponpolarityswitch=yes switches in chan_dahdi.conf please test and report in.

Alec


By: Alec Davis (alecdavis) 2008-11-13 03:51:29.000-0600

Please remove chan_dahdi.bug13716.diff2.txt

Tested OK using new installation, using different line equipment, Jtec ALEM2 card setup to reverse line polarity on answer.

asterisk SVN-trunk-r155671
chan_dahdi.c release verison 155324

DAHDI Version: SVN-trunk-r5270M

dialplan code:
exten => _4866,1,Dial(DAHDI/35/4866#,,r)

console output:
  -- Executing [4866@trusted:1] Macro("SIP/8620-08451a68", "dialout,DAHDI/R4,4866") in new stack
   -- Executing [s@macro-dialout:1] ChanIsAvail("SIP/8620-08451a68", "DAHDI/R4") in new stack
   -- Hungup 'DAHDI/35-1'
   -- Executing [s@macro-dialout:2] Goto("SIP/8620-08451a68", "5") in new stack
   -- Goto (macro-dialout,s,5)
   -- Executing [s@macro-dialout:5] Set("SIP/8620-08451a68", "AVAILCHAN_NOSESSION=DAHDI/35") in new stack
   -- Executing [s@macro-dialout:6] Dial("SIP/8620-08451a68", "DAHDI/35/4866#,,r") in new stack
[Nov 13 22:55:29] NOTICE[9881]: chan_dahdi.c:2301 dahdi_call: Ignore possible polarity reversal on line seizure
   -- Called 35/4866#
<<< delay until remote end answers call >>>
   -- DAHDI/35-1 answered SIP/8620-08451a68

Hopefully this is enough to get committed.

Alec Davis


By: Leif Madsen (lmadsen) 2009-01-20 13:25:35.000-0600

Assigned this to sruffell for his review. Please reassign this as necessary. Thanks!
By: Alec Davis (alecdavis) 2009-02-09 18:29:59.000-0600

please close this bug report as http://bugs.digium.com/view.php?id=13917 is more up to date.
By: Leif Madsen (lmadsen) 2009-02-10 07:49:11.000-0600

Closed at the request of the reporter. See issue 13917 for a more up to date version.