asterisk

History

Russell Bryant 0d9ea31f3a Fix a problem that occurred if a user entered a digit that matched a bridge feature that was configured using multiple digits, and the digit that was pressed timed out in the feature digit timeout period. For example, if blind transfer is configured as '##', and a user presses just '#'. In this situation, the call would lock up and no longer pass any frames. (issue #7977 reported by festr, and issue #7982 reported by michaels and valuable input provided by mneuhauser and kuj. Fixed by me, with testing help and peer review from Joshua Colp). There are a couple of issues involved in this fix: 1) When ast_generic_bridge determines that there has been a timeout, it returned AST_BRIDGE_RETRY. Then, when ast_channel_bridge gets this result, it calls ast_generic_bridge over again with the same timestamp for the next event. This results in an endless loop of nothing until the call is terminated. This is resolved by simply changing ast_generic_bridge to return AST_BRIDGE_COMPLETE when it sees a timeout. 2) I also changed ast_channel_bridge such that if in the process of calculating the time until the next event, it knows a timeout has already occured, to immediately return AST_BRIDGE_COMPLETE instead of attempting to bridge the channels anyway. 3) In the process of testing the previous two changes, I ran into a problem in res_features where ast_channel_bridge would return because it determined that there was a timeout. However, ast_bridge_call in res_features would then determine by its own calculation that there was still 1 ms before the timeout really occurs. It would then proceed, and since the bridge broke out and did not return a frame, it interpreted this as the call was over and hung up the channels. The reason for this was because ast_bridge_call in res_features and ast_channel_bridge in channel.c were using different times for their calculations. channel.c uses the start_time on the bridge config, which is the time that the feature digit was recieved. However, res_features had another time, 'start', which was set right before calling ast_channel_bridge. 'start' will always be slightly after start_time in the bridge config, and sometimes enough to round up to one ms. This is fixed by making ast_bridge_call use the same time as ast_channel_bridge for the timeout calculation. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@43778 65c4cc65-6c06-0410-ace0-fbb531ad65f3		20 years ago
..
Makefile	remove extraneous svn:executable properties	21 years ago
res_adsi.c	remove extraneous svn:executable properties	21 years ago
res_agi.c	Don't close the second file descriptor if it's the same as the first one, as it will have already been closed elsewhere and could cause massive panic. (issue #7699 reported by bn999)	20 years ago
res_config_odbc.c	Bug 6615 - Fix 64bit conversion errors by using a long int	21 years ago
res_crypto.c	remove extraneous svn:executable properties	21 years ago
res_features.c	Fix a problem that occurred if a user entered a digit that matched a bridge	20 years ago
res_indications.c	remove extraneous svn:executable properties	21 years ago
res_monitor.c	fix inaccurate ack message to ChangeMonitor action (issue #6630 )	21 years ago
res_musiconhold.c	Treat the file as invalid if we have no valid formats for it (issue #7643 reported by KNK)	20 years ago
res_odbc.c	Fix for (#6309 ), potential (highly unlikely) memory leak in res_odbc	21 years ago
res_osp.c	remove extraneous svn:executable properties	21 years ago