| Summary: | ASTERISK-13739: [patch] Callee cannot use dynamic features | ||
| Reporter: | Mark Michelson (mmichelson) | Labels: | |
| Date Opened: | 2009-03-12 19:16:45 | Date Closed: | 2009-03-13 12:39:50 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_features |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 14657.patch | |
| Description: | The dynamic features which can be set in the applicationmap section of features.conf are supposed to be able to control the access to the feature for both parties of a bridged call. Unfortunately, the way the code is written, the callee is unable to actually make use of the features because the DYNAMIC_FEATURES variable is only read from the channel pressing DTMF during a bridge. Since 99% of the time, the DYNAMIC_FEATURES variable has only been set on the calling channel, this means that even if the dynamic features defined are supposed to allow for the callee to use them, he will not be able to. I am attaching a patch which changes the behavior of ast_feature_interpret. With this change, we concatenate the dynamic features defined on both channels. The features themselves control who should have the ability to use them, so this should not introduce any "permissions" problems. | ||
| Comments: | By: Digium Subversion (svnbot) 2009-03-13 12:12:33 Repository: asterisk Revision: 181990 U branches/1.4/res/res_features.c ------------------------------------------------------------------------ r181990 | mmichelson | 2009-03-13 12:12:32 -0500 (Fri, 13 Mar 2009) | 35 lines Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF. Dynamic features defined in the applicationmap section of features.conf allow one to specify whether the caller, callee, or both have the ability to use the feature. The documentation in the features.conf.sample file could be interpreted to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the calling channel in order to allow for the callee to be able to use the features which he should have permission to use. However, the DYNAMIC_FEATURES variable would only be read from the channel of the participant that pressed the DTMF sequence to activate the feature. The result of this was that the callee was unable to use dynamic features unless the dialplan writer had taken measures to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel. This commit changes the behavior of ast_feature_interpret to concatenate the values of DYNAMIC_FEATURES from both parties involved in the bridge. The features themselves determine who has permission to use them, so there is no reason to believe that one side of the bridge could gain the ability to perform an action that they should not have the ability to perform. Kevin Fleming pointed out on the asterisk-users list that the typical way that this was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel so that the value would be inherited by the called channel. While this works, the documentation alone is not enough to figure out why this is necessary for the callee to be able to use dynamic features. In this particular case, changing the code to match the documentation is safe, easy, and will generally make things easier for people for future installations. This bug was originally reported on the asterisk-users list by David Ruggles. (closes issue ASTERISK-13739) Reported by: mmichelson Patches: 14657.patch uploaded by mmichelson (license 60) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181990 By: Digium Subversion (svnbot) 2009-03-13 12:26:43 Repository: asterisk Revision: 182029 _U trunk/ U trunk/main/features.c ------------------------------------------------------------------------ r182029 | mmichelson | 2009-03-13 12:26:43 -0500 (Fri, 13 Mar 2009) | 41 lines Merged revisions 181990 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181990 | mmichelson | 2009-03-13 12:12:32 -0500 (Fri, 13 Mar 2009) | 35 lines Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF. Dynamic features defined in the applicationmap section of features.conf allow one to specify whether the caller, callee, or both have the ability to use the feature. The documentation in the features.conf.sample file could be interpreted to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the calling channel in order to allow for the callee to be able to use the features which he should have permission to use. However, the DYNAMIC_FEATURES variable would only be read from the channel of the participant that pressed the DTMF sequence to activate the feature. The result of this was that the callee was unable to use dynamic features unless the dialplan writer had taken measures to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel. This commit changes the behavior of ast_feature_interpret to concatenate the values of DYNAMIC_FEATURES from both parties involved in the bridge. The features themselves determine who has permission to use them, so there is no reason to believe that one side of the bridge could gain the ability to perform an action that they should not have the ability to perform. Kevin Fleming pointed out on the asterisk-users list that the typical way that this was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel so that the value would be inherited by the called channel. While this works, the documentation alone is not enough to figure out why this is necessary for the callee to be able to use dynamic features. In this particular case, changing the code to match the documentation is safe, easy, and will generally make things easier for people for future installations. This bug was originally reported on the asterisk-users list by David Ruggles. (closes issue ASTERISK-13739) Reported by: mmichelson Patches: 14657.patch uploaded by mmichelson (license 60) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=182029 By: Digium Subversion (svnbot) 2009-03-13 12:33:30 Repository: asterisk Revision: 182064 _U branches/1.6.0/ U branches/1.6.0/main/features.c ------------------------------------------------------------------------ r182064 | mmichelson | 2009-03-13 12:33:30 -0500 (Fri, 13 Mar 2009) | 48 lines Merged revisions 182029 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r182029 | mmichelson | 2009-03-13 12:26:43 -0500 (Fri, 13 Mar 2009) | 41 lines Merged revisions 181990 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181990 | mmichelson | 2009-03-13 12:12:32 -0500 (Fri, 13 Mar 2009) | 35 lines Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF. Dynamic features defined in the applicationmap section of features.conf allow one to specify whether the caller, callee, or both have the ability to use the feature. The documentation in the features.conf.sample file could be interpreted to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the calling channel in order to allow for the callee to be able to use the features which he should have permission to use. However, the DYNAMIC_FEATURES variable would only be read from the channel of the participant that pressed the DTMF sequence to activate the feature. The result of this was that the callee was unable to use dynamic features unless the dialplan writer had taken measures to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel. This commit changes the behavior of ast_feature_interpret to concatenate the values of DYNAMIC_FEATURES from both parties involved in the bridge. The features themselves determine who has permission to use them, so there is no reason to believe that one side of the bridge could gain the ability to perform an action that they should not have the ability to perform. Kevin Fleming pointed out on the asterisk-users list that the typical way that this was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel so that the value would be inherited by the called channel. While this works, the documentation alone is not enough to figure out why this is necessary for the callee to be able to use dynamic features. In this particular case, changing the code to match the documentation is safe, easy, and will generally make things easier for people for future installations. This bug was originally reported on the asterisk-users list by David Ruggles. (closes issue ASTERISK-13739) Reported by: mmichelson Patches: 14657.patch uploaded by mmichelson (license 60) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=182064 By: Digium Subversion (svnbot) 2009-03-13 12:39:50 Repository: asterisk Revision: 182068 _U branches/1.6.1/ U branches/1.6.1/main/features.c ------------------------------------------------------------------------ r182068 | mmichelson | 2009-03-13 12:39:50 -0500 (Fri, 13 Mar 2009) | 48 lines Merged revisions 182029 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r182029 | mmichelson | 2009-03-13 12:26:43 -0500 (Fri, 13 Mar 2009) | 41 lines Merged revisions 181990 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181990 | mmichelson | 2009-03-13 12:12:32 -0500 (Fri, 13 Mar 2009) | 35 lines Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF. Dynamic features defined in the applicationmap section of features.conf allow one to specify whether the caller, callee, or both have the ability to use the feature. The documentation in the features.conf.sample file could be interpreted to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the calling channel in order to allow for the callee to be able to use the features which he should have permission to use. However, the DYNAMIC_FEATURES variable would only be read from the channel of the participant that pressed the DTMF sequence to activate the feature. The result of this was that the callee was unable to use dynamic features unless the dialplan writer had taken measures to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel. This commit changes the behavior of ast_feature_interpret to concatenate the values of DYNAMIC_FEATURES from both parties involved in the bridge. The features themselves determine who has permission to use them, so there is no reason to believe that one side of the bridge could gain the ability to perform an action that they should not have the ability to perform. Kevin Fleming pointed out on the asterisk-users list that the typical way that this was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel so that the value would be inherited by the called channel. While this works, the documentation alone is not enough to figure out why this is necessary for the callee to be able to use dynamic features. In this particular case, changing the code to match the documentation is safe, easy, and will generally make things easier for people for future installations. This bug was originally reported on the asterisk-users list by David Ruggles. (closes issue ASTERISK-13739) Reported by: mmichelson Patches: 14657.patch uploaded by mmichelson (license 60) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=182068 | ||