| Summary: | ASTERISK-11354: Call-bridged Macro feature request | ||
| Reporter: | Steve Davies (one47) | Labels: | |
| Date Opened: | 2008-02-01 05:53:05.000-0600 | Date Closed: | 2011-06-07 14:02:42 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/NewFeature |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Request for a new feature on Dial() and Queue(), to allow dialplan macro(s) to be executed on channels when they are bridged. ****** ADDITIONAL INFORMATION ****** Feature request based on a mailing-list discussion: A new parameter to Dial(), perhaps a B(macro) parameter which works a bit like M(macro), except that is is executed whenever any sort of call bridge is completed, rather than when the call is answered. The macro would be called with a couple of system variables set to indicate channels involved, and the type of transfer taking place. One complication - There might be 2 call legs with either the same or different B() parameters specified... This would need resolving in some defined way! Most simply by calling macros repeated times, with a variable set to show what calls have already been completed. This feature would allow more than just a Beep to be played (bug ASTERISK-8972), it would allow call-recording settings to be re-evaluated for the newly bridged call, MoH settings to be changed, CDR updates, and all sorts of other useless behaviour that keeps end-users happy :) Of course, ideally M() and B() behaviour would also be available to app_queue originated calls. | ||
| Comments: | By: Michiel van Baak (mvanbaak) 2008-02-01 05:55:09.000-0600 We dont support feature requests without code on the bugtracker. This is for tracking bugs and new patches only. By: Michiel van Baak (mvanbaak) 2008-02-01 06:16:42.000-0600 reopened. Sorry if I offended anyone, not my intention at all By: Steve Davies (one47) 2008-02-01 06:57:15.000-0600 No offence taken. I am easily confused ;) Could this feature request be marked as associated with bug ASTERISK-8972, which prompted the feature request. After which, it /could/ be marked as closed while the details are discussed on the mailing list - I believe that is how it is meant to work :) I have sufficient need for a feature like this that I am happy to put some effort into a patch, but would appreciate some advice on the best way to implement it, and what people would expect to be possible. Setting a channel variable to indicate that a macro should be executed whenever a bridge-type event occurs would be one way, and would be app-independent, or perhaps using a B() parameter to Dial() and adding a parameter to the channel structure would be another. What complications are there in running a macro on a already-bridged channels? By: Steve Davies (one47) 2008-02-14 10:18:00.000-0600 Please feel free to mark this as closed - No significant discussion was forthcoming, and I will re-open it once I have code to offer. By: Russell Bryant (russell) 2008-02-27 19:37:06.000-0600 Suspended as requested | ||