ONVIF, GB28181, or RTSP

Do not choose the protocol with the most features. Choose the one that can run reliably at the site. For the first camera, the table below is enough.

Choose in one minute

Site condition	First choice	What you get
A stable `rtsp://...` address is known and only video is needed	RTSP	Fewest steps and fastest preview
Camera is on the same LAN and discovery, main/sub streams, PTZ, or image settings are needed	ONVIF	Device information, Profiles, media URL, and control capabilities
Camera/NVR registers to the center or GB cascading is required	GB28181	SIP registration, catalog, playback, recorded playback, and cascading
Across the Internet and the center cannot actively reach the device	GB28181 or active push	Device creates the connection and usually handles NAT better

flowchart LR
    A{"Do you have a stable RTSP URL?"}
    A -- yes --> R["Start with RTSP"]
    A -- no --> B{"Can the platform actively reach the device?"}
    B -- yes --> O["Start with ONVIF"]
    B -- no --> G["Use GB28181 or active push"]

When to choose RTSP

Use it when “the video address is known and only playback and recording are needed.” It usually does not provide discovery, complete PTZ, image settings, or events.

Its advantage is fewer variables. After verifying the URL, create it under Onboarding → Manual RTSP channel.

When to choose ONVIF

Use it for LAN cameras and NVRs. The platform can discover devices, read multiple Profiles and StreamUri values, and show PTZ, image settings, or events according to real capabilities.

ONVIF behavior varies by vendor. Signing in to the device webpage does not prove that a dedicated ONVIF account, clock synchronization, and Profiles work.

When to choose GB28181

Use it for GB devices, large-scale registration, and platform cascading. The device registers through SIP and returns a Catalog. For playback, the platform sends INVITE and the device sends RTP video.

“Registered” completes only the first step. Catalog, channel activation, INVITE, RTP arrival, and browser playback still require verification.

Do not onboard the same camera repeatedly

Using three protocols for one physical channel can cause:

duplicate channels in the asset tree;
duplicate pulling and recording of the same video;
duplicate license usage;
external systems not knowing which channel ID is primary.

Combine protocols only when one must provide video and another control, and record the primary channel and auxiliary control binding.

Selection success criteria

You can explain why this protocol was chosen and which capabilities were deferred.
One real target model completes authentication, channel generation, and browser preview.
Restart and repeated synchronization do not create duplicate channels.
Only then begin batch onboarding of the same model.

Next: follow the detailed steps for RTSP, ONVIF, or GB28181.