Summary:	ASTERISK-08651: stray DTMF (rfc2833) during conversations
Reporter:	Dan Moschuk (dnatural)	Labels:
Date Opened:	2007-01-23 10:03:16.000-0600	Date Closed:	2007-01-29 13:54:17.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 8898-rtp-debug.txt ( 1) 8898-rtp-debug-really.txt
Description:	During SIP calls at seemingly random points, a DTMF signal is delivered to one party of the conversation when no button was pressed. ****** ADDITIONAL INFORMATION ****** Possibly related to 8628 (the patch on file with that bug didn't work -- in fact it caused more issues with DTMF tones being delivered in triplicate (ie: voicemail pins came out 111222333444 instead of 1234).
Comments:	By: Joshua C. Colp (jcolp) 2007-01-23 10:05:40.000-0600 An rtp debug has to be included to see the DTMF packets. By: Dan Moschuk (dnatural) 2007-01-23 12:29:37.000-0600 Here you go.  According to our logs a 2 and an 8 were sent at 12:30:33. By: Joshua C. Colp (jcolp) 2007-01-23 17:15:17.000-0600 I don't understand... that shows DTMF coming into Asterisk via RFC2833 from 206.248.156.19, not Asterisk generating it unless Asterisk is running on 206.248.156.19. Can you elaborate a bit more? By: Dan Moschuk (dnatural) 2007-01-24 10:19:41.000-0600 There's a better example of it. Basically these are ghost DTMF tones.  Only one party hears them, and the other party did not initiate them.   I've eliminated the sip devices and our carrier.  Asterisk 1.2.13 doesn't seem to do this.  Asterisk 1.4{.0, svn} did. By: Joshua C. Colp (jcolp) 2007-01-24 10:27:06.000-0600 Now I'm even more confused... this bug was filed against 1.2 - so is the issue there, or does it just start at 1.4? DTMF between the two is quite different - also this latest debug still shows RFC2833 coming in properly, and then being sent out. By: Dan Moschuk (dnatural) 2007-01-24 12:20:36.000-0600 The bug manifests itself in 1.2-svn, 1.4.0 and 1.4-svn, but NOT in 1.2.13.   The problem isn't with the RFC2833 packets coming in incorrectly -- the fact that they are present at all is the actual mystery. By: Joshua C. Colp (jcolp) 2007-01-24 12:24:35.000-0600 Okay, maybe you are giving me the wrong rtp debug... I was looking for the one where the DTMF is being generated/sent from. The ones you provided are perfectly fine and doing as it should. By: Dan Moschuk (dnatural) 2007-01-24 13:31:47.000-0600 I'm not sure what other rtp debug I can send you.  The conundrum is where these tones are coming from.  I realize that it appears to be coming from one end of the conversation, but the other end claims to have pressed no button. [Jan 23 19:56:16] DTMF[23760]: SIP/sipguy-1-1136b1d0 : A An 'A' DTMF tone?  Since asterisks appear as '*' I'm not sure what this is.   Can regular phones do this?  This happens regardless of the sip device that claims to be initiating it.  I would just assume its our carrier but this happens with internal asterisk calls as well -- truly the only common thread I can find is asterisk 1.2-svn (and the other versions mentioned). Crazy. By: Joshua C. Colp (jcolp) 2007-01-24 13:37:34.000-0600 Yes, 'A' is a valid DTMF digit. And just because they didn't press DTMF doesn't mean it wasn't detected... if an inband DTMF detection is being done then the person may have tripped it via speaking. By: Dan Moschuk (dnatural) 2007-01-24 13:52:49.000-0600 This was the only thing I could up with too, but with dtmfmode=rfc2833 will this not turn off any DSP for DTMF tones?  Did the detection code change significantly after 1.2.13? By: Joshua C. Colp (jcolp) 2007-01-24 13:55:17.000-0600 No but it's the remote side that is sending the RFC2833 to your Asterisk... which then sends it to the phone... which then produces the tone. Asterisk is just doing it's job and sending on the received DTMF. Do you know what's happening over there? By: Dan Moschuk (dnatural) 2007-01-24 14:30:51.000-0600 I'm not entirely sure... both Linksys ATA and Aastra 9133s report the problem so I can reasonably deduce that it's likely not a device issue.  From my understand DTMF ABCD are reserved tones and not normally produced by regular phones.   Not to throw another monkey wrench into the chaos but it appears that more tones are being generated and passed through, but are *not* heard by the caller. By: Joshua C. Colp (jcolp) 2007-01-24 14:34:23.000-0600 Do they show up in rtp debug as RFC2833? If not then they are going in the audio stream and this just further proves that it's not Asterisk. By: Dan Moschuk (dnatural) 2007-01-24 14:51:52.000-0600 Yes they appear in the rtp debug output as well as the dtmf file from logger.conf... they are definitely being processed as part of the rtp stream By: Joshua C. Colp (jcolp) 2007-01-24 15:31:12.000-0600 Well from all that you've shown me Asterisk seems to be working fine and doing as it should - receiving DTMF and sending it... do you have any other info? if not I'm just going to close this out. By: Dan Moschuk (dnatural) 2007-01-24 16:40:45.000-0600 Can you give me a week to experiment with different builds and device options before closing this out?  If asterisk isn't at fault then I must have made an error somewhere in my initial process, which would mean one of the above reported facts isn't.  To be sure I'll need to gather more data. By: Joshua C. Colp (jcolp) 2007-01-24 16:43:14.000-0600 I shall assign this to me and wait. By: Dan Moschuk (dnatural) 2007-01-29 13:45:42.000-0600 Hi again!  Thanks for keeping it open while I tinkered.  This bug is very likely bogus.  Sorry to waste your time. By: Joshua C. Colp (jcolp) 2007-01-29 13:54:17.000-0600 Closed since the bug is bogus.