VoIP Troubleshooting Guide

VoIP Calls Drop After 30 Seconds

7 min read  ·  Updated April 2026

Calls that drop after exactly 30 seconds — or 32, or 64 — are one of the most recognizable patterns in VoIP troubleshooting. The precision of the timing is the clue. This isn't random packet loss or a flaky network. It's a SIP timer firing, a NAT binding expiring, or RTP silence detection kicking in. Here's how to tell which one and fix it.

In this guide

1. Why the timing is always exact

When a VoIP call drops at a precise interval — 30 seconds, 32 seconds, 64 seconds, 180 seconds — it's because a timer expired. SIP is full of timers defined in RFC 3261, each governing how long a UA waits before retransmitting or giving up on a transaction. When the timer fires and no response has been received, the call is torn down.

The most common culprits by timing:

If your calls drop at an irregular time, it's probably not a timer issue — look at network quality instead. Precision timing is always a timer.

2. Five common causes

Cause 01
No ACK received — SIP Timer B
The most common cause of 30-second drops. After sending a 200 OK to an INVITE, the UAS starts Timer B waiting for the ACK. If the ACK is lost (firewall, NAT, routing issue) and never arrives, Timer B fires after 64×T1 seconds and the dialog is torn down with a BYE. The caller hears the call connect briefly then drop.
Cause 02
NAT UDP binding expiry
Many routers and firewalls expire UDP NAT bindings after 30 seconds of inactivity. If RTP packets stop flowing (hold, silence suppression, codec issue) the NAT binding closes. When packets resume they're dropped because the binding no longer exists. The call appears to drop or go silent exactly 30 seconds after the last packet.
Cause 03
SIP session timer expiry
Session timers (RFC 4028) require periodic re-INVITEs to keep a dialog alive. If one endpoint supports session timers and the other doesn't respond to the re-INVITE, the session expires and is torn down. The Session-Expires header in the INVITE defines the interval — typically 1800 seconds but configurable as low as 90 seconds on some platforms.
Cause 04
RTP inactivity timeout
Some PBX and SBC platforms monitor RTP streams and terminate calls when no RTP has been received for a configurable period. If silence suppression is enabled and the codec stops sending packets during silence, the inactivity timer fires. Common default values are 20–30 seconds. Check your PBX RTP timeout settings.
Cause 05
Proxy or SBC transaction timeout
An intermediate proxy or SBC has its own transaction timeout. If it doesn't receive a final response within its timeout window it sends a BYE to both legs. Often seen when a downstream element is slow to respond during call setup and the proxy gives up before the call fully establishes.

3. SIP Timer B and Timer F in depth

Timer B governs INVITE transactions. Timer F governs non-INVITE transactions. Both are defined as 64 × T1, where T1 defaults to 500ms — giving a default timeout of 32 seconds.

; RFC 3261 timer defaults T1 = 500ms (RTT estimate) T2 = 4s (max retransmit interval for non-INVITE) T4 = 5s (max duration a message can remain in network) Timer B = 64 × T1 = 32 seconds (INVITE transaction timeout) Timer F = 64 × T1 = 32 seconds (non-INVITE transaction timeout) Timer H = 64 × T1 = 32 seconds (wait time for ACK receipt)

Timer H is the specific timer that governs the wait for ACK after a 200 OK. If ACK doesn't arrive within 32 seconds, the UAS sends a BYE. This is why the "no ACK" failure mode produces drops at almost exactly 32 seconds.

Some implementations use a T1 of 200ms or 1000ms, which shifts the timeout to ~13 seconds or ~64 seconds respectively. If your drops are at an unusual interval, calculate the T1 value being used: dropout_time / 64.

4. NAT binding expiry

UDP NAT bindings are stateless — the router creates a mapping when the first packet goes out and expires it after a period of inactivity. The default on many consumer and small business routers is 30 seconds. Enterprise firewalls typically use 60–300 seconds.

The failure pattern: call connects, both parties can hear each other, then exactly 30 seconds after the last RTP packet the audio stops. The SIP signaling may still be up (the dialog is alive) but the media path is dead because the NAT binding closed.

How to confirm NAT binding is the issue

In a PCAP, look at the RTP stream timestamps. If you see a gap in RTP packets at exactly the timeout interval — and the packets resume sending but stop arriving — the NAT binding closed during the gap. The sending side is still transmitting but packets are being dropped at the NAT.

Fix: keepalive packets

Configure your SIP endpoint or PBX to send RTP comfort noise or SIP OPTIONS keepalives every 15–20 seconds to keep the NAT binding alive. On Asterisk, set rtpkeepalive=15 in rtp.conf. On FreeSWITCH, set rtp-timeout-sec and enable comfort noise.

5. How to diagnose from a trace

Step 1 — Find the BYE

Every call drop produces a BYE request. Find it in your trace and note who sent it — the caller, callee, or a proxy. The source of the BYE tells you which side timed out.

Step 2 — Measure the interval

Calculate the time from call connect (200 OK) to the BYE. If it's 30–32 seconds, Timer H or NAT. If it's 60–64 seconds, Timer B with default T1. If it's 90–1800 seconds, session timer. If it's 20–30 seconds, RTP inactivity.

Step 3 — Check for the ACK

If the drop is at ~32 seconds, search your trace for the ACK after the 200 OK. If no ACK is present, the ACK was lost in transit — NAT, firewall, or routing issue.

Step 4 — Look for re-INVITE

If the drop is at a longer interval (90s+), look for a re-INVITE before the BYE. If a re-INVITE was sent but never acknowledged, session timer expiry is the cause.

; Trace pattern: Timer H expiry (no ACK received) 200 OK → 00:00:00 (call connects) BYE → 00:00:32 (Timer H fires, no ACK received) ↑ exactly 32 seconds = Timer H ; Trace pattern: Session timer expiry 200 OK → 00:00:00 re-INVITE → 00:30:00 (session refresh attempt) 408/no reply → 00:30:32 (no response to re-INVITE) BYE → 00:30:32 (session expired)

6. Fix by cause

No ACK (Timer H): The ACK is being lost between the two endpoints. Check firewall rules — the ACK uses the same port as the INVITE but some stateful firewalls don't track it correctly. Disable SIP ALG on your router. If behind NAT, ensure your SIP proxy or SBC is handling ACK routing correctly.

NAT binding expiry: Enable RTP keepalives on your PBX (every 15–20 seconds). Increase the NAT UDP timeout on your firewall to 120+ seconds. Consider deploying an SBC to anchor media and eliminate endpoint NAT traversal entirely.

Session timer: Ensure both endpoints support RFC 4028 session timers and are configured with compatible Session-Expires values. Set a minimum of 1800 seconds unless you have a specific reason for shorter intervals. Configure your proxy to handle session refresh if endpoints don't support it.

RTP inactivity: Disable RTP inactivity timeout on your PBX if silence suppression is enabled, or increase the timeout to 120+ seconds. Alternatively disable silence suppression to ensure continuous RTP flow.

7. Analyze your trace automatically

Paste your SIP trace into SIPSymposium. The analyzer identifies the exact timer that fired, checks for missing ACKs, detects NAT issues in RTP timing, and tells you exactly which endpoint sent the BYE and why.

Frequently asked questions

Why do VoIP calls drop after exactly 30 seconds?

VoIP calls dropping after exactly 30 seconds indicate a timer is firing. At ~32 seconds it is SIP Timer H — the server sent a 200 OK but never received the ACK, so it terminates the call. Other common causes are NAT UDP binding expiry (many routers expire bindings after 30 seconds of inactivity) and RTP inactivity timeouts on the PBX.

How do I fix VoIP calls dropping after 30 seconds?

To fix 30-second call drops: enable RTP keepalives every 15-20 seconds to prevent NAT binding expiry, check that ACK packets are not being dropped by a firewall (disable SIP ALG), configure session timers with a minimum of 1800 seconds, and increase the NAT UDP timeout on your firewall to 120 seconds or more.

What is SIP Timer H and why does it drop calls?

SIP Timer H is the wait time for ACK receipt after sending a 200 OK. It defaults to 64 x T1 = 32 seconds. If the ACK is lost in transit (due to NAT, firewall, or routing issue), Timer H fires and the call is terminated with a BYE. The fix is to ensure ACK packets can travel the full network path between both endpoints.

Getting calls that drop after exactly 30 seconds?

Paste your SIP trace into SIPSymposium. The analyzer identifies the timer, finds the missing ACK, detects NAT binding issues, and tells you exactly what to fix.

Analyze my trace Create free account
Related guides