Merged revisions 181990 via svnmerge from
authorMark Michelson <mmichelson@digium.com>
Fri, 13 Mar 2009 17:26:43 +0000 (17:26 +0000)
committerMark Michelson <mmichelson@digium.com>
Fri, 13 Mar 2009 17:26:43 +0000 (17:26 +0000)
commit88e3279f83c22b60d8c66e1066aa5f941ddd6323
tree7c22c32001dac7410bafafef3036f911f36f5948
parenta6734b5a957fc9e3f4a67dbf9b7ad8ed2dcec48f
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 #14657)
  Reported by: mmichelson
  Patches:
        14657.patch uploaded by mmichelson (license 60)
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
main/features.c