VoIP One-Way Audio and Calls That Drop at 32 Seconds: What Causes Them and How to Fix Them

VoIP one-way audio and calls that drop at about 32 seconds are nearly always NAT problems, not a bad internet connection. NAT is how an office router lets many devices share one public IP address, and the fix is configuration, not a faster line.

They're also the two VoIP complaints that come up most: "they can hear me but I can't hear them" and "every call cuts off after about 30 seconds".

You'll find what causes each one, how to pin it down in about 10 minutes, and the settings that fix it on Asterisk-based systems (including VICIdial), common firewalls and hosted phone services. Getting NAT right is part of our VoIP and SIP work, alongside SIP trunks and network tuning for clear calls.

Why VoIP breaks behind a router

A VoIP call is really two conversations:

• SIP signalling sets the call up and ends it: "I'm calling you", "it's ringing", "answered", "hang up". It usually runs on port 5060.
• RTP carries the audio, on a separate range of UDP ports. Asterisk's sample configuration uses 10000 to 20000.

When a call starts, each side tells the other where to send audio: an IP address and a port, written inside the SIP message in a section called the SDP. Behind a typical office router, a phone or PBX only knows its own private address, something like 192.168.1.20. If it writes that into the SDP, the other end sends audio to an address that doesn't exist on the internet.

That one detail explains most of what follows.

Problem 1: one-way audio

What it sounds like: you hear the caller but they can't hear you, or the other way round. Sometimes it only happens on calls in one direction.

The usual causes, most common first:

1. A private address in the SDP. The PBX or phone advertises 192.168.x.x as its audio address, so audio from the provider never arrives.
2. The firewall blocks incoming audio. Signalling gets through, but nothing lets the RTP ports in from the provider.
3. The router rewrites the audio's source port. Some firewalls, pfSense among them, change the source port of outgoing traffic by default. Netgate's pfSense documentation notes this can cause one-way audio with some providers.
4. SIP ALG. A router feature that tries to "help" SIP by rewriting addresses inside the messages. When it gets them wrong, which is often, audio goes to the wrong place.

How to fix it on Asterisk (PJSIP):

• On the transport, set local_net to every internal subnet, and external_media_address and external_signaling_address to your public IP. Asterisk then writes the public address into the SDP when it talks to anything outside local_net.
• On endpoints for remote phones or providers behind NAT, set rtp_symmetric=yes, force_rport=yes and rewrite_contact=yes, so Asterisk replies to where packets actually came from.
• Set direct_media=no for anything crossing NAT, so audio flows through Asterisk instead of trying to go phone to phone.

VICIdial runs on Asterisk, so the same principles apply. Many VICIdial installs still use the legacy chan_sip driver, where the equivalents are externip (or externaddr), localnet and nat=force_rport,comedia. chan_sip was removed in Asterisk 21, so plan a move to PJSIP when you upgrade.

On the firewall:

• Forward the RTP port range to the PBX, and allow it only from your SIP provider's IP addresses, which your provider publishes.
• On pfSense, switch outbound NAT to hybrid or manual and add a static port rule for the phone system's UDP traffic, so audio keeps its source port.
• Turn off SIP ALG on the router unless your provider specifically tells you to use it. SonicWall and Palo Alto Networks give the same advice, and many hosted phone providers require it.

Problem 2: calls drop after 30 to 32 seconds

What it sounds like: the call connects, audio may even work, and then it ends at almost exactly the same moment every time.

That timing is the clue. When a call is answered, the answering side sends 200 OK and waits for an ACK to confirm. It keeps resending the 200 OK until the ACK arrives, and gives up after 64 times the SIP timer T1. T1 defaults to 500 milliseconds, so 64 × 0.5 = 32 seconds. Then it hangs up.

So a call that drops at 32 seconds almost always means the `ACK` never arrived. Twilio's documentation for its SIP error 32022 describes exactly this case and lists NAT as the first likely cause.

Why the ACK goes missing:

• The 200 OK carried a private address in its Contact header, so the ACK was sent somewhere unreachable.
• SIP ALG rewrote the headers incorrectly.
• A firewall dropped the ACK because it arrived on an unexpected path.

The fix is usually the same set of settings as for one-way audio: correct external_signaling_address and local_net, rewrite_contact=yes for NATed endpoints, and SIP ALG off.

Problem 3: calls drop after a few minutes, or incoming calls stop ringing

What it sounds like: outgoing calls work, but after a quiet spell, incoming calls stop arriving until a phone is rebooted. Or longer calls drop at random.

Routers keep a short-lived "mapping" for each UDP conversation and forget it after a period of silence. RFC 4787 says a UDP mapping shouldn't expire in under two minutes and recommends five, but many routers use shorter timers. Once the mapping is gone, the provider can't reach your phone or PBX.

Fixes:

• Send keep-alives more often than the router's timeout. In PJSIP, set qualify_frequency on the AOR (for example 30 to 60 seconds), and keep registration intervals short.
• Check that the PBX's own "no audio received" timeout isn't hanging up calls that are one-way audio in disguise. Fix the audio and the timeout stops firing.
• Consider SIP over TCP or TLS if your provider supports it. Long-lived TCP connections are less affected by short UDP timeouts, and TLS also stops routers tampering with the messages.

Find the cause in 10 minutes

1. Note the exact symptom. One direction or both? Every call or some? A drop at a fixed 32 seconds points straight at a missing ACK.
2. Capture the signalling. On Asterisk, run pjsip set logger on, or use sngrep on the server to see each call's messages as a diagram. Look for a missing ACK, and check the c= line in each SDP: if it shows a 192.168, 10. or 172.16 to 172.31 address going out to the internet, you've found it.
3. Watch the audio. sngrep shows RTP streams too. If packets flow out but none come back, the problem is inbound: firewall rules, SIP ALG or the advertised address.
4. Test from a phone hotspot. Connect a softphone or one desk phone through a mobile hotspot, bypassing the office router. If the problem disappears, the router or firewall is the cause, not the PBX or the provider.
5. Check SIP ALG last, but always check it. It hides in "advanced", "NAT helper" or "VoIP" settings, and some ISP-supplied routers switch it back on after a firmware update.

Quick reference

Only the last row is really about your internet connection.

Planning to connect an AI voice agent to your call centre? It usually joins your phone system over SIP like any other phone, so sort out these NAT problems first.

Frequently asked questions

The bottom line

When VoIP misbehaves, the line usually isn't the problem. The router is. Once the phone system advertises the right address, the firewall lets the provider's audio in and SIP ALG is out of the way, most one-way audio and 32-second drops disappear.

Still stuck, or running a call centre where every dropped call costs money? Book a free consultation and we'll go through your setup with you, from the PBX to the firewall.

Sources

• Asterisk documentation, Configuring res_pjsip to work through NAT: https://docs.asterisk.org/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Configuring-res_pjsip-to-work-through-NAT
• Asterisk project, Asterisk 21 Module Removal: chan_sip (January 2023): https://www.asterisk.org/asterisk-21-module-removal-chan_sip/
• IETF, RFC 3261: SIP: Session Initiation Protocol (timers T1 and 64*T1): https://www.rfc-editor.org/rfc/rfc3261.html
• IETF, RFC 4787: NAT Behavioral Requirements for Unicast UDP (UDP mapping timeouts): https://www.rfc-editor.org/rfc/rfc4787.html
• Netgate, pfSense documentation, Configuring NAT for VoIP Phones: https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-voip-phones.html
• Twilio, Error 32022: ACK not received from your SIP endpoint: https://www.twilio.com/docs/api/errors/32022
• SonicWall, How and when to disable SIP ALG: https://www.sonicwall.com/support/knowledge-base/how-and-when-to-disable-sip-alg/kA1VN0000000FTk0AM
• Palo Alto Networks, Prisma SD-WAN, ALG Disable: https://docs.paloaltonetworks.com/prisma/prisma-sd-wan/prisma-sd-wan-admin/prisma-sd-wan-nat-policies/use-cases/alg-disable