[asterisk-users] Audio Dropouts During Call
tony at softins.co.uk
Tue Apr 3 16:53:46 CDT 2018
In article <0ed7d81c-4507-0355-3dd7-cebd7b9a82aa at texascountrytitle.com>,
Brent Davidson <brent at texascountrytitle.com> wrote:
> Well, I now have another office complaining of the audio drop-outs. Logs
> are showing the same issues. RTP just stops for awhile then resumes.
> At the original problem office, I replaced all the network cables,
> replaced two network hubs, and made sure the phones are all connected
> correctly. The problem still exists.
> One thing I did notice during testing is that the audio is perfectly
> fine as long as there is no internet traffic, but once there is internet
> traffic, the audio quality drops drastically, then cuts out completely.
> Once the internet traffic stops, there is about a 2 second lag, then the
> audio resumes.
> I find that incredibly odd as we don't use VOIP outside lines, and none
> of the voice traffic should be passing through our firewall, router, or
> DSL modem.
> Internal network traffic, such as moving a file between shared folders
> on 2 computers on the internal office network does not impact the audio
> at all. However, if I try to send a file across the VPN, refresh a web
> page in the browser, or run a bandwidth test from either computer, the
> audio goes glitchy then drops out until the traffic returns to normal.
> Attached is a network diagram to show how both offices are set up. There
> shouldn't be any reason for traffic that goes straight to the internet
> to affect the internal VOIP traffic. The Asterisk server only runs
> Asterisk, Hylafax, and a Samba share for the workgroup copier/scanner to
> save scanned files to. It isn't doing DNS, or anything that would tax
> it's resources. The servers both have quad-core CPUs and 16 GB of ram.
> I've tried switching codes between ulaw, alaw, and g.729 and the problem
> persists at both offices.
> Any ideas?
I looked at your network diagram. Try checking the configuration of the
Ethernet ports on the firewall and the Asterisk box. Make sure they are
set to auto-negotiate and not set to a fixed speed and fixed duplex.
I have found in the past that if one end of a link is expecting auto-
negotiation (as the switches probably are) and the other end is expecting
a fixed configuration, things can degrade to half-duplex trying to talk
to full-duplex, resulting in lots of collisions and packet loss when there
is any kind of significant traffic.
Your description would be consistent with the firewall introducing lots of
LAN collisions when busy, in the central gigabit switch, even if the VoIP
traffic isn't passing through the firewall.
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org
More information about the asterisk-users