Damian, Cheers to you for buying that support hour and posting their response. Hopefully we all can come to a solution for this pesky problem and in a very timely manner. I will try all of the suggestions and post any solutions I find. I made a call today on the SIP phone and it was clear for abou 45 seconds and then went to static/line noise for about 3 seconds and then returned to normal. The remaining 30 - 60 seconds of the conversation was normal. I'm wondering if maybe it has to do with network congestion. I called the SIP phone from a separate landline and listened and waited for the static...it never came. I wish the problem was less sporadic. Thanks again for your post.
Cheers, Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Damian Funnell Sent: Tuesday, April 12, 2005 14:02 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Line Noise HELP! Hi Rich, Hear your point about the trace and all, will try and figure something out. Will also look at logging debug messages. We did the unthinkable and purchased a support incident through Digium and they have zeroed in on the zttest output, as per the info below (I've pasted in an excerpt from their email in case anyone else finds it useful). Not sure if this is the cause of our problem or not, as I don't understand whether the TDM card is used as a timing source for calls over CAPI, but will look at getting zttest output up regardless. Have to say that I am pretty impressed with Digium support so far - the engineer even rang me in New Zealand to follow up on their email and to inform me that I still have 45 minutes of my hour left to use. Cheers, Damian. Excerpt of email from Digium support: Digium does not support CAPI or BRI, either freely or commercially. We can only provide support for you Digium TDM400P card. Your zttest output is extemely low. We are looking for nothing less than 99.98%. If you are receiving 99.96% this will cause major problems. Have a best output of 99.975% is really low. Please ensure that you are running either Asterisk Release 1.07, Zaptel Release 1.07, and Libpri Release 1.07 (Libpri only required if using a PRI) from www.asterisk.org or Asterisk CVS Stable/HEAD, Zaptel CVS Stable/HEAD, and Libpri CVS Stable/HEAD (Libpri only required if using a PRI) as of the current date from Digium's CVS server. You may obtain instructions on downloading CVS Stable/HEAD from Digium's CVS server by visiting the download area on www.asterisk.org. Please verify that your Digium hardware is not sharing an IRQ on your system. You can accomplish this by running "cat /proc/interrupts". Do not solely rely on "cat /proc/interrupts" to determine whether your Digium hardware is sharing an IRQ on your system. Make sure your Digium hardware is on its own IRQ by itself and that it is taking interrupts. You can determine whether it is taking interrupts from the 2nd column of output from "cat /proc/interrupts". This should be something other than zero. You will also need to verify that your Digium hardware is not sharing an IRQ by examining the output after running"lspci -v" and "lspci -vb". Using lspci is the best way to determine whether or not your Digium hardware is sharing an IRQ on your system. Please verify that all Digium hardware is on its very own IRQ by itself. You may need to disable unnecessary hardware on your machine such as sound controllers, USB controllers, extra ethernet controllers, firewire, parallel ports, and/or serial ports. You should try moving and swapping our card to different PCI slots in order to get it on it's own IRQ. Some BIOS's will allow you to specify an IRQ for each PCI slot and/or onboard devices. If you are running an IDE hard drive please verify that you are using DMA mode with a UDMA setting of no lower than 2 or higher than 3. UDMA mode 2 is ATA33. UDMA mode 3 is ATA44. This can be done using hdparm. We suggest using "hdparm -d 1 -X udma2 -c 3 /dev/[IDE Device]". You can check the status using "hdparm /dev/[IDE Device]" and "hdparm -i /dev/[IDE Device]". If you make modifications to your IDE hard drive settings they will only be kept until you reboot. You will need to add the hdparm command you executed to one of your distribution's startup scripts. This way the IDE hard drive settings will be updated on each reboot. You can check whether or not your Digium hardware on your system is experiencing IRQ misses by using the zttest application which should be located in yourzaptel source directory. Do not solely rely on zttest to determine whether you are having IRQ misses with your Digium hardware on your system. Optimally,we are looking for output of 100% from zttest. Our cards will function properly as long as they do not report back less than 99.98%. Some people have reported no apparent problems with output as low as 99.975%, while others will have many apparent problems with an output as low 99.975%. You are almost guaranteed to have many apparent problems with an output lower than 99.975%. We strongly suggest doing everything possible in order to obtain atleast 99.98% output from zttest. I would watch the output over a 5 minutes period to check for spikes on intervals. You may also look for IRQ misses using the zttool application. Do not solely rely on zttool to determine whether you are having IRQ misses with your Digium hardware on your system. This application should be built while compiling zaptel. zttool requires the libnewt development package to be installed on your system in order to compile properly. IRQ misses with your Digium hardware can be due to I/O problems on your system. You may test if you are having I/O problems on your system by running "hdparm -t /dev/[Hard Drive Device]". This will causes massive amounts of I/O on your system. The symptoms of an I/O problem on your system could be cracklingand/or static on the line while running "hdparm -t /dev/[Hard Drive Device]". If you are having an I/O problem on your system and run this command it could result in dropped calls temporarily. If you are experiencing those symptoms while running "hdparm -t /dev/[Hard Drive Device]" it is likely that you havean I/O problem on your system. We would suggest using an IDE harddrive rather than SCSI or SATA in order to configure your hard drive to UDMA2. Configuring a SCSI or SATA hard drive to UDMA2 is not possible. This is only possible on an IDE hard drive. Do not solely rely on "hdparm -t /dev/[Hard Drive Device]" to determine whether or not you have an I/O problem on your system. Please ensure that you are not running X-Windows, frame-buffer, or serial console, as these will cause problems with our hardware. You can disable frame-buffer by supplying the "vga=normal" option to your kernel at boot time. Frame-buffer may start your console with a high resolution and a logo that is alongthe top of the screen. If you are still having IRQ misses with our hardware you could try booting your kernel with "acpi=off" and/or "noapic" to disable ACPI power management andAPIC. These has been known to cause interrupt sharing problems as well. If your system supports Hyper-Threading Technology, you should disable it in your BIOS to see if it resolves your problems. If these suggestions do not resolve your issue, please call 1-877-LINUX-ME to provide us with remote root access to your Asterisk server. This will allow us to further debug your problem. You may provide us this information by email if you prefer. FFF Managed Technology Ltd 60 Cook St P.O. 6368 Wellesley St Auckland t +64 9 356 2911 f +64 9 358 9070 m +64 21 415 297 w www.fff.co.nz Rich Adamson wrote: >>Thanks for that Rich. Etheral trace is going to be almost impossible >>for various reasons, but will try the other two options. >> >>Can't find much online re. debugging - any chance of killing the box by >>turning this on? >> >>SIP show channels and the various CAPI show commands do not show >>anything out of the ordinary when the problem occurs. >> >> > >In order for anyone to help identify the noise problem, you really >are going to have to find a way to capture some data, otherwise >we're all spinning our wheels and guessing. > >To implement debugging, look at /etc/asterisk/logger.conf and add >the keyword 'debug' like: > messages => notice,warning,error,debug >Adding that keyword requires that * be stopped and restarted to take >effect. That tells asterisk to log all debug statements (that are >embedded in asterisk source code) to write to /var/log/asterisk/debug >file. > >That debug file will grow to a very large size rather quickly, so >you need to pay attention to available disk space, etc. > >When the noise problem occurs, note the specific system "time", and >take a look at /var/log/asterisk/debug to see what was happening >around that time. Once you've captured at least some data, you may >want to remove the debug statement. > >If you haven't tried some of the other cli debug tools, you might >want to do "help sip debug", "help rtp debug", etc. > >If you can't run ethereal on the system with the problem, there are >other tools like tcpdump, etc, that can be used to capture packets. > > >_______________________________________________ >Asterisk-Users mailing list >Asterisk-Users@lists.digium.com >http://lists.digium.com/mailman/listinfo/asterisk-users >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users