Calls Sound Fine Internally But Bad on External Calls

When Your Phones Sound Bad: Part 10 of 12

Everything sounds great when you call a coworker across the office. Crystal clear audio, no delay, no choppiness. But when you call a customer, a vendor, or anyone outside the office, the audio quality drops noticeably. The difference might be subtle or dramatic, but it's consistent: internal good, external bad.

This is actually one of the more useful symptoms because it immediately tells you where the problem is not. If internal calls are fine, your phones are working, your local network is healthy, and your PBX is processing audio correctly. The problem lives somewhere in the path between your PBX and the outside world.

Why internal and external calls are different

When you call another extension in your office, the audio typically stays entirely on your local network. The RTP packets carrying your voice travel from your phone to the PBX (or directly to the other phone, depending on the configuration) over your internal switches and cables. The audio never touches the internet. The round trip path might be a few hundred feet of Ethernet cable.

When you call an external number, the audio has to leave your building. It travels over your internet connection, through your ISP's network, across the internet to your SIP trunk provider, through their infrastructure, and then across the telephone network to the destination. The round trip path might cross thousands of miles and dozens of network devices.

Every additional component in that path is an opportunity for latency, jitter, and packet loss to be introduced. Internal calls have almost none of those components. External calls have all of them.

The SIP trunk connection

The SIP trunk is the bridge between your phone system and the outside world. If external call quality is consistently bad, the trunk connection is the first place to investigate.

Codec mismatch or transcoding. Internal calls between your phones probably use whatever codec your phones negotiate directly, which might be Opus, G.722, or G.711 depending on your configuration. The SIP trunk might require a different codec, commonly G.711 for PSTN interconnection. If the codec on the trunk doesn't match the codec used internally, your PBX has to transcode, converting the audio from one format to another in real time.

Transcoding adds processing delay and can reduce audio quality, particularly if the PBX is transcoding under heavy load. Check whether your internal phones and your trunk are using the same codec. If not, consider configuring them to match. G.711 is the safest universal choice because it's supported by virtually every SIP endpoint and trunk provider, and it avoids transcoding entirely if used end to end.

If transcoding is unavoidable (your phones use a wideband codec like Opus or G.722 for better internal audio quality, and the trunk requires G.711), at least ensure that only one transcoding step occurs. If both legs are being transcoded (internal phone to PBX, then PBX to trunk), the double transcoding compounds the quality loss.

Trunk provider quality. Not all SIP trunk providers are equal in terms of audio quality. Some providers invest heavily in their network infrastructure, maintaining well peered connections with low latency to the major carriers. Others route traffic through cheaper paths that add latency and are more susceptible to quality issues.

If you've ruled out other causes and external call quality is consistently mediocre, it might be worth testing a different trunk provider. Many providers offer trial periods or pay per use pricing that lets you compare quality without a long term commitment. When evaluating, pay attention to latency to the provider's servers (a ping test gives you a rough idea), and ask about their network peering and the path your calls take to reach the major carriers.

Trunk capacity and congestion. If your SIP trunk has a limited number of concurrent channels and those channels are fully utilized, additional calls might be routed through a secondary path that has worse quality, or calls might fail entirely. Even if the trunk isn't at capacity, the provider's infrastructure might be congested during peak hours.

Check your trunk's concurrent call usage during the times when quality is worst. If you're consistently near the channel limit, you may need more capacity.

Your internet connection (upload specifically)

External calls use your internet connection's upload bandwidth to send outgoing audio. Internal calls don't use the internet at all. So if your upload is constrained, only external calls are affected.

This is the same bandwidth saturation issue covered in the afternoon call quality post, but framed differently. The key test: run a speed test and a ping test to your trunk provider's server during a period when external calls sound bad. If the speed test shows reduced upload, or the ping test shows elevated latency or packet loss, your internet connection is the constraint.

QoS configuration on your router specifically prioritizes the VoIP traffic going to and from your trunk provider's IP addresses. This ensures that voice gets through even when other traffic is competing for the upload.

Firewall and router processing

Your firewall or router might be introducing latency or dropping packets on traffic that crosses the network boundary. This affects external calls (which cross the firewall) but not internal calls (which stay within the LAN).

If your firewall is performing deep packet inspection, intrusion detection, content filtering, or other CPU intensive operations on outbound traffic, these processes can add milliseconds of delay to every packet. Under heavy load, the firewall might even drop packets that it can't process quickly enough.

Check the firewall's CPU utilization during problem periods. If it's consistently high, the firewall might be a bottleneck. Some firewalls allow you to create rules that bypass deep inspection for specific traffic types or destinations. Exempting your trunk provider's IP addresses from intensive inspection can reduce the delay on voice traffic.

The far end

Sometimes the problem isn't on your end or on your trunk's end. It's on the far end of the call. If external calls to certain numbers or carriers sound bad but calls to others sound fine, the issue might be with the destination carrier's network, the called party's phone system, or the interconnection between your trunk provider and the destination carrier.

This is largely outside your control, but it's worth identifying because it prevents you from chasing a problem on your own infrastructure that doesn't exist there. If the quality issue is specific to calls to a particular area code, carrier, or destination, report it to your trunk provider with specific examples. They can investigate the routing path to that destination and potentially adjust their routing to use a better path.

Testing methodology

To systematically determine where external call quality is degrading:

1. Test an internal call. If it sounds fine, your phones and local network are good.
2. Run a ping test to your trunk provider's SIP server. Note the latency and packet loss.
3. Place a test call to an external number and note the quality.
4. Check your PBX logs for the call to see what codec was negotiated on the internal leg and the trunk leg. If they're different, transcoding is happening.
5. Run a speed test during the external call. Note the upload speed and compare to your plan's rated speed.
6. Check your firewall's CPU and connection table utilization.

Each test eliminates a possible cause. If the ping test shows good metrics but external calls sound bad, the problem is likely in the codec negotiation, transcoding, or the trunk provider's network beyond their SIP server. If the ping test shows poor metrics, the problem is your internet connection or your ISP.

Next up: Static, Buzzing, or Humming on Calls, which covers the electrical and hardware problems that create persistent background noise.