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-0600 | Date Closed: | 2007-12-12 13:52:23.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_features |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
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: [test] exten => 201,1,NoOp(Incoming for 201) exten => 201,n,Dial(SIP/201,30,rtM(dynamic-features)) [macro-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. ****** ADDITIONAL INFORMATION ****** 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! |