Summary:	ASTERISK-08069: SendDTMF() through IAX channel transmits only first digit
Reporter:	Stephen Bosch (rhombus)	Labels:
Date Opened:	2006-11-05 13:44:20.000-0600	Date Closed:	2006-11-16 13:41:59.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk.dtmf.txt ( 1) asterisk.sip.dtmf.txt ( 2) asterisk.sip-iax.debug.dtmf.txt ( 3) asterisk.sip-sip.debug.dtmf.txt ( 4) messages ( 5) sip.conf
Description:	A macro contains these lines: exten => s,1,Wait(0.5) exten => s,n,SendDTMF(9531290) exten => s,n,Wait(1.0) exten => s,n,Set(MACRO_RESULT=CONTINUE) To test I direct the call to a live extension dialed through an IAX channel just to hear what's happening -- what actually happens is that only the 9 is sent, and it sounds as though someone is leaning on the button for about a second. Even if I rewrite it like this: exten => s,1,Wait(0.5) exten => s,n,SendDTMF(9) exten => s,n,SendDTMF(5) exten => s,n,SendDTMF(3) exten => s,n,Wait(1.0) exten => s,n,Set(MACRO_RESULT=CONTINUE) I get the same behaviour -- someone "leaning" on the 9, and none of the other digits. If I change the macro section to read like so: [macro-page] exten => s,1,Wait(1) exten => s,n,SendDTMF(2) exten => s,n,Wait(10) exten => s,n,SendDTMF(6) exten => s,n,Wait(10) exten => s,n,Set(MACRO_RESULT=CONTINUE) the called party hears the '2' for about 1.5 seconds, followed by a 10 second pause, followed by the '6' for three seconds. This is the current configuration: [macro-page] exten => s,1,Wait(1) exten => s,n,SendDTMF(234|100) exten => s,n,Wait(1) exten => s,n,SendDTMF(6|250) exten => s,n,Wait(1) exten => s,n,SendDTMF(1) exten => s,n,Wait(1) exten => s,n,SendDTMF(3) exten => s,n,Wait(1) exten => s,n,SendDTMF(6) exten => s,n,Wait(10) exten => s,n,Set(MACRO_RESULT=CONTINUE) The called party hears a long "2" (about 1.5 - 2.0 seconds) then a very brief "6", then a "1" for 3 seconds. ****** ADDITIONAL INFORMATION ****** The console debugging output is attached.
Comments:	By: jmls (jmls) 2006-11-06 05:03:12.000-0600 what happens if you dial through a SIP channel ? By: Stephen Bosch (rhombus) 2006-11-06 10:10:25.000-0600 Right now, this is how the calls flow: origin                       destination SIP extension ---------->    IAX channel I presume you want me to test: origin SIP extension ---------->    SIP channel correct? By: jmls (jmls) 2006-11-06 10:13:02.000-0600 yes please. thanks. By: Joshua C. Colp (jcolp) 2006-11-06 10:14:13.000-0600 An iax2 debug would also be helpful for the IAX2 test. Thanks. By: Stephen Bosch (rhombus) 2006-11-06 10:27:51.000-0600 I have reconfigured the system to dial another SIP extension before executing the macro. The console output is attached as 'asterisk.sip.dtmf.txt'. In this case I hear no digits on the receiving end (which makes sense, because my SIP extensions use out-of-band DTMF). Do you want me to try to change the setting to use in-band DTMF? By: Stephen Bosch (rhombus) 2006-11-06 10:44:46.000-0600 Okay -- I have learned the hard way that changes to debug settings don't always apply unless you restart Asterisk. I've done another IAX channel test with more complete debug information. I've attached this as asterisk.sip-iax.debug.dtmf.txt I'll follow up with a SIP test also. How do I obtain an IAX debug? By: Stephen Bosch (rhombus) 2006-11-06 11:01:03.000-0600 After restarting Asterisk I did another SIP test. The called party is 'stephen', and has dtmfmode=inband in the sip.conf file. The called party hears no tones at all. The calling party continues to hear ringing even after the called party has picked up the phone. The console debug output is attached as asterisk.sip-sip.debug.dtmf.txt By: Joshua C. Colp (jcolp) 2006-11-06 11:08:47.000-0600 To do an iax2 debug you just type "iax2 debug" on the CLI and do your calling, the DTMF should show up as frames being sent to the remote server. By: Stephen Bosch (rhombus) 2006-11-06 11:21:50.000-0600 After doing 'iax2 debug' and performing another test, I have attached the messages file. By: Stephen Bosch (rhombus) 2006-11-07 13:13:35.000-0600 With IAX2, the problem is present; with SIP, no DTMF is heard at all, even with dtmfmode=inband. What can I do to help find a resolution to the issue, given that I am not a programmer? This capability is vital; I don't know how I'm going to build a wireless pager application without it. By: Joshua C. Colp (jcolp) 2006-11-07 13:20:57.000-0600 For the IAX2 debug: DTMF is clearly being sent to the other side properly, so it might be a case of generation on the other side. For the SIP inband: Depending on the configuration the remote side will "mute" the DTMF and generate it. Have you tried using RFC2833 for the SIP portion? By: Stephen Bosch (rhombus) 2006-11-07 19:05:36.000-0600 Yes, I have tried with rfc2833 explicitly set for SIP extensions. When I point the macro to a SIP extension, the called party hears no tones at all and the calling party continues to hear ringing even after the called party has picked up the phone. When I point the macro to an IAX channel, I get the same long, initial tone and many of the subsequent tones are not heard at all. (In other words, the same behaviour). The provider suggested that it had something to do with the SendDTMF() timeout settings, but I have changed those and it makes no difference. Other than that, they claim it is not their problem. Who was responsible for writing the SendDTMF() code? Perhaps the original developer or the current maintainer could shed some light on the problem? By: Stephen Bosch (rhombus) 2006-11-07 19:09:52.000-0600 Even assuming there is nothing wrong with SendDTMF(), given that the provider is an IAX provider running Asterisk, that still leaves us with the question of how Asterisk must be configured in order to make this work. By: Stephen Bosch (rhombus) 2006-11-07 19:20:17.000-0600 I'm convinced this is a bug. I just changed my macro to read like so: [macro-page] exten => s,1,Wait(1) exten => s,n,SendDTMF(23441212|2000) exten => s,n,Set(MACRO_RESULT=CONTINUE) This is the longest timeout I have tried so far. Now I actually hear (some) of the other digits: I hear '2' for two seconds, then a '3' for 1.5 seconds interrupted by a 4 for about 2 - 3 seconds, then a very brief pause of perhaps 250 ms, then a very long '1' (about 4 seconds). Something is definitely screwy, if not with this function, then elsewhere in Asterisk. By: Joshua C. Colp (jcolp) 2006-11-09 22:01:16.000-0600 Time for a DTMF lesson: In pre-1.4 Asterisk installations DTMF is represented in one way, just as a simple "this key was pressed". It does not tell how long it was pressed for. This is what gets conveyed over IAX2, and the remote side has to send on the DTMF information or generate it for an acceptable length. For RFC2833 this is similar, the DTMF is blasted out all at once and received on the remote Asterisk as a single DTMF event, which it then has to send on as out of band or generate it for an acceptable length. You have no say in the actual length. Can you describe the full call flow in a diagram including the remote side? ie: My Asterisk (IAX2) -> Provider (PRI) -> PSTN This would give me a better understanding of where the issue could be. By: Stephen Bosch (rhombus) 2006-11-10 10:17:10.000-0600 Thanks for the DTMF lesson. The call flow is more or less as you describe, though *exactly* what's on the provider end is opaque to me as they avoid sharing that information. Local Asterisk --> IAX2 --> IAX service provider --> [FOG - maybe PRI?] --> PSTN I will ask. I don't know how forthcoming they'll be. Your explanation strongly suggests this is a provider side problem, although it is a concern to me that I don't hear DTMF on internal SIP extensions either --  but perhaps that's a different issue and a red herring. What's important to me is getting the DTMF tones -- all of them -- out on to the PSTN. By: Stephen Bosch (rhombus) 2006-11-10 10:44:47.000-0600 Has this patch for this bug been applied to 1.2.13? Someone on the mailing list suggests it hasn't: http://bugs.digium.com/view.php?id=5970 By: Serge Vecher (serge-v) 2006-11-15 11:06:28.000-0600 5970 is closed because the dtmf issues were solved by adding VLDTMF functionality to 1.4/trunk. Due to extensiveness of changes, those patches were not committed to 1.2 branch. By: Joshua C. Colp (jcolp) 2006-11-16 13:41:58.000-0600 I think we can safely say that we've proven it enough that DTMF is being conveyed correctly to the remote side and there's nothing wrong with your stuff. If you still feel that it is your side and want to try to track it down more, feel free to reopen this bug. Peace and good luck!