[Asterisk-bugs] [Asterisk 0008066]: [patch] hanguponpolarityswitch hangs up on incoming call during ring phase
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Jul 9 19:51:36 CDT 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=8066
======================================================================
Reported By: jared
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 8066
Category: Channels/chan_zap
Reproducibility: always
Severity: major
Priority: normal
Status: ready for testing
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 44144
Disclaimer on File?: Yes
Request Review:
======================================================================
Date Submitted: 10-02-2006 02:17 CDT
Last Modified: 07-09-2007 19:51 CDT
======================================================================
Summary: [patch] hanguponpolarityswitch hangs up on incoming
call during ring phase
Description:
I am in Australia and use Telstra as my provider. During the ringing phase
of the call I see reversal of polarities, which asterisk interprets
incorrectly. It assumes that the polarity reversal during the ring phase
means that the caller has hung up. This is definitely not the case.
(Telstra may be sending the polarity reversal for good reason during the
ring phase, i just don't know what that reason might be though).
Below in (Appendix 1: Zaptel Driver Log) the zaptel driver debug output
showing the polarity reversals as they come from the Telstra exchange. In
the example, I ring from an outside phone into the the zaptel line and just
let it ring... no one inside answers.
When asterisk finds the polarity reversal during this ring phase it does a
ast_softhangup(p->owner, AST_SOFTHANGUP_EXPLICIT) of the incoming channel
see (Appendix 2: chan_zap.c source code fragment). I think the purpose of
this is so that it will stop ringing extensions that may have started
ringing immediately, so that the users wont pick a call which has actually
stopped ringing but asterisk hasn't detected that fact yet.
I suspect that other users of the reverseonpolarityswitch feature don't
have exchanges that generate these polarity events during the ring phase.
I have made a patch which I have attached that works for my purposes, but
I'm not sure how to go about making it work in a more general sense with
what I think the existing code is trying to achieve.
I would like to ask how people think this could be improved so that it
could be included in the svn trunk without breaking the existing features.
I have 2 ideas:
1) Add a new config option in zapata.conf.
nohanguponpolarityswitchinringphase=yes
2) Some how find an alogithm that detects real hangups during ringing
phase rather than just these random reversal pulses.
Any ideas welcome.
Thanks
======================================================================
----------------------------------------------------------------------
jared - 07-09-07 19:51
----------------------------------------------------------------------
I posted my experience to:
http://www.voip-info.org/wiki/view/Australia+Asterisk+Details
A wiki page editor has included my comments in the main section of the
page confirming that many people have been having difficulty.
I have noticed today there is a "SoloFlyer's Patch" on that wiki page. The
solution sounds hopefull. I will try it myself and let you know of its
success. The author claims it works without any side effects.
Although I do not recommend chan_zap_reverse_polarity_on_ring.patch, as it
has associated problems.
I would however recommend inclusion of
"wctdm_reverse_debug_log_polarity_reverse.patch" (this will help future
debuggers) as it simply adds which channel is receiving the polarity
reversal to the debug log.
Issue History
Date Modified Username Field Change
======================================================================
07-09-07 19:51 jared Note Added: 0066845
======================================================================
More information about the Asterisk-bugs
mailing list