RTSP, ONVIF, DVR/NVR, mixed brands, fully on-prem (no cloud dependency)
Table of contents
- Why this integration problem matters in India
- The 3 integration patterns that work (pick one)
- Step-by-step integration guide (field-tested approach)
- Step 1: Build a camera inventory that’s actually usable
- Step 2: Decide which stream you will use (main vs sub-stream)
- Step 3: Plan network and security (India reality: most issues are networking)
- Step 4: RTSP integration (the “works everywhere” baseline)
- Step 5: ONVIF integration (the “scale it properly” layer)
- Step 6: NVR/DVR realities (what you can and cannot assume)
- Three example deployments (with numbers you can sanity-check)
- What “good” looks like after integration
- FAQs
Why this integration problem matters in India
Most real-world CCTV deployments in India are “assembled systems”, not single-vendor stacks: one camera brand at the gate, another inside the building, a third for PTZ, plus an NVR that came from whoever won the tender. The result: your upgrade path breaks unless you design for interoperability.
Two standards make interoperability realistic:
- RTSP: the de-facto way most cameras expose a live video stream. RTSP servers typically use port 554 by default, which becomes important for firewall/VLAN planning.
- ONVIF: the industry’s interoperability layer for discovery, configuration and streaming control. ONVIF notes Profile S enabled basic video streaming interoperability across 33,000+ conformant devices and clients.
For an India-first buyer, on-prem analytics is not a “preference”, it’s often a constraint:
- multi-site bandwidth limits and unstable links,
- privacy and compliance constraints for identifiable video,
- operational reality: security teams need alerts even when internet is down.
The 3 integration patterns that work (pick one)
You can integrate an AI analytics box (edge compute) into existing CCTV in three practical ways. The “best” depends on your NVR/VMS and how much control you have over cameras.
Pattern A: Camera streams directly to the AI box (recommended when possible)
Camera (RTSP/ONVIF) → AI box → events/alerts + optional clips → security team
Pros: cleanest, lowest latency, easiest to scale analytics.
Cons: you must access camera credentials and ensure network reachability.
Pattern B: NVR provides streams to the AI box (works when cameras are locked)
Camera → NVR → AI box pulls streams from NVR (RTSP/SDK/secondary stream)
Pros: avoids touching camera configs.
Cons: some NVRs expose limited streams; you may get lower quality or higher latency.
Pattern C: SPAN/mirror from switch (only for special cases)
Camera traffic mirrored at switch → AI box
Pros: useful when credentials are unavailable.
Cons: messy, brittle, harder to maintain; avoid unless you have strong networking support.
Most Indian deployments end up using Pattern A for “important cameras” (gate, billing counters, perimeter) and Pattern B for the rest.
Step-by-step integration guide (field-tested approach)
Step 1: Build a camera inventory that’s actually usable
Create a sheet with:
- Camera make/model, location, purpose (gate, cash counter, warehouse aisle)
- IP address, VLAN/subnet, PoE switch port
- Resolution, FPS, codec (H.264/H.265), main stream and sub-stream
- Access method: RTSP URL known? ONVIF enabled? NVR-only?
This is the first place projects fail. If you can’t answer “which stream do we pull and from where”, integration becomes trial-and-error.
Step 2: Decide which stream you will use (main vs sub-stream)
Analytics does not always need your heaviest stream. Many sites overload networks by pulling the main stream for everything.
A practical starting point:
- People analytics, shoplifting, intrusion: sub-stream often sufficient (lower bitrate) if placement is good.
- Face recognition, number plate: prefer main stream or a higher-quality sub-stream.
To size bandwidth realistically, use typical vendor bitrate guidance. For example, Hikvision’s recommended bitrates show 1080p can range widely based on codec and FPS; their table lists 1080p H.265 around 2048 Kbps at 30 fps, and 1080p H.264 max bitrate can be 4096 Kbps at 30 fps (values vary by settings and scene complexity).
Translation: 16 cameras can be “fine” or “painful” depending on stream choice.
Step 3: Plan network and security (India reality: most issues are networking)
Minimum best practices for an enterprise or even a serious SME:
- Put cameras and NVR on a dedicated VLAN
- Allow AI box to reach camera subnet on required ports (RTSP commonly 554, plus HTTP/HTTPS for ONVIF depending on config)
- Avoid exposing camera subnet to corporate LAN
- Use strong credentials, rotate defaults, disable unused services
If you are deploying face recognition or anything that can identify a person, treat it as personal data processing. India’s DPDP Act creates rights around access/correction/erasure and frames obligations around processing. (Rules have also been notified, so operational compliance is becoming more real, not theoretical. )
Step 4: RTSP integration (the “works everywhere” baseline)
Most cameras and most NVRs can give you RTSP.
What you need
- RTSP URL format (varies by vendor)
- Username/password
- Whether you want TCP or UDP transport (TCP is more firewall-friendly)
RTSP basics that matter
- RTSP default port is typically 554.
- Many systems use alternate ports (8554 etc.) if 554 is blocked or repurposed.
Practical RTSP checklist
- Confirm you can open the stream from the AI box network (not from your laptop Wi-Fi)
- Prefer the sub-stream for bulk analytics to protect bandwidth
- Lock codec and FPS to stable values (avoid “auto” if it causes bitrate spikes)
Common India failure modes
- NVR and cameras sit behind double NAT or mismatched subnets in multi-building campuses
- Someone enabled “stream encryption” on a vendor-specific feature that breaks third-party RTSP clients
- A channel partner changed passwords but didn’t document them
Step 5: ONVIF integration (the “scale it properly” layer)
ONVIF is not just “another checkbox”. Used well, it reduces manual work:
- discover devices,
- pull supported profiles,
- confirm stream URIs,
- manage time sync and events more consistently.
ONVIF describes Profile S devices as those that can send video over IP to Profile S clients, which can configure and request streaming.
ONVIF also highlights that video systems can use profiles including S and T.
Important industry update: ONVIF has communicated deprecation guidance around Profile S and recommends moving toward Profile T and stronger security methods like TLS/HTTPS.
In practice, in India you will see both S and T in the field. Your integration should support both.
ONVIF checklist
- Enable ONVIF on the camera/NVR (many devices ship with it off)
- Ensure system time is correct (time drift can break event correlation)
- Prefer secure auth and avoid weak legacy modes where possible
Step 6: NVR/DVR realities (what you can and cannot assume)
In Indian deployments, “DVR” often means analog cameras via encoder, and “NVR” means IP. Your integration choices change:
If cameras are analog behind DVR
- You will not get ONVIF per camera
- You typically get 1 stream per channel from DVR/NVR
- Analytics quality depends heavily on encoder settings
If cameras are IP behind NVR
- You may still access cameras directly (best)
- Or pull RTSP per NVR channel (works, but sometimes limited)
Rule of thumb
- For “high-value outcomes” (face recognition, number plate, shoplifting): direct camera access is worth the effort.
- For “broad monitoring outcomes” (intrusion, loitering, crowd): NVR channel streams can be acceptable.
Three example deployments (with numbers you can sanity-check)
Example 1: Retail store, 16 cameras, want shoplifting + queue + people count
- Use sub-stream for 12 cameras (analytics)
- Use main stream for 4 cameras (billing counters and entrance)
- Expect per-camera bitrate to vary by codec/FPS; vendor tables show 1080p can be around 2 Mbps (H.265) to 4 Mbps (H.264 max) depending on configuration.
Outcome: stable analytics without upgrading WAN. Alerts can go to WhatsApp or app.
Example 2: Housing society, 64 cameras, want gate face recognition + ANPR + intrusion
- Gate cameras: main stream, tuned placement, dedicated VLAN, strict access control
- Perimeter cameras: sub-stream analytics, schedule-based intrusion
- Keep all processing on-prem; store only events/clips you need
Example 3: Factory, 120 cameras, want PPE + forklift near-miss zones
- Segment cameras by use-case: safety zone cameras prioritized, rest on lower stream
- Use ONVIF discovery for faster onboarding across mixed brands
- Run “proof-of-coverage” test: measure false positives by zone and lighting shifts
What “good” looks like after integration
A professional rollout ends with:
- A documented camera-to-model mapping (which analytics runs where)
- A bandwidth and compute budget that remains stable
- A daily/weekly operations rhythm: alerts, review, continuous tuning
- A change-control process: adding new cameras/models without breaking the system
This is also where the platform approach matters: once streams are integrated, adding new analytics should feel like installing a capability, not starting another integration project.
Integrating AI analytics with existing CCTV infrastructure often delivers strong ROI by reducing guard dependency and improving incident response without replacing cameras. You can estimate expected savings and payback timeline using our AI CCTV ROI calculator for existing CCTV systems.
FAQs
Yes, if your cameras or NVR can expose RTSP streams, and ideally ONVIF for discovery/control. RTSP is widely supported and uses port 554 by default in many systems.
ONVIF discovery can often surface stream URIs and supported capabilities, reducing manual vendor-specific work.
Mixed brand is exactly why RTSP + ONVIF exist. ONVIF cites interoperability across 33,000+ conformant devices/clients over time.
Not necessarily. On-prem analytics can run fully locally; internet is only needed for remote access, updates, or optional cloud reporting.
RTSP commonly uses port 554 by default. ONVIF typically uses HTTP/HTTPS depending on configuration; many environments also see RTSP on alternate ports like 8554.
It depends on resolution, codec, FPS, and scene motion. Vendor bitrate tables show 1080p can range from about 2 Mbps to 4 Mbps depending on codec/settings. Practical tip: use sub-stream for “wide coverage analytics” and reserve main stream for high-precision tasks.
If you pull camera streams directly, NVR is unaffected. If you pull from NVR, ensure it supports additional clients without choking. Do a 48-hour soak test.
Yes, but you’ll typically analyze per-channel encoded streams from the DVR/NVR, not individual camera ONVIF feeds. Quality depends on encoder settings.
RTSP is primarily for streaming control/transport. ONVIF is broader: discovery, device management, and standardized streaming access across vendors.
Profile S is widely deployed. ONVIF now recommends moving toward Profile T and stronger security approaches, while noting deployed Profile S systems continue to operate.
Segment networks (VLAN), restrict access, strong passwords, disable unused services, and prefer secure auth methods. If you process identifiable video, design retention and access controls carefully.
Yes. If video is identifiable personal data, DPDP obligations and rights become relevant (access, correction, erasure, etc.).
Use camera-specific zones, schedule policies, and tune thresholds by time-of-day lighting. Start with a pilot on 5–10 cameras and expand.
For 16–32 cameras with known credentials and clean networking: a few days including testing. For 100+ cameras with mixed brands and undocumented networks: plan a structured discovery and phased rollout.
A complete inventory, documented credentials handover, VLAN plan, stream plan (main vs sub), and a post-deployment tuning schedule.