Summary

  • RFC 4028 defines a SIP session refresh as an in-dialog re-INVITE or UPDATE whose 2xx response extends the negotiated session expiration. Sending the request, receiving 422 or observing signaling traffic is not enough.
  • Session-Expires, Min-SE and refresher allocate timing and cleanup duties among endpoints and proxies. They do not establish media flow, human presence, service quality, consent or charging authority.
  • A reliable operating model keeps transaction, dialog, media, application and commercial evidence separate, then reconciles them before declaring a call alive, ended or billable.

The green event beside a silent call

Consider a managed voice service with a call-stateful proxy, two user agents and an RTP path that does not follow the signaling route. Halfway through the call, the assigned refresher sends an UPDATE without SDP. The other endpoint returns 200 OK. The proxy records a successful session refresh and moves its expiration forward.

At the same moment, an unrelated network failure has stopped media in one direction. RTCP reports are missing. The user has already put down the handset, but the endpoint application has not produced BYE. A charging system consumes only the proxy's “session refreshed” event and extends the billed duration.

Nothing in that sequence requires a broken implementation of the session timer. The 2xx can be valid. The expiration can be correctly extended. The media can still be dead, the human can still be absent and the invoice can still be wrong.

RFC 4028 was designed to solve a narrower problem. Core SIP could leave call-stateful proxies holding state when a user agent failed to send BYE or when BYE was lost. Periodic re-INVITE or UPDATE requests give endpoints and intermediaries a bounded way to decide when SIP session state has gone stale. The standard even explains why this signaling mechanism is separate from session-specific liveness such as RTCP.

That separation is the key. A timer refresh is not a universal heartbeat. It is a successful signaling transaction with a defined effect on a defined expiration.

Three clocks hiding inside one field

Operational dashboards often reduce RFC 4028 to “Session-Expires equals call timeout.” The standard carries three different ideas.

The session interval is the maximum period permitted between successful refreshes. Its operative value comes from the Session-Expires field in the most recent 2xx response to a refresh request.

The minimum timer is the smallest interval an element is willing to tolerate. Mid-dialog requests cost processing capacity, so a proxy or endpoint can reject a proposed interval that would force refreshes too frequently. Min-SE expresses this floor.

The session expiration is a local deadline calculated by each participating element. The UAS calculates from transmission of its last 2xx. The UAC calculates from reception. A proxy calculates from the response it forwards. Network transit and processing mean these deadlines are related but not identical. They are not one attested global timestamp.

The distinction matters in an incident. “The interval was 1,800 seconds” does not identify which response installed it, when each element started its clock, whether a later response turned the timer off, or which endpoint was responsible for refreshing.

It also matters in design. A local monotonic deadline is safer than a wall-clock timestamp exposed to clock adjustments. A reconstruction record should preserve both the source event and the calculated deadline rather than inventing one canonical clock after the fact.

Negotiation runs through the path

The timer is not chosen by one endpoint alone. A UAC can advertise support with the timer option tag and request a session interval. Proxies on the signaling path may care because they retain call state. A proxy can request a timer, lower the proposed Session-Expires value, or raise the minimum interval. It cannot force a value below the accumulated Min-SE floor.

The UAS returns the final interval in a 2xx response and adds a refresher parameter. As the response travels back, proxies can observe the result but cannot rewrite the final value.

If a proposed interval is below an element's permitted minimum, the element returns 422 Session Interval Too Small with Min-SE. The UAC may retry as a new transaction, using a higher CSeq and retaining the largest relevant minimum it has learned.

This is constraint convergence, not a successful refresh. Only a 2xx extends expiration. A 422 received near the old deadline can therefore create an uncomfortable race: the next request may propose a longer future interval, but it still has to complete before the current expiration. Recording only the eventual 200 hides the period in which continuity was genuinely at risk.

The minimum exists partly as a denial-of-service control. Without it, a hostile endpoint or path element could demand refresh traffic at an extreme rate. A sudden increase in 422 responses can mean a policy change, a path change, overload protection, bad defaults or an attempt to force work. Those possibilities require different owners and remedies.

uac and uas are roles, not people

The final refresher=uac or refresher=uas value assigns the duty to generate the next refresh. It does not name the permanent caller, the paying customer or the owner of the session.

UAC and UAS are transaction roles. The endpoint that was UAS for the initial INVITE can become UAC when it sends a later UPDATE. RFC 4028 gives rules for setting the parameter on subsequent requests so the actual refresher can remain stable even as transaction roles reverse.

A log entry that says only refresher=uac is therefore incomplete. A useful record maps the role to the endpoint identity for that transaction, the dialog, method, CSeq and direction. Without that mapping, a later analyst can assign responsibility to the wrong party.

Forking adds another boundary. One initial INVITE can establish several dialogs. Each dialog can have a different interval, refresher and expiration, or no active timer. A call-level record that merges these branches can make a refresh on one dialog appear to preserve another.

The role may also be reselected. A subsequent negotiation can preserve the refresher, deliberately change it or omit the timer. If the most recent 2xx contains no Session-Expires, the timer can be turned off in mid-dialog. “The call once had a timer” does not prove that it still does.

The only event that moves the deadline

RFC 4028 draws a bright line: only a 2xx response to a session refresh request extends the expiration.

Sending an UPDATE does not. Receiving a provisional response does not. A 401 or 407 challenge does not, although an authenticated retry may later succeed. A 422 does not. A proxy seeing the request enter its network does not. A successful transport write does not.

If a refresh transaction times out or produces 408 or 481, the refreshing UA sends BYE under the SIP rules. Other errors can permit a bounded retry, but the UA should not retry the same failure forever.

The non-refresher has a different obligation. If it sees no refresh before expiration, it should send BYE shortly before the deadline. The recommended lead is the smaller of 32 seconds and one third of the interval. The margin acknowledges a practical boundary: firewalls and NAT application gateways may stop passing SIP traffic at the expiration itself.

A call-stateful proxy has less authority. When its local deadline passes, it may delete its own call state and release its resources. It must not originate BYE. The proxy is entitled to clean its ledger; it is not entitled to impersonate an endpoint and declare the conversation ended.

That difference creates observable disagreement. A proxy may have removed state while media continues directly. One endpoint may have sent BYE that never arrived. The two endpoints may reach their deadlines at slightly different moments. A responsible system records these as separate events instead of replacing them with a single synthetic hang-up time.

A refresh can carry more than a heartbeat

A session refresh is an ordinary re-INVITE or UPDATE. It inherits the semantics and hazards of that method.

RFC 3311 defines UPDATE as a request capable of changing session information before or after a dialog is confirmed. UPDATE is also a target-refresh request. RFC 3261 makes re-INVITE part of dialog and offer/answer processing and gives it target-refresh effects.

RFC 4028 recommends an offerless UPDATE for a pure timer refresh when the peer supports UPDATE. A re-INVITE normally carries an offer even when the session description is unchanged, and unchanged SDP must be marked accordingly. A request sent for another purpose can also refresh the timer.

One 2xx can therefore sit beside several different facts:

  • the timer was extended;
  • the remote target changed;
  • an SDP offer and answer completed;
  • a stream moved to hold or returned;
  • a codec or address changed;
  • authentication was challenged and retried;
  • a race with another offer was resolved.

RFC 6141 exists because re-INVITE handling is not a trivial ping. Overlapping requests, offer/answer restoration, 491 responses and target changes can create subtle state alignment problems. A timer dashboard that records only “refresh success” can hide an operationally important media or routing change in the same transaction.

The audit record should say whether the request was intended as timer-only, whether it carried SDP, whether the SDP origin version or stream directions changed, whether Contact changed, and which response completed the transaction.

Signaling alive is not media alive

RFC 3264 defines offer/answer as a negotiated description of media streams. A stream can be sendonly, recvonly, sendrecv, inactive or rejected with port zero. These are negotiated states. They are not packet-delivery proofs.

RFC 3550 is equally precise about RTP. RTP does not guarantee delivery or quality of service. RTCP provides reception reports, timing, participant identity and limited session-control information. It can supply valuable evidence about flow and quality, but it does not prove a human listened, understood, consented or received business value.

The evidence chain should therefore retain at least five layers:

  1. the SIP transaction — method, CSeq, authentication, response and timing;
  2. the dialog and timer — Call-ID and tags, route set, interval, refresher and expiration;
  3. the media path — RTP counters, RTCP reports, loss, jitter, direction and last packet;
  4. the application and human state — device mode, user action, feature state and session purpose;
  5. the commercial and compliance state — entitlement, charging, recording and dispute rules.

A 2xx refresh can be strong evidence in the first two layers while saying almost nothing about the last three. Media can fail while refreshes succeed. Media can continue while signaling is partitioned. An intentionally inactive stream can coexist with a valid timer. A user can leave while software continues to refresh.

This is where Heng Lu's distinction between symbolic and practical control becomes operational. The signaling record is not fake; it is simply smaller than the reality it is often asked to govern. Running media systems, endpoints, policy engines and billing platforms decide what becomes service reality.

Path integrity has a boundary too

Session-timer fields are designed to be changed by proxies. End-to-end S/MIME cannot protect a field that legitimate intermediaries must modify. RFC 4028 therefore recommends hop-by-hop integrity using TLS on each relevant hop and the SIPS scheme.

That protection matters. An outsider able to alter Session-Expires or Min-SE can force rapid refresh traffic or change cleanup behavior. A malicious path insider can also exploit its legitimate position, although minimum-timer rules limit some amplification.

Hop protection does not make the timer an end-to-end attestation. Its strength is only as complete as the protected path. It authenticates or protects signaling relationships according to SIP's security setup; it still does not prove media, presence, charging or intent.

The RFC Editor's RFC 4028 errata registry reinforces the need for disciplined interpretation. Verified errata correct UAC/UAS wording and example details. A May 2026 report questions one proxy behavior when a UAC explicitly requests refresher=uas; its status remains Reported. Operators can test the interoperability question, but they should not present an unresolved report as amended law.

An evidence path that can survive a dispute

A defensible session-timer record binds the dialog identity to each transaction's actual endpoint roles. It preserves method, CSeq, branch, route, timer fields before and after each proxy, request and response timestamps, calculated deadlines and the exact event that moved them.

It also records side effects: SDP presence and hash, offer/answer version, stream directions, Contact changes, authentication challenges and error retries. BYE needs an origin and cause — user action, refresh timeout, peer timeout, application policy or another reason.

Media and application evidence remain separate. The general telemetry plane may keep compact projections or keyed hashes while restricted incident storage preserves the signaling needed for reconstruction. SIP messages expose identity and topology; accountability does not require publishing them indiscriminately.

Tests should cover a 422 near expiry; 401 followed by successful retry; 408 and 481; missing refresh at the non-refresher; proxy cleanup without endpoint BYE; media failure during continued refresh; media continuation after signaling loss; forked dialogs with different timers; timer removal by a 2xx without Session-Expires; offerless UPDATE; re-INVITE with unchanged and changed SDP; target changes; failover that loses dialog state; and a path where one hop lacks the expected integrity protection.

The result is not one green call-state bit. It is a reconstruction that explains which layer stayed alive, which did not, and who had authority to act.

Sources