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

[Dan Austin]

Dan Austin wrote:
>> The bug was opened against chan_skinny, but it was an
>> innocent bystander.
>> 
>> The test for AST_FLAG_EMULATE_DTMF in __ast_read() needs
>> the else clause wrapped in braces, or it will null-out our
>> much loved DTMF.
>> 
>> Chan_skinny with it's unusual method of handling DTMF might
>> just be the only channel driver that would trigger this
>> particular failure.
>> 
>> The fix in bugid has been tested against chan_skinny, chan_sip,
>> chan_iax2 and chan_ooh323.  It fixed DTMF detection with chan_skinny,
>> and does not appear to have caused any regressions against
>> SIP, IAX2 or H323.
>> 
>> Dan

> 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