[asterisk-dev] semantics of send_digit_begin and AST_FLAG_END_DTMF_ONLY

[Russell Bryant]

Luigi Rizzo wrote:
> 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 is pretty much how it works now.

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

This would be undesirable behavior.  After you receive the beginning of 
a digit, we want to wait indefinitely until the end of the digit 
arrives.  This allows preserving the length of the digit instead of just 
passing an arbitrary length across the bridge.

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

You do know if a second even is coming.  You tell this based on what the 
first event was.  If it was marked as the beginning of the digit, you 
know an end is coming.  If you only got the end of a digit, you know 
that you have to emulate it instead.

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

There isn't any delay.  In the case that only the end is received, and 
also that the other side wants to see a beginning and end event, the end 
is immediately turned into a begin event, and passed along.  Then, after 
some time, and end is sent.

So, currently digit processing works as follows:

---------------------------------------
CHANNEL 1        |Bridge|     CHANNEL 2 (wants begin and end)
---------------------------------------
DTMF_BEGIN =====> ...... ==> DTMF_BEGIN
..
DTMF_END =======> ...... ==> DTMF_END
----------------------------------------


---------------------------------------
CHANNEL 1        |Bridge|     CHANNEL 2 (wants begin and end)
---------------------------------------
DTMF_END =====> ...... ==> DTMF_BEGIN
...
Audio
......100 ms later ... ==> DTMF_END
---------------------------------------


---------------------------------------
CHANNEL 1        |Bridge|     CHANNEL 2 (wants end only)
---------------------------------------
DTMF BEGIN =====> ......
..
DTMF_END =======> ...... ==> DTMF_END
---------------------------------------


---------------------------------------
CHANNEL 1        |Bridge|     CHANNEL 2 (wants end only)
---------------------------------------
DTMF_END =======> ...... ==> DTMF_END
---------------------------------------


I suppose the one simplification that could be made is that in the 3rd 
situation shown, instead of waiting for the end of the digit to pass on 
the event, it could be done at the beginning.  However, it seems that it 
would be most desirable for the system to act on a digit when the user 
lets go of a button instead of as soon as it is pressed.

-- 
Russell Bryant
Software Engineer
Digium, Inc.