When calls drop after 30 seconds, or after exactly 15 minutes, the time is the most useful clue you have. Drops at a fixed time are almost never “bad lines”: a timer in the PBX ran out because something it waited for never arrived. We reproduced each of these drops on a FreePBX 17 server and recorded the SIP messages, so you can match your own trace against ours.
Short answer: On FreePBX with default settings, a drop at exactly 30 seconds is usually the RTP timeout (no audio reached the PBX); the Asterisk log line confirms it. A drop at about 32 seconds means the phone’s ACK never arrived. A drop just after 15 minutes means a session-timer refresh got lost, usually because a NAT or firewall closed the UDP mapping. Check who sent the BYE and its Reason header, then fix the network path, not the timer.
Table of Contents
Decision tree: what the drop time tells you
| Call drops after | BYE and Reason (from our trace) | What Asterisk logs | Cause | Fix |
|---|---|---|---|---|
| Exactly 30 s | From the PBX, Reason: Q.850;cause=44 | Disconnecting channel … for lack of audio RTP activity in 30 seconds | No RTP reaches the PBX (FreePBX default rtp_timeout=30) | Fix one-way audio: NAT settings, RTP ports, SIP ALG |
| About 32 s | From the PBX, Reason: SIP ;cause=408 ;text="Request Timeout", after 200 OK sent 11 times | Nothing specific at the default log level | The ACK for the 200 OK never arrives | Contact and NAT handling, disable SIP ALG |
| Half the session timer + 32 s (900 + 32 = 932 s with the default 1800) | From the PBX, 408 Request Timeout, after its refresh re-INVITE went unanswered | Nothing specific | The refresh cannot reach the phone or provider, usually a closed NAT mapping | Keepalives, longer UDP timeout, TCP/TLS, disable SIP ALG |
| Session timer − 32 s (1768 s, about 29.5 min, with 1800) | From the PBX, Reason: SIP ;cause=408 ;text="No session refresh received." | Nothing specific | The other side was the refresher and never refreshed | Fix the peer, or change who refreshes |
| Another fixed time | Check who hangs up | – | A setting that matches the time: a changed rtp_timeout, a Dial() time limit, the provider’s maximum call length | Find the matching setting |
Two numbers are worth remembering. 32 seconds is the SIP transaction timeout (64 × T1, with T1 = 0.5 s) from RFC 3261, so a drop near 32 seconds means a SIP message went unanswered. 30 seconds is FreePBX’s default RTP timeout, so with the defaults a drop at exactly 30 seconds points at missing audio rather than missing signalling. Confirm it with the log line “lack of audio RTP activity” and the BYE’s Reason header: another limit set to 30 seconds, such as a provider’s or a Dial() time limit, would end the call at the same moment. The timer values in this guide are the defaults of FreePBX 17 and Asterisk 22; other versions or changed settings move them.
How we reproduced each drop
On our FreePBX 17 lab server (Debian 12, Asterisk 22.11, 4 vCPU) a SIPp script played the part of extension 1002 and called the echo test (*43), so every call had a known, answered destination. For each case we broke one thing on purpose and kept the phone’s SIP log; a matching “good” call shows the same setup working. To keep the session-timer tests short, the phone asked for a 90-second session timer instead of the default 1800 seconds; the timers scale the same way.
| Test | What we broke | Result |
|---|---|---|
| No audio from the phone | Phone sends no RTP after the call is answered | PBX hung up at 30.0 s |
| Same call with audio | Nothing | Call stayed up until the phone hung up at 45 s |
| Lost ACK | Phone sends audio but never the ACK | PBX resent the 200 OK 11 times, hung up at 32.0 s |
| Refresh lost (PBX refreshes) | Phone ignores the PBX’s refresh re-INVITE | Refresh at 45 s (half of 90), hang-up at 77.0 s |
| No refresh (phone refreshes) | Phone is the refresher and never refreshes | PBX hung up at 60.0 s (90 − 30) |
| Phone refreshes every 40 s | Nothing | Call stayed up until the phone hung up at 125 s |
One more result from the first lost-ACK attempt: that phone sent neither audio nor the ACK, and the RTP timeout ended the call at 30 seconds, before the ACK timer at 32. When both are broken you see the 30-second drop, so check audio first.
Calls drop after 30 seconds: no audio is reaching the PBX
FreePBX sets rtp_timeout=30 on every PJSIP extension (and rtp_timeout_hold=300 for calls on hold). If Asterisk receives no RTP for 30 seconds it hangs up, sends a BYE with Reason: Q.850;cause=44 and logs the reason in plain words:
The timer is not the problem: it ends calls that already had one-way or no audio. Look at why the audio does not arrive:
- The PBX is behind NAT and advertises a private address in its SDP: set
external_media_address,external_signaling_addressandlocal_neton the transport (our PJSIP NAT generator writes them), as in the Asterisk NAT documentation. - The RTP port range (10000 to 20000 on FreePBX) is blocked by a firewall in front of the PBX.
- A router with SIP ALG rewrites the SDP. See how to disable SIP ALG.
- The phone is remote and
direct_mediasends audio straight between two NATed phones. Setdirect_media=nofor remote extensions.
Setting rtp_timeout=0 stops the drops but leaves the caller talking to silence. Fix the audio path instead; our one-way audio guide goes through it step by step.
Calls drop after 32 seconds: the ACK never arrives
After a call is answered, the caller must confirm the 200 OK with an ACK. Until the ACK arrives Asterisk keeps resending the 200 OK, at 0.5, 1.5, 3.5, 7.5 seconds and then every 4 seconds. After 32 seconds it gives up and hangs up with a 408 Request Timeout:
Audio usually works during those 32 seconds, which is why this drop is so confusing. The 200 OK reaches the phone, but the phone’s ACK goes somewhere else, or never makes it back. Common reasons:
- The 200 OK carries a private Contact address, so the phone sends the ACK to an address it cannot reach. Turn on
rewrite_contact,force_rportandrtp_symmetricfor NATed phones and set the transport’s external addresses. - A SIP ALG on a router rewrites headers and breaks the dialog.
- Large SIP messages over UDP get fragmented and the fragments are dropped. Try TCP for that phone.
- Asymmetric routing: the ACK leaves through a different gateway or firewall that has no state for the call.
In a trace, look for the same 200 OK repeated with the same CSeq. Our sngrep guide shows how to see it live, and the SIP trace analyzer flags retransmissions in a pasted trace.
Call drops after 15 minutes: the session refresh is lost
Session timers (RFC 4028) let both ends confirm that a call is still alive. FreePBX enables them with timers=yes and timers_sess_expires=1800. When the PBX is the refresher it sends a re-INVITE halfway through, after 900 seconds. If that refresh never gets an answer, the transaction times out 32 seconds later and the call ends, at about 932 seconds, just over 15 minutes. In our shortened test the refresh went out at 45 seconds and the call ended at 77:
Why would a refresh go unanswered when the call is working? Because nothing else used the signalling path for 15 minutes. A NAT router or firewall closes an idle UDP mapping long before that, so the PBX’s re-INVITE never reaches the phone or the provider. Fixes, from the most to the least effective:
- Keep the mapping open:
qualify_frequencyon the endpoint’s AOR (FreePBX uses 60 seconds), and NAT keepalives on the phone. - Raise the UDP timeout on the firewall in front of the phones or PBX, or use TCP or TLS for those phones.
- Disable SIP ALG on every router in the path.
- As a last resort, set
timers=noon the affected endpoint. The drops stop, but calls whose other end vanished are no longer cleaned up by the timer.
Calls drop at almost 30 minutes: nobody refreshed
If the other side is the refresher (the 200 OK says refresher=uac for a call the phone started) but never sends a refresh, Asterisk waits until shortly before the session expires and hangs up with Reason: SIP ;cause=408 ;text="No session refresh received.". RFC 4028 sets that point at the expiry minus 32 seconds or a third of the interval, whichever is smaller: 1768 seconds with the default 1800, and 60 seconds in our 90-second test.
The same call with a phone that refreshes every 40 seconds stayed up until the phone hung up:
If a phone or provider advertises session timers but never refreshes, update its firmware or turn session timers off in the phone. On the Asterisk side, timers=no on that endpoint stops the drops.
Capture the evidence on your own PBX
Make a test call that drops and collect three things: the time from answer to hang-up, the BYE with its Reason header, and the Asterisk log around the hang-up.
asterisk -rx "pjsip set logger on" # SIP messages into the Asterisk log (turn off afterwards)
grep -E "lack of audio RTP|Reason:" /var/log/asterisk/full | tail
asterisk -rx "pjsip show endpoint 1001" | grep -E " rtp_timeout|timers"
tcpdump -ni any -w /tmp/drop.pcap udp port 5060 or udp portrange 10000-20000
sngrep # live ladder diagram: look for repeated 200 OK or re-INVITEThen read the table at the top of this page: exactly 30 seconds plus the RTP log line means missing audio; a repeated 200 OK and a 408 means a lost ACK; a re-INVITE without an answer around 15 minutes means a lost refresh. For other drops, compare the time with every timer you have set, and check whether the BYE came from the PBX, the phone or the provider.
What we tested and how
All traces on this page come from our FreePBX 17 lab server (Debian 12, Asterisk 22.11, 4 vCPU) on 16 and 17 October 2026 (FreePBX 17.0.33, Asterisk 22.11, SIPp 3.6.1). The “phone” was a SIPp scenario registered as a normal FreePBX PJSIP extension with the FreePBX defaults; the session-timer tests used a 90-second timer requested by the phone, which Asterisk accepted. We did not test real routers or SIP ALGs: the network causes listed for each drop are the usual reasons for the message that went missing, not something this lab reproduced. The screenshots are the real terminal output; only IP addresses are masked.
Related: common VoIP problems, one-way audio, PJSIP NAT on Asterisk and FreePBX, disable SIP ALG, SIP ports for the firewall, SIP response codes, PJSIP health check script.
At a glance
Frequently asked questions
Why do my VoIP calls drop after exactly 30 seconds?
On FreePBX the most common reason is the RTP timeout: rtp_timeout is 30 seconds by default, and Asterisk hangs up when no audio arrives from the phone for that long. The Asterisk log says “for lack of audio RTP activity in 30 seconds”. Fix the audio path (NAT, RTP ports, SIP ALG) rather than the timer.
Why do calls drop after 32 seconds?
The ACK for the 200 OK never reached the PBX. Asterisk resends the 200 OK for 32 seconds, then hangs up with a 408 Request Timeout. Usually a NAT, Contact or SIP ALG problem.
Why do calls drop after 15 minutes?
With session timers at 1800 seconds the PBX refreshes the call after 900 seconds. If the refresh cannot reach the other side, usually because a firewall closed the idle UDP mapping, the call ends about 32 seconds later. Keepalives, a longer UDP timeout or TCP fix it.
Should I just set rtp_timeout to 0?
Only if you understand the trade-off. It stops the 30-second hang-ups, but the caller still has no audio, and calls whose other end disappeared stay open until something else ends them.
How do I see the BYE Reason header in FreePBX?
Run asterisk -rx "pjsip set logger on", make a test call and look at the BYE in /var/log/asterisk/full, or capture with sngrep or tcpdump. The Reason header shows a Q.850 cause or a SIP code with text.
Reading a lot of our guides? Go ad-free with srvScripts Pro for $6 a month. It also pays for new guides. Cancel any time.