Session Timer Refreshes

What It Measures

Session Timer Refreshes counts the number of SIP session timer re-INVITE or UPDATE transactions that occurred during a call. RFC 4028 defines a mechanism for SIP sessions to send periodic in-dialog re-INVITEs or UPDATEs — called refreshes — to confirm that both endpoints and all intermediate proxies are still alive and the session remains valid.

If a refresh transaction fails to receive a response, the refreshing endpoint terminates the call. This mechanism exists to clean up calls that have become "orphaned" — where one side has disappeared without sending a proper BYE, leaving the other side and intermediate proxies holding session state indefinitely.

Why It Matters

Session timers are a silent reliability mechanism — when they work, you never notice them. When they fail, calls drop unexpectedly on long-duration sessions with no warning and no obvious cause.

The "30-minute call drop" pattern is the canonical symptom: calls that work fine for short durations start dropping at a consistent interval — often 30, 45, or 60 minutes. The pattern is reproducible. The Final Status Code is typically 408 Request Timeout or 481 Call Leg Does Not Exist. The issue: session timers are enabled but a proxy or SBC in the path is not forwarding the refresh re-INVITEs.

This is one of the most common VoIP production bugs in enterprise SIP deployments. An organization deploys a new SBC or firewall, and long calls start dropping. The new device is stateful and the session timer refreshes are not passing through correctly.

For call center and conference bridge applications, where calls can last hours, session timer failures directly translate to abandoned calls and service disruption.

The refreshes count provides two useful signals:

1. Is the expected number of refreshes occurring? For a 60-minute call with a 30-minute session interval, you expect approximately 2 refreshes. Zero refreshes on a long call means session timers are not active (negotiated or not supported by one endpoint).
2. Did any refresh transactions fail? Correlate refresh count with call duration. A call that should have had 4 refreshes but dropped after 2 had a refresh failure — and the Final Status Code at that point confirms it.

Thresholds

There is no fixed threshold — expected refresh count depends on session duration and the negotiated session interval. Use this reference:

Flag these conditions:

How to Fix It

1. Check that refreshes are being forwarded. If session timers are configured and calls drop at interval boundaries, capture a SIP trace and verify the re-INVITE is being sent, forwarded, and receiving a response at every hop.
2. Verify SBC session timer support. Some SBCs support only UPDATE for refreshes (not re-INVITE), or require explicit configuration. Check that your SBC's session timer mode matches your endpoint configuration.
3. Check for NAT timeout issues. The session timer mechanism was designed partly to work around NAT keepalive requirements. If a NAT device closes the UDP pinhole between refreshes, the next refresh fails. Shorten the session interval below the NAT timeout.
4. Disable session timers if not needed. If your infrastructure does not have orphaned call problems, disabling session timers (or setting them to very long intervals) eliminates the risk of unexpected drops.
5. Monitor the Supported: timer header. Session timers are only active when both endpoints negotiate support via the Supported: timer and Session-Expires headers in the SDP exchange.

Related Metrics

• Call Duration — Session timer refreshes are expected at regular intervals relative to call duration
• Final Status Code — 408 or 481 at consistent call durations indicates session timer failure
• Final Reason Phrase — Reason text at call termination may reference session expiry
• Hold Count — Hold events trigger re-INVITEs that may interact with session timer state