[asterisk-dev] Unexpected variable-length DTMF behaviors

[Russell Bryant]

Paul Cadach wrote:
> Which sort of problems follow from above? A few:
> 1) we always make a delay when peer channel isn't support dual-event scheme;
> 2) peer channel should calculate DTMF duration itself (for SIP 
> INFO/H.323 signal events) by remembering times of DTMF_BEGIN and 
> DTMF_END events;

As you mentioned below, these first two issues have already been resolved.

> 3) applications get AST_FRAME_DTMF_BEGIN transparently (because they 
> react to AST_FRAME_DTMF only), which could cause some side effects (for 
> example, Echo() application).

I'm not sure what side effects a DTMF_BEGIN frame could cause for
applications.  If they are only coded to react to AST_FRAME_DTMF, then
the BEGIN frames will be silently ignored.  That is exactly what we wanted.

For the echo application, it just sends back *any* frames it gets,
including the new BEGIN frames.  There are no problems there.

> To resolve last issue, application should react on first DTMF event 
> (BEGIN) only and silently ignore second event (END). This can be easily 
> done by re-assigning AST_FRAME_DTMF from AST_FRAME_DTMF_END to 
> AST_FRAME_DTMF_BEGIN. How it will impact existing applications? Lets 
> examine...

I'm not sure that this is really desired.  We made it so applications
react on an END frame on purpose.

For example, if there is an application that is going to start playing a
  prompt once you press a key, it should wait until you stop pressing
the key to start playing the sound to you.  Otherwise, the prompt would
start while you're still listening to DTMF during your key press.

As far as I am concerned, there are no problems with the current
implementation.  If you still think there is, then you will need to show
some examples of situations where the current implementation causes a
real problem.

-- 
Russell Bryant
Software Engineer
Digium, Inc.