Summary:	ASTERISK-03403: [request] don't quelch dtmf when bridging between two inband methods.
Reporter:	linde (linde)	Labels:
Date Opened:	2005-01-31 18:22:43.000-0600	Date Closed:	2011-06-07 14:10:18
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	dtmf_detect is called "in dsp.c" with digitmode bits masked only allowing "DSP_DIGIMODE_RELAXDTMF" to be passed. This blocks the bit "DSP_DIGITMODE_NOQUELCH" from being passed. Not that it is anyway. But I think it SHOULD be passed when running with g.711 and inband or at least there should be an option to allow digitmode bits to be set on a channel basis. Call from dsp.c note the mask of dsp->digitmode res = dtmf_detect(&dsp->td.dtmf, s, len, dsp->digitmode & DSP_DIGITMODE_RELAXDTMF, writeback, dsp->features & DSP_FEATURE_FAX_DETECT); Without "DSP_DIGITMODE_NOQUELCH" being set all DTMF tones are blocked on detect by the dsp code. When running inband this results in a short and substandard DTMF tone from ZAP channels most of the time.(If bridged via SIP) ****** ADDITIONAL INFORMATION ****** I can provide a Fix to allow this to function but the style of my code and location of the fix might not be as expected by the normal Asterisk staff. Its a very easy tweak depending on how you wish it to function: You can fix the mask call and then set NOSQUELCH in the chan code when running as INBAND. Or by default you can put it in NOSQUELCH and clear it when you set a codec that can't handle inband. IE: I would think it should follow inband in most cases. You might want to quelch on bridged channels  when in conference mode. BTW. I can file a disclaimer if you want my fix. But I have not yet since I have not provided anything other than the BUG :)
Comments:	By: linde (linde) 2005-01-31 20:03:58.000-0600 Bug ASTERISK-3068 might be related to this as well. By: linde (linde) 2005-01-31 20:09:21.000-0600 Addl info: OS: Debian 2.6.10-1-k7 CPU: AMD Athlon T100p card to CAC ABII SIP I/F to MAXTNT V11.0 (PSTN Gateway) SIP Phones tested:  Cisco 9760, Polycom IP500, SPA-2000 Zap Phones tested: Std Analog, Sayson 380, 480 (adsi) By: linde (linde) 2005-01-31 21:29:06.000-0600 This is not the normal way of dealing with DTMF on any other SIP/PSTN gateways. IE: The normal way of dealing with inband DTMF is to NOT mute the tones. If you mute tones during inband dtmf it makes the * way incompatible with many existing PBX/telco systems. At the very least it should be a option to allow * to function in a more normal way or have a brokedtmf bit for existing methods edited on: 01-31-05 21:39 By: linde (linde) 2005-01-31 21:35:01.000-0600 One addl note: Currently there is no way to set DSP_DIGITMODE_NOQUELCH and have it work. It masks the bit off before it gets to the check. By: Olle Johansson (oej) 2005-02-13 13:13:25.000-0600 Still a problem? Find people on #asterisk-dev and discuss this or mail out to asterisk-dev to get response on your proposal. /Housekeeping By: jzeeff (jzeeff) 2005-02-21 07:56:16.000-0600 I've been seeing some behavior that could well be caused by this.  It's a serious problem. By: jzeeff (jzeeff) 2005-02-21 08:25:42.000-0600 If I'm reading it correctly, dtmf_detect() does check DSP_DIGITMODE_NOQUELCH and never looks at DSP_DIGITMODE_RELAXDTMF.  Sounds like a bug (passing things that are never looked at, always clearing things that are). I propose changing to no mask: res = dtmf_detect(&dsp->td.dtmf, s, len, dsp->digitmode, writeback, dsp->features & DSP_FEATURE_FAX_DETECT); By: Olle Johansson (oej) 2005-03-17 08:05:22.000-0600 Find markster on the #irc (his id is "kram") to discuss this. Or start with the bug marshals in #asterisk-bugs /Housekeeping By: Clod Patry (junky) 2005-05-01 14:31:58 Where are we with this bug? can we close this current one? thanks. By: Michael Jerris (mikej) 2005-05-23 23:37:42 No response from original poster in almost 4 months.  Closing this request until we have a patch. If you want result, add a bounty on the www.voip-info.org wiki. This bug report will be re-opened when we have a patch by the reporter or any bug marshal (available in #asterisk-bugs on the IRC channel). Thank you!