2026-06-02

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

How to debug RTCP BYE, RTP stream end, camera teardown, session timeout, packet loss, and unexpected RTSP stream stops with protocol evidence.

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.

RTSP Inspector 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:

Confirm whether RTP stopped, RTSP closed, or both.
Look for RTCP BYE before media stops.
Check whether the client sent RTSP TEARDOWN.
Check whether the camera closed the TCP connection.
Measure the time from PLAY to stream end.
Inspect RTSP Session timeout and keepalive behavior.
Inspect RTP sequence continuity before the end.
Inspect RTCP Sender Reports and jitter before the end.
Compare LAN vs routed/VPN path.
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.

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

Read BYE as a source event, then find its preceding boundary

An RTCP BYE identifies an RTP source by SSRC and may include a reason string, but it does not promise a complete root-cause report. Start at the BYE timestamp, then look backward to the final sender report, final RTP sequence/timestamp, final RTSP request, TCP close, and any camera/NVR change. This establishes whether the media source ended cleanly, declined under a timeout, or was already unhealthy before it left.

Preceding pattern	Evidence-compatible reading	Next check
Clean RTP/SR until BYE at a fixed interval	Session expiry or scheduled source change may be involved	Session timeout and keepalive timeline
RTP gaps/jitter before BYE	Delivery or encoder stress may precede shutdown	Capture point, camera load, path comparison
BYE immediately after client TEARDOWN	Expected client-initiated closure	Session header and teardown acknowledgement
BYE with new SSRC shortly after	Encoder/source restart or profile switch may have occurred	Camera/NVR event timeline and new SDP boundary
RTP stops but no BYE observed	Silent path/source/capture failure remains possible	Transport, firewall/NAT, and capture placement

The RTCP sender report, jitter, and packet-loss guide covers the preceding health fields. A BYE after a poor interval is correlation, not proof that packet loss caused the device to leave.

Keep RTSP and RTP lifecycles separate

RTSP control can remain connected while RTP has ended; an NVR can also emit its own control behavior after an upstream camera leaves. Do not call a visible BYE “an RTSP error” unless an RTSP response actually contains an error. Preserve both lifecycles.

Layer	End evidence
RTSP control	TEARDOWN, 4xx/5xx response, TCP FIN/RST, or idle control connection
RTP media	Final sequence/timestamp, SSRC change, sequence silence
RTCP control	Sender/receiver report cadence, BYE source/reason, final report timing
Device state	Camera reboot/config change, NVR channel/offline event, maintenance window

This separation is especially useful when a player auto-reconnects. Each new DESCRIBE/SETUP sequence should be marked as a new session; otherwise a valid new SSRC can be misreported as a loss burst from the old stream.

BYE investigation QA checklist

Capture a bounded window before and after BYE with RTSP, RTP, and RTCP traffic.
Record BYE time, SSRC, reason if present, final RTP sequence/timestamp, and last sender report.
Check client teardown and keepalive behavior without assuming either caused the end.
Compare one authorized direct-camera/NVR or UDP/TCP path only if the boundary matters.
Retain the first reconnect result and label it as a new session.

Does RTCP BYE mean the network dropped the stream?

No. It is an explicit sender/source departure message at the observed RTP session. Network conditions can precede it, but the BYE itself is not a packet-loss indication.

Can a camera send BYE during a normal reconnect or profile change?

Yes. Encoder/source changes and intentional shutdowns can end one RTP source cleanly. Compare SSRC, session, and device timing before calling it a fault.

The right handoff is concise: “SSRC X sent BYE at this time after a 60-second session window; RTSP remained open/closed as shown, and a new session did/did not recover.” That gives the correct owner a testable next step.

What evidence separates an intentional BYE from a path failure?

Preserve the RTCP compound packet, SSRC, optional reason text, sender identity, last RTP sequence/timestamp, RTSP Session state, and subsequent TCP behavior. Compare a normal user-initiated TEARDOWN with the unexpected stop. A syntactically valid BYE from the active sender supports an intentional media-source decision; silence followed by timeout does not. Use the RTSP troubleshooting guide to keep control and media timelines aligned.

Also note whether another SSRC continued, because a single-track BYE is not necessarily a complete session shutdown.

Related guides

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