Asterisk PJSIP session timers: endpoint policy, negotiated refresh and expiry

Separate configured policy from the negotiated timer

Asterisk 22 documents timers on a PJSIP endpoint with modes no, yes, required and always, plus timers_min_se and timers_sess_expires. The reference lists defaults of yes, 90 seconds and 1,800 seconds respectively. Those values describe loaded endpoint policy; they are not proof of the Session-Expires, Min-SE or refresher role accepted in one dialog.

Record the exact channel and loaded endpoint for each Asterisk leg, then preserve the initial INVITE, successful response and ACK. Asterisk is a back-to-back user agent, so the phone-facing and trunk-facing dialogs can negotiate different intervals, methods and refresher owners.

Read Session-Expires, Min-SE and refresher together

RFC 4028 uses Session-Expires to carry the interval and can name the user-agent client or server as refresher. Min-SE establishes a lower bound, including in a 422 response when a proposed interval is too small. The timer option tag expresses support or requirement; its presence alone does not establish the interval that a successful dialog accepted.

Follow the complete negotiation on the affected leg. A successful 2xx response can revise the interval or refresher, while a 422 retry is a new transaction. Keep initial offer, final answer and any learned minimum together rather than reading a single header out of context.

Follow the refresh as an in-dialog transaction

The refresher sends an in-dialog re-INVITE or UPDATE before expiry. Preserve Call-ID, tags, CSeq, route set, method, Session-Expires, SDP if present, response and ACK where required. A successful refresh extends the session; a request that never reaches the peer, receives an error or cannot complete can leave the session eligible for termination under the timer rules.

A re-INVITE or UPDATE can also renegotiate media, change hold state or serve another purpose. Establish that the observed request carries the session-timer state before classifying every mid-dialog request as a timer refresh.

Use explicit refresh injection only as a controlled test

Asterisk 22 documents PJSIP_SEND_SESSION_REFRESH() as an immediate refresh on an established media session, using re-INVITE by default or UPDATE when selected. It is especially associated with media-offer renegotiation, not a passive timer inspector.

The same documentation warns that the function does not check or enforce the formats supported by the endpoint and that offering unsupported formats can cause loss of media. Use it only in an authorized, reversible test with an existing answered channel, a known media offer and a rollback plan; do not add it globally to hide a natural refresh failure.

Keep other clocks outside the session-timer diagnosis

Registration expiration controls a contact binding. OPTIONS qualification measures a target's response to a probe. rtp_timeout observes received media inactivity. SIP transaction timers govern request retransmission and timeout. A NAT or firewall state timeout belongs to another device. Similar numeric values do not make these clocks interchangeable.

Build parallel signaling and media timelines. A call can lose audio before a later BYE, or preserve audio while a refresh request is misrouted. Correct only the owner demonstrated by the trace and loaded configuration.

Retest the whole interval and ordinary call lifecycle

After a bounded correction, establish a new call, preserve the negotiated interval and refresher on both Asterisk legs, observe at least one successful natural refresh and verify media before and after it. Then test ordinary local and remote hangup and the deployment's hold, transfer or direct-media branches where relevant.

Do not report success from the absence of 422, from one manually injected request or from a call ended before the interval. No host, endpoint, trunk, intermediary, dialog, timer, request, response, media stream or live call was tested for this guide.

Do not confuse a media refresh with timer maintenance

PJSIP_SEND_SESSION_REFRESH() can carry a changed media offer by re-INVITE or UPDATE, but its explicit renegotiation role is narrower than natural session-timer ownership. The media-offer guide keeps those reasons separate.

Keep manual refresh actions separate from Session-Expires policy

An immediate PJSIP_SEND_SESSION_REFRESH action is not proof of the negotiated timer refresher role or later expiry behavior.