RTSP Inspector vs ONVIF Device Manager for Camera Stream Failures
Compare RTSP Inspector with ONVIF Device Manager when discovery works but RTSP URLs, SDP, transport, RTP, or codec diagnostics still fail.
Short answer: use ONVIF management tooling to discover a camera, inspect its media profiles, and obtain a candidate stream URI. Use RTSP Inspector when that URI must be tested as a protocol session: authorization, DESCRIBE and SDP, track control URLs, SETUP transport, PLAY, RTP/RTCP continuity, and codec evidence. If ONVIF discovery succeeds but video still fails, the next useful question is no longer “does the camera exist?” but “where does this specific RTSP session first diverge from the expected exchange?”
ONVIF Device Manager is useful for discovery, camera profile inspection, and finding stream URIs. RTSP Inspector is useful after that URI becomes a diagnostic case. If ONVIF works but RTSP fails, the problem has moved from device discovery to RTSP control, SDP, transport, RTP, RTCP, or codec behavior.
This comparison connects to the IP camera RTSP troubleshooting workflow because discovery is only the first part of the camera path.
Comparison table
| Need | RTSP Inspector | ONVIF Device Manager |
|---|---|---|
| Discover cameras | Not the main job | Strong fit |
| Find stream URI | Can test a known URI | Strong fit for ONVIF profiles |
| Diagnose RTSP status codes | Shows OPTIONS, DESCRIBE, SETUP, PLAY, headers, and status | Limited |
| Inspect SDP and codecs | Shows tracks, payload types, clock rates, control URLs, H.264/H.265 evidence | Limited |
| Diagnose transport | TCP interleaved, UDP unicast, channel, port, NAT, and firewall evidence | Limited |
| Export diagnostic reports | PDF, HTML, Markdown, JSON, and .risession cases |
Not the focus |
The handoff from ONVIF to RTSP
An ONVIF profile can identify a camera endpoint and provide a stream URI, encoder settings, or profile relationship. That is valuable configuration evidence, but it does not prove that a separate client can authenticate to the URI, resolve every SDP control attribute, negotiate a supported transport, receive media through the current network path, or decode the advertised payload.
Treat the URI as the beginning of a test rather than the conclusion of discovery:
- Record the selected ONVIF media profile and candidate RTSP URI with credentials removed from notes.
- Preserve whether the profile is intended as the main stream, substream, audio/video combination, or another camera-defined option.
- Connect with RTSP Inspector and capture the authorization exchange plus OPTIONS or DESCRIBE.
- Verify that DESCRIBE returns SDP and that each media section has a usable control target and payload mapping.
- Compare the requested SETUP transport with the server reply, including client/server ports or interleaved channels.
- Confirm PLAY status and Session continuity.
- Observe whether RTP and RTCP arrive and whether their payload type, sequence, timestamp, SSRC, and clock assumptions match SDP.
- Save the failing case and the first abnormal event before changing the camera profile or network path.
| Handoff item | ONVIF-side evidence | RTSP-side verification |
|---|---|---|
| Camera identity | Discovered endpoint, model, firmware, service address | The tested host and port are the intended camera interface |
| Media profile | Profile token, encoder choice, main/substream role | DESCRIBE advertises the expected tracks and codec |
| Candidate URI | Camera-provided RTSP URI | Request URI, authentication, and server response are accepted |
| Video settings | Resolution, codec, bitrate, frame-rate intent | SDP and observed RTP carry a compatible media description |
| Audio settings | Enabled track and codec intent | SDP control URI, payload mapping, clock rate, and arriving packets agree |
| Network choice | Interface or service address used for management | RTSP control and negotiated media path are reachable from the client |
This table prevents a common reporting mistake: “ONVIF says H.264, so the RTSP stream must be valid.” The profile establishes intended configuration. The RTSP session establishes what this client was actually told and what packets it actually received.
Best fit
Use RTSP Inspector when the ONVIF profile exists but the stream URL fails, the main stream differs from the sub stream, authentication loops, SETUP returns unsupported transport, or media packets do not arrive. Good companion articles are ONVIF works but RTSP URL fails, RTSP 401 and 404 diagnostics, and RTSP main stream vs sub stream.
RTSP Inspector is also a better fit when the case must be handed to a vendor. A report that shows the RTSP exchange, SDP, transport choice, RTP continuity, and RTCP timing is stronger than "the ONVIF profile looked correct".
Diagnose the first meaningful divergence
When the same camera appears in an ONVIF tool but fails elsewhere, compare the first protocol fact that differs rather than changing several settings at once.
| Symptom after successful discovery | First RTSP evidence to inspect | Useful controlled comparison |
|---|---|---|
| 401 repeats forever | WWW-Authenticate, realm, nonce, stale state, Authorization method |
Same URI and credentials in one working client |
| DESCRIBE returns 404 | Exact path, query, proxy behavior, camera profile URI | Main versus substream URI from the same profile set |
| SDP arrives but SETUP returns 404 | Media-level a=control, aggregate URI, URI resolution |
Absolute versus relative control target as returned by camera |
| SETUP returns 461 | Requested Transport and server-supported reply | UDP unicast versus TCP interleaved on the same session |
| PLAY is 200 but no media arrives | Negotiated ports/channels, first RTP time, firewall/NAT path | TCP interleaved test while preserving the failed UDP exchange |
| RTP arrives but video is black | Payload type, codec mapping, SPS/PPS or VPS, fragmentation, sequence gaps | Main/substream or a second decoder using the same captured facts |
| Stream stops predictably | Session timeout, keepalive, RTCP BYE, TEARDOWN, resource state | Same duration with explicit keepalive behavior recorded |
The ONVIF works but RTSP URL fails guide covers this transition in depth. The important discipline is to preserve both sides of the handoff: the profile that produced the candidate URI and the RTSP evidence that shows why the candidate did or did not become a viable stream.
Not a fit
Do not use RTSP Inspector as an ONVIF configuration console. It is not meant to replace camera discovery, device settings, profile editing, or ONVIF management. ONVIF Device Manager remains useful for locating cameras and reading profile metadata.
RTSP Inspector begins where that metadata stops being enough.
It is also not an ONVIF conformance tester. A passing RTSP stream does not prove that every ONVIF service, profile, event, PTZ, imaging, or management behavior is correct. Keep the acceptance criterion narrow: RTSP Inspector explains the stream control and media evidence it observes.
Where ONVIF Device Manager still belongs
Use ONVIF Device Manager to find the camera, inspect media profiles, and discover the vendor-provided stream URI. Then copy the RTSP URI into RTSP Inspector when you need to prove what happens during DESCRIBE, SETUP, PLAY, RTP, RTCP, and codec inspection.
The split is practical: ONVIF identifies a candidate stream, RTSP Inspector explains whether that stream actually behaves correctly.
Main stream and substream comparisons
Camera profiles often expose more than one stream. The main stream may use a higher resolution, bitrate, or different codec, while a substream is intended for lower-bandwidth viewing. If one works and the other fails, do not describe the camera as simply online or offline. Compare the two sessions layer by layer.
| Comparison | Question to answer |
|---|---|
| URI | Do the profile paths or query parameters differ exactly as expected? |
| Authentication | Is the same challenge method and realm used on both paths? |
| SDP | Do media sections, payload types, clock rates, control targets, and codec parameters differ? |
| Transport | Does either profile force a different UDP/TCP behavior or port allocation? |
| RTP | Does the failing stream send packets, and are there sequence gaps or SSRC changes? |
| Codec | Does the main stream use H.265 while the working substream uses H.264? |
| Camera capacity | Does disabling another client or reducing the active profile change a 503 or timeout? |
The main stream versus substream diagnostic gives the detailed workflow. A good vendor handoff includes both profile identities and the first evidence difference, not just two screenshots with different playback results.
What to include in a camera-vendor report
Use the smallest case that still proves the failure. Remove credentials from the report while retaining the method, URI shape, challenge type, status, and session sequence needed for review.
| Report section | Useful content |
|---|---|
| Camera context | Model, firmware, selected ONVIF profile, main/substream role |
| Client context | RTSP Inspector version, operating system, transport preference |
| Reproduction | Exact action and first failed expectation |
| Control evidence | OPTIONS/DESCRIBE/SETUP/PLAY sequence, status, Session and Transport headers |
| SDP evidence | Media sections, control attributes, codec and payload mappings |
| Media evidence | First packet time, sequence/timestamp behavior, SSRC, RTCP observations |
| Boundary | What the capture proves, what is inferred, and the next comparison |
Save a .risession case when another engineer needs the retained observations and replay context. Export a human-readable report when the recipient needs the concise conclusion and evidence table. The reports help explains the available handoff surfaces.
Questions about ONVIF and RTSP diagnostics
If ONVIF discovery works, is the RTSP port definitely reachable?
No. Discovery and management can use a different service path from RTSP control, and RTP media can use yet another negotiated path. Test the RTSP host and port directly, then preserve the transport details returned by SETUP.
Does a stream URI from an ONVIF profile guarantee that DESCRIBE will work?
No. The URI is a candidate supplied by the camera configuration. Authentication state, firmware defects, path handling, profile state, proxying, or a changed service address can still make DESCRIBE fail. The response status and headers are the next evidence.
Should I edit the camera profile immediately after a 461 response?
Not first. Record the requested and returned Transport values, then test a controlled UDP/TCP difference. A 461 means the requested transport was not accepted; it does not by itself identify which camera profile setting must change.
Why keep ONVIF profile details in an RTSP case?
They explain where the URI and expected codec came from. Without that context, a vendor may not know whether the client tested the intended main stream, substream, or stale profile.
Can RTSP Inspector configure camera profiles?
No. Use ONVIF or vendor management tools for discovery and configuration. RTSP Inspector is the diagnostic side of the handoff: it tests and explains the resulting RTSP session and media evidence.
Decision point
Use ONVIF tooling for discovery and configuration. Choose RTSP Inspector when the stream must be diagnosed, reported, or compared across network paths and clients. Start with the RTSP Inspector download and the connection guide.
For related cases, browse the RTSP Inspector blog index.
How do you build an ONVIF-to-RTSP evidence handoff?
Record the ONVIF device/service address, profile token, video/audio encoder settings, returned stream URI with secrets removed, transport requested from the media service, and time of discovery. Then begin a fresh RTSP connection and preserve DNS/connect, DESCRIBE, SDP, each resolved track URL, SETUP Transport, PLAY, RTP/RTCP, and the first media or decoder result.
| Handoff boundary | ONVIF evidence | RTSP evidence |
|---|---|---|
| Device/profile identity | Device info and profile token | Camera/NVR endpoint and sanitized URI |
| Media configuration | Codec, resolution, rate, audio state | SDP payload, clock, format parameters |
| Stream address | URI returned by service | Exact DESCRIBE request target and response |
| Transport intent | Requested stream setup | SETUP request and accepted Transport |
| Usability | Configuration appears valid | Control/media sequence actually succeeds or fails |
ONVIF success proves that a management service returned a profile and URI; it does not prove RTSP authentication, URI freshness, track-control resolution, network delivery, or decoder readiness. RTSP success does not prove that a profile change was saved correctly. Keep those ownership boundaries explicit.
What does a fair tool comparison require?
Use ONVIF Device Manager or equivalent tooling to answer discovery/configuration questions, then use the same profile and URI in the RTSP diagnostic run. Do not compare a main stream discovered through ONVIF with a manually typed substream URL and call the tools inconsistent. Record versions, clock/timezone, account policy, and whether the stream is direct from camera or relayed by NVR.
Acceptance means a second engineer can trace profile selection to the exact RTSP request and media outcome. Preserve the chain with RTSP Inspector reports and use ONVIF works but RTSP fails when discovery succeeds but the returned URI does not establish a valid session.
Retest profile drift and stale URIs
Change one harmless, reversible profile setting through the authorized management workflow, fetch the URI again, and compare profile token, endpoint host, path, query, codec settings, and timestamp with the prior record. Restore the intended configuration afterward. This test reveals clients that cache a stale URI or keep using an old profile after the camera/NVR reports a new one.
Run the RTSP session from both the management host and the actual client network when routing or NAT may differ. The ONVIF service address and returned RTSP host can belong to different reachable boundaries; preserve both instead of rewriting the URI silently.
The final case should name which tool owns the next action. Profile/encoder changes return to the ONVIF or vendor-management owner. DESCRIBE/authentication/SETUP/media failures go to the RTSP, camera, network, or client owner according to the first observed boundary. This prevents a configuration screenshot from being mistaken for playback proof and an RTSP trace from being used as evidence that a configuration was saved.
<!-- multilingual-related-reading:start -->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 -->