Asterisk call drops when a PJSIP session refresh is due

Prove that the drop aligns with an agreed session timer

For a failing call, preserve the initial INVITE, final 2xx and ACK on each Asterisk leg. Record the accepted Session-Expires interval, refresher parameter, any Min-SE, Call-ID, tags, CSeq and exact start and end times. A repeatable duration near a round number is a clue, not proof; the dialog must have negotiated the timer.

If no Session-Expires was accepted, continue with signaling transport, RTP inactivity, application hangup, carrier policy, NAT or firewall evidence. Do not enable or disable timers merely to make the symptom resemble a theory.

Find the refresh request and the component that stopped it

Follow the named refresher's re-INVITE or UPDATE from sender to responder. Preserve every observation point, retransmission, response and ACK. Distinguish no request generated, request leaving Asterisk but not arriving, peer rejection, response lost on return, dialog mismatch, authentication challenge, 422 minimum conflict and successful transaction followed by a separate hangup.

Record which component sent BYE or released the channel and its cause at that time. A later BYE can be cleanup after an earlier refresh or media-path failure; its presence does not identify where the first packet was lost.

Inspect the loaded endpoint on the affected leg

Use the channel identity to locate the exact loaded PJSIP endpoint, then inspect timers, timers_min_se and timers_sess_expires. Asterisk 22 documents defaults of yes, 90 and 1,800 seconds, but defaults and saved configuration are not incident evidence. Preserve the running values and their configuration owner.

Repeat for the other Asterisk leg. A trunk endpoint's policy can differ from a phone endpoint's policy, and Asterisk can be refresher on one dialog while the remote peer refreshes the other. Do not apply one provider minimum to unrelated devices globally.

Keep refresh failure separate from glare and media loss

If the refresh receives 491 because another in-dialog offer is in progress, follow the retry and the transaction that overlapped it with the re-INVITE glare investigation. If the refresh receives 422, follow the Session Interval Too Small investigation. A 481, 408 or transport loss needs its own request-path evidence.

Track RTP on both directions independently. Continuous media does not prove the signaling refresh succeeded, and silence does not prove timer expiry. Compare any rtp_timeout threshold with last received RTP on the channel that actually released, not merely total call duration.

Correct one demonstrated owner and observe a natural refresh

Correct only the loaded endpoint policy, peer minimum, refresher routing, dialog state, proxy or firewall handling, transport persistence or overlapping transaction demonstrated by the trace. Preserve management-system ownership and generated configuration. Disabling timers can remove stale-session detection or violate peer policy; increasing every timeout can only postpone an unidentified failure.

Create a fresh call and observe the negotiated values, one complete natural refresh, media continuity and ordinary hangup. If an authorized lab uses PJSIP_SEND_SESSION_REFRESH() to reproduce the path, keep the documented media-renegotiation warning in scope and still verify the natural interval. No host, endpoint, trunk, intermediary, dialog, timer, request, response, packet path, media stream or call was tested for this diagnostic.

Distinguish immediate dialplan refresh from timer expiry

Use the PJSIP_SEND_SESSION_REFRESH guide when an application deliberately triggers the renegotiation rather than assuming every mid-call refresh came from Session-Expires.