No Audio on VoIP Calls (Both Ways): Causes and Fixes

You dial a number, the call connects, but neither side can hear anything. No audio in both directions is one of the most common — and most baffling — VoIP issues businesses encounter. The call appears to be active, but there is complete silence.

This problem is almost always caused by how your network handles the audio stream, not the VoIP service itself. This guide explains exactly what causes two-way audio failure and how to fix it step by step.

How VoIP Audio Works (Quick Background)

Understanding the basics helps you troubleshoot more effectively. A VoIP call involves two separate protocols:

• SIP (Session Initiation Protocol) — handles call setup, ringing, and teardown. This is the signalling layer. If SIP works, your call connects and shows as active.
• RTP (Real-time Transport Protocol) — carries the actual audio. RTP packets flow between your phone and the VoIP server (or directly between phones in some configurations).

When you have no audio in both directions, SIP is working fine (the call connects) but RTP is being blocked or misdirected. The audio packets cannot reach their destination.

Cause 1: SIP ALG Interference

This is the number one cause of no-audio issues on VoIP calls. SIP ALG (Application Layer Gateway) is a feature in most consumer and many business routers that attempts to modify SIP packets as they pass through NAT.

Why It Causes No Audio

SIP ALG rewrites the IP addresses and port numbers inside SIP packets. The idea is to help VoIP traffic traverse NAT, but it frequently rewrites them incorrectly. The result: your phone tells the VoIP server to send audio to the wrong IP address or port. The server sends RTP packets into the void, and you hear nothing.

How to Fix It

1. Log into your router (typically 192.168.1.1 or 192.168.0.1)
2. Search for SIP ALG — it may be under NAT settings, VoIP settings, Application settings, or Security
3. Disable it completely
4. Reboot the router — the change often requires a restart to take effect
5. Reboot your VoIP phones — so they re-register with correct information

In many cases, this single change restores audio immediately.

Cause 2: Firewall Blocking RTP Ports

Your firewall may be allowing SIP traffic (which is why calls connect) but blocking the RTP audio stream.

What to Check

• SIP ports — UDP 5060 (standard) or 5061 (encrypted). These are usually open if calls connect.
• RTP ports — this is the critical range. RTP uses a range of UDP ports for audio, typically between 10000 and 20000. Your VoIP provider will specify their exact range.

How to Fix It

• Open the full RTP port range specified by your VoIP provider on your firewall for both inbound and outbound UDP traffic
• If you use a stateful firewall, ensure it is correctly tracking UDP sessions and not dropping return packets
• Check that no security software on individual PCs is blocking audio traffic (relevant for softphone users)

Cause 3: NAT Configuration Issues

Network Address Translation lets multiple devices on your network share a single public IP address. VoIP is notoriously sensitive to NAT because both SIP and RTP contain embedded IP address information.

Common NAT Problems

• Symmetric NAT — the most restrictive type, which assigns different external ports for each destination. Many VoIP services struggle with symmetric NAT. If your router uses it, consider switching to a router that supports full cone or restricted cone NAT.
• NAT timeout too short — if the NAT mapping expires between packets, audio drops. Set UDP NAT timeout to at least 300 seconds.
• Multiple NAT layers (double NAT) — if your network has two routers performing NAT (e.g., ISP router plus your own), VoIP traffic gets translated twice, often incorrectly. Put your ISP router into bridge mode or use the DMZ feature.

STUN, TURN, and ICE

Modern VoIP systems use these protocols to help phones discover their public IP address and punch through NAT:

• STUN — lets the phone learn its public IP and port. Works with most NAT types except symmetric.
• TURN — relays audio through an intermediary server. Works with all NAT types but adds latency.
• ICE — tries multiple methods to establish the best audio path.

Check your phone or softphone settings to ensure STUN is configured with your provider recommended server address.

Cause 4: VPN Interference

If you or your staff are using a VPN, it can block or misdirect RTP audio traffic.

Why VPNs Cause Audio Issues

• The VPN encrypts and tunnels all traffic, but may not handle real-time UDP audio efficiently
• The VPN endpoint may be in a different geographic location, adding latency
• Split tunnelling may route SIP through the VPN but RTP outside it (or vice versa), confusing the VoIP server about where to send audio

How to Fix It

• Exclude VoIP traffic from the VPN — configure split tunnelling to route SIP and RTP traffic directly, not through the VPN tunnel
• Use your VoIP provider IP addresses in the split tunnel exclusion list
• Test without the VPN to confirm it is the cause

Cause 5: Codec Mismatch

If your phone and the VoIP server cannot agree on an audio codec, the call may connect (SIP negotiation partially succeeds) but audio fails.

• Check supported codecs — common ones include G.711 (best quality, higher bandwidth), G.729 (compressed, lower bandwidth), and Opus (modern, adaptive)
• Ensure at least one common codec — your phone codec list must overlap with what your provider supports
• Try G.711 first — it is universally supported and eliminates codec issues as a variable

Cause 6: Incorrect Phone Network Settings

Misconfigured phones can advertise the wrong IP address for audio.

• Check the phone NAT settings — ensure the phone is configured to use NAT traversal if it is behind a router
• Verify the phone local IP — it should be on the correct subnet with the right gateway
• Check for IP conflicts — if two devices share the same IP, packets get routed unpredictably

Diagnostic Steps: Systematic Approach

If you are not sure which cause applies, work through this checklist in order:

1. Disable SIP ALG on your router and reboot everything. This fixes the majority of cases.
2. Check firewall rules — ensure RTP ports are open for UDP in both directions.
3. Test from a different network — connect a phone to a mobile hotspot. If audio works, the problem is your network configuration.
4. Check for double NAT — trace the path from your phone to the internet and count how many NAT devices are involved.
5. Disable VPN temporarily and test.
6. Run a packet capture — tools like Wireshark can show you exactly where RTP packets are going (or not going). Look for RTP packets leaving your phone and check whether responses come back.
7. Contact your provider — they can check server-side logs to see whether RTP packets are reaching their infrastructure.

Preventing No-Audio Issues

Once resolved, keep audio working reliably with these practices:

• Document your working configuration — router settings, firewall rules, phone settings. If something changes, you can compare.
• Test after any network change — new router, firmware update, ISP change, or firewall rule modification
• Use business-grade routers — they handle VoIP traffic far more predictably than consumer models
• Consider a managed VoIP service — where the provider pre-configures phones and monitors audio quality proactively

For a full comparison of managed VoIP providers that handle setup and troubleshooting for you, see our hosted VoIP solutions guide.