Summary:	ASTERISK-17237: inband DTMF cannot be detected and trigger service execute when A and B both use u-law (the same codec)
Reporter:	aaa (shihchuan)	Labels:
Date Opened:	2011-01-13 05:04:49.000-0600	Date Closed:	2011-07-19 13:00:18
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) A.log ( 1) B.log ( 2) DIALPLAN ( 3) README
Description:	1. A and B both use the same codec (u-law, a-law). When A enter *96(transfer feature key), transfer service don't be executed but B hear dtmf tone. 2. If A and B use different codec.(A use u-law, B use a-law) When A enter *96(transfer feature key), transfer sevice is executed.
Comments:	By: David Woolley (davidw) 2011-01-13 05:35:49.000-0600 I think it almost certain that the channel technology affects this.  In particular, it may be erroneously doing an external bridge.  Assuming you are using SIP, I think you need to follow the rules for reporting SIP problems.  You also need to provide the dialplan, just in case the real problem is that the feature code is being erroneously detected when transfers are disabled. By: Leif Madsen (lmadsen) 2011-01-13 11:13:37.000-0600 I bet you don't have the 't' or 'T' flags enabled in Dial() which would make this a configuration problem. By: aaa (shihchuan) 2011-01-14 00:26:28.000-0600 Yes, I did have put 'tT' in Dial() in these 2 cases. The problem is that, when using the SAME codec in a conversation, the inband dtmf is not detected. I set debug level to 5 but no any debug messages about dtmf is displayed when using the same codec. However, if using DIFFERENT codec, debug message:'Got DTMF begin on channel (SIP/2112-00000027)' will be shown, which is correct. By: David Woolley (davidw) 2011-01-14 05:06:10.000-0600 You need to provide the SIP(?) debug output, so one can tell whether the problem is that the call is being erroneously externally bridged, and more generally, the nature of the bridge being created. More generally, it is generally better to include the actual debug output in a report, rather than a interpretation that it shows nothing. By: Nickilo ( ThinkroSystem) (nickilo) 2011-01-16 05:43:54.000-0600 I can confirm this bug exist. But at the moment i have two asterisk with the same binary, the same configuration files. On can reproduce the problem, the other not. I'm gonna try to understand the problem, give you a way to reproduce the problem and the debug output. I confirm also that using différent codecs "solves" the problem. By: Nickilo ( ThinkroSystem) (nickilo) 2011-01-17 17:10:26.000-0600 Hi, i just uploaded Bug_18611_case_1.zip You can find explanations and logs inside the zip file. I hope it can help, if you need anything else, just ask. Thank you ! By: Leif Madsen (lmadsen) 2011-01-19 10:46:22.000-0600 Please re-upload your data as text files attached to the issue and not as an archive file. By: Nickilo ( ThinkroSystem) (nickilo) 2011-01-19 10:58:40.000-0600 Done Imadsen, i've just uploaded README wich describe the test i have made. A.log and B.log contains logs files. By: Leif Madsen (lmadsen) 2011-01-19 14:49:27.000-0600 You're still missing the dialplan to be used to reproduce this issue. By: Nickilo ( ThinkroSystem) (nickilo) 2011-01-21 17:53:01.000-0600 The dialplan is uploaded as a separate file By: Nickilo ( ThinkroSystem) (nickilo) 2011-01-27 15:39:56.000-0600 I found that difference between the A and the B case is dtmf configuration of the sip client. If using pure in-band, asterisk is no more working. The bug still exist in version 1.8.2.3 By: David Woolley (davidw) 2011-01-28 05:11:59.000-0600 That sounds like a configuration error involving dtmfmode, rather than a bug. By: Nickilo ( ThinkroSystem) (nickilo) 2011-01-28 17:43:57.000-0600 In sip.conf i have dtmfmode = inband and no dtmf parameter in the phone configuration. By: Remi Quezada (remiq) 2011-02-11 09:59:45.000-0600 I am also experiencing this problem.  I am able to reproduce this in 1.6.1 and 1.6.2. By: Kinsey Moore (kmoore) 2011-06-29 17:23:32.472-0500 I have posted a fix for this issue here: https://reviewboard.asterisk.org/r/1302/ By: Kinsey Moore (kmoore) 2011-07-19 13:00:18.566-0500 fixed in 1.8, 1.10, and trunk