|Summary:||ASTERISK-04638: [patch] add a feature_timer member to bridge_config|
|Reporter:||Anthony Minessale (anthm)||Labels:|
|Date Opened:||2005-07-20 12:09:05||Date Closed:||2008-01-15 15:43:31.000-0600|
|Environment:||Attachments:||( 0) feature_timer_rev2.diff|
( 1) feature_timerB.diff
( 2) timelimitdebug.diff
|Description:||Currently the feature engine hijacks the timer from the call limit feature thus cancelling any timed calls. This patch adds a timer (a long int) specifically for features so they can co-exist properly.|
****** ADDITIONAL INFORMATION ******
Disclaimer on File
|Comments:||By: Kevin P. Fleming (kpfleming) 2005-07-25 18:24:37|
I've looked over this code quite a bit, and I don't see how it's failing in the way that you say that it is.
When a DTMF key that could potentially invoke a feature is detected, the entire bridge_config is copied into backup_config and then that one is used for time limiting until either it runs out or the feature key timer runs out. While it's not the most obvious or logical way to do it, it shouldn't be failing either.
If you want to simplify the whole function by adding the feature_timer element and eliminating _all_ the backup_config cruft I think that would make more sense than this patch as it stands.
By: Brian West (bkw918) 2005-07-25 21:04:22
Guess you missed the part where another feature hijacks "config->timelimit" and uses it for something else while at the same time you try to use it for the L option in dial.
By: Anthony Minessale (anthm) 2005-07-26 09:52:51
Bottom line is:
When I implemented the L() feature and the whole bridge_config object the timelimit field was intended for use by the call limit code in app_dial.
The feature codes came along later and just took over that int, even copying it does not help since there are like 10 places that reset the timelimit. IT makes perfect sense to me that the featrure codes have it's own timer seperate from that of the call limit. This is a bug that was reported to me directly because I made the L() feature so I had to fix it when I didn't break it.
I am trying my best to be sincere when I say this is the stuff that causes me to lose interest in helping to fix asterisk. I will not suffer if this patch is rejected but the people who have a calling card based in L() might, since when you dial any digit during a timed call, your timer turns off for good giving the caller infinite time for the call.
If you would like to see for yourself apply timelimitdebug.diff and make a call
you will see the timer display on the console
now dial a digit an watch the timer stop forever.
By: Dmytro Mishchenko (arkadia) 2005-07-27 02:41:00
Something similar supposed to be fixed a year ago.
By: Tusar Ahmed (tusar) 2005-07-27 11:31:29
It is not happening always ... But happening .
For logs.. http://bugs.digium.com/view.php?id=4609
Note : At stable-v.1.0.9 , it is working fine .
By: Anthony Minessale (anthm) 2005-07-27 13:53:49
Aparently a whitespace formatting bug took precedence. Allow me to retool.
By: Mark Spencer (markster) 2005-07-28 14:46:24
Does not compile
By: Anthony Minessale (anthm) 2005-07-28 15:30:31
that sucks! so 2 days in a row some other patch killed mine that was here a week already.
By: Anthony Minessale (anthm) 2005-07-28 15:35:14
here it is again for the 3rd time.
By: clive18 (clive18) 2005-07-29 04:55:36
I am not sure if you guys also experience this, but when dtmf is pressed my call timer seems to reset itself to its orginal value. Maybe I did something wrong in the paching, please double check this behaviour.
Still miles better than no timer which is what hapenned before.
Thanks and regards
By: Brian West (bkw918) 2005-07-29 08:36:33
if you didn't apply this patch pressing a DTMF key will kill the timer. With this patch that shouldn't happen.
By: Anthony Minessale (anthm) 2005-07-29 09:25:15
clive, apply timelimitdebug.diff and you can see the state of the timer on the cli during the call. This will tell you if dtmf is affecting the call or not with and without the patch.
By: Anthony Minessale (anthm) 2005-08-01 21:23:34
wait there's more needs this too or the timer resets when you have any featre flags installed.
By: Anthony Minessale (anthm) 2005-08-01 21:27:53
it looks like rev2 is committed into CVS already but it's not resolved but that's ok cos I had to patch it even more and move the start time into the config obj so it's not reset whenever you exit ast_channel_bridge.
By: Mark Spencer (markster) 2005-08-03 00:38:38
Fixed in CVS head (with minor changes), thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:43:31.000-0600
r6268 | markster | 2008-01-15 15:43:30 -0600 (Tue, 15 Jan 2008) | 2 lines
Fix timestamp issue with features (bug ASTERISK-4638 with mods)