SIP calls drop after several minutes for several different reasons. An established call may end because a NAT mapping expires, a firewall removes an idle flow, a session timer fails, or a provider sends a deliberate termination. The timing matters, but signaling evidence matters more.
This guide presents a safe way to separate those causes. You will compare call duration, SIP messages, RTP media, device settings, firewall state, and provider records. Avoid changing several settings at once. A successful test should identify a cause, not merely make one call last longer.
Start with the exact call timing
First, record the time from call answer to disconnection. “After a few minutes” is not precise enough for useful diagnosis. Test several calls and note whether they end at nearly the same interval.
- Record the caller, destination, direction, and extension or trunk.
- Note the answer time and the exact disconnect time.
- Test inbound, outbound, and internal calls separately.
- Compare calls with continuous conversation against calls with silence.
- Write down the disconnecting party, if the phone or PBX displays it.
A repeatable interval points toward a timer or state timeout. A changing interval may indicate packet loss, device behavior, provider policy, or a network event. The pattern does not prove the cause, but it helps rank your next checks.
Also check whether the problem affects one endpoint, one location, one trunk, or every call. A single phone suggests endpoint or local network behavior. All calls through one provider route suggest trunk, firewall, or carrier evidence deserves priority. When SIP calls drop after several minutes, this timing record helps separate a fixed timer from a changing network condition.
Use SIP signaling to find who ended the call
SIP is the signaling protocol that creates, updates, and ends a call. During a normal call, the PBX and endpoints exchange messages such as INVITE, 200 OK, ACK, and BYE. The important question is simple: which side sent the first BYE or received an error?
Capture a focused trace
Use the PBX, SBC, or provider trace tools available in your environment. Capture one test call and include signaling from call setup through disconnect. Avoid recording unrelated customer calls or exposing credentials in exported logs.
Look for these patterns:
- PBX sends BYE: an application, endpoint, dialplan rule, timer, or administrator action may have ended the call.
- Provider sends BYE: the carrier or upstream system may have terminated the call.
- No BYE appears: a signaling path may have failed, or a device may have closed the connection without a clean message.
- Repeated re-INVITE or UPDATE messages: inspect session timer negotiation and whether each side answers correctly.
- Transport errors or retransmissions: investigate reachability, NAT state, firewall handling, and packet loss.
A BYE identifies the signaling action, not necessarily the underlying fault. For example, a provider may send BYE after it stops receiving expected traffic. Read the surrounding messages and timestamps before assigning blame.
For Asterisk-based systems, the official Asterisk documentation provides reference material for SIP, RTP, endpoints, and troubleshooting concepts. Configuration names vary by channel driver and deployment, so verify the active technology before applying advice.
Check NAT mappings and RTP media paths
Network address translation, or NAT, lets private devices share public addresses. A router tracks each flow in a temporary mapping. If the mapping expires, later packets may no longer reach the correct phone or PBX.
NAT problems often affect signaling, media, or both. RTP is the packet stream that carries the actual voice. A call can remain connected in SIP while RTP stops moving. Some systems then clear the call after a media or signaling timeout.
When SIP calls drop after several minutes, compare packet flow before and after the failure. Ask the following:
- Check whether RTP packets flow in both directions throughout the call.
- Compare the public address in SIP or SDP with the address reachable by the peer.
- Review whether the router shows the SIP and RTP states until disconnect.
- Test whether the problem occurs only when the endpoint sits behind a second router.
- Determine whether speaking continuously prevents the failure while silence triggers it.
Do not assume that enabling SIP Application Layer Gateway, often called SIP ALG, will help. Some routers rewrite SIP traffic incorrectly. Test with a documented configuration and a rollback plan instead of changing multiple NAT features together.
For a plain explanation of address translation and traffic flow, see Cloudflare’s NAT overview. The exact behavior still depends on your router, firewall, transport protocol, and provider design.
If the device repeatedly loses registration as well as calls, review the separate checks in this SIP registration troubleshooting guide. Registration loss and mid-call termination can share a NAT cause, but they are not the same symptom.
Distinguish session timers from firewall timeouts
A SIP session timer is a negotiated refresh mechanism. During a long call, one side sends a periodic re-INVITE or UPDATE. The other side must respond within the agreed process. If refreshes fail, the call can end even when the users are actively speaking.
Inspect the initial SIP messages for session timer headers and negotiated values. Then check whether refresh messages appear at the expected intervals. A failed refresh, missing response, or unexpected change in role is stronger evidence than call duration alone.
Firewall timeouts are different. A firewall tracks traffic state and may delete a connection after inactivity or after a policy-defined period. Some devices treat UDP flows as short-lived because UDP has no built-in connection handshake. Voice traffic may continue only while packets refresh that state.
- Compare the firewall’s UDP and TCP timeout values with the failure interval.
- Check whether SIP signaling and RTP use different ports or protocols.
- Review state-table logs around the disconnect time.
- Confirm that return traffic matches the expected public address and port.
- Test one controlled call after documenting the original settings.
A timer failure usually leaves SIP refresh evidence. A firewall expiry may show a removed state, blocked return packet, or a sudden lack of traffic. These clues can overlap, so correlate both traces rather than relying on one log.
Look for provider-side termination
When the provider sends the first BYE, request the carrier’s call detail and signaling explanation. Ask for the call identifier, disconnect code, timestamps with time zone, and the side that initiated release.
Provider-side rules may involve maximum duration, authentication, route policy, fraud controls, media supervision, or an upstream interconnect. Do not guess at a carrier limit without documentation. Instead, compare affected calls with a known-good route, destination, or trunk when that test is permitted.
Check whether the failure affects:
- Only external calls or internal calls too.
- Inbound calls, outbound calls, or both.
- One destination range or all destinations.
- One trunk account or multiple accounts.
- Calls with silence or calls with continuous speech.
If the provider’s logs show a clean termination from its platform while your PBX shows no preceding fault, preserve both records. That evidence supports a focused provider ticket. The article on SIP rejection responses covers setup failures; mid-call termination requires a different evidence set.
Follow a safe test sequence
Change one variable at a time. Begin with a short baseline test and save the current PBX, router, and firewall configuration. A configuration export helps you reverse an experiment without relying on memory.
- Run one internal call and one external call.
- Capture SIP signaling and, where appropriate, a limited packet trace.
- Record the exact disconnect interval and first terminating message.
- Check RTP direction and firewall state during the final minute.
- Review session timer negotiation and refresh responses.
- Compare PBX records with the provider’s call detail.
- Apply one documented adjustment, then repeat the same test.
Do not disable the firewall, expose the PBX directly to the internet, or leave broad port forwards in place as a diagnostic shortcut. Those actions can create security and fraud risks. If a provider or equipment vendor recommends a change, record its scope and rollback step.
A structured evidence process reduces false conclusions. Google’s effective troubleshooting guidance also emphasizes clear hypotheses, controlled tests, and records that support root-cause analysis.
When remote SIP troubleshooting is appropriate
SIP calls drop after several minutes is a symptom, not a diagnosis. Timing, SIP signaling, RTP flow, NAT state, firewall logs, session refreshes, and provider records can separate similar-looking failures.
If you cannot safely capture a trace, interpret the PBX logs, or change the edge firewall without risking service, professional remote assistance may be appropriate. Tech Rescue Ops LLC can help organize evidence and test VoIP, SIP, NAT, firewall, and provider behavior in a controlled sequence.