RTSP TEARDOWN and Session Cleanup Debugging: Camera Resource Leaks, Reconnect Fails, Timeout, and Busy Streams

RTSP streams do not only fail at connect time. They can also fail after disconnect, when the camera or RTSP server keeps the old session alive. Users search for "RTSP TEARDOWN", "RTSP reconnect fails", "camera stream busy", "RTSP session timeout", "too many connections camera", and "RTSP resource leak" when a stream works once but cannot be reopened immediately.

RTSP Inspector is useful because this is a session-state problem. The key evidence is whether the client sent TEARDOWN, whether the server acknowledged it, whether the TCP socket closed without cleanup, and whether a later SETUP or PLAY is rejected because the old session still exists.

Why TEARDOWN matters

TEARDOWN tells the RTSP server the client is finished with the session. A clean shutdown often looks like:

TEARDOWN rtsp://camera/live RTSP/1.0
Session: 12345678

The server should release selected streams, RTP ports, decoder resources, encoder slots, or per-client session state.

If the client simply closes TCP without TEARDOWN, some servers clean up immediately. Others wait for a session timeout.

Common symptoms

Session cleanup bugs appear as:

• First connection works, second connection fails.
• Camera says "user limit reached."
• NVR reports stream busy.
• RTSP server returns 503 Service Unavailable.
• SETUP fails until timeout expires.
• Stream recovers only after camera reboot.
• Multiple clients compete for one stream slot.
• Server keeps sending RTP after client stops.

These symptoms are often misdiagnosed as authentication or network problems, but they may be stale RTSP session state.

TEARDOWN missing

Some client libraries do not send TEARDOWN on crash, force quit, network drop, or app navigation. Mobile apps can also lose the chance to clean up when backgrounded.

Evidence:

• Last RTSP method before disconnect.
• TCP FIN or RST without TEARDOWN.
• No server 200 OK for teardown.
• Camera accepts no new session until timeout.
• Same behavior appears only after abnormal exit.

If the trace proves no TEARDOWN was sent, the fix may be client lifecycle handling.

Server ignores TEARDOWN

The opposite is also possible. The client sends TEARDOWN, but the server does not release resources correctly.

Evidence:

• Client sends valid TEARDOWN.
• Session header matches active session.
• Server returns 200 OK.
• New session still fails as busy.
• Resource is released only after fixed timeout.

That points to camera firmware, NVR restreamer behavior, or RTSP proxy session cleanup.

Wrong Session header

Some clients send TEARDOWN with the wrong Session value, stale session value, or missing session header.

Causes:

• Session ID changed after reconnect.
• Proxy rewrote session values.
• Multiple tracks have confusing session state.
• Client stores session globally across cameras.
• Client sends TEARDOWN to aggregate URL but wrong session.

RTSP Inspector should make the session ID visible across SETUP, PLAY, keepalive, and TEARDOWN.

Timeout and keepalive interaction

Many RTSP servers advertise a session timeout. The client may need to send periodic keepalive requests such as OPTIONS, GET_PARAMETER, or another server-supported method.

Cleanup bugs can mix with keepalive bugs:

• Session times out because keepalive is missing.
• Client thinks session is alive but server cleaned it up.
• Server keeps stale session because TCP close was not observed.
• Reconnect fails until timeout expires.

Look at timing. A failure exactly after 30, 60, or 120 seconds often points to timeout policy.

Debug checklist

Use this workflow:

1. Capture a successful connection.
2. Capture the disconnect path.
3. Check whether TEARDOWN is sent.
4. Verify the Session header value.
5. Check server response to TEARDOWN.
6. Capture immediate reconnect attempt.
7. Compare response codes on DESCRIBE, SETUP, and PLAY.
8. Measure time until reconnect works again.
9. Check keepalive method and timeout.
10. Preserve session IDs across the whole trace.

Final diagnosis

RTSP TEARDOWN problems are session cleanup problems. The important evidence is the shutdown method, session ID, server response, TCP close behavior, timeout, and reconnect result.

RTSP Inspector helps prove whether reconnect failures are caused by missing TEARDOWN, stale session IDs, camera resource leaks, keepalive timeout, or server cleanup bugs.