ONVIF

ONVIF is the IP physical-security interoperability framework used by cameras, encoders, `VMS` / `NVR` platforms, analytics services, access-control devices, and some AV/security crossover control platforms. It is not one media protocol. In practical designs, ONVIF normally provides discovery, device/service description, configuration/control, profile/add-on conformance, PTZ/event/metadata/recording interfaces, and stream URI negotiation. The live media path usually still resolves to `RTSP/RTP` or another ONVIF-defined streaming mode, with codec and security behavior decided by the profile, firmware, and client implementation. **Sources:** ONVIF mission / governance <https://www.onvif.org/about/mission/>; ONVIF profiles overview <https://www.onvif.org/profiles/>; ONVIF profiles/add-ons/specifications overview <https://www.onvif.org/profiles-add-ons-specifications/>; ONVIF network interface specifications <https://www.onvif.org/profiles-specifications-new/>; ONVIF specification history <https://www.onvif.org/profiles/specifications/specification-history/>; ONVIF conformance process <https://www.onvif.org/profiles/conformance/>; ONVIF Conformance Process Specification v5.7 <https://www.onvif.org/wp-content/uploads/2026/04/ONVIF-Conformance-Process-Specification-v5-7.pdf>; ONVIF conformance FAQ <https://www.onvif.org/conformance-faq/>; ONVIF Profile `T` <https://www.onvif.org/profiles/profile-t/>; ONVIF Profile `G` <https://www.onvif.org/profiles/profile-g/>; ONVIF Profile `M` <https://www.onvif.org/profiles/profile-m/>; ONVIF Profile `S` <https://www.onvif.org/profiles/profile-s/>; ONVIF Profile `S` deprecation Q&A <https://www.onvif.org/profiles/profile-s/profile-s-deprecation-qna/>; ONVIF Profile `A` <https://www.onvif.org/profiles/onvif-profile-a/>; ONVIF Profile `C` <https://www.onvif.org/profiles/onvif-profile-c/>; ONVIF Profile `D` <https://www.onvif.org/profiles/profile-d/>; ONVIF Profile `Q` <https://www.onvif.org/profiles/profile-q/>; ONVIF TLS Configuration Add-on <https://www.onvif.org/profiles/add-on/tls-configuration-add-on/>; OASIS `WS-Discovery 1.1` <https://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html>; IANA service-name registry <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>; IANA CSV <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv>; ONVIF Streaming Specification v25.12 <https://www.onvif.org/specs/2512/ONVIF-Streaming-Spec-v2512.pdf> — accessed 2026-05-30, rechecked 2026-06-03 and 2026-06-08 **Infra context:** Treat `ONVIF` as a management/control/discovery layer plus a pointer into separate media services, not as a single firewall exception. For a camera/VMS path, schedule `WS-Discovery` only if automatic discovery is required, schedule the actual device service endpoint over `HTTP` or `HTTPS`, schedule `RTSP` / secure streaming according to the selected profile and camera configuration, and then schedule the negotiated `RTP` / `RTCP` media behavior. For routed enterprise networks, manual camera enrollment is often cleaner than trying to make multicast discovery cross VLANs. **Current verification note:** Official ONVIF, OASIS, and IANA sources rechecked `2026-05-30`: ONVIF mission/profiles/specifications/conformance pages, Conformance Process Specification `v5.7`, conformance FAQ, Profile `S` deprecation, Profile `T` / `G` / `M` / `A` / `C` / `D` / `Q`, TLS Configuration Add-on, ONVIF Streaming Specification v`25.12`, OASIS `WS-Discovery 1.1`, and IANA service-name registry. Port guidance remains unchanged: `UDP 3702` multicast is discovery only; ONVIF device services usually ride over `HTTP` / `HTTPS`; live media is commonly adjacent `RTSP/RTP` or another explicitly supported ONVIF streaming mode; and dynamic media ports cannot be replaced by one generic "`ONVIF port`" firewall rule. The important current lifecycle note is that the June `2026` conformance test tools are the last version enabling new Profile `S` claims and new Profile `S` submissions end on `2027-03-31`; do not design new security-sensitive camera estates around Profile `S` unless a brownfield constraint forces it. **Current verification note, 2026-06-03:** Rechecked the official ONVIF mission, profiles, Profile `T`, Profile `G`, Profile `M`, Profile `S` deprecation Q&A/press release, conformance-process, TLS Configuration Add-on, specification-history, Network Interface Specifications, and Streaming Specification v`25.12` pages, plus OASIS `WS-Discovery 1.1` and the IANA service-name registry. No port-data change: ONVIF still has no single universal "ONVIF port." Schedule the selected workflow planes instead: optional local `WS-Discovery` on `UDP 3702`; ONVIF SOAP/XML device services on the actual `HTTP` / `HTTPS` service port; `RTSP` setup on the configured camera/VMS listener where used; negotiated `RTP` / `RTCP` or interleaved TCP media; and separate VMS/NVR/cloud, firmware/update, DNS/NTP, certificate, MQTT/WebRTC, or vendor-management services where the project actually uses them. The current ONVIF lifecycle signal remains important for firewall and security narratives: Profile `S` new-submission support ends `2027-03-31`, Profile `T` is the current video target, and TLS/add-on support must be named and proven rather than inferred from the ONVIF badge. Sources accessed 2026-06-03: ONVIF mission <https://www.onvif.org/about/mission/>; profiles <https://www.onvif.org/profiles/>; Profile `T` <https://www.onvif.org/profiles/profile-t/>; Profile `G` <https://www.onvif.org/profiles/profile-g/>; Profile `M` <https://www.onvif.org/profiles/profile-m/>; Profile `S` deprecation Q&A <https://www.onvif.org/profiles/profile-s/profile-s-deprecation-qna/>; Profile `S` deprecation press release <https://www.onvif.org/pressrelease/onvif-to-end-support-for-profile-s/>; conformance process <https://www.onvif.org/profiles/conformance/>; TLS Configuration Add-on <https://www.onvif.org/profiles/add-on/tls-configuration-add-on/>; specification history <https://www.onvif.org/profiles/specifications/specification-history/>; Network Interface Specifications <https://www.onvif.org/profiles-specifications-new/>; Streaming Specification v`25.12` <https://www.onvif.org/specs/2512/ONVIF-Streaming-Spec-v2512.pdf>; OASIS `WS-Discovery 1.1` <https://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html>; IANA service-name registry <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>. **Current verification note, 2026-06-08:** Local-library-first review confirmed this Clearport entry and the companion taxonomy file remain the natural homes; no duplicate standalone markdown file was created. Rechecked current official ONVIF mission, FAQ, profile, specification-history, conformance, Profile `T` / `G` / `M`, Profile `S` deprecation, TLS add-on, OASIS `WS-Discovery`, and live IANA CSV sources. Port guidance remains unchanged: `ONVIF` has no single universal firewall row. `WS-Discovery` is optional local discovery on `UDP 3702` to `239.255.255.250` / `ff02::c`; IANA also lists `TCP 3702` for `ws-discovery`, but ordinary ONVIF discovery scheduling should not include `TCP 3702` unless the selected client/device documentation explicitly uses it. Device services remain actual `HTTP` / `HTTPS` endpoints; live video remains the selected stream setup and media path such as `RTSP/RTP`, interleaved TCP, secure streaming, `WebSocket`, or other supported ONVIF streaming mode. The IANA CSV fetched on `2026-06-08` had `Last-Modified: Sat, 30 May 2026 01:11:26 GMT` and still listed `ws-discovery,3702,tcp`, `ws-discovery,3702,udp`, `http,80,tcp`, `https,443,tcp`, and `rtsp,554,tcp/udp`. **Current verification note, 2026-06-13:** Local-library-first review again confirmed this Clearport entry and the companion taxonomy file are the natural homes; no duplicate standalone markdown file was created and `library/INDEX.md` did not need a new-file update. Rechecked current official / primary ONVIF mission, profiles, conformance-process, specification-history, Profile `T`, Profile `G`, Profile `M`, Profile `S` deprecation, Profile `Q`, add-on, TLS add-on, OASIS `WS-Discovery`, and live IANA CSV sources. No port-design change: `ONVIF` still does not have one defensible "ONVIF port" row. Schedule the workflow planes: optional `WS-Discovery` on local `UDP 3702` multicast, actual ONVIF device services over `HTTP` / `HTTPS` or a vendor-configured service port, `RTSP` / secure streaming setup where used, negotiated `RTP` / `RTCP` or interleaved media transport, and separate `VMS` / `NVR` / cloud / firmware / `DNS` / `NTP` / certificate / `MQTT` / `WebRTC` / vendor-management paths where the project uses them. OASIS still anchors `WS-Discovery` multicast to `239.255.255.250` and `ff02::c`; IANA's CSV fetched `2026-06-13` had `Last-Modified: Fri, 12 Jun 2026 22:41:24 GMT` and listed `ws-discovery,3702,tcp`, `ws-discovery,3702,udp`, `http,80,tcp/udp/sctp`, `https,443,tcp/udp/sctp`, and `rtsp,554,tcp/udp`. The registry rows do not prove that `TCP 3702`, `UDP 554`, `HTTP/3`, `RTSPS`, `SRTP`, `WebSocket`, `MQTT`, or `WebRTC` is in use; use only the selected device/client/VMS evidence. | Port / Range | Protocol | Direction | Purpose | Configurable | |---|---|---|---|---| | UDP 3702 to multicast `239.255.255.250` / `ff02::c` | UDP multicast | B on local segment | `WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually. | No | | TCP 80 / 8080 / vendor-specific service port | TCP | B | ONVIF device/client web-services endpoint over `HTTP`, typically SOAP/XML using ONVIF WSDL-defined services. Used for device information, capabilities, media profiles, stream URI retrieval, PTZ/configuration functions, events, user/access functions, and profile/add-on features as implemented. Exact path and port are product/firmware configurable in many cameras. | Usually | | TCP 443 / vendor-specific secure service port | TCP | B | ONVIF web-services endpoint over `HTTPS` where supported. Required by some security-conscious deployments and relevant to `Profile T` / secure-streaming designs, but `HTTPS` alone does not prove the device exposes certificate lifecycle controls or the `TLS Configuration Add-on`. | Usually | | TCP 554 | TCP | B | `RTSP` session/control channel commonly returned by ONVIF media services for live stream setup. IANA registers both `TCP` and `UDP 554` for `RTSP`; in deployed camera work, `TCP 554` and vendor alternate ports such as `8554` are common. | Usually | | TCP 8554 or other configured `RTSP` alternate | TCP | B | Alternate `RTSP` listener where the camera/vendor/VMS does not use `554`, or where multiple services share an appliance. Do not open this by default; verify the selected device/client configuration. | User-configurable | | UDP dynamic `RTP` / `RTCP` ports | UDP | Usually O from camera to client / recorder for media, with control/statistics return as negotiated | Live media payload after `RTSP` setup when `RTP/UDP` is used. There is no universal ONVIF port number; the session description and transport setup decide the client/server ports. | Dynamic / negotiated | | `RTSP` interleaved over TCP 554 / 8554 / configured port | TCP | B | Fallback/traversal mode where `RTP` / `RTCP` are interleaved inside the `RTSP` TCP connection. Useful when firewalls block dynamic UDP, but it trades failure modes and can add head-of-line blocking under loss. | Depends on client/device | | `RTSP` over `HTTP` / `HTTPS` or `WebSocket` modes | TCP | B | ONVIF streaming specifications define additional traversal/secure modes, including secure `RTSPS` and `SRTP` carriage. These are not universal camera defaults; schedule only when the selected profile/firmware/client actually supports and is configured for them. | Depends on client/device | **IT notes:** - `ONVIF` is governed by `ONVIF, Inc.`, a non-profit member forum founded in `2008` by Axis Communications, Bosch Security Systems, and Sony Corporation. Its mission is standardized interfaces for IP-based physical security products and services, not general-purpose AV distribution. - The protocol family is web-services based: `XML`, `SOAP`, and `WSDL` define the control/configuration interfaces. That is why "ONVIF API" usually means SOAP/XML service calls rather than a modern JSON/REST API. - `WS-Discovery` is local multicast. OASIS assigns `UDP 3702`, IPv4 multicast `239.255.255.250`, and IPv6 link-local multicast `ff02::c`. Discovery failure across VLANs does not prove ONVIF is broken; it often only proves multicast discovery is not routed or proxied. - IANA lists both `TCP 3702` and `UDP 3702` for `ws-discovery`, but the normal ONVIF design question is `UDP 3702` multicast discovery. Do not add `TCP 3702` to an AV/security firewall schedule just because the registry contains the row; add it only when the selected implementation documents a TCP discovery/service workflow. - Manual enrollment by IP/FQDN and ONVIF service path is a valid enterprise design. It is often preferable for camera VLANs, secured networks, and large estates where discovery broadcast/multicast should not leak widely. - Do not collapse `ONVIF` with `RTSP`. ONVIF may tell the client what media profiles exist and return stream URIs; `RTSP/RTP`, codec support, keyframe cadence, transport mode, and client decoder behavior still decide whether the picture is usable. - `Profile T` is the new-design video target for advanced streaming. ONVIF states it supports `H.264` / `H.265`, imaging settings, motion/tampering events, metadata streaming, `HTTPS` streaming support, PTZ configuration, and conditional bidirectional audio/digital I/O/relay features. - `Profile T` does not remove the need to document the actual stream engineering profile. Resolution, frame rate, bitrate mode, GOP/keyframe interval, audio codec, multicast/unicast mode, metadata detail, and decoder/client support still need explicit commissioning evidence. - `Profile S` is being deprecated for security reasons. ONVIF says support for new Profile S conformance submissions ends on `2027-03-31` because its username-token authentication requirement no longer aligns with current cybersecurity recommendations. Keep legacy `Profile S` systems contained; do not specify it as the preferred new-design target. - `Profile G` is the edge-recording/storage profile. If the brief requires local camera recording, failover recording, or standards-based retrieval/playback from device storage, `Profile T` alone is incomplete. - `Profile M` is the analytics metadata/events profile. If people counting, object classification, license plate recognition, face/body metadata, analytics eventing, or MQTT-facing IoT handoff matters, name `Profile M` explicitly and verify client support. - Access-control scope is not automatically covered by a camera/video profile. `Profile A`, `Profile C`, and `Profile D` are the access-control side of the ONVIF family; `Profile D` is for access-control peripherals and is not itself an access-control unit. Schedule the actual door controller, reader/peripheral, lock/relay, event, credential, video, and management paths rather than writing one generic ONVIF line. - Do not use deprecated `Profile Q` as a security or commissioning baseline. ONVIF says Profile Q was deprecated on `2022-04-01` because factory-default setup required anonymous access to all ONVIF commands. - Add-ons are separate conformance claims layered on top of profiles. A device being `Profile T` conformant does not mean it supports the `TLS Configuration Add-on`, and the current TLS add-on v1.0 conformance submission path is itself in deprecation with version `2.0` scheduled for early `2027`. - ONVIF conformance is profile-specific, feature-level, and tied to an exact firmware/software version. ONVIF says only products registered in its Conformant Products database are considered conformant, and membership or marketing language alone is not enough. - ONVIF conformance is a member self-declaration scheme using ONVIF test tools and submitted conformance documents. That is useful, but it is not a substitute for bench-testing the actual required workflows: discovery/manual enrollment, authentication, stream profile selection, PTZ, presets, backchannel audio, event subscription, metadata, recording retrieval, and TLS/certificate behavior. - The current public conformance-process page points to `ONVIF Conformance Process Specification` version `5.7` from April `2026`, effective `2026-04-22`; in infrastructure terms, that reinforces the same rule: ask for the product's ONVIF database record, Declaration of Conformance, claimed profile(s), firmware/software version, Feature List, Interface Guide, and client-side conformance evidence where the receiver/VMS/control platform is also part of the claim. - Security responsibility does not end at the ONVIF logo. Segment camera networks, restrict ONVIF/RTSP access to the VMS/control hosts that need it, disable unused insecure services, prefer `HTTPS`/secure profiles where supported, and coordinate firmware/security-hardening ownership with the security integrator or IT team. - ONVIF is good for cross-vendor surveillance interoperability and AV/security crossover camera integration. It is poor for deterministic AV-over-IP distribution, live production switching, IMAG, low-latency operator camera contribution, or as a generic room-AV PTZ command language when `VISCA over IP` or a vendor API is the cleaner supported path. - For firewall schedules, split the workflow by plane: discovery (`UDP 3702`) only if used; ONVIF SOAP/XML device services (`HTTP`/`HTTPS` or vendor port); live media (`RTSP`, negotiated `RTP`/`RTCP`, interleaved TCP, secure streaming, or WebSocket mode); and separate VMS/cloud/firmware/NTP/DNS/certificate services. One broad "allow ONVIF" rule is not a defensible enterprise handoff. - Do not make `WS-Discovery` relay a default requirement. On large or secured networks, explicit camera enrollment by IP/FQDN and ONVIF service path is usually cleaner than extending multicast discovery across security boundaries. Discovery convenience is not the same thing as operational architecture. - When IT asks for "the ONVIF ports," answer with the selected workflow: discovery if used, device service endpoint, stream setup, media transport, secure-streaming option, VMS/NVR/cloud paths, NTP/DNS/certificate services, and update/management paths. The port list is a consequence of the architecture, not a property of the ONVIF logo. - Do not let AV bypass the security owner just because ONVIF can enroll a camera directly. In shared estates, identify whether AV is consuming a direct camera stream, a VMS/restream output, a hardware decoder output, a browser/cloud client, or an access-control/video-entry workflow. Each handoff changes firewall direction, credentials, audit logs, retention/evidence policy, firmware ownership, and recovery testing. - A useful ONVIF commissioning test includes discovery or manual enrollment, authentication, profile retrieval, stream URI retrieval, selected media transport, picture decode, PTZ/preset behavior where required, event/metadata subscription where required, recording retrieval where required, TLS/certificate behavior where required, and recovery after camera/client/VMS reboot and credential change. A port scan is not an ONVIF acceptance test.

Network Ports & Requirements

Port(s)	Transport	Direction	Purpose	DSCP	Multicast	Config.
3702	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
239	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
255	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
255	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
250	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
2	Multicast	Both	`WS-Discovery` ad hoc discovery. ONVIF clients send `Probe` / `Resolve`; devices answer or announce. Useful for commissioning and small flat LANs, but not required if the client is configured with the device service address manually.	—	—	No
—	TCP	Both	ONVIF device/client web-services endpoint over `HTTP`, typically SOAP/XML using ONVIF WSDL-defined services. Used for device information, capabilities, media profiles, stream URI retrieval, PTZ/configuration functions, events, user/access functions, and profile/add-on features as implemented. Exact path and port are product/firmware configurable in many cameras.	—	—	No
443	TCP	Both	ONVIF web-services endpoint over `HTTPS` where supported. Required by some security-conscious deployments and relevant to `Profile T` / secure-streaming designs, but `HTTPS` alone does not prove the device exposes certificate lifecycle controls or the `TLS Configuration Add-on`.	—	—	No
554	TCP	Both	`RTSP` session/control channel commonly returned by ONVIF media services for live stream setup. IANA registers both `TCP` and `UDP 554` for `RTSP`; in deployed camera work, `TCP 554` and vendor alternate ports such as `8554` are common.	—	—	No
8554	TCP	Both	Alternate `RTSP` listener where the camera/vendor/VMS does not use `554`, or where multiple services share an appliance. Do not open this by default; verify the selected device/client configuration.	—	—	Yes
—	UDP	Both	Live media payload after `RTSP` setup when `RTP/UDP` is used. There is no universal ONVIF port number; the session description and transport setup decide the client/server ports.	—	—	No
554	TCP	Both	Fallback/traversal mode where `RTP` / `RTCP` are interleaved inside the `RTSP` TCP connection. Useful when firewalls block dynamic UDP, but it trades failure modes and can add head-of-line blocking under loss.	—	—	No
8554	TCP	Both	Fallback/traversal mode where `RTP` / `RTCP` are interleaved inside the `RTSP` TCP connection. Useful when firewalls block dynamic UDP, but it trades failure modes and can add head-of-line blocking under loss.	—	—	No
—	TCP	Both	ONVIF streaming specifications define additional traversal/secure modes, including secure `RTSPS` and `SRTP` carriage. These are not universal camera defaults; schedule only when the selected profile/firmware/client actually supports and is configured for them.	—	—	No

AV500.io