Normalize what support asks for
The same report structure captures RTSP control, SDP, RTP, RTCP, transport, codec readiness, and case metadata for every customer stream.
VMS and NVR support teams
Triage customer RTSP stream failures before escalating to engineering
Customer RTSP tickets usually arrive as screenshots, VLC claims, and partial URLs. RTSP Inspector turns them into a support packet engineering can act on.
Field problems
What this page is built to solve
- The customer says VLC works, but your VMS cannot decode or record the stream.
- Support does not know whether the issue is URL format, authentication, SDP, transport, RTP, or codec readiness.
- Engineering receives escalations without packet, timing, or stream-structure evidence.
- Vendor back-and-forth stalls because each side asks for a different log.
- Support needs a repeatable answer that works across camera brands.
Why RTSP Inspector
The output is a failure boundary.
Reduce low-quality escalations
Cases can be separated into wrong URL/auth, unsupported transport, no media, packet loss, codec incompatibility, or camera-side server behavior before engineering is pulled in.
Attach evidence instead of opinions
PDF and HTML reports can go to customers, vendors, or internal issue trackers, while .risession keeps the diagnostic case replayable.
Workflow
From stream URL to handoff report
-
1
Ask the customer for the RTSP URL, camera model, NVR/VMS version, and failure symptom.
-
2
Run the URL in RTSP Inspector with TCP and, when needed, UDP transport.
-
3
Export the evidence packet and classify the failure boundary.
-
4
Escalate only with the report attached, or send the customer a concrete fix request.
Stop sending screenshots as evidence.
RTSP Inspector connects RTSP control, SDP, transport, RTP, RTCP, codec readiness, likely cause, recommended fix, and exportable evidence in one report path.