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.
- IETF RFC 3261 — SIP, including linked updates ↗
- IETF RFC 3550 — RTP and RTCP ↗
- Asterisk res_pjsip configuration ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.