[asterisk-dev] VLDTMF redesign

[Dmitry Andrianov]

Dear core developers,
I've spent another day fighting with VLDTMF emulation code in ast_read which caused some digits to be swapped randomly and again came to conclusion that it cannot be properly fixed in its current design. The main problem is the AST_FLAG_END_DTMF_ONLY channel flag which indicates that code calling ast_read is not interested in AST_FRAME_DTMF_BEGIN frames and only wants AST_FRAME_DTMF_END ones.
This flag is mostly used by the autoservice. The flag is set each time channel is being autoserviced and reset when autoservice ends. Obviously this switch can occur multiple times during dialing because channel set to autoservice mode each time Asterisk does lookup in DUNDi/realtime switch which can occur for each new digit dialed (in case of Zap).

Clearly, the current implementation cannot properly handle bounces of this flag and worst of all it is really difficult to fix. Because of this I remember about five DTMF-related issues in the last two months and two new filled today. All of them revolve around ast_read.

My proposal is to move the VDTMF emulation code from ast_read to ast_write. This way, when application reads channel it is not guaranteed to get properly paired BEGIN+END frames. It is not guaranteed to get reasonable minimum duration of DTMF. And it is not guaranteed to see reasonable gap between these frames. The good thing is that I'm not aware of any application for which these things are important. Majority of them only need DTMF_END frame - this is how digits pressed by the user are read.

When application writes DTMF frames using ast_write - this function will normalize DTMF. It will create missing BEGIN frames if needed, ensure proper delay between BEGIN and END, between END and BEGIN of the next digit etc. So at the end, Asterisk will still guarantee that any DTMF it sends out is good. Only the "internal DTMF traffic" may be not normalized.

I believe this will simplify things a lot (can explain why). Also I can provide more details on how I'm going to approach if anyone interested.

Any thoughts?

Regards,
Dmitry Andrianov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080515/60941035/attachment.htm