[Home]

Summary:ASTERISK-19917: When WaitExten is called immediately on a new SIP call - DTMF fails to be detected with the RFC2833 and In-band methods, but succeeds with SIP INFO
Reporter:Jackmcbarn (jackmcbarn)Labels:
Date Opened:2012-05-27 16:23:44Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:PBX/General
Versions:SVN 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Ubuntu Server 12.04 LTS AMD64, Asterisk 10 SVN , multiple SIP phones by different manufacturersAttachments:( 0) debuglog
Description:When calling WaitExten immediately after answering a call, no DTMF is ever read. For DTMF to be read, a Wait() instruction or similar must happen first. For example:

[waitexten-test]
exten => 3000,1,Answer()        ; Doesn't work
       same => n,WaitExten(10)

exten => 3001,1,Wait(0.01)      ; Doesn't work
       same => n,Answer()
       same => n,WaitExten(10)

exten => 3002,1,Wait(0.02)      ; Works
       same => n,Answer()
       same => n,WaitExten(10)

exten => 3003,1,Answer(20)      ; Doesn't work
       same => n,WaitExten(10)

exten => 3004,1,Answer()        ; Doesn't work
       same => n,Wait(0.02)
       same => n,WaitExten(10)

exten => 3005,1,Answer()        ; Works
       same => n,Wait(0.03)
       same => n,WaitExten(10)

Only extensions 3002 and 3005 above allow DTMF dialing. This happens whether RTP or in-band DTMF signaling is used, but not when SIP INFO DTMF signaling is used. DTMF begin and end messages are visible in the console during calls that work, but not calls that do not work. I have been able to reproduce this bug 100% of the time when using the failing extensions above.

[16:57] <jackmcbarn> WaitExten isn't working if i use it immediately when a call begins. ive ran several tests on this and detailed my results at http://pastebin.com/YXZtwY8i
[17:14] <[TK]D-Fender> jackmcbarn: playback(silence/2) and then show us your configs and the actual call attempt.
[17:19] <jackmcbarn> Playback(silence/2) makes it work
[17:19] <jackmcbarn> but so does a Wait(0.03) before or after answering
[17:24] <[TK]D-Fender> jackmcbarn: RTp setup may take a second or two dependsing...
[17:27] <jackmcbarn> if i call WaitExten immediately, no DTMF ever reads correctly, no matter how long i wait to send it
[17:36] <jackmcbarn> when i set my phone to SIP INFO for dtmf, it works fine with all of them
[17:37] <[TK]D-Fender> because that is SIP, not RTP
[17:38] <[TK]D-Fender> SIP is used to negotiate RTP, but the SIP part is already accepted
[17:39] <jackmcbarn> so the bug happens when i call WaitExten before RTP is set up and the DTMF comes over RTP
[17:39] <[TK]D-Fender> that'd ddo it
Comments:By: Rusty Newton (rnewton) 2012-05-30 15:32:05.610-0500

Please provide a sanitized sip.conf and rtp.conf. Also if possible, if you or someone else can verify this happens in trunk and 1.8.x would help us out.
By: Jackmcbarn (jackmcbarn) 2012-06-01 19:08:54.518-0500

Unfortunately, I can't currently test on other versions.

rtp.conf:

[general]
rtpstart=10000
rtpend=20000

sip.conf:

[general]
context=default                 ; Default context for incoming calls
allowguest=no                  ; Allow or reject guest calls (default is yes)
allowoverlap=no                 ; Disable overlap dialing support. (Default is yes)
allowtransfer=yes               ; Disable all transfers (unless enabled in peers or users)
udpbindaddr=::             ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
tcpenable=no                    ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=::             ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
transport=udp                   ; Set the default transports.  The order determines the primary default transport.
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls

[redacted]
type=friend
secret=redacted
context=internal
description=Redacted
host=dynamic
directmedia=no
dtmfmode=rfc2833
By: Jackmcbarn (jackmcbarn) 2012-06-01 19:13:10.998-0500

I've done some more testing and have found that the wait times may need to be slightly increased for it to work consistently in extensions 3002 and 3005.
By: Matt Jordan (mjordan) 2012-06-04 08:08:33.023-0500

This is probably due to the RTP stream not being fully set up when DTMF is relayed.  This can occur when the RTP stream has 'strictrtp' enabled, and the system is still in probation mode.  A DEBUG log would confirm this; alternatively, you could try setting strictrtp=no in your rtp.conf to see if that helps.
By: Jackmcbarn (jackmcbarn) 2012-06-06 18:15:25.468-0500

I used extension 2000 at the beginning of the call here, which is identical to 3000 I posted. This unsuccessful log is with strictrtp off and attempted to use rfc2833 for DTMF.

[Edit by Rusty Newton - debug removed - reporter attached to issue]

At this point, I dialed the new extension and no log messages were received. The next log message did not occur until timeout.
By: Matt Jordan (mjordan) 2012-06-08 09:32:20.945-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please do not paste log statements directly into comments.  Please generate a DEBUG log using the information above and attach it as a file to this issue.
By: Jackmcbarn (jackmcbarn) 2012-06-17 10:38:49.212-0500

Taken with all logging options enabled, SIP debugging enabled, and debug and verbose at 15.
By: Jackmcbarn (jackmcbarn) 2012-06-17 10:39:16.006-0500

The requested log is attached.
By: Olle Johansson (oej) 2013-09-05 04:56:50.148-0500

Any progress on this?