2026-06-20

RTSP Diagnostics FAQ for Camera Teams Debugging Stream Failures

Answers to common RTSP diagnostics questions about VLC, ONVIF, UDP, TCP, SDP, RTP loss, RTCP timing, camera reports, and RTSP Inspector.

This FAQ answers the questions camera vendors, CCTV integrators, NVR teams, and video platform engineers ask when a stream connects, fails, freezes, or behaves differently across clients. It pairs with the IP camera RTSP troubleshooting workflow.

Is RTSP Inspector a replacement for VLC?

No. VLC is a player. RTSP Inspector is a diagnostic and reporting workbench. Use VLC to see whether a stream can play. Use RTSP Inspector to explain RTSP status, SDP, transport, RTP, RTCP, and codec behavior when the result is ambiguous.

Why does VLC play the stream but my NVR or analytics app fails?

VLC may tolerate stream behavior that stricter clients reject. Common causes include SDP mismatch, missing SPS/PPS, H.265 compatibility, RTP packet loss, timestamp drift, payload type mismatch, or transport differences. RTSP Inspector helps prove which boundary failed.

What is the difference between ONVIF and RTSP diagnostics?

ONVIF helps discover devices, profiles, and stream URIs. RTSP diagnostics explains what happens after a URI is tested: DESCRIBE, SETUP, PLAY, SDP, RTP, RTCP, and codec structure. See RTSP Inspector vs ONVIF Device Manager.

Should I try UDP or TCP interleaved first?

Try the path that matches production, then compare. UDP can expose firewall, NAT, and packet-loss issues. TCP interleaved can pass through stricter networks but may hide network loss behind a reliable stream. Use RTSP timeout over UDP or TCP and RTSP UDP blocked by firewall or NAT.

What does SDP prove?

SDP proves what the camera claims about tracks, codecs, payload types, clock rates, control URLs, and media parameters. If SDP is wrong, playback can fail before any useful video analysis begins. Read SDP, H.264, and H.265 diagnostics.

What does RTCP add beyond RTP packet loss?

RTP shows packet delivery and timestamps. RTCP adds sender reports, timing context, packet counts, jitter, CNAME, and stream-health evidence that helps distinguish network loss from camera timing behavior.

When do I need a diagnostic report?

Use a report when the case must leave your screen: customer support, camera vendor escalation, QA evidence, field-service notes, or internal debugging. RTSP Inspector Professional exports PDF, HTML, Markdown, JSON, and saved .risession cases.

Is RTSP Inspector useful if I already have Wireshark?

Yes, when the task is RTSP diagnostics rather than broad packet analysis. Wireshark can show packets. RTSP Inspector organizes RTSP, SDP, RTP, RTCP, and codec evidence into a focused workflow and report path.

Where should a camera team start?

Start with the IP camera RTSP troubleshooting workflow, then use RTSP Inspector connect help. Download

RTSP diagnostics: collect evidence in the order a camera session happens

An RTSP camera problem is easier to solve when the team stops asking “does it play?” as the only question. A video client may connect, authenticate, show a still frame, or display live video while a VMS, recorder, or mobile client fails at a different boundary. The diagnostic sequence should preserve what the camera said and what the client requested before a player hides the protocol details.

Session boundary	What to record	What it can prove	Related investigation
URI and DNS reachability	Exact RTSP URI, host, port, client location, and time	Whether every client is testing the same endpoint and network path	RTSP connects but no video
Authentication	Status code, challenge scheme, realm, and redacted username context	Whether the failure is credentials, digest negotiation, or an application loop	RTSP 401 authentication loop
DESCRIBE and SDP	SDP body, tracks, payload types, control URLs, codecs, and clock rates	What the camera advertises before media starts	SDP and codec diagnostics
SETUP	Requested transport, server reply, interleaved channels, ports, and Session header	Whether the selected media path was accepted	RTSP unsupported transport
PLAY and Range	Range request/reply, RTP-Info, sequence numbers, and timestamps	Whether playback begins where the client believes it does	RTSP Range header and npt=now
RTP media	SSRC, sequence continuity, marker bits, timestamp pace, loss, duplicates, and reordering	Whether packets arrive and form plausible media access units	RTP packet loss for camera streams
RTCP	Sender reports, jitter, packet counts, CNAME, BYE, and timing	Whether camera timing and media lifecycle support the RTP story	RTCP sender reports and jitter

This order prevents a common escalation failure: a team captures a player screenshot after several retries but cannot say whether the failure occurred at DESCRIBE, SETUP, PLAY, the first media packet, or decoder readiness. A useful RTSP diagnostic report should let another person reconstruct that boundary without needing the original camera or the same player open on the same laptop.

A field runbook for a camera stream that fails in one client

Freeze the test input. Copy the exact RTSP URL privately into the case record, then redact passwords from any shared report. Note the camera model, firmware if known, client name/version, network location, and time window. Do not silently substitute a “similar” stream URL after the first failure.
Run the production transport first. If the VMS uses UDP, test UDP before switching to TCP interleaved merely to obtain a picture. If TCP works and UDP does not, that is useful evidence about firewall, NAT, multicast, or packet delivery—not proof that the camera is fixed.
Capture the control conversation. Record OPTIONS, DESCRIBE, SETUP, PLAY, status codes, headers, CSeq progression, Session identifiers, and the SDP. If the client fails before RTP, this is the evidence that matters most.
Measure the first media interval. For a black screen, inspect whether RTP actually arrives, whether sequence numbers move, whether the payload type matches the SDP, and whether parameter sets or keyframes appear when expected. “Packets exist” is not equivalent to “a decoder can start.”
Compare a second client only after saving the first case. A second client can reveal compatibility differences, but its success should not overwrite the first client’s trace. Compare the URI, headers, transport request, accepted tracks, and timing behavior side by side.
Produce a bounded conclusion. Write what the trace supports: for example, “DESCRIBE succeeds; UDP SETUP is accepted; no RTP reaches the client network,” or “RTP arrives but the advertised H.265 payload is not decoder-ready.” Avoid claiming a root cause that the capture cannot prove.

RTSP Inspector is a focused desktop evidence workflow for this sequence. It is not an NVR, a cloud monitoring service, or a promise that every proprietary camera stream can be made playable. Its job is to retain the control, SDP, RTP, RTCP, and report evidence needed to identify the failure boundary. The troubleshooting help explains the operational limits and the case replay guide explains how a saved .risession can be handed to another engineer.

Fast answers to recurring RTSP failure patterns

ONVIF discovery works, but the RTSP URL fails. What does that mean?

ONVIF discovery and RTSP playback are separate stages. Discovery can return a device profile or URI while the later RTSP connection fails because of authentication, a malformed path, an unsupported transport request, a missing media track, or a network boundary. Record the exact URI supplied by discovery and then inspect the RTSP conversation rather than treating ONVIF success as playback proof.

RTSP connects but there is no video. Should we change codecs first?

Not yet. Start with the SDP and the first RTP interval. Confirm that the selected track, payload type, clock rate, control URL, and transport match what the client uses. Then look for packet continuity, parameter sets, keyframe readiness, and a timestamp pace that makes sense. Codec settings may be relevant, but changing them before preserving the evidence can erase the only reproducible symptom.

Why does VLC play the stream while a VMS fails?

Different clients may request different transports, choose different tracks, tolerate malformed SDP differently, send different keepalives, or start decoding with different assumptions. “VLC works” is a comparison point, not a diagnosis. Capture both paths and identify the first meaningful divergence. The VLC and Wireshark alternative guide explains why a player result alone is usually too coarse for escalation.

Is TCP interleaved always safer than UDP?

TCP interleaved can be easier to pass through constrained networks, but it changes the delivery behavior and can conceal loss that would be visible over UDP. UDP is not inherently wrong; it is often the intended production path. Test the path that users actually rely on, then compare transports to identify whether the failure belongs to media delivery, network policy, or the camera session itself.

What should a vendor escalation include?

Include the redacted RTSP URI, camera/firmware context, client context, timestamps, request/response sequence, SDP, selected transport, concise RTP/RTCP observations, and a statement of what reproduces the issue. Attach a report or saved case when the recipient can use it. Do not send raw credentials, unrelated traffic, or a conclusion stronger than the available evidence.

When a report is good enough to hand off

A good report answers three questions quickly: what was tested, where did the session first diverge from expectation, and what evidence supports that boundary? It does not need to be long to be useful. A field engineer should be able to say “the camera returned this SDP; this client requested UDP; SETUP succeeded; RTP did not reach the capture point,” and a camera vendor should be able to reproduce or challenge that claim with a specific next test.

That standard makes RTSP diagnostics scalable across installers, support teams, QA, and vendors. It replaces a vague black-screen ticket with a small, reviewable packet-and-protocol narrative. For a practical next step, use the camera-stream troubleshooting workflow to collect the first case consistently, then preserve the same sequence for the next client comparison.

What should every closed RTSP ticket answer?

State whether DNS/TCP/TLS connected, which RTSP method first failed or succeeded, whether SDP described usable media, which transport was negotiated, whether RTP arrived with continuous sequence and advancing timestamps, and whether codec configuration preceded the first decodable frame. Add the controlled comparison and the owner of the next action. A ticket is not closed merely because one player displayed video; it is closed when the observed boundary and recovery are reproducible.

Record the tested camera profile and firmware only when verified.

Related guides

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