What Is ONVIF? Protocol Guide for CCTV Buyers (2026)

Table of Contents
A buyer pairs a so-called "ONVIF compatible" NVR with a cheaper camera from a different brand and gets a blank screen on the first site visit — no discovery, no stream, no image, and a customer who has lost confidence before lunch. That scenario repeats across the industry because "ONVIF" is treated as a magic word that guarantees every device talks to every other device. It does not work that way. ONVIF is an open standard for how network video devices discover, configure and stream — but the standard only does what the camera firmware and the recorder both implement, and the implementation depth varies far more than most buyers expect.
This guide answers the question "what is ONVIF" in plain language, explains how ONVIF works under the hood (discovery, SOAP/XML, ports 80 and 554), walks through the ONVIF Profile S, G and T grades, separates "ONVIF compatible" marketing from genuine "ONVIF compliant" certification, shows how ONVIF and RTSP divide the work of a single camera, and ends with a verification routine and a business buyer checklist. By the end you will be able to read a spec sheet's ONVIF line and know exactly what it promises — and what it does not.
Keep reading for more!
The Snapshot
- ONVIF is the Open Network Video Interface Forum, an industry standard founded in 2008 by Axis, Bosch and Sony, now backed by more than 500 member companies worldwide. It defines how IP cameras, NVRs and software talk to each other over a network.
- ONVIF does not carry the video itself. The standard handles discovery, device configuration and control over HTTP (typically port 80), while the actual video stream travels separately over RTSP, typically on port 554.
- ONVIF profiles are the real specification. Profile S (2011) covers streaming, Profile G (2014) covers recording and storage, Profile T (2018) adds modern H.264/H.265 streaming. "ONVIF" alone on a spec sheet is meaningless; the profile is the promise.
- "ONVIF compliant" means tested; "ONVIF compatible" usually means marketing. Compliant devices pass ONVIF conformance testing and appear on the forum's list; compatible devices often implement only basic discovery and fail on PTZ, audio or recording calls.
- Verification takes ten minutes, not a full project. Check the conformance list, confirm the profile and firmware ONVIF version, then run a free discovery tool against the actual unit before you commit to a mixed-vendor order.
What Is ONVIF?
ONVIF stands for Open Network Video Interface Forum. It is a global standard, launched in 2008 by Axis Communications, Bosch Security Systems and Sony, that defines common interfaces for network video products. The driving problem was fragmentation: in the mid-2000s every camera manufacturer had a proprietary way to configure, control and stream video, so an NVR from one brand could not reliably manage cameras from another. ONVIF was created so that a camera, a recorder, a video management software (VMS) and a mobile app could exchange discovery, device information, media configuration, PTZ commands and alarm events using one shared language.
The organization behind the standard is a nonprofit forum with a typical membership of more than 500 companies — camera makers, recorder makers, software vendors, chip suppliers and system integrators. Any member can contribute to the specifications, and any manufacturer can build a conformant product. The result is an ecosystem where an ONVIF camera from one factory can be added to an ONVIF NVR from another factory, and where a building owner is not locked into a single vendor's software for the life of the installation. That interoperability is the entire point of the standard.
What does ONVIF actually cover? The specifications are organized into three layers. The first is device discovery — how software finds cameras on a network. The second is device management — how software reads device information, sets network parameters, manages users and updates system time. The third is media services — how software requests video streams, controls PTZ movement, manages recording and receives alarm events. An ONVIF camera implements these services over a standard web protocol stack, which is why the standard is described as an open interface rather than a proprietary application.
Two details matter for buyers. First, ONVIF is not a codec and not a video format: it does not define H.264 or H.265, it defines the interfaces around them. Second, ONVIF is versioned — the core specification has moved through versions such as ONVIF 2.0, 2.4 and 3.0, and a camera with old firmware may implement an older version with fewer functions. When a spec sheet says "ONVIF 2.0", that is a statement about the interface version, not about the camera's resolution or lens.
How ONVIF Works: Discovery, SOAP and Ports
Understanding how ONVIF works is simpler than the acronym soup suggests. The standard uses three well-known web technologies: HTTP, SOAP/XML for the control messages, and RTSP for the video stream. The control plane and the media plane are separate, and this separation is the root of most "ONVIF doesn't work" confusion.
Discovery: an ONVIF client finds cameras without typing IP addresses. When a camera boots on a local network, it announces itself using WS-Discovery, a multicast protocol typically on UDP port 3702. An NVR or app on the same subnet listens for these announcements, or sends a probe and collects the replies. This is why an ONVIF NVR can show a list of cameras the moment they are plugged in — the discovery step is automatic, usually completing in seconds on a local subnet.
Control: configuration and commands travel as SOAP/XML over HTTP. After discovery, the client calls ONVIF web services on the camera's HTTP interface, typically port 80 (or port 443 when HTTPS is enabled). Each call is an XML message — GetDeviceInformation, GetProfiles, GetStreamUri, ContinuousMove for PTZ — and each one returns an XML response. This is why ONVIF integration is described as "web services for cameras": it is the same request-response pattern a browser uses to load a page, just with structured commands.
Media: the actual video moves over RTSP, typically port 554. When software wants to watch or record, it asks ONVIF for the stream URI, and the camera answers with something like rtsp://192.168.1.64:554/stream1 — then the NVR or app opens that RTSP session and the video flows as H.264 or H.265 frames. ONVIF set up the conversation; RTSP carries the pictures. That pairing is what buyers mean by "onvif video" support: the ONVIF side manages the video configuration, and the RTSP side delivers the frames. A typical 4MP camera streams 2-4 Mbps over RTSP with H.265 at 15 fps, which is the number that matters for bandwidth planning.
The practical consequence: for ONVIF to work end to end, the network must allow the HTTP control port, the RTSP media port and the discovery multicast. On a flat LAN this works out of the box. Across VLANs or firewalls, port 80, 554 and UDP 3702 must be permitted, and time synchronization (NTP) should be enabled on cameras so event timestamps match between devices.
ONVIF Profiles: S, G and T Explained
An ONVIF profile is a published set of services that a conformant device must implement. Instead of claiming generic "ONVIF support", a manufacturer declares a specific profile, and that declaration is what a buyer should look for. The three profiles that matter for CCTV procurement are S, G and T.
| Profile | Released | What It Covers | Typical Use |
|---|---|---|---|
| Profile S | 2011 | IP video streaming, audio, PTZ control, basic motion alarm | Adding IP cameras to NVRs and VMS |
| Profile G | 2014 | Recording, playback and storage management on the device | Edge recording, camera-side storage, exports |
| Profile T | 2018 | Advanced streaming: H.264/H.265, 4K-class resolution, motion metadata, improved audio | Modern high-resolution deployments |
← swipe to scroll →
Profile S is the baseline that most CCTV buyers actually need. If a camera is Profile S conformant, an NVR or app that also supports Profile S can discover it, request streams and control PTZ without any manufacturer-specific driver. Profile S was released in 2011, which is why it is the most widely implemented profile in the market — nearly every IP camera on a price sheet carries it.
Profile G covers recording. A Profile G device can start and stop recording, store footage locally on SD card or internal storage, and serve playback back to a client. It matters when cameras record at the edge, on solar or 4G sites where the recorder is not always reachable, or when a site needs on-camera export as a backup path. Profile G was released in 2014.
Profile T is the modern streaming profile, released in 2018. It covers H.264 and H.265 streaming at high resolution, metadata such as motion regions, and improved audio handling. For a 4K-class or H.265 site, Profile T support is the meaningful check — a camera that only implements the older Profile S may still stream, but the modern compression and metadata functions are not guaranteed.
There are also specialist profiles — Profile C for door control and Profile A for access control — that matter for physical access systems rather than video. The rule for a video buyer is simple: write the profile letter into the specification. "ONVIF Profile S" is a real requirement; "ONVIF" alone is not.

ONVIF Compatible vs ONVIF Compliant
Few spec-sheet words are abused as consistently as these two. "ONVIF compliant" and "ONVIF compatible" sound interchangeable, but they sit on different sides of a testing boundary — and the difference decides whether your mixed-vendor system works on day one.
ONVIF compliant means the product passed ONVIF conformance testing. The manufacturer submits the device to ONVIF's conformance process, the device is tested against the published test tooling for the declared profile, and the result is published on the ONVIF conformant products list. A compliant camera carries a conformance statement naming its profile — Profile S, G or T — and a buyer can look it up. This is the strongest claim a spec sheet can make, because it is verifiable against an independent list.
ONVIF compatible is a marketing term with no official definition. A manufacturer can print "ONVIF compatible" because the camera responds to a discovery probe or implements a fraction of the web services. In practice such cameras often join a network and appear in a device list, then fail the moment the NVR asks for PTZ movement, a second stream or an event subscription. Compatibility claims are not published anywhere and cannot be verified — which is exactly why they appear on products that never passed conformance.
The grey zone is firmware version. A camera that passed conformance at ONVIF 2.0 may run firmware that is years old, and the profile implementation can regress or stay frozen while the rest of the camera improves. The checks to run before trusting any claim: confirm the profile letter, confirm the ONVIF core version on the firmware, and look the device up on the conformant products list. If the supplier cannot name the profile and the version, the "compatible" sticker is all you have — and that is not a specification.
For wholesale orders the risk compounds. A batch of 200 "ONVIF compatible" cameras that cannot record through the customer's chosen NVR creates a recall, not a support ticket. That is why every serious buyer turns the compatibility question into a test: put one sample on the network, run discovery, request PTZ and both streams, and only then scale the order.
ONVIF and RTSP: Two Standards on One Camera
ONVIF and RTSP are frequently confused because they appear on the same spec sheet and both matter for streaming. The clean way to think about them: ONVIF is the control plane, RTSP is the media plane, and a single camera speaks both at the same time.
RTSP — Real Time Streaming Protocol — is the standard that actually delivers the video frames. Defined in RFC 2326 and updated in RFC 7826, RTSP sets up and controls media sessions: the client asks for a stream URI, the server responds, and the frames flow as RTP packets, typically over UDP or TCP on port 554. RTSP is not specific to cameras — it is used for all kinds of media servers — and it has no idea what a PTZ motor is, what an alarm input is, or even what an IP address the camera has. It only moves media.
ONVIF is what makes RTSP usable in a camera system. ONVIF discovers the camera, reads its capabilities, and returns the exact RTSP URI to use — the stream address, the encoding profile, the resolution and frame rate configuration. Without ONVIF you would have to know the camera's IP address, login and proprietary stream path before RTSP could do anything. With ONVIF, the recorder asks "give me your stream URI" and the camera answers with the rtsp:// address to connect to.
This is also why "onvif rtsp" appears together in so many searches: integrators need both values when configuring a system. The ONVIF side gives them the device list and credentials management; the RTSP side gives them the streams that third-party software, analytics or a media server can consume directly. A typical integration uses ONVIF to discover and configure, then RTSP to pull the main stream (2-4 Mbps at 4MP H.265) and the sub-stream (0.5-1 Mbps) for preview and recording.
The practical difference for procurement: a camera that supports RTSP but not ONVIF can still be watched by software that knows its stream path — but it cannot be discovered, cannot be configured, and cannot report events through the standard. For multi-vendor systems, ONVIF support is the difference between a camera that joins the system and a camera that must be driven by one manufacturer's tool forever.
ONVIF App and VMS Integration
When a buyer searches for an "ONVIF app", the question underneath is usually: "can I add this camera to my recorder, my phone app or my VMS without vendor lock-in?" The answer is yes — if both sides implement the same profile. Here is the standard flow, which works the same way on an NVR, a VMS workstation or a mobile viewer.
Step 1 — Discovery. The app scans the local subnet with WS-Discovery and lists every ONVIF device it finds. This typically takes seconds and requires no typing: the camera appears with its model name and IP address. If the camera is on another network segment, the app may require a manual IP entry — multicast discovery does not cross VLANs by default.
Step 2 — Authentication. The app prompts for the camera's username and password. ONVIF credentials are the camera's own user accounts, not a separate ONVIF account. This step is where default-password cameras become a security problem: a camera left on its factory credentials is discoverable by anyone on the network, so change the password before connecting anything to the internet.
Step 3 — Profile negotiation. The app reads the camera's ONVIF profiles and picks the streaming configuration that matches — resolution, frame rate, H.264 or H.265, main stream or sub-stream. On a typical 5MP full-color camera the app chooses the H.265 main stream at 2-4 Mbps for recording and the sub-stream for live preview. The whole add process usually takes 30 seconds to 2 minutes per camera.
Step 4 — Stream and control. The app requests the RTSP URI through ONVIF and starts displaying video. PTZ buttons, motion events and audio calls all travel back over the ONVIF control channel. If the camera is Profile T and the app supports Profile T, the modern metadata features are available too.
Two caveats for buyers. First, many consumer camera apps are proprietary — they use the manufacturer's own SDK and do not speak ONVIF at all, which is why a cheap consumer camera can be "added" only through its own app. Second, ONVIF integration is not always full integration: a VMS may use ONVIF for discovery and streaming but still need a manufacturer driver for advanced features like analytics, privacy masking or unusual PTZ presets. The professional rule is to confirm which functions run over ONVIF and which need a driver — before the contract, not after.

How to Verify ONVIF Compliance Before You Buy
Verification is cheap, fast and decisive — and it separates buyers who read spec sheets from buyers who test products. The routine below takes about ten minutes per sample and catches the failures that produce blank screens on site.
| Check | What to Look For | Typical Pass |
|---|---|---|
| 1. Conformance list | Device model on the ONVIF conformant products list | Listed with profile and core version |
| 2. Spec sheet profile | Profile letter (S, G, T) stated, not generic "ONVIF" | Named profile with version |
| 3. Firmware version | ONVIF core version in the device information | ONVIF 2.x or newer, current firmware |
| 4. Discovery test | Camera appears in a free ONVIF discovery tool | Found in seconds on the local subnet |
| 5. Stream test | Main and sub-stream play through an ONVIF client | Both streams play, RTSP URI returned |
| 6. Control test | PTZ and event calls work over ONVIF | Commands executed, events received |
← swipe to scroll →
The fastest practical check is a discovery tool on a laptop. Free ONVIF client software scans the subnet, lists devices and shows the profile and stream URIs each camera exposes. Plug the camera into a PoE switch, run the scan, and you will see exactly what the camera advertises — its ONVIF version, its profiles and its RTSP paths. A camera that answers discovery and returns a playable RTSP URI for both streams has passed the checks that matter for 90% of installations.
For the stream test, add the camera to the actual NVR or VMS brand the project will use, not just a generic client. The combination that fails on site is usually a specific pairing — this camera model, that recorder firmware — so test the real pairing with the real firmware versions. Also verify the control plane: request PTZ movement if the camera has a motorized lens or head, and confirm alarm events (motion, tamper) arrive at the recorder. A camera that streams but never reports events is only half integrated.
Finally, record the verification results in the project file — model, firmware, ONVIF version, profiles, test date. That record becomes the acceptance document at handover, and it is the same evidence you need if a later firmware update changes the camera's ONVIF behavior. Verification is not a one-time gate; it is a baseline that every subsequent firmware release should be re-tested against.
ONVIF Buying Checklist for Business Buyers
When you turn ONVIF requirements into a purchase, put these items in the RFQ and the inspection plan. Each one is a written line a supplier can confirm — and a written line is what survives a dispute.
- 1. Demand the profile, not the buzzword. Write "ONVIF Profile S" (and G or T where needed) into the specification. A supplier that answers "supports ONVIF" without a profile letter has not answered.
- 2. Ask for the conformance statement. Request the ONVIF conformance document or the list entry for the exact model and firmware you are buying — not a similar model from the same brand.
- 3. Confirm the ONVIF core version. Ask which ONVIF version the current firmware implements. Old firmware on a new camera is a compatibility risk disguised as a discount.
- 4. Test the real pairing. Before a bulk order, add one sample to the customer's actual NVR or VMS brand, test discovery, both streams, PTZ and event reporting, and record the results.
- 5. Check the network requirements. Confirm the camera needs port 80 (or 443) for ONVIF control and port 554 for RTSP, and that your VLAN and firewall design allows them — plus UDP 3702 if discovery must work across segments.
- 6. Plan the credentials policy. Change default passwords before deployment, use per-site accounts, and document them in the handover pack. Discoverable cameras with factory credentials are a liability, not a feature.
- 7. Verify the firmware update path. Ask whether ONVIF behavior can change with firmware updates and who tests that before release. A supplier that ships a regression is a problem; a supplier that tests and documents it is a partner.
- 8. Include ONVIF in the acceptance test. Make "all cameras discoverable, streaming and controllable through the customer's recorder" a signed acceptance item, not an assumption.
The mindset behind the checklist: ONVIF is a floor, not a ceiling. A Profile S conformant camera guarantees the basics — discovery, streaming, control — and that is already enough to avoid vendor lock-in on the most common CCTV deployments. Everything above the floor (analytics, advanced events, deep PTZ presets) should be specified separately, with the mechanism named in the contract.
For wholesalers, the same checklist scales to the order book: put the conformance statement and firmware version in the product data sheet, keep one sample of each SKU wired to a test NVR, and re-run the stream test after every firmware batch update. That routine is what lets you promise "ONVIF works" to your customers and mean it.
ONVIF Questions Buyers Ask
What is ONVIF?
ONVIF is the Open Network Video Interface Forum, an open industry standard launched in 2008 by Axis, Bosch and Sony that defines common interfaces for network video devices — discovery, configuration, streaming, PTZ and events — so cameras, NVRs and software from different manufacturers can work together.
Is ONVIF a protocol?
ONVIF is a standard built on existing web protocols: it uses HTTP with SOAP/XML messages for control, WS-Discovery (UDP 3702) for finding devices, and RTSP for the video stream itself. Buyers usually describe it as a protocol, but technically it is a set of web services that standardize how cameras are managed.
Is ONVIF the same as RTSP?
No. ONVIF is the control plane: it discovers devices, configures them and returns stream URIs. RTSP is the media plane: it actually carries the video frames, typically on port 554. A camera uses both together — ONVIF to set up the conversation, RTSP to deliver the pictures.
Are all IP cameras ONVIF?
No. Most professional IP cameras are ONVIF conformant to at least Profile S, but many consumer cameras use proprietary apps and SDKs and do not speak ONVIF at all. The spec sheet should name the profile — if it only says "ONVIF compatible" without a profile, verify it before relying on integration.
How do I know if a camera is ONVIF compliant?
Check the ONVIF conformant products list for the exact model and firmware, confirm the profile letter (S, G or T) in the specification, and run a free ONVIF discovery tool against the actual unit — it will show the device's advertised ONVIF version, profiles and stream URIs.
Will any ONVIF camera work with any ONVIF NVR?
Usually, for the basics — if both sides implement the same profile, a camera will be discovered, stream and respond to control commands. Advanced functions like analytics or deep PTZ presets may still need a manufacturer driver, so test the real pairing and confirm which features run over ONVIF before committing.
The Bottom Line
ONVIF is the open standard that lets cameras, recorders and software from different brands work together — but only as far as the profile, the firmware and the network allow. Specify the profile letter, verify the conformance statement, test discovery and both streams with the real recorder, and record the results. A system built on verified ONVIF interoperability avoids vendor lock-in, survives firmware changes and hands over cleanly — and a system built on "ONVIF compatible" stickers is a gamble.
At FULLCOLORCAM, based in Guangzhou, we build 5MP F1.0 full-color night vision IP cameras that are ONVIF conformant, with H.265 streaming, free P2P remote access and every unit tested before shipping. If you are buying or importing cameras and need an ONVIF line you can verify, email us at cj226144@gmail.com — we will send the conformance details, a sample for your discovery test, and a quote with the profile written into it.
NEXT STEP
Ready to Upgrade to Full-Color Night Vision?
Send us your requirements — our team responds by email.
Written by
Ray ChanCCTV Buyer's Guide Author · Full-Color Night Vision Specialist. Ray helps global importers and integrators source factory-direct security cameras.