Summary:	ASTERISK-27033: chan_dahdi - dialtone_detect not working
Reporter:	Henry Moffett (drmoffet)	Labels:
Date Opened:	2017-06-06 00:04:00	Date Closed:	2017-06-08 11:44:30
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:	13.15.0	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-27044 Documentation: Indicate that dialtone_detect and waitfordialtone are influenced by progzone option.
Environment:	Linux Debian jessie 64 bits, Wildcard TDM410P PCI card with 1 FXO	Attachments:
Description:	Recently I bought Wildcard TDM410P PCI card with 1 FXO port in order to make and receive calls on PSTN analog line. I've been playing with it for few days, and I've noticed that two options in chan_dahdi.conf: dialtone_detect and waitfordialtone don't detect the dialtone at all. At least not the 425 Hz. If I set waitfordialtone, I cannot make an outgoing call. I'm using "loadzone=pl" in /etc/dahdi/system.conf, and "options wctdm24xxp opermode=POLAND" in /etc/modprobe.d/dahdi.conf.
Comments:	By: Asterisk Team (asteriskteam) 2017-06-06 00:04:01.505-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Richard Mudgett (rmudgett) 2017-06-06 10:51:15.505-0500 {noformat} ; On trunk interfaces (FXS) it can be useful to attempt to follow the progress ; of a call through RINGING, BUSY, and ANSWERING.   If turned on, call ; progress attempts to determine answer, busy, and ringing on phone lines. ; This feature is HIGHLY EXPERIMENTAL and can easily detect false answers, ; so don't count on it being very accurate. ; ; Few zones are supported at the time of this writing, but may be selected ; with "progzone". ; ; progzone also affects the pattern used for buzydetect (unless ; busypattern is set explicitly). The possible values are: ;   us (default) ;   ca (alias for 'us') ;   cr (Costa Rica) ;   br (Brazil, alias for 'cr') ;   uk ; ; This feature can also easily detect false hangups. The symptoms of this is ; being disconnected in the middle of a call for no reason. ; ;callprogress=yes ;progzone=uk {noformat} The {{progzone}} option in {{chan_dahdi.conf}} affects dialtone detection in chan_dahdi.  The only supported country that has a 425 Hz detection is Costa Rica and that is the only tone enabled for that country.  According to a quick lookup, Poland only uses a 425 Hz tone for its signaling so the Costa Rica setting should work. By: Henry Moffett (drmoffet) 2017-06-06 12:28:04.508-0500 Thank you for clarifying that. After applying *progzone=cr* I can make an outgoing call with *waitfordialtone* option enabled. As for the second option: *dialtone_detect*, it seems it still doesn't work. The test I'm doing goes like this: * Make a call from mobile phone to asterisk * When IP phone starts ringing, I disconnect the call on mobile phone * IP phone still rings for few seconds (until ringtimeout is reached I think) * When I answer the call on IP phone, I hear the dialtone (because the call is already ended) and the channel is not being hang up. I don't know if *dialtone_detect* must be used together with *callprogress=yes* but that doesn't change the effect. {code:title=chan_dahdi.conf|borderStyle=solid} [trunkgroups] [channels] signalling=auto language=pl progzone=cr usecallerid=no dialtone_detect=always waitfordialtone=1000 ringtimeout=4000 echocancel=yes echocancelwhenbridged=yes busydetect=yes busycount=3 rxgain=5.0 group=0 context=pstn-in channel => 1 {code} By: Richard Mudgett (rmudgett) 2017-06-06 13:44:15.359-0500 * I expect the dialtone you are hearing is from the IP phone itself to make a new call and not from the analog line.  Normal verbose and debug output will tell you if the analog line has been hung up. * The {{dialtone_detect}} option helps prevent a line from being stuck off-hook from stray rings or a caller hanging up before the call is answered. * Beware that setting {{dialtone_detect=always}} can cause a call to be dropped unexpectedly if it detects dialtone *during* your call.  Tone detection is not perfect as it is a compromise of several factors such as detection speed and the signal/noise ratio. * You probably shouldn't use the {{signaling=auto}} setting.  I usually have difficulty figuring out what signaling mode it is actually using.  Many options work differently depending upon what signaling mode is actually in effect. * This has turned into a support issue and not a bug report. We appreciate the difficulties you are facing, however this does not appear to be a bug report and your request or comments would be better served in a different forum. The Asterisk community provides support over IRC, mailing lists, and forums as described at http://asterisk.org/community. The Asterisk issue tracker is used specifically to track issues concerning bugs and documentation errors. Please see the Asterisk Issue Guidelines [1] for instruction on the intended use of the Asterisk issue tracker. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Henry Moffett (drmoffet) 2017-06-06 14:27:47.725-0500 The dialtone I hear is generated by the telecommunication company and not by the IP phone. I know this from LCD screen of the phone and the logs. I've set *dialtone_detect* to *always* for debug purposes only, and I know I shouldn't use it in production environment. *signaling=auto* is using the one in /etc/dahdi/system.conf which is *fxsks*. The audio quality of analog line I'm using is good. There are no clicks or any noise. After setting *progzone=cr*, *waitfordialtone* option started to work immediately with 100% accuracy. Yet  *dialtone_detect* option is not able to hung up the channel for 12 seconds of 425 Hz dialtone. That's why I think it might be buggy. Maybe it doesn't respect *progzone=cr* and is looking for US dialtone. Before reporting this bug I looked for help in asterisk cummunity forum, but no one replied. https://community.asterisk.org/t/dialtone-detect-not-working-in-dahdi/70913 If you think this is caused by misconfiguration or hardware, please feel free to close the issue. By: Richard Mudgett (rmudgett) 2017-06-06 16:53:13.005-0500 I think I see what is going on.  The Costa Rica setting doesn't actually declare that it detects dialtone.  It claims it is the ringback tone.  Cadence recognition isn't supported to distinguish between dialtone and ringback tones.  The reason {{waitfordialtone}} works is that it accepts either the dialtone or ringback dsp state to continue dialing.  The {{dialtone_detect}} option doesn't work because it only looks for the dialtone dsp state.  A more general tone and cadence *recognition* module is needed to support more countries for the chan_dahdi call progress options like is available to *generate* the call progress signals described in {{indications.conf}}.  I think the main reason it doesn't exist is because it isn't easy to do and chan_dahdi would be the only channel driver that would use it. I'm sorry but {{dialtone_detect}} isn't supported for the country you need. By: Henry Moffett (drmoffet) 2017-06-07 01:18:54.774-0500 So chan_dahdi is not able to distinguish dialtone from ringback tone if it has the same frequency, as I understand. And there's no simple modification in the code to make it work. I would suggest to indicate in documentation that *dialtone_detect* and *waitfordialtone* are influenced by *progzone* option. I think this issue can be closed. Thank you. By: Rusty Newton (rnewton) 2017-06-08 11:44:30.874-0500 Thanks for the feedback Henry. Closing this one out. I'll talk with Richard about the documentation need and we will get a new issue created if necessary. Thanks!