An IP camera stream failure is rarely just “RTSP does not work”. The useful question is more specific:
- Did RTSP authentication succeed?
- Did DESCRIBE return the SDP you expected?
- Did SETUP choose TCP interleaved or UDP RTP?
- Is media arriving after PLAY?
- Are RTP sequence numbers continuous?
- Does the codec profile match what the client can decode?
- Is ONVIF handing the VMS a different URI than the one you tested in VLC?
When a camera plays in VLC but not in an NVR/VMS, the failure is usually in the gap between “the stream exists” and “this client can negotiate, receive, and decode it reliably”.
Start with the exact URI
Do not compare two different tests.
Write down the full RTSP URL used by each client:
rtsp://user:pass@camera.local:554/path
Check for differences in:
- profile path
- channel number
- stream subtype
- query parameters
- username/password encoding
- transport settings
- ONVIF-generated URI vs manually copied URI
Many cameras expose multiple profiles. VLC may be opening the main stream while the VMS is using a substream, or vice versa.
Check the RTSP control flow
A normal session usually looks like this:
OPTIONS
DESCRIBE
SETUP video
SETUP audio (optional)
PLAY
TEARDOWN
Useful failure patterns:
401 loop
Authentication is not being accepted. Check digest/basic auth, clock drift on some devices, special characters in passwords, and whether the VMS encodes credentials differently.
DESCRIBE succeeds, SETUP fails
The client can read metadata but cannot negotiate media transport. Check UDP/TCP mode, client ports, firewall/NAT, and multicast settings.
PLAY succeeds, black screen
The control session succeeded, but media or decoding failed. Now inspect RTP and codec details.
Read the SDP instead of guessing
The DESCRIBE response should return SDP similar to:
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:trackID=1
a=fmtp:96 packetization-mode=1; profile-level-id=...
Check:
- codec: H.264, H.265, MJPEG
- payload type
- control attribute
- SPS/PPS availability for H.264
- profile-level-id compatibility
- audio track that may confuse weaker clients
A stream can be valid but still use a profile or packetization mode the receiving system handles poorly.
Verify RTP actually arrives
If RTSP SETUP selected UDP, confirm that RTP packets arrive on the negotiated ports.
Symptoms of blocked media:
- RTSP commands return 200 OK
- PLAY succeeds
- no RTP packets arrive
- no RTCP receiver reports
- client shows black screen or timeout
This often means firewall, NAT, VLAN, routing, or client port negotiation is the real issue.
If TCP interleaved works but UDP does not, you have a transport path problem, not necessarily a camera problem.
Inspect RTP continuity
When packets arrive but playback freezes or breaks, look for:
- sequence gaps
- timestamp jumps
- marker bit behavior
- payload type changes
- RTCP sender reports
- jitter patterns
A few packet losses may be tolerable. Repeated gaps around keyframes can make a stream look like a decode failure.
ONVIF handoff can hide the real URI
Many VMS products discover cameras through ONVIF, then request stream URIs from the device.
That URI may not match the one you tested manually.
Compare:
- ONVIF profile token
- returned media URI
- transport protocol requested by ONVIF client
- main/sub stream selection
- authentication behavior after handoff
If VLC uses a hand-written URI and the VMS uses an ONVIF URI, you have not tested the same thing yet.
What to hand to support
A useful report should include:
Camera model / firmware
Client name and version
RTSP URL path (without password)
Transport mode: TCP or UDP
RTSP request/response summary
SDP video/audio details
RTP arrival status
Packet loss or sequence gap notes
Codec profile notes
Exact failure symptom
That is much more actionable than “camera does not play”.
Where RTSP Inspector fits
You can do parts of this manually with VLC logs, Wireshark, ONVIF tools, and packet captures. The hard part is turning those pieces into a compact handoff that a camera vendor, installer, or VMS support team can understand.
I build RTSP Inspector for that workflow. It is a local desktop tool for RTSP, RTP, RTCP, SDP, ONVIF handoff, packet loss, and codec-readiness diagnostics. It is not a VMS, NVR, surveillance recorder, or media player; it is meant to explain why a stream does or does not work.
A practical workflow is:
- Reproduce the failure with the same URI the client uses.
- Capture RTSP control messages and SDP.
- Confirm transport mode and media arrival.
- Inspect RTP/RTCP evidence.
- Export a report for support handoff.
Disclosure: I build RTSP Inspector.
Quick checklist
[ ] Same RTSP URI in both clients
[ ] Authentication result known
[ ] DESCRIBE response saved
[ ] SDP codec/profile inspected
[ ] SETUP transport mode known
[ ] RTP arrival confirmed
[ ] RTP sequence gaps checked
[ ] ONVIF media URI compared
[ ] Report prepared for support