[asterisk-bugs] [Asterisk 0014657]: [patch] Callee cannot use dynamic features

Fri Mar 13 12:39:50 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14657 
====================================================================== 
Reported By:                mmichelson
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14657
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 181768 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-03-12 19:16 CDT
Last Modified:              2009-03-13 12:39 CDT
====================================================================== 
Summary:                    [patch] Callee cannot use dynamic features
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0101738) svnbot (reporter) - 2009-03-13 12:39
 http://bugs.digium.com/view.php?id=14657#c101738 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=14657)
    Reported by: mmichelson
    Patches:
          14657.patch uploaded by mmichelson (license 60)
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=182068 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-13 12:39 svnbot         Checkin                                      
2009-03-13 12:39 svnbot         Note Added: 0101738                          
======================================================================