Suppose a customer-service call connects with clear audio in both directions, but longer calls repeatedly end after a similar duration. Short acceptance tests pass while operations keeps reporting dropped calls. SIP session refresh is one part of the call path worth checking alongside media.
This guide is for engineers integrating or operating FreeSWITCH with phones, SBCs and carrier trunks. A repeatable duration is a clue, not a diagnosis or a reason to apply a universal timeout setting.
Establish whether this call negotiated refreshes
RFC 4028 defines session refresh through re-INVITE or UPDATE. Inspect the interval and refresher parameter in Session-Expires, interpreting the refresher role against the direction of that request.
Check the negotiated result in the successful response rather than relying only on the initial offer. Min-SE is the minimum acceptable interval, not a mandatory maximum call length. Registration expiry is also distinct from the duration of an established call.
When session timers are active, sending a refresh is not enough: the corresponding successful response matters. Follow the timeline from the latest successful refresh instead of always measuring from the original answer.
A normal disconnect label can hide a refresh failure
Cisco explains that Meeting Server logs specific timeout reasons when it ends a call because refresh has failed. If the peer sends BYE first, the local record can instead look like a normal remote teardown. The final disconnect label alone does not explain the preceding sequence.
Compare signaling for the same call on the FreeSWITCH and SBC sides. Did the responsible device send the refresh, did the peer receive it, and did the response return? If a request appears on one side but not the other, inspect routing, filtering and connection state between those points before changing timeout settings everywhere.
Preserve error responses and what happened next. A rejected request followed by a correct retry differs from a sequence that never receives a successful response. Capturing only the BYE near disconnection can miss the earlier failure.
Read configuration alongside live signaling
The current FreeSWITCH Sofia documentation lists enable-timer, session-timeout and minimum-session-expires. They concern enabling timers, the session interval and the minimum acceptable interval. Documentation does not establish what your running version and active Profile actually use. Check the version, loaded configuration and observed signaling together.
For projects involving several suppliers, agree which node initiates refreshes, which nodes carry them and how failures are recorded. Disabling refresh globally or lengthening the interval is not evidence of a fix. Preserve the original configuration, test changes outside production and plan a recoverable deployment.
Try three checks in a non-production project: keep a normal call active across multiple negotiated refresh cycles; confirm refresh continues after hold and resume; and simulate a refresh failure to see whether both sides' logs explain termination. Choose the test duration from the negotiated interval. One successful short call is insufficient.
This explanation is based on standards and official documentation, not testing in your environment. If captures show continuing successful refreshes, investigate other possibilities such as media timeouts or application call-duration limits instead of treating similar disconnect times as proof of the original hypothesis.