[Home]

Summary:ASTERISK-21897: D option in Dial doesn't recognize "w" as a pause
Reporter:Sean Darcy (seandarcy)Labels:
Date Opened:2013-06-10 18:08:02Date Closed:2013-06-25 17:28:11
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Applications/app_dial
Versions:11.4.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Fedora 17Attachments:( 0) dtmf-sip-debug-clean
Description:The D option in the Dial command does not recognize 'w' as a pause:

Dial("DAHDI/1-1", "SIP/<>,,D(wwwwwww249#)") in new stack
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
   -- Called SIP/<>
   -- SIP/<>-00000063 answered DAHDI/1-1
   -- Sending DTMF 'wwwwwww249#' to the called party.

Interestingly, if you put other characters in the DTMF string, you get an error:

-- Sending DTMF 'pwwwwwww249#' to the called party.
[Jun 10 18:28:03] WARNING[20775][C-000000fc]: app.c:780 ast_dtmf_stream: Illegal DTMF character 'p' in string. (0-9*#aAbBcCdD allowed)

This appears to be a regression since it once worked:

ASTERISK-5536

http://forums.whirlpool.net.au/archive/609344
Comments:By: Michael L. Young (elguero) 2013-06-10 20:00:24.525-0500

What did the other side get?  Can you provide a trace?  Since it looks like the endpoint that should be receiving the DTMF is using SIP, can you provide a pcap?  Can you provide your dtmf settings?

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please provide more details to help us understand why you say the "w" is not being recognized as a pause when using the D option.

Thanks
By: Sean Darcy (seandarcy) 2013-06-10 20:57:02.164-0500

The endpoint is receiving the DTMf, but there's no pause, so it's lost. A w should be .5 sec. But the dtmf is sent immediately. I put 20 w's, still sent immediately.

Sending DTMF 'wwwwwww249#' to the called party

But that's not right. Asterisk should only send 249# to the called party. The 'w' s are metacharacters.

sean
By: Sean Darcy (seandarcy) 2013-06-10 21:00:52.089-0500

FYIW: dtmfmode=rfc2833
By: Michael L. Young (elguero) 2013-06-10 21:38:01.946-0500

Perhaps the message is a bit misleading.  The log message "Sending DTMF 'wwwwwww249#' to the called party" is accurate, though, and I feel beneficial to see.  At least you know that the 'wwwwwww249#' is being sent to the _function_ responsible for streaming DTMF.  That function will parse the string and pause when it sees the 'w'.

Can you attach a PCAP?  Not sure what you mean by "the endpoint is receiving the DTMF" and then say, "it's lost".  If it received it, how can it be lost?

I just tested this out on 11.3 and in trunk.  The pauses worked as intended.  Please attach full debug logs as well as a PCAP.

Thanks
By: Sean Darcy (seandarcy) 2013-06-11 09:46:29.644-0500

Some progress. I increased the number of w's. Now the called party gets something, but says it's invalid (if I send the tones by hand it works). And oddly, I get no audio for the wait period. I don't get the opening spiel about inserting the passcode regardless of how many w's. The first audio is about the invalid passcode.

Also, I never hear the dtmf tones. Is that expected?

I've attached the sip debug. Will do wireshark this afternoon.
By: Sean Darcy (seandarcy) 2013-06-11 09:48:04.679-0500

sip debug log.
By: Michael L. Young (elguero) 2013-06-11 10:24:12.245-0500

In looking at the debug log, I see that as soon as the call is answered, Asterisk sends the DTMF.  But, it appears that there is a re-invite involved.

So, I am thinking that we start to send audio to the first ip and then the re-invite occurs which changes the ip of were the audio is being sent, causing your dtmf not to work as you expect.

I am leaning towards a configuration issue.

Please look at "core show application Dial".

{noformat}
D([called][:calling[:progress]]): Send the specified DTMF strings
   *after* the called party has answered, but before the call gets bridged.
   The <called> DTMF string is sent to the called party, and the <calling>
   DTMF string is sent to the calling party.  Both arguments can be used
   alone.  If <progress> is specified, its DTMF is sent to the called party
   immediately after receiving a PROGRESS message.
   See SendDTMF for valid digits.
{noformat}
By: Sean Darcy (seandarcy) 2013-06-11 11:21:32.205-0500

Interesting. Tried D(::249#) but no joy. As far as I can tell, the DTMF is never sent. Is that because there's no PROGRESS message?
By: Sean Darcy (seandarcy) 2013-06-11 11:42:55.552-0500

Should we send the DTMF as soon as the call is answered? If the w's were honored then the dtmf tone would be sent over the called channel later, and would work regardless of any reinvites that have taken place.
By: Michael L. Young (elguero) 2013-06-11 11:56:47.781-0500

Well, I don't want this to turn into a support issue since this is not the proper place.  asterisk-users mailing list, irc or the forums are a better place.

I was pointing out why adding more pauses (w) perhaps was helping the other side to get some DTMF digits as you mentioned above since it helped.  Look at SendDTMF.  You might want W instead of w.
By: Sean Darcy (seandarcy) 2013-06-11 12:09:21.592-0500

I've used up to 30 w's . The opening spiel only takes 3-4 seconds. More w's do delay the first audio, but still doesn't send the correct dtmf. I've now tied it with 40, 20 seconds. No joy. Over PSTN, a 4 second puase does it.

Sure seems to me that the w's aren't honored.

BTW, W is an invalid character.

I'd be happy to send privately the actual number and passcode.
By: Michael L. Young (elguero) 2013-06-11 12:45:16.601-0500

Woops... looks like the W (one second pause) was added to trunk (future Asterisk 12).  Sorry about that.

Simple dialplan
{noformat}
exten => 555,1,NoOp(Testing D option in Dial)
same => n,Dial(SIP/9999999999@peer,,D(wwwwwwww259#))
same => n,Hangup
{noformat}

I set the number to my mobile phone.  Dialed this extension using a SIP softphone.  Answered the call on my mobile phone when it rang.  Counted 4 seconds and then heard digits.  I would say the 'w' is being honored.
By: Rusty Newton (rnewton) 2013-06-25 17:27:47.361-0500

This looks like a config issue. @Sean, you need to figure out exactly when you should be sending DTMF based on both whats happening with your SIP dialog (the reinvite that Michael mentioned) and any needs the far-end has. Often legacy equipment has some delay before accepting DTMF digits. It can be quite tricky, especially if you don't have any debug on the far end to see exactly what they are seeing.

Unfortunately this is not a bug report, so I'm going to close this out.

Fortunately, you have somewhere to start troubleshooting.

If you find something more like a bug, please feel free to contact a bug marshal on #asterisk-bugs.