I am using asterisk with the Amportal tool and it works fine between SIP (soft) phones using linux. Now I’m trying to create a SIP <> PSTN gateway. It does work, but I have an audio delay of +/- 500 ms.
If I call from a SIP phone to a normal phone number, the outgoing voice has this delay.
If I call from a normal number to the asterisk box who routes the call to a SIP phone, again the SIP phone has the delay.
The normal phone does not create a delay. Calling between SIP phones does not create a delay. I have a I4L compatible ISDN card (I load it with modprobe hisax id=HiSax type=35 protocol=2)
Unfortunately, I don’t have an echo problem but a delay/lag problem…[/quote]
I believe a delay is all part of the same echo phenomenon.
Your zapata.conf file looks about right
This page is quite concise and to the point about how to deal with echo problems on Zaptel hardware. I don’t know about digital cards but the gain adjustment description at the bottom solved my echo problems on a TDM card. asteriskdocs.org/modules/tin … x1695.html
I spent literally months tracking this problem down on my first machine. Usually it is a combination of several problems.
You neglected to mention the type of Zaptel card your using, the
software version your running, the brand of SIP phones, the software
version in the Phone, the LAN ( assume 100BT ), Ethernet switch type,
and loading of your LAN.
Also need to know the type of server, CPU speed, Memory available
type of disk ( ATA100 , SCSI ) and if your mirroring or doing anything
else unusual.
The type and qualities of the far end phone, also make a substantial
difference. ( Because echo is caused by reflection from the FAR end )
This is one thing you can’t do much about - and you will likely have
some delay/echo on a fraction of calls. And if the far end is a cellular - then you’ve got even more varaibles to deal with.
Turns out that any of the above can cause the above problem.
If you call Digium they can help. You should also run
/usr/src/zaptel/zttest and monitor the output for a few minutes
are any values less than 99.98% ? If so you have PCI problems.
Also, for a quick test, borrow another brand of SIP phone, and/or
use a softphone and see what results you get.
Most of those things you mentioned can be eliminated. For example, I have not heard of anyone having problems because of the type of network switch they were using. 100baseT is preferred but not necessary and will not cause echo problems. Echo is an analog phenomenon. Delay is mostly a digital phenomenon.
Sure there are lots of variables but 95% of the time it is the most common ones that are causing the problem.
My severe problem with echo was related to a bad software load
in the SIP phone, in conjunction with poor quality ( low signal level)
in our very old POTS trunks, along with PCI interrupt problems caused by SCSI disk interrupts having priority over digium interrupts. After all that
was cleared up the normal echo training started to work.
Sure, most people may have the common problems, but if your one of
the exceptions it helps to know where else things can go wrong.
UFX, There are lots of links on voip-info.org about echo/delay problems
that you may find useful. It’s more complicated than you would think.
With all the problems I had with this 1U server, I’m not sure what
percentage of the echo/delay was caused by SCSI, but it definitely
caused the zttest interrupt test to show missing interrupts.
I suspect the Sipura-841 phone ( I had one of the early ones ) was
the primary problem, which caused overcompenstion by asterisk for
echo, which led to the delay.
The TDM cards seem overerly sensitive to this, and must be assuming
better than specified behavior on the PCI bus.
[quote=“lmarzke”]UFX, There are lots of links on voip-info.org about echo/delay problems
that you may find useful. It’s more complicated than you would think.
[/quote]
Thanks for the information. I’m going to bugtest all the things and hope to find the exact ‘problem’.
By ripping out the SCSI disks and using IDE.