Calls Dropping After a Set Amount of Time

When Your Phones Sound Bad: Part 3 of 12

When VoIP calls drop, they usually fall into one of two patterns. Either they drop randomly and unpredictably, or they drop at a suspiciously consistent interval. The consistent interval is actually the more useful clue because it points to specific causes. A call that drops at exactly 30 seconds is telling you something very different than a call that drops at exactly 15 minutes, and both are different from calls that drop at random times.

This post covers the timer based drops first (because the interval is the diagnosis) and then the random drops.

Calls dropping at exactly 30 to 32 seconds

This is one of the most recognizable patterns in VoIP troubleshooting. The call connects, audio works, and then at almost exactly 30 to 32 seconds the call disconnects. Every time.

The cause is almost always a missing ACK. When someone answers a VoIP call, their phone sends a 200 OK message. The caller's phone is supposed to respond with an ACK to confirm it received the 200 OK. If the ACK never arrives, the answering phone doesn't know whether the caller actually received the answer. It retransmits the 200 OK several times, and if it still doesn't get an ACK after about 32 seconds (this is based on SIP Timer H, RFC 3261 Section 17.2.1, which defaults to 32 seconds), it gives up and tears down the call.

The ACK is being sent by the caller's phone. The question is why it's not arriving at the callee's phone. Common reasons include:

A firewall or NAT device is blocking the ACK. The initial INVITE and the 200 OK made it through because they were part of an established transaction that the NAT device was tracking. But the ACK might be routed differently (in some SIP implementations, the ACK for a 2xx response goes directly end to end rather than through the proxy), and if the direct path is blocked, the ACK is lost.

SIP ALG is mangling the routing information. If SIP ALG on the router is rewriting addresses in the call setup messages, the ACK might be addressed to a location that doesn't match what the callee's phone expects. The ACK is sent but to the wrong address.

The proxy or PBX is not forwarding the ACK correctly. If the proxy or PBX sits in the signaling path and has a bug or misconfiguration related to ACK handling, the ACK might be absorbed without being forwarded to the callee.

The fix follows the standard approach: disable SIP ALG, verify firewall rules, and check the PBX or proxy configuration. If you have access to SIP debug logging on the callee's phone or PBX, look for whether the ACK is arriving. If it's not, capture traffic on the callee's network to see if the ACK is reaching the network at all or being lost somewhere upstream.

Calls dropping at 15 minutes (or another longer interval)

If calls consistently drop at longer intervals like 15 minutes, 30 minutes, or an hour, the likely culprit is a SIP session timer or a NAT timeout.

SIP session timers are a mechanism where both parties agree to periodically refresh the call session. The idea is to ensure that both sides are still present and that the call is still active. The refresh happens through a re-INVITE or UPDATE message sent at intervals specified in the Session-Expires header during call setup.

If the refresh message fails (because a firewall blocks it, the network path has changed, or the PBX doesn't handle re-INVITEs correctly), the session timer expires and the call is terminated. The dropout interval will match the Session-Expires value, which is commonly 1800 seconds (30 minutes) but can be configured to other values.

To diagnose this, check the SIP headers during call setup for a Session-Expires header. If it's present, note the value. If calls drop at or near that interval, session timer refresh failure is the likely cause. Some PBX platforms allow you to disable session timers or adjust the interval. If your calls are otherwise stable, disabling session timers eliminates this as a cause (though it removes the stale session detection benefit).

NAT timeout is the other common cause of calls dropping at consistent intervals. Your router's NAT device maintains a table of active connections. For UDP traffic (which VoIP uses), this table has a timeout, typically between 30 seconds and several minutes. If no traffic passes through a specific NAT mapping within the timeout period, the mapping is removed.

During a normal VoIP call, RTP audio packets flow constantly in both directions, which keeps the NAT mapping alive. But if the call is on hold (where RTP might stop in one or both directions), or if there's a long pause in conversation (and silence suppression is enabled, stopping RTP transmission during silence), the NAT mapping might expire. When audio resumes, the NAT device no longer has a mapping for the returning packets, and the call breaks.

This can also affect the SIP signaling itself. If the SIP session uses keep alive packets to maintain the NAT mapping and those keep alives stop for some reason, the signaling path can break, causing the call to drop.

The fix for NAT timeout issues is to ensure that keep alive intervals are shorter than the NAT device's timeout. Most phones and PBX systems have a keep alive or registration renewal setting. Set it to a value shorter than your router's UDP timeout (which you can usually find in the router's NAT or firewall settings).

Calls dropping randomly

Random drops without a consistent interval are harder to diagnose because there's no timer pointing you to a specific cause. The most common reasons for random drops are:

Internet connection instability. If your internet connection experiences brief outages, even for a few seconds, active VoIP calls may drop. A cable connection that loses sync with the headend for three seconds might not affect your web browsing (the browser just retries), but a phone call experiences three seconds of complete audio loss, and depending on the SIP configuration, the call may be terminated.

Check your modem's logs for sync errors, T3 timeouts (on cable modems), or line errors. These indicate physical layer problems with your connection that cause brief interruptions. If you find frequent errors, contact your ISP. The connection might look fine on a speed test but still have stability issues that affect real time traffic. Running a VoIP quality test during the hours when drops occur will surface the packet loss and jitter spikes a speed test hides.

PBX overload. If your PBX (whether on premises or cloud hosted) is under heavy load, it might fail to process keep alive messages, re-INVITEs, or other maintenance traffic for active calls. When this traffic is missed, calls can be terminated. Check the PBX's CPU and memory usage during the times when drops are occurring. If the PBX is consistently above 80% CPU, it may be struggling to handle the call volume.

Routing changes. If your internet connection or the path between you and your VoIP provider changes mid-call (due to a routing update, a failover event, or an ISP maintenance activity), active calls can be disrupted. This is outside your control but worth knowing about. If drops correlate with your ISP's maintenance window, that's a likely explanation.

Power issues. VoIP phones are typically powered by PoE (Power over Ethernet) from the network switch. If the switch's PoE budget is maxed out, phones can lose power intermittently. A switch that's providing PoE to 24 phones and also powering several access points might run out of power budget, causing phones to briefly lose power and drop their calls. Check the switch's PoE utilization.

Calls dropping when transferred

If calls drop specifically during or immediately after a transfer, the issue is usually with how the transfer is being handled at the SIP level rather than a network problem. Transfers involve a complex sequence of SIP messages (REFER, NOTIFY, a new INVITE to the transfer target), and interoperability issues between different phone brands or PBX platforms can cause transfers to fail.

If transfers consistently fail between specific devices or platforms, check for firmware updates on the phones involved and look for known interoperability notes between the PBX and the phone manufacturer. Some PBX platforms have specific settings for transfer handling that may need to be adjusted for certain phone models.

Calls dropping during hold

If calls drop specifically when placed on hold or when taken off hold, the issue is usually related to the re-INVITE that the phone sends to signal the hold. The hold operation changes the media session, which requires a re-INVITE with modified SDP. If the re-INVITE fails (blocked by a firewall, rejected by the other end, or mangled by a SIP ALG), the hold operation fails and the call may drop.

Check whether the re-INVITE is being sent and received correctly by examining the SIP debug logs. If the phone sends a re-INVITE for hold and never gets a 200 OK back, the re-INVITE isn't reaching the other end or is being rejected.

What to document when reporting dropped calls

When you're reporting dropped calls to your VoIP provider or your IT team, the following information dramatically speeds up diagnosis:

The exact time the call dropped. Down to the minute if possible. This allows the support team to find the specific call in their logs.

The direction of the call. Was it inbound or outbound? To what number?

How long the call lasted before dropping. "About 30 seconds" is very different from "about 15 minutes" is very different from "random."

Was the call active, on hold, or being transferred when it dropped?

Does it happen on all phones or just specific ones?

Does it happen at specific times of day?

Has anything changed recently? New router, new ISP, firmware update, new phones added?

Each piece of information eliminates possibilities and narrows the investigation. A dropped call report that says "calls keep dropping" gives the support team almost nothing to work with. A report that says "outbound calls to external numbers drop at exactly 30 seconds, started happening Tuesday after we replaced the router" gives them everything they need.

Next up: Echo on VoIP Calls, the different types of echo, what causes each one, and how to fix them.