Audio delay SIP <> PTSN


#1

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)

Some info about my configs:

modem.conf:
group=1
msn=xxxxx
incomingmsn=xxxx,xxxx
device => /dev/ttyI0

sip.conf:
[general]
port = 5060
bindaddr = 0.0.0.0
disallow=all
allow=ulaw
context = from-sip-external ; Send unknown SIP callers to this context
callerid = Unknown

[200]
username=200
type=friend
secret=xxx
record_out=Always
record_in=Always
qualify=no
port=5060
nat=never
host=dynamic
dtmfmode=rfc2833
context=from-internal
canreinvite=no
callerid=“test” <200>

Any idea what the problem is?


#2

You probably need to look at the echocancel settings.
This link should get you started.
voip-info.org/tiki-index.php … ncellation

Post your zapata.conf file here.

You should have the following two lines:
echocancel=yes
echocancelwhenbridged=yes

You might also want to try adding the following:
echotraining=yes


#3

Thanks for the reply. My zapata.conf:

[trunkgroups]

[channels]
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes

Unfortunately, I don’t have an echo problem but a delay/lag problem…


#4

[quote=“ufx”]Thanks for the reply. My zapata.conf:

[trunkgroups]

[channels]
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes

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


#5

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.


#6

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.


#7

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.

Lee


#8

lmarzke

Could you please explain how you solved the SCSI IRQ priority problem? I would be very interested in case I run into this sort of problem.


#9

Don’t ask. :angry: By ripping out the SCSI disks and using IDE.

Digium has recomendations on tuning the IDE drivers to make disk
interrupts less of a problem for TDM interrupts, but this can’t be
done with SCSI.

lists.digium.com/pipermail/aster … 01118.html

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.


#10

Here is a better link to the SCSI thread:
lists.digium.com/pipermail/aster … 02385.html

Lee


#11

[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’.