VoIP calls drop at unpredictable times

Build a comparable incident set

Collect exact answer and failure timestamps, call direction, duration, endpoint, site, trunk, transport, hold or transfer state and each audio direction. Keep a control call through the same path. A failure that looks random in user reports may align with one carrier route, device family, WAN transition, address renewal, scheduled task or resource event once the fields are normalized.

Preserve the PBX channel identifiers, SIP Call-ID values and carrier correlation identifier for each incident. Do not merge CDR duration, dialog lifetime and media-observation window into one timestamp.

Classify the first terminating event

Use the earliest causal evidence, not the last BYE visible to the phone. Classify the event as an explicit participant or application BYE, failed initial-answer ACK, failed session refresh, configured RTP inactivity hangup, transport loss, process or device restart, dialplan or application limit, or an unresolved disappearance. A Reason or Q.850 value is an assertion from one element and must be correlated with its preceding events.

For a relaying PBX, inspect both dialogs. The PBX can translate an upstream timeout into a clean downstream BYE, so the message closest to the user may be a consequence rather than the initiating fault.

Inspect negotiated and effective timers

For each affected dialog, record Session-Expires, Min-SE, the named refresher and any mid-dialog re-INVITE or UPDATE. Only a successful 2xx refresh extends a session under RFC 4028. Keep that state separate from the Asterisk endpoint's rtp_timeout and rtp_timeout_hold, which count a lack of received RTP, and from transaction timers such as T1 and Timer B.

Read the effective running endpoint and system configuration rather than a template or GUI field. Do not infer that a setting is active from its presence in a generated file, and do not interpret an OPTIONS reachability result as proof that an established dialog or media path stayed healthy.

Correlate media, connection and host events

Compare the last RTP packet received at the component that declared inactivity with sender-side and receiver-side observations. Direct media, hold SDP, address or port changes and encrypted media can change the valid capture point. A gap in one capture does not establish that the sender stopped, and outgoing keepalive packets do not prove inbound media arrived.

Review interface transitions, NAT or firewall state, TCP or TLS connection events, DHCP or public-address changes, VPN reconnects, endpoint reboots, PBX restarts, process crashes, storage pressure and brief resource saturation at the same timestamp. Include recording and backup activity where it can affect the call path; a whole-hour average can hide a short incident.

Validate one demonstrated cause under comparable conditions

Make one bounded repair with the previous value and rollback recorded, then repeat calls through the affected direction and topology during comparable load. Keep calls beyond the prior duration range and exercise the triggering hold, transfer or network transition where authorized. Confirm normal participant hangup and cleanup of abandoned calls.

Avoid globally disabling session or media timers, turning off security controls or adding broad keepalives as a diagnostic shortcut. If the first terminating event remains unresolved, preserve the evidence and escalate with exact identifiers rather than declaring the last configuration change a fix. No call, endpoint, network event, resource condition, timer or repair was tested for this guide.

Test a session-timer hypothesis against the dialog

When failures cluster near the accepted Session-Expires interval, follow the Asterisk session-refresh diagnostic. A repeated duration alone does not distinguish session expiry from RTP inactivity, transport, policy or firewall state.