| Summary: | ASTERISK-13435: After Dial's L() limit is reached, res_feature's dynamic features don't work | ||
| Reporter: | Tim Ringenbach at Asteria Solutions Group (tim_ringenbach) | Labels: | |
| Date Opened: | 2009-01-22 15:20:44.000-0600 | Date Closed: | 2009-03-03 14:11:10.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/Channels |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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. | ||
| Comments: | By: Mark Michelson (mmichelson) 2009-01-23 17:44:18.000-0600 I can confirm this bug exists. It also affects features which are not dynamic features, too, such as built-in transfers and one-touch parking. By: Rene Gollent (rgollent) 2009-01-23 20:57:09.000-0600 Note another problem here: even with the above patch, no feature can be activated *while* the warning sound is playing, only after. Should this be considered as a separate issue (and have a ticket filed), or part of the same problem? By: Jeff Peeler (jpeeler) 2009-02-17 15:52:24.000-0600 Unfortunately, the dynamic features are not designed to work while playing back audio from outside the bridge. It would be considered a separate issue, but really is a feature request. By: Digium Subversion (svnbot) 2009-02-17 15:54:35.000-0600 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 ASTERISK-13435 Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176701 By: Digium Subversion (svnbot) 2009-02-17 16:08:01.000-0600 Repository: asterisk Revision: 176708 _U trunk/ U trunk/include/asterisk/channel.h U trunk/main/channel.c U trunk/main/features.c ------------------------------------------------------------------------ r176708 | jpeeler | 2009-02-17 16:08:01 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ 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 ASTERISK-13435 Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176708 By: Digium Subversion (svnbot) 2009-02-17 16:14:39.000-0600 Repository: asterisk Revision: 176710 _U branches/1.6.0/ U branches/1.6.0/include/asterisk/channel.h U branches/1.6.0/main/channel.c U branches/1.6.0/main/features.c ------------------------------------------------------------------------ r176710 | jpeeler | 2009-02-17 16:14:38 -0600 (Tue, 17 Feb 2009) | 30 lines Merged revisions 176708 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ 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 ASTERISK-13435 Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176710 By: Digium Subversion (svnbot) 2009-02-17 16:15:26.000-0600 Repository: asterisk Revision: 176711 _U branches/1.6.1/ U branches/1.6.1/include/asterisk/channel.h U branches/1.6.1/main/channel.c U branches/1.6.1/main/features.c ------------------------------------------------------------------------ r176711 | jpeeler | 2009-02-17 16:15:26 -0600 (Tue, 17 Feb 2009) | 30 lines Merged revisions 176708 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ 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 ASTERISK-13435 Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176711 By: Digium Subversion (svnbot) 2009-02-17 16:17:44.000-0600 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) | 18 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 ASTERISK-13435) Reported by: tim_ringenbach Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176701 By: Digium Subversion (svnbot) 2009-02-17 16:18:10.000-0600 Repository: asterisk Revision: 176708 _U trunk/ U trunk/include/asterisk/channel.h U trunk/main/channel.c U trunk/main/features.c ------------------------------------------------------------------------ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 24 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ 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 ASTERISK-13435) Reported by: tim_ringenbach Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176708 By: Digium Subversion (svnbot) 2009-02-17 16:18:36.000-0600 Repository: asterisk Revision: 176710 _U branches/1.6.0/ U branches/1.6.0/include/asterisk/channel.h U branches/1.6.0/main/channel.c U branches/1.6.0/main/features.c ------------------------------------------------------------------------ r176710 | jpeeler | 2009-02-17 16:14:38 -0600 (Tue, 17 Feb 2009) | 31 lines Merged revisions 176708 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ 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 ASTERISK-13435) Reported by: tim_ringenbach Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176710 By: Digium Subversion (svnbot) 2009-02-17 16:18:59.000-0600 Repository: asterisk Revision: 176711 _U branches/1.6.1/ U branches/1.6.1/include/asterisk/channel.h U branches/1.6.1/main/channel.c U branches/1.6.1/main/features.c ------------------------------------------------------------------------ r176711 | jpeeler | 2009-02-17 16:15:26 -0600 (Tue, 17 Feb 2009) | 31 lines Merged revisions 176708 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ 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 ASTERISK-13435) Reported by: tim_ringenbach Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=176711 By: Steve Murphy (murf) 2009-02-28 10:20:27.000-0600 sorry, I don't mean to rain on the parade, but I've just verified that version 176701 introduces a regression to 1.4 (and who knows/cares what other versions!). The problem is this: Pick your favorite 3 phones. Call them A, B and C. 1. A calls B 2. B answers 3. A dials *2# (or whatever the feature code is for attended xfer). (B will get MOH; A will get "transfer played) 4. A dials C 5. Before C answers, A hangs up. At 176701, and after, at this point, B is hung up and C is closed down. The call collapses. At 176700, and previous, at this point, C continues ringing, and B is still getting MOH. The situation has reverted to a blind xfer. I haven't investigated to see why this behavior changes, but you (jpeeler) know better what your change was for; I'd be happy to work with you on fixing this: if you need me, just let me know. By: Digium Subversion (svnbot) 2009-03-02 17:54:39.000-0600 Repository: asterisk Revision: 179536 U branches/1.4/main/channel.c ------------------------------------------------------------------------ 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 ASTERISK-13435) Reported by: tim_ringenbach ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179536 By: Digium Subversion (svnbot) 2009-03-02 18:01:52.000-0600 Repository: asterisk Revision: 179537 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r179537 | jpeeler | 2009-03-02 18:01:52 -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 ASTERISK-13435) Reported by: tim_ringenbach ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179537 By: Digium Subversion (svnbot) 2009-03-02 18:03:37.000-0600 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 ASTERISK-13435) Reported by: tim_ringenbach ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179538 By: Digium Subversion (svnbot) 2009-03-02 18:04:11.000-0600 Repository: asterisk Revision: 179539 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r179539 | jpeeler | 2009-03-02 18:04:10 -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 ASTERISK-13435) Reported by: tim_ringenbach ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179539 By: Digium Subversion (svnbot) 2009-03-03 14:10:20.000-0600 Repository: asterisk Revision: 179536 U branches/1.4/main/channel.c ------------------------------------------------------------------------ r179536 | jpeeler | 2009-03-02 17:54:39 -0600 (Mon, 02 Mar 2009) | 10 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. (closes issue ASTERISK-13435) Reported by: tim_ringenbach ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179536 By: Digium Subversion (svnbot) 2009-03-03 14:10:36.000-0600 Repository: asterisk Revision: 179537 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r179537 | jpeeler | 2009-03-02 18:01:51 -0600 (Mon, 02 Mar 2009) | 16 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. (closes issue ASTERISK-13435) Reported by: tim_ringenbach ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179537 By: Digium Subversion (svnbot) 2009-03-03 14:10:53.000-0600 Repository: asterisk Revision: 179538 _U branches/1.6.0/ U branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r179538 | jpeeler | 2009-03-02 18:03:36 -0600 (Mon, 02 Mar 2009) | 23 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. (closes issue ASTERISK-13435) Reported by: tim_ringenbach ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179538 By: Digium Subversion (svnbot) 2009-03-03 14:11:09.000-0600 Repository: asterisk Revision: 179539 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r179539 | jpeeler | 2009-03-02 18:04:10 -0600 (Mon, 02 Mar 2009) | 23 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. (closes issue ASTERISK-13435) Reported by: tim_ringenbach ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=179539 | ||