[asterisk-dev] DTMF emulation

[Dmitry Andrianov]

Hi,
This question was initially directed to Russell but since he advised to use -dev list, I'm going to explain things first to who unaware.

The _ast_read of channel.c does post-processing for DTMF frames. What it does basically is:

1.       Ensures there is a proper gap between digits

2.       Ensures that every digit has at least minimal duration

3.       It emulates DTMF_BEGIN frames to make proper pair when DTMF_END arrives without preceding DTMF_BEGIN

Everything would be perfect if AST_FLAG_END_DTMF_ONLY flag did not exist. The flag indicates that "end user" of _ast_read is not interested in BEGIN frames. It is used in three situations I'm aware of:

1.       When Asterisk reads digits (ast_waitfordigit_full)

2.       When channel is being autoserviced (that happens much more frequently than you could anticipate!).

3.       When channel is bridged to a channel which does not need BEGIN frames - that is SIP channel with dtmfmode=info

Since flags may be turned on and off quite frequently (even when in the middle of emulated digit), it affects the process of emulation. Things made worse because when autoservice ends, END frames read by autoservice are feed back into channel queue and participate in the "emulation" process again when next dequeued by the ast_read. As result, the emulation code is somewhat cumbersome and prone to errors (as you seen in recent bugs like http://bugs.digium.com/view.php?id=11740 or http://bugs.digium.com/view.php?id=11911)

So the QUESTION: why doing this kind of stuff in the ast_read at all? Most internals of the Asterisk AFAIK do not care about BEGIN frames nor about digits being properly separated in time. Proper BEGIN/END pairs may be important for channel drivers - so why not doing DTMF normalization in the ast_write instead? In ast_write you would not have situations where AST_FLAG_END_DTMF_ONLY flag changes on the fly and I believe things would be MUCH simpler.

Regards,
Dmitry Andrianov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080219/cc1f8925/attachment-0001.htm