Why 15 minutes when the session timer is 30?

Because the refresher acts at half the negotiated expiry (a safety margin built into RFC 4028 practice). A 30-minute Session-Expires with a failed refresh surfaces as a teardown right after the 15-minute refresh fails and retries exhaust.

It only happens on calls to one provider/destination.

Timers are negotiated per dialog and enforced per path — one carrier's SBC policy or one route's NAT behavior differs from others. That selectivity is consistent with a timer fault and narrows the configuration to compare.

Can we just disable session timers?

You can align them instead: both ends agreeing on the mechanism (or cleanly declining it with supported negotiation) is safer than one side silently assuming refreshes that never come. Disabling on your PBX while the provider still enforces expiry changes nothing upstream.

Troubleshooting · Symptoms

Calls Drop After Exactly 15 or 30 Minutes

By the VoIP Cost Guide Editorial Team | Last updated: October 2026

Support calls that die at 32 minutes. Conference calls that end at 15:00 like a parking meter. A call dropping at a consistent, repeatable duration is the most informative symptom in VoIP — randomness implicates the physical world, but a timer implicates configuration: something in the path is counting, and when it reaches zero it kills the call.

Three timers account for nearly every case: the SIP session timer refresh failing, a NAT/firewall UDP state timeout, and a provider or PBX maximum-session or refresh policy. This guide separates them.

Suspect 1: SIP session timers (RFC 4028)

Session timers keep calls 'refreshed': one side periodically sends a re-INVITE or UPDATE, and if the refresh fails, the call is torn down. Sessions commonly negotiate a 1800-second (30-minute) expiry with refresh at half that (15 minutes) — which is precisely why drops cluster at 15 and 30 minutes. The refresh fails when the re-INVITE never arrives (NAT pinhole for signaling closed), arrives malformed (an ALG or SBC mangles it), or is rejected (a 481/488/501 from a confused endpoint). In the capture, the signature is unmistakable: a re-INVITE or UPDATE at the refresh point, no successful response, retries, then a BYE.

# The smoking gun in a ladder view
00:00  INVITE / 200 OK    Session-Expires: 1800;refresher=uac
15:00  re-INVITE ------->  (no response — NAT pinhole closed)
15:00  re-INVITE ------->  (retry)
15:01  re-INVITE ------->  (retry)
15:32  BYE <--------------  call torn down

Suspects 2 and 3: state timeouts and platform policies

UDP NAT/firewall timeout: many NAT devices age out idle UDP mappings in 30–120 seconds; signaling survives because registrations refresh it, but some paths (a quiet signaling association, a media-only flow) let the mapping lapse — then the refresh or the media hits a closed door. Media itself usually keeps its own pinhole open; signaling-only flows are the vulnerable ones.
SBC/provider session policy: carriers and SBCs enforce maximum call durations and media-inactivity policies (RTP inactivity timers of 30–60 minutes exist on real platforms). Held music / muted long calls with zero RTP trip inactivity timers — the 'our board call dies at 30 minutes while on hold' variant.
PBX/license timers: some systems enforce per-call duration limits in class-of-service settings — worth one settings check before deep network surgery.

Fix sequence

Reproduce deliberately: place a test call and let it run past the failure point while capturing. Note the exact drop second across two attempts — consistent to the minute confirms a timer.
In the capture, find what happens at the refresh point (usually half the drop duration): a re-INVITE/UPDATE failing, or nothing at all (refresh never sent — an endpoint/session-timer negotiation issue).
If the refresh is sent but unanswered: the signaling path's NAT/firewall state is expiring. Raise UDP timeout values on your firewall (to at least 300s for SIP), enable keepalives, and disable SIP ALG on the path.
If the refresh is rejected or mangled: compare the re-INVITE against the original INVITE — an SBC or ALG altering headers mid-dialog is the classic culprit; align session-timer support (refresher role and Min-SE) between your system and the provider.
If no refresh exists and media simply stops: suspect inactivity timers — check SBC/provider media-timeout settings, especially for calls that sit muted or on hold.
Verify with a call held past two full refresh cycles (e.g., 65 minutes for a 30-minute fault) before closing the ticket.

Frequently asked questions

Why 15 minutes when the session timer is 30?: Because the refresher acts at half the negotiated expiry (a safety margin built into RFC 4028 practice). A 30-minute Session-Expires with a failed refresh surfaces as a teardown right after the 15-minute refresh fails and retries exhaust.
It only happens on calls to one provider/destination.: Timers are negotiated per dialog and enforced per path — one carrier's SBC policy or one route's NAT behavior differs from others. That selectivity is consistent with a timer fault and narrows the configuration to compare.
Can we just disable session timers?: You can align them instead: both ends agreeing on the mechanism (or cleanly declining it with supported negotiation) is safer than one side silently assuming refreshes that never come. Disabling on your PBX while the provider still enforces expiry changes nothing upstream.

Sources and further reading

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.