[asterisk-dev] semantics of send_digit_begin and AST_FLAG_END_DTMF_ONLY

[Steven Critchfield]

On Fri, 2007-01-19 at 13:08 -0800, Luigi Rizzo wrote:
> On Fri, Jan 19, 2007 at 02:15:22PM -0600, Russell Bryant wrote:
> > Luigi Rizzo wrote:
> > > probably Russel has some ideas on this...
> > > 
> > > I am a bit confused on the logic for handling AST_FRAME_DTMF_BEGIN
> > > and AST_FRAME_DTMF_END event/frames.
> > > 
> > > Basically, i understand that some channels two events per
> > > digit, and some only want one, and for the latter, we
> > > [somewhat arbitrarily i think] call it AST_FRAME_DTMF_END.
> > 
> > Well, there is some history behind the reasoning that this is the case. 
> >   Previously, Asterisk treated DTMF as a single event, and the frame 
> > type was AST_FRAME_DTMF.  However, there were some problems with this, 
> > so we had to start moving toward treating a digit as two events, a 
> > beginning and end.
> > 
> > To make this transition easiest, AST_FRAME_DTMF and AST_FRAME_DTMF_END 
> > are actually the exact same thing.  When the core receives an END 
> > without receiving a BEGIN earlier for whatever reason, it turns it into 
> > a BEGIN and later sends an END.
> > 
> > > Wouldn't it be simpler to just send a 'begin' event in
> > > all cases ? It seems that the whole processing would be
> > > simpler, because on the outgoing side, we don't have
> > > any conditional behaviour on the generation of
> > > the first event, and for the latter we could just
> > > not transmit it, or drop it if one comes in and
> > > we have no meaning for it ?
> > 
> > I wish that it actually was the case that when you read a digit from a 
> > channel, that the channel driver would always send a BEGIN and END for 
> > the digit.  However, it's not.  In some cases, it's for technical 
> > reasons, and for some it's backwards compatibility.
> 
> i think i did not explain myself clearly.
> I understand that in some cases a channel only generates
> one event, and in some it generates two. Now, what i meant is
> 
> 1. when you receive a digit, always send event #1 (call it begin if you like)
> 2. if the destination channel needs two events, when it is due time, also
>    send event #2 (call it end if you like)
> 
> This would remove the need for any magic in the initial handler,
> woudln't it ?
> an incoming event #1 in would always generate an event #1 out,
> possibly scheduling also an event #2 at a later time if
> the destination needs one (e.g. by setting send_dtmf_end
> to non-null).
> Then:

You seem to have missed the historic problem and the flag day event to
do it your way. Old versions sending stuff via IAX and such would only
have one event to send. When you have only one event, you can't
attribute it to a start because you may not receive an end. If you
receive an end without corresponding begin, you assume you are in this
condition and create the begin and end out of the one event.
-- 
Steven Critchfield <critch at basesys.com>