Calls drop: after 30 seconds, after 15–30 minutes

A drop “after exactly so long” is not a bad connection but a timer: one side was waiting for something, did not get it and dutifully hung up. So the moment of the drop names the cause almost for certain: ~32 seconds — the confirmation that the call started never arrived; ~15 or ~30 minutes — a refresh of the call did not get through; incoming calls only work for the first minutes — the router closed the road to the phone. Below is the mechanism of each case in plain words, and what to do.

General phone setup is in the overview “SIP Phone Setup”, other symptoms — in troubleshooting by symptom.

Check the admin panel first#

1. The call log — open the dropped call. “Talk” shows the duration to the second: 0:31–0:33 is the signature of the first case, about 15:00 or 29:30 of the second. The same card shows “Hung up by” (caller, employee or PBX) and “Hangup cause”.
2. The *43 echo test, but a long one: dial it and hold the handset for 45 seconds. *43 is also a call, and the confirmation that it started travels the same road. It dropped at 32 seconds — the fault is between the phone and the PBX; it held — the phone and the venue network are fine, look further (external calls, the carrier).
3. Device card → “Uptime”: regular “no connection” gaps mean the router closes the way back to the phone (see the third case).
4. “Call this phone” in the card, 10 minutes after the last call: it rings — the road to the phone is alive; silent with a green dot — it is the router.
5. The SIP trace on a dedicated PBX: a repeated 200 OK with no ACK, then BYE — the first case; a BYE after an INVITE or UPDATE in the middle of the call — the second.

Drop after 30–32 seconds#

Why it happens#

The start of a call is a handshake of three messages: “calling” (INVITE) — “answered” (200 OK) — “got it, let’s go” (ACK). The side that answered keeps repeating its “answered” until it gets “got it”. The SIP rule is: if “got it” has not arrived within 64 × T1 = 64 × 0.5 s = 32 seconds, the call must be ended. The voice is already flowing by then — which is why the first half-minute is fine and then the call drops by itself.

So a drop at 32 seconds means: the ACK confirmation is being lost somewhere. Why — from the most common to the rarest:

1. SIP ALG on the router. The router rewrites the addresses inside signalling messages, and the confirmation goes the wrong way or is thrown away. Always the first thing to check.
2. A packet that is too big. If dozens of codecs are enabled in the phone, the call description grows beyond ~1300 bytes and goes over UDP “in pieces” (fragments). Many routers and firewalls silently drop fragments — and exactly that message is lost. The SIP standard itself requires switching to TCP for such messages.
3. An internal address in the messages. The phone writes its internal address (192.168.x.x) about itself, and the confirmation is sent there. Our PBX corrects this by itself — it answers wherever the message actually came from — but a carrier may not have such protection: then only external calls drop.
4. Double NAT or a strict firewall that lets through the first messages of a call and cuts the later ones.

What to do#

After each step, repeat the long *43 (45 seconds) and a test call; go further only if it did not help.

1. Turn off SIP ALG on the router (“SIP Helper”, “SIP Passthrough”, “ALG for SIP”) and reboot the router. Where to find it on popular brands — “Network, router and internet”.
2. Leave three codecs in the phone — G.711 PCMA, G.711 PCMU and G.722 — and disable the rest: the messages get shorter and stop fragmenting.
3. Switch the transport to TCP (same port, 5060) if step 2 did not help: TCP splits long messages properly by itself, and fragmentation goes away. Our PBX accepts both UDP and TCP.
4. Only external calls drop, while *43 and internal calls hold — the fault is between the PBX and the carrier. Send the times of several dropped calls to support.
5. Remove the double NAT — switch the provider’s router to bridge mode or plug the phone straight into it.

Drop after 15 or 30 minutes#

Why it happens#

During a long call the sides now and then confirm that the call is still going — these are session timers. The interval is agreed at the start of the call; one side undertakes to “refresh” the call halfway through the interval, the other waits for the refresh. Our PBX has session timers on with an interval of 1800 seconds (30 minutes); they exist so that a call whose connection vanished silently does not hang for hours and tie up the line.

Hence two signatures:

• around 15 minutes — the refresh was sent halfway through the interval but did not get through: the other side rejected it or never answered;
• around 29.5 minutes — there was no refresh at all, and the side waiting for it hung up just before the interval expired.

Why a refresh does not get through:

1. The router closed the signalling path. During a call the voice flows continuously, while signalling messages are silent. If keep-alive is off on the phone, after a few minutes the router closes the “door” for signalling — and the refresh from the PBX no longer reaches the phone.
2. The phone does not understand the refresh method or rejects it — old firmware, a “Session Timer” turned on with non-standard parameters.
3. SIP ALG mangles the refresh message.
4. The carrier’s timer — if only external calls drop, and always at the same minute.

The PBX only uses session timers in a call if the phone supports them too ⚠️ verify. On most desk phones “Session Timer” is off out of the box (on Yealink and Grandstream — according to their documentation), and then the call has no session timers at all.

What to do#

1. Turn on keep-alive in the phone — it keeps the signalling path open during a call too. Yealink: Account → Advanced → Keep Alive Type (Default or Options) and Keep Alive Interval — 30 s (the factory value).
2. Turn off SIP ALG on the router.
3. If someone switched on “Session Timer” in the phone, return it to the factory value (off) or set the interval to 1800 s: Yealink — Account → Advanced → Session Timer / Session Expires; Grandstream — Account → SIP Settings → Session Timer (Enable Session Timer, Session Expiration).
4. Update the phone’s firmware — bugs in refreshing calls are often fixed in newer versions.
5. Only external calls drop, at the same minute every time — send the call times to support: we will check the timers against the carrier.

Incoming calls only work for the first minutes after power-on#

Why it happens#

The phone sits behind a router, and the PBX can reach it only through the “door” the phone opened with its last message. A router keeps such doors open only briefly — on home routers from half a minute to a few minutes of silence — and then closes them. As long as the phone sends something often (registration right after power-on, keep-alive), the door is open. Once it goes quiet, the door closes, and an incoming call from the PBX runs into the router.

The dot in the admin panel may stay green meanwhile: the phone refreshes its registration itself, from the inside, and that goes through, but getting in to the phone from outside is no longer possible. A reboot “cures” it because it opens the door again — for a while.

On its side, our PBX checks every device every 60 seconds with an “are you there?” request: that incoming packet also keeps the door open — but only if the router takes longer than a minute to close it. If the device does not answer, the PBX considers it unreachable, the dot goes out, and a gap appears in “Uptime”.

What to do#

After each step, test an incoming call after 10 idle minutes (with the “Call this phone” button or from the extension next to it); go further only if it did not help.

1. Turn on keep-alive in the phone with a 20–30 second interval. Yealink: Account → Advanced → Keep Alive Type / Keep Alive Interval (factory Default and 30 s); on Fanvil — Keep Alive Type in the line’s advanced settings.
2. Turn off SIP ALG on the router — it also likes to “forget” doors.
3. Shorten the registration period in the phone (Expires / Register Expiration) to 60–120 seconds — the phone will open the door itself more often. Our PBX does not accept less than 60 (423 Interval Too Brief).
4. On a dedicated PBX, devices can be checked more often: “Advanced SIP settings” → “Liveness check, seconds” — 20–30 instead of 60. This holds the door from the PBX side but adds signalling traffic; the phone’s keep-alive is more reliable.
5. Double NAT (provider’s router + your own) means two doors that close differently: remove one — “Network, router and internet”.

Drop when switching from Wi-Fi to mobile data#

Why it happens#

The venue’s Wi-Fi and mobile data are two different addresses. The call started from one, and at the start of the call the PBX remembered where the voice comes from: for security reasons it accepts audio only from that address. When the smartphone switches to the mobile network, the voice starts arriving from a new address — to the PBX that is now a foreign stream — while signalling keeps going to the old address, which no longer exists. A call started on one network almost always breaks on moving to another. This is a limitation of the technology itself, not a fault.

The other side of the same thing: while the smartphone is switching, the softphone loses its registration, and incoming calls in those seconds do not get through. On top of that, Android puts background apps to sleep — more in the overview, in the part about softphones.

What to do#

1. Do not change networks during a call: finish the call before leaving Wi-Fi range.
2. Turn off automatic switching from weak Wi-Fi to mobile data on the smartphone (on iPhone — “Wi-Fi Assist”, on Android — “Switch to mobile data” in the Wi-Fi settings): right now it breaks the call on the café doorstep.
3. Allow the softphone to run in the background and exempt it from battery optimisation — then it re-registers faster after a network change.
4. Where a call must not be lost (the counter, the reception), use a desk phone or a DECT handset rather than a smartphone.

What to send to support#

• the date and time of several dropped calls to the minute, the numbers and the extension;
• after how long it drops (the “Talk” value in the log) and whether it is always the same;
• whether all calls drop or only external ones; whether a long *43 (45 seconds) holds;
• the phone’s model and firmware (the string from the equipment tag), whether keep-alive and Session Timer are on in it;
• the router model, whether SIP ALG is off, whether there is a second router from the provider;
• on a dedicated PBX — the SIP trace text of a repeated drop.

How to reach us — “Support”.

Frequently asked questions#

Why exactly at 32 seconds, not at 30 or 40?#

Because that number is built into the SIP protocol itself: the confirmation that a call started is awaited for 64 intervals of half a second — 32 seconds. If yours is “about 30 seconds” and the same every time, this is it, even if the stopwatch said 31 or 33: part of the time went on ringing and answering.

SIP ALG is off, but the drop at 30 seconds remains — what else?#

Check that ALG is off on every router along the way (the provider’s router often has its own), leave three codecs in the phone and try TCP transport. If only external calls drop while *43 holds for 45 seconds, the problem is on the stretch to the carrier — send the call times.

The dot is green but incoming calls do not arrive — is that a “drop” too?#

It is the same mechanism as in the section about incoming calls for the first minutes: registration is refreshed from the inside, while the door to the phone from outside is already closed. The check is “Call this phone” after 10 idle minutes; the fix is keep-alive in the phone.

Can I just turn off session timers on the PBX?#

You can (on a dedicated PBX, “Advanced SIP settings”), but that treats the symptom, not the cause: the refresh does not get through because the signalling path is closed or mangled, and that same path is needed for call transfer and hold. Besides, without timers, calls that died silently will hang for hours and tie up the lines. Keep-alive and SIP ALG first.

Related sections#

• Phone not working: troubleshooting by symptom — including “no incoming calls while outgoing work”
• No audio, one-way audio, echo, “robot” voice
• Not registering: on-screen messages and error codes — “registers, then drops off”, 423 Interval Too Brief
• Network, router and internet for telephony — where to turn off SIP ALG, double NAT
• SIP Phone Setup — venue network, checking call quality
• Call log and SIP trace

Sources#

• RFC 3261 — SIP: retransmitting 200 OK until the ACK arrives and ending the session after 64 × T1 (§13.3.1.4), T1 = 500 ms (§17.1.1.1), switching to TCP for messages longer than 1300 bytes (§18.1.1) — https://www.rfc-editor.org/rfc/rfc3261
• RFC 4028 — Session Timers: refresh halfway through the interval, BYE min(32 s, interval / 3) before expiry — https://www.rfc-editor.org/rfc/rfc4028
• Yealink SIP-T2/T3/T4/T5/CP920 Administrator Guide V86.60 — Keep Alive Type / Interval (factory Default, 30 s), Session Timer (off by factory default; Session Expires 1800 s; refresh at half the interval)
• Grandstream GRP261x/262x/263x Administration Guide — Session Timer: Enable Session Timer (factory “No”), Session Expiration, Min-SE — https://documentation.grandstream.com/knowledge-base/grp261x-grp262x-grp263x-series-administration-guide/
• Zoiper 5 User Guide v1.0.7 — UDP and the packet size limit, router NAT timeouts — https://www.zoiper.com/pdf/User%20Guide%20Zoiper%205%20v.1.0.7.pdf
• PBX code: shared/sip/advanced-options.json (timers=yes, timers_sess_expires=1800, timers_min_se=90, qualify_frequency=60, minimum_expiration=60, rtp_timeout=0, force_rport, rewrite_contact), sip-edge/asterisk/rtp.conf (strictrtp=yes), sip-edge/sipsync/linecheck.go (the *43 echo test, a 300 s cap on the test)