Troubleshooting RTSP Streams for RTSP Inspector: Setup and Workflow Guide
RTSP failures follow a pattern. Work through these layers in order — each layer depends on the one below it working correctly.
Layer 1: Connection
Can the client reach the camera at all?
- Verify the camera is powered and on the network
- Ping the camera IP — confirms basic network reachability
- Check port 554 is open:
telnet <camera-ip> 554 - If behind a VPN, verify the VPN tunnel passes RTSP traffic (some corporate VPNs block non-HTTP ports)
- Check for firewall rules blocking port 554 or the RTP port range
Common failure: "Connection refused" or timeout. The camera is unreachable — fix networking before debugging RTSP.
Layer 2: Control plane (DESCRIBE, SETUP, PLAY)
Does the RTSP handshake complete?
| Error | Diagnosis | Check |
|---|---|---|
| 400 Bad Request | Malformed URL or headers | RTSP URL format, special characters, encoding |
| 401 Unauthorized | Authentication failure | Username/password, digest vs basic auth |
| 404 Not Found | Wrong stream path | Camera-specific URL format (Axis, Dahua, Hikvision differ) |
| 461 Unsupported Transport | Transport negotiation failed | UDP vs TCP, client port range, Transport header |
| DESCRIBE returns non-SDP | Wrong endpoint or proxy interference | Response Content-Type, proxy-injected headers |
Troubleshooting steps:
- Capture the full DESCRIBE request and response. Compare the request URL, headers, and CSeq to what VLC or ffmpeg sends successfully.
- Check the response Content-Type — it must contain
application/sdp. If it returns HTML or JSON, you're hitting the wrong endpoint. - If authentication fails, verify the auth mode (digest is more common than basic for IP cameras).
- For SETUP 461, check the Transport header. Try UDP first (RTP/AVP), then TCP interleaved (RTP/AVP/TCP).
Layer 3: Media plane (RTP, RTCP)
Control works but video/audio is broken?
| Symptom | Diagnosis | Check |
|---|---|---|
| PLAY 200 OK, no RTP arrives | Firewall or NAT blocking UDP | Client port reachability, NAT traversal, TCP interleaved fallback |
| RTP arrives, video is black | Payload type mismatch | SDP rtpmap, codec mapping, H.264 vs H.265 confusion |
| Video plays then freezes | Packet loss or session timeout | Sequence number gaps, RTCP loss reports, session keepalive |
| Block corruption / artifacts | Fragmentation or codec issues | H.264 FU-A fragments, NAL unit reassembly, IDR frames |
| Audio/video drift | Timestamp or clock rate | RTP timestamp vs NPT, clock rate in SDP, frame timing |
| Stream stops after ~30 seconds | Session timeout | RTSP timeout parameter, keepalive GET_PARAMETER |
Troubleshooting steps:
- Inspect RTP sequence numbers — gaps indicate packet loss
- Check RTP payload type byte against SDP rtpmap lines
- Verify RTCP sender reports for jitter and loss counts
- For H.264/H.265 issues, check SPS/PPS parameter sets are present
- Compare timestamps between audio and video tracks for sync issues
When in doubt: compare against a known-good baseline
Save the failing session as a .risession file. Connect to a camera that works correctly and save that session too. Compare:
- DESCRIBE responses: same SDP structure? Same codecs?
- SETUP negotiation: same transport mode?
- RTP payload: same payload type assignments?
- RTCP reports: similar loss and jitter?
The difference between the working and failing session usually points directly to the root cause.
When to escalate
If all three layers check out — TCP connects, RTSP commands succeed, RTP packets arrive with correct payload types and stable timestamps — but the video is still broken, the problem is likely in the decoder or application layer. Export a short PCAP of the RTP stream and hand it to the decoder team.