[asterisk-bugs] [Asterisk 0014315]: After Dial's L() limit is reached, res_feature's dynamic features don't work
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Mar 2 18:03:37 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14315
======================================================================
Reported By: tim_ringenbach
Assigned To: jpeeler
======================================================================
Project: Asterisk
Issue ID: 14315
Category: Core/Channels
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: 1.4.23
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-01-22 15:20 CST
Last Modified: 2009-03-02 18:03 CST
======================================================================
Summary: After Dial's L() limit is reached, res_feature's
dynamic features don't work
Description:
There's a problem with channel.c's ast_channel_bridge and how the limit
functionality is implemented.
We have a dynamic feature from res_features set to happen when the user
hits star. (It calls an AGI and does an IVR to let a user add money to
their account.)
We use the L option to add dial to limit the call and play a warning when
the limit is low.
After the limit is reached, however, hitting star repeats the warning
instead of actually activating the feature. This is a problem of us
because the warning message says to hit star, but now hitting star replays
the message.
The reason for this is that hitting the key sends you back into the for
(/*ever/*) loop in channels.c, and the if statement on line 4160 is still
true, so it plays the warning again instead of processing the dtmf.
Since we weren't doing replays on the warning, we patched asterisk to set
config->play_warning to 0 in the else block of the "if
(config->warning_freq && (time_left_ms > (config->warning_freq + 5000)))"
line. However, that's not a generic solution.
======================================================================
----------------------------------------------------------------------
(0101054) svnbot (reporter) - 2009-03-02 18:03
http://bugs.digium.com/view.php?id=14315#c101054
----------------------------------------------------------------------
Repository: asterisk
Revision: 179538
_U branches/1.6.0/
U branches/1.6.0/main/channel.c
------------------------------------------------------------------------
r179538 | jpeeler | 2009-03-02 18:03:37 -0600 (Mon, 02 Mar 2009) | 28
lines
Merged revisions 179537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r179537 | jpeeler | 2009-03-02 18:01:51 -0600 (Mon, 02 Mar 2009) | 21
lines
Merged revisions 179536 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179536 | jpeeler | 2009-03-02 17:54:39 -0600 (Mon, 02 Mar 2009) | 15
lines
Fix bridging regression from commit 176701
This fixes a bad regression where the bridge would exit after an
attended
transfer was made. The problem was due to nexteventts getting set
after the
masquerade which caused the bridge to return AST_BRIDGE_COMPLETE.
The problem is not completely solved however. A bridge configured with
a warning
still does not operate correctly. It actually operates the same as
before except
the DTMF is properly recognized after the first warning. I just wanted
to get
this fix in as quickly as possible.
(issue http://bugs.digium.com/view.php?id=14315)
Reported by: tim_ringenbach
........
................
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=179538
Issue History
Date Modified Username Field Change
======================================================================
2009-03-02 18:03 svnbot Checkin
2009-03-02 18:03 svnbot Note Added: 0101054
======================================================================
More information about the asterisk-bugs
mailing list