[asterisk-bugs] [Asterisk 0014315]: After Dial's L() limit is reached, res_feature's dynamic features don't work

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
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:                     resolved
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-01-22 15:20 CST
Last Modified:              2009-02-17 15:54 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0100282) svnbot (reporter) - 2009-02-17 15:54
 http://bugs.digium.com/view.php?id=14315#c100282 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 176701

U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/main/channel.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17
lines

Modify bridging to properly evaluate DTMF after first warning is played

The main problem is currently if the Dial flag L is used with a warning
sound,
DTMF is not evaluated after the first warning sound. To fix this, a flag
has 
been added in ast_generic_bridge for playing the warning which ensures
that if
a scheduled warning is missed, multiple warrnings are not played back (due
to a
feature evaluation or waiting for digits). ast_channel_bridge was modified
to
store the nexteventts in the ast_bridge_config structure as that
information
was lost every time ast_channel_bridge was reentered, causing a hangup due
to
incorrect time calculations.

Closes issue http://bugs.digium.com/view.php?id=14315

Reviewed on reviewboard:
http://reviewboard.digium.com/r/163/


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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-17 15:54 svnbot         Note Added: 0100282                          
2009-02-17 15:54 svnbot         Status                   assigned => resolved
2009-02-17 15:54 svnbot         Resolution               open => fixed       
======================================================================