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

[Pavel Troller]

> 
> 
> ----- 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

Hi Matthew!

> 
> 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.

Of course there is this support, I know it very well and I actively use it -
and this is the reason for which I so strongly beg for the possibility to
register the forwarded digits. AFAIK, the digits forwarded (bridged over) are
not being remembered anywhere, so we cannot add them to the CDR (so the CDRs
with overlapped calls are incomplete, the called numbers are truncated at the
point where Asterisk made the routing decision and seized the outgoing line
with Dial()), and also, when somebody tries to use the Last Number Redial
feature (if implemented), he will get the dialtone of the outgoing line (if
provided) and not the desired destination.

> 
> 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.

I fully understand all the problems. I'm fully aware of the real time nature
of the switching systems, which Asterisk definitely is. Of course execution of
the Gosub() should be very, very quick.

> 
> 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.

Of course. But still, if the execution would be very short (a few
microseconds), neither of these dangers can make any harm.

> 
> 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?

The only thing I would like to do in the subroutine would be something like
this:

exten => s,1,GotoIf($[${DIALSTATUS} = "ANSWER"]?end)
exten => s,n,Set(OVERLAP_DIGITS=${OVERLAP_DIGITS}${FRAME_DATA})
exten => s,n(end),Return()

The subroutine has these assumptions:
1) That the DIALSTATUS variable (or a similar one, provided by the hook calling
   logic) is available in it, reporting current call status, to be able to 
   ignore the dialling after the call is answered (this is not considered as an
   overlap dialling anymore)
2) That the hook calling logic passes the frame data field to the subroutine
3) That the subroutine is being called only for the DTMF_END events, which can
   be nicely done by using the white filter.

The contents of the OVERLAP_DIGITS variable would be then used at two places:
1) If the called party hangs up first, in continuation of the main dialplan
   (the 'g' flag is set for the Dial())
2) If the calling party hangs up first, in the 'h' extension.

The variable would be used just to complete the CDR records and the Last Number
Redial database entry.


> 
> 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. 

And this is the problem. The missing 1% is preventing to use the whole nice
overlap dialling feature in the real telecom industry environment, making it
just an "enthusiast's" one. A real operator (please believe me, I'm working for
one, and trying to push Asterisk, wherever I can) really needs complete CDRs
for several reasons, including Lawful Interception. A real PBX owner also
requires this feature, to have the LNR feature fully working.

> 
> 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.

I fully agree, that this feature would require BIG BIG BIG caution from the
users. But - you know - if you buy a knife, you also should be careful when
using it. And the possibility to make yourself an injury doesn't prevent knives
from being sold :-).

With regards,
  Pavel

> 
> --
> 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
> 
> --
> _____________________________________________________________________
> -- 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