When VoIP calls drop after 30 seconds troubleshooting begins, the timing itself is valuable evidence. A call that ends at nearly the same interval usually has a control or state timeout, not random audio quality trouble.
The most common causes involve Real-time Transport Protocol (RTP), Network Address Translation (NAT), SIP session timers, or firewall connection tracking. SIP carries call-control messages. RTP carries the audio. Those paths may travel through different ports and may fail independently.
This guide uses a safe diagnostic order. Record the exact call duration, identify which devices sit between the endpoints, and collect SIP and firewall evidence before changing settings.
Why a fixed call duration matters
First, measure the symptom. Test several calls from the same endpoint and note whether the call ends at 29, 30, 31, or another repeatable number of seconds. Also test an inbound call, an outbound call, an internal call, and a call involving another phone.
A precise interval narrows the search:
- About 30 seconds: suspect missing SIP responses, failed ACK handling, or a transaction timer.
- Several minutes: inspect RTP inactivity, NAT expiration, session refreshes, and firewall state.
- Only one direction of audio: inspect RTP addressing, port access, and NAT behavior.
- Variable timing: consider packet loss, device behavior, provider issues, or overloaded network equipment.
Timing does not prove the cause. It helps you form a testable hypothesis. In VoIP calls drop after 30 seconds troubleshooting, avoid changing multiple timers at once, because that can hide the original failure.
For a broader comparison, see SIP call duration, NAT, and session timer checks. That article focuses on longer calls, while this guide emphasizes fixed-interval failures.
Separate SIP signaling from RTP audio
SIP signaling establishes, modifies, and ends a call. Messages include INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, re-INVITE, UPDATE, and BYE. RTP usually carries the media after the call connects.
That distinction matters. A call can have clear audio and still end because SIP signaling stops working. Conversely, the call may remain connected while RTP fails, producing silence or one-way audio.
Capture the call flow from the phone or PBX, the firewall, and the provider when possible. Then ask:
- Who sent the final BYE?
- Was a re-INVITE or UPDATE sent for a session refresh?
- Was the expected response received?
- Did the firewall log a dropped packet or expired state?
- Could RTP packets have stopped before the call ended?
These questions are central to VoIP calls drop after 30 seconds troubleshooting. They distinguish a signaling timeout from a media-path failure.
Use the official Asterisk documentation when reviewing channel, endpoint, SIP, and RTP details. Product menus vary, so confirm terminology against the PBX version and signaling driver in use.
Check RTP timeouts and media activity
RTP is normally a stream of small voice packets. A PBX or phone may treat prolonged media inactivity as a failed call. Some systems monitor RTP directly. Others rely on signaling or provider-side timers.
RTP timeout behavior can become confusing when silence suppression, hold, comfort noise, or direct-media settings are involved. A quiet call does not always produce the same packet pattern as an active conversation.
During a controlled test, compare packet activity before and after the failure. Look for the source and destination IP addresses, UDP ports, packet direction, and the last packet timestamp. A packet capture can show whether RTP stops first or whether a SIP BYE ends the call.
For VoIP calls drop after 30 seconds troubleshooting, these packet timestamps help separate an RTP timeout from a signaling failure.
Questions for the PBX configuration
- Is an RTP inactivity timeout enabled?
- Does it apply to all calls or only a trunk or endpoint?
- Does the system expect RTP from the provider’s advertised address?
- Are direct media or reINVITE options moving RTP around the firewall?
- Does the configured RTP port range match the firewall policy?
Do not simply increase a timeout. If packets use the wrong address or port, a longer timer only delays the failure. Confirm the media path first.
Inspect NAT mappings and public addresses
NAT, or Network Address Translation, lets private devices share or use public addresses. A NAT device creates a temporary mapping between an internal address and an external flow. Voice traffic can fail when that mapping expires, changes, or points to the wrong interface.
Check the SIP and SDP information in the call trace. SDP describes the media address and RTP ports. A private address in a message sent to an outside provider may prevent return audio. A public address can also be wrong when the PBX sits behind more than one router.
Confirm these details:
- The PBX knows its correct external address, if it requires one.
- The firewall has one clear NAT path for SIP and RTP.
- Port forwarding targets the correct PBX address.
- No second router performs competing NAT.
- The RTP port range is narrow enough to manage and broad enough for the call load.
- SIP ALG is understood and tested rather than assumed to help.
For a plain-language explanation of address translation, read Cloudflare’s overview of NAT. The correct fix depends on your router, PBX, provider, and network design.
For related port-forwarding checks, see this firewall NAT troubleshooting guide. Do not expose the PBX broadly while testing. Restrict administrative access, permit only required signaling and media traffic, and preserve a rollback plan.
Review session timers and refresh messages
SIP session timers provide a way to confirm that an established call remains active. A session refresh uses a re-INVITE or UPDATE. If the refresh does not complete, one device may terminate the call.
Review the Session-Expires and Min-SE values in the SIP messages. Identify which side acts as the refresher. Then check whether the expected refresh leaves the PBX, reaches the provider, and receives a valid response.
Common problems include a firewall blocking in-dialog requests, a provider rejecting a refresh, mismatched timer values, or a device that does not handle UPDATE correctly. A proxy can also alter the path or record-route behavior.
Do not disable session timers as a first response. They protect against abandoned sessions. Test a controlled adjustment only after confirming the failing message and the responsible device.
Examine firewall state and timeout handling
Firewalls track flows in connection tables. A rule may allow the initial call while later packets fail because the state expires or the return path changes. This is especially important when SIP and RTP use separate UDP flows.
Compare the failure time with firewall state and UDP timeout settings. Check whether the firewall sees packets as established, invalid, asymmetric, or unrelated. Review both allow and deny logs. A missing log entry can also matter if the firewall does not log expired state.
Pay attention to:
- UDP idle timeouts for SIP and RTP.
- SIP helper or ALG processing.
- Policy changes between LAN, WAN, and VPN zones.
- Return traffic leaving through a different interface.
- Provider address ranges and changing media destinations.
- Rate limits or inspection features that rewrite SIP messages.
If you change a timeout, record the old value, the new value, the test call, and the result. Apply one change at a time. A short maintenance window reduces the effect of an incorrect change.
Build a useful SIP evidence package
Good evidence makes remote diagnosis faster. Gather the call direction, extension, external number, timestamp, call duration, public IP, PBX address, and provider name. Remove passwords, authorization headers, and personal call content before sharing captures.
Include a SIP trace with timestamps and a firewall log covering the same call. If possible, include an RTP summary or packet capture. Mark the moment the audio stopped and the moment the call disconnected.
Use a comparison test. Call the same destination from another extension, then place a call through another network path. If only one phone fails, inspect its endpoint and local network. If every endpoint fails at the same interval, prioritize the PBX, firewall, NAT, or provider path.
A structured method matters more than repeated restarts. Google’s effective troubleshooting guidance also emphasizes evidence, hypotheses, and controlled tests.
Safe fixes after the cause is known
Choose the smallest change that addresses the observed failure. Correct the advertised external address when SDP is wrong. Fix the RTP port policy when packets are blocked. Adjust a firewall UDP timeout when state expires before the expected traffic returns.
For session problems, align timer behavior across the PBX, endpoint, and provider. For SIP helper problems, test with the feature disabled only when your equipment and provider support that design. Document the result and keep a rollback option.
Afterward, test inbound, outbound, internal, hold, transfer, and multi-minute calls. Confirm two-way audio and review logs after the call ends. A call that survives one test does not prove that every call path works.
When to involve remote VoIP support
Professional help is appropriate when packet captures, provider traces, or firewall changes require specialist access. Tech Rescue Ops LLC can help correlate SIP signaling, RTP behavior, NAT mappings, session timers, and firewall state without relying on guesswork.
Provide the evidence package and a clear maintenance window. That preparation helps a technician test the right layer while protecting active calls and the wider network.