[Home]

Summary:ASTERISK-05536: When using the D option of the Dial command, DTMF tones not sent correctly
Reporter:Michael Gaudette (bluefox)Labels:
Date Opened:2005-11-09 16:15:16.000-0600Date Closed:2011-06-07 14:10:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) example.dump
Description:1) Using a provider with an IAX link
2) Dialing Dial(IAX2/user@provider/5555555555||D(12345))
3) Only the first DTMF (the "1") seems to be sent, not the rest


****** ADDITIONAL INFORMATION ******

Intrestingly, if I use "w" in the D command like this : D(1w1234)
the 1 is sent, the pauses seem to occur but the other tones are not sent
Comments:By: Russell Bryant (russell) 2005-11-10 18:08:40.000-0600

Please retry this with 1.2-RC1 with the patch from ASTERISK-5482 applied.
By: Russell Bryant (russell) 2005-11-10 18:27:17.000-0600

This is most likely due to the issues in ASTERISK-5482.  Please re-open if the problem is not fixed.  Thanks!
By: Michael Gaudette (bluefox) 2005-11-10 19:46:55.000-0600

Now it works "better" in that tones are sent, but the parentheses are causing some problems:

1) exten => 66,1,Dial(Zap/1,,D(1234))
missing closing paranthesis in string '1234)'

2) exten => 66,1,Dial(Zap/1,,D(1234)))
does send some tones (but not all it seems) and I get this msg:
Illegal DTMF character ')' in string. (0-9*#aAbBcCdD allowed)
By: Michael Gaudette (bluefox) 2005-11-10 19:51:35.000-0600

Just noticed that the DTMF tones are sent over Zap channels (but with the parenthesis error) but not over the IAX2 channel like my original bug stated. (only the first tone is sent, still)
By: Kevin P. Fleming (kpfleming) 2005-11-10 20:12:46.000-0600

OK, that's what we get for trying to over-optimize the source code. Sorry about that... it really is fixed in CVS HEAD now, I just tested it on my dev box.
By: Michael Gaudette (bluefox) 2005-11-11 08:57:07.000-0600

The parenthesis problem is fixed, thank you.  But again, only the first DTMF tone is sent.  

using
exten => 111,1,Dial,IAX2/user@provider/1231234567||D(12345)

1231234567 being my home phone, I only hear the first tone. When I use some company number I know, the PBX recognizes the first tone and switches menu accordingly, but nothing after that.
By: Kevin P. Fleming (kpfleming) 2005-11-11 11:17:53.000-0600

This is not a problem with app_dial, it's a problem with chan_iax2 that has been previously reported and remains unsolved. I'll close this bug, but it would be best if the older bug was found and updated instead.
By: Kevin P. Fleming (kpfleming) 2005-11-11 11:18:27.000-0600

OK, well, I'm wrong.. this _is_ the bug where this was reported. Never mind :-)
By: Kevin P. Fleming (kpfleming) 2005-11-11 11:25:13.000-0600

OK, I can't reproduce this problem here... I call from an Asterisk server to another over IAX2 and then to a Zap phone, including D(w1234) in the dial options, and I hear all four DTMF tones as expected.

Can you post the console log from your serve as the call is being placed and answered? We need to confirm that app_dial is trying to send the whole DTMF string.
By: Michael Gaudette (bluefox) 2005-11-11 11:30:06.000-0600

I can do better though, I can give you SIP access to my Asterisk if you want.

   -- Starting simple switch on 'Zap/1-1'
   -- Executing Dial("Zap/1-1", "IAX2/$USER@unlimitel/5143404711||D(12345)") in new stack
   -- Called $USER@unlimitel/5143404711
   -- Call accepted by 64.26.157.230 (format gsm)
   -- Format for call is gsm
   -- IAX2/unlimitel-6 is making progress passing it to Zap/1-1
   -- IAX2/unlimitel-6 answered Zap/1-1
   -- Sending DTMF '12345' to the called party.
   -- Hungup 'IAX2/unlimitel-6'
 == Spawn extension (internal, 68, 1) exited non-zero on 'Zap/1-1'
   -- Hungup 'Zap/1-1'
By: Kevin P. Fleming (kpfleming) 2005-11-11 11:33:16.000-0600

No, SIP access won't help, thanks anyway :-)

At this point you will need to use tcpdump to determine whether your Asterisk server is sending the DTMF frames to your provider; if it is, and the called party is not hearing them, then the fault is with your provider. If it is not, we need to figure out why they are not being sent.

Are you familiar with making a tcpdump capture of the IAX2 traffic? If not, find one of us on IRC and we'll help you.
By: Michael Gaudette (bluefox) 2005-11-11 11:50:09.000-0600

There you go, this is my dump, using a demo user on voipjet (both voipjet and unlimitel.ca have the same behavior).  Feel free to use it, there is a 0.25$ credit and I dont plan on using this passed this bug report.
By: Kevin P. Fleming (kpfleming) 2005-11-11 16:11:25.000-0600

Your packet trace clearly shows the digits '1', '2', '3', '4', and '5' being sent to the provider after the call gets answered. Asterisk is doing what you asked it to do :-)