[asterisk-dev] semantics of send_digit_begin and AST_FLAG_END_DTMF_ONLY

[Luigi Rizzo]

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:
- if event #2-in comes in, you call send_dtmf_end() (or drop the
  event if NULL), and reset the timeout;
- if the timeout comes first, call send_dtmf_end() (or drop)
  and record that the next event#2 (if any comes before
  a new event#1) should be dropped because the timeout
  already took care of it.
Note, i think you know upfront if an event#2 will be
coming or you need to simulate it, so the above is
even simpler than what i wrote.

Makes sense ? It also seems to remove the delay that
you are introducing (because from the description below,
which i am leaving, it seems that you wait for the END
event before forwarding the events ?)

	cheers
	luigi

> For example, if you connect to an Asterisk 1.2 system using IAX2, when 
> the 1.2 system sends DTMF, it will send just a single AST_FRAME_DTMF 
> frame over IAX2.  Another example is SIP INFO dtmf.  The INFO message is 
> just a single event.
> 
> One way to solve this would be to make all of the channel drivers figure 
> out a way to turn single DTMF events into a BEGIN and END.  However, it 
> made more sense to me to implement this in the core, so it only had to 
> be dealt with in one place.
> 
> To solve this situation, ast_read() performs some magic.  It turns an 
> END into a BEGIN, and after a certain amount of audio has passed 
> through, it sends an END frame.  Now, with the latest changes, this only 
> done if we determine that the other channel cares to receive BEGIN 
> frames in the first place.  The only case of this we have right now is a 
> SIP channel using INFO dtmf.  The reason it has to be this way is 
> because if you have two SIP channels with audio not flowing through 
> Asterisk, there is no audio to time off of to figure out when to send 
> the END.  There are other ways we could go about scheduling the end of 
> the digit, but it's all extra unneeded processing if the other side 
> doesn't care anyway.
> 
> The way the core decides if a channel wants begin frames is if the 
> technology has a send_digit_begin callback.  I agree that this seems a 
> bit of a hack, but I haven't really thought of a better way.  Another 
> option would be to just introduce another flag on the channel structure 
> itself that would be set by the channel driver when the channel gets 
> created.
> 
> --
> Russell Bryant
> Software Engineer
> Digium, Inc.
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev