RTCP BYE and RTSP Camera Streams Ending Unexpectedly: Why Video Stops Without a Clear Error

Some RTSP camera streams do not fail with a clean error. They start, play for a while, and then the video stops. The player may freeze on the last frame. The recorder may close the file. The client may reconnect automatically. Logs may say "end of stream", "RTP timeout", "RTCP BYE", "server closed connection", or nothing useful at all.

Searches like "RTCP BYE camera stream", "RTSP stream ends unexpectedly", "camera sends RTCP BYE", "RTP stream stops no error", and "RTSP video freezes after minutes" usually come from teams that already proved the URL works. They need to know why the stream ended.

RTCP BYE is one possible answer. It is a control message that indicates a participant is leaving the RTP session. In a camera stream, it may mean the camera intentionally ended a media track, restarted its encoder, expired a session, or closed media delivery while the RTSP control channel behaved differently.

RtspInspector is useful because a player may hide this detail. A protocol diagnostic tool can preserve RTSP, RTP, and RTCP events together.

What RTCP BYE means

RTCP is the control protocol paired with RTP. RTP carries media packets. RTCP carries reports and control information. An RTCP BYE packet signals that a source is leaving the RTP session.

In a simple case:

RTP video packets arrive
RTCP Sender Reports arrive
RTCP BYE arrives
RTP video packets stop

The BYE packet is not packet loss. It is an explicit control message. The camera, sender, or media relay is saying that the RTP source ended.

RTCP BYE vs RTP timeout

If RTP packets stop and no RTCP BYE appears, the client may report a timeout. That can mean UDP loss, firewall timeout, camera freeze, transport failure, or capture gap.

If RTCP BYE appears, the diagnosis changes. The sender intentionally announced departure from the RTP session. You still need to determine why, but the evidence is stronger than a generic timeout.

Common reasons include:

• Camera session timeout.
• Encoder restart.
• Stream profile reconfiguration.
• User limit exceeded.
• NVR channel changed state.
• Camera went idle or lost source input.
• RTSP control session was not kept alive.
• Firmware bug under load.
• Media relay closed the stream.

RTSP TEARDOWN vs RTCP BYE

RTSP TEARDOWN and RTCP BYE are different.

RTSP TEARDOWN is a control request to terminate an RTSP session:

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

RTCP BYE is a media-session control packet. A stream may end with one, both, or neither visible depending on camera behavior and capture point.

Cases:

• Client sends RTSP TEARDOWN: expected shutdown.
• Camera closes TCP connection: abrupt server-side end.
• Camera sends RTCP BYE: media source ended.
• RTP stops without RTCP BYE: timeout or lost media path.
• RTSP remains open but RTP ends: media layer ended while control stayed alive.

This distinction helps avoid blaming the wrong layer.

Stream ends after a predictable time

If the stream ends at 30, 60, 120, or 300 seconds, suspect keepalive or session timeout. Check the RTSP Session header:

Session: abcdef;timeout=60

Then inspect whether the client sent OPTIONS or GET_PARAMETER keepalive before timeout. If no keepalive appears and the camera ends the RTP session with RTCP BYE, the BYE may be a symptom of RTSP session expiration.

If keepalive exists and receives 200 OK, inspect whether it used the correct Session ID and control URL.

Stream ends during camera reconfiguration

Many cameras restart encoders when settings change:

• Resolution change
• Frame rate change
• Bitrate change
• H.264 to H.265 change
• Main stream/sub-stream switch
• Day/night profile switch
• Audio enable/disable
• Smart codec toggle

During this transition, the camera may stop RTP, send RTCP BYE, close RTSP, or force clients to reconnect. If the stream ends at the same time as configuration changes or scheduled profile changes, the failure may be expected behavior, not network instability.

NVR and channel behavior

When streaming through an NVR, the RTSP session may depend on channel state. If the source camera behind the NVR disconnects, reboots, changes profile, or loses signal, the NVR may terminate the outgoing RTP stream.

The client sees an RTSP stream ending, but the real cause is upstream of the RTSP endpoint.

Evidence to collect:

• NVR stream URL and channel path.
• Whether the NVR sends RTCP BYE.
• Whether all channels fail or only one.
• Whether the direct camera stream also fails.
• Whether the NVR logs source camera offline events.

Packet loss before BYE

RTCP BYE can appear after a period of poor media delivery. Check before the BYE:

• RTP sequence gaps.
• Rising jitter.
• Missing RTCP Sender Reports.
• Long packet silence.
• Transport errors.
• Camera CPU or bandwidth stress.

If the stream degrades before ending, the BYE may be part of recovery or shutdown. If the stream is clean and then BYE appears exactly on a timer, session policy is more likely.

Checklist for RTCP BYE investigations

Use this process:

1. Confirm whether RTP stopped, RTSP closed, or both.
2. Look for RTCP BYE before media stops.
3. Check whether the client sent RTSP TEARDOWN.
4. Check whether the camera closed the TCP connection.
5. Measure the time from PLAY to stream end.
6. Inspect RTSP Session timeout and keepalive behavior.
7. Inspect RTP sequence continuity before the end.
8. Inspect RTCP Sender Reports and jitter before the end.
9. Compare LAN vs routed/VPN path.
10. Check camera or NVR logs for encoder restart or channel loss.

What a useful report includes

For a vendor or network team, include:

• Exact stream duration before end.
• Whether RTCP BYE appears.
• BYE source SSRC.
• Last RTSP request and response.
• Last RTP sequence number.
• Whether RTSP TEARDOWN was sent.
• Keepalive interval and response.
• Transport mode: UDP or TCP interleaved.
• Whether reconnect immediately succeeds.

This turns "stream randomly stopped" into a protocol timeline.

Final diagnosis

RTCP BYE is a strong clue that the media source intentionally left the RTP session. It does not by itself explain why, but it separates an explicit media end from silent packet loss. The next step is to correlate BYE with RTSP teardown, keepalive, session timeout, encoder restart, NVR channel state, RTP loss, and network path.

RtspInspector helps by keeping RTSP, RTP, and RTCP evidence together so unexpected stream endings can be diagnosed from the actual protocol sequence.