Summary:	ASTERISK-03723: Busydetect failure on unanswered calls
Reporter:	richard (richard)	Labels:
Date Opened:	2005-03-20 16:16:28.000-0600	Date Closed:	2011-06-07 14:10:06
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) zapata.conf.txt
Description:	A call is placed as follows: POTS -> Digium TDM FXO module - Asterisk - Digium FXS module -> Analog phone. 1).If the analog phone is left unanswered and the POTS party hangs up, about 50% of the time the FXO channel fails to hangup via Busydetect or runs on well over "busycount" value before hanging up. 2).If the FXS analog phone answers the call and it is left off hook, a hangup at the POTS end will successfully hangup the FXO channel via busydetect 100% of the time. Using ztmonitor -v to examine the FXO channel in 1) above, the RX indication shows busy/congestion tone from POTS after they hangup, peaking about 3/4 scale and the TX indication shows shows ringing tones from the unanswered FXS phone peaking at full scale. After a few seconds of this, the ringing tone on the TX side starts leaking into the RX side at a steadily increasing level, until after 5 seconds or so the the incoming busy tone is swamped and busy detect cannot function correctly. I am guessing this may be the echo canceller diverging or being overloaded by the ring tones. In case 2), as there is silence on the TX side, busy detect works perfectly as per the zapata.conf settings. The above occurs with rxgain and tx gain set to 0.0. If rxgain is increased to 3.0, which I would like to do to balance incoming POTS line loss, busydetect fails 100% of the time. Reducing txgain appears to have no effect and while reducing rxgain does improve busydetect hit rates (at a cost to already low incoming level), it is only improved because it delays the length of time taken for the TX ringtone leakage level to rise to saturation point. ****** ADDITIONAL INFORMATION ****** Tonezone in use is nz. Busy detect algorithms in use are BUSYDETECT+= -DBUSYDETECT_MARTIN and BUSYDETECT+= -DBUSYDETECT_COMPARE_TONE_AND_SILENCE Echo canceller in use ECHO_CAN_MARK2
Comments:	By: richard (richard) 2005-04-06 15:52:10 If I am right in assuming the FXO echo can is active in scenario 1 above, is there any real difficulty in changing it's behaviour such that after the initial echo train, coefficent updating is then inhibited until the called channel (FXS) answers? By: Mark Spencer (markster) 2005-04-11 00:35:45 Have you tried another echo can (e.g. MARK3)? By: richard (richard) 2005-04-11 02:43:56 I have not used it in this test, but will certainly give it a try. This is a production system and given that mec2 is the default and reading the list thead from when mec3 was introduced, I got the impression it is not as stable/effective as mec2. I note that by default in mec3, DO_BACKUP is disabled. Is there a reason why it is not active? By: richard (richard) 2005-04-23 20:52:58 Testing using MARK3, with and without DO_BACKUP shows no improvement. By: Clod Patry (junky) 2005-06-09 18:58:49 Any development here? If nothing, let's close that bug. /Housekeeping By: richard (richard) 2005-06-10 00:27:25 I've done my best and received no response, so hey, why not clean it up. Perhaps someone will write a better echo canceller some day. By: Michael Jerris (mikej) 2005-07-13 07:59:33 I know there were some echocan improvements in ASTERISK-2771.  Could you by chance try the new version from that bug to see if there is any improvement? By: richard (richard) 2005-07-13 14:35:20 Yes I have tried the 2820 changes and it makes no obvious difference. By: Olle Johansson (oej) 2005-08-15 12:03:17 Closing this bug report due to lack of activity. Please re-open when we have new information, ideas, inspiration or bugs in this area.