[asterisk-dev] VLDTMF eats DTMF, news at 11 (or look at bugid7868 if you love DTMF)

[Joshua Colp]

Dan Austin wrote:
> 
>> See bug for further notes... this isn't what you think.
> 
> I see the notes, a little thin on details though.  I checked
> Qwell's updates to chan_skinny, and see how he fixed it.
> I could see how my patch might not be 'right', but the
> fix wasn't exactly clear.
> 
> It seemed odd that chan_skinny could queue a proper series of 
> frames and ast_waitfordigit would get a munged series.  My 
> use of proper and munged is likely, well, munged.
> Instrumenting ast_waitfordigit_full with an ast_log() showed
> the first digit in a series of being of type FRAME_DTMF_BEGIN,
> ,thus ignored, and subsequent frames being type NULL and
> obviously ignored.
> 
> Might I assume that the major issue with my patch was a memory
> leak?  I'm not trying to defend my approach, but to understand
> where I went wrong.
> 
> In any case I'll test the version in svn on Tuesday.  
> 
> Thanks,
> Dan

1. Your patch added (maybe reverted) AST_FRAME_DTMF_BEGIN in the 
waitstream core, this would have caused duplicate received DTMF in 
applications that used the waitstream API.

2. Your patch disregarded DTMF compensation. The return of a null frame 
is on purpose, the DTMF compensation will later send a BEGIN and an END. 
This wasn't happening correctly because of the way chan_skinny operates. 
The channel wasn't in a state where compensation was working correctly. 
By sending a BEGIN and END in chan_skinny during dialing compensation 
doesn't occur and everything works. Once the channel is up after this 
then DTMF compensation works fine.

Joshua Colp
Digium