Summary:	ASTERISK-11797: [patch] Add dialtone detection to chan_zap FXO devices
Reporter:	Steve Davies (one47)	Labels:
Date Opened:	2008-04-08 09:05:03	Date Closed:	2008-11-25 16:45:56.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) zap-waitfordialtone-1.2.25.patch ( 1) zap-waitfordialtone-1.4.19.patch ( 2) zap-waitfordialtone-bra-1.4.21.2.patch ( 3) zap-waitfordialtone-trunk.080409.patch ( 4) zap-waitfordialtone-trunk.080901.patch
Description:	In the UK, analogue lines can only be hung-up by the caller. If asterisk is not the caller, then when asterisk hangs up, it may well have no effect, but asterisk thinks the line is available! This can cause a "special" kind of glare - This feature was abused as a Phreaking tool for many years... British telecom insist that this behaviour cannot be disabled. The only workaround to this that I have been able to come up with is dialtone detection before dialing. I believe this will also be a popular feature for people with lines that do not offer an immediate dialtone. The attached patch adds a new DSP mode of "WAITFORDIALTONE" which will use the existing dialtone detection code - I have extended it to work for UK users (progmode=uk in zapata.conf) It also adds a new zapata.conf parameter of "waitfordialtone" which takes a numeric parameter to specify how long in ms to wait for a dialtone before giving up and failing the call. ****** ADDITIONAL INFORMATION ****** Apologies - This patch is against Asterisk 1.2.25-bristuffed. I believe that the changes are small and simple enough that it should be possible to apply it to 1.4.x or a clean 1.2.x checkout, and will endeavour to create a 1.4.x patch soon if somebody does not do it before me. This version of the code assumes that 10 DSP-sized samples of audio is enough to detect a dialtone. It would be useful in a future version to try and implement a method to try other lines in a Zaptel group if dialtone is not detected, or perhaps to flag a red-alarm on the channel temporarily.
Comments:	By: Steve Davies (one47) 2008-04-08 09:08:40 Note. I particularly dislike the way I have changed the UK frequency #defines to: #define HZ_350UK       0 #define HZ_400UK       1 #define HZ_440UK       2 I would welcome a suggestion for a better way to handle that! All other comments also welcome as C programming is not my strength... By: Tilghman Lesher (tilghman) 2008-04-08 09:17:46 1.2 is now in maintenance, which means that it gets security fixes only.  Since this is a new feature, it is a candidate for inclusion only in trunk, not in the released 1.4 branch. You'll need to update this patch for trunk. By: Steve Davies (one47) 2008-04-08 09:49:10 Thanks, noted. I'll aim for a patch to trunk. A patch to 1.4.x will not hurt though for those not ready to jump into 1.6.x territory :) By: Jason Parker (jparker) 2008-04-08 10:25:40 I think a 1.4 patch would be welcome by the community (though as Tilghman said, not appropriate for committal), if you would be willing to provide one. By: Steve Davies (one47) 2008-04-09 05:31:55 I have uploaded COMPLETELY UNTESTED 1.4.x and trunk versions of this patch. My 1.4.x test environment is currently out of operation, so I cannot even compile test them and they come with no warranty! By: snuffy (snuffy) 2008-04-09 07:41:50 Have only small comment, for trunk asterisk time functions are availible which means you could call ast_tvnow() instead of using gettimeofday() directly By: Steve Davies (one47) 2008-04-16 06:41:42 snuffy - Thanks for the pointer (no pun intended) That is such a small change I will not upload new patches yet. Feedback from anyone who tries this is welcome, good bad or indifferent. Particularly from anyone using the 1.4 or trunk patches - If they do not work, I will try to build a test rig for them. By: snuffy (snuffy) 2008-08-22 09:21:28 Since there is no chan_zap in 1.4/1.6/trunk anymore in the upcoming release could you redo the patch for chan_dahdi ? By: Steve Davies (one47) 2008-09-01 06:26:30 I'll look at what needs changing in the trunk patch to allow it to apply to chan_dahdi. By: Steve Davies (one47) 2008-09-01 07:22:56 Okay, I just uploaded an updated patch for the latest (chan_dahdi) based trunk. I do not have a test environment to compile this, (and am still jet-lagged after a 2 week vacation) so am uploading it blindly for someone to test rather than sitting on it for any longer. Feedback welcome. Thx. Steve By: fleed (fleed) 2008-09-19 09:46:58 This is brilliant, I've been waiting for this patch for a while now, so I can get dialing to work correctly on my sluggish-dialtone line. I've had to make a slight change to it so that it would work with the type of dialtone we use here in Brazil. It is 425Hz for dialtone and the same 425Hz for ringing, though interrupted. So I added DSP_TONE_STATE_RINGING to the trigger, with its own count. The default count of 10 chunks seems to be working okay so far. I also added one line so that the dialtone waiting time is displayed in 'zap show channel '. Thanks a lot! By: Leif Madsen (lmadsen) 2008-11-20 16:11:34.000-0600 Pinging this issue. Anything we need to do to move this forward for commital? I don't want it to sit if it isn't appropriate to go in, and if it is, we should get it in! :) By: Digium Subversion (svnbot) 2008-11-25 16:45:54.000-0600 Repository: asterisk Revision: 159317 U   trunk/CHANGES U   trunk/channels/chan_dahdi.c U   trunk/configs/chan_dahdi.conf.sample U   trunk/include/asterisk/dsp.h U   trunk/main/dsp.c ------------------------------------------------------------------------ r159317 | tilghman | 2008-11-25 16:45:54 -0600 (Tue, 25 Nov 2008) | 9 lines Add an option, waitfordialtone, for UK analog lines which do not end a call until the originating line hangs up. (closes issue ASTERISK-11797) Reported by: one47 Patches:       zap-waitfordialtone-trunk.080901.patch uploaded by one47 (license 23)       zap-waitfordialtone-bra-1.4.21.2.patch uploaded by fleed (license 463) Tested by: fleed ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=159317