[asterisk-dev] [Code Review] Modify bridging to properly evaluate DTMF after first warning is played

[Kaloyan Kovachev]

On Tue, 17 Feb 2009 14:46:36 -0600 (CST), Jeff Peeler wrote
<skipped>
> 
> I wouldn't say this is exactly off topic, but here I was trying to minimize
changes to the core.  More confusing (to me, but related) than the dual role
of nexteventts is that the start_time for the bridge is set to the start of
the feature and then later reset to the true bridge start_time from the
backup_config.

by changing the config structure (in channel.h) it already makes too much
changes, so maybe dedicated variables (and the other changes below) will not
add much to that.

other changes:
 removing of the last variable of ast_generic_bridge - will not harm anything
and is used only in channel.c
 adding feature_start and feature_first_pass variables in config too - will
only change channel.c and features.c, but will also make the entire backup
config in features.c unnecessary ... removing it will need more changes though:
	config->play_warning = 0;
	ast_clear_flag(&(config->features_caller), AST_FEATURE_PLAY_WARNING);
	ast_clear_flag(&(config->features_callee), AST_FEATURE_PLAY_WARNING);
	config->warning_freq = 0;
	config->warning_sound = NULL;
	config->end_sound = NULL;
	config->start_sound = NULL;
	config->firstpass = 0;
   can be safely removed if in channel.c caller_warning and callee_warning
(lines 4081 & 4082) are moved inside the "} else if (config->timelimit) {"
block, because in case of feature the "if (config->feature_timer) {" block
will match and no warnings will be played.

   more problematic is the feature_timer itself as there is some simultaneous
use of it from the backup config, so maybe another config variable
old_feature_timer will be needed (not sure what exactly happens here and is it
possible to use a local variable)


> I also thought about playing the warnings not in the bridge. Changes such as
these are more appropriate for trunk though.
> 
> I assume you've been keeping up with the new review here:
> http://reviewboard.digium.com/r/93/
> 

yes, waiting for it to be committed, but it still lacks the interval hooks and
the most demanding part for the 'out of bridge warnings' is the 'wishper file'
or similar from the audiohooks