Identify the channel and first hangup cause
Find the earliest Asterisk log event that declares media inactivity or initiates hangup, then bind it to the channel, endpoint and dialog leg. Record answer time, hold state, the last RTP packet that Asterisk received for that channel and the first terminating SIP message. A phone receiving BYE from the PBX is observing the consequence; the PBX log must establish why it ended the channel.
Do not classify every repeatable disconnect as an RTP timeout. A missing ACK after the initial answer, a failed session refresh, transport loss, dialplan limit or remote application can produce a similar duration.
Simplified caller-side decision. The CANCEL and BYE requests also receive their own responses; a successful answer racing with cancellation still needs ACK and dialog cleanup.
Inspect the effective off-hold and hold thresholds
The current Asterisk reference defines rtp_timeout as seconds without received RTP while off hold and rtp_timeout_hold as the corresponding on-hold interval. Reaching either configured value hangs up the underlying channel; zero is the documented default and disables that check. These options are independent of SIP session timers.
Inspect the running endpoint configuration and its management source rather than assuming a default or copying a value from another endpoint. For a managed PBX, preserve the module field, generated configuration and effective Asterisk object as separate evidence. Compare the applicable threshold with the measured time since the last received RTP packet, not merely total call duration.
Prove the media direction and topology
Asterisk's timeout is based on RTP received by the relevant channel. It does not prove whether that channel sent RTP, whether a remote endpoint received it or whether decoded audio was audible. Compare the sender-side and Asterisk-side observations using SSRC, sequence, timestamp, payload type, address and port where available. Determine whether media was anchored at the PBX or negotiated directly between endpoints before choosing a capture point.
Ask whether the peer stopped transmitting, sent to an earlier address after renegotiation, changed address or port without a valid exchange, or continued sending packets that the network did not deliver. If Asterisk sees packets yet declares inactivity, retain the exact stream, encryption and endpoint association for version-specific investigation; arbitrary UDP on a media port is not automatically the relevant RTP stream.
Treat hold, silence and keepalive as distinct cases
Preserve the SDP direction before, during and after hold, which side supplies music on hold and whether the channel is actually classified as on hold. A normal silence interval is not automatically missing RTP; an endpoint may continue packets, use silence suppression or change direction according to the negotiated state. Test the exact scenario that triggered the hangup.
Asterisk documents rtp_keepalive as an interval for outgoing comfort-noise keepalive packets. Sending those packets does not establish receipt of RTP from the peer and does not repair a wrong SDP address or failed inbound network path. Likewise, a SIP OPTIONS response does not prove media reception on an established channel.
Keep session refresh evidence separate
If Session-Expires was negotiated, record its interval, refresher role, re-INVITE or UPDATE and response. RFC 4028 treats only a successful 2xx transaction as a refresh and defines separate termination behavior when refresh traffic times out or never arrives. That is a signaling failure, not proof of an RTP timeout, even when the resulting BYE reaches the same phone.
Correlate the first Asterisk media-timeout log and the first session-refresh failure before deciding which control acted. Do not disable both mechanisms at once; doing so removes the evidence needed to identify the owner.
Repair the failed path before relaxing policy
A temporary threshold change can test a bounded hypothesis, but a longer timer does not restore missing sound. Fix the demonstrated sender, routing, NAT, SDP, hold or endpoint problem, then return temporary settings to the intended policy.
Verify an answered call beyond the former threshold, hold beyond the former hold threshold, resume, bidirectional media and normal caller hangup. Confirm that abandoned sessions still clear. Record media reception and call lifetime separately so an apparent improvement is not merely a silent call that persists longer. No PBX, channel, packet, timeout, hold state or repair was tested for this guide.
Watch the explanation
Compares an intact RTP capture with a copy containing deliberately removed packets. The stream list and detailed analysis show how gaps become loss indicators and how burst patterns differ from scattered loss.
Read applicability and editorial notes →Watch this video here
A 2024 Wireshark demonstration; menu placement can change. The second capture is a teaching fixture with simulated loss. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk current res_pjsip option reference ↗
- IETF RFC 4028 — SIP session timers ↗
- Asterisk PJSIP troubleshooting guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.