2026-06-02

RTSP Stream Stops After 30 Seconds: Keepalive, Session Timeout, NAT, and Camera Idle Disconnects

Why RTSP streams stop after 30 seconds, 60 seconds, or a few minutes, and how to debug keepalive requests, session timeout, NAT, RTP silence, and camera disconnects.

An RTSP stream that starts successfully and then stops after 30 seconds is a different problem from a stream that never starts. Authentication worked. SDP was returned. SETUP and PLAY likely succeeded. Media may have arrived for a while. Then the camera closed the session, RTP stopped, the player froze, or the connection timed out.

Searches like "RTSP stream stops after 30 seconds", "RTSP keepalive timeout", "camera stream disconnects after one minute", and "RTSP session timeout" usually point to a session lifetime problem. The stream may need keepalive requests, the NAT mapping may expire, the camera may close idle RTSP sessions, UDP media may be blocked after a path change, or RTCP may reveal media loss before the disconnect.

RTSP Inspector is useful here because the timeline matters. You need to know what happened at second 0, second 30, second 60, and the exact moment the stream stopped.

Why RTSP can stop after it starts

Common causes include:

The client does not send RTSP keepalive.
The camera expects GET_PARAMETER keepalive.
The camera expects OPTIONS keepalive.
The RTSP session timeout is shorter than expected.
NAT or firewall state expires.
UDP RTP stops while RTSP TCP remains open.
The camera closes the TCP connection after media silence.
The client used a wrong aggregate control URL.
The camera firmware has a session cleanup bug.
RTCP reports packet loss or jitter before the stream freezes.

The fix depends on which layer stopped first: RTSP control, RTP media, RTCP feedback, or the underlying TCP/UDP path.

RTSP Session header and timeout

After SETUP, the camera usually returns a Session header:

RTSP/1.0 200 OK
Session: 12345678;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

The timeout=60 value means the session can expire unless the client keeps it alive. A client should send a keepalive request before the timeout. Some cameras accept OPTIONS. Some expect GET_PARAMETER. Some accept either. Some vendor implementations are picky.

If a stream stops around the timeout value, inspect whether the client sent any keepalive request and whether the camera answered it.

OPTIONS vs GET_PARAMETER keepalive

Two common keepalive methods are:

OPTIONS rtsp://camera/stream RTSP/1.0
Session: 12345678

and:

GET_PARAMETER rtsp://camera/stream RTSP/1.0
Session: 12345678

Some cameras do not require a body for GET_PARAMETER. Others behave strangely if the request URI or Session header is missing. If the keepalive is sent to the wrong URL, the camera may not count it for the active stream session.

When debugging, check:

Did the client send keepalive before the timeout?
Which method was used?
Did the keepalive include the correct Session header?
Did the camera return 200 OK?
Did the camera still close the stream after a successful keepalive?

Aggregate control URL problems

SDP may provide track-level control URLs and an aggregate control URL. Some cameras expect PLAY and keepalive requests on a particular URL. A client might use the original stream URL, while the camera expects the aggregate control URL from SDP.

This can create subtle behavior:

Initial playback works.
Keepalive request is sent.
Camera returns 200 OK or ignores it.
Session still expires.

The trace should preserve the SDP and every control URL used by SETUP, PLAY, and keepalive. Without that, you may not see that the client kept alive the wrong resource.

NAT and firewall idle timeout

If the camera is behind NAT, VPN, or firewall, the stream can stop because network state expires. This is especially common with UDP RTP. RTSP control over TCP may remain open, but UDP media packets stop arriving.

Symptoms:

RTSP connection still appears established.
RTP packets stop at a predictable time.
No RTSP TEARDOWN is visible.
Switching to RTSP over TCP interleaved fixes the problem.
Stream works on LAN but fails over VPN or WAN.

If UDP RTP is the issue, compare UDP transport with TCP interleaved transport. TCP interleaved often survives NAT better because RTSP control and RTP media share one TCP connection.

Camera idle disconnects

Some cameras close streams when they think the client is idle. This can happen if the camera expects RTCP receiver reports or keepalive messages and does not receive them. It can also happen if the camera's stream resource manager is aggressive.

Look for:

Camera sends TEARDOWN.
Camera closes TCP connection without RTSP error.
RTP stops while RTSP remains quiet.
RTCP BYE appears.
Disconnect happens exactly after 30, 60, 90, or 120 seconds.

Exact timing is a clue. Random disconnects suggest network instability or device load. Predictable disconnects suggest session timeout or keepalive policy.

RTP silence vs RTSP disconnect

Do not treat "video stopped" as one event. Split it:

Did RTSP TCP close?
Did the camera send TEARDOWN?
Did RTP packets stop?
Did RTP continue but timestamps freeze?
Did sequence numbers jump?
Did RTCP report packet loss?
Did the client stop reading?

A player may show the same frozen frame for all of these. A protocol trace can separate them.

Checklist for streams that stop after 30 seconds

Use this process:

Record the exact stop time.
Inspect the RTSP Session header and timeout value.
Check whether keepalive was sent before timeout.
Confirm keepalive method: OPTIONS or GET_PARAMETER.
Confirm keepalive includes the correct Session header.
Confirm keepalive uses the correct request URI.
Check whether camera replies 200 OK.
Inspect whether RTSP control or RTP media stops first.
Compare UDP RTP with TCP interleaved RTP.
Inspect RTCP for BYE, jitter, or packet loss.
Test on LAN before testing through NAT or VPN.
Check camera firmware notes for RTSP timeout behavior.

What to report to a vendor or network team

A useful report includes:

RTSP URL shape without exposing credentials.
Transport mode: UDP or TCP interleaved.
Session timeout value.
Keepalive method and interval.
Last successful RTSP response.
Last RTP packet timestamp.
Whether RTCP BYE appeared.
Whether the camera closed the TCP connection.
Whether TCP interleaved changes the result.

That evidence is much stronger than "the stream stops sometimes."

Final diagnosis

An RTSP stream that stops after 30 seconds or one minute usually has a timing cause: session keepalive, camera idle policy, NAT timeout, UDP media loss, or RTCP/session teardown behavior. The correct fix starts by identifying what stopped first and whether the client kept the session alive correctly.

RTSP Inspector supports that work by exposing the RTSP session timeline, keepalive behavior, RTP continuity, and RTCP evidence so the failure can be diagnosed as a protocol event instead of a vague playback problem.

Make a clocked timeout hypothesis

“About 30 seconds” is not enough for diagnosis. Measure the elapsed time from successful SETUP or PLAY to the last RTP packet, last RTCP packet, first failed keepalive, TCP close, and successful reconnect. Compare that timeline to the server's advertised Session timeout. A repeatable interval is useful evidence; it does not prove the camera ignored every keepalive until the actual requests are reviewed.

Observed timing	Careful interpretation	Next check
Stops just before advertised `timeout=60`	Missing/invalid keepalive is plausible	Keepalive method, URI, Session header, response
Stops at 30 seconds with no advertised timeout	NAT/device policy or application timer may be involved	LAN vs routed test and device logs
Control TCP lives, UDP RTP stops	Media path/state can expire independently	UDP source/port, firewall/NAT, TCP-interleaved comparison
Keepalive gets 200 but stream ends	Acceptance alone may not identify correct session/resource	Session ID, aggregate URL, RTP/RTCP boundary
Stops at varying intervals under load	Device/network capacity may be more relevant than simple expiry	RTP gaps/jitter, camera/NVR resource state

Use the RTSP TEARDOWN and session cleanup guide when reconnect behavior suggests stale session state, and the RTCP BYE stream-end guide when the sender explicitly leaves the RTP session.

Validate each keepalive request as an active-session operation

A request only keeps the intended session alive if the camera accepts the method, correct target, and current Session association. Do not infer success from sending a packet. Retain CSeq, method, URI, Session header, response status, and interval.

Keepalive result	Interpretation
`OPTIONS` with 200 before timeout	Server answered an options request; verify it applies to current session/profile
`GET_PARAMETER` with 200 and correct Session	Stronger evidence of active session maintenance
454 Session Not Found	Server has already expired/forgotten the session; later retries need a fresh session
401 on keepalive	Authentication or method policy changed; do not treat it as network silence
No response but RTP continues	Control response path may be separate; retain both observations
200 then BYE/RTP end	Look for profile/source/device event rather than assuming keepalive fixed the issue

The RTSP digest authentication guide is relevant only if the keepalive actually encounters an authentication challenge. Do not send high-rate retries to work around a 401 or 454; it can obscure the first definitive event.

Controlled 30-second stop test

Use an authorized camera/profile and start a new RTSP session.
Record Session timeout, transport, SDP control URL, and baseline RTP/RTCP activity.
Run the documented client keepalive policy; do not add unapproved synthetic load.
If it stops, mark exact last control/media events and first reconnect result.
Run one comparison with TCP interleaved if UDP/NAT is in scope; keep all other variables fixed.
Repeat only enough to establish whether the timing is fixed or variable.

QA case	Acceptance evidence
Correct keepalive	Method/URI/Session and response fit active stream
Expiry	Stop time is compared to advertised timeout with trace support
UDP path	RTP/RTCP silence is distinguished from RTSP TCP state
TCP interleaved	Difference is labelled transport-specific
Reconnect	Old/new session and SSRC are separated

Does TCP interleaved always fix a 30-second RTSP stop?

No. It can reveal or avoid a UDP/NAT media-path issue, but it does not repair an incorrect Session header, unsupported keepalive, device idle policy, or encoder restart.

Does a 200 keepalive response guarantee the stream will continue?

No. It proves that request received a 200 response. The camera can still end the media source for profile, capacity, source, or firmware reasons; compare RTP and RTCP events after it.

The final conclusion should be time-bounded and factual: identify the first layer that stopped, the session/keepalive evidence, and the one comparison that changed or did not change the result. That is what turns a 30-second playback complaint into an actionable RTSP case.

What is the smallest decisive A/B test?

Run one session with the client’s current keepalive method and one with the server-advertised or vendor-supported alternative, keeping transport and camera profile unchanged. Record Session timeout, keepalive request and response times, last RTP and RTCP packets, TCP closure, and any RTCP BYE. If media stops at the same interval while RTSP remains healthy, investigate the media path. If the server closes immediately after a missing or rejected keepalive, the control-session evidence is stronger. Preserve both runs with the case workflow.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: