I’ve been looking for information about the dtmf emulation on *, haven’t been able to find any usefull info. Maybe I haven’t looked hard enough but google hasn’t delivered.
In my * dialplan I make use of the Read command to be able to get an phonenumber given by a dialer.
When an phonenumber consists of 15 numbers it takes 11 seconds for * to proces the entered dtmf codes. When I enable the dtmf logging you can see that most/all off that time is taken by the dtmf emulation.
I my case I dont need the emulation, I think. Cause in the logging you can see that * registers the correct number and then starts the emulation.
Is there any way to disable the dtmf emulation while still being able to get the entered dtmf codes?
I think it may have more to do with using read. I use background to play a file and then Exten => _X. It may seem a bit backwards but you have more control that way (in my opinion any way ).
Thanks for the answer Dovid, after your remark I tried it with Background and with WaitExten.
In both cases the dtmf is slow again, there is no emulation but still slow, here is some logging;
[2009-09-04 13:54:36] DTMF[21923]: channel.c:2706 __ast_read: DTMF end ‘0’ received on DAHDI/1-1, duration 0 ms
[2009-09-04 13:54:36] DTMF[21923]: channel.c:2751 __ast_read: DTMF end accepted without begin ‘0’ on DAHDI/1-1
[2009-09-04 13:54:36] DTMF[21923]: channel.c:2762 __ast_read: DTMF end passthrough ‘0’ on DAHDI/1-1
[2009-09-04 13:54:37] DTMF[21923]: channel.c:2706 __ast_read: DTMF end ‘0’ received on DAHDI/1-1, duration 0 ms
[2009-09-04 13:54:37] DTMF[21923]: channel.c:2751 __ast_read: DTMF end accepted without begin ‘0’ on DAHDI/1-1
[2009-09-04 13:54:37] DTMF[21923]: channel.c:2762 __ast_read: DTMF end passthrough ‘0’ on DAHDI/1-1
[2009-09-04 13:54:38] DTMF[21923]: channel.c:2706 __ast_read: DTMF end ‘3’ received on DAHDI/1-1, duration 0 ms
[2009-09-04 13:54:38] DTMF[21923]: channel.c:2751 __ast_read: DTMF end accepted without begin ‘3’ on DAHDI/1-1
[2009-09-04 13:54:38] DTMF[21923]: channel.c:2762 __ast_read: DTMF end passthrough ‘3’ on DAHDI/1-1
[2009-09-04 13:54:39] DTMF[21923]: channel.c:2706 __ast_read: DTMF end ‘1’ received on DAHDI/1-1, duration 0 ms
[2009-09-04 13:54:39] DTMF[21923]: channel.c:2751 __ast_read: DTMF end accepted without begin ‘1’ on DAHDI/1-1
[2009-09-04 13:54:39] DTMF[21923]: channel.c:2762 __ast_read: DTMF end passthrough ‘1’ on DAHDI/1-1
[2009-09-04 13:54:40] DTMF[21923]: channel.c:2706 __ast_read: DTMF end ‘6’ received on DAHDI/1-1, duration 0 ms
[2009-09-04 13:54:40] DTMF[21923]: channel.c:2751 __ast_read: DTMF end accepted without begin ‘6’ on DAHDI/1-1
[2009-09-04 13:54:40] DTMF[21923]: channel.c:2762 __ast_read: DTMF end passthrough ‘6’ on DAHDI/1-1
[2009-09-04 13:54:41] DTMF[21923]: channel.c:2706 __ast_read: DTMF end ‘4’ received on DAHDI/1-1, duration 0 ms
[2009-09-04 13:54:41] DTMF[21923]: channel.c:2751 __ast_read: DTMF end accepted without begin ‘4’ on DAHDI/1-1
[2009-09-04 13:54:41] DTMF[21923]: channel.c:2762 __ast_read: DTMF end passthrough ‘4’ on DAHDI/1-1
It gives me one digit a second, I just cant get my head around it why it takes so long…
I’ve been looking in the channel.c, but I’m not an C programmer…
Gj,
How are you testing this ? Are you testing with an external phone number (like from an ITSP) ? Trying creating an internal extension and see if you get the same result.
I’ve been testing with an incomming E1 line. I will test with an internal extension.
I have been able to to get the time down to 6 seconds for 13 digits.
Have recompiled asterisk with the changed minimum dtmf duration and the minimum dtmf gap in the channel.c . But when you take in consideration that the max dtmf speed is 10 digits a second…
am also having this same issue, tried compiling asterisk 1.4 through to 11.3,
still slow DTMF interpretation.
logs demonstrate that its definately asterisk that is slowing this process down.
i noticed when i dialled DTMF via a SIP phone, DTMF was very fast,
i assume because its not inband, therefore asterisk doesnt need to
convert ‘tones to digits’, so to speak.
does anyone know more about this process? unfortunately, its timing critical.
).