Fixing Common 3CX Call Quality Problems: One-Way Audio, Jitter and Dropouts

Bad call quality issues do not always mean something is broken. A lot of the time, the problem is a setting that got missed, a router that has not been configured properly, or a firewall that is quietly interfering with your VoIP traffic. This guide walks through the most common VoIP problems on 3CX systems and gives you the troubleshooting tips to sort them out fast.

Whether you are running a small office or managing a multi-site phone system, these troubleshooting steps apply. We have covered audio issues, jitter, dropped calls, one-way audio, and everything in between.

Common VoIP Problems and Where to Start

How to Troubleshoot One-Way Audio in VoIP Calls

One-way audio is one of the more frustrating VoIP issues you will run into. You can hear the other person, but they cannot hear you, or it is flipped the other way. This almost always comes back to how SIP and RTP traffic is being handled across your network.

Why One-Way Audio Happens

The SIP protocol sets up the call, but the actual voice data travels over RTP on a completely different path. If your firewall or NAT setup is blocking or redirecting that RTP stream, you end up with a one-way audio problem.

The main culprits are:

• SIP ALG being enabled on the router or modem
• Firewall rules blocking RTP port ranges (usually UDP 9000-10999 on 3CX)
• Incorrect NAT settings on the 3CX server or VoIP endpoint
• A mismatch between the internal and external IP address configured in 3CX

Quick Fix: Disabling SIP ALG is the single most effective first step for one-way audio. SIP ALG rewrites SIP headers in ways that break NAT traversal, and most business-grade routers have it turned on by default.

How to Fix One-Way Audio: Step by Step

1. Log in to your router or modem admin panel and locate the SIP ALG or Application Layer Gateway setting.
2. Disable SIP ALG and save. Reboot the router if required.
3. In your 3CX admin console, go to Settings > Network and confirm the external IP or FQDN is correct.
4. Check that UDP ports for RTP traffic are open on your firewall (both inbound and outbound).
5. Make a test call. If one-way audio persists, enable the 3CX STUN server or use the built-in Session Border Controller.

If you are on a Cisco, Netgear, or similar business router, the setting may be labelled as ‘SIP Helper’ or ‘SIP Inspection’. Disabling SIP ALG across all your network hardware is worth doing regardless.

2. Fixing Jitter and Choppy Audio in VoIP Calls

Jitter is the variation in the time it takes for voice packets to arrive. A small amount of jitter is normal, but when it gets too high, audio becomes choppy, robotic, or cuts out entirely. Network jitter above 30ms will cause noticeable audio quality problems on most VoIP systems.

Solving Jitter: QoS Configuration

The most reliable fix for jitter is getting QoS set up correctly on your router. Quality of Service lets your router prioritise VoIP traffic over other traffic on the network, so a large file download or a video stream does not kill your call quality.

To enable QoS for VoIP:

• Log in to your router admin panel and find the QoS or traffic shaping settings.
• Create a rule that gives the highest priority to VoIP traffic. On most business routers, you do this by marking VoIP packets with DSCP (Differentiated Services Code Point) values, typically EF (Expedited Forwarding) for voice.
• Set QoS settings to prioritise UDP traffic on the ports used by SIP (usually 5060/5061) and RTP (9000-10999 by default in 3CX).
• If your router supports it, configure separate traffic queues so voice gets its own lane.

3. Troubleshooting Call Quality Issues

Packet loss is what happens when voice packets do not arrive at the destination. Even 1-2% packet loss is enough to cause poor audio quality on a VoIP call. At 5% or above, calls become unusable. Unlike latency or jitter, packet loss is often a sign of a hardware or ISP problem rather than a configuration issue.

How to Identify Packet Loss

Run an extended ping test to your SIP trunk provider’s server or to the 3CX server. Use a tool like MTR (on Linux/Mac) or WinMTR on Windows, which shows you hop-by-hop where loss is occurring. If loss is happening on the first few hops inside your local network, the issue is with your internal hardware. If it is happening further out, contact your internet service provider.

Check network conditions during peak times. Many businesses experience call quality problems only between 9am and 11am, which is often a congestion problem either on the internal network or at the ISP level.

Common Causes of Packet Loss in VoIP Systems

• Faulty or low-grade network cabling
• Overloaded switches with no QoS or VLAN separation for voice traffic
• Congested internet connection with no bandwidth reservation for VoIP
• ISP-level congestion during peak periods
• Outdated firmware on routers, switches, or VoIP phones

Fixes for Packet Loss

Start by checking network hardware. Replace suspect cables and test with a direct connection to rule out switch issues. Update firmware on all network hardware, including routers, switches, and desk phones.

If the problem is at the ISP level, document it with evidence from your packet loss tests and raise it with your internet service provider. Ask specifically about jitter and packet loss on their connection, not just download speeds.

For internal network congestion, separate your VoIP traffic onto its own VLAN. This stops other traffic from competing for the same bandwidth and is standard practice for any business running more than a handful of VoIP phones.

4. Fixing Dropped Calls on 3CX: SIP Timeouts and Firewall Session Limits

Dropped calls on a 3CX phone system usually come down to one of two things: SIP session timeouts, or your firewall closing UDP connections before the call is finished.

SIP Session Timeout Issues

SIP sessions use a keepalive mechanism called re-INVITE or OPTIONS ping to stay alive. If your SIP trunk provider sends a keepalive and the 3CX server does not respond in time, or if the firewall has already dropped the UDP session, the call drops.

To fix SIP timeout issues in 3CX:

1. Go to your 3CX admin console and navigate to the SIP trunk settings.
2. Enable the ‘Register’ option if it is off, so 3CX maintains an active registration with your trunk provider.
3. Check the SIP OPTIONS interval and confirm it matches what your trunk provider expects.
4. In your firewall, extend the UDP session timeout to at least 180 seconds. Many firewalls default to 30-60 seconds, which drops VoIP sessions mid-call.

Firewall Configuration for VoIP

Your firewall needs to be configured to handle VoIP traffic properly. The critical ports to open are:

After opening the required ports, test calls from an external location to confirm calls are connecting and staying connected. If calls are still dropping, run a packet capture with Wireshark on the 3CX server during a failing call to see exactly where the session is being terminated.

5. Troubleshooting Call Quality for Remote and External VoIP Phones

Remote workers connecting to 3CX over the internet introduce a different set of VoIP issues. When VoIP phones are outside the local network, you are dealing with public internet conditions, different routers and modems, and in some cases, ISP-level SIP filtering.

Remote Endpoint Checklist

• Home router/modem: Check that SIP ALG is disabled on the remote worker’s router. This applies even for home internet connections.
• Bandwidth: Confirm the remote worker has enough bandwidth for VoIP. A minimum of 1 Mbps up and down per concurrent call is recommended, though the actual VoIP codec requirement is much lower. The buffer matters when other devices share the connection.
• 3CX Tunnel: For remote VoIP phones that cannot connect directly via SIP, the 3CX Tunnel protocol encapsulates all traffic through a single TCP port, making it easier to traverse firewalls and NAT.
• Latency: One-way latency above 150ms causes noticeable delay. Above 300ms and conversations become difficult. Have the remote worker run a ping test to the 3CX server to check round-trip time.

Testing Remote Call Quality

To test the network conditions for a remote endpoint:

1. Have the remote worker run a VoIP quality test from their location. Free tools like 3CX’s built-in diagnostics or similar VoIP test sites work well.
2. Check latency from their router to the 3CX server. Anything over 100ms one-way is worth investigating.
3. Review the 3CX call log for that extension after a failed call. Look for error codes, SIP timeout messages, or codec negotiation failures.
4. If calls are dropping specifically for remote extensions, check the UDP timeout on the office firewall for connections coming from external IPs.

6. When to Escalate: Getting Your Support Team or Managed Provider Involved

Not every VoIP problem is one you should try to resolve yourself, especially when it involves your SIP trunk provider or ISP-level issues. If you have worked through the steps above and the problem is still happening, it is time to loop in your support team or managed VoIP provider.

When you escalate, bring:

• A Wireshark capture from a failing call
• The 3CX call log entries for the affected calls (time, extension, direction)
• The results of your bandwidth and jitter tests
• Details of any recent changes: firmware updates, ISP plan changes, new VoIP phones added, firewall rule changes

A good managed 3CX provider will be able to identify the problem quickly from this information. If the issue is on the SIP trunk provider’s side, having the call data ready means the conversation is much more efficient and you are more likely to get a resolution quickly.

If you are looking at an ongoing pattern of call quality issues and do not have the internal resources to manage it, a managed 3CX phone system takes this off your plate entirely. Your provider handles configuration, monitoring, and troubleshooting so your team can focus on the work that actually matters.

Frequently Asked Questions

Why do I have one-way audio on external calls but not internal calls?

This almost always points to a NAT or firewall issue affecting RTP traffic between your internal network and the SIP trunk. Internal calls stay within your PBX and do not cross the firewall, so they work fine. External calls do. Start by disabling SIP ALG on your router and confirming that the RTP port range is open on your firewall, both inbound and outbound.

How much bandwidth does a VoIP call actually need?

The codec determines the raw audio data requirement: G.711 uses around 64 kbps for the audio stream, but with headers and overhead, a single call needs around 87 kbps. G.729 uses around 32 kbps per call. The practical rule is to have at least 1 Mbps of upload and download speed reserved per concurrent call, to account for network overhead and variability.

My calls are dropping after exactly 30 minutes. What is causing it?

This is almost always a SIP session timeout on your firewall. Many firewalls drop UDP sessions after 30 minutes of what they consider idle traffic (even though the call is active). Extend the UDP timeout to at least 180-300 seconds in your firewall settings. Some SIP trunk providers also send a re-INVITE at 30 minutes to test if the session is still alive, and if the 3CX server does not respond in time, the call is terminated.

We updated our router firmware and now calls have poor audio quality. How do I troubleshoot this?

Firmware updates sometimes reset SIP-related settings back to their defaults, including re-enabling SIP ALG or changing QoS settings. After any firmware update, check that SIP ALG is still disabled, confirm your QoS rules are still in place, and verify the UDP session timeout is still set to an appropriate value. A quick test call to a known external number after any router change will catch most issues immediately.

Can I run VoIP and video conferencing on the same connection without call quality problems?

Yes, but you need to manage it properly. Configure QoS settings to prioritise VoIP traffic over video conferencing traffic. Video can tolerate more latency and jitter than voice calls. Set voice to the highest priority queue, mark it with EF DSCP values, and give video a lower but still prioritised class. With enough bandwidth and proper traffic shaping, both can run simultaneously without affecting each other.