Summary:ASTERISK-11014: [patch] DYNAMIC_FEATURES variable looked up in wrong channel during feature interpretation
Reporter:Nic Bellamy (nic_bellamy)Labels:
Date Opened:2007-12-11 20:47:45.000-0600Date Closed:2007-12-12 13:52:23.000-0600
Versions:Frequency of
Environment:Attachments:( 0) dynamic_features_branch1.4-rev92423_v2.patch
Description:I just spent half a day banging my head against the dialplan before discovering this.

When you are using ${DYNAMIC_FEATURES}, the features are only checked against the channel that started the bridge. They should be checked against the channel that pressed the digits and broke the bridge.

This broke the following config for me:

exten => 201,1,NoOp(Incoming for 201)
exten => 201,n,Dial(SIP/201,30,rtM(dynamic-features))

exten => s,1,Set(DYNAMIC_FEATURES=myfeature)

What I wanted was for the called channel (SIP/201) to be able to dial the dynamic feature code, but not the calling channel; when attempting to dial it, however, it wouldn't work.

There's a lot more detail that could be added, but instead, I'm going to attach a patch - since when you read it, you'll go "Doh!" and instantly see the problem.

This bug is probably the reason most people have avoided using dynamic features - it was impossible to make them work correctly.


Patch attached.

FYI - this was actually developed against 1.2.25, but the code appears to be unchanged, and hence have the same problem, right through to trunk. Patch is for 1.4 SVN branch.
Comments:By: Nic Bellamy (nic_bellamy) 2007-12-11 20:50:14.000-0600

Whoops, ignore dynamic_features_branch1.4-rev92423.patch and look at dynamic_features_branch1.4-rev92423_v2.patch - I missed a bit.

Admin, please remove dynamic_features_branch1.4-rev92423.patch

By: Mark Michelson (mmichelson) 2007-12-12 13:52:22.000-0600

This is fixed in 1.4 (revision 92510) and in trunk (revision 92526). Thanks for the patch!