RTSP Stream Stops After 30 Seconds: Keepalive, Session Timeout, NAT, and Camera Idle 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.

RtspInspector 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:

1. Record the exact stop time.
2. Inspect the RTSP Session header and timeout value.
3. Check whether keepalive was sent before timeout.
4. Confirm keepalive method: OPTIONS or GET_PARAMETER.
5. Confirm keepalive includes the correct Session header.
6. Confirm keepalive uses the correct request URI.
7. Check whether camera replies 200 OK.
8. Inspect whether RTSP control or RTP media stops first.
9. Compare UDP RTP with TCP interleaved RTP.
10. Inspect RTCP for BYE, jitter, or packet loss.
11. Test on LAN before testing through NAT or VPN.
12. 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.

RtspInspector 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.