[asterisk-dev] [Code Review]: Triggers dialplan actions when specific CONTROL_FRAMES are detected on a channel

[Pavel Troller]

> 
> 
> > On April 10, 2012, 6:14 a.m., Olle E Johansson wrote:
> > > A few thoughts:
> > > * CONTROL_SOMETHING is a source code name and I don't like using that in userspace. There are a few events during the call and we should define them as names, instead of using the event names. 
> > > * Enabling all the control frames is not even remotely needed and can possibly be an issue. Does this function receive it before or after or instead of the normal consumer? What state are we in. If you trigger on DTMF and the dial plan listens for DTMF (like in an IVR) then what happens?
> > > * I suggest you add a channel variable to specify which event that triggered the execution
> > > 
> > > This needs a thorough architecture discussion.
> > 
> > Marco Signorini wrote:
> >     Hi Olle. Thank you for your review. Here are my comments.
> >     
> >     * CONTROL_SOMETHING is a source code name...: I don't have any preference on this. We used CONTROL_SOMETHING because these symbols are already defined in the code. What I think is that adding other definitions could generate maintenance issues and/or mismatch in the future. But this is just my opinion.
> >     * Enabling all the control frames is not even remotely needed and can possibly be an issue...: The idea is that the list of control frames types will raise a trigger should be specified in the dialplan when calling the function. I couldn't see problems when listening for DTMF in a IVR channel but obviously is up to the caller to define what the gosub function will do. If, for example, the gosub action for a DTMF event is something like "hangup" this should be a problem (probably).
> >     * I suggest you add a channel variable to specify which event that triggered the execution: we decided to have a different behavior. Instead of defining a channel variable to specify which event triggered the execution we preferred to call a specifig gosub extension where the event name is embedded in the extension itself. I mean, triggered by, for example, a CONTROL_HOLD event, the execution will gosub on the ext-CONTROL_HOLD at context. This allow the user to differentiate the code for each different event.
> >     
> >     Thanks!
> 
> Options that are 'experimental' or for hobby enthusiasts, when included in the main release branches of Asterisk, have a tendency to cause more problems then they solve.
> 
> While this may be a fun feature to have in some systems, the objections raised by Olle, Josh, and Mark are valid, and this feature has inherent dangers that make it more risky to include then we feel is warranted.  As such, in its current incarnation, this is not a feature we will want in Asterisk.
> 
> You're more then welcome to have this patch made available in a personal branch.
> 

Hi!
  If I understand it correctly, this feature could fulfill my long-term wish - being able to register digits sent in the overlap dialling mode (when the main dialplan is already executing Dial() but the dialling is still in progress). This is a feature strongly needed not only for enthusiasts, but for any regular Asterisk user, who wants to use overlap dialling, to be able to have complete numbers in the CDRs, to have the "Last Number Redial" feature fully functional etc. etc. It works even in the most stupid classic PBXes and in my case, it was at least three times a showstopper for replacing them with Asterisk. So, my opinion is that this feature is really needed and it fills a big hole in Asterisk functionality. Please rethink it, or suggest a better way to solve this problem.

  With regards,
    Pavel

> 
> - Matt
> 
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1778/#review5958
> -----------------------------------------------------------
> 
> 
> On April 10, 2012, 5:47 a.m., Marco Signorini wrote:
> > 
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviewboard.asterisk.org/r/1778/
> > -----------------------------------------------------------
> > 
> > (Updated April 10, 2012, 5:47 a.m.)
> > 
> > 
> > Review request for Asterisk Developers.
> > 
> > 
> > Summary
> > -------
> > 
> > A filter can be applied to the trigger to limit frames sensibility. This filter can either be a white or black list of control frame types. When no filter type is present, white is used. If no arguments are provided at all, all frames will trigger the specified gosub call.
> > If the specified gosub extension is not present on the dialplan, the function will gosub to the "s-XXXX" extension in the gosub context where XXXX is the type of the control frame.
> > It can be set only once on a given channel.
> > 
> > Examples:
> > exten => 1,1,Set(FRAME_TRIGGER(white, CONTROL_HOLD)=ext,context); trigger gosub ext-CONTROL_HOLD at context only for HOLD type control frames
> > exten => 1,1,Set(FRAME_TRIGGER(black, CONTROL_HOLD)=ext,context); trigger gosub ext-CONTROL_XXXX at context for all control type frames except for HOLD type control frames
> > exten => 1,1,Set(FRAME_TRIGGER(CONTROL_HOLD, CONTROL_UNHOLD)=context) ; trigger gosub to s-CONTROL_HOLD at context and s-CONTROL_UNHOLD context only for HOLD and UNHOLD type control frames
> > 
> > This feature was originally developed in order to track MOH events in a call center environment but has general interest.
> > 
> > 
> > This addresses bug ASTERISK-19319.
> >     https://issues.asterisk.org/jira/browse/ASTERISK-19319
> > 
> > 
> > Diffs
> > -----
> > 
> >   /trunk/funcs/func_frame_trigger.c PRE-CREATION 
> > 
> > Diff: https://reviewboard.asterisk.org/r/1778/diff
> > 
> > 
> > Testing
> > -------
> > 
> > 
> > Thanks,
> > 
> > Marco
> > 
> >
> 

> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev