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

[Matthew Jordan]

----- Original Message -----
> From: "Pavel Troller" <patrol at sinus.cz>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Friday, July 27, 2012 11:27:27 PM
> Subject: Re: [asterisk-dev] [Code Review]: Triggers dialplan actions	when	specific CONTROL_FRAMES are detected on a
> channel
> 
> 
> 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

First, there is already support for Overlap dialing in Asterisk.  Granted,
this requires careful construction of the dialplan, usage of the Incomplete
application, and proper configuration of the channel drivers, but it is a
supported and used feature in Asterisk.

Now, consider what you're proposing - an inbound call has entered an extension
and has executed a Dial.  We are now somewhere inside the Dial application,
most likely servicing frames for that channel while we wait for the dialed
technology to indicate to us that something has happened.  While inside the
Dial, the inbound channel receives additional digits.  Let's say this patch was
used and, on the reception of a DTMF frame, the frame hook intercepts the frame
from the Dial application's frame servicing loop and goes and runs a GoSub.

This is all happening on the same thread of execution that would be servicing
the channel in the Dial loop.  Because autoservice wasn't started (Mark and
Josh's finding) on the channel, frames are piling up and no one is servicing
them.  Heck, at this point, the outbound channel technology may have told the
inbound channel calling it that its Busy, or Congested, or it may have even
Answered!  But because you're off in the frame hook's GoSub loop, and no
Autoservice was started, you have no knowledge of this.

In this particular scenario, say you got a DTMF.  What do you do with it? 
You're already in a Dial application.  Do you go and start another Dial
application with the new digits that were passed to you?  What about the one
that you're already in?  How do you leave it?  Since you haven't started
Autoservice, there isn't even the possibility that another thread can respond to
the frames that the outbound channel has put on the inbound channel.  What do you
do with the outbound channel that you called if it Answered?

Your statement underscores the danger of this feature, particularly when a
properly configured Asterisk system can probably handle 99% of the use case
you outlined. 

While this patch has valid uses, the fact that it blindly allows bouncing out to
a section of dialplan for *any* frame means that people will configure their
systems and break them in ways we can't imagine or envision, much less support.
Because of this, if you really want this patch, and the author of the patch
is willing to provide it, you can go and patch your Asterisk system with this
feature.  But I don't think that in its current incaranation it should be in
Asterisk.

--
Matthew Jordan
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org