RTSP Stream Troubleshooting: The Complete Diagnostic Guide for Camera Streams
Complete RTSP diagnostic workflow: connection layer, control plane errors (400/401/404/454/461/500/503), media plane failures (H.264/H.265/RTP/RTCP), session management, and comparison with Wireshark/VLC. Every RTSP problem mapped to a diagnostic page.
Short answer: troubleshoot an RTSP camera stream in protocol order. First prove that the client can reach the camera and complete any TLS handshake. Next record the DESCRIBE, SETUP, and PLAY exchanges, including status codes, Session and Transport headers, and the SDP body. Finally verify whether RTP and RTCP packets arrive with the payload type, sequence, timestamp, SSRC, clock rate, and codec parameters advertised by SDP. Stop at the first layer whose expected evidence is missing; later symptoms are often consequences rather than separate root causes.
This is the hub page for RTSP camera stream diagnostics. Every RTSP problem follows a pattern — it fails at the connection layer, the control plane, or the media plane. This guide maps every common failure to a specific diagnostic page and tells you what evidence to collect.
Quick triage: where is the failure?
Before reading any specific page, determine which layer is failing:
- Can the client reach the camera? → Connection layer problems
- Does DESCRIBE return valid SDP? → Control plane problems
- Do RTP packets arrive and decode correctly? → Media plane problems
If you don't know which layer is failing, start with the systematic diagnostic workflow.
| First failed expectation | Evidence to preserve | What the failure narrows | Do not conclude yet |
|---|---|---|---|
| TCP or TLS connection never completes | Destination, port, timestamps, handshake result, certificate error | Addressing, routing, firewall, listener, or TLS setup | That the RTSP path or credentials are wrong |
| DESCRIBE does not return usable SDP | Request URI, authorization exchange, status, headers, SDP bytes | URL, authentication, server response, or SDP generation | That RTP is blocked; media setup has not succeeded |
| SETUP fails or returns different transport | Track control URI, requested Transport, server Transport, Session | Track resolution and UDP/TCP negotiation | That the codec is unsupported |
| PLAY succeeds but no RTP arrives | PLAY response, negotiated ports/channels, packet timestamps | Firewall/NAT, server media start, or interleaved channel handling | That a decoder caused the silence |
| RTP arrives but frames fail | SDP mappings, payload type, sequence, timestamp, marker, SSRC, NAL evidence | Packet loss, payload mapping, codec parameters, or reassembly | That the camera is generally offline |
The evidence order matters when the user-facing symptom is simply “camera connects but there is no video.” A client can display that message after a 401 loop, a bad SDP control URI, a UDP transport mismatch, absent RTP, or a decoder failure. Treating the final message as the diagnosis causes configuration changes at several layers and makes the next capture harder to compare.
Connection layer: reaching the camera
These problems happen before any RTSP command is sent. TCP handshake fails, TLS negotiation fails, or the network path is blocked.
RTSP connects but no video — The most common symptom. Camera appears online but no media stream.
RTSP over TLS (RTSPS) debugging — TLS certificate errors, handshake failures, cipher suite negotiation.
Control plane: RTSP command errors
These are protocol-level errors returned by the camera in response to DESCRIBE, SETUP, or PLAY. The error code tells you exactly what went wrong.
400 Bad Request
- RTSP 400 Bad Request: DESCRIBE failed — Malformed URL, unsupported headers, proxy interference. Covers Axis, Dahua, and Hikvision URL formats.
401 Unauthorized
RTSP 401 authentication loop — Digest vs basic auth, nonce/realm parameters, why authentication succeeds in VLC but fails in your app.
RTSP digest authentication deep dive — Nonce expiration, realm matching, stale=true handling.
401/404 camera URL diagnostics — When the URL works in one client but not another.
404 Not Found
401/404 camera URL diagnostics — Wrong stream path, camera-specific URL formats.
Aggregate control URL and SDP SETUP 404 — When the control URL in SDP doesn't match the DESCRIBE URL.
454 Session Not Found
- RTSP 454 Session Not Found — Session ID mismatch, expired sessions, PLAY before SETUP.
461 Unsupported Transport
- RTSP 461 Unsupported Transport: SETUP failed — UDP vs TCP transport negotiation, ffmpeg "method SETUP failed: 461", Frigate/Scrypted/NVR integration errors.
500 / 503 Server Errors
RTSP 500 Internal Server Error — Camera-side failure. When to conclude the camera firmware is at fault.
RTSP 503 Service Unavailable — Camera resource exhaustion, too many concurrent streams, bandwidth limits.
Transport and networking
UDP RTP blocked by firewall/NAT — RTSP control works but UDP RTP media is blocked. Firewall rules, NAT traversal, RTSP protocol port configuration, TCP interleaved fallback.
TCP interleaved channel mismatch — When interleaved RTP/RTCP channels don't match between client and server.
Non-matching transport server reply — Server responds with different transport parameters than requested.
Multicast UDP debugging — Multicast RTSP/RTP configuration, IGMP, TTL, and network infrastructure.
RTSP timeout: UDP vs TCP interleaved — Why streams timeout differently on UDP vs TCP.
Media plane: RTP, codec, and payload problems
Control plane works perfectly — DESCRIBE returns SDP, SETUP succeeds, PLAY returns 200 OK — but video is broken. These are media plane problems.
RTP packet analysis
RTP dynamic payload type mismatch — "Unknown write" RTP/NDPI errors. How to map dynamic payload IDs to SDP rtpmap lines.
RTP packet loss diagnosis — RTP error in primary stream. Freezes, macroblocks, decoder errors. Read sequence numbers and RTCP reports to find the loss.
RTP timestamp drift — Audio/video sync loss, frame timing errors, clock rate mismatch.
RTP marker bit and frame boundaries — How the RTP marker bit signals H.264 access unit boundaries.
RTP sequence number wraparound — 16-bit sequence number rollover and how to detect actual loss vs wraparound.
RTP SSRC change mid-stream — When the camera changes SSRC mid-stream and the client loses sync.
H.264 and H.265 codec issues
H.264 FU-A fragmentation and reassembly — Missing fragments, start/end bit bugs, NAL unit reassembly failures, "invalid NAL unit" errors.
H.264 packetization mode 0 vs 1 — Single NAL vs non-interleaved mode. SDP parameter configuration.
H.264 SPS/PPS missing — Decoder errors when parameter sets are missing from SDP or RTP stream.
H.265 stream not working — H.265/HEVC failures and H.264 fallback behavior.
SDP H.264/H.265 diagnostics — Reading SDP for H.264/H.265: profile-level-id, sprop-parameter-sets, packetization-mode.
Audio and metadata tracks
- Audio track AAC unknown track SDP — AAC audio tracks appearing as "unknown" in clients.
ONVIF and camera-specific
ONVIF works but RTSP URL fails — ONVIF discovery succeeds but direct RTSP connection fails.
Main stream vs sub stream — When the main stream works but the sub stream doesn't, or vice versa.
RTCP and session management
RTCP sender reports: jitter and loss — Reading RTCP SR packets to understand network quality from the camera's perspective.
RTCP BYE: stream ends unexpectedly — When the camera sends RTCP BYE and terminates the stream.
RTCP CNAME and audio/video sync — Using RTCP CNAME to synchronize audio and video tracks.
RTSP TEARDOWN and session cleanup — Camera resource leaks, reconnect fails, busy stream state.
RTSP session timeout and keepalive — Why streams stop after ~30 seconds and how to keep them alive.
RTSP Range header and NPT — Controlling playback position with Range and NPT parameters.
RTSP Scale header and trick play — Fast-forward, rewind, and speed control via Scale header.
Comparison and alternatives
RTSP Inspector vs Wireshark/VLC/ONVIF Device Manager — When to use a dedicated RTSP diagnostic tool vs a general network analyzer.
Wireshark RTSP alternative — Why RTSP diagnostics need more than packet capture.
Build a reviewable RTSP case
A useful RTSP ticket lets another engineer replay the reasoning without access to the original camera. Record the camera model and firmware, client build, network path, full request URI with credentials removed, transport preference, and one bounded reproduction. Keep the first abnormal request/response or media event with enough preceding context to explain how the session reached that state.
| Case item | Minimum useful detail | Reason it belongs in the handoff |
|---|---|---|
| Reproduction boundary | Start action, expected result, first visible failure | Separates a repeatable protocol problem from an intermittent report |
| Control transcript | Method, URI, status, key headers, Session and Transport values | Shows whether client and camera agreed on one session and transport |
| SDP snapshot | Media sections, control attributes, payload mappings, codec parameters | Defines what the client was told to SETUP and decode |
| Media observation | First packet time, count, sequence gaps, timestamps, SSRC, RTCP | Distinguishes no media from damaged or misinterpreted media |
| Comparison | One working client, transport, stream profile, or firmware when available | Gives the investigation a controlled difference |
| Current conclusion | Observed fact, likely cause, uncertainty, next test | Prevents an inference from being presented as captured evidence |
RTSP Inspector is designed around that bounded protocol case. It can keep control-plane exchanges, SDP, RTP/RTCP observations, reports, and replay-oriented evidence together. It is not a general video player and should not be used to hide a missing protocol step behind successful picture rendering. The case replay help explains how retained observations support a repeatable handoff.
RTSP troubleshooting questions
Why does an RTSP URL work in VLC but fail in another client?
The two clients may send different authorization headers, resolve SDP control URLs differently, request UDP versus TCP interleaved transport, select different media tracks, or tolerate malformed responses differently. Capture both attempts and compare the first request or response that diverges. “Works in VLC” proves that one client found a viable path; it does not prove that every RTSP assumption in the camera response is correct.
Does a 200 OK response to PLAY prove the stream is healthy?
No. It proves that the camera accepted the PLAY request for that control session. You still need to verify that media arrives on the negotiated UDP ports or interleaved channels and that its payload mapping, sequence, timestamps, and codec data match SDP.
Should I switch from UDP to TCP whenever video is missing?
Use the switch as a controlled test, not a permanent explanation. If TCP interleaved works while UDP does not, the difference points toward port negotiation, firewall, NAT, or UDP path handling. Preserve both SETUP exchanges and the media result so the network issue remains diagnosable.
Can packet capture alone explain every decoder error?
It can establish many transport and payload facts, but not every decoder implementation decision. Verify sequence continuity, fragmentation, marker use, payload type, SDP parameters, and parameter sets first. If those are coherent, compare decoder logs and a second known client without rewriting the capture evidence.
What is the fastest first check for a stream that stops after 30 seconds?
Inspect the Session timeout, keepalive behavior, RTCP events, and any TEARDOWN or server error near the stop. A repeatable duration often points to session maintenance or resource policy rather than random packet loss. Use the linked keepalive and cleanup guides to test the exact control sequence.
Getting started
New to RTSP diagnostics? Start here:
- Systematic diagnostic workflow — The three-layer model and evidence collection.
- Connect to a stream — Setting up your first RTSP connection.
- Troubleshooting guide — Common failures and their fixes.
Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-related-reading:end -->