[svn-commits] mmichelson: branch 1.6.0 r182064 - in /branches/1.6.0: ./ main/features.c

[SVN commits to the Digium repositories]

Author: mmichelson
Date: Fri Mar 13 12:33:29 2009
New Revision: 182064

URL: http://svn.digium.com/svn-view/asterisk?view=rev&rev=182064
Log:
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 #14657)
    Reported by: mmichelson
    Patches:
          14657.patch uploaded by mmichelson (license 60)
  ........
................

Modified:
    branches/1.6.0/   (props changed)
    branches/1.6.0/main/features.c

Propchange: branches/1.6.0/
------------------------------------------------------------------------------
Binary property 'trunk-merged' - no diff available.

Modified: branches/1.6.0/main/features.c
URL: http://svn.digium.com/svn-view/asterisk/branches/1.6.0/main/features.c?view=diff&rev=182064&r1=182063&r2=182064
==============================================================================
--- branches/1.6.0/main/features.c (original)
+++ branches/1.6.0/main/features.c Fri Mar 13 12:33:29 2009
@@ -1715,20 +1715,30 @@
 	struct ast_call_feature *feature;
 	struct feature_group *fg = NULL;
 	struct feature_group_exten *fge;
-	const char *dynamic_features;
+	const char *peer_dynamic_features, *chan_dynamic_features;
+	char dynamic_features_buf[128];
 	char *tmp, *tok;
 	int res = FEATURE_RETURN_PASSDIGITS;
 	int feature_detected = 0;
 
 	if (sense == FEATURE_SENSE_CHAN) {
 		ast_copy_flags(&features, &(config->features_caller), AST_FLAGS_ALL);
-		dynamic_features = pbx_builtin_getvar_helper(chan, "DYNAMIC_FEATURES");
 	}
 	else {
 		ast_copy_flags(&features, &(config->features_callee), AST_FLAGS_ALL);
-		dynamic_features = pbx_builtin_getvar_helper(peer, "DYNAMIC_FEATURES");
-	}
-	ast_debug(3, "Feature interpret: chan=%s, peer=%s, code=%s, sense=%d, features=%d, dynamic=%s\n", chan->name, peer->name, code, sense, features.flags, dynamic_features);
+	}
+
+	ast_channel_lock(peer);
+	peer_dynamic_features = ast_strdupa(S_OR(pbx_builtin_getvar_helper(peer, "DYNAMIC_FEATURES"),""));
+	ast_channel_unlock(peer);
+
+	ast_channel_lock(chan);
+	chan_dynamic_features = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "DYNAMIC_FEATURES"),""));
+	ast_channel_unlock(chan);
+
+	snprintf(dynamic_features_buf, sizeof(dynamic_features_buf), "%s%s%s", S_OR(chan_dynamic_features, ""), chan_dynamic_features && peer_dynamic_features ? "#" : "", S_OR(peer_dynamic_features,""));
+
+	ast_debug(3, "Feature interpret: chan=%s, peer=%s, code=%s, sense=%d, features=%d, dynamic=%s\n", chan->name, peer->name, code, sense, features.flags, dynamic_features_buf);
 
 	ast_rwlock_rdlock(&features_lock);
 	for (x = 0; x < FEATURES_COUNT; x++) {
@@ -1750,10 +1760,10 @@
 	}
 	ast_rwlock_unlock(&features_lock);
 
-	if (ast_strlen_zero(dynamic_features) || feature_detected)
+	if (ast_strlen_zero(dynamic_features_buf) || feature_detected)
 		return res;
 
-	tmp = ast_strdupa(dynamic_features);
+	tmp = dynamic_features_buf;
 
 	while ((tok = strsep(&tmp, "#"))) {
 		AST_RWLIST_RDLOCK(&feature_groups);