Distinguish DirectIP management from RTSP viewing
DirectIP setup can manage a camera within an IDIS recording installation, while RTSP is a separate media request from a viewer to a device. Identify whether the desired image should be received directly from the camera or through an NVR. That decision determines which IP address and user permissions to use.
The global FAQ separates camera track selection from recorder channel and stream selection. Do not interpret a number used in one format as the same thing in the other. Check the exact recorder firmware and enabled output options when using a recorder endpoint.
Verify the local RTSP service and account
- Record the camera or recorder model, installed firmware and local address. Identify the physical camera image you intend to view.
- Open the authorized device configuration and check whether RTSP output is available and enabled for that model. Read the currently configured port.
- Check the local user’s live-view rights. For a recorder, confirm permission for the intended camera channel rather than only general access to the recorder.
- Use the camera track syntax or recorder channel/stream syntax from the matching official instructions. Preserve all required parameters and avoid copying a cloud login into the stream credentials.
- Add the confirmed URI to SmartRTSP on a reachable local network. Verify the expected image and reconnection, then test another exposed stream only when needed.
rtsp://<camera-ip>:<configured-rtsp-port>/trackID=<documented-stream-number>Select a media track using the device instructions
The example above intentionally leaves the track number as a documented value. An available encoder and the device’s numbering convention must be confirmed on the exact model. Guessing a new track number does not establish that an additional stream exists.
For NVR output, IDIS’s FAQ describes trackID and streamID in a recorder-specific format. The recorder must expose that output and the user must be authorized for the requested image. A camera’s direct stream URI should not simply be moved to the recorder’s address.
Separate video verification from installation-wide features
Confirm ordinary live video before assessing audio, PTZ, events or recording search. Those functions can use different interfaces and permissions. Successful playback of an RTSP stream is not a complete reproduction of an IDIS management application.
When the picture is unstable, check the enabled encoder and compression, local bandwidth and connection path. If authentication fails, inspect the account and channel rights first. Preserve the working recorder configuration while adding an additional viewer.
Check each feature independently
Start on the same local network with the exact model, firmware and account permissions. A working video stream does not prove support for ONVIF discovery, pan or tilt, two-way audio, events, or every recording feature. Test the features you need in your installed SmartRTSP app.
Keep camera credentials private. Do not expose camera ports to the public internet just to test local viewing. Manufacturer cloud accounts, device accounts and generated sharing links are not interchangeable.
Frequently Asked Questions
Does DirectIP automatically supply a third-party RTSP address?
No. Identify the actual camera or recorder endpoint and follow its documented RTSP configuration and account requirements.
Does trackID always refer to a physical camera channel?
Not across every endpoint. Camera media tracks and recorder channel/stream parameters are documented separately.
Has the full IDIS range been tested with SmartRTSP?
No. Official documentation was checked on 2026-10-18. Verify the exact model, firmware and required functions on the physical installation.
Official sources and scope
Read the documentation for the exact model before changing settings. Manufacturer menus, firmware and service availability can change. These sources explain the published connection conditions, not independently verified SmartRTSP hardware compatibility.