[Home]

Summary:ASTERISK-16609: Screech Sound (loud noise) heard every 100-200 calls in call centre environment
Reporter:James Wilson (integratedvoip)Labels:
Date Opened:2010-08-23 20:20:18Date Closed:2011-07-28 12:16:33
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1285732158.411.mp3
( 1) 1285732247.441_.mp3
( 2) 128583227.441.png
Description:I have this happening on 3 clients now and it is getting to be a serious problem.

These machines are connected to existing Phone systems via ISDN to record calls and to directly connect SIP extensions.

On 2 machines the caller (connected to the existing phone system or via SIP) hears the screeching sound (or loud noise) and then has to hangup the call as it does not stop. On 1 machine the callee (on the other end of the ISDN) hears the  screeching sound (or loud noise) and then has to hangup the call as it does not stop.

I have the same configuration (i.e. connected to the Teclo and PABX to record calls) on a number of clients and it works fine with large volumes of over 20,000 calls per day on the same hardware.

I do not think this is a configuration issue, rather an incompatability issues with certain PABX systems and we would need to find a workaround for them.


This is causing me to pull me hair out. If someone can solve this one for all machines I will make a minimum $500 support payment to the online community of your choice.

****** ADDITIONAL INFORMATION ******

The versions I am using are:
Machine 1:
OS: Linux 2.6.31-gentoo-r6 #1 SMP Fri Apr 16 11:59:24 EST 2010 x86_64 Intel(R) Xeon(R) CPU X3430 @ 2.40GHz GenuineIntel GNU/Linux
Asterisk:  1.6.2.10
Dahdi: 2.3.0.1
Libpri: 1.4.11.3
PABX: NEC

Machine 2:
Linux 2.6.30-gentoo-r5 #1 SMP Wed Jan 27 12:34:43 EST 2010 x86_64 Intel(R) Xeon(R) CPU X3430 @ 2.40GHz GenuineIntel GNU/Linux
Asterisk: 1.6.2.10
Dahdi:2.3.0.1
Libpri: 1.4.11.3
PABX: NEC

Machine 3:
Linux 2.6.30-gentoo-r5 #1 SMP Mon Aug 23 12:16:54 EST 2010 x86_64 Intel(R) Xeon(R) CPU E5504 @ 2.00GHz GenuineIntel GNU/Linux
Asterisk: 1.6.2.11
Dahdi:2.3.0.1
Libpri:1.4.11.3
PABX Samsung Officeserv 7200
Comments:By: James Wilson (integratedvoip) 2010-08-23 20:21:34

Typo in the subject - loud - not "lound" :)
By: Alec Davis (alecdavis) 2010-08-23 23:46:46

fixed typo in subject.
By: Alec Davis (alecdavis) 2010-08-24 00:01:16

I've experienced this before, with analog FXO/FXS ports - not digital like you, setting 'callwaiting=no' in chan_dahdi.conf is my current workaround.

This always happened after analog FXO<->FXS was setup, when a sip call came in and the FXS port was dialled.

May be totally unrelated...
By: James Wilson (integratedvoip) 2010-08-24 00:25:12

Thanks for the info, however is already have callwaiting set to no. I would suspect it could happen within the analogue lines if a call came in during another call.

[channels]
usesmdi=no
usecallerid=yes
callerid=asreceived
callwaiting=no
usecallingpres=yes
callwaitingcallerid=no
threewaycalling=no
transfer=no
canpark=no
cancallforward=no
callreturn=no
echocancel=yes
echocancelwhenbridged=no
By: Shaun Ruffell (sruffell) 2010-08-24 08:54:52

integratedvoip:  What hardware are you using for your ISDN connection? In my experiencing "screeching" like you described can be related to confusion between the driver / hardware on what the current companding mode is.


By: James Wilson (integratedvoip) 2010-08-24 19:04:42

I am using the G711 alaw codec.

The hardware is a TE420BF for the first 2 machines and a TE220BF for the mlast machine. So all digium hardware which should have no issue.

This issue is very random and usually mid conversation.

Some additional ideas i have had is that this "appears" to occur more often if the call is placed on hold or transferred by the remote end. This is not confirmed and not always the case - the staff have commented this in the fault logs that they keep each day.


REALLY appreciate your help and comments thus far.
By: James Wilson (integratedvoip) 2010-08-24 19:54:14

Does anyone think changing to hardhdlc will make a difference?
By: Shaun Ruffell (sruffell) 2010-08-25 13:45:38

integratedvoip: I don't think hardhdlc would help.  If the artifacts were intermittent, perhaps, but the fact that you have to tear down and reestablish the call in order to make it work doesn't seem consistent.

Do you have any recordings of this screeching that you could attach?  Also, are you using the same sip phones in the working setups and the non-working ones?
By: James Wilson (integratedvoip) 2010-08-25 18:42:31

Strangely the screeching sound is never heard in the recordings. The audio stops as the screech starts.

Good question regarding the sip phones. I only have sip phones on one of the 3 sites. I am using snom 300/320 handsets on that one site. So i dont believe it is related to the handsets.

Usually the customer uses their existng phone system handsets, and our system in in series with the Telco ISDN lines to record the calls and provide auto dialling capabilities.

Thanks.
By: James Wilson (integratedvoip) 2010-09-05 19:53:12

Please help anyone who is able. I have just had some further complains from one of the 3 customers.
By: James Wilson (integratedvoip) 2010-09-07 01:22:39

One important item i just remembered is that this is most likely only occuring with MixMonitor turned on. I have tested one customer with MixMonitor not being used and they said the screech stopped.

However, you cannot always believe what they tell you :)
By: James Wilson (integratedvoip) 2010-09-07 02:07:40

Do you think this issue is related https://issues.asterisk.org/view.php?id=9430

I know it is to do with playing audio files, but the description of the sound is identical.

Perhaps with the mixmonitor app running the audio is not being written out the PRI correctly and we get this ugly sound
By: James Wilson (integratedvoip) 2010-09-07 02:41:04

Another thing i have noticed is that it is more likely to occur during a transfer from the remote end.
By: Shaun Ruffell (sruffell) 2010-09-07 09:14:10

integratedvoip:  are there any other clues?  If it was something like you suggest...then it should be fairly reproducible.  So there aren't any other differences between those calls that have problems and those that do not?
By: James Wilson (integratedvoip) 2010-09-07 18:05:20

Unfortunately not. Sorry for the bit by bit information. All of the things i have found are not always the case, for example it is not always during a transfer, it is not always during peak loads, etc.

I will increase my support payment to the online community of your choice to $800 for anyone who can solve this issue.
By: Shaun Ruffell (sruffell) 2010-09-08 09:46:17

integratedvoip:  Are there any cases where the screech is heard that doesn't run through the Asterisk system?  Since the callees always come in through the existing PABX it is always involved, but it appears that when internal users connected to the existing PABX hear the screeching (and the recorder on the Asterisk box stops) the only thing really constant are those PABX (i.e. if the asterisk box is only recording in that case, how is it injecting audio into the call between the callee and the agent?).

Maybe the problem really lies with the PABX?  That could also be why you don't have any problems with this setup at your other clients?

I'm assuming you have |PSTN| <--> |PABX| <--E1--> |Asterisk| <---> |Sip end points|
By: Alec Davis (alecdavis) 2010-09-08 14:38:10

If I read the OP I understand the setup to be like below, please confirm<pre><b>
[PABX]
 ||
 ||E1
 ||
[TE420BF ASTERISK]-------{Sip Phones}
 ||
 ||E1
 ||
[PSTN]</b></pre>

We randomly experience screeching (for a few seconds) during a call, if we are on a call to our warehouse (no asterisk there) where they drive forklifts with reversing beepers, and I'm sure the beeping triggers some FAX detection.
But we have additional ISDN switches (Jtec's) that the call passes through, so it may be the Jtec going into FAX mode.
By: James Wilson (integratedvoip) 2010-09-08 18:33:58

sruffell - i have tried it without the asterisk system installed and the screeching sound stops. So it is definately related to Asterisk and not the PABX. This is also happening on 3 clients, but not on many many others. So it could be a combination of asterisk, its protocol implementation of libpri, or somethig else.

alecdavis - yes that configuration is correct. Our system sits in series with the PABX and the Telco to record calls.
By: Shaun Ruffell (sruffell) 2010-09-24 18:31:59

integratedvoip:  Any new information on this issue?
By: James Wilson (integratedvoip) 2010-09-28 23:34:16

I have come to one of the sites today armed with a Sangoma card hoping that will fix this and it has not fixed it.

The good news is i was able record the offending audio for the first time.

I accidently had faxdetect turned on and there were messages in the logs saying:
Sep 29 12:35:44 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 62
Sep 29 12:35:44 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 1
Sep 29 12:38:52 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 2
Sep 29 12:38:52 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 61
Sep 29 12:54:59 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 32
Sep 29 12:55:39 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 32
Sep 29 12:56:19 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 32
Sep 29 12:56:53 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 4
Sep 29 12:56:53 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 59
Sep 29 13:25:18 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 32
Sep 29 13:45:46 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 1
Sep 29 13:45:46 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 59
Sep 29 13:48:51 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 10
Sep 29 13:48:51 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 54
Sep 29 13:49:41 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 9
Sep 29 13:49:41 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 55
Sep 29 13:50:12 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 7
Sep 29 13:50:12 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 58
Sep 29 13:51:48 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 4
Sep 29 13:51:48 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 53
Sep 29 13:56:33 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 12
Sep 29 13:56:33 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 52
Sep 29 14:19:04 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 3
Sep 29 14:19:04 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 62
Sep 29 14:22:37 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 11
Sep 29 14:22:37 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 55
Sep 29 14:24:36 jamieson dahdi: Disabled echo canceller NLP because of CED rx detected on channel 13
Sep 29 14:24:36 jamieson dahdi: Disabled echo canceller NLP because of CED tx detected on channel 53


These error messages may simply be because asterisk has detected the noise as an fax signal.

Audio file attached.
By: Shaun Ruffell (sruffell) 2010-09-29 09:45:24

integratedvoip: when you disable faxdetect do you still have the screech?
By: Shaun Ruffell (sruffell) 2010-09-29 11:43:00

I uploaded a spectral plot of the audio file that you attached.  It's definitely a fax answer tone (2100 Hz) (which you can see the horizontal bar to the right of the image) which is similar to what alecdavis described a couple of posts up.
By: James Wilson (integratedvoip) 2010-09-29 18:35:04

With faxdetect turned ON the audio is heard by one end of the call (never both) and the audio recording with MixMonitor RECORDS the tone.

With faxdetect turned OFFthe audio is still only heard by one end of the call (never both) but the audio recording with MixMonitor NEVER RECORDS the tone.


By: James Wilson (integratedvoip) 2010-10-10 20:22:39

Update: I upgraded to Asterisk 1.8.0-rc2, DAHDI Version 2.4.0 (Echo Canceller MG2) and libpri 1.4.11.4.

The issue is still occuring after 4 days; it has not fixed the problem.

/James
By: James Wilson (integratedvoip) 2010-10-12 22:50:41

Update: I have had to revert to asterisk 1.6.2.13 as asterisk 1.8.0-rc2 caused it to crash every few days. The channels were not hanging up properly.
By: Shaun Ruffell (sruffell) 2010-10-12 23:08:44

I'm moving this out of DAHDI-Linux since I'm nearly certain this isn't a driver problem.  Something in your network is generating fax answer tones, so either fax detect is setup in an asterisk server, softphones have fax detect software installed, there is a fax machine monitoring the line, etc..

Nothing in DAHDI would generate a 2100hz tone that I'm aware of.
By: Robert Boardman (robboardman) 2010-11-19 04:39:36.000-0600

Just wanted to add that this happens to me using a similar configuration asterisk 1.6.2.13 dahdi 2.4.0, but in an Avaya IP Office, I have rolled back to 1.6.11 which has worked flawlessly on othe sites, I think it is a problem with MixMonitor
By: Russell Bryant (russell) 2011-07-28 12:16:28.487-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!