VoIP.info Troubleshooting

VoIP calls drop at unpredictable times

Correlate termination with network, device and PBX events instead of changing timers blindly.

Reviewed 2026-09-07Asterisk 22 LTS · FreePBX 17 / Debian 12 checksIntermediateDocumentation based · not lab tested

Build an incident timeline

Collect several timestamps, call directions, durations and affected endpoints. Ask whether only one site, carrier route or device family is involved. Random-looking failures can correlate with a WAN failover, device reboot, scheduled job or resource spike.

Find who terminated the call

Inspect a bounded signaling trace for BYE or another final event and identify its source. If signaling disappears entirely, compare network and device logs. An application timeout after media loss differs from a participant intentionally hanging up.

For a relaying PBX, inspect both legs because it can translate an upstream failure into a local hangup. Keep carrier call identifiers for support correlation.

Compare infrastructure events

Review interface changes, power interruptions, DHCP/address changes, VPN reconnects and host resource alerts around the same time. Include recording storage and backup jobs in a self-hosted deployment. A normal average CPU chart can hide a short spike.

Validate with the original conditions

Correct the observed cause, then repeat calls through the affected topology during comparable load. Avoid disabling session or media timers globally as an experiment. Preserve the pre-change values and confirm that abandoned calls still clear correctly after the repair.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.