Summary:	ASTERISK-09343: Incoming DTMF signal plays continuously
Reporter:	Mark MacVicar (mmacvicar)	Labels:
Date Opened:	2007-04-27 18:28:34	Date Closed:	2008-01-14 12:31:05.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) relevant_extensions.conf ( 1) sip_show_peer_vitel-outbound.txt ( 2) sip.conf
Description:	Incoming DTMF signal repeats forever If someone presses keys in rapid succcession a tone plays continuously as if they were holding the key down. Reproducible Steps: 1. establish a call between asterisk phone system and outside caller 2. have the outside caller press 1 rapidly (about 10 times) A continuous tone is produced on the asterisk phone system. ****** ADDITIONAL INFORMATION ****** "sip debug" did not report any messages when this problem occurred. This issue is much less severe in 1.4.3, in prior versions you only had to press a key once to get this behavior. I prior versions when someone pressed a key (accidentally or otherwise) the tone played continuously as if they were holding the key down, the outside party wouldn't hear the tone, however the party using asterisk wouldn't be able to hear anything but the tone. To trigger this issue 1.4.3 you have to press a key twice rapidly and even then the problem only occurs maybe 50% of the time. I think this issue maybe triggering another issue. When incoming callers dial an extension through our asterisk menu about half the time no incoming sound can be heard, possibly due to the DTMF tone. The Asterisk console messages haven't shed any light on this issue, so any advice about how to diagnose this issue would be appreciated.
Comments:	By: Russell Bryant (russell) 2007-04-29 00:36:00 I'm fairly certain that I just fixed this yesterday.  The fix is in Asterisk 1.4.4.  Please upgrade, and if it is not fixed for you, please re-open this bug and let me know! Thanks! By: Mark MacVicar (mmacvicar) 2007-04-30 15:37:47 I just installed 1.4.4 and was able to reproduce the issue several times (by pressing any numpad key twice in rapid succession).  The issue may have become slightly more difficult to reproduce as I averaged about 4 attempts (25%) before reproducing it. I wasn't as thorough last time I tried but it seemed like I averaged about 2 attempts to reproduce the issue. By: dea (dea) 2007-04-30 23:25:16 Have you tried shouting at it?  I'm only half kidding... The new code to enforce DTMF duration wants to see a voice frame before clearing the emulate DTMF flag.  Chan_skinny is major, big time broken by the assumption that you will get voice frames between DTMF, and I think other situations might fall into the same pit. To fix up chan_skinny I added ast_clear_flag(chan, AST_FLAG_EMULATE_DTMF) in the AST_FRAME_DTMF_BEGIN case.  I am pretty sure it is not enough, since it is completely ignorant of when the previous DTMF frame set AST_FLAG_EMULATE_DTMF. Before that change I also noted spotty (not reliable) DTMF detection on a SIP endpoint I use in testing.  Since that both my skinny and SIP endpoints have had reliable DTMF (but with possibly too short a duration) By: Russell Bryant (russell) 2007-05-01 11:36:03 I can see from your configuration that you are using SIP for the outbound side of the call.  What type of phone are you using on the internal side?  Also, can you show the relevant parts of the dialplan that get executed when you reproduce this problem?  Also, can you look at "sip show peer vitelity-outbound" and tell me what DTMF mode you are using? By: Mark MacVicar (mmacvicar) 2007-05-01 12:40:13 We're using Astra Telecom 480e telephones. I've attached the output from "sip show peer vitel-outbound". I've also attached the relevant sections of extensions.conf. I can get the problem to occur when dialing out or in. Dialing out uses the "outbound" and "default" dial plans. Dialing in using the "inbound" and "MainMenu" dial plans, and dialing any of our extensions (e.g., 107). By: Mark MacVicar (mmacvicar) 2007-05-01 12:43:49 Sorry the DTMF mode we are using is just the default rfc2833 By: Russell Bryant (russell) 2007-05-01 13:36:32 What do you have your analog phones hooked up to?  I have been trying to reproduce it with an analog phone hooked up to a TDM400 card but have been unable to do so. By: Mark MacVicar (mmacvicar) 2007-05-01 14:17:58 We're using TDM400 cards also. If the outside caller press "11" quickly the problem happens about 25% of the time (sometimes it's easier to reproduce, sometimes it's harder). Here's our complete wiring path in case it's helpful. 1. Astra Telecom 480e, connected to 2. Internal office wiring, wired to 3. two TDM400P cards in our Asterisk server (an old PIII 733mhz, running Linux 2.4), connected to 4. Linksys router 5. DSL modem 6. VOIP provider Vitelity.net Let me know if there is any other info I can provide. By: Russell Bryant (russell) 2007-05-01 15:46:57 I just had another idea, can you try setting "rfc2833compensate=yes" in the vitelity-outbound section of sip.conf? By: Mark MacVicar (mmacvicar) 2007-05-01 16:27:33 adding rfc2833compensate=yes to vitel-outbound fixed the problem when dialing out. I've added it to general so that the problem wont occur on incoming or outgoing calls. Thank you. In interesting side note with rfc2833compensate=yes; When an outside caller calls in and presses a key, a beep is heard. When I call out to an outside caller, and the outside caller presses a key, the DTMF sounds like it is generating a double beep, two beeps are heard. I haven't noticed any problem with this, just wanted to note it. By: Russell Bryant (russell) 2007-05-01 17:29:37 I'm glad that your problem is now resolved! Now, regarding the issue you noted, I am aware of it.  I believe the issue has to do with translating between inband DTMF and RFC2833.  I think what you are hearing is the original inband DTMF that the vitelity servers detected and then sent DTMF via RFC2833, and also the sound created by your phone to indicate that it received rfc2833 DTMF.  I'm still working on this one ... Thanks!