SIP disconnect evidence helps explain why a working call ends after 30 or 60 seconds. The elapsed time offers a clue, but it does not identify the cause. You need a timeline showing which message, media gap, or network event came first.
This guide focuses on correlating evidence across the phone system, firewall, and provider. Use it when you need to prove where a call failed or prepare a useful escalation. For an initial symptom checklist, start with our general guide to repeatable call drops.
Define One Test Call Before Collecting Evidence
SIP, or Session Initiation Protocol, controls call setup, changes, and termination. RTP, or Real-time Transport Protocol, usually carries the audio separately. A call can exchange voice while its signaling path already has a fault.
Choose one repeatable test rather than collecting an entire busy afternoon. Record these details:
- Calling and called numbers, with extensions where relevant.
- Call direction and the provider connection involved.
- Start time, answer time, and disconnect time, including the time zone.
- Whether both parties heard audio until the disconnect.
- Whether hold, transfer, silence, or another action preceded the failure.
Measure the interval from answer, not just from dialing. Also note the time since the last signaling exchange or received audio packet. Different timers start from different events.
Synchronize device clocks where possible. Otherwise, document each clock offset before comparing logs. Use a successful call through the same path as a control.
Capture SIP Disconnect Evidence at Both Boundaries
A PBX, or private branch exchange, connects phones to internal users and outside providers. It often creates separate SIP call legs. The phone-facing leg and provider-facing leg may use different Call-ID values, which identify SIP dialogs.
Collect a short PBX signaling trace and relevant call logs. Where authorized, capture traffic on the firewall’s inside and outside interfaces. Ask the provider to preserve its trace for the same test.
Map the legs through PBX channel identifiers and timestamps. Do not assume one Call-ID follows the call through every system.
Limit captures by time, host, and relevant traffic where practical. Packet captures can expose telephone numbers, authentication material, and audio. Restrict access, use secure transfer, and follow your retention policy.
Encrypted SIP traffic will not reveal readable messages in an ordinary network capture. Use authorized application logs or provider traces instead. Avoid disabling encryption just to simplify inspection.
Check the Asterisk documentation for logging options that match your installation. Broad debug logging can create heavy output on a busy system.
Build a Timeline Around the First Failure
Start with the initial INVITE request, which begins call setup. Find the final 200 OK response that accepts it, followed by ACK, which confirms receipt. Then follow later signaling and media through termination.
A compact evidence worksheet keeps the investigation focused:
| Event | Evidence to record |
|---|---|
| Answer | 200 OK sender, timestamp, and call leg |
| Confirmation | ACK destination and arrival at the answering system |
| Media | Last received RTP packet in each direction |
| Mid-call change | re-INVITE or UPDATE request and its response |
| Termination | First BYE, transport failure, or local timeout |
A BYE request ends an established SIP session. Its sender identifies who initiated termination on that leg, not necessarily who caused the fault.
For example, a provider may send BYE because it stopped receiving audio. The underlying cause could still sit inside your network. Compare the first failure with later cleanup messages before assigning responsibility.
Prove Whether the Answer ACK Reached Its Destination
A missing ACK is a strong candidate when calls fail roughly 32 seconds after answer. With common default SIP timing, an unanswered confirmation process can reach that interval. It is not a universal deadline for every implementation.
Look for repeated 200 OK responses to the same INVITE. Then check whether the caller sends ACK and whether the answering system receives it.
For a successful INVITE, ACK routing uses the dialog’s remote target and route set. The Contact header supplies the remote target; Record-Route headers help establish the signaling path. Compare those values with the actual packet destination.
- Does Contact advertise an unreachable private address?
- Check whether the route set points to the expected provider proxy.
- Trace whether ACK leaves the PBX but disappears at the firewall.
- Confirm that the provider receives ACK on the correct call leg.
The core SIP specification explains these dialog and ACK rules. A matching message sequence number alone does not prove correct routing or delivery.
Separate Session Refreshes From Other re-INVITEs
Session timers let call participants confirm that a session remains active. Inspect the negotiated Session-Expires value and the refresher parameter, which identifies the party responsible for refreshing.
A 60-second drop alone does not prove session-timer failure. Standards-based session timers have a 90-second minimum interval. Other device policies and timeout mechanisms can produce shorter failures.
Find the actual refresh request, usually a re-INVITE or UPDATE. A re-INVITE changes or refreshes an existing call. UPDATE can also modify session information without starting another call.
Check whether the request arrives, receives a successful response, and completes correctly. A successful re-INVITE also requires ACK. UPDATE does not use ACK.
Not every re-INVITE represents a timer refresh. Hold, transfer, or direct-media changes can trigger one too. Compare the request timestamp with user actions and inspect any changed media addresses. Escalate the observed exchange rather than labeling every mid-call request a timer problem.
Compare NAT Mappings With Firewall State
NAT, or network address translation, maps private addresses and ports to external ones. Firewalls also track active traffic flows. These related mechanisms can expire or change independently of a PBX’s call state.
Compare inside and outside packet addresses throughout the test. Record the external source port, remote address, transport, and firewall state entry. Look for state removal, port changes, or replies that target an old mapping.
Media traffic does not necessarily keep signaling state alive. RTP and SIP usually use different flows. Likewise, a registration or keepalive exchange may use a different destination from the active dialog.
If state disappears before the failure, investigate its configured timeout and matching traffic. If it remains present, check routing and policy decisions instead.
Do not increase every timeout or open broad port ranges. First identify the affected flow. A controlled test should change only the relevant setting and include a rollback plan.
Distinguish RTP Inactivity From a Signaling Failure
Some PBXs and providers end calls when they receive no RTP for a configured interval. This policy differs from a SIP session timer.
Compare the last received media packet with the disconnect time. Check both call legs and both directions. Audio may still reach one person while the opposite direction has already stopped.
Inspect SDP, or Session Description Protocol, within signaling messages. SDP describes media addresses, ports, and formats. A mid-call update may redirect RTP toward an unreachable address.
Hold and silence suppression can affect expected media behavior. Verify whether the configured inactivity policy handles those states correctly. Do not treat silence at the handset as proof that RTP stopped.
If audio disappears before the call ends, follow our guide to tracing the SIP media path. Increasing an inactivity timer may hide the symptom without restoring missing audio.
Turn SIP Disconnect Evidence Into a Provider Escalation
Send the provider a short evidence package, not an unexplained capture. Include the test numbers through a secure channel and identify the exact provider-facing Call-ID.
- State the answer and failure times with time zone.
- List the first abnormal event and the system that observed it.
- Attach the relevant signaling sequence and PBX termination reason.
- Show whether expected packets crossed your external interface.
- Ask for the corresponding provider-side receipt and release records.
Phrase requests narrowly. Ask whether their system received ACK, attempted a refresh, or triggered a media inactivity policy. If they sent BYE, request the underlying release reason and relevant upstream events.
A Reason header or call record can help, but it may reflect a translated cause. Provider traces must confirm what happened on their side. Absence from your capture alone does not prove they never sent a packet.
Validate the Fix Against the Original Timeline
Change one confirmed cause at a time. Repeat the original test beyond the previous failure point and through any relevant refresh interval. Then test inbound calls, outbound calls, hold, and resume where those paths matter.
Successful validation should show the missing ACK arriving, the refresh completing, or the media flow remaining active. Preserve a brief before-and-after comparison, then stop temporary logging and remove unnecessary captures.
If access gaps prevent correlation, professional help may be appropriate. Tech Rescue Ops LLC provides remote VoIP and PBX support for evidence collection and coordinated troubleshooting. Clear SIP disconnect evidence helps keep that work focused on the failing path rather than speculative changes.